RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document

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

My review comments on the -04 version as are follows:

(1) Short-lived reference.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

* Reviews of specifications are posted to the RADEXT WG or
equivalent IETF mailing list;

The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
WG completes its charter and closes one of these days.  :-)  This text
provides no guidance to the reader as to how to determine what constitutes
an "equivalent" IETF mailing list.

Requested change:

* Reviews of specifications are posted to the RADEXT WG mailing list or
another IETF mailing list suggested by the Operations & Management Area
Directors of the IETF;


(2) Misplaced modifier.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

   RADIUS protocol changes, or specification of attributes that
   can be used to, in effect, provide new RADIUS commands (such as
   Service-Type) require greater expertise and deeper review, as
   do changes to the RADIUS operational model, as described in
   Section 3.3.

Service-Type is an attribute, not a command.

Requested change:

   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.


(3) Undefined term.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 2.1.3
Rationale/Explanation of issue:

   As a result, the introduction of new complex data types
   within RADIUS attribute specifications SHOULD be avoided,
   except in the case of complex attributes involving authentication
   or security functionality.

"Security functionality" is a term that could be assigned a fairly broad
range of possible meanings.  Well intentioned RADIUS Attribute designers
might think this applies to any attribute that they wish to remain "secure"
or which has security implications for their product, e.g. important service
provisioning parameters.  While the term is defined by various examples in
Appendix B, I think a better "normative" definition is required here.

Requested change:

Add a definition of what constitutes "security functionality".  Given that
I'm having difficulty in suggesting specific text to accomplish this, I'm
thinking it's not all that obvious.  Do we need to reference "security
functionality" at all, or is an exception for "authentication credentials"
sufficient?


(4) Needlessly IETF-centric viewpoint.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 3.1.3
Rationale/Explanation of issue:

  SDO RADIUS Attribute specifications SHOULD 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.

This leads me to believe that the authors think that other (non-IETF) SDOs
(or worse yet, groups of SDOs) are unlikely to define attributes that are
useful to the broad Internet Community.  That may or may not be true.  I'm
guessing that what this really means is that only the IETF ought to be
consuming standard RADIUS attribute IDs, based on IANA allocation, and all
other bodies need to host attributes in a private code-point space (i.e. the
assigned VSA block).  Does this document intend to Update RFC 3575?

I think the conditional phrase "for attributes matching any of the following
criteria" will almost always evaluate to TRUE because of the second and
third bullet items, so the whole paragraph makes little sense to me.

If the issue is standard attribute scarcity, isn't this addressed by the
RADIUS Extended Attribute format [EXTEN]?

I think that this document should provide better guidance as to when an IANA
allocation from the standard RADIUS Attribute code-point space is
appropriate.  Does the need for interoperability between multiple SDOs meet
that threshold?  Or must the usage be of general applicability to the
Internet Community?  How does the existence of the Extended RADIUS Attribute
(a VSA with a code-point block assigned to the IETF) change the distinction
between "standard" and "VSA" allocations?

Requested change:

  SDO RADIUS Attribute specifications SHOULD allocate attributes from
  the vendor space, rather than requesting an allocation from the
  RADIUS standard attribute space, unless the attributes match any of the
  following criteria:

   * attributes intended for interoperable use across multiple SDOs.
   * attributes intended for interoperable use across a broad spectrum 
     of the Internet Community.


(5) Format issues.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 3.3
Rationale/Explanation of issue:

      * The RADIUS protocol is stateless; * Provisioning of services is
      not possible within an Access-Reject; * Distinction between
      authorization checks and user authentication; * Authentication and
      integrity protection of RADIUS packets; * The RADIUS protocol is a
      Request/Response protocol.

Bulleted list not well formatted.

Requested change:

  * The RADIUS protocol is stateless;
  * Provisioning of services is not possible within an Access-Reject;
  * Distinction between authorization checks and user authentication;
  * Authentication and integrity protection of RADIUS packets;
  * The RADIUS protocol is a Request/Response protocol.


(6) Bad reference.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Requested change:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

A.1.2 --> A.1.1


(7) Missing definition/reference.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Where do we normatively define the term "extended data types"?

Requested change:

Add a definition, or a reference to a definition.  Does this, in fact, mean
the RADIUS Attribute format defined in [EXTEN]?

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types [EXTEN] SHOULD be used only where 
   there is no clear method of expressing the data using existing types.


(8) Duplicate section title.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.3, A.2.2
Rationale/Explanation of issue:

Both of these sections are entitled "Complex data types".  One of them is
permissive and the other prohibitive.

Requested change:

Clarify the subject of each of these sections in its title.


(9) Confusion over allocation policy.

Submitter name: Dave Nelson
Submitter email address: d.b.nelson@comcast.net
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: A.5
Rationale/Explanation of issue:

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage
      * 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.

As discussed in comment (4), above, attributes intended for interoperable
use across multiple SDOs *could* qualify for allocation from the standard
RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
space.

Requested change:

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage
      * attributes relying on data types not defined within RADIUS
      * attributes intended for use within an single SDO
     


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