Re: WGLC for draft-ietf-radext-radius-extensions-01

[Alan DeKok <aland@deployingradius.com>]

  I've submitted -02 which addresses the concerns below.  All SHOULD /
MAY / MUST / etc. has been removed from the IANA considerations section.

  It repeated text elsewhere in the document, so there is no loss.

  Alan DeKok.


Bernard Aboba wrote:
> Here are my comments:
> 
> The IANA Considerations section needs to be revised.  It is recommended
> that the IANA considerations section be rewritten according to the
> recommendations of RFC 5226, and that this be cited as a normative
> reference.
> 
> Some issues:
> 
> 1. The IANA considerations section does not specify how attributes are
> to be allocated from the extended space, using policy terms defined in
> RFC 5226.
> 2. Normative language terms "SHOULD"/"SHOULD NOT" are used in Sections
> 9.1 and 9.5. 
> 
> The IANA is not a policy making body and therefore is not capable of handling MAY, SHOULD or SHOULD NOT directives. 
> 
> 
>       9.1. Attribute Allocations
> 
> 
> 
>    IANA is requested to move the "Unassigned" numbers in the range
>    144-191 from "Unassigned" to "Deprecated".  This status means that
>    allocations SHOULD NOT be made from this space.  Instead, allocations
>    SHOULD be taken from the Extended Type space, starting with lower
>    numbered attributes.  However, allocation from the "Deprecated" space
>    MAY still be performed by publication of an IETF specification, where
>    that specification requests allocation from the "Deprecated" space,
>    and gives reasons why use of the Extended Type space is impossible.
> 
> 
> [BA] 
> 
> It seems that the goal is to still allow allocation from the Unassigned range, while preferring allocation from the Extended Type space.
> 
> A more implementable way of accomplishing this might be to say that unless specifically requested to allocate from the Standard RADIUS space,
> IANA should make allocations from the extended type space. 
> 
> 
>       9.5. Extending the RADIUS Attribute Type Space
> 
> 
> 
>    The extended RADIUS Attribute Type space may eventually approach
>    exhaustion.  When necessary, the space SHOULD be extended by
>    publication of a specification which allocates new attributes of
>    either the "Extended Type", or the "Extended Type with flags" format.
> 
> [BA] This material relates to IETF not IANA processing, and so is not
> appropriate for an IANA considerations section.  The IANA cannot handle
> the policy decisions that are implied here. 
> 
> 
>    The specification SHOULD request allocation of a specific number from
>    the "Reserved" RADIUS Attribute type space, such as 247.  The
>    attribute(s) SHOULD be given a name which follows the naming
>    convention used in this document.  The Extended-Type value of 26 MUST
>    be allocated to a "Vendor Specific" attribute, of data type "esv".
>    The Extended-Type values of 241 through 255 MUST be marked as
>    "Reserved".
> 
>    IANA SHOULD allocate the attribute(s) as requested.  For example, if
>    allocation of attribute 247 is requested, the following definitions
>    MUST be made in the specification, and allocated by IANA.
> 
>    * 247.1          Extended-Attribute-7
>    * 247.{1-25}     Unassigned
>    * 247.26         Extended-Vendor-Specific-7
>    * 247.{27-240}   Unassigned
>    * 247.{241-255}  Reserved
> 
>    We note,however, that the above list is an example, and we do not
>    request or perform allocation of attribute 247 in this document.
> 
> 
> 
> 
> 
> 
> 


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