Re: [netmod] Rfc8407

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.

> 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-bounces@ietf.org <mailto:netmod-bounces@ietf.org>> De la part de Kent Watsen
> Envoyé : vendredi 16 février 2024 21:55
> À : Andy Bierman <andy@yumaworks.com <mailto:andy@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 <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>  
>  
>  
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <kent+ietf@watsen.net <mailto:kent%2Bietf@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.