Subject: Re: Questions on modified Extended Attribute format?

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Jan 2008 05:13:10 +0100

Glen Zorn wrote:

> As I said, put that way or any other way you like, ANY change is
> incompatible with existing deployments.  If one were to add a new "standard"
> attribute (in the old format or the proposed VSA-like format or any other)
> it would be incompatible with existing deployments.

  That isn't the point.  Everyone accepts that implementations have to
be updated to handle new standards.  One of the major efforts in RADIUS
has been to maintain backwards compatibility with existing deployments.

  i.e. if a product doesn't implement the new standard, it can still
communicate with products that do implement that standard.

  This proposal breaks that completely.  It will be perfectly legal for
implementations of your proposal to put ALL RADIUS attributes as
grouped, inside of an "extended attribute".  Any NAS that receives such
a response will get a packet containing *nothing* but VSA's.  It will
then decide that there is nothing in the packet that it recognizes, and
will fail.

  i.e. your proposal creates a new protocol that is incompatible with
legacy RADIUS.

> Actually, while the timeframe was long, the discussion wasn't: I've only
> received a couple of comments on it in the last months.  It _did_ take an
> inordinate amount of time to reject the 'Diameterization' of RADIUS,
> though...

  This proposal is no better.  It's worse in many respects.

  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: Bernard Aboba <[email-masked]>
Date: Thu, 3 Jan 2008 00:54:25 -0800

> This proposal breaks that completely. It will be perfectly legal for> implementations of your proposal to put ALL RADIUS attributes as> grouped, inside of an "extended attribute". Any NAS that receives such> a response will get a packet containing *nothing* but VSA's. It will> then decide that there is nothing in the packet that it recognizes, and> will fail.
>
> i.e. your proposal creates a new protocol that is incompatible with> legacy RADIUS.
 
Presumbably new attributes using the extended format will define 
whether they can be grouped or not, and if so, what the grouping
means.  
 
But what about legacy attributes?  For example, what would it mean for a 
NAS-Identifier attribute to be grouped with say, a Tunnel-Password
attribute?   Presumably, this document would not define the semantics
of grouping for legacy attributes, which begs the question of where,
if anywhere, that semantic would be specified.  
 
Unless that semantic is specified somewhere (and I doubt it would be
specified anywhere for a substantial period of time), then the semantics
of grouping of legacy attributes is likely to be "implementation specific". 
 
So not only would the "new" RADIUS not be backward compatible with
the old one -- it wouldn't even have a public specification.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 7 Jan 2008 22:44:53 -0800

That isn't the point.  Everyone accepts that implementations have to
be updated to handle new standards.  One of the major efforts in RADIUS
has been to maintain backwards compatibility with existing deployments.
[gwz] 
You keep saying that but I really don't know where you get this funny idea.
[/gwz]

[gwz] 

  This proposal breaks that completely.  It will be perfectly legal for
implementations of your proposal to put ALL RADIUS attributes as
grouped, inside of an "extended attribute".  Any NAS that receives such
a response will get a packet containing *nothing* but VSA's.  It will
then decide that there is nothing in the packet that it recognizes, and
will fail.
[gwz] 
Only if the authentication method in use is EAP, I think.  RFC 2865 doesn't
list any attributes as required in any type of response; if your client
fails because it can't find any attributes in the packet, your client is
broken.  Of course, if the aim is to maintain backwards compatibility with
existing _deployments_ (rather than the existing _protocol_) we need to
support broken clients, right?
[/gwz]

[gwz]
Really?  Tell me what happens when a NAS receives, say, a tunnel attribute
that it doesn't understand; then tell me how that is different from the
introduction of _any_ new standard attribute and how it constitutes
"communication".
[/gwz]

[gwz]
Care to expand upon that a bit?
[/gwz]

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 7 Jan 2008 22:55:35 -0800

[gwz]

 Presumably, the implementors would be interested in actually accomplishing
