[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
Avi Lior wrote:
> On 06-01-2010, at 15:54 , Alan DeKok wrote:
>> 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
SHOULD != MUST
This is a BCP document. If SDOs choose to ignore the SHOULDs, they
will not be following BCP. But there is *nothing* in the document that
prevents them from ignoring the BCP recommendations.
> 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.
How?
> Either RADEXT formally adopts this usage or not. I would argue that it is too late.
There appeared to be consensus that this usage was OK for the BCP.
The document has passed a number of last calls && IESG reviews.
> By specification i assume that you mean SDO specifications. Right? well you should state that.
Vendor or SDO specifications. That should be clear from the context.
> 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.
You're right. The IETF has no control over any IETF protocol, and
should give up now. It's *crazy* talk for the IETF to suggest how the
IETF protocols should be used. I mean, who's kidding, who? An IETF BCP
should apply only to the IETF, and SDOs should pay *zero* attention to it.
> 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.
You can't re-define it.
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/>