Re: [netmod] Rfc8407

On Mon, Feb 19, 2024 at 11:39 PM <mohamed.boucadair@orange.com> wrote:

> Hi all,
>
>
>
> I updated the PR to use a wording aligned with 4.23:
>
>
>
> NEW:
>
>    If the document contains a temporary non-NMDA (Network Management
>
>    Datastore Architecture) [RFC8342], then the Introduction section
>
>    should mention this fact with the reasoning that motivated that
>
>    design.  Refer to Section 4.23 for more NMDA-related guidance.
>
>
>

Does this mean that the Transition to NMDA is completed, and it is now
considered a bad idea
to include a non-NMDA 'state' module?  Most deployments (90%?) are non-NMDA.
The motivation will always be to allow this 90% to retrieve the operational
values of specific configuration data.

Cheers,
>
> Med
>
>
>

Andy

> *De :* Andy Bierman <andy@yumaworks.com>
> *Envoyé :* lundi 19 février 2024 19:58
> *À :* Kent Watsen <kent+ietf@watsen.net>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
>
>
>
>
> On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen <kent+ietf@watsen.net> wrote:
>
> Hi Med,
>
>
>
> On Feb 19, 2024, at 3:29 AM, mohamed.boucadair@orange.com wrote:
>
>
>
> Hi Kent, all,
>
>
>
> I also think that highlighting the exceptions + motivate them makes sense
> here. A PR to fix that can be seen at [1].
>
>
>
> Thank you.
>
>
>
> I hope folks express objections now, before WGLC, as an expeditious
> resolution helps me close off an IESG review comment in NETCONF.
>
>
>
> Guidelines should be specific and clear.
>
> This inverse exception text seems better than the boilerplate text you
> want to replace.
>
>
>
> What exactly does it mean for a YANG module to be non-NMDA-compliant?
>
> Is the guideline forbidding config/state sibling containers, or just those
> that use a grouping or cut-and-paste
>
> to implement its non-NMDA-ness?
>
> Maybe NMDA experts can explain when this exception is needed and what it
> should say.
>
>
>
>
>
>
>
>
>
>
>
> FWIW, the OLD text was added draft-ietf-netmod-rfc6087bis-17 as per a
> comment in the AD review [2].
>
>
>
> That’s a great find!
>
>
>
>
>
> No wonder I didn't remember the WG discussing this during draft-8407.
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> K.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
>
>
>
> *De :* netmod <netmod-bounces@ietf.org> *De la part de* Kent Watsen
> *Envoyé :* vendredi 16 février 2024 21:55
> *À :* Andy Bierman <andy@yumaworks.com>
> *Cc :* netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
> Hi Andy,
>
>
>
> Thanks for the speedy reply.
>
>
>
> This guidance seems inverted, at least within the IETF (where SHOULDs are
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407
> is read.  See the first paragraph of
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
>
>
> I doubt any module would get past the IETF-publication process now if it
> defined a non-NMDA compliant structure (i.e., CF nodes that provide the
> opstate value for CT nodes), unless it was a “temporary non-NMDA module” (
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).
>
>
>
> Since this, for awhile now, is the normal thing to do, the text
> highlighted in my OP seems to have little to no value.  That said, an
> “inverted” statement would have some value, that is, to explicitly
> highlight if the document defines any “temporary non-NMDA modules”.  This
> would be akin to highlighting when a document defines any IANA-maintained
> modules.
>
>
>
> I am proposing to update the text in rfc8407bis accordingly (to invert the
> guidance).  Thoughts?
>
>
>
> If there is agreement to update this text accordingly, I will delete the
> "Adherence to the NMDA” section in all my drafts, since none of them define
> a “temporary non-NMDA module”.
>
>
>
> PS: top-posting for simplicity
>
>
>
> K.
>
>
>
>
>
>
>
> On Feb 16, 2024, at 3:25 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
>
>
>
>
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <kent+ietf@watsen.net> wrote:
>
> NETMOD,
>
>
>
> An IESG member reviewing one of my drafts flagged a section I had written
> to satisfy this text from
> https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
>
>
>
>        If the document contains a YANG module(s) that is compliant with
> NMDA
>
>        [RFC8342], then the Introduction section should mention this fact.
>
>
>
>        Example:
>
>
>
>          The YANG data model in this document conforms to the Network
>
>          Management Datastore Architecture defined in  RFC 8342.
>
>
>
>
>
> What does "compliant with NMDA” actually mean?   Are not all modules
> “compliant”, even if they unnecessarily define some opstate nodes?
>
>
>
>
>
> I do not recall the discussions that led to that text.
>
>
>
> Does this sentence actually point to if the document publishes any so
> called “-state” modules, defined only to support legacy “non-NMDA” servers?
>
>
>
>
>
> I think the state modules are optional, so it is still unclear what NMDA
> conformance means for a YANG module.
>
>
>
>
>
> Does it make sense to clarify this text, since rfc8407bis is an open WG
> document at the moment?
>
>
>
> maybe it means to follow all the guidelines in 4.23.3
>
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
>
>
> maybe remove this other text you cite.
>
>
>
>
>
>
>
> Thanks,
>
> Kent
>
>
>
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> ____________________________________________________________________________________________________________
>
> 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.
>
>
>
> ____________________________________________________________________________________________________________
> 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.
>
>