[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MUST vs. SHOULD, Mandatory vs. Optional
>RADIUS has never had a protocol-based notion of >Mandatory vs. Optional Attributes.
In RFC 2865, it says that attributes that aren't understood may be treated as optional. On the other hand, a RADIUS client that receives a request for a service it does not implement must not provide that service. So the question comes down to what attributes define a service (mandatory) and which don't (optional). One take on this is that Service-Type is a mandatory attribute. That is, if a NAS doesn't support the Service-Type value requested by the server, then it has to act as if an Access-Reject was sent.
>I think that the most that can be said of an existing >NAS that is RFC2865 compliant, but does not implement >a new attribute is that it is not RFCxxxx compliant.
That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869, RFC 3580, etc.). But if each attribute is published in a separate RFC then we end up with a tower of Babel -- creating lots of new RADIUS dialects. That's not helpful.
--
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/>