Return-Path: X-Original-To: netmod@mail2.ietf.org Delivered-To: netmod@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5E47D5087A45 for ; Wed, 6 Aug 2025 05:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joX6kxxqKzn3 for ; Wed, 6 Aug 2025 05:29:01 -0700 (PDT) Received: from sonic.asd.mail.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 571D75087A39 for ; Wed, 6 Aug 2025 05:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1754483341; bh=IHuWECvIQ63skqNXEjcNInFyw0xu6b2XtYZmH/VU4Ic=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=X1Zm1n4kuRuc9uQ7QXjD7aU5i4Vmyrv0THt9mR1klFX3miuoXGqYFIwypXVp45Be6l3LQl3sVNm3ROTBJRLwGKKeZNeDzF3hG0TWfbcLVFOW/P/7OBKrQuxEa2hEJaGBuZsynw+AHlDroMsjOjFPztxZ9a+4hexpfEWnXWywMAf1QBNEePUrYIQ4qo7hOhVGhP/3Ups3gcNXyME3rMhp/fqQpSgjv8itR2CKG9X1GOP1/0OcNxE1NUC+zVATQDMo2VuNwe5RqaRrDg7FHO87KFYHWxaWfAqvUhG5aguz1ZVPLGXvSSKat5iGD6to6tfRGOidVssoRf1XHzdwxMy4Fg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1754483341; bh=qLfv7fYWoK4aiCA3SMtNqjgXklCHmaIF2vNtxb9T9TM=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=fYJuRFMvLdJayHv70NnaJAxJ5siOZsF42/I1OeAbZjzcwvMvUWKM3Qgj8iMDwV0C52tayWgda7JO6uJ/R7LqFaPO1eQFdBjYT93L8tVe2pffx9Mortp+iQccjnSf8UDZVAB96dE+wAuS56wdeVsxwqfMV9zkK0Gy5KxkcCURzRQDxGSs+PHkYYYfuPJoR5Xqf+FQZXQh2zfSJXYXKOM3mLY3FMHbSqtxVhiMMubCCRzB2yz+MOZUlfewkrAIz/OjgDfTeF2o13keduqWwvr17cW1mnWsloOYaBM704BOVy7Ejppxw7jAAlMkgF77Ueb547aeUVS6+Oo0t3cZ0I2w8A== X-YMail-OSG: 1QWzIVwVM1ly.dvtCmlMQeZiMIgUzVFSxXagpeLHOv9m0yVS.coNaMkO8Xihlpe 7K_4tPuenHb3jdN8jbmez5TMgdZIBURO8_iq5HB.Nhla3Trm_0LdbPyNg4qP335mBGyNQnPYmrp6 NxZg.k8Qxwno6B6yjQx3YT85nPSWaSOoRdqF8YARmv.A4iSeUwERvKw5YdB._ZLtEZqIPVxxgO0w d4Tl2_VZHY8ZawotVfSuoNk_F.Koqt4N9yb8S8xKGie_KD_xga.LTCpHLojUn_6JcxqojRAZuhgd cnPPBU1rUIpplAGl9Ytbxn.P2lPsS98xgTsmWRbQ8UzhgkigAr0zgAmM.UvSsV9oR2aE7FqzLItI FF5rPWFQ6bCahH46aBElqh2JOI0C2bt9I7rG0fMBOuT28qkHiT3b_Vtz8M3N2NWqmWU0lS.qzOoU SipESYxaQzzfzDNa6jWSCFOBPJQFmhCaejhytYl.naa8rXRnjiNDfG3Rup6RL6U9WFSAs1gUsHIJ 7HcS7MrQfQZW1BVuS8MKWwsRkhN32AxXakVbwBlW0X0iGqmxdx2qTnm5RvwPV5sgAGWxGWGaxl6E vFuvY.WiN3uzRUgS6FHpdqtiMEB3P6qAPh9Dljq81C4w_3VYLjM5PZK9NnddYX5v3Aw7NZYDwR70 O0w3FRprD10IJaIKh32C5cF.ExNlXv8ZJF7mU5a76dD.MWOfB_zyJbTxQSAaROhIIuGXxKtVQBAP XRDdp6z2Se7uFeZMsSBjAOaxbdiF5iEzoiroCBWout4cgA0LkBUdo6MYgRK_Hlpo8cvypO.XIOLM b9n18PYCQg4rZ6FrML0.wtQM88dJ0JOCvc.rwn.gcemUvIFJ0SMhJImmC.1aca61B659dSFuIr8z GQgemElg5TXBVTL_5NUbJrn3.gcCBzOp0ombGpuhE650xTe4._zo01jgiwl5nwbSlAZVDxmDHHBf l7X.nZ.eBrNjofGs0YrO74BBqxaKp1CnIOiTJ91itIL6YssLSi74zA0zPyFLMIzC9cP9un89z7q6 iJZExKg4eDLDNRV6RsDAPm.i4FoEWgAVsPIFFVlG6vX5OHi1wi_mPkBqiUQHUCFv2dyNYI.n7.6y mDFbhAV.qVsayW5lif5_Pjb0yeTQgpYaWE_tAl6H9Lzv_kmbF5bqYW3PG5Rv7rEHFBHYWM0xhiMO MZGVHqJ.U8DpaT1isFupEIDz_gY5gENRBUmhAKuj1jmYTRU8R0VFsdoYaiabO5p09eAxbpJ.Fm1Y E3rj_m4FoCTeM0vIl7u2IxrWg3UZeF4QNlKSqwQYPRorKTA3bnulvwIb_W_0SI8ru2nOiFRI3P0X 7eNjK9H9tU47paJsYgSKf05ocJtn5ieaAuwpm5w_8TpAN_Mmf5ZVSY6pi3OpgBVox_xME6J_2CG. kIkfLQIZjh4Az0ZxQ2XpfhwSk_gZzGCVH959414NbqJfy1FgMFB0jam8SWdCSg50yQLpO5KRgPlE 4ET3..3pkxx6YT2joHnT_xyVOIidZ0VJjOx8ufUdU81k_ccsTHyd38_LNWiBrswLLjRF21tEfzNy 7nnbV_t4.cNN7flMh7tsWfKREnzWqbZkz.yuLD1HfHn5O25iHJ7ZLwcRXLBfRi7beRV7R7y67B4l uPgIjJ8x21Ps5zD2JeC1_nEucABKb8vTWkQ_ebv6roKrxx8YNzUpJhKbWJIoLU63ztViNravOZiT zdqQSuI_z3rg8ofzc6ieoE1WjA6ZGllQYE0t0zTwKHJCn.r5ek29OIwVOtqJSwVnwd3BHV_Fm1s9 1f6pIV_glCNYqUvTQrxWLQ9HniRBh2.sXe8LPStoW61Agmms71POaVch4XD7J5d3.QE6iDDMhwO2 R8tPnSnl2fhjRFqMlTJUcDz6kStm_xoZIaywgU8CEgJKysnarg.l8TaXxz8rHTO9wSzfMHu0WWRN 6SASiyrE_8jKAHnruO3kylfNJAJ8S5zb_rHV9v4ThScMO9wDsmiOE3t6sAi3uipA6qe3c9M0GbIf 1Jcr65jw7ZG.V_dKJwTnvJAgfEEKkYCwJ441H2GqrACBh0tdW5YBNbWeHNcWnTLVwFmMM1K2H5it Q61y1mEwP3ZGpXoD8seM1EPeS33cPNmp6_J1bm6Z1qW6Dg.a4_3OMfU7HEGJOfUcHCbGQkXgmxoR MZVhwrutqq9sg_GvE2BI5bOijilin8htP_.DS2RGOWRJ_EHZi7tvreucbFVx6EIsik9i6.ovAJqS JF0Sypzt67PKET1gQp5k42eMLyYknIAKKTGt5Sbtptr1Ribx_Vj3iTPC5HFgp X-Sonic-MF: X-Sonic-ID: 632818fa-ed1f-46ac-ba48-aa5f003c02ea Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 Aug 2025 12:29:01 +0000 Date: Wed, 6 Aug 2025 12:29:00 +0000 (UTC) From: Reshad Rahman To: "draft-ietf-netmod-yang-module-versioning.all@ietf.org" , Mahesh Jethanandani Message-ID: <474383958.1354379.1754483340580@mail.yahoo.com> In-Reply-To: <6EF13DEC-7227-4955-97D2-CC452D095B02@gmail.com> References: <6EF13DEC-7227-4955-97D2-CC452D095B02@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1354378_1358238528.1754483340576" X-Mailer: WebService/1.1.24260 YMailNorrin Message-ID-Hash: O5IERZVT6W34NH3PSC4WZGD672U74K7X X-Message-ID-Hash: O5IERZVT6W34NH3PSC4WZGD672U74K7X X-MailFrom: reshad@yahoo.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: NetMod WG X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: Reshad Rahman Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_AD_review_of_draft-ietf-netmod-yang-module-vers?= =?utf-8?q?ioning-13_=28Document_1_of_3=29=2E?= List-Id: NETMOD WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_1354378_1358238528.1754483340576 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mahesh, Thank you for the review. We (the authors) will get back to you soon on you= r comments. Regards,Reshad. On Tuesday, August 5, 2025 at 05:46:29 PM EDT, Mahesh Jethanandani wrote: =20 =20 =EF=BB=BFHi Authors, Thanks for working on this document. It has taken a lot to get here. While = this review is particularly for this draft, the two other related drafts, d= raft-ietf-netmod-yang-semver and draft-ietf-netmod-yang-module-filename, wi= ll be progressed along with this draft as a single cluster. Please find enclosed some comments that hopefully go towards improving the = document. Overall Comment: This is a comment more for Shepherd writers. The fact that a document conta= ins a YANG module does not mean its intended status is Proposed Standard by= default. Some recent documents are publishing YANG modules in other tracks= , such as Experimental. Separately, Juergen provided comments on all three related drafts. I saw re= sponses to draft-ietf-netmod-semver (by Joe, thanks for that), and to draft= -ietf-netmod-yang-module-filename (by Per, thanks for that). But I did not = see anyone respond to comments for draft-ietf-netmod-yang-module-versioning= . Can one of the authors respond to his comments? "Abstract", paragraph 0> =C2=A0 =C2=A0This document refines the RFC 7950 mo= dule update rules. =C2=A0It specifies> =C2=A0 =C2=A0a new YANG module updat= e procedure that can document when non-> =C2=A0 =C2=A0backwards-compatible = changes have occurred during the evolution of a> =C2=A0 =C2=A0YANG module. = =C2=A0It extends the YANG import statement with a minimum> =C2=A0 =C2=A0rev= ision suggestion to help document inter-module dependencies. =C2=A0It> =C2= =A0 =C2=A0provides guidelines for managing the lifecycle of YANG modules an= d> =C2=A0 =C2=A0individual schema nodes. =C2=A0This document updates RFC 79= 50, RFC 6020,> =C2=A0 =C2=A0RFC 8407 and RFC 8525. The document states it is updating RFC 8407. However, it also touches on th= e same set of updates that rfc8407bis touches upon in its Section 4.8. How = do the changes described in this document jive with the changes in rfc8407b= is? Can specific sections in rfc8407bis that are being updated be called ou= t, or state what is being updated? Section 1, paragraph 0> =C2=A0 =C2=A0The current YANG [RFC7950] module upda= te rules require that updates> =C2=A0 =C2=A0of YANG modules preserve strict= backwards compatibility. =C2=A0This causes> =C2=A0 =C2=A0problems as descr= ibed in [I-D.ietf-netmod-yang-versioning-reqs].> =C2=A0 =C2=A0This document= recognizes the need to sometimes allow YANG modules to> =C2=A0 =C2=A0evolv= e with non-backwards-compatible changes, which can cause> =C2=A0 =C2=A0brea= kage to clients and when importing YANG modules. =C2=A0Accepting that> =C2= =A0 =C2=A0non-backwards-compatible changes do sometimes occur -- e.g., for>= =C2=A0 =C2=A0bugfixes -- it is important to have mechanisms to report when= these> =C2=A0 =C2=A0changes occur, and to manage their effect on clients a= nd the broader> =C2=A0 =C2=A0YANG ecosystem. I know this comment is not in particular for this document, but since the r= equirements document is mentioned here, what is the plan for draft-ietf-net= mod-yang-versioning-reqs? Is the plan to keep it as a =E2=80=9Clive=E2=80= =9D document, with no plan to publish it? If this document is not able to a= ddress all the requirements documented there, can those unfulfilled require= ments be identified? Section 1.1, paragraph 0> =C2=A0 =C2=A0This document updates [RFC7950] sect= ion 11 and [RFC6020] section 10.> =C2=A0 =C2=A0Section 3 describes modifica= tions to YANG revision handling and> =C2=A0 =C2=A0update rules, and Section= 4.1 describes a YANG extension statement to> =C2=A0 =C2=A0describe potenti= al YANG import revision dependencies. RFC7950 states that extension statements can be ignored. If the YANG Semver= statement were to be ignored, particularly the recommended-min-date, what = would be the effect on the import of the module? Can we have some text that= describes that scenario? Section 4, paragraph 1> =C2=A0 =C2=A0[RFC7950] and [RFC6020] allow YANG mod= ule "import" statements to> =C2=A0 =C2=A0optionally require the imported mo= dule to have a specific revision> =C2=A0 =C2=A0date. =C2=A0In practice, imp= orting a module with an exact revision date> =C2=A0 =C2=A0can be too restri= ctive because it requires the importing module to be> =C2=A0 =C2=A0updated = whenever any change to the imported module occurs, and hence> =C2=A0 =C2=A0= section Section 6.1 suggests that authors do not restrict YANG module> =C2= =A0 =C2=A0imports to exact revision dates. I do not understand this paragraph. First of all, isn't "optionally require" an oxymoron? Did you mean to say t= hat YANG modules can optionally import modules with a specific revision dat= e? Secondly, isn't the whole idea of importing a module with a revision date t= o make sure the imported module is "frozen in time"? RFC 7950 is Section 5.= 1.1, says for imported modules using revision statements that "As future re= visions of the imported module are published, the importing module is unaff= ected". Therefore, saying that "importing module to be updated whenever any= changes to the imported module occurs" is not a true statement. Section 4.1, paragraph 1> =C2=A0 =C2=A0Although the previous section indica= tes that the actual relationship> =C2=A0 =C2=A0constraints between differen= t revisions of YANG modules should be> =C2=A0 =C2=A0specified outside of th= e modules, in some scenarios YANG modules are> =C2=A0 =C2=A0designed to be = loosely coupled, and implementors may wish to select> =C2=A0 =C2=A0sets of = YANG module revisions that are expected to work together.> =C2=A0 =C2=A0For= these cases it can be helpful for a module author to provide> =C2=A0 =C2= =A0guidance on a recommended minimum revision that is expected to> =C2=A0 = =C2=A0satisfy a YANG import. =C2=A0E.g., the module author may know of a> = =C2=A0 =C2=A0dependency on a type or grouping that has been introduced in a= > =C2=A0 =C2=A0particular imported YANG module revision. =C2=A0Although the= re can be no> =C2=A0 =C2=A0guarantee that all derived future revisions from= the particular> =C2=A0 =C2=A0imported module will necessarily also be comp= atible, older revisions> =C2=A0 =C2=A0of the particular imported module may= not be compatible. RFC 7950 in Section 5.1.1 says that when a module is imported without a spe= cific version, it is undefined which revision is used. Given that, specifyi= ng an exact version helps. But if implementations always import the latest = version, does specifying the minimum version help? I feel that we are not p= roviding a complete context here. Section 6, paragraph 0> =C2=A0 =C2=A0The following text updates section 4.7= of [RFC8407] to revise the> =C2=A0 =C2=A0guidelines for updating YANG modu= les. Should the reference be updated to rfc8407bis? Section 6.1.1, paragraph 1> =C2=A0 =C2=A01. =C2=A0The changes should be mad= e gradually, e.g., a data node's status> =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD = NOT be changed directly from "current" to "obsolete" (see> =C2=A0 =C2=A0 = =C2=A0 =C2=A0Section 4.7 of [RFC8407]), instead the status SHOULD first be>= =C2=A0 =C2=A0 =C2=A0 =C2=A0marked "deprecated". =C2=A0At some point in the= future, when support> =C2=A0 =C2=A0 =C2=A0 =C2=A0is removed for the data n= ode, there are two options. =C2=A0The first,> =C2=A0 =C2=A0 =C2=A0 =C2=A0an= d preferred, option is to keep the data node definition in the> =C2=A0 =C2= =A0 =C2=A0 =C2=A0model and change the status to =E2=80=9Cobsolete=E2=80=9D.= The second option is> =C2=A0 =C2=A0 =C2=A0 =C2=A0to simply remove the data= node from the model, but this has the> =C2=A0 =C2=A0 =C2=A0 =C2=A0risk of = breaking modules which import the modified module, and> =C2=A0 =C2=A0 =C2= =A0 =C2=A0the removed identifier may be accidentally reused in a future> = =C2=A0 =C2=A0 =C2=A0 =C2=A0revision. Should the reference to RFC8407 be updated to point to rfc8407bis? Section 8.2, paragraph 0> =C2=A0 =C2=A0The YANG module specified in this do= cument defines a schema for data> =C2=A0 =C2=A0that is designed to be acces= sed via network management protocols such> =C2=A0 =C2=A0as NETCONF [RFC6241= ] or RESTCONF [RFC8040]. =C2=A0The lowest NETCONF layer> =C2=A0 =C2=A0is th= e secure transport layer, and the mandatory-to-implement secure> =C2=A0 =C2= =A0transport is Secure Shell (SSH) [RFC6242]. =C2=A0The lowest RESTCONF lay= er> =C2=A0 =C2=A0is HTTPS, and the mandatory-to-implement secure transport = is TLS> =C2=A0 =C2=A0[RFC8446]. Please update to reflect the latest version of the template defined in rfc8= 407bis. No reference entries found for these items, which were mentioned in the tex= t:[draft-ietf-netmod-rfc6991-bis]. I think you meant [I-D.ietf-netmod-rfc69= 91-bis]. ---------------------------------------------------------------------------= ----NIT--------------------------------------------------------------------= ----------- All comments below are about very minor potential issues that you may choos= e toaddress in some way - or ignore - as you see fit. Some were flagged bya= utomated tools (via https://github.com/larseggert/ietf-reviewtool), so ther= ewill likely be some false positives. There is no need to let me know what = youdid with these suggestions. Section 3.1.1, paragraph 3> =C2=A0 =C2=A0* =C2=A0YANG schema nodes with a "= status" "obsolete" substatement MAY be> =C2=A0 =C2=A0 =C2=A0 removed from p= ublished modules, and the removal is classified as a> =C2=A0 =C2=A0 =C2=A0 = backwards-compatible change. =C2=A0In some circumstances it may be> =C2=A0 = =C2=A0 =C2=A0 helpful to retain the obsolete definitions since their identi= fiers> =C2=A0 =C2=A0 =C2=A0 may still be referenced by other modules and to= ensure that their> =C2=A0 =C2=A0 =C2=A0 identifiers are not reused with a = different meaning. s/may be helpful/MAY be helpful/? Section 3.2, paragraph 0> 3.2. =C2=A0non-backwards-compatible extension sta= tement s/non-backwards-compatible/Non-backwards-compatible/ Section 7, paragraph 8> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Copyright (c) 2024 IETF= Trust and the persons identified as> =C2=A0 =C2=A0 =C2=A0 =C2=A0 authors o= f the code. =C2=A0All rights reserved. s/2024/2025/ Section 7, paragraph 27> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Copyright (c) 2024 IET= F Trust and the persons identified as> =C2=A0 =C2=A0 =C2=A0 =C2=A0 authors = of the code. =C2=A0All rights reserved. s/2024/2025/ Uncited references: [I-D.ietf-netmod-rfc6991-bis]. This will be fixed once = you change the reference above. "Table of Contents", paragraph 1> =C2=A0. . . . . . 31 B.2. Changing the ty= pe of a leaf node . . . . . . . . . . . .> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^^^^^^^^If "type" is a classification term, "a" is not neces= sary. Use "type of". (Thephrases "kind of" and "sort of" are informal if th= ey mean "to some extent".). Section 3, paragraph 2> f revision B, or if revision A would have been list= ed had it not been removed> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^= ^^^^^^Did you mean "had been"? Section 3, paragraph 12> introduces a method to indicate that an non-backwa= rds-compatible (NBC) chang> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^^Use "a" instead of "an" if the following word doesn't start = with a vowel sound,e.g. "a sentence", "a university". Section 3.1, paragraph 14> marking the "status" as "obsolete" is a NBC chan= ge, however removing the node> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ^Use "an" instead of "a" if the following word starts wit= h a vowel sound, e.g."an article", "an hour". Section 3.1.2, paragraph 1> ence of entries from the end (i.e., oldest entr= ies) of the revision history.=C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^^^^^A determiner may be missing. Section 4.1.1.2, paragraph 1> n Handling February 2025 any nodes has change= d to "deprecated" and whether th> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0^^^You should probably use "have". Section 10.1, paragraph 20> =C2=A0the old node is already set (and vice-ver= sa). The new node could have a "whe> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^^^^^^^^^^The expression "vice versa" is spelled without hyphens. Section 10.2, paragraph 19> old list already has entries (and vice-versa). = 4. When list "sessions" is no> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ^^^^^^^^^^The expression "vice versa" is spelled without hyphens. Section 10.2, paragraph 25> =C2=A0the old node is already set (and vice-ver= sa). The new node could have a "whe> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^^^^^^^^^^The expression "vice versa" is spelled without hyphens. Thanks Mahesh Jethanandanimjethanandani@gmail.com _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-leave@ietf.org =20 ------=_Part_1354378_1358238528.1754483340576 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

