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. > 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! > Cheers, > Med K. > > [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 <mailto:netmod-boun...@ietf.org>> De la > part de Kent Watsen > Envoyé : vendredi 16 février 2024 21:55 > À : Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>> > Cc : netmod@ietf.org <mailto: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 > <mailto:a...@yumaworks.com>> wrote: > > > > On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <kent+i...@watsen.net > <mailto:kent%2bi...@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 <mailto: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.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
