[Dime] Diameter Guidelines as BCP? (was: AD review draft-ietf-dime-app-design-guide)

<lionel.morand@orange.com> Mon, 07 April 2014 17:58 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186421A0161 for <dime@ietfa.amsl.com>; Mon, 7 Apr 2014 10:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqrhUVXxDU6B for <dime@ietfa.amsl.com>; Mon, 7 Apr 2014 10:58:49 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9C1A04AF for <dime@ietf.org>; Mon, 7 Apr 2014 10:58:48 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A2DE526417A; Mon, 7 Apr 2014 19:58:41 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8996F27C1B3; Mon, 7 Apr 2014 19:58:41 +0200 (CEST)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 7 Apr 2014 19:58:41 +0200
From: lionel.morand@orange.com
To: Benoit Claise <bclaise@cisco.com>, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" <draft-ietf-dime-app-design-guide@tools.ietf.org>
Thread-Topic: Diameter Guidelines as BCP? (was: AD review draft-ietf-dime-app-design-guide)
Thread-Index: AQHPTlKK04bn8aLKgkqsyndd0aygjpsGeLuQ
Date: Mon, 07 Apr 2014 17:58:40 +0000
Message-ID: <24395_1396893521_5342E751_24395_4614_1_6B7134B31289DC4FAF731D844122B36E54AE2F@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com>
In-Reply-To: <533BD276.7000401@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E54AE2FPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.7.63014
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/o-HExvNc70RWX9zy3yYp5chF1NU
Cc: dime mailing list <dime@ietf.org>
Subject: [Dime] Diameter Guidelines as BCP? (was: AD review draft-ietf-dime-app-design-guide)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 17:58:54 -0000

Hi Benoit,

Defining this document as BCP makes sense.
Any other feedback from the working group before modifying the objective of this document?

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise
Envoyé : mercredi 2 avril 2014 11:04
À : draft-ietf-dime-app-design-guide.all@tools.ietf.org
Cc : dime mailing list
Objet : [Dime] AD review draft-ietf-dime-app-design-guide

Dear authors,

Sorry for dropping the ball on this one.
If any of the points was already discussed/addressed by the WG, feel free to let me know.


- When I read the document, it looked to me as a BCP.
BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs



   The BCP subseries of the RFC series is designed to be a way to

   standardize practices and the results of community deliberations.
Interestingly, the charter mentions:
May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document

If you go to BCP, don't forget to update the abstract, and the writeup.
Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013)
Example:
OLD:

Diameter

protocol designers are then strongly advised to carefully consider
NEW:

   Diameter

   protocol designers SHOULD NOT consider


OLD:

   Instead of using

   an Enumerated AVP for a Boolean flag, protocol designers are again

   encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which

   the data field would be defined as

NEW:

   Instead of using

   an Enumerated AVP for a Boolean flag, protocol designers SHOULD

   use AVPs of type Unsigned32 or Unsigned64 AVP in which

   the data field would be defined as
Finally, with a BCP, RFC 6733 could be a normative reference, which I believe it should.


- Editorial
Please don't use "we" in RFCs

-
Section 3

  Major Extension:  Enhancing an application that requires the

      definition of a new Diameter application.



      Typical examples would be the creation of a new command for

      providing functionality not supported by existing applications or

      the definition of a new AVP with the M-bit set to be carried in an

      existing command.  For such extension, a significant specification

      effort is required and a careful approach is recommended.
Do you want to mention that Major Extension have backward compatibility issue, as opposed to the minor one?

- Editorial

      Typical examples would be the creation of a new command for

      providing functionality not supported by existing applications or

      the definition of a new AVP with the M-bit set to be carried in an

      existing command.  For such extension, a significant specification

      effort is required and a careful approach is recommended.
NEW:

      Typical examples would be the creation of a new command for

      providing functionality not supported by existing applications or

      the definition of a new mandatory AVP set to be carried in an

      existing command.  For such extension, a significant specification

      effort is required and a careful approach is recommended.
Justification:

        * Minor extension speaks about "optional"

        * The M-bit is explained in 4.3.1



- Section 3
I see Minor Extension versus Major Extension, and I tried to match the following classifications to Minor or Major

   1.  Addition of new functionality to an existing Diameter application

       without defining a new application.



   2.  Addition of new functionality to an existing Diameter application

       that requires the definition of a new application.



   3.  The definition of an entirely new Diameter application to offer

       functionality not supported by existing applications.



   4.  The definition of a new generic functionality that can be reused

       across different applications.
2 and 3 are Major
For 1, I thought about Minor, but the following sentence "or the definition of a new AVP with the M-bit set to be carried in an existing command." in the Major paragraph confuses me.
I guess that 4 is Major, but it's not mentioned.
Can you please better explain the mapping between the 4 categories and Minor/Major extensions
Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Minor/Major extensions would be beneficial.

