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

From: Avi Lior <[email-masked]>
Date: Wed, 2 Jun 2010 11:14:51 -0400

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
[email-masked]
office: +1 613-591-9104x6417
    cell: +1 613-796-4183

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Jun 2010 11:02:35 +0200

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

> 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 ow…

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

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

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

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

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

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

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

---

From: Avi Lior <[email-masked]>
Date: Thu, 3 Jun 2010 06:51:58 -0400

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

Okay.  Perhaps giving an example of what is meant by encoding otherwise this may be confused with formatting.

---

From: Avi Lior <[email-masked]>
Date: Thu, 3 Jun 2010 06:59:05 -0400

> not the case, and the rationale for the document should be explained.

The above states that the approach taken by SDOs when working on their attributes was incompatible - but as the document asserts SDOs dont have to be compatible with other SDOs.

Just say:

These approaches lead to additional complexity in RADIUS implementations.

Avi Lior

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Jun 2010 14:52:01 +0200

> The above states that the approach taken by SDOs when working on their attributes was incompatible - but as the document asserts SDOs dont have to be compatible with other SDOs.

  No, it does not.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Thu, 3 Jun 2010 13:52:10 -0400

With which do you disagree when you say "No, it does not."
a) The above states that the approach taken by SDOs when working on their attributes was incompatible.
b) but as the document asserts SDOs dont have to be compatible with other SDOs.
c) Both of these statements

???

Avi Lior

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Jun 2010 22:00:39 +0200

> With which do you disagree when you say "No, it does not."

  It's a rather straightforward reading of the message:

You: ... the document asserts SDOs dont have to be compatible
       with other SDOs.

Me:  No, it does not.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 3 Jun 2010 16:53:23 -0400

My thinking on the applicability of design guidelines has always been  
pretty simple.  It starts with the premise that any Standards  
Development Organization (SDO) is in the business of defining  
interoperable standards.  If we can't all agree that this is a truism,  
we have deeper problems.  Within that framework, the notion that what  
one SDO does will never impact any other SDO or the Internet Community  
at large is questionable.  It may be true sometimes, but I don't  
believe it's universally true.

Within the scope of RADIUS Attribute design and compatibility, I think  
there are three levels:

(1)  Attributes that are of interest to a single vendor, e.g., for a  
single product line.  No cross-vendor interoperability is needed.

We use Vendor-Specific Attributes for these cases.  The rules are  
pretty lax.  Code-point allocation is managed by the vendor with the  
number space defined by their Private Enterprise Number (PEN).

(2) Attributes that are  of interest to an industry segment and a  
single SDO that serves that industry.  WiMAX is one example.  Multi- 
vendor interoperability within an industry segment is expected.

We use SDO-Specific Attributes (SSA) for these cases, which are VSAs  
in terms of format and code-point allocation, using a PEN assigned to  
the SDO rather than one assigned to an individual vendor.  The rules  
are more stringent.  Compliance with the design guidelines is strongly  
encouraged, but review by outside agencies (the IETF, AAA Doctors,  
etc.) is purely optional.

(3)  Attributes that are of broad interest to the Internet Community.   
Global Internet multi-vendor interoperability is expected.

We use Standard Attributes for these cases, with code-point allocation  
via IANA, subject to the appropriate IETF review and consensus.   
Strict conformance with the design guidelines is expected, unless a  
good case can be made for an exception, and those tasked with  
reviewing the proposals will almost certainly use the design  
guidelines as a review checklist.

---

From: Avi Lior <[email-masked]>
Date: Thu, 3 Jun 2010 22:56:17 -0400

Read this:

Section 1.3 ....

 While SDOs and vendors MAY choose to create specifications not
   following these guidelines, this should be done only when those
   specifications are intended for use in scenarios within a limited
   scope of applicability.  Where general usage is possible, adhering to
   these guidelines is RECOMMENDED.

Unless i am missing something  -- the above states that they dont have to be compatible.

Avi Lior

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jun 2010 07:07:09 +0200

> Unless i am missing something  -- the above states that they dont have to be compatible.

  No, it does not.  The word "compatible" does not appear in that text.
 I have no idea what you mean by "compatible".  That word could mean
almost anything.

  Two SDOs may choose to ignore the guidelines, but may still both be
"compatible", or they may not be "compatible".  The document does not
distinguish between those two scenarios.

>>... the document asserts SDOs dont have to be compatible
>>       with other SDOs.

  The only usage of "compatible" in the document is via the word
"incompatible", as in:

	... different groups taking different approaches.
	These approaches are often incompatible, leading to
	additional complexity

  The document suggests that incompatibility is a problem to be avoided.
 You assert that the document says the exact opposite.

  I repeat my objection: No, it doesn't.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jun 2010 09:15:19 +0200

David B. Nelson wrote:
> pretty simple.

  While I agree, discussion shows that isn't a uniformly held opinion.

> Within the scope of RADIUS Attribute design and compatibility, I think

  If it's all right, I'll wordsmith that and put it into the introduction.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Fri, 4 Jun 2010 09:26:54 -0400

> distinguish between those two scenarios.

In the context of this document and in the context of the specific section I was commenting on --  i think it is darn clear what we mean by compatible or incompatible.

In any case....

>  I repeat my objection: No, it doesn't.

No i don't assert the opposite.  I am saying the document allows for SDOs to create incompatible specifications.  To repeat what I said with appropriate words highlighted:  "the document asserts SDOs DONT HAVE TO BE COMPATIBLE." 

back to the original issue - that is issue 6:

Issue 6: Section 3.2

Just say "These approaches often lead to additional complexity in RADIUS implementations."

I dont see the need to bring incompatibility statement into this paragraph.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 4 Jun 2010 09:38:45 -0400

> If it's all right, I'll wordsmith that and put it into the  
introduction.

Of course.  Anything to help move this document along.