Thank you for the review. We (the authors) will get back to you soon on yo= ur comments.

Regards,
Reshad.

=20
=20
On Tuesday, August 5, 2025 at 05:46:29 PM EDT, Mahe= sh Jethanandani <mjethanandani@gmail.com> wrote:


=20 =20
=EF=BB=BF
Hi Authors,

Th= anks for working on this document. It has taken a lot to get here. While th= is review is particularly for this draft, the two other related drafts, dra= ft-ietf-netmod-yang-semver and draft-ietf-netmod-yang-module-filename, will= be progressed along with this draft as a single cluster.

Please find enclosed some comments that hopefully go towards improv= ing the document.

Overall Comment:

<= /div>
This is a comment more for Shepherd writers. The fact that a docu= ment contains a YANG module does not mean its intended status is Proposed S= tandard by default. Some recent documents are publishing YANG modules in ot= her tracks, such as Experimental.

Separately, Juer= gen provided comments on all three related drafts. I saw responses to draft= -ietf-netmod-semver (by Joe, thanks for that), and to draft-ietf-netmod-yan= g-module-filename (by Per, thanks for that). But I did not see anyone respo= nd to comments for draft-ietf-netmod-yang-module-versioning. Can one of the= authors respond to his comments?

"Abstract", para= graph 0
>    This document refines the RFC 7950 modu= le update rules.  It specifies
>    a new YANG = module update procedure that can document when non-
>   &= nbsp;backwards-compatible changes have occurred during the evolution of a
>    YANG module.  It extends the YANG import st= atement with a minimum
>    revision suggestion to h= elp document inter-module dependencies.  It
>   &nbs= p;provides guidelines for managing the lifecycle of YANG modules and
<= div>>    individual schema nodes.  This document updates = RFC 7950, RFC 6020,
>    RFC 8407 and RFC 8525.

