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

[Hannes Tschofenig <[e-mail]>]

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