RE: Capabilities: Summary

["Nelson, David" <dnelson@enterasys.com>]

Alan DeKok writes...

>   Backwards compatibility in existing attributes being "mandatory" for
> an implementation?  Existing Vendor-Specific extensions that don't
> have a mandatory bit?

This could be addressed by encapsulating the existing attributes in the
extended attribute format.

>  Or, *requested* information like location?

I wonder how many attributes will end up falling into this category?
That is to say, informative attributes that the server would like to see
included in Access-Requests as hints to the authorization process.

I am operating under the impression that the Access-Challenge mechanism
was deemed to be a sufficient solution for the desired attributes use
cases.  Is that not so?  I proposed the Mandatory bit to address the
required (to be obeyed, feature to be implemented, service to be
provided) attributes (server to client), not the required to be supplied
attributes (client to server).

>   I don't think the issue is "required attribute support", so much as
> "required and optional functionality support". 

Well, yes, customers worry about functionality.  OTOH, if we were to
communicate functionality, it would require a new IANA registry and
corresponding RFCs for each code point to define *exactly* what the
functionality was.  The nice thing about attributes is that that (we
expect) that the associated functionality is already well defined.

> The mandatory bit in Diameter is nice, but I don't see it as being
> incredibly useful in deployments. 

Given that Diameter interoperability is a charter requirement, what does
this say about the requirements for such a feature in RADIUS?


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>