The document states it is updating RFC 8407. However, = it also touches on the same set of updates that rfc8407bis touches upon in = its Section 4.8. How do the changes described in this document jive with th= e changes in rfc8407bis? Can specific sections in rfc8407bis that are being= updated be called out, or state what is being updated?

Section 1, paragraph 0
>    The current YANG [= RFC7950] module update rules require that updates
>   &nb= sp;of YANG modules preserve strict backwards compatibility.  This caus= es
>    problems as described in [I-D.ietf-netmod-ya= ng-versioning-reqs].
>    This document recognizes t= he need to sometimes allow YANG modules to
>    evol= ve with non-backwards-compatible changes, which can cause
> &n= bsp;  breakage to clients and when importing YANG modules.  Accep= ting that
>    non-backwards-compatible changes do s= ometimes occur -- e.g., for
>    bugfixes -- it is i= mportant to have mechanisms to report when these
>   &nbs= p;changes occur, and to manage their effect on clients and the broader
>    YANG ecosystem.

I know thi= s comment is not in particular for this document, but since the requirement= s document is mentioned here, what is the plan for draft-ietf-netmod-yang-v= ersioning-reqs? Is the plan to keep it as a =E2=80=9Clive=E2=80=9D document= , with no plan to publish it? If this document is not able to address all t= he requirements documented there, can those unfulfilled requirements be ide= ntified?

