Review of draft-ietf-radext-design-00.txt

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

Network Working Group                                           G. Weber
INTERNET-DRAFT                                             Cisco Systems
Category: Standards Track                               Alan DeKok (ed.)
                                                             FreeRADIUS
Expires: March 4, 2008

                                                       4 September 2007

There are some extra spaces in the boilerplate above.  Also, the document is 
a BCP, not Standards Track.

Section 1

  In addition,
  recommendations are made with respect to recommended VSA formats as
  well as handling of RADIUS type 26 attributes within Diameter.

The material on type 26 attribute translation has been removed, no?

Section 2.1.1

  In addition to these data types, follow-on RADIUS specifications
  define attributes using the following additional types:

  IPv6 address   128 bit value, most significant octet first.
  IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
              128 bits of value, most significant octet first.
  integer64      64 bit unsigned value, most significant octet first.

Note the alignment problem in the above entries.

Section 2.1.2

Given the limitations of the existing tagging schemes, is there a 
recommendation to be made (e.g. don't use the existing tagging schemes for 
new attributes?)

Section 2.2

  Other attribute formats are NOT RECOMMENDED.  Examples of NOT
  RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
  lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
  Vendor-Specific contents that are not in Type-Length-Value format.

You need to add a space between this paragraph and the previous figure.

Section 3

  For future work, any extensions to the RADIUS data model should be
  used to minimize the use of complex attributes.

I think you're referring to the extension draft, no?  If so, you might as 
well reference it non-normatively, such as by saying  "Extensions to the 
RADIUS data model such as [EXTEN] make it possible to minimize the use of 
complex attributes."

Section 3.1

  In particular, it is RECOMMENDED that RADIUS Attribute specifications
  allocate attributes from the vendor space, rather than requesting an
  allocation from the RADIUS standard attribute space, for attributes
  matching any of the following criteria:
     * attributes relying on data types not defined within RADIUS *
     attributes intended primarily for use within an SDO * attributes
     intended primarily for use within a group of SDOs.

I think there is a formatting issue here.

4.  IANA Considerations

  This document defines the use of a RADIUS type 26 attribute code in
  the Diameter Protocol space as defined in [RFC3588] and [RFC4005].

Given that type 26 translation is not included any more, I think you can 
instead say:

"   This draft requires no action by IANA."

Appendices

I think that this document needs a "checklist" that a reviewer can go 
through to look for issues.  You might consider including this as Appendix A 
and moving the existing Appendix A to Appendix B.



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