something & not merely playing word games & landing red herrings.  They also
might not ignore the second word in the phrase "group related attributes"
which occurs at least 6 times in the draft.  Are NAS-Identifier &
Tunnel-Password related attributes?  If so, and someone wanted to group them
together, that could be documented.

[/gwz]

[gwz]

Why is it necessary to specify the semantics of every possible combination
of RADIUS attributes?  Obviously, it's not; all that is required is to
define those groups that are useful, which in any reasonable process could
be done as the utility of those groupings became apparent.
 [/gwz]

---

From: Alan DeKok <[email-masked]>
Date: Tue, 08 Jan 2008 09:31:55 +0100

> You keep saying that but I really don't know where you get this funny idea.

  New extensions cannot break existing deployments.

  This is NOT the same as saying new extensions require new code for
implementations to support those extensions.

>> [ re: packing standard attributes inside of extended ]
> broken.

  The client will reject the user, or will apply the wrong policy (i.e.
default "empty response" policy, rather than the policy in the
response).  Please explain to the user and administrator that the users
are being rejected because of a new feature in RADIUS, and that this is
a Good Thing.

> introduction of _any_ new standard attribute and how it constitutes

  The issue is NOT introduction of a new standard attribute.  The issue
is encapsulating standard attributes that the client DOES understand in
a VSA that the client DOES NOT understand.

> Care to expand upon that a bit?

  If you're going to increase the attribute space, AND support long
attributes, you might as well give up and use the Diameter AVP format.
Your proposal involves:

   VSA header: 2 bytes  (type, length)
   Vendor-Id of zero: 4 bytes
   Extended attribute header: 3 bytes (16 bit type + length)
   "continuation" flag: 1 byte

  For a total of 10 bytes of header for one attribute.

  The "Diameter AVP in RADIUS" involves:

   new attribute header: 2 bytes
   Diamater header: 8 bytes (4 byte type + 4 byte length)

  For a total of 10 bytes.  Plus, conversion to Diameter in Diameter to
RADIUS gateways is easy.  We can get arbitrary grouping via the Diameter
method.  We can have attributes as long as we want.  AND the coding is
much, much, easier.

  I implemented the Diameter format as a test a while ago, and it was
~400 LoC, in part because it could leverage the existing code base of
Diameter encapsulation/decapsulation.  I've been looking at the extended
attribute format.  It doesn't leverage any existing code.  It has an
awkward "continuation" byte, which means it can't use any of the
pre-existing VSA handlers, etc.

  This proposal offers LESS than the "Diameter AVP in RADIUS" does, at
the cost of MORE work.

  We've been having this argument for too long.  We need to stop NOW,
pick a format, and move on.  The endless re-visiting of attribute format
is holding up other key work.

  Alan DeKok.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 8 Jan 2008 10:23:40 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Tuesday, January 08, 2008 8:45 AM
> To: 'Alan DeKok'
> Cc: [email-masked]
> Subject: RE: Questions on modified Extended Attribute format?
> 
> Glen Zorn wrote:
> 
> > attribute (in the old format or the proposed VSA-like format or any 
> > other) it would be incompatible with existing deployments.
> 
>   That isn't the point.  Everyone accepts that 
> implementations have to be updated to handle new standards.  
> One of the major efforts in RADIUS has been to maintain 
> backwards compatibility with existing deployments.
> [gwz]

The current RADEXT charter is quite explicit about the requirements for
backwards compatibility. 

- All RADIUS work MUST be backward compatible with existing RADIUS 
RFCs,
including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.

Dan

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Jan 2008 09:13:00 -0800

> is holding up other key work.

This discussion does need to stop.  

The RADEXT WG has already discussed this issue extensively, and come to
consensus.  Re-design of the RADIUS attribute format (as originally advocated
in the "Design Guidelines" document) was discussed and rejected.
"Diameter in RADIUS" proposals were discussed and rejected. 
The consensus of the WG has been to extend the RADIUS attribute format in
backward compatible manner, and that is a requirement in the RADEXT WG
charter.

