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

[Alan DeKok <aland@deployingradius.com>]

Avi Lior wrote:
> 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.  

  It is not necessary.  The special language for "MUST" and "MUST NOT"
is there because there were concerns that the document didn't state
clearly enough that it had no new normative requirements on RADIUS.

  i.e. that text is explanatory, and has no meaning other than to
clarify the role of the document for the reader.  The normal RFC 2119
meanings of those words are unchanged.

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

  The "limited scope of applicability" is explained in the following
paragraph, which references Sections 3.3.2 and 3.3.3.

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

  The limited scope of applicability is explained in detail.  It's
difficult to solve the problem of not explaining in enough detail what
it means, and simultaneously having too much explanatory text in the
document.

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

  The checklist gives a simple and unambiguous definition for when IETF
reviews are needed.  As the rest of the document has been deemed long
and repetitive, a short checklist should be useful.  An SDO wanting to
know if they require an IETF review needs only read a short checklist,
rather than a long and exhausting 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.

  The following paragraph qualifies the above statement with an
explanation as to why complex types are sometimes necessary.  Removing
the recommendation means that the flow and logic of the document would
be broken.

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

  It is intended to refer to the "TLV encoding scheme", i.e. RFC 2865
Section 5.26 encoding of {8-bit type, 8-bit length, data}, versus (e.g.)
the USR encoding of {32-bit type, data}.

  I suggest changing the text to clarify this, by saying:

--
All VSA encodings that do not follow the [RFC2865] Section 5.26 scheme
are NOT RECOMMENDED.  Although [RFC2865] does not mandate
it, implementations commonly assume that the Vendor Id can be used as
a key to determine the on-the-wire encoding of a VSA.  Vendors
therefore SHOULD NOT use multiple encodings for VSAs that are
associated with a particular Vendor Id.  A vendor wishing to use
multiple VSA encodings SHOULD request one Vendor Id for each VSA
encoding that they will use.
---

  This uses terminology which is in line with RFC 2865.  I will also
review the document, and ensure that discussion about TLVs uses
"encoding", rather than "format", for consistency and clarity.

> Issue 6:
>  Section 3.2
> 
> " These approaches are often incompatible, leading to
>    additional complexity in RADIUS implementations."
> 
> But they dont have to be compatible.

  The above text is in a section titled "Rationale", i.e. motivation for
the document.  Motivation includes explanations of why bad things are bad.

> Get rid of that statement.

  If everyone had done "the right thing" for RADIUS design, there would
have been no need for the guidelines document.  Unfortunately, that is
not the case, and the rationale for the document should be explained.

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

  The repetition is a the result of a gradual exposition of ideas.
First, a short introduction.  Second, a set of recommendations.  Third,
a detailed rationale for the recommendations.

  When the recommendations and rational were placed side by side, the
feedback was that the document was too complex, and the text should be
separated.  We cannot, unfortunately go back to the previous layout as
it has already been judged to be inappropriate.

  Alan DeKok.

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