Re: [Dime] AD review draft-ietf-dime-app-design-guide

Hi Lionel,

No more feedback from the mailing list, please post a new version with 
the text below.

Regards, Benoit
> Hi Benoit,
>
> Would you be happy with the following rewording?
>
> OLD:
>
> 4.4.1. Setting of the AVP Flags
>
>     When reusing AVPs in a new application, the M-bit flag setting MUST
>     be re-evaluated for a new Diameter application and, if necessary,
>     even for every command within the application.  In general, for AVPs
>     defined outside of the Diameter base protocol, the characteristics of
>     an AVP are tied to its role within a given application and the
>     commands used in this application.
>
>     All other AVP flags (V-bit, P-bit, reserved bits) MUST remain
>     unchanged.
>
> NEW:
>
> 4.4.1. Setting of the AVP Flags
>
>     When reusing existing AVPs in a new application, application designers
>     MUST specify the setting of the M-bit flag for a new Diameter application
>     and, if necessary, even for every command within the application.
>     In general, for AVPs defined outside of the Diameter base protocol, the
>     characteristics of an AVP are tied to its role within a given application
>     and the commands used in this application.
>
>     All other AVP flags (V-bit, P-bit, reserved bits) MUST remain
>     unchanged.
>
> -----Message d'origine-----
> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Envoyé : mardi 13 mai 2014 16:30
> À : MORAND Lionel IMT/OLN; Benoit Claise; draft-ietf-dime-app-design-guide.all@tools.ietf.org
> Cc : dime mailing list
> Objet : Re: [Dime] AD review draft-ietf-dime-app-design-guide
>
>
> I think the change Lionel made is a good one. Diameter allows us, even
> if not too much recommended, to change M-bits for existing AVP per
> application. Emphasizing the "sanity check" is a good practise imho.
>
> - Jouni
>
> 5/13/2014 9:27 AM, lionel.morand@orange.com kirjoitti:
>> Hi Benoit,
>>
>> The "MUST" is maybe not required.
>>
>> But this will cause interoperability issues if you just say "re-use AVP
>> 1" without saying exactly how to set the M-bit. Some may decide to set
>> the M-bit as initially defined, others may decide to change it.
>>
>> So the idea was to provide an absolute recommendation for designers and
>> then a MUST/REQUIRED/SHALL for all the AVP flags:
>>
>> - The M-bit flag MUST be re-evaluated
>>
>> - Other AVP flags MUST remain unchanged.
>>
>> If not valid, no problem to revert the change.
>>
>> Regards,
>>
>> Lionel
>>
>> *De :*Benoit Claise [mailto:bclaise@cisco.com]
>> *Envoyé :* mardi 13 mai 2014 00:16
>> *À :* MORAND Lionel IMT/OLN;
>> draft-ietf-dime-app-design-guide.all@tools.ietf.org
>> *Cc :* dime mailing list
>> *Objet :* Re: [Dime] AD review draft-ietf-dime-app-design-guide
>>
>> Hi Lionel,
>>
>> Thanks for the new version 23.
>>
>> One question regarding the attached picture.
>>
>>
>> What does it mean "MUST be re-evaluated" with a RFC 2119 keyword.
>> RFC 2119 keywords are useful for interoperability, and I don't see why
>> it's used here.
>>
>> Regards, Benoit.
>>
>>      Hi Lionel,
>>
>>      Thanks for the new version.
>>      See in line
>>
>>
>>
>>          - 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
>>
>>          */[LM] discussed in another email thread./*
>>
>>
>>          If you go to BCP, don't forget to update the abstract, and the
>>          writeup.
>>
>>      Abstract:
>>
>>          It is meant as a guidelines document and
>>
>>          therefore as informative in nature.
>>
>>
>>
>>      I would remove this sentence. Informative and BCP don't go along very well.
>>
>>
>>
>>      Jouni, don't forget to update the writeup.
>>
>>
>>          - Editorial in section 5.7
>>          OLD:
>>
>>          Destination- Realm
>>
>>
>>
>>          NEW:
>>
>>          Destination-Realm
>>
>>          */  /*
>>
>>      Still there.
>>
>>
>>
>>
>>
>>      - 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.
>>
>>      */[LM] ok/*
>>
>>      Still there.
>>
>>
>>      Regards, Benoit
>>
>>
>>
>>      _______________________________________________
>>
>>      DiME mailing list
>>
>>      DiME@ietf.org  <mailto:DiME@ietf.org>
>>
>>      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,
>> 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.
>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> 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,
> 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.
>
> .
>