Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt

[<[e-mail]>]

Hi Hannes,

Based on your input, I propose to add a specific section with the content given below. It may be a little bit redundant with some information already given in RFC6733 but I agree that it is worth to repeat the guidelines.
Please comment.

Best Regards,

Lionel

************************
7.  Guidelines for Registrations of Diameter Values

   As summarized in the Section 3 of this document and further described
   in the Section 1.3 of [RFC6733], there are four main ways to extend
   Diameter.  The process for defining new functionality slightly varies
   based on the different extensions.  This section provides protocol
   designers with some guidance regarding the definition and
   registration of values for possible Diameter extensions.

   a. Defining new AVP values

      The specifications defining AVPs and AVP values provide guidance
      for defining new values and the corresponding policy for adding
      these values.  For example, the [RFC5777] defines the Treatment-
      Action AVP which contains a list of valid values corresponding to
      pre-defined actions (drop, shape, mark, permit).  This set of
      values can be extended following the Specification Required policy
      defined in [RFC5226].  As a second example, the Diameter base
      specification [RFC6733] defines the Result-Code AVP that contains
      a 32-bit address space used to identity possible errors.
      According to the Section 11.3.2 of [RFC6733], new values can be
      assigned by IANA via an IETF Review process [RFC5226].

   b. Creating new AVPs

      Two different types of AVP Codes namespaces can be used to create
      a new AVPs:

      *  IETF AVP Codes namespace;

      *  Vendor-specific AVP Codes namespace.

      In the latter case, a vendor needs to be first assigned by IANA
      with a private enterprise number, which can be used within the
      Vendor-Id field of the vendor-specific AVP.  This enterprise
      number delimits a private namespace in which the vendor is
      responsible for vendor-specific AVP code value assignment.  The
      absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP
      header identifies standard AVPs from the IETF AVP Codes namespace
      managed by IANA.  The allocation of code values from the IANA-
      managed namespace is conditioned by an Expert Review of the
      specification defining the AVPs or an IETF review if a block of
      AVPs needs to be assigned.  Moreover, the remaining bits of the
      AVP Flags field of the AVP header can be also assigned via
      Standard Action if the creation of new AVP Flags is desired.

   c. Creating new commands

      Unlike the AVP Code namespace, the Command Code namespace is flat
      but the range of values is subdivided into three chunks with
      distinct IANA registration policies:

      *  A range of standard Command Code values that can be allocated
         via IETF review;

      *  A range of vendor-specific Command Code values that can be
         allocated on a First-Come/First-Served basis;

      *  A range of 2 values reserved only for experimental and testing
         purposes.

      As for AVP Flags, the remaining bits of the Command Flags field of
      the Diameter header can also be assigned via a Standards Action to
      create new Command Flags if required.

   d. Creating new applications

      Similarly to the Command Code namespace, the Application-Id
      namespace is flat but divided into two distinct ranges:

      *  A range of values reserved for standard Application-Ids
         allocated after Expert Review of the specification defining the
         standard application;

      *  A range for values for vendor specific applications, allocated
         by IANA on a First-Come/First-Serve basis.

   The IANA AAA parameters page can be found at http://www.iana.org/
   assignments/aaa-parameters/aaa-parameters.xml and the enterprise
   number IANA page is available at http://www.iana.org/assignments/
   enterprise-numbers.  More details on the policies followed by IANA
   for namespace management (e.g. First-Come/First-Served, Expert
   Review, IETF Review, etc.) can be found in [RFC5226].

   NOTE:
      When the same functionality/extension is used by more than one
      vendor, it is recommended to define a standard extension.
      Moreover, the registration of vendor-specific extension is
      encouraged to avoid interoperability issues in the same network.
      With this aim, the registration policy of vendor-specific
      extension has been simplified with the publication of [RFC6733]
      and the namespace reserved for vendor-specific extensions is large
      enough to avoid exhaustion.

************************

-----Message d'origine-----
De : Hannes Tschofenig [mailto:[e-mail]] 
Envoyé : mardi 11 juin 2013 13:48
À : MORAND Lionel OLNC/OLN
Cc : Hannes Tschofenig; [e-mail]
Objet : Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes, I can give it a try to see whether the group thinks it is worthwhile to add this additional piece of information. 

On a high level this is what I plan to say:

- --------

There are four main ways to extend Diameter and the process for defining new functionality slightly varies based on the different extensions: 
 
   1.  Defining new AVP values: The specifications that define the AVP and the AVP values provide guidance for defining new values and also provide the policy for adding these values. For example, RFC 5777 defines AVPs for traffic classification and QoS. Among the AVP it defines the Treatment-Action AVP, which contains a list of actions (drop, shape, mark, permit). New values can be defined by following the policy outlined in Section 10.3 of RFC 5777. As a second example, the Diameter base specification defines a number of AVPs. The Result-Code AVP is one of them and, according to Section 11.3.2 of RFC 6733, new values are available for assignment via IETF Review.

   2.  Creating new AVPs: New AVPs can be defined in one of two ways: (a) as vendor-specific AVPs and (b) within the IETF AVP codespace. In case (a) a vendor needs to obtain an enterprise number (which is then carried inside the Vendor-ID field of the AVP) through IANA. When a vendor-specific AVP is used then the vendor has to manage it's AVP code space internally. The absence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AVP Codes namespace, which is under IANA control. The policy for registering AVPs under the IANA controlled namespace is described in Section 11.1.1 of RFC 6733. 

