Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue

From: <[email-masked]>
Date: Tue, 11 Jun 2002 12:55:27 +0300

Hi Dan,

I think Randy, as Area Director, may need to speak to the concerns that documenting
extensions as an Information RFC may be too difficult.  The IESG has raised the
issue that all Diameter extensions need a paper trail & informational RFCs are
the way to provide a paper trail in the IETF.

> I have little problem with this text except for the part that says;- 
>
> 'All vendor-specific Diameter commands require Informational RFCs documenting 
> the command and specifying interoperation with Diameter peers not implementing 
> the command.'
>
> There are two points about this that I would like to make.  First, if a vendor 
> is  extending Diameter in some way that it intends to only use between it's own 
> nodes, why should it reveal that extension to the public domain.  In cases where 
> interoperability with another vendor's equipment is required, then the vendors 
> would exchange information on relevant extensions.  I see no good reason for any 
> vendor to submit this information to IETF as it removes the insentive for private 
> innovation and negates the possibility of vendor differentiation.  One of the key 
> points of Diameter is that it is easily extensible.  Putting this kind of bureaucracy 
> in place removes that ease.

My feeling is that if a vendor implements Diameter with non-standard commands,
then they are doing just that, having a non-standard Diameter implementation.

If they wish to have extensions to Diameter, then those extensions should be
standardized, some sort.  

> Second, if you accept the points that Johan and I made with regard to optionality, 
> the behaviour of a peer not implementing the command can be defined here and now as 
> 'ignore it'.  

Randy's comment has been that the current text in Diameter indicates that it is not
optional.  Obviously, then we need additional text in the base spec.

> My feeling is that if you define the behaviour of the receiving peer when it receives 
> a command with a vendor-id it does not recognise (or even one that it does know but 
> with a command code that it doesn't believe to be associated with that vendor-id) 
> as 'ignore the command', then doesn't the requirement for the informational RFC's go away?  

I think that text should be added to the spec, but I don't that the requirement goes away.
The problem is that there is no way to guarentee that an extension is used only in a
closed network (not visible to the interenet).  If it is a useful extension, then why
not document it.  If it is not useful, why do it in the first place?

John

---

From: Johan Johansson <[email-masked]>
Date: Tue, 11 Jun 2002 12:02:08 +0200

>not document it.  If it is not useful, why do it in the first place?

If I were to define some messages to e.g. exchange state information 
between AAA servers the contents of that message almost certainly would 
depend on the implementation and would be useful to me but probably of 
little use to anyone else.

j

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jun 2002 07:21:55 -0700

> I think Randy, as Area Director, may need to speak to the concerns that
> documenting extensions as an Information RFC may be too difficult.  The
> IESG has raised the issue that all Diameter extensions need a paper trail
> & informational RFCs are the way to provide a paper trail in the IETF.

warning: i suspect (but am not sure) the iesg will request it be a standards
action, i.e. a standards track rfc, not info.  the iesg has been down this
road many times before, and tends to be pretty firm in this area.  the iesg
seems to think standards are about inter-operability.

randy

---

From: Johan Johansson <[email-masked]>
Date: Tue, 11 Jun 2002 16:38:02 +0200

>seems to think standards are about inter-operability.

Then again a vendor-specific extension is as far away as you can get 
from a standard and by definition have nothing to do with 
interoperability between vendors. I find it unreasonable that the IESG 
truly wants vendor-specific extensions turned into standards so there 
must be a huge misunderstanding hiding somewhere in all this lack of 
communication.

j

---

From: Pete McCann <[email-masked]>
Date: Tue, 11 Jun 2002 11:14:13 -0500

> seems to think standards are about inter-operability.

I think that would pretty much kill the work going on now to define
the Cx, Dx, and Sh interfaces in 3GPP.  The protocols being defined
for these interfaces could be considered precursors to an
IETF-approved SIP-AAA application, and I suspect if they came before
the IESG for approval they would be vetoed in favor of waiting for the
completed SIP-AAA protocol.

I understand that the current thinking from SIP is to tightly control
the extension process with the goal of better interoperability, but I
would argue that the Diameter suite, with its background in the RADIUS
experience, is a different kind of animal.  There has always been
strong consensus among the working group to support a clean mechanism
for vendor-specific (non-standards-track and even non-documented)
extensibility.  The usefulness of the Diameter base protocol will be
severely impaired if these functions are removed.  I daresay that 3GPP
would be tempted to go define its own version of the Diameter protocol
(let's call it Circumference, because it's a way around the IETF) to
put these attributes back in.

Philosophically, I do not really agree with the sentiment that
extensions should be tightly controlled.  I think the purpose of the
IETF is to build communications infrastructure and then get out of the
way, and allow end-to-end applications to experiment and develop on
their own.  That is how I view the Diameter base protocol.  Should we
go back and try to prohibit any non-standards-track UDP applications
from being used on the Internet?  I think not.

-Pete