Since other IETF documents have a dependency on attribute extension, we need to
get on with it. 

Perhaps the quickest way to do that is to bring the document to WG last 
call, and focus on addressing the last call comments from this point forward.

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 8 Jan 2008 22:17:22 -0500

WiMAX did try to align at one time.  But things have changed.

And to get WiMAX to align again with the IETF would be hard now.  We
would need a good reason to change given that we have implementation.
But not impossible since lots of things are changing.

But to be 100 clear, the WiMAX encoding is WiMAX's encoding and not
IETF.  While compatiblity is desirable it is not required at this stage.

It would have been nice if the IETF addressed the issues -- much --
earlier.  

Note in WiMAX we use the M bit but dont use the tag part. 

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Wednesday, December 26, 2007 9:59 PM
> To: [email-masked]
> Bernard Aboba writes...
> > >  WiMAX uses the same attribute format as proposed here.  Changes 
> > > that are incompatible with WiMAX should be discouraged.
> > 
> > I would agree.   If the extensions remain compatible with WiMAX then
> > the amount of code duplication will be minimized.
> 
> I'm not so sure that I agree.  We should do what's right for 
> the RADIUS community.  If that happens to be compatible with 
> WiMAX, then great.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 9 Jan 2008 00:15:12 -0500

Regarding allowing legacy attributes to be grouped within the extended
attribute.

Lets look at it from a practical perspective.  If I am writing a new
"Application" which will use grouping and I need to encode the IP
address of the NAS.

In Glen's proposal I would reuse the existing attribute NAS-IP vs. what
others are saying I would have to create a new attribute called
New-NAS-IP and include that in the grouped attribute.

Glen's approach *seems* more appropriate no?

I dont understand Alan's comment.  The NAS-IP that appears in the RADIUS
message is semantically different then the NAS-IP attribute that is
going to be grouped.  The semantics for the former case is defined by
RFC2865 and the semantics of the later case would be defined by a new
RFC.

This is no different in Diameter.  An attribute can appear standalone
and also be included in a group (for that matter, in many groups).  The
definition of the attribute is the same in both cases, but the semantics
is different right?

So what am I missing?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 09 Jan 2008 08:14:05 +0100

> RFC2865 and the semantics of the later case would be defined by a new

  The traditional RADIUS data model has involved defining new attributes
for new semantics, even if the contents are commonly understood items
like IP addresses.

> definition of the attribute is the same in both cases, but the semantics

  Diameter implementations are more flexible and capable about AVP's
than RADIUS implementations.  This is solely because the Diameter AVP
format is more flexible and capable than the RADIUS AVP format.

  If we agree to use the Diameter format for extended attributes, then
we would obtain all of the benefits of that format for new attributes.
And that format is more flexible and capable than the current proposal
in the extended attributes draft.

  Alan DeKok.

---

From: "Matt Holdrege" <[email-masked]>
Date: Tue, 8 Jan 2008 23:21:15 -0800

While I completely understand the disappointment with the IETF RADIUS
development process I don't think that it is a good idea to give up on
alignment. Alignment is a VERY serious issue given that mixed 802.11 and
802.16 networks will be the norm for many, many years to come. 

And although there are a few WiMax implementations out now, 802.16e in a
real sense still hasn't started yet so I don't see any serious problem
with making changes. 

-Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Wednesday, January 09, 2008 4:17 AM
To: David B. Nelson; [email-masked]
Subject: RE: Questions on modified Extended Attribute format?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 9 Jan 2008 00:11:00 -0800

Avi --

Is it correct to say that the current proposal is compatible with WiMAX VSAs? 

For example, is there no tag part in the WiMAX VSAs, or is it just not used in any existing VSAs? 
----------------------------------------
> Date: Tue, 8 Jan 2008 22:17:22 -0500
> From: [email-masked]
> To: [email-masked]; [email-masked]
> 
>> archive: 
> archive:

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 9 Jan 2008 09:39:17 -0500

