Re: [netmod] Rfc8407 - what does this text mean?

[[e-mail]]

Hi Andy,

Please see inline.

Cheers,
Med

De : Andy Bierman <[e-mail]>
Envoyé : mardi 20 février 2024 18:19
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Kent Watsen <[e-mail]>; [e-mail]
Objet : Re: [netmod] Rfc8407 - what does this text mean?



On Mon, Feb 19, 2024 at 11:39 PM <[e-mail]<mailto:[e-mail]>> 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?
[Med] We don’t actually change the core NMDA guidance (hence the pointer to 4.23). All we do here is, given the SHOULD NMDA-compliant reco in 4.23 and the practice adopted for published modules since then, we encourage highlighting exceptions (MAY temporary thing in 4.23) in the Introduction rather than the SHOULD.

  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 <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 19 février 2024 19:58
À : Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : Re: [netmod] Rfc8407 - what does this text mean?



On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Med,

On Feb 19, 2024, at 3:29 AM, [e-mail]<mailto:[e-mail]> 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 <[e-mail]<mailto:[e-mail]>> De la part de Kent Watsen
Envoyé : vendredi 16 février 2024 21:55
À : Andy Bierman <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:



On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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.
____________________________________________________________________________________________________________
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.