Associated with AVPs are AVP flags, which requires Standards Action for extensions [RFC5226]. 

   3.  Creating new commands: Unlike the AVP code space the command code space is flat but the number range is divided into different chunks for different purposes and with different registration policies. There are three number ranges, namely a range for command codes allocated via IETF review, a number range for vendor-specific command codes with a First-Come, First-Serve policy, and a number range reserved for experimental and testing purposes. 

Associated with commands is the Command Flags field, which requires Standards Action for extensions. 

   4.  Creating new applications: Similarly to the command code space the application id space is flat but divided into two number ranges, namely one for for vendor
   specific applications, on a First-Come, First-Serve basis, and another one space with a Specification Required policy. 

The IANA AAA parameters page can be found at http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml and the enterprise number IANA page is available at http://www.iana.org/assignments/enterprise-numbers

Note: Register your extensions to avoid interoperability problems which can occur when two implementations using the same code point but with different semantic are run in the same network. The registration policy has been simplified with the publication of RFC 6733 and the number space is large enough to avoid exhaustion. 

- --------

Ciao
Hannes

On Jun 11, 2013, at 1:52 PM, <[e-mail]> wrote:

> Hi Hannes,
>  
> OK in the principle. Could you provide a short text that I could insert in the draft? It should not be too long.
>  
> Lionel
>  
> De : Hannes Tschofenig [mailto:[e-mail]] 
> Envoyé : mardi 11 juin 2013 12:48
> À : MORAND Lionel OLNC/OLN
> Cc : [e-mail]
> Objet : Aw: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>  
> Hi Lionel, 
>  
> thanks for the response.
>  
> Switching back to "the Diameter base protocol" is good for me. We should try to avoid creating additional work for the RFC Editor. I will change it. 
>  
> Version -18 is good for me. I was onlywondering whether it would make sense to add a short section about what steps to take when defining new extensions (in terms of interacting with IANA, for example). 
>  
> Ciao
> Hannes
>  
>  
> Gesendet: Donnerstag, 06. Juni 2013 um 21:09 Uhr
> Von: [e-mail]
> An: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Betreff: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
> Hi,
> 
> The version covers the changes proposed by the detailed review done by Hannes (thank you!).
> Most of them are OK and taken into account in this new version... except one:
> 
> In the RFC 6733, the correct wording used is "the Diameter base protocol" and not "Diameter Base Protocol". I have received the same comment in the recent past! :)
>  
>  
> 
> Hannes, please confirm that this version is OK. If it is, the WGLC on this document is finished and we can move forward.
>  
>  
> Ciao
> Hannes
> 
> 
> Regards,
> 
> Lionel
> 
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
> Envoyé : jeudi 6 juin 2013 21:03
> À : [e-mail]
> Cc : [e-mail]
> Objet : [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.
> 
> Title : Diameter Applications Design Guidelines
> Author(s) : Lionel Morand
> Victor Fajardo
> Hannes Tschofenig
> Filename : draft-ietf-dime-app-design-guide-18.txt
> Pages : 21
> Date : 2013-06-06
> 
> Abstract:
> The Diameter base protocol provides facilities for protocol
> extensibility enabling to define new Diameter applications or modify
> existing applications. This document is a companion document to the
> Diameter Base protocol that further explains and clarifies the rules
> to extend Diameter. It is meant as a guidelines document and
> therefore as informative in nature.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-18
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJRtw6LAAoJEGhJURNOOiAteI8H/33XsWes4eZKapGZVNOpW+p2
5PJDwJr3rcshajT4HzCRraD2Z07zn2JRAhG3rMdpwOpGjt9eOxsIgLcBPjS2N9rm
vIH1QSssekt3O9z4pO++GdFeczclnlzYkQE68R2Jhvo9lOVFv3MuW+N3ryoUGBmn
NLk5bvP5IHdrxM8TNeT0xK1bLtB7tFkthyrfIIlfN2GeD0eKDqGbp4QY1x3Q4zCY
u12b9AwVOOT09lJ/jS4EueT9yaiaUkB4siqpQdlmWUVZU1Dhn2j0D1xBsiq7OMJR
1TkaU+4DgiT9xe0vQDwUckoahW643wrkgY6jeP5oYhloMfzPr5m3/HXWkUWlgd4=
=DCtz
-----END PGP SIGNATURE-----

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.