RE: backwards compatible introduction of NEW attribute such as CUI

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

Lothar Reith writes...

>I like to comment on your statement: 
> David Nelson wrote: 
> You seem to think the "supports CUI but did not advertise" scenario is
> reasonable, and I disagree. I really can't comment, other than to repeat
> myself."
> I continue to believe that "supports CUI but did not advertise" is a
> possible scenario.

Possible, yes.  Reasonable, no.  In my opinion, of course.  :-)

> If you want to exclude this implementation decision and configuration
> decision, than the text should say: if CUI is supported, it MUST be
> advertised in all Access Request Messages.

I would not object to the "MUST" language.  However, I note that Bernard Aboba has proposed defining a new Capabilities-Advertisement attribute, which (presumably) contains a list of supported Attribute IDs (8-bit values).  It might be better to adopt a single Capabilities-Advertisement attribute now, given the requirements for capabilities advertisement in other documents under consideration as WG work items.

> When such "advertise only on as needed basis" policy is in place, the NAS > could on receipt of a Access-Reject with failure cause "CUI-not-
> determined" delay sending the reject message to the client, and rather
> send a second access-request with the CUI-NUL attribute to the server,
> hoping to get back an Access-Accept in time in order to be able to proceed > with accepting the user. Are you aware of any standard which would be
> violated by such an implementation specific behaviour of a NAS ?

No, but IMHO, this optimization (of a few protocol message bytes) is needless complexity.  The "always advertise" approach is much simpler, and therefore easier to "get right", advancing multi-vendor interoperability.  Basically speaking, the KISS principle.  :-)

--
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/>