- Section 3
I don't understand what your message is with:

   We would also like to remind that the definition of a new Diameter

   application and the definition of a new command should be something

   to avoid as much as possible.  In the past, there has been some

   reluctance to define new commands and new applications.  With the

   modified extensibility rules provided by [RFC6733<http://tools.ietf.org/html/rfc6733>], registering new

   commands and new applications does not lead to additional overhead

   for the specification author in terms of standardization process.

   Registering new functionality (new commands, new AVPs, new

   applications, etc.) with IANA remains important to avoid namespace

   collisions, which will likely lead to deployment problems.
"should be something to avoid as much as possible", is this valid today?
Because the next sentence speaks about the past, then the next sentence seems like it's fixed now with 6733.

- Editorial:

   With the

   modified extensibility rules provided by [RFC6733<http://tools.ietf.org/html/rfc6733>], registering new

   commands and new applications does not lead to additional overhead

   for the specification author in terms of standardization process.

   Registering new functionality (new commands, new AVPs, new

   applications, etc.)
"etc.": What does it refer to? new AVP value is the only one I can think of.
Worth removing "etc." and specifying the full list?


- Application and command

   Major Extension:  Enhancing an application that requires the

      definition of a new Diameter application.



      Typical examples would be the creation of a new command for

      providing functionality not supported by existing applications or

      the definition of a new AVP with the M-bit set to be carried in an

      existing command.  For such extension, a significant specification

      effort is required and a careful approach is recommended.

4.1<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-21#section-4.1>.  Adding a New Command

   Adding a new command is considered as a major extension and requires

   a new Diameter application to be defined.
I'm not clear on the application/command boundary.
Why do we need a new application for a new command?
Why can't I add a command to an existing application?
There are commands that are for all applications/independent of the application, no?
    CER/CEA (Capabilities-Exchange-Request)
This contradicts:

   Before adding or importing a command, application designers

   should consider the following ...



This also appears to contradict, in section 6

   Generic Diameter extensions are AVPs, commands or applications that

   are designed to support other Diameter applications.


My issue comes from the fact that there are no "application" and "command" definitions.
Draft says:
2<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-21#section-2>.  Terminology

   This document reuses the terminology defined in [RFC6733]<http://tools.ietf.org/html/rfc6733>
However, RFC 6733 terminology doesn't contain the application and command definitions.
Talking to Jouni, I now understand that a command is always specified within the context of an application.
This should be clarified.

Also, from section 5.2:

   As a general recommendation, commands should not be defined from

   scratch.  It is instead recommend to re-use an existing command

   offering similar functionality and use it as a starting point.
Based on my latest understanding (a command is always specified within the context of an application), the only justification for the above text is code reuse, right. Please mention it.

- Editorial

   Adding a new command is considered as a major extension and requires

   a new Diameter application to be defined.  Adding a new command to an

   application means ...
A new command addition is always to an application, right?
If yes, why do you make the distinction between the sentences above

- Application version?

An exception might be if the

   intent of the deletion is to create a newer version of the same

   application that is somehow simpler than the previous version.
        ...

   o  Would the new AVP be used to differentiate between old and new

      versions of the same application whereby the two versions are not

      backward compatible?
Readers might be understanding that diameter applications having a version field.
This is not the case. Please rephrase.
Also, mention that a new version of an application is a new application.
I guess it needs to be mentioned in 7.d


- Section 4.3.2
For the reader convenience, I would mention the convention behind { AVP } and [ AVP ], or at least give a reference.

- Section 5.3
OLD:

   Some existing

   specifications do not adhere to this rule for historical reasons.

   However, this guidance should be followed to avoid routing problems.



NEW:

   Some existing

   specifications do not adhere to this rule for historical reasons.

   However, this guidance should be followed for new applications to avoid routing problems.

In the same section, why "In general" in the next sentence? It contradicts with "must use"

In general, when a new application has been allocated with a new

   Application Id and it also reuses existing commands with or without

   modifications, it must use the newly allocated Application Id in the

   header and in all relevant Application Id AVPs (Auth-Application-Id

   or Acct-Application-Id) present in the commands message body.

- Editorial, section 5.5

OLD:

   Based on these considerations, protocol designers should carefully

   appraise whether the application currently defined relies on it's own

   session management concept or whether



NEW:

   Based on these considerations, protocol designers should carefully

   appraise whether the application currently defined relies on its own

   session management concept or whether

- Editorial in section 5.7
OLD:

Destination- Realm



NEW:

Destination-Realm


- The section 5.8 should mention RFC4005bis

- Section 5.9

 Applications that do not understand these AVPs can discard

   them upon receipt.
Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference.
This document is not an extension/deviation to RFC 6733.

- Do you have a good reason to add a reference to a work-in-progress that didn't progress since 2001?

   [I-D.calhoun-diameter-res-mgmt]

              Calhoun, P., "Diameter Resource Management Extensions",

              draft-calhoun-diameter-res-mgmt-08.txt<http://tools.ietf.org/html/draft-calhoun-diameter-res-mgmt-08.txt> (work in progress),

              March 2001.

- Editorial (section 6)
I can't parse the following sentence:

 Backward Compatibility:



      With the design of generic extensions an protocol designer has to

      consider with potential concerns about how existing applications

      deal with the new extension they do not understand.

- Contributors:
If Victor and Hannes are authors, then they shouldn't be in the contributors list.
Btw, I don't see an affiliation for Victor in the document header. I believe the common practice is to write down "consultant"

Did the WG ever considered the following questions:
- Any naming convention for new applications?
- When it is not a good idea to define diameter applications? Let me make something up: to push syslog message

Regards, Benoit









_________________________________________________________________________________________________________________________

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.