Section 1.1, paragraph 0
> &= nbsp;  This document updates [RFC7950] section 11 and [RFC6020] sectio= n 10.
>    Section 3 describes modifications to YANG= revision handling and
>    update rules, and Sectio= n 4.1 describes a YANG extension statement to
>    d= escribe potential YANG import revision dependencies.

RFC7950 states that extension statements can be ignored. If the YANG Sem= ver statement were to be ignored, particularly the recommended-min-date, wh= at would be the effect on the import of the module? Can we have some text t= hat describes that scenario?

Section 4, paragraph = 1
>    [RFC7950] and [RFC6020] allow YANG module "im= port" statements to
>    optionally require the impo= rted module to have a specific revision
>    date. &= nbsp;In practice, importing a module with an exact revision date
= >    can be too restrictive because it requires the importing = module to be
>    updated whenever any change to the= imported module occurs, and hence
>    section Sect= ion 6.1 suggests that authors do not restrict YANG module
> &n= bsp;  imports to exact revision dates.

I do n= ot understand this paragraph.

First of all, isn't = "optionally require" an oxymoron? Did you mean to say that YANG modules can= optionally import modules with a specific revision date?

Secondly, isn't the whole idea of importing a module with a revisio= n date to make sure the imported module is "frozen in time"? RFC 7950 is Se= ction 5.1.1, says for imported modules using revision statements that "As f= uture revisions of the imported module are published, the importing module = is unaffected". Therefore, saying that "importing module to be updated when= ever any changes to the imported module occurs" is not a true statement.

