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

[<[e-mail]>]

Thank you!

I will incorporate the proposed text in a new version of the draft, including your minor comments.

Regards,

Lionel

-----Message d'origine-----
De : Hannes Tschofenig [mailto:[e-mail]] 
Envoyé : mercredi 26 juin 2013 09:27
À : 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

Hi Lionel, 

this looks like a good writeup. 

A few minor remarks below: 

On Jun 19, 2013, at 2:27 PM, <[e-mail]> wrote:

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

maybe add "... and the necessary interaction with IANA to register the new functionality.". 

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

Minor bug: "For example, RFC 5777 [RFC5777]  defines ... 

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

This should rather say " A range of 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.
> 
> ************************
> 

Ciao
Hannes

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

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

iQEcBAEBCgAGBQJRype/AAoJEGhJURNOOiAthTMH/3WayLZ2+6O8emrPRmcfuTIX
C5ObqhhUJ3Af4mM6pil7ApFrVy4wGya/AG6iofeLJb2wDd0eeuR1kBKshOhJHuiu
got8AkT4UvoOjI1d/U6nl0a1ZpXbeeal8Bf9oACMFwviSlu9AdjT+d+zF1moW5YI
v8/ujDgcTzi2TNY9z+1EhF5BB2gtHqNkAM8HYHf4uCluyTjdQyl51HCgQBk2DBaq
FMb9bf/IT5oQLof9AP4AFxojODRi6Cu/wUe3e0e/OpSY4QxHnXOKcetaN6ElE9To
7XfYj1zfUOqcAjwhdTJKOyj1aml08P9yQlC0vckEVemBCyOzsj2HjlHjdml6M8s=
=Gk0N
-----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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.