Bernard,

Here is the WiMAX VSA definition (the payload of a RADIUS Type 26
attribute).  As you can see it aligns with the earlier proposal.  The
fragmentation concept is used but the tag concept is not used but is
reserved. 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WiMAX Type    | Length        | Continuation  | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Continuation Field is defined as follows:
 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
The C-bit of the continuation field indicates if a WiMAX attribute is
being fragmented.
When the C-bit is set to one '1' this indicates that the attribute is
being fragmented that is
the next WiMAX VSA of the same WiMAX type is to be appended to this
attribute.
When the C-bit is set to zero '0' this indicates that the next attribute
is not a fragment of
this attribute.
A WiMAX attribute that is not being fragmented will have the C-bit set
to '0'. A WiMAX
attribute that is being fragmented will have its C-bit set to '1' for
all fragments until the last
fragment which will have its C-bit set to '0' indicating it's the last
fragment of the attribute.
The r-bits are reserved for future use. They SHALL be set to zero by the
sender and
SHALL be ignored by the receiver.

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 3:11 AM
> To: Avi Lior; David B. Nelson; [email-masked]
> >> I'm not so sure that I agree.  We should do what's right for the 
> >> RADIUS community.  If that happens to be compatible with 
> WiMAX, then 
> >> great.
> >> 
> >> 
> >> 
> >> --
> >> [email-masked] with the word 'unsubscribe' in a 
> >> single line as the message text body.
> >> archive: 
> >> 
> > 
> > --
> [email-masked] with

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 9 Jan 2008 10:43:27 -0500

Avi Lior writes...

> An attribute can appear standalone and also be included in a group 
> (for that matter, in many groups).  The definition of the attribute 
> is the same in both cases, but the semantics is different right?

I'm confused by this.  The "definition" of the attribute consists of syntax
(format) and semantics (meaning).  What does it means to say that the
definition is the same but the semantics (meaning) is different?

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 10 Jan 2008 14:03:35 -0800

Romascanu, Dan (Dan) <mailto:[email-masked]> scribbled on Tuesday,
January 08, 2008 1:24 AM:

>>> incompatible with existing deployments.  If one were to add a new
>>> "standard" attribute (in the old format or the proposed VSA-like
>>> format or any other) it would be incompatible with existing
>>> deployments. 
>> 
>>   That isn't the point.  Everyone accepts that implementations have
>> to be updated to handle new standards.
>> One of the major efforts in RADIUS has been to maintain backwards
>> compatibility with existing deployments.
>> [gwz]
>> You keep saying that but I really don't know where you get this
>> funny idea. [/gwz]
>> 
> 
> The current RADEXT charter is quite explicit about the requirements
> for backwards compatibility. 
> 
> RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579,
> and 3580.  

Yup, very true.  That's not what Alan is requiring, however: "backwards
compatibility with existing deployments"
 
--------------------
is not at all the same thing as being backward compatible with the RFCs.
The proposal I'm making is not intended (nor, I believe, is it)
incompatible with the existing RFCs.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 10 Jan 2008 14:52:16 -0800

Alan DeKok <> scribbled on Tuesday, January 08, 2008 12:32 AM:

>> funny idea. 
>> Only if the authentication method in use is EAP, I think.  RFC 2865
>> doesn't list any attributes as required in any type of response; if
>> your client fails because it can't find any attributes in the packet,
>> your client is broken.
> 
>   The client will reject the user, 

If it does, it is broken (modulo the above).

> or will apply the wrong policy
> (i.e. 
> response).  Please explain to the user and administrator that the
> users are being rejected because of a new feature in RADIUS, and that
> this is a Good Thing.  

The users are being rejected because the provider of their client has
made up his own rules about what a valid response is; if they get the
wrong policy (or the wrong service), tell me how that is different from
a client getting tunnel attributes that it doesn't understand &
therefore ignores.
 
