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

[<[e-mail]>]

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:[e-mail]] 
Envoyé : mardi 13 mai 2014 16:30
À : MORAND Lionel IMT/OLN; Benoit Claise; [e-mail]
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, [e-mail] 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:[e-mail]]
> *Envoyé :* mardi 13 mai 2014 00:16
> *À :* MORAND Lionel IMT/OLN;
> [e-mail]
> *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
>
>     [e-mail]  <mailto:[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,
> 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
> [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,
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.