Re: [Dime] Diameter Guidelines as BCP?

Benoit Claise <bclaise@cisco.com> Mon, 14 April 2014 13:08 UTC

Return-Path: <bclaise@cisco.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 0A7071A01D4 for <dime@ietfa.amsl.com>; Mon, 14 Apr 2014 06:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.772
X-Spam-Level:
X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ss5bLo6DmXFB for <dime@ietfa.amsl.com>; Mon, 14 Apr 2014 06:08:05 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id B79C91A048A for <dime@ietf.org>; Mon, 14 Apr 2014 06:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45661; q=dns/txt; s=iport; t=1397480878; x=1398690478; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0E19PwezjpRv8T4ExedCODZHYKw3slVNT5k8BK2DYKY=; b=gVT3wHzP5pOGWaq/8nI7JiOuiyzbonyI6MqNRfBC4Cv1XOqLaoqH1E8u ep2R3vT/Gi8sdES1cCtOifRhpMcdBICkeSoCUxDb4/YDvVa4WkXN5AkJh s/Xu/4A+vN1nCZerzqFFtE0D/YA5exWyaP+gv8c6HrVR3qRVslhAjEprZ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArAEAAXdS1OtJssW/2dsb2JhbABZgkJ/iUS6M4E1dIImAQEEGhM6BwoBEAshFgEBBgcJAwIBAgE0EQYBDAEFAgEBEIdoDcscF4lGhDsJAhEBUAYBhDgBA4VhkwCBNoUei2+DMzuBLAkX
X-IronPort-AV: E=Sophos; i="4.97,857,1389744000"; d="scan'208,217"; a="17276170"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Apr 2014 13:07:56 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3ED7t2H023825; Mon, 14 Apr 2014 13:07:55 GMT
Message-ID: <534BDDAB.1030603@cisco.com>
Date: Mon, 14 Apr 2014 15:07:55 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" <draft-ietf-dime-app-design-guide@tools.ietf.org>
References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <24395_1396893521_5342E751_24395_4614_1_6B7134B31289DC4FAF731D844122B36E54AE2F@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <24395_1396893521_5342E751_24395_4614_1_6B7134B31289DC4FAF731D844122B36E54AE2F@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------030601020808000105010309"
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sk7QiPzvJkAOQ3BCX5wSoSoinUU
Cc: dime mailing list <dime@ietf.org>
Subject: Re: [Dime] Diameter Guidelines as BCP?
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, 14 Apr 2014 13:08:11 -0000

Hi Lionel,

No feedback after a week. I think it's time to apply this change.

Regards, Benoit
>
> 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 anew Diameter application.
>   
>        Typical examples would be the creation of anew 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.