David,
good point.
I like to add to your list:
(d): print a readable text message to the user (human) that may stimulate a user reaction leading to a successfull authentication in an unmodified or modified second attempt.
By the way:
b) is what I had proposed in the first place. This would allow a NAS to advertise CUI on an as needed basis. After all, initially CUI advertisement may be superfluous in 99,9999999999% of all cases.
Lothar
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Mittwoch, 8. Dezember 2004 20:47
An: radiusext@ops.ietf.org
Betreff: RE: backwards compatible introduction of NEW attribute such as CUI
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/>