Section 4.1, paragraph 1
>    = ;Although the previous section indicates that the actual relationship
=
>    constraints between different revisions of YANG modu= les should be
>    specified outside of the modules,= in some scenarios YANG modules are
>    designed to= be loosely coupled, and implementors may wish to select
> &nb= sp;  sets of YANG module revisions that are expected to work together.=
>    For these cases it can be helpful for a module= author to provide
>    guidance on a recommended mi= nimum revision that is expected to
>    satisfy a YA= NG import.  E.g., the module author may know of a
>  = ;  dependency on a type or grouping that has been introduced in a
>    particular imported YANG module revision.  Alt= hough there can be no
>    guarantee that all derive= d future revisions from the particular
>    imported= module will necessarily also be compatible, older revisions
>=    of the particular imported module may not be compatible.

RFC 7950 in Section 5.1.1 says that when a module is i= mported without a specific version, it is undefined which revision is used.= Given that, specifying an exact version helps. But if implementations alwa= ys import the latest version, does specifying the minimum version help? I f= eel that we are not providing a complete context here.

=
Section 6, paragraph 0
>    The following text = updates section 4.7 of [RFC8407] to revise the
>    = guidelines for updating YANG modules.

Should the r= eference be updated to rfc8407bis?

Section 6.1.1, = paragraph 1
>    1.  The changes should be made= gradually, e.g., a data node's status
>       =  SHOULD NOT be changed directly from "current" to "obsolete" (see
>        Section 4.7 of [RFC8407]), instead th= e status SHOULD first be
>        marked "= deprecated".  At some point in the future, when support
>=        is removed for the data node, there are two opt= ions.  The first,
>        and prefer= red, option is to keep the data node definition in the
>  = ;      model and change the status to =E2=80=9Cobsolete=E2= =80=9D. The second option is
>        to s= imply remove the data node from the model, but this has the
> =        risk of breaking modules which import the modifi= ed module, and
>        the removed identi= fier may be accidentally reused in a future
>     &n= bsp;  revision.

