Subject: [Dime] Vendor-Specific Commands

From: "Mark Jones" <[email-masked]>
Date: Fri, 27 Jul 2007 13:14:41 -0400

The Diameter command header originally contained a Vendor Id to allow
vendor-specific commands. If I remember correctly, it was removed
following IESG review due to interop concerns. However, the command
mangling that is occurring now due to the lack of vendor-specific
commands is complicating command routing and will lead to interop
issues.

The least invasive way to bring back vendor-specific commands is to
sub-divide the Command code namespace (as was done for Application Id)
to allow a vendor-specific range that is allocated by IANA on a 'First
Come First Served' basis. We should take the opportunity to address this
in 3588bis.

Vendor-specific applications are allocated by IANA on a 'First Come
First Served' basis. Vendor-specific AVPs just require a vendor id (also
'First Come First Served'). The 'IETF Consensus' policy for new Command
codes is so incongruous that it looks like a 'bug' in RFC3588 to me. I
suspect this restrictive policy was originally just intended for IETF
commands and we should also fix this in 3588bis.

Regards
Mark

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "David Frascone" <[email-masked]>
Date: Fri, 27 Jul 2007 15:29:28 -0400

I do think that leaving out vendor specific command codes was a
mistake.  And, I think asking for any kind of command code 'request',
when the vendor-specific application has already been requested, is a
huge waste of time.

Given this, I'm for allocating a range of codes to be considered
vendor specific, and not regulated beyond that.  That way, in a vendor
specific aplication, vendors don't have unnecessary waiting when
developing custom applications.

Just my $0.02 worth,

-Dave
(Dave the guy, not Dave the WG Chair)

-- 
David Frascone

Oxymoron: Safe Sex.

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Sat, 28 Jul 2007 08:37:42 +0200

Any signalling protocol should support the possibility of private
extensions.
Just due to intra-vendor deployment scenarios, etc.
However, the "vendor role" must be specified, it could be a e.g.
manufacturer or an operator, but it shouldn't be any other
standardization development organization (SDO) besides IETF.
Non-IETF SDO's with own vendor-IDs will create interop issues in my
opinion.
Another issue is the development of similar protocol functionality
(syntax/semantic) under different vendor-ID name spaces.
The IETF is the owner of the Diameter. Any strict control of technology
extensions is a prerequisite for minimization of interop issues,
protocol redundancy and semantical unclearness.
 
Thus, could imagine that a stricter policy concerning vendor-ID usage
might be a compromise.

________________________________

	From: David Frascone [mailto:[email-masked]] 
	Sent: Freitag, 27. Juli 2007 21:29
	To: Mark Jones
	Cc: [email-masked]
	Subject: Re: [Dime] Vendor-Specific Commands

	I do think that leaving out vendor specific command codes was a
	mistake.  And, I think asking for any kind of command code
'request', 
	when the vendor-specific application has already been requested,
is a
	huge waste of time.
	
	Given this, I'm for allocating a range of codes to be considered
	vendor specific, and not regulated beyond that.  That way, in a
vendor 
	specific aplication, vendors don't have unnecessary waiting when
	developing custom applications.
	
	Just my $0.02 worth,
	
	-Dave

	
	On 7/27/07, Mark Jones <[email-masked]>
wrote: 

		The Diameter command header originally contained a
Vendor Id to allow
		vendor-specific commands. If I remember correctly, it
was removed
		following IESG review due to interop concerns. However,
the command
		mangling that is occurring now due to the lack of
vendor-specific 
		commands is complicating command routing and will lead
to interop
		issues.
		
		The least invasive way to bring back vendor-specific
commands is to
		sub-divide the Command code namespace (as was done for
Application Id) 
		to allow a vendor-specific range that is allocated by
IANA on a 'First
		Come First Served' basis. We should take the opportunity
to address this
		in 3588bis.
		
		Vendor-specific applications are allocated by IANA on a
'First Come 
		First Served' basis. Vendor-specific AVPs just require a
vendor id (also
		'First Come First Served'). The 'IETF Consensus' policy
for new Command
		codes is so incongruous that it looks like a 'bug' in
RFC3588 to me. I 
		suspect this restrictive policy was originally just
intended for IETF
		commands and we should also fix this in 3588bis.
		
		Regards
		Mark

	-- 
	David Frascone 
	
	Oxymoron: Safe Sex.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 29 Jul 2007 09:26:04 -0700

Any signalling protocol should support the possibility of private
extensions.
Just due to intra-vendor deployment scenarios, etc.
However, the "vendor role" must be specified, it could be a e.g.
manufacturer or an operator, but it shouldn't be any other
standardization development organization (SDO) besides IETF.
Non-IETF SDO's with own vendor-IDs will create interop issues in my
opinion. 
Why?  What specific issues?  Don't exactly know how you can say that,
given the fact that DSLF, 3GPP & 3GPP2 (at least) have & use their own
vendor IDs; further, the fact that there are already many, many
SDO-specific RADIUS attribute that hasn't seemed to have harmed RADIUS
interoperability and finally, there are already vendor (which may be
SDOs) specific applications and AVPs in Diameter -- in essence,
everything needed to build an application except a vendor-specific
command code . 
Another issue is the development of similar protocol functionality
(syntax/semantic) under different vendor-ID name spaces.
The IETF is the owner of the Diameter.  
That is extremely questionable.
Any strict control of technology extensions is a prerequisite for
minimization of interop issues, protocol redundancy and semantical
unclearness.
Unfortunately, this hasn't proven to be the case thus far; what has
happened is that seriously broken protocols have been published under
the IETF imprimatur.  That doesn't really help the IETF;  it does allow
the sponsoring SDO to claim no responsibility, though, because the IETF
"approved" it.
Thus, could imagine that a stricter policy concerning vendor-ID usage
might be a compromise.
 
