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

[Alan DeKok <aland@nitros9.org>]

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.

>    o  The next 2 octets are the Ext-Type field

  See my earlier comments.  If we're going to a 2-byte Ext-Type field,
then the Diameter AVP format is more flexible, powerful, and takes up
just as much space as this format.

> a. Do you support increasing the size of the Extended-Type field to two
> octets,
> from one octet?

  No.

> b. Do you support use of the RADIUS Extended Type VSAs to encode standard
> RADIUS attributes?

  No.

  My preferences for the format, in order of priority, are:

  1) Extended format as in -00 of the draft
  2) Diameter AVP format as in draft-wolff-radext-ext-attribute
  3) anything else

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