Should the reference to RFC84= 07 be updated to point to rfc8407bis?

Section 8.2,= paragraph 0
>    The YANG module specified in this = document defines a schema for data
>    that is desi= gned to be accessed via network management protocols such
> &n= bsp;  as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NET= CONF layer
>    is the secure transport layer, and t= he mandatory-to-implement secure
>    transport is S= ecure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
>=    is HTTPS, and the mandatory-to-implement secure transport is = TLS
>    [RFC8446].

Please = update to reflect the latest version of the template defined in rfc8407bis.=

No reference entries found for these items, which= were mentioned in the text:
[draft-ietf-netmod-rfc6991-bis]. I t= hink you meant [I-D.ietf-netmod-rfc6991-bis].

----= ---------------------------------------------------------------------------=
NIT
--------------------------------------------------= -----------------------------

All comments below a= re about very minor potential issues that you may choose to
addre= ss in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so th= ere
will likely be some false positives. There is no need to let = me know what you
did with these suggestions.

=
Section 3.1.1, paragraph 3
>    *  YA= NG schema nodes with a "status" "obsolete" substatement MAY be
&g= t;       removed from published modules, and the removal is = classified as a
>       backwards-compatible ch= ange.  In some circumstances it may be
>     &n= bsp; helpful to retain the obsolete definitions since their identifiers
>       may still be referenced by other modules a= nd to ensure that their
>       identifiers are= not reused with a different meaning.

