Re: Guidelines suggested text for checklist:

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> I think that the issue is that there is no inherent interoperability
> benefit from rehosting VSAs that already conform to the criteria
> expressed in the document into the RADIUS standard attribute space.
> Creating two ways to express the same attribute does not help
> interoperability -- it hurts it.  As long as a VSA conforms to the
> checklist, it can be added to existing RADIUS servers, so that there is
> no reason for the IETF to force the SDO to use the RADIUS standard space
> solely in order to get the document reviewed.

  Suggested text:

   In particular, 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:

      * attributes defined by vendors and not suitable for general use,
        as per [RFC2865] Section 5.26.
      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   SDOs are encouraged to submit their RADIUS specifications to the IETF
   for publication as an informational RFC.  Vendors defining Vendor-
   Specific dictionaries for their own use SHOULD make their
   specification publicly available, but there is no need to publish
   their specification as an RFC.

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

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