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

Re: Guidelines suggested text for checklist:



3.1.1.  Vendor Allocations

   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. 


   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? Or do we mean to say "self-allocate"? 



   As discussed in [RFC2865] Section 5.26, the vendor space is intended
   for Vendors to support their own extended attributes not suitable for
   general use.  However, it is RECOMMENDED that Vendors follow the
   guidelines outlined here, which are intended to enable maximum
   interoperability with minimal changes to existing systems.

   Following these guidelines means that RADIUS servers can be updated
   to support the vendor's equipment by editing a RADIUS dictionary.  If
   these guidelines are not followed, then the vendor's equipment can
   only be supported via code changes in RADIUS server implementations.
   Such code changes add complexity and delay to implementations.

   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. 


   Instead, vendors SHOULD
   allocate an attribute from their Vendor-Specific space, and define an
   appropriate value to it.

   If Vendors require multi-vendor interoperability for some RADIUS
   specification, then the guidelines given below for SDO allocations
   SHOULD be followed.

3.1.2.  SDO Allocations

   SDO RADIUS Attribute specifications SHOULD allocate attributes from
   the vendor space, rather than requesting an allocation from the
   RADIUS standard attribute space, for attributes matching any of the
   following criteria:
...

  ... as posted previously.

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