On Mon, Feb 19, 2024 at 11:39 PM <mohamed.boucad...@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 <a...@yumaworks.com> > *Envoyé :* lundi 19 février 2024 19:58 > *À :* Kent Watsen <kent+i...@watsen.net> > *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@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+i...@watsen.net> wrote: > > Hi Med, > > > > On Feb 19, 2024, at 3:29 AM, mohamed.boucad...@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-boun...@ietf.org> *De la part de* Kent Watsen > *Envoyé :* vendredi 16 février 2024 21:55 > *À :* Andy Bierman <a...@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 <a...@yumaworks.com> wrote: > > > > > > > > On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <kent+i...@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. > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
