Re: IPv6 Address Option

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
>>"New attributes SHOULD NOT use this tagging method...". Which is it?
> 
> The tagging scheme in draft-lourdelet does not have the same flaws as
> that described in RFC 2868.  So does the Design Guidelines advice even
> apply here?

  The draft-lourdelet document defines a new data type.  8-bit tag,
followed by 32-bit integer.  While this is arguably better than the RFC
2868 form, it still is a new data type.  And the document discourages
new data types.

  As with most protocol design, there is room for an intelligent
application of checks and balances.  The issues associated with defining
a new data type should be weighed against the issues associated with
re-using a deprecated data type.

  An application of intelligence is suggested.  A thoughtless
application of the guidelines is not appropriate, as is a thoughtless
rejection of it.  I will note that the *only* "MUST" text in the
document is:

   1) provisioning of new services MUST be done in the IETF

   2) service provisioning MUST NOT be done in Access-Reject.

  All other "MUST" text in the documents are quotes from other RFCs.

  Hence, the suggestions of the guidelines documents are SHOULD, SHOULD
NOT, etc.  A reviewer following the guidelines document is perfectly
free to *not* follow its suggestions, if he believes that doing so would
be worse than the alternatives.

  Maybe the document needs to say:

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.  Reviewers are expected to weigh the cost and
   benefits of following or ignoring the guidelines, as nearly all
   suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
   intent is for the guidelines to help authors create better documents.
   This intent means that reviewers can choose to ignore some of the
   recommendations herein.  When this is done, their review MUST be
   accompanied by an explanation as to why the guidelines were not
   followed, and why following the guidelines would have resulted in
   a worse architecture.

>  Perhaps the Design Guidelilnes document should be more
> clear about exactly what the flaws were in the RFC 2868 scheme that the
> SHOULD NOT applies to. 

  Or, it could say that the tagging mechanism MAY be used when none of
the above limitations apply.

  Alan DeKok.

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