Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 10 Jun 2002 15:42:04 -0400

Based on the summary of Randy's concerns presented this morning, the
protocol mechanisms for extensibility are not the issue.  The issue is that
the document must state a requirement that extensions be publicly
documented.  Probably the form of that documentation will be required to be
an IETF Informational RFC, analogous to the SIP P-Header process now being
tested in the SIP WG.

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Monday, June 10, 2002 3:35 PM
To: 'Ignacio Goyret'; Randy Bush
Cc: Bernard Aboba; [email-masked]
Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans
port-07 drafts

Certainly we have existence proof of what Ignacio describes below 
with the RADIUS protocol. Not necessarily something we want to 
duplicate. 
Perhaps we can better understand the concerns so that we can react 
better than just scrapping a major feature. 
PatC 
- -----Original Message----- 
From: Ignacio Goyret [mailto:[email-masked]] 
Sent: Monday, June 10, 2002 12:30 PM 
To: Randy Bush 
Cc: Bernard Aboba; [email-masked] 
Subject: Re: [AAA-WG]: Request for IETF last call on Diameter-11 and 
Transport-07 drafts 

At 09:32 PM 6/8/02 -0700, Randy Bush wrote: 
> 
>as ad, i will not be passing this to the iesg for review.  there is 
>one  comment that has not been addressed by -11, vendor-specific 
>commands.   as i have repeatedly said, if i was to pass this to the 
>iesg, it is a  sure show-stopper. 
> 
>rather than saying it all over again, can folk please review the 
>mailing list archive on this.  essentially, the iesg has a hot- 
>button  about mandatory vendor commands. 
If that is true, it seems to me the IESG needs to get a big dose of 
reality check. A fact of life is that the IETF and just about every 
other standard body moves ever so slowly that vendors are forced to 
add vendor specific extensions to satisfy their clients. Often, those 
extensions become de-facto "standards". 
Now, would you prefer those extension mechanisms to be ad-hoc, where 
interoperability will probably be an issue or would you prefer that 
vendor extension mechanisms be defined up front in a way that 
guarantees interoperability?

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2002 12:58:09 -0700

it's two things

in general, extensions need ietf process.

and, non-standard extensions can not be mandatory.  e.g. when dynamic
negotiation over an extension fails, the fault must clearly be with
the side demanding the extension, not the side not implementing it.

randy

---

From: Johan Johansson <[email-masked]>
Date: Tue, 11 Jun 2002 10:51:20 +0200

Randy and others,

I hereby join the officially confused party. Specific items of confusion 
below.

>in general, extensions need ietf process.

Try as I may to grasp it the meaning of that statement eludes me.Your 
objection is against vendor-specific extensions. I would have thought 
that they by definition were outside the scope of ietf. The whole 
purpose of making a vendor-specific extension is to avoid ietf process. 
If it goes through ietf process, in what way would it be vendor-specific?

>the side demanding the extension, not the side not implementing it.

This is self-evident. Where and in what way do the current drafts fail 
to meet this criterion? Wouldn't it be better to quickly fix these 
problems rather than to remove a feature that we know beyond a shadow of 
a doubt will be requested and implemented by ugly hacks if we don't 
provide a controlled means for it?

j