....

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 29 Jul 2007 14:20:41 -0700

Given this, I'm for allocating a range of codes to be considered
vendor specific, and not regulated beyond that.  That way, in a vendor
specific application, vendors don't have unnecessary waiting when
developing custom applications.

I agree.  Let me offer this text:

11.2.1.  Command Codes

   The Command Code namespace is used to identify Diameter commands.
The values 0-255  (0x00-0xff) are reserved for
   RADIUS backward compatibility, and are defined as "RADIUS Packet Type
Codes" in [RADTYPE].  Values 256 - 16,777,213
   (0x100 - 0xfffffd) are for permanent, standard commands, allocated by
IETF Consensus [RFC2434].  This document defines
   the Command Codes 257, 258, 271, 274-275, 280 and 282.  See Section
3.1 for the assignment of the namespace in this
   specification.

   The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
0xffffff) are reserved for experimental commands.
   As these codes are only for experimental and testing purposes, no
guarantee is made for interoperability between
   Diameter peers using experimental commands, as outlined in
[IANA-EXP].

   The values 16,777,216 - 4,294,967,295 (0x1000000 - 0xffffffff) are
reserved for vendor-specific command codes, to be
   allocated on a First Come, First Served basis by IANA [RFC2434].

...

---

From: Rajith R <[email-masked]>
Date: Mon, 30 Jul 2007 14:29:45 +0530

>   The values 16,777,216 - 4,294,967,295 (0x1000000 - 
>0xffffffff) are reserved for vendor-specific command codes, to be

But command code is only 3 bytes ...

>-----Original Message-----
>From: Glen Zorn (gwz) [mailto:[email-masked]] 
>Sent: Monday, July 30, 2007 2:51 AM
>To: David Frascone; Mark Jones
>Cc: [email-masked]
>Subject: RE: [Dime] Vendor-Specific Commands
>
>I do think that leaving out vendor specific command codes was 
>a mistake.  And, I think asking for any kind of command code 
>'request', when the vendor-specific application has already 
>been requested, is a huge waste of time.
>
>Given this, I'm for allocating a range of codes to be 
>considered vendor specific, and not regulated beyond that.  
>That way, in a vendor specific application, vendors don't have 
>unnecessary waiting when developing custom applications.
>
>   RADIUS backward compatibility, and are defined as "RADIUS 
>Packet Type Codes" in [RADTYPE].  Values 256 - 16,777,213
>   (0x100 - 0xfffffd) are for permanent, standard commands, 
>allocated by IETF Consensus [RFC2434].  This document defines
>   As these codes are only for experimental and testing 
>purposes, no guarantee is made for interoperability between
>   The values 16,777,216 - 4,294,967,295 (0x1000000 - 
>0xffffffff) are reserved for vendor-specific command codes, to be

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 30 Jul 2007 08:46:50 -0400

Thanks for the proposal. I am in favor of allocating a vendor-specific 
command as well though I'm waiting to hear legitimate concerns before 
closing the issue.

>    allocated on a First Come, First Served basis by IANA [RFC2434].

Some adjustments to the proposed vendor-specific command space: range 
can be between  8,388,607 - 16,777,213 (7fffff - 0xfffffd) . Half the 
command space should be sufficient unless some folks have reasonable 
objections.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 30 Jul 2007 08:58:00 -0400

Hi,

> The IETF is the owner of the Diameter. Any strict control of 
> technology extensions is a prerequisite for minimization of interop 
> issues, protocol redundancy and semantical unclearness.

This strict control strategy is not helpful since other SDO's will find 
ways to circumvent these rules when they are not convenient. This 
resulted in some bad design choices and from experience, it is what's 
causing "real" interop issues.

-- victor

---

From: Tom Taylor <[email-masked]>
Date: Mon, 30 Jul 2007 09:07:40 -0400

Just a bit of history here. The IESG originally wanted to keep fairly tight 
control of the protocol architecture because Diameter was being promoted as the 
vehicle for all sorts of applications, not just AAA. As an example, in 1998 a 
group of us convened by Level 3 used it as the basis for IPDC, a forerunner to 
MGCP and Megaco/H.248.

It is quite possible that the IESG would take a more relaxed view of the 
situation now that Diameter's role is more clearly established.

...

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 30 Jul 2007 09:00:27 -0700

Victor Fajardo <mailto:[email-masked]> allegedly scribbled on
Monday, July 30, 2007 5:47 AM:

> Thanks for the proposal. I am in favor of allocating a
> vendor-specific command as well though I'm waiting to hear legitimate
> concerns before closing the issue.  
> 
> can be between  8,388,607 - 16,777,213 (7fffff - 0xfffffd) . 

Okee-dokee.

> Half the command space should be sufficient 

I would expect so.

>unless some folks have reasonable objections.   
> 
> regards,
> victor