RE: I-D Action:draft-zorn-radius-pkmv1-03.txt

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

Bernard Aboba writes...

> Given the widely divergent interpretations of the document applicability,
> it would seem that we will need to develop an applicability statement 
> section so that the scope (and intent) of the document is clear. 

Uh...  There *is* an applicability statement, Section 1.1 Applicability.
:-)

I previously quoted part of it.  Here's the complete section:

1.1.  Applicability

   As RADIUS has become more widely accepted as a management protocol,
   its usage has become more prevalent, both within the IETF as well as
   within other SDOs.  Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their RADIUS
   work within the IETF is inherently inefficient and unscalable.  By
   articulating guidelines for RADIUS attribute design, this document
   enables SDOs to design their own RADIUS attributes within the Vendor-
   Specific Attribute (VSA) space, seeking review from the IETF.  In
   order to enable IETF review of SDO RADIUS attribute specifications,
   the authors recommend that:

      * SDOs make their RADIUS attribute specifications publicly
      available;

      * SDOs request review of RADIUS attribute specifications by
      sending email to the AAA Doctors [DOCTORS] or equivalent mailing
      list;

      * IETF and SDO RADIUS attribute specifications are reviewed
      according to the guidelines proposed in this document;

      * Reviews of specifications are posted to the RADEXT WG mailing
      list, the AAA Doctors mailing list [DOCTORS] or another IETF
      mailing list suggested by the Operations & Management Area
      Directors of the IETF.

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes (such as Service-Type) that
   can be used to, in effect, provide new RADIUS commands require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3 .  Such changes should
   not be undertaken outside the IETF and when handled within the IETF
   require "IETF Consensus" for adoption, as noted in [RFC3575] Section
   2.1.


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