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

From: <[email-masked]>
Date: Wed, 12 Jun 2002 18:44:53 +0300

Hi Miguel,

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

3GPP is working on informational RFCs for SIP in release 5.
This is not a bad precidence.  SDOs and IETF working this
way would save most of us a lot of agony.
 
> 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.

This could / should be done by a simple IANA registry, with
documentation provided at the time of registry.
 
> 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.

The reason being is that the IETF is concerned about end-user
experience over the Internet.  Vendor extensions should not
break the protocol, nor harm the end-users.  

I think the IESG is concerned based on past experiences.  

John

---

From: <[email-masked]>
Date: Wed, 12 Jun 2002 19:15:51 +0300

Dan,

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

It is possible in the base spec to set vendor AVPs to be mandatory.
This is not a problem, it is based upon experiences with Radius.

What is needed is to sort out the rules for this and ensure the correct
paper trail.

John

---

From: <[email-masked]>
Date: Thu, 13 Jun 2002 15:28:49 +0300

Hi Glen,

> > Continue operation - i.e. - not crash, and preferably not abort.
> > Basically, try to have fall back operation.
> 
> Isn't that behavior already defined in the document?

I think some folks did not think this was clear enough.  I think it is in the draft,
but may just need to be clearer.
 
> Maybe, maybe not: if for some reason the visted network needs the extension
> to operate correctly (not that I can think of such a circumstance, but it's
> hard to imagine your example, too), I would prefer denial of access to
> unexplained, bizarre behavior (crash failure is almost always 
> preferable to Byzantine failure).

Ok, lets just suggest that the result should be clear.

John