s/may be hel= pful/MAY be helpful/?

Section 3.2, paragraph= 0
> 3.2.  non-backwards-compatible extension statement

s/non-backwards-compatible/Non-backwards-compatible= /

Section 7, paragraph 8
>   &nb= sp;     Copyright (c) 2024 IETF Trust and the persons identified = as
>         authors of the code.  Al= l rights reserved.

s/2024/2025/

Section 7, paragraph 27
>         C= opyright (c) 2024 IETF Trust and the persons identified as
> &= nbsp;       authors of the code.  All rights reserved.<= /div>

s/2024/2025/

Uncited refe= rences: [I-D.ietf-netmod-rfc6991-bis]. This will be fixed once you change t= he reference above.

"Table of Contents", paragraph= 1
>  . . . . . . 31 B.2. Changing the type of a leaf nod= e . . . . . . . . . . . .
>          =                     &nbs= p;   ^^^^^^^^^
If "type" is a classification term, "a" is no= t necessary. Use "type of". (The
phrases "kind of" and "sort of" = are informal if they mean "to some extent".).

Sect= ion 3, paragraph 2
> f revision B, or if revision A would have= been listed had it not been removed
>       &n= bsp;                     =    ^^^^^^^^^^^^^^^
Did you mean "had been"?
<= br>
Section 3, paragraph 12
> introduces a method to= indicate that an non-backwards-compatible (NBC) chang
>  = ;                     &nb= sp;              ^^
Use "a" in= stead of "an" if the following word doesn't start with a vowel sound,
=
e.g. "a sentence", "a university".