> 
>> Really?  Tell me what happens when a NAS receives, say, a tunnel
>> attribute that it doesn't understand; then tell me how that is
>> different from the introduction of _any_ new standard attribute and
>> how it constitutes "communication".
> 
>   The issue is NOT introduction of a new standard attribute.  The
> issue is encapsulating standard attributes that the client DOES
> understand in a VSA that the client DOES NOT understand.  

Tell me the difference in effect.  As for encapsulating all the
attributes in VSAs, that is easily handled by disqualifying the
mandatory attributes (such as User-Name, EAP-Message, etc.) from
inclusion.

>    "continuation" flag: 1 byte

I'm going to give you the benefit of the doubt & assume that you have
actually read the draft & merely misspoke: the "continuation flag" is
one bit, not one byte; the rest of that octet is the Tag field.

>    Diamater header: 8 bytes (4 byte type + 4 byte length)

Pardon me: 4 byte type, 1 byte of flags (BTW, are those 8 bits of flags
actually useful in RADIUS?) and a 3 byte length.  

> 
>   For a total of 10 bytes.  Plus, conversion to Diameter in Diameter
> to RADIUS gateways is easy.  We can get arbitrary grouping via the
> Diameter method.  We can have attributes as long as we want.  

Really?  The "new attribute header" that you conveniently gloss over
above contains a 1 octet total length for the attribute, giving the same
length limit as old-style RADIUS; of course, you could always either a)
just concatenate "Diameter AVPs" of the same AVP type together (but then
you can only have one AVP of a given type in a message) or b) add an
"awkward" continuation BIT to the Flags field of the AVP...

> AND the
> coding is much, much, easier.   
> 
> Diameter encapsulation/decapsulation.  I've been looking at the
> extended attribute format.  It doesn't leverage any existing code. 
> It has an awkward "continuation" byte, which means it can't use any
> of the pre-existing VSA handlers, etc.  

Again, I'm kind of amazed: I thought that you had implemented the WiMax
VSAs.  You mean that that code couldn't be leveraged?  The formats are
practically identical.
   
> 
>   This proposal offers LESS than the "Diameter AVP in RADIUS" does,
> at the cost of MORE work. 

See above.

> pick a format, and move on.  The endless re-visiting of attribute
> format is holding up other key work.  

I agree completely: it is becoming rather painfully obvious (from the
landing of red herrings (make that whales ;-), the frothing at the
mouth, grasping at straws & confusing of implementations with standards)
that this idea is entirely too close to useful to be approved by this
committee.

---

From: Barney Wolff <[email-masked]>
Date: Thu, 10 Jan 2008 21:23:40 -0500

> "awkward" continuation BIT to the Flags field of the AVP...

Well, no.  The proposal was that all the EA TLVs would be concatenated
before being decoded, so the Diameter length fields would delimit the
attributes.  No continuation bits, bytes or logic.  And of course, the
totality of EAs could/should be packed into as many full RADIUS TLVs as
necessary, with much less TL overhead.

Allow me to express some wry amusement that the pretext for rejecting
the Diameter-format proposal was that only attribute typespace exhaustion
was of interest, not attribute length or grouping.  Then, magically,
length and grouping came back.  Being retired, at least I won't have
to code whatever y'all eventually agree on.

-- 
Barney Wolff         I never met a computer I didn't like.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2008 07:26:24 +0100

Glen Zorn wrote:
> made up his own rules about what a valid response is;

  Umm... the provider of their client is compatible with 2865, not with
the new specification allowing 2865 to be tunneled in extended
attributes.  i.e. they haven't upgraded.

  Is this permitted?  Or should we just say "too bad", and move ahead?

> mandatory attributes (such as User-Name, EAP-Message, etc.) from

  Then those issues need to be addressed in the extended attributes
