Subject: [Dime] Registering new Command Codes with IANA based on "Expert Review"

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Jun 2007 23:35:49 +0200

Hi all,

RFC 3588 describes that "IETF Consensus" is needed when registering a 
new Command Code with IANA. That's fine if you develop a specification 
in the IETF.
It is, however, challenging when another SDOs extend Diameter but don't 
want todo this within the IETF itself. What they then do is to avoid 
creating a command code (and applications in general) but re-using 
existing applications, such as Diameter NASREQ, and adding 
vendor-specific AVPs. As one might guess the consequence is a hack. This 
can lead to interoperability problems.

Now, in a chat between Dan, Victor and myself we thought about ways how 
to change the current situation. We would like to have other SDOs to 
extend Diameter in such a way that it does not cause interoperability 
problems. One way is to improve the current situation is to change the 
policy for registering Command Codes from "IETF Consensus" to "Expert 
Review" (as part of the work on 
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt). 
This would obviously require that we setup a expert review team in order 
to actually handle the incoming review requests.

What do people think about the suggested change?

Ciao
Hannes

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 13 Jun 2007 17:43:30 -0400

I think it really would be useful to prevent people hacking existing
commands.

It may be also considered to signal that a command code is not from IANA
assigned name space with a new AVP (whose values are controlled by IANA,
and is assigned per organization). The absence of this AVP would mean
that the command code is from IANA name space. Organizations would be
able to assign new command codes the way they want in their own name
space. This would be similar to the Vendor-Id field in an AVP. Just a
thought ....

  Thanks,
  Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2007 5:36 PM
> To: [email-masked]
> Subject: [Dime] Registering new Command Codes with IANA based on
> "ExpertReview"
> 
> Hi all,
>

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 14 Jun 2007 03:47:06 -0400

Hannes,

I agree with your assessment of the SDO situation and that we need to
revisit the assignment rules.

Why are vendor-specific application ids assigned on a 'First Come First
Served' basis whereas new vendor-specific commands within that
application require 'IETF Consensus'?

Why not subdivide the Command Code namespace (like the application id)
to allow a vendor-specific range that is also allocated by IANA on a
'First Come First Served' basis?

Thanks
Mark

> Sent: June 14, 2007 04:36
> To: [email-masked]
> Subject: [Dime] Registering new Command Codes with IANA based 
> on "ExpertReview"
> 
> Hi all,
>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 14 Jun 2007 10:11:16 +0200

Hi Mark, 

It is somewhat strange that the application ids and the command codes
have a different policy. 
I would, however, like to have a model where some Diameter experts could
do a brief (e.g., 2 weeks time) review of the suggested extension to
check whether the chosen design approach is not violating the Diameter
extensibility concept. 
This review would be based on Diameter extensiblity and not on the
actual content of the extension. 

Ciao
Hannes

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 14 Jun 2007 06:42:39 -0400

Hannes, 

The inconsistency in the assignment rules may be the result of the
removal of some vendor-specific features late in the Diameter base
protocol design. Once upon a time, the Diameter header contained a
vendor id to allow a vendor-specific namespace for commands. I suspect
the 'IETF Consensus' rule was originally intended just for the IETF
commands.

I have concerns about the effectiveness of the 'Expert Review' given the
limited success in getting other SDOs to submit to 'IETF Consensus' for
new commands. The DIME group may find it can achieve the same
interoperability goals by giving the SDOs (and vendors) the tools they
need to police their own specifications. The Diameter Applications
Design Guidelines draft is an key deliverable in this regard. Once this
draft is complete, SDOs creating Diameter applications can
encourage/require their working groups to review their specifications
against it for compliance.

If the Expert Review is the preferred route of this group, we should
recognize the importance of effective socialization with the other SDOs
to ensure they appreciate its value and understand where it fits in
their specification process.

Regards
Mark

> From: Tschofenig, Hannes [mailto:[email-masked]] 
> Sent: June 14, 2007 15:11
> To: Mark Jones; Hannes Tschofenig
> Cc: [email-masked]
> Subject: AW: [Dime] Registering new Command Codes with IANA 
> based on"ExpertReview"
> 
> Hi Mark, 
>

---

From: "Arun Santhanam, TLS-Chennai" <[email-masked]>
Date: Fri, 15 Jun 2007 18:05:39 +0530

Hi All,
	I think this is a good idea the Expert Team can review the
request for Creation/Modification of the Command code as per the 
http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.
txt Doc. This will also ensures the effective re-usability of the
Command codes. 

Thx
-Arun

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, June 14, 2007 3:06 AM
To: [email-masked]
Subject: [Dime] Registering new Command Codes with IANA based on
"ExpertReview"

Hi all,

Ciao
Hannes

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Jun 2007 11:14:45 +0200

Hi Mark

> the 'IETF Consensus' rule was originally intended just for the IETF
That might be true. Let us ask, for example,  John & Jari  what the 
original intention  was.

> against it for compliance.
The document will hopeful give some help to people extending Diameter.

> their specification process.
We will do our best.

Ciao
Hannes

>>> I agree with your assessment of the SDO situation and that 
>>>       
>> we need to
>>     
>>> Why not subdivide the Command Code namespace (like the 
>>>       
>> application id)
>>     
>>>> RFC 3588 describes that "IETF Consensus" is needed when 
>>>>         
>>> registering a 
>>>       
>>>> want todo this within the IETF itself. What they then do is 
>>>>         
>>> to avoid 
>>>       
>>>> creating a command code (and applications in general) but 
>>>>         
>> re-using 
>>     
>>>> to change the current situation. We would like to have 
>>>>         
>>> other SDOs to 
>>>       
>>>> extend Diameter in such a way that it does not cause 
>>>>         
>>> interoperability 
>>>       
>>>> policy for registering Command Codes from "IETF Consensus" 
>>>>         
>>> to "Expert 
>>>