Subject: RE: [Dime] Vendor-Specific Commands

From: <[email-masked]>
Date: Wed, 1 Aug 2007 02:26:36 -0500

Hi Mark,

Here is my 2 cents on this.  When this was an issue with the IESG,
the IESG at that time wanted strong change control over Diameter, like
there is with SIP.  There was a concern that some vendor extensions
might
become defacto standards that would negative impact upon interop.

I have heard similar complaints with RADIUS, where small companies must
licence vendor specs from large companies (as a note, I do work for a
large
company with proprietary RADIUS extentions).  This is a real issue for
some parts of RADIUS in certain network deployments.

There is another issue about SDO usage of vendor codes.  For some SDOs,
like
3GPP, it is less of an issue because 3GPP specifications are relatively
easy
to access.  However, for some SDOs, you have to either be a member of
that
SDO to access the specifications or pay money to access those
specifications.
What the IESG had hoped was that SDOs would submit their Diameter
extensions
to the IETF, so that these specifications would be at least available
for anyone
who wanted to implement them.

I would think that the best possible solution for vendor specifc command
code
would be to allocate a range of codes that IANA would freely handout as
long
as there was a specification pubically available.  Ideally this would be
an
information RFC (perhaps even submitted directly to the RFC editor) so
that
there would be documentation on the extension.

John 

>-----Original Message-----
>From: ext Mark Jones [mailto:[email-masked]] 
>Sent: 27 July, 2007 20:15
>To: [email-masked]
>Subject: [Dime] Vendor-Specific Commands
>
>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
>

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

---

From: "David Frascone" <[email-masked]>
Date: Wed, 1 Aug 2007 10:45:10 -0400

The problem here is that companies that want to develop something are just
going to make a vendor specific application, then simply misuse existing
commands.  I'll be willing to wager that this is already happening.

Since we already have vendor-specific applications and vendor-specific
AVP's, I don't see any point in *not* having vendor-specific command codes.

I would probably agree with you, if vendor-specific applications did not
exist.

So, now that people are already doing this, why not let the protocol
actually allow it, instead of having everyone misuse the protocol to get
their tasks done?

-Dave
(Again, the guy, not the chair)

-- 
David Frascone

Know what I hate? I hate rhetorical questions!
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 1 Aug 2007 11:35:48 -0400

> I would think that the best possible solution for vendor 
> specific command code
> would be to allocate a range of codes that IANA would freely 
> handout as long
> as there was a specification publicly available.  

Excellent suggestion, John. This is already being done for Application
Ids and IANA could follow the same reference rules for new command codes
assignments:

- IETF: Reference an RFC.

- Non-IETF SDO: Reference an information RFC (preferred) or SDO spec.

- Non-SDO Vendor: Reference is email of vendor contact person.

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 01 Aug 2007 12:10:48 -0400

Hi Mark,

> - Non-IETF SDO: Reference an information RFC (preferred) or SDO spec.

This is ok.

> - Non-SDO Vendor: Reference is email of vendor contact person.

I'm not sure if we should start distinguishing between non-IETF SDOs and 
vendors. It maybe better if they fall in the same category as the 
'Non-IETF' above. Besides, 'vendor contact person' does not seem helpful 
if we want publicly available specification.

regards,
victor

---

From: Tom Taylor <[email-masked]>
Date: Wed, 01 Aug 2007 12:31:36 -0400

Megaco packages have a public and private numbering space. For private numbers, 
only a package name and contact are needed. Any SDO can request a public space 
number upon production of a specification which is subject to expert review.

Victor Fajardo wrote:
> Hi Mark,
> 
>>> I would think that the best possible solution for vendor specific 
>>> command code
>>> would be to allocate a range of codes that IANA would freely handout 
>>> as long

---

From: <[email-masked]>
Date: Wed, 1 Aug 2007 12:12:07 -0500

Mark,

Unfortunately, the IETF does not recognize the difference between SDOs
and
vendors.  SDOs and Vendors would be in the same class.  I think that
there should
be an stable reference of the spec that can be used for the command code
for
either SDOs and Vendors.  Most likely, vendors could file an
informational 
RFC, if they like.

John 

>Sent: 01 August, 2007 18:36
>To: Loughney John (Nokia-NRC/PaloAlto)
>Cc: [email-masked]
>Subject: RE: [Dime] Vendor-Specific Commands
>
>> command code would be to allocate a range of codes that IANA would 
>> freely handout as long as there was a specification publicly 
>> available.
>
>Excellent suggestion, John. This is already being done for 
>Application Ids and IANA could follow the same reference rules 
>for new command codes
>assignments:
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 1 Aug 2007 11:41:08 -0700

[email-masked] <mailto:[email-masked]> allegedly
scribbled on Wednesday, August 01, 2007 10:12 AM:

> Mark,
> 
> Unfortunately, the IETF does not recognize the difference between
> SDOs and vendors.  SDOs and Vendors would be in the same class.  I
> think that there should be an stable reference of the spec that can
> be used for the command code for either SDOs and Vendors.  

That would probably be desirable, but I don't see why it should be
required.  After all, these are _vendor-specific_ extensions: even in
the case of SDOs, I can't see any real reason why anyone outside the
organization really needs to know how they work.  As for your earlier
comment about vendors having to join SDOs or license proprietary
extensions from other vendors: if you want to play, you have to pay.

