[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Technical Errata Reported] RFC5176 (2012)
The summary for this discussion is:
-Access-Accept should be used as defined by 5080.
-However there are dangers - which a capability negotiation could have solved.
-Error-Cause is for protocol errors mostly. Having said that it does have a an Error Code 501 "Administratively Prohibited" which would be a stretch to call a protocol error.
Regarding the Errata. I still think it should be issued because it is not that obvious where Error-Cause can be included. But we know.
-IANA should have clear instruction on how to extend Error-Cause. Currently i dont think they do.
-Unless i am missing something, except for values 0-199 and 300-399, the RFCs do not reserve unused values for Error-Cause -- and then we wonder why people just grab numbers.
-It would have been useful to allow VSA to be included in Access-Reject. So at least an SDO can return an Error-Cause of their own or even Authorization-Failure-Cause or Authentication-Failure-Cause instead of hacking the Reply-Message attribute.
On 26-01-2010, at 21:51 , Dave Nelson wrote:
>> There are just too many unknowns around NAS behavior to over-load
> I don't think anyone has suggested over-loading Access-Accept. If use as
> originally intended, to provision service, it works just fine, at least if
> the service is described in the Service-Type attribute.
> After all, RADIUS is not about answering authorization questions from NASes,
> it's about identifying users and *telling* them what service they get, based
> on their identity, and contextual hints from the NAS.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.