Re: [netmod] Rfc8407 - what does this text mean?
Hi Andy, We need to be careful here to avoid redundant guidance. For example, the guidance you are suggesting is already covered in 4.23. It even includes guidance for motivating exceptions: Designers SHOULD describe and justify any NMDA exceptions in detail, such as the use of separate subtrees and/or separate leafs. The "description" statements for both the configuration and the operational state SHOULD be used for this purpose. The proposed narrative text is about highlighting when a temporary non-NMDA is **included in the spec**; to echo this part from 4.23.3, bullet a: A temporary non-NMDA version of this type of module MAY exist, as either an existing model or a model created by hand or with suitable tools that mirror the current modeling strategies. Both the NMDA and the non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in a non-normative appendix. The use of the non-NMDA module will allow temporary bridging of the time period until NMDA implementations are available. That’s said, if you have a NDMA-related text proposal of you think is worth highlighting in the narrative text, please share it. Thanks. Cheers, Med De : Andy Bierman Envoyé : vendredi 23 février 2024 02:25 À : BOUCADAIR Mohamed INNOV/NET Cc : Kent Watsen ; netmod@ietf.org Objet : Re: [netmod] Rfc8407 - what does this text mean? 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 on would be useful. If not, then the foo-state module is not even relevant. Andy 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
Re: [netmod] Rfc8407 - what does this text mean?
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 on would be useful. If not, then the foo-state module is not even relevant. Andy On Tue, Feb 20, 2024 at 10:34 PM wrote: > Hi Andy, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Andy Bierman > *Envoyé :* mardi 20 février 2024 18:19 > *À :* BOUCADAIR Mohamed INNOV/NET > *Cc :* Kent Watsen ; netmod@ietf.org > *Objet :* Re: [netmod] Rfc8407 - what does this text mean? > > > > > > > > On Mon, Feb 19, 2024 at 11:39 PM 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 > *Envoyé :* lundi 19 février 2024 19:58 > *À :* Kent Watsen > *Cc :* BOUCADAIR Mohamed INNOV/NET ; > netmod@ietf.org > *Objet :* Re: [netmod] Rfc8407 - what does this text mean? > > > > > > > > On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen 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_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 *De la part de* Kent Watsen > *Envoyé :* vendredi 16 février 2024 21:55 > *À :* Andy Bierman > *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
[netmod] Adoption call for draft-ma-netmod-immutable-flag-09
NETMOD WG, This email begins a 2-week adoption poll for: YANG Metadata Annotation for Immutable Flag https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09 There is no known IPR on this draft: https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/ Please voice your support or technical objections to adoption on the list by the end of the day Mar 7 (any time zone). PS: This draft was discussed in our recent Interim, where a show-of-hands hands showed unanimous support for adoption. Thank you, Kent (as co-chair) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IPR poll for draft-ma-netmod-immutable-flag-09
Thank you authors and contributors for your responses. No IPR is being declared at this time. Kent (and Lou) > On Feb 12, 2024, at 5:50 PM, Kent Watsen wrote: > > Authors, Contributors, WG, > > As a prerequisite for the adoption on this document: > > YANG Metadata Annotation for Immutable Flag > https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09 > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft” > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules” > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. > > Also please send the response to the list above, and not unicast it. > > FWIW, currently, no IPR is filed for this draft: > https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ma-netmod-immutable-flag > > Thanks. > Kent (and Lou) > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
