Re: Guidelines suggested text for checklist:

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
...
>>    Vendor RADIUS Attribute specifications SHOULD allocate attributes
>>    from the vendor space, rather than requesting an allocation from the
>>    RADIUS standard attribute space.  Vendor RADIUS Attribute
>>    specifications MUST NOT allocate attributes from the standard space
>>    (i.e. attributes 1 through 255).
> 
> I would delete the above sentence since we can't change IANA allocation
> policy within a BCP.

  Perhaps that was badly phrased.  The intent isn't to change IANA
allocations.  The intent is to make it clear to vendors that poaching on
the IANA space is wrong.

>>    Vendor allocations from the
>>    standard space would prevent inter-operation with later standards
>>    that follow the IETF process.
> 
> Not if the vendor requested and received an IANA allocation, correct? 

  Correct.

> Or do we mean to say "self-allocate"?

  Yes.  I can clarify the text.

>>    Vendors SHOULD NOT allocate new values for attributes of enumerated
>>    type (e.g. Service-Type), despite the Vendor Specific Enumerations
>>    proposal in [RFC2882] Section 2.2.1.
> 
> I would not specifically mention Service-Type since this has its own
> IANA allocation policy.  Also, we might say more about why VSEs are a
> bad idea elsewhere in the document.

  Because they're poaching on the IANA allocation space.  If a VSE is
useful, a vendor can update their edge equipment to support
Vendor-Service-Type, with vendor-specific values.

  Suggested replacement text for the two paragraphs:

   Vendor RADIUS Attribute specifications SHOULD allocate attributes
   from the vendor space, rather than requesting an allocation from the
   RADIUS standard attribute space.  Vendors are reminded that
   allocations from the standard space MUST follow the process described
   in [RFC3575] Section 2.1.  Vendor RADIUS Attribute specifications
   MUST NOT allocate attributes with vendor-specific meaning from the
   standard space (i.e. attributes 1 through 255).  Uncoordinated
   allocations from the standard space would prevent inter-operation
   with later standards that follow the IETF process.
...
   Vendors SHOULD NOT allocate new values for attributes of enumerated
   type (e.g. Service-Type), despite the Vendor Specific Enumerations
   proposal in [RFC2882] Section 2.2.1.  Such allocations may only be
   performed under the guidelines of [RFC3575] Section 2.1.  Instead,
   vendors SHOULD allocate an attribute from their Vendor-Specific
   space, and define an appropriate value for it.


  I think that's clearer: Allocations from the standard space requires
that the standard process be followed.

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