Re: Guidelines suggested text for checklist:

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> Alan DeKok writes...
...
>>       * 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.
> 
> I find this text very troubling.

  It's substantially the same as the least draft.

>  It infers that one type of
> interoperability is required for use in IETF documents (i.e. global Internet
> usage) while something less is required for other SDOs.  What is the IETF,
> after all, but yet another SDO?  We even slight "groups of SDOs".  I think
> this is highly inappropriate.

  No... it means that the IETF does not assert change control over SDO
specifications.  Given 3GPP2, WiMAX, etc. extensions of the RADIUS data
model, it makes sense to acknowledge this reality.

> If what we are trying to say is something like "If you're not doing this
> work in the IETF, we don't want to share our IANA-assigned code points with
> you.", then maybe I understand where this coming from.  (Still don't like
> it, though.)

  Yes, that's true, too.  The standard RADIUS attribute space is
available for allocation through IANA, which requires publication of
specifications via the IETF process, as per RFC 3575.

  Why is this problematic?

> I think we need to be very careful here.  The general implication that I
> take away from the juxtaposition of:
> 
>>       * attributes defined by vendors and not suitable for general use,
>>         as per [RFC2865] Section 5.26.
> 
> with
> 
>>       * attributes intended primarily for use within an SDO
>>       * attributes intended primarily for use within a group of SDOs.
> 
> Is that we think that the work done is other SDOs is less serious that the
> work done in the IETF, and need not be done with as much care.  That
> inference bothers me very much.

  Text can be added to clarify this.  How about the following text added
just after that list above:

   The recommendation for SDOs to allocate attributes from a vendor
   space rather than via IETF process is a recognition that SDOs may
   desire to assert change control over their own RADIUS specifications.
   This change control can be obtained by requesting a Private
   Enterprise Number (PEN) from the Internet Assigned Number Authority
   (IANA), for use as a Vendor id within a Vendor-Specific attribute.
   Further allocation of attributes inside of the VSA space defined by
   that Vendor id is subject solely to the discretion of the SDO.
   Similarly, the use of data types (complex or not) within that VSA
   space is solely under the discretion of the SDO.  It is RECOMMENDED
   that SDOs follow the guidelines outlined here, which are intended to
   enable maximum interoperability with minimal changes to existing
   systems.

>>    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.
> 
> If what we are trying to accomplish is to carve out of the traditional VSA,
> something more akin to a Standard Attribute, in terms of rigor of design and
> scope of applicability, then I think we need better text.

  I'd like to add suggestions for rigor.  Failing that, pointing out
bone-headed mistakes would be sufficient.

>  A few years ago,
> I was promoting use of the term "SDO Specific Attribute" (SSA), to highlight
> the distinction between VSAs defined for proprietary vendor features and
> VSAs (SSAs) defined by SDOs for multi-vendor interoperability within an
> industry segment, or more globally for wide spread LAN or Internet usage.
> That term never quite caught on.  I think that making the distinction is
> important, however, and even if we don't like coining a new term, I think
> the text needs to mode clearly delineate the usage distinctions.

  It sounds like a reasonable term to me.

> If there is general agreement with this philosophy, I'll volunteer to
> suggest some specific text.

  I await your suggestion.

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