RE: Review of draft-ietf-radext-design-01.txt

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Bernard Aboba writes...

There is some overlap in coverage.  My recommendation is to reorganize
the discussion as follows:
 
"1.  Introduction
   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other Standards Development
   Organizations (SDOs).  By articulating RADIUS design guidelines, it 
   is hoped that this document will encourage the development and
   publication of high quality RADIUS attribute specifications.
   The advice in this document will not be helpful unless it is put to use. 

   As with "Guidelines for Authors and Reviewers of MIB Documents"
   [RFC4181], it is expected that this document will enable authors to
   check their document against the guidelines prior to requesting a
   review (such an "Expert Review" described in [RFC3575]).  Similarly,
   it is hoped that this document will be of use to reviewers (such as
   WG participants or the AAA Doctors) in improving the consistency of
   reviews.
 
   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.
 
   In order to characterize current attribute usage, both the basic and
   complex data types defined in the existing RADIUS RFCs are reviewed,
   together with the ad-hoc extensions to that data model that have been
   used in Vendor-Specific Attributes.

DBN: I think this text is very good.

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 enable IETF review of SDO RADIUS attribute specifications,
   the authors recommend:
 
      * Development of a program to encourage SDOs to make their RADIUS
      attribute specifications publicly available;
      * Review of IETF and SDO specifications according to the
      guidelines proposed in this document;
 
   The advice in this document applies to attributes used to encode
   data.


DBN:  I think this last sentence could be a bit more specific.  All
attributes encode data.  The question is what kind of data.  I think what
you want to say is:

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.


   RADIUS protocol changes, or specification of attributes that
   can be used to provide new RADIUS commands (such as Service-Type) are
   out of scope.

DBN: I recommend clarifying this last sentence just a bit by:

s/can be used to provide new RADIUS commands/can be used to, in effect,
provide new RADIUS commands/


   Since protocol changes require greater expertise and
   deeper review, 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.
 
   As with protocol changes, this document does not provide guidance to
   document authors seeking to change the RADIUS operational model.
   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.
   See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute."
 


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