[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Technical Errata Reported] RFC5176 (2012)
Yes 5080 is helpful here - I remember this discussion. I can use it to clear up the issue and squash any arguments at the SDO.
It both describes a problem and provides a way to address this problem:
"If the desire is to allow
limited access, then an Access-Accept can be sent with attributes
provisioning limited access. "
I wish another document was as clear ;-)
There are still issues with this approach since a legacy NAS may not recognize the attributes that provision the limited access. It would have been good to include the warning.
However, in my case this is not going to be a problem.
On 26-01-2010, at 20:58 , Dave Nelson wrote:
>> As you say, most of the existing uses of Error-Cause are for
>> protocol error of some kind, so in looking at the IEEE 802.1X-REV
>> authorization scenarios, the preliminary thinking was to use some
>> other attribute to communicate the content that might end up in
>> EAPOL-Announcements that provide the client with an indication
>> of the access status.
>
> Haven't we already clarified, in RFC 5080 Section 2.6, that with the use of
> an Access-Reject message "no means no" and that Access-Reject cannot be used
> to provision restricted or alternate forms of service or access?
>
>
--
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/>