> Most likely, vendors could file an informational RFC, if they like.   

Ditto for SDOs.
 
...

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 1 Aug 2007 14:47:23 -0400

> if we want publicly available specification.

I agree that a reference to a publicly available spec SHOULD be included
when requesting a new app/command code. However, tightening the 'SHOULD'
to a 'MUST' would result in IANA refusing to assign an id for apps that
are unpublished because they are company confidential and I think that
is unnecessarily restrictive.

Regards
Mark

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 1 Aug 2007 16:14:15 -0400

Not sure if this is covered.

RFC3855 describes Acct-Multi-Session-Id as UTF8String.

RADIUS defines Acct-Multi-Session-Id as String that SHOULD contain UTF8
String.

Thus this difference can create interoperability issues between RADIUS
and Diameter.

The suggested remedy is to define Acct-MultiSession-Id in the similar
sense as in RADIUS that is as an OctetString.  That should be
sufficient.  However, we could say that it SHOULD contain UTF-8
characters.

Note NASREQ (4005) is silent about this descrepency.

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 2:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Dime] Vendor-Specific Commands

> and vendors.  SDOs and Vendors would be in the same class.  I think 
> that there should be an stable reference of the spec that can be used 
> for the command code for either SDOs and Vendors.

Ditto for SDOs.
 
...

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 01 Aug 2007 18:02:00 -0400

Thanks Avi,

I've added this into the tracker: 
http://www.tschofenig.priv.at:8080/diameter-interop/issue59

-- victor

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Aug 2007 14:33:08 +0200

> From: Mark Jones [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 9:47 PM
> To: Victor Fajardo; [email-masked]
> Cc: [email-masked]
> > I'm not sure if we should start distinguishing between 
> non-IETF SDOs 
> > and vendors. It maybe better if they fall in the same 
> category as the 
> > 'Non-IETF' above. Besides, 'vendor contact person' does not seem 
> > helpful if we want publicly available specification.
> > 
> 
> I agree that a reference to a publicly available spec SHOULD 
> be included when requesting a new app/command code. However, 
> tightening the 'SHOULD'
> to a 'MUST' would result in IANA refusing to assign an id for 
> apps that are unpublished because they are company 
> confidential and I think that is unnecessarily restrictive.
> 
> Regards
> Mark
> 

Yes, but in this case the policy to be used for IANA cannot be labeled
as 'Specification Required', which according to RFC 2434 implies: 

Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.

You need to be clear what to ask from IANA. 

Dan

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 2 Aug 2007 11:19:18 -0400

Dan,

> You need to be clear what to ask from IANA. 

I think we've concluded that "First Come First Served" is the most
appropriate policy for assignment of Vendor-Specific Command Codes. 

In IETF, "Vendor-Specific" does not distinguish between SDO and
equipment vendor. A single IANA assignment policy for these two groups
is not ideal: The "Specification Required" policy is preferable for SDOs
but it simply does not work for proprietary commands.

The "First Come First Served" assignment policy requires "a brief
description of what the value would be used for" [RFC2434]. I suggest
that RFC3588bis clarifies this in the context of Vendor-Specific Command
Codes with the following text in section 11.2.1 (following Glen's
proposed text):

"The request for a Vendor-Specific Command Code SHOULD include a
reference to a publicly available specification which documents the
command in sufficient detail for interoperability between independent
implementations. If the specification is not publicly available, the
request for a Vendor-Specific Command Code MUST include a point of
contact for the proposed command."

The Vendor-Specific Application IDs already assigned by IANA follow
these rules so there should not be any issues with extending them to
Vendor-Specific Command Codes.

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 07 Aug 2007 15:17:50 -0400

Hi,

Mark had proposed a text for rfc3588bis with regards to the rules on 
Vendor-Specific command code allocation. The result would look like:

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 - 8,388,607 (0x100 to 0x7fffff) are for 
   permanent, standard commands, allocated by Expert Review [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 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are 
   reserved for vendor-specific command codes, to be allocated on a 
   First Come, First Served basis by IANA [RFC2434]. The request to 
   IANA for a Vendor-Specific Command Code SHOULD include a reference
   to a publicly available specification which documents the command 
   in sufficient detail to aid in interoperability between independent
   implementations. If the specification cannot be made publicly
   available, the request for a vendor-specific command code MUST
   include the contact information of persons and/or entities responsible
   for authoring and maintaining the command.

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

I would like to poll the WG to see if there are still concerns about 
this proposal or if there are any other comments. It would be great if 
we can get some conclusion regarding this topic.

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 9 Aug 2007 09:35:37 -0400

Hi Victor,

I agree with this text.

Considering also "Application Design Guidelines" document, we probably
will end-up lots of new commands/applications, e.g. any operator which
wants to add a new AVP with M-bit set (pretty much all AVPs) will
require a new command code and this further will require a new
application. OTOH, I still think this is the direction to follow to
guarantee proper routing of messages to endpoints, which actually can
process them.

    Thanks,
    Tolga

> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2007 3:18 PM
> To: Mark Jones
> Cc: [email-masked]
> Subject: [Dime] Re-Visiting Vendor-Specific Commands
> 
> Hi,
>