draft.  That should triple it's size, and add another few years to the
time frame. :(

> one bit, not one byte; the rest of that octet is the Tag field.

  I read the draft... I just don't see a need to explain what every bit
means when I'm trying to count bytes.

> "awkward" continuation BIT to the Flags field of the AVP...

  See Barney's comments.

> VSAs.

  Not offically as of yet.  See the web page: no mention of WiMax.

  The Diameter stuff was easy: pack diameter AVP's (using existing
code), encapsulate in RADIUS (~50 lines of new code), etc.  The hardest
part was internal book-keeping && data structure updates.

>> at the cost of MORE work. 

  I've looked into it... the Diameter AVP stuff was easier.

> that this idea is entirely too close to useful to be approved by this

  I thought it was that the goal-posts were changing.  Just as everyone
was resigned to accepting the format in the extended attributes draft...
it changed.

  How about this.  I'll stop arguing with the extensions to the extended
draft if you stop proposing them.  I'm willing to achieve consensus on
the basic format of the extended attributes draft:

    1 byte type
    1 byte length
    1 byte Cttttttt
    data...

  You'll note that my recent objections have NOT been to that format,
but only to the proposed extensions.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Fri, 11 Jan 2008 11:39:08 -0500

You are correct.  In RADIUS definitions we define attributes by specifying the format and meaning.

When we define the meaning typically we say when this attribute "when included in an access accept message it means ...." and "when included in an access request it means ...."

Now if we want to reuse the attribute (because we love the format) in a new container.  We would just have to modify the meaning part of the definition by adding "when the attribute appears as part of this grouping it means ..."

Going forward if you really want to promote reuse when it is possible you would just define the syntax of the attribute and then when you define the container (grouping) which includes that attribute you would define what it means when this attribute is in a particular container/grouping.

> Sent: Wednesday, January 09, 2008 10:43 AM
> > (for that matter, in many groups).  The definition of the
> attribute is
> > the same in both cases, but the semantics is different right?
>
> (format) and semantics (meaning).  What does it means to say
> that the definition is the same but the semantics (meaning)
> is different?
>
>
>
>
> --

---

From: Alan DeKok <[email-masked]>
Date: Mon, 14 Jan 2008 08:53:36 +0100

Glen Zorn wrote:
> It hasn't changed yet, I was proposing to change it in order to provide
> greatly enhanced functionality.

  I was under the impression that the WG had mostly achieved consensus
on the format.

> How about this: leave the extra octet in there, but mark it as
> "Reserved", so at least it will be there for future use?

  If that's the proposal, then I prefer the Diameter AVP format.  It is
simpler, more flexible, and does not require the introduction of yet
another incompatible VSA format.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Jan 2008 06:29:37 +0100

Glen Zorn wrote:
> Not to mention being "backward compatible", right?  Oh, wait, that is
> only a requirement for things you don't like...

  Putting the invective aside, I think you've missed much of what I've said.

 - the format AS PROPOSED IN THE DOCUMENT is OK.
   - I'm not perfectly happy with it, but it's OK
   - it leverages a format used for other purposes: that's great
   - I am fine with it not being "backwards compatible"
   - it achieved WG consensus: that's a miracle

 - The "16-bit" variant recently proposed on the list is not OK
   - it's less nice than the format in the document
   - it's yet another "magic" vsa format
   - it introduces even more incompatibilities than the other format
   - it has not acheived WG consensus
   - it throws away the consensus obtained for the other format.

  To put it bluntly: every argument FOR the 16-bit variant of the
extended format is also an argument FOR the Diameter AVP format.  If you
are going to seriously propose a 16-bit variant of the extended format,
then I think there is a contingent of this WG that would have issues
with that.

  My preference, in order of priority:

  1) extended format AS IN THE DOCUMENT
  2) Diameter AVP format
  3) 16 bit variant of the extended format

  (1) has achieved WG consensus.  (2) and (3) have not.  Can we stop
this, and just move on?

 Alan DeKok.