Revised PROTO: RADIUS Design Guidelines

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

Title:  RADIUS Design Guidelines
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt
 
Status: Best Current Practice
 
Response to template:
 
1) Have the chairs personally reviewed this version of the ID and do
   they believe this ID is sufficiently baked to forward to the IESG
   for publication?
 
Yes.
 
2) Has the document had adequate review from both key WG members and
   key non-WG members? Do you have any concerns about the depth or
   breadth of the reviews that have been performed?
 
Yes. The ID has had 2 working group last calls.
 
3) Do you have concerns that the document needs more review from a
   particular (broader) perspective (e.g., security, operational
   complexity, someone familiar with AAA, etc.)?
 
No concerns.  
 
4) Do you have any specific concerns/issues with this document that
   you believe the ADs and/or IESG should be aware of? For example,
   perhaps you are uncomfortable with certain parts of the document,
   or whether there really is a need for it, etc., but at the same
   time these issues have been discussed in the WG and the WG has
   indicated it wishes to advance the document anyway.
 
No.
 
5) How solid is the WG consensus behind this document?  Does it
   represent the strong concurrence of a few individuals, with others
   being silent, or does the WG as a whole understand and agree with
   it?
 
There is solid consensus behind this document.  The overall approach
to the document has been extensively discussed, both in IETF meetings
and on the mailing list.  Over a dozen people have commented on various
aspects of the document during its development.  The issues raised in
WG last call, available for inspection at 
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -05
version of the document.
 
6) Has anyone threatened an appeal or otherwise indicated extreme
   discontent?  If so, please summarize what are they upset about.
 
No.
 
7) Have the chairs verified that the document adheres to _all_ of the
   ID nits?  (see http://www.ietf.org/ID-nits.html).
 
Yes. An output of the run on this revision of the ID by the online nits
checker:
 
idnits 2.08.10 

tmp/draft-ietf-radext-design-05.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Best Current Practice
 
----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '8' on line 1431
     'The Text field consists of UTF-8 encoded 10646 [8] characters....'


     Summary: 0 errors (**), 0 warnings (==), 1 comment (--).


8) Does the document a) split references into normative/informative,
   and b) are there normative references to IDs, where the IDs are not
   also ready for advancement or are otherwise in an unclear state?
   (Note: the RFC editor will not publish an RFC with normative
   references to IDs, it will delay publication until all such IDs are
   also ready for publication as RFCs.)
 
The document does split references into normative and informative ones.
There are no normative references to IDs.
 
9) For Standards Track and BCP documents, the IESG approval
   announcement includes a writeup section with the following
   sections:
 
   - Technical Summary
 
   This document provides guidelines for the design of attributes used
   by the Remote Authentication Dial In User Service (RADIUS) protocol.
   It is expected that these guidelines will prove useful to authors and
   reviewers of future RADIUS attribute specifications, both within the
   IETF as well as other Standards Development Organizations (SDOs). 
 
   - Working Group Summary
 
    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the design guidelines 
    surrounding complex attributes, as well as the relationship of the
    RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute
    space.  There was also considerable discussion relating to the
    process for review of RADIUS attributes specified by SDOs.  
    Ultimately, a consensus developed behind a model similar to that
    described in [RFC4663]. 


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