Section 3.= 1, paragraph 14
> marking the "status" as "obsolete" is a NBC = change, however removing the node
>        = ;                     &nb= sp;         ^
Use "an" instead of "a" if the = following word starts with a vowel sound, e.g.
"an article", "an = hour".

Section 3.1.2, paragraph 1
> e= nce of entries from the end (i.e., oldest entries) of the revision history.=  
>               &nbs= p;                     ^^= ^^^^
A determiner may be missing.

Sectio= n 4.1.1.2, paragraph 1
> n Handling February 2025 any nodes ha= s changed to "deprecated" and whether th
>      = ;                     &nb= sp;        ^^^
You should probably use "have"= .

Section 10.1, paragraph 20
>  = the old node is already set (and vice-versa). The new node could have a "wh= e
>                 &n= bsp;                 ^^^^^^^^^^
The expression "vice versa" is spelled without hyphens.
Section 10.2, paragraph 19
> old list already has= entries (and vice-versa). 4. When list "sessions" is no
> &nb= sp;                     &= nbsp;           ^^^^^^^^^^
The expressio= n "vice versa" is spelled without hyphens.

Section= 10.2, paragraph 25
>  the old node is already set (and v= ice-versa). The new node could have a "whe
>     &nb= sp;                     &= nbsp;       ^^^^^^^^^^
The expression "vice versa"= is spelled without hyphens.

Thanks
<= div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; text-indent: 0px;= text-transform: none; word-spacing: 0px; text-decoration: none;">

Mahesh Jethanandani
mjethanandani@gm= ail.com






_______________________________________________=
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email t= o netmod-leave@ietf.org
------=_Part_1354378_1358238528.1754483340576--