[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
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:
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
* SDOs request review of RADIUS attribute specifications by
sending email to the AAA Doctors [DOCTORS] or equivalent mailing
* 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
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.