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

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 10 Jun 2002 12:35:10 -0700

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: <[email-masked]>
Date: Tue, 11 Jun 2002 06:10:22 +0300

Hi Randy,

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

For vendor-specific commands, should I add text which states
that

1) IETF Process is needed
2) Documentation needs to provide mechanism so that communication with
	Diameter peers without the said vendor-specific command is
	still possible.

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

Is this enough?

John