Re: "Last Look" at the RADIUS Design Guidelines document

[Avi Lior <avi@bridgewatersystems.com>]

On 06-01-2010, at 15:54 , Alan DeKok wrote:

> Avi Lior wrote:
>> Great!!!! But this also creates confusion.  Because what is RADIUS.....
>> 
>> IETF publishes a document that says its BAD to do something if it is RADIUS and not bad if it is not RADIUS --- then it better define what is meant by RADIUS.  Otherwise I have to live with the debate for the rest of my SDO life.
> 
>  The guidelines document says "SDOs do whatever the heck they want".
> 
>  If this isn't clear, we can put it in 50pt blinking neon text.
> 


Not only it is not clear but also not true and I want it to be true ...  In section 3.1.1  there is text that contradicts what you say.  Here it is:

"
The design and specification of VSAs for multi-vendor usage SHOULD be
   undertaken with the same level of care as standard RADIUS attributes.
   Specifically, the provisions of this document that apply to standard
   RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage."

Please get rid of that text!

Also in 3.1.3 ....

It is RECOMMENDED that SDOs follow the guidelines
   outlined here, which are intended to enable maximum interoperability
   with minimal changes to existing systems.

Also since you already have an applicability section and you already make the recommendations that SDOs and vendors follow this document -- you dont need to repeat yourself over and over again.  So please get rid of the repeated text.


So reading the document with respect to SDOs....

In section 3.1.1 please remove the "stuff" related to SDO Specific Attribute (SSA).
This is only going to create confusion.  Either RADEXT formally adopts this usage or not.  I would argue that it is too late.

  As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
   Attribute" to refer to an encoding format which can be used by
   individual vendors to define attributes not suitable for general
   usage.  However, since then VSAs have also become widely used by SDOs
   defining attributes intended for multi-vendor interoperability. As
   such, these attributes are not specific to any single vendor, and the
   term "Vendor-Specific" may be misleading.  An alternate term which
   better describes this use case is SDO-Specific Attribute (SSA).


Thus in section 3.1.1 the last two paragraphs should go.

Back to applicablity section 1.3

"It is RECOMMENDED that SDOs follow the guidelines articulated in this
   document.  Doing so will ensure the widest possible applicability and
   interoperability of the specifications, while requiring minimal
   changes to existing systems. ....
This is fine but the rest is problematic...
"
 Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.  However, we
   recognize that there are some situations where SDOs or vendors
   require the creation of specifications not following these
   guidelines.  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 attributes defined in those specifications
   are VSAs, as discussed Appendix A.5, below."

By specification i assume that you mean SDO specifications.  Right?  well you should state that.

Assuming that is correct then i have a problem with the text...

I dont think that the IETF has a say on whether they can prohibit or "not recommend" or even recommend an SDO specification.  I think you have captured what needs to be captured in the previous part and also in the following paragraph.

And also what does it mean that all the attributes are VSA....  you mean i cant reuse an attribute such as User-Name as defined by 2865 in my SDO specification.  I don't agree with that.






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