Hi, I don't think the issue is whether a foo-state module is included in the RFC or not. There is an algorithm to produce the foo-state module for vendors to use.
IMO the NMDA guideline should indicate "need NMDA", and be present if it is believed that the operational state can be different than the config. In that case a <get-data> on <operational> would be useful. If not, then the foo-state module is not even relevant. Andy On Tue, Feb 20, 2024 at 10:34 PM <[email protected]> wrote: > Hi Andy, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Andy Bierman <[email protected]> > *Envoyé :* mardi 20 février 2024 18:19 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > *Cc :* Kent Watsen <[email protected]>; [email protected] > *Objet :* Re: [netmod] Rfc8407 - what does this text mean? > > > > > > > > On Mon, Feb 19, 2024 at 11:39 PM <[email protected]> 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 <[email protected]> > *Envoyé :* lundi 19 février 2024 19:58 > *À :* Kent Watsen <[email protected]> > *Cc :* BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > *Objet :* Re: [netmod] Rfc8407 - what does this text mean? > > > > > > > > On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen <[email protected]> wrote: > > Hi Med, > > > > On Feb 19, 2024, at 3:29 AM, [email protected] 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 <[email protected]> *De la part de* Kent Watsen > *Envoyé :* vendredi 16 février 2024 21:55 > *À :* Andy Bierman <[email protected]> > *Cc :* [email protected] > *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 <[email protected]> wrote: > > > > > > > > On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <[email protected]> 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 > [email protected] > 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. > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
