RE: Guidelines suggested text for checklist:

["David B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...

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

I find this text very troubling.  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.

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.)

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.

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

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

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




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