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
>