[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.