Avi review of I-D Action:draft-ietf-radext-design-13.txt

[Avi Lior <avi@bridgewatersystems.com>]

Section 1.2

Issue 1:
Special language is provided for "MUST" "MUST-NOT"  do we need to state the same for "SHALL" and "SHALL-NOT"?  I am not sure because I haven't checked.  

Section 1.3.1

Issue 2:
"We do not forbid these specifications, but it is
   RECOMMENDED that they are created only if they have a limited scope
   of applicability, and all new attributes defined in those
   specifications are VSAs."

What is meant by "limited scope of applicability"?  Is it limited scope of applicability within the SDO?  I would think not.  It is already stated in this section that - SDO can design for their own purposes in several places in this section:

 "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."

Is "limited scope of applicability" over and above that?  The basic problem is that we have lots of text that is repeating in this section.

Issue 3:

I disagree that:

 * use only the "basic data types" (see below) for all VSAs;

Please delete that.  Since the next bullet 

Actually, the last bullet suffices:

  * follow the guidelines given in this document.

I suggest getting rid of the bullets and just state:

 It is RECOMMENDED that SDOs and vendors seek review of RADIUS
   attribute specifications from the IETF.  However, specifications do
   not require IETF review when they follow the guidelines given this document.

Issue: 4:

Section 2.1

Change:

 All other data formats are defined to be "complex data types", and
   are NOT RECOMMENDED for normal use.  Nested attributes, or attributes
   grouped via methods other than defined in [RFC2868] do not qualify as
   "basic data types", and SHOULD NOT be used.

To
 All other data formats are defined to be "complex data types", and
   are NOT RECOMMENDED for normal use including nested attributes, or attributes
   grouped via methods other than defined in [RFC2868].

I think the document asserts already that complex data types should not be used.

Issue 5:

Section 2.2

The following text does not make sense:

" Vendors therefore SHOULD NOT use multiple
   formats for VSAs that are associated with a particular Vendor Id.  A
   vendor wishing to use multiple VSA formats SHOULD request one Vendor
   Id for each VSA format that they will use."

If a vendor defines two VSAs one of a basic type and another of a non-basic type they should not require a new vendor id.  Please delete this recommendation.

Issue 6:
 Section 3.2

" These approaches are often incompatible, leading to
   additional complexity in RADIUS implementations."

But they dont have to be compatible.

Get rid of that statement.

Issue 7:

Section 3.3.3:
Is repeating text in previous sections: 1.3.1

The level of repetition in this document is very high. Points are stated and restated and restated.  It is very exhausting to read.


Avi Lior
avi@bridgewatersystems.com
office: +1 613-591-9104x6417
    cell: +1 613-796-4183



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