MUST vs. SHOULD, Mandatory vs. Optional

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

RADIUS has never had a protocol-based notion of Mandatory vs. Optional
Attributes.  There is a proposal to add this feature, by means of an
explicit "M" bit in the format of certain classes of extended
attributes.  I'm going to withhold substantive comment on that proposal,
until I have had more time to contemplate the all implications. This
would be a useful feature.  OTOH, our charter is not to evolve RADIUS
into Diameter.

There has also been some discussion as to when to use MUST and when to
use SHOULD in describing new attributes defined within RADEXT documents.
One issue is with respect to conformance and whether a MUST implies that
existing NASes must be upgraded to implement the feature to be "RADIUS
compliant" or be useful in environment where the new attribute is in
use.

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 (where RFCxxx defines the new feature and its
attributes).  RFCxxxx can specify a MUST only with respect to
implementation of the feature described in the document.  I think of
this as a "conditional MUST", which means MUST if and only if the
underlying extended feature has been implemented. 

If the MUST language is appropriate to describing the need for specific
attribute handling or implementation with respect to the new feature,
then the language ought not to be softened to SHOULD, just because some
NASes will not implement the new feature. The scope of applicability of
the RFC should clearly indicate that the requirements of the document
apply to NASes that implement the feature described in the document.

The capabilities announcement functionality should be sufficient to
address global interoperability issues with respect to NASes that do and
do not implement the new feature.  These considerations should be part
of the respective document.

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