RE: backwards compatible introduction of NEW attribute such as CUI

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

Farid Adrangi writes...

> One possibility is to add a new value indicating Missing-CUI-Support
to
> Error-Cause attribute defined in RFC3576.   We most likely need to
define
> specific values for other attributes (e.g., RADIUS location
attributes) as
> Lothar pointed out.  Another possibility is to use the error-code
defined
> in draft-zorn-radius-err-msg-01.txt.  But, The draft is not a WG item
so
> and I am not sure if we can use it for our purpose at this point.
What
> is your thought on this?

I think we should back up and decide what function the error reporting
is intended to serve.  What component is the ultimate consumer of the
information?

Is the intent to:

(a) print a readable text message to the user (human) that will
stimulate an informed call to the appropriate help desk,  or

(b) instruct the NAS to perform a different form of authentication
request, or include different attributes, or

(c) stimulate the NAS to perform an automatic, on-line, firmware upgrade
to acquire the missing, but desired, functionality?

If the desire is (a), a simple, printable message that describes the
authentication policy conditions that are not being met (in layman's
terms) would be appropriate.

If the desire is (b), I offer two further observations.  (1) If the NAS
supported the desired attribute (and was configured to provide it) it
would probably have done so in the first instance.  Unassisted
corrective action is unlikely. (2) If we are talking about introducing
PPP-style capabilities/option negotiation, I still think that is a
slippery slope and a substantial effort to get it right and obtain
interoperability.

If the desire is (c) I'd like to buy one, please.  :-)



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