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