RE: MUST vs. SHOULD, Mandatory vs. Optional

["Nelson, David" <dnelson@enterasys.com>]

> >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.

It says that they may be ignored, which means the same thing.

> 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 agree.

What I meant by "protocol-based notion" was an attribute by attribute
flagging mechanism, such as we have in Diameter.

> >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.

Um...  Yes, there is that practical side to the issue.  I would hope
that the number of new features (I'm explicitly avoiding the word
"application" because of the debate that's been going on over on the AAA
WG list), would be small, such that it might be practical to have an RFC
per feature.  Certainly not an RFC per attribute, as I see each new
feature as requiring a set of new attributes.

-- Dave



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