[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt



owner-radiusext@ops.ietf.org <> scribbled on Saturday, March 08, 2008
10:12 AM:

> Bernard Aboba wrote:
>> Two comments were received:
>> http://ops.ietf.org/lists/radiusext/2008/msg00095.html
>> http://ops.ietf.org/lists/radiusext/2008/msg00096.html
> 
>  I have a review pending, too.  But I'll add a few comments here.
> 
>>    o  The first bit is the Standard or 'S' flag.  The Standard flag
>>       is set (1) if the TLV is a standard RADIUS attribute (as
>>       defined in RFC 2865, for example), otherwise it is clear (0).
> 
>  That's just bad practice.  With a 16-bit format, there's
> plenty of room to leave the first 256 attributes as
> "old-style".  A separate bit to indicate this does nothing
> more than complicate things.

Alan, I really wish that you could say something about this w/o frothing
at the mouth.  In fact, this paragraph was just left in _by mistake_
from my changes that introduced the (obviously excellent to me,
apparently akin to heretical to you) idea of allowing the extended and
legacy typespaces to overlap.  If that was the case, one would obviously
need to be able to determine if type 29 was legacy type 29 or new type
29.  In any case, I gave up the battle for sanity in this WG some time
ago, so you can stop: one will never be able to group legacy RADIUS
attributes, nor have more than one instance > 255 octets in length in a
single message.  Happy?

...



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