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

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Mar 2008 09:41:28 -0800

RADEXT WG last call has concluded on draft-ietf-radext-extended-attributes-00.txt. 

Two comments were received:
http://ops.ietf.org/lists/radiusext/2008/msg00095.html
http://ops.ietf.org/lists/radiusext/2008/msg00096.html

This leaves three open issues on the document (225, 250 and 251):
http://www.drizzle.com/~aboba/RADEXT/

A new version of the document has been posted to the archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-01.txt

The major difference between version -00 and -01 appears to be a change to the TLV format: 

In -00, Section 4 stated:

"   TLVs are encoded as follows:

   o  The first octet is the Ext-Type field

   o  The second octet is the Ext-Length field, representing of the
      entire TLV, including the length of the Ext-Type field (1 octet),
      the length of the Ext-Length field itself (1 octet) and the length
      of the Value field (1 or more octets)"

-01 Section 4 now states:

"   TLVs are encoded as follows:

   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).

   o  The next 2 octets are the Ext-Type field

   o  The next octet is the Ext-Length field, representing of the entire
      TLV, including the length of the Ext-Type field (2 octets), the
      length of the Ext-Length field itself (1 octet) and the length of
      the Value field (1 or more octets)

   o  The Value field consists of one or more octets comprising the
      actual data."

Since previous discussion of these changes on the RADEXT WG mailing list
was inconclusive (see http://ops.ietf.org/lists/radiusext/2008/msg00000.html)
the Chairs would like to determine whether RADEXT WG consensus exists for
the changes or not. 

We are requesting RADEXT WG participants to review the -01 Extended Attributes
draft and to post a note the RADEXT WG mailing list indicating their support 
(or opposition) to the changes.  Specifically:

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

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

The Consensus call will last until March 29, 2008.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 08 Mar 2008 19:12:27 +0100

> http://ops.ietf.org/lists/radiusext/2008/msg00096.html

  I have a review pending, too.  But I'll add a few comments here.

>       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

  No.

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

  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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 9 Mar 2008 14:21:04 -0400

[email-masked] <> scribbled on Saturday, March 08, 2008
10:12 AM:

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

...

---

From: Alan DeKok <[email-masked]>
Date: Sun, 09 Mar 2008 20:51:45 +0100

> at the mouth.  In fact, this paragraph was just left in _by mistake_

  I'm sorry I can't tell intent from the content of the draft.

> legacy typespaces to overlap.

  I have no objection to them overlapping.  It's a *good* idea for them
to overlap.  I just don't know what it means to allow old-style
attributes in a new-style format.

>  If that was the case, one would obviously

  Never.  RADIUS is a horrible protocol with huge amounts of legacy
cruft.  I am very wary of breaking existing systems, no matter how
appealing the idea may seem.

  Alan DeKok.