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

From: "Daniel Warren" <[email-masked]>
Date: Tue, 11 Jun 2002 10:41:29 +0100

John

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.

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

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?  Who cares what the
commands are if all I need to know is that if I don't recognise it, I don't
do anything with it...

Regards

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11 June 2002 10:13
To: [email-masked]
Subject: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific
command code issue

Hi all,

Here is my suggested text for Diameter to fix this issue.

John

1.2  Approach to Extensibility

   The Diameter protocol is designed to be extensible. However, it is
   strongly encouraged to reuse existing mechanisms before attempting
   any Diameter extensions.  The extensibility includes:

      - Defining new AVP values.
      - Creating new AVPs
      - Creating new authentication/authorization applications
      - Creating new accounting applications
      - Application authentication procedures

   The extension MUST be documented through an IETF process.  The 
   documentation MUST describe interaction with Diameter peers 
   that do not implement the extension.

******

3  Diameter Header

[clip]

   Vendor-ID
      In the event that the Command-Code field contains a vendor
      specific command, the four-octet Vendor-ID field contains the IANA
      assigned "SMI Network Management Private Enterprise Codes"
      [ASSIGNNO] value. If the Command-Code field contains an IETF
      standard Command, the Vendor-ID field MUST be set to zero (0). Any
      vendor wishing to implement a vendor-specific Diameter command
      MUST use their own Vendor-ID along with their privately managed
      Command-Code address space, guaranteeing that they will not
      collide with any other vendor's vendor-specific command, nor with
      future IETF applications. All vendor-specific Diameter commands
      require Informational RFCs documenting the command and specifying
	interoperation with Diameter peers not implementing the command.

---

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Tue, 11 Jun 2002 12:00:25 +0200

Hi,
 
I support Dan's statement.
 
What is missing in the existing capabilities exchange procedure that doesn't allow a pre-negotiation of the vendor-specific applications that two peers support? If a peer supporting a vendor-specific application doesn't receive the indication from the corresponding peer of the support of the same application, according to existing text in the base, it mustn't send commands belonging to such application.
 
BR/Miguel

-----Original Message-----
From: Daniel Warren [mailto:[email-masked]]
Sent: martes, 11 de junio de 2002 11:41
To: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue

John 

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

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

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?  Who cares what the commands are if all I need to know is that if I don't recognise it, I don't do anything with it...

Regards 

Dan 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: 11 June 2002 10:13 
To: [email-masked] 
Subject: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific 
command code issue 

Hi all, 

John 

****** 

3  Diameter Header 

[clip] 

   Vendor-ID

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 11 Jun 2002 10:26:22 -0400

The SIP precedent is active right now.  P-headers are Informational.  See
draft-tsvarea-sipchange-02.txt.

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 10:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific
command code issue

> 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: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 11 Jun 2002 11:05:11 -0400

Again, look at the SIP change process draft I cited in my previous message.
The reason for IETF oversight is to protect the integrity of the protocol
architecture.

-----Original Message-----
From: Johan Johansson [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 10:38 AM
To: Randy Bush
Cc: [email-masked]; [email-masked]
Subject: Re: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific
command code issue

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

Hi,

I agree with Mikko. The vendor extensions we are thinking on fully respect the base protocol.

BR/Miguel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: miércoles, 12 de junio de 2002 17:40
To: [email-masked]
Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific
command code issue

Hello,

Vendor-specific extensions to Diameter are not meant to modify a standard.
The intention is that vendor-specific extensions use and support fully
IETF-standard Diameter Base Protocol. The vendor-specific extensions do not
modify anything that is defined in Diameter Base Protocol standard.

The current Base Protocol draft specifies a standard way to make the extensions.
It also defines means that ensure that the communicating entities know what
extensions, if any, are supported at a given time.

As I have understand it, the requirement for the extensibility is also
defined in RFC 2989, Criteria for Evaluating AAA Protocols for Network Access.

I'm a bit afraid that if it is not allowed to standardize how to make
vendor-specific extensions, the vendors will make the extensions in
ad-hoc ways -- causing interoperability problems galore.

Best Regards,
Mikko