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

From: <[email-masked]>
Date: Wed, 12 Jun 2002 15:40:02 +0100

Dear All,
 
I agree with Dan. I also think the words "public" and "private" are slightly
mis-used here. 3GPP could be considered a "private vendor" but at the same
time, the technical specifications they produce are already publicly
available (http:// www.3gpp.org.ftp/ftp/Specs
<http://www.3gpp.org.ftp/ftp/Specs> ). So why should 3GPP, after producing
their publicly available technical specifications, have to replicate their
work by producing informational RFCs? They more than likely will not; which
would be preferred as it saves duplication which is always bad in standards.
 
But if all that is needed is a paper trail, why not include other standards
bodies documents, not just informational IETF RFCs, as sufficient
documentation for vendor specific extensions?
 
Cheers,
Nick (a "newbie")

-----Original Message-----
From: Daniel Warren [mailto:[email-masked]]
Sent: 12 June 2002 1:54pm
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens
ions

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]
<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: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Wed, 12 Jun 2002 16:50:15 +0200

Hi,

(1) is non-arguable.

(2) John, how do you think this should work? Two examples:

Let's suppose that an external Standards Development Organization develops a vendor-specific extension of Diameter (as has happened in 3GPP). What would 3GPP request IANA to register? The command-codes, AVP codes and result codes + a reference to the appropriate documentation (i.e. a 3GPP specification)? In this case the documentation would be publicly available. For the 3GPP case, I am not sure that an Informational Draft could be accepted by the IESG, on the basis that it can be considered that it collides with future work in the AAA WG.

A different example is a vendor-specific extension, where the vendor is a manufacturer, not a Standards Development Organization. I guess that the vendor would need to register with IANA the same codes as in previous example. The difference here is that the documentation of the specification may well be something that the vendor does not want to make public. A possible solution to this could be not to mandate such pointer to documentation.

In either case, what is the usefulness of this? I mean, when using a Vendor-Id, it should be (as it is with current text) the vendor's responsibility to manage its own namespaces for commands, AVPs and result codes. I would like to understand why IETF may want to know how vendors are using/extending Diameter.

BR/Miguel

-----Original Message-----
From: Johan Johansson [mailto:[email-masked]]
Sent: miércoles, 12 de junio de 2002 14:13
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor
extensions

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

This is undisputable and I doubt that it would be an IETF extension 
otherwise.

>to bring this to the IESG.

I maintain that anything that is vendor-specific is outside the scope of 
IETF, but if this is the only way forward I can live with this being 
added to the text.

j

---

From: "Daniel Warren" <[email-masked]>
Date: Wed, 12 Jun 2002 17:02:06 +0100

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

From what you say here, it sounds to me that we actually have three cases
rather than the two that John described.  There is the Public, IETF
standardised extensions and 'Private', vendor extensions, and then there is
this third 'a vendor may do whatever they wish' extension, just so long as
they don't call it Diameter.

My continued confusion is that if you accept that 'a vendor may do whatever
they wish', and whatever they wish is defined in a way that says 'if you
don't understand it, ignore it' and there are no interactions with the base
protocol that cause the standardised element of Diameter to fail, THAT is
the essence of a vendor-specific extension.  Fundamentally, I don't believe
anyone will ever take the 'Private' path of registering a vendor's own
extension with IANA if the 'whatever they wish' path is open.  By definition
an extension is something that adds to Diameter's functionality with out
affecting the base protocol.  If it has interaction swith the base protocol,
then it is surely an 'enhancement', and in that case it has to be
standardised, or it has to be recognised as something other than Diameter.

Dan

---

From: "Daniel Warren" <[email-masked]>
Date: Wed, 12 Jun 2002 17:05:48 +0100

John

'In the case when a vendor extensions is marked as mandatory, any failures
MUST be the fault of the sending side (the side which sends extension marked
as mandatory).  Also, the system MUST be able to work without the 
non-standard extension.'

This text makes no sense.  If the system can work without a non-standard
extension then the extension is not Mandatory, it's Optional.  In short,
there cannot be a mandatory non-standard extension to anything, it HAS to be
optional, otherwise it HAS to be standardised.

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 June 2002 16:59
To: [email-masked]; Warren, Daniel [MDN05:EP10:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor
extensions

Hi Randy,

> with vendor B's diameter.  that is what standards are all about.

I agree.  I propose the following for vendor extensions:

We need a way for vendors to 'register' their extensions, so that there
is some paper trail.  

In the case when a vendor extensions is marked as mandatory, any failures
MUST be the fault of the sending side (the side which sends extension marked
as mandatory).  Also, the system MUST be able to work without the 
non-standard extension.  In summary, all vendor extensions MUST NOT
harm interoperability.

I propose to add this kind of text to 1.2 'Approach to Extensibility' and
to make the text in the IANA section more bullet-proof.  Also, a
recommendation
that vendors submit documentation for consideration as Informational RFCs
may 
be a good recommendation as well.

John

---

From: "Daniel Warren" <[email-masked]>
Date: Thu, 13 Jun 2002 15:25:28 +0100

> I'd _really_ like it if someone could show where in base-11 it even
suggests
> that a VSC can be "mandatory".

Me too...