[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guidelines suggested text for checklist:



  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.


Right.


  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.
Reading the text, I'm still not sure if we want them to create their own new VSA or to get a proper IANA allocation. Most vendors seem to prefer the latter, and is to be discouraged, I think we need more explanation about why.
How about "Rather than self-allocating new values for attribute of enumerated type (as described by the Vendor Specific Enumerations proposal in [RFC2882] Section 2.2.1), vendors SHOULD obtain an allocation under the IANA guidelines of [RFC3575] Section 2.1. If this is not possible, vendors should allocate an attribute from their Vendor-Specific space, and define an appropriate value for it." 



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