Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions

From: "Daniel Warren" <[email-masked]>
Date: Wed, 12 Jun 2002 13:53:50 +0100

I am still slightly confused.  In extension type (2), John has described it
as 'Private, vendor extensions'.  I think the significant word here is
'Private' - if, to include a private extension, there is a requirement to
provide an informational RFC and register it with IANA, that sounds more
like a public extension to me.  If, for example, Nokia develops a
proprietary extension for their Diameter implementation, what is to stop
every other vendor from implementing it as well, once it is an informational
RFC?  Basically, the only difference between extension type (1) and
extension type (2) will be in the way it is documented.

If we do take this approach, we should probably remove vendor-id and vendor
extentions completely (since IANA could now manage the name space) and
prohibit all forms of extension that are not put through IETF.  This does
mean that there is no motivation for vendors to innovate using Diameter, and
little possibility for the customers of vendors to be able to obtain any
form of differantiation between suppliers.  I didn't think that was the
intention or the ethos of Diameter as a protocol, but it appears I may have
been wrong.

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 June 2002 08:35
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor
extensions
Importance: High

Hi all,

There seems to be some misunderstanding in the recent discussions
about the role of Diameter extensibility.  I believe there are
2 kinds of extensions:

(1) Public, IETF Standard extensions
(2) Private, vendor extensions

For (1) a standards track document is needed, in my opinion.

For (2) I think a good way forward would be an IANA registry,
with documentation needed, and a strong suggestion for an IETF
informational document.  The reason being is that we want
to keep track of how vendors are extending Diameter and
an Informational document would help the organization proposing
the vendor extension to ensure they are doing the right thing.

If my above analysis of the situation is correct, I can add explanatory
text to section 1.2 & chapter 11.

I would be happy to get AD acceptance on this, at least to be able
to bring this to the IESG.

thanks,
John

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jun 2002 08:44:54 -0700

> I am still slightly confused.  In extension type (2), John has described
> it as 'Private, vendor extensions'.  I think the significant word here is
> every other vendor from implementing it as well, once it is an
> informational RFC?  Basically, the only difference between extension type
> (1) and extension type (2) will be in the way it is documented.
> 
> If we do take this approach, we should probably remove vendor-id and
> vendor extentions completely (since IANA could now manage the name space)
> and prohibit all forms of extension that are not put through IETF.  This
> does mean that there is no motivation for vendors to innovate using
> Diameter, and little possibility for the customers of vendors to be able
> to obtain any form of differantiation between suppliers.  I didn't think
> that was the intention or the ethos of Diameter as a protocol, but it
> appears I may have been wrong.

a vendor may do whatever they wish.  the point is what they can do and
still call it diameter.  when they call it diameter, the customer has
a legitimate expectiation that vendor A's diameter will inter-operate
with vendor B's diameter.  that is what standards are all about.

randy

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 12 Jun 2002 09:44:48 -0700

Randy Bush [mailto://[email-masked]] writes:

...

> with vendor B's diameter.

So you are saying that a customer's expectation that vendor A's
_vendor-specific extensions_ to Diameter will be supported by any, arbitrary
vendor B is legitimate?

> that is what standards are all about.
>
> randy
>
>
>