AD review of draft-ietf-radext-design-05.txt

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

This is the AD review of draft-ietf-radext-design-05.txt. The document
is in good shape, and unless I hear in the next 24 hours any other
opinions from the document shepherd or other WG participants I will send
it to IETF Last Call. 

Please consider the comments below together with the other comments
received during the IETF Last Call. 

Thanks and Regards,

Dan

1. Document title - to a large extent the document deals with RADIUS
attributes, so I am wondering if 'RADIUS and RADIUS Attributes Design
Guidelines' would not be a more appropriate title. 

2. In Section 1.1 - it would be useful to make clear that we are
referring to SDOs outside the IETF. For example: 

OLD: 

   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:

NEW: 

   By articulating guidelines for RADIUS attribute design, this document
   enables SDOs out of the IETF 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 SDOs out of the IETF RADIUS attribute
specifications,
   the authors recommend that:

Ni need to repeat this exercise farther in the document at each
occurrence of the SDO acronyms. 

3. Also in Section 1.1 I suggest that we add a note to make clear that
the AAA-DOCTORS review is a voluntary-based service offered on
best-effort basis.

4. In Section 3.1.3 and Appendix A.5 I suggest that we replace 

s/for use within an SDO/for use within an SDO specification/
s/for use within a group of SDOs/for use within specifications from a
group of SDOs/

5. In section 3.1.4

s/All other specifications, including new authentication and/All other
specifications, including new authentication, authorization and/

6. I think that the IANA Considerations section should mention that
guidelines in this specifications impact sometimes IANA actions. For
example: 

OLD: 

This document requires no action by IANA.

NEW:

   This document does not require that the IANA update any existing
   registry or create any new registry, but includes information that
affects the IANA, 
   for example: 

    - includes guidelines that recommend against allocation from the
RADIUS
   standard attribute space  in other SDO RADIUS Attribute
specifications 
   - recommends requesting a Private Enterprise Code (PEC) from the
IANA, 
   for use as a Vendor-Id within a Vendor-Specific attribute

7. I suggest that we add to Appendix B a note stating that this appendix
is published for informational purposes only, and that it reflects the
usage of attributes with complex data types at the time of the
publication of this document. 


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