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 E7E5AF9C5331 for ; Tue, 2 Jun 2026 20:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780456048; bh=9V4XMJ9+JeKnCEY4v4yhHMsOKjBXjFOHG7HMMmFD88k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject; b=BkbNBlyhecqxJ+7e8mqO5OzS0ijLJXsbNXb4kC3QKps3u/LUmp+1Vel9vyORgqih3 5bpDnvr6q0/PCQi6JM4qVlC3jzTY51d3a61HNTgXgGnhiumb84zjG9RVLOsGYcDPkC tu7Cw3nupU0/a2siWsSjuOBT62j7az5fbE9MigU4= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 oIaCdC_c1BCj for ; Tue, 2 Jun 2026 20:07:27 -0700 (PDT) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (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 7E813F9C51BB for ; Tue, 2 Jun 2026 20:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1780455942; bh=w+xJ5qV6RcI8gcPoE3WGEII+nYL3WZTm0uGTMpOzsKg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=cEk5O8UBvYIAVE0yNnEoSdJIrAUbYeWjt3RLpBvF9FAA7rJ1WL/u6k9ktWBNnmPa7B1ty6Y+uDhJLvi4KQAr8vjZCLw7GzEymAD+pmbYJ8NMXkwH60wdKXD4fyGtU6zcD7BdR17bY2XplB/h78lA6zZEedlER3P3z4qmyAPDj8NpgpSGVtraRk5k9lidLeoaVsrKdDYUFJRyuQkZZrSqI8dHtpekzcIx6lRARd/ldhEbJqm3pkcvtr8WlLayZKjl/f33861xywJzORt8TB9jpYA9mIL19/aDnsNtD4yxjaXAUt5kkI+qHn7OIYfjbRo3vEXRpeMuRcY0JRGfTdmaKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1780455942; bh=4dwHZlW0Cap9t5HbBJ4/i57+e+wfvbbqbV5SkGPq0nX=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=GbIXK34q0tzmNemtRqRymTz6l/tyVL9o602tIs2kjIgWd2Fn4lTa2lMKjYUy6oZ3UAD3riTL9dTtSgOevxnlxWGq7TF7c0+MRijGtdpz3+7czrbBHL/HZB0C6gPMNAcgf0WsFP5Sphf2NZabWGcDyv/rUM9yvcUyjQ80gmc2D+2INXGGU7Ta6G+z0LwLFWfJSqAKEctKg3PBFIMt8JeXG7kbFSyV8BgIFsBYRDKKJW4EbmtOFMS7ILPo7DQ7Vg12v/pKhPeIzlyP/id6fyuCW9c6j7uC45wKcU+JQmF3uR/mSfDosC3jPyyzK41Ze/JsRPba2CKYEP1xmVJwbU5xGQ== X-YMail-OSG: 1XMlIEIVM1mvyC9ce1WINMtLHnrdvrbzMS2ktVrRM3QAgqopUpmr.WRgyLwoDPP H_t9UCTnhwAem2me7Rn6btqPz0k7srPk0W8AisLNz_iWTROkB.Z1i1UetcgbosgdUxtN0tZnTxSe s5OMfmB3GeUUrfL3UxG5WqQZ6BLhgvhjCuay6zln6nD.31EdwlSaOC8e1ONPJwKQrpnHkAGCUTU. nPlB5uB7DAEoLKVxWWXklXYI.pFUKjcP6UzrvEZBmHbjmtVWg6I.fhmdZYc8p2gEsQk7Ubsm4lGj 3zQQYuX8PVB545NcurI3b8XBVb_Kax61DdVW6msnGhy1dD6ujbVykuU5IK9UpftS6jgeBChoopv5 6jKlnZ748H58o3spWnSbD6A6673UZLFW6mS342OzWsD5WDW5qMPyln3ED.S2qH7406ja.veGIcH7 CCC9I7ZobmmxJRlhpx29jIqhVs3ZhZKoizKglfYcFgcOG8KTGMw5pSTIpQnDWTHBcqLCchllrnMo QG0RHrvIJevnyrmJ4EFrtrLHoKh2ihsiooWg1QP.9NTxPEKS7vOhY6Wh0gRx_SxHcYbQLWl.jFqx TbBQDOo9uU5INGrgsAWKOP18UCqc4_fTXmExDTcdImkVoE2vu1h.MwSdF5pqEJSDhTOgY.9h8VqV rxCScsJeODK2TMxbDEb0aoQJYvfyERE.J4K4g8wGsREvK9kfsgKaz8nMZIF8fMsd9_DDL.lDCnzL tLDTtPdsVTW_ryt.bZZiGr_CsjU84fN.TSSPCW9efXSSdeUSFnMblgyyZ0qfULE8yOewBTpXltfr d0ALZRc1QqBjqpB74UXRgFoAH.tZLL.HgT_r8eSEgFEmPZeL0rAU5_nXG849A1V.3vvAc9EZsvnQ wFHYVQ.7oj.rmHgC6OJO4wxfyQkOKryy.mhmcqpi48x9VLSfuOuhX4ilmN.Qs8vhk3AGgqG.sbKG WoVIrdh6IEbDFa.lrmhp2g5j3CdqYXCeCBdmuFnNuHz12mSTVi3aTtD8HB5NTIiCGTGRIp1E8yLf 8fFw_d2kZjpL1wmEaQgvq7Cv0BJHTh3JqpuIOvRStZMHP5vgO4sx8W441YVyzHMOBHtHCpld91N2 wR0mtXJIBACuTu2nsX1dxEDrP7_Q6Qm4oMlcFvcEgjz5q5kU9RhdzJG.scMDlfbBhylbtEqsB5Gs RfzkcAYBh6AxdqsFzLYI1Y_2nur5oO03Z8S203bpyH4Yd7uIFzmFoNB9MH6R3__oRSOMHZcF8pCZ yQEt81eqW2sdDUCb9OVfIiabsSxATbHNrx8LrHCFrKT9efAdNG3bdIQb4rXoU7TMbxdeKzDBh3g6 1ghRDQfKNAYlICPS1KtKcNWcKdMfVKJ6UNmyHOf9kKCDdd9PW56Q_.RB0IHnfjf.xDWh6khN8YaW GGzMiKZA8n6GovaWDZW6QOD1Ybdk2xtAgj.vmAU04lP3g.4bB4R8kaC__FIkOkcwWopPVHB2THbg MtNqvr2MMd1Goub5Cm.BklGV3W9xBxlH3ET7GWWdXAYk00FlaBvCy6gNe_Wb7tjP_ZvrZ8ynvope yG5pszeGJ9k5AVWo6Kp2HdF7GeHdJRsp6vIuihN1n_nreMOB_hQbdVhecwCb0cZMMkuMMCRzNrKe XsZKqrFDbHwWd6jDv60Gg.iDHJSgoLwslCvciOto.CV2vVmFeFiS5bqSTWgCDSJXaT8qDLoEfZjb BcnTcftzWFEyQ7gpPFJPeV4p0HEU3.C1ZpaSfUmQq3NrCsZUMCtIxZCz0TBkfilLOTJUn1VDWwk0 v1MU3nPw8o6wNWaf1UOJ5zaBucZSyEwwf6OzmKCI.MDnQyRMTVgnvZom4u00WS0QT48wrMO.5ewS KVvH6evVYEYWMptBJlFCt110AsixRliyglsIjFLQ1GL16qMj2oVzvE.WZXiW6o8bR5JRAcVvWxaV O1AIn1ZSVg48JQnLoafqs0VWqBfro9m.LJiNY7t6Mw.DVGbEnYW4W3w8ElCSbFAx8XLnG95JJk34 GZ.rOutsQ.dtwnNM_EdmtlNgLAbhym_x7cze5OJcqLH43cC9Ia_lNCpmcXFOl_4vSvdh1_YVS3PG 2eiV50thYZcxX..lY6SLrw8l3nJC.jbzJZLWQ.61qY_QF8ZW_EKiPSFH0WNz325UIDEQoYe9C4ti 9g6gavv56fGOy1s3nmlsN0YXwTtAy4PGUT09BKrTPNzK_UpJfcqPbXjqxRxeP4y2viHz1JPQBDrH QayD.ZXDVn6fMasWIkkNcZpKrpG5XmzNSVyAvDyQgGSj3VwYcUZVs_.6ZKUmcdb.r4bv4r3j59PG 1Fh1V X-Sonic-MF: X-Sonic-ID: 63bcca5f-b6db-4b28-a051-9b7ad09bce83 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 3 Jun 2026 03:05:42 +0000 Date: Wed, 3 Jun 2026 03:05:39 +0000 (UTC) From: Reshad Rahman To: The IESG , Mohamed Boucadair Message-ID: <1854719627.384393.1780455939785@mail.yahoo.com> In-Reply-To: <177997148638.1360269.5440529245145539540@dt-datatracker-5b4c8598b5-4ztf9> References: <177997148638.1360269.5440529245145539540@dt-datatracker-5b4c8598b5-4ztf9> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_384392_1384825797.1780455939777" X-Mailer: WebService/1.1.25882 YMailNorrin Message-ID-Hash: G3S7EU4IYHUKQVS35OZROIEPEDSA5VAT X-Message-ID-Hash: G3S7EU4IYHUKQVS35OZROIEPEDSA5VAT 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: "draft-ietf-netmod-yang-module-versioning@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: Reshad Rahman Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_Mohamed_Boucadair=27s_Discuss_on_draft-ietf-net?= =?utf-8?q?mod-yang-module-versioning-16=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: NETMOD WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_384392_1384825797.1780455939777 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, Thanks for the review. Below are responses to the DISCUSS points. On Thursday, May 28, 2026 at 08:32:12 AM EDT, Mohamed Boucadair via Dat= atracker wrote: =20 =20 Mohamed Boucadair has entered the following ballot position for draft-ietf-netmod-yang-module-versioning-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-= ballot-positions/=20 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Rob, Reshad, Bal=C3=A1zs, Joe, and Jason, Thank you for the effort put into this important piece. I will be definitel= y balloting YES. I have some few points to discuss. Comments are listed following the order = in the document, not their importance. # Augmentation and Update CURRENT: =C2=A0 This document updates [RFC8525] with augmentations to include two =C2=A0 boolean leafs to indicate whether status deprecated and status =C2=A0 obsolete schema nodes are implemented by the server. We don=E2=80=99t usually update specs with augmented module. Please conside= r adding some text to explain what is special here. Understood, but what is different in this case is that we're clarifyin= g RFC8525 behaviour.=C2=A0Proposed text: Note, an updates tag is being used= to highlight to readers of RFC8525 of the relationship between these docum= ents because RFC 8525 is a core manageability specification and this docume= nt sets the future direction of YANG versioning. # Authors Guidelines vs Specification Section 3 is more about refinement of rules in [RFC7950] and [RFC6020], how= ever there are parts that are move guidance to authors, which fall under 9907 updates. An example of such text is the following: CURENT: =C2=A0 Removing revision statements is allowed, but can cause =C2=A0 issues and SHOULD NOT be done without careful analysis of the =C2=A0 potential impact to users of the module or submodule since it may =C2=A0 cause loss of visibility of when non-backwards-compatible changes =C2=A0 were introduced. ## Wouldn=E2=80=99t be cleaner to move such parts to be under the section w= ith 9907 updates? =C2=A0Could we instead, add a sentence=C2=A0referencing RFC 9907 sectio= n 4.8 to the list of things being referenced/updated at the beginning of se= ction 3? =C2=A0We feel that it might be helpful to keep this text together = rather than splitting into two sections, particularly because section 6 foc= uses on different aspects. =C2=A0Thoughts? ## The text is more about what can be considered, but there is no guidance/= reco on how/whether the outcome of that analysis is recorded in the module/docum= ent itself. Can we add some guidance? The guidance in this section is that the revision histories can be rem= oved, if they don't impact the tracking of NBC changes. =C2=A0The expectati= on is that there shouldn't be any need for any extra documentation of remov= ing old revision statements that are no longer required, e.g., perhaps they= are in versions that are 5+ years old and are no longer in any shipping re= lease. =C2=A0I guess the authors could add a comment describing the removal= to the latest revision change, but we think that probably isn't needed (or= the authors don't have consensus on this point), and this should be out of= scope for this document. ## BTW, does this cover published modules or any flavor? Published modules. # Multiple versions of the same module CURRENT: =C2=A0 If a "recommended-min-date" extension statement is ignored by a YANG =C2=A0 parser, the import statement is processed according to the rules =C2=A0 documented in Section 7.1.5 of [RFC7950]. Per 7950, =E2=80=9CMultiple revisions of the same module can be imported, p= rovided that different prefixes are used=E2=80=9D. This would allow in theory authors to pick from revisions of the same modul= es but with distinct deprecation status. Do we need to say anything about mixi= ng versions that deprecate vs. not deprecate a given data node? =C2=A0The issue above is orthogonal to this document. =C2=A0The actual = behaviour would depend on how the imported data nodes are used (e.g., is it= pulling a particular version of a grouping or type) and would pick up the = deprecated status of whichever version is imported. =C2=A0Also, it is worth= noting that you can only "implement" a single version of a module even if = you can import definitions from multiple versions. # Missing Rationale CURRENT: =C2=A0 Servers SHOULD set both the "deprecated-nodes-implemented" and =C2=A0 "obsolete-nodes-absent" leafs to "true", which allows clients to =C2=A0 determine the exact schema used by the server. ## I don=E2=80=99t understand what is the reasoning of this reco? Why are w= e asking an implem to still support data nodes? =C2=A0The core reason is that the schema is well defined, i.e., so that= the clients can know with certainty which nodes are actually implemented b= y the server. =C2=A0For any nodes (current or deprecated) that are not impl= emented then deviation "not-supported" are a better and precise mechanism t= o remove nodes that are not supported. =C2=A0Note that in programming langu= ages deprecated APIs often also means that the API is supported but not rec= ommended, similarly in YANG, deprecated does not in itself mean that the no= de is not supported. ## How setting these Boolean helps know =E2=80=9Cthe exact schema used by t= he server=E2=80=9D.=20 A server may have partial support of those. These nodes are not helpful for that. See above. # Incomplete Guidance CURRENT: =C2=A0 A module that includes submodules SHOULD use the "revision-date" =C2=A0 statement to include specific submodule revisions.=C2=A0 The revisio= n of =C2=A0 the including module MUST be updated when any included submodule has =C2=A0 changed. ## Who is the target of the last part of this guidance? =C2=A0The key goal/requirement here is that a particular module version= /revision is well defined to a particular schema so the guidance is for aut= hors, and users of the YANG modules. =C2=A0But as per the section headline,= it is really=C2=A0aimed at ensuring module authors follow this rule. ## How that update is supposed to work? # I would strengthen the guidance to MUST for this part: CURRENT: =C2=A0 =C2=A0 =C2=A0 If there is a replacement data node, rpc, action or =C2=A0 =C2=A0 =C2=A0 notification for the deprecated node, this SHOULD be s= tated in =C2=A0 =C2=A0 =C2=A0 the "description". We had some discussions and our suggestion is to remove the normative = language: =C2=A0 =C2=A0 =C2=A0 If there is a replacement data node, rpc, action or=C2= =A0 =C2=A0 =C2=A0 notification for the deprecated node, then updating the= =C2=A0 =C2=A0 =C2=A0 description of the deprecated node to highlight the=C2= =A0 =C2=A0 =C2=A0 replacement may be helpful. FYI, note that this document aimes to tackle the replacement "issue". # IANA-maintained modules CURRENT: =C2=A0 In all cases, IANA MUST follow the versioning guidance specified in =C2=A0 Section 3.1, and MUST include a "rev:non-backwards-compatible" =C2=A0 substatement to the latest revision statement whenever an IANA =C2=A0 maintained module is updated in a non-backwards-compatible way, as =C2=A0 described in Section 3.2. ## I don=E2=80=99t see how these MUSTs can be done by IANA without expert a= ssistance. This guidance smells like adding Expert Review to all registries that are represented with a YANG module. ## I guess some of the answers are in: CURRENT: =C2=A0 See [I-D.ietf-netmod-iana-yang-guidance] for complete guidance on ho= w =C2=A0 to handle versioning for IANA maintained YANG modules. However, I-D.ietf-netmod-iana-yang-guidance is only listed as Informative. If the full guidance is what is recorded in that draft, then I-D.ietf-netmod-iana-yang-guidance has to be normative. This document defines the strict rules (normative) and=C2=A0I-D.ietf-n= etmod-iana-yang-guidance is the current guidance of how those rules can be = achieved.=C2=A0 ## The normative language in the IANA section can be avoided per the IESG statement on the matter. Could you clarify which IESG statement you are referring to? We looked= for it... Regards,Reshad. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Applicability I suggest to add a statement early in the document about the target modules= (is it published, unpublished, IETF modules, IANA-maintained, etc.). # The lifecycle model in 4.7 of 9907 (also updated here) can also be relaxe= d when there are no known implem/deploymnents. Can we include a I have seen b= is doc fixing those. Relax rule is needed. # RFC 8407 CURRENT: Network Working Group=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 R= . Wilton, Ed. Internet-Draft=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 C= isco Systems, Inc. Updates: 6020, 7950, 8407, 8525 (if approved)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 R. Rahman, Ed. Intended status: Standards Track=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 Equin= ix Expires: 23 October 2026=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 B. Lengyel, = Ed. =E2=80=A6 =C2=A0 This document updates RFC 7950, RFC 6020, =C2=A0 RFC 8407 and RFC 8525. Please update to RFC9907. # Ambiguous =E2=80=9Csuggestion=E2=80=9D CURRENT: =C2=A0 It extends the YANG import statement with a minimum =C2=A0 revision suggestion to help document inter-module dependencies. =C2=A0 ^^^^^^^^^^^^^^^^^^^^ I don=E2=80=99t know how to interpret the highlighted text. # Won=E2=80=99t age well OLD: =C2=A0 The current YANG [RFC7950] module update rules require that updates =C2=A0 of YANG modules preserve strict backwards compatibility. NEW: =C2=A0 The YANG module update rules per [RFC7950] require that updates =C2=A0 of YANG modules preserve strict backwards compatibility. # (nit) YANG 1.0 OLD: Refinements to the YANG 1 and YANG 1.1 module revision update NEW: Refinements to the YANG 1.0 and YANG 1.1 module revision update # Stale text: CURRENT: 1.2.=C2=A0 Editorial Note (To be removed by RFC Editor) =C2=A0 =C2=A0 =C2=A0 Note to the RFC Editor: This section is to be removed = prior to =C2=A0 =C2=A0 =C2=A0 publication. =C2=A0 This document updates [I-D.ietf-netmod-rfc8407bis].=C2=A0 The header =C2=A0 metadata for this document should be updated to the new RFC number =C2=A0 when [I-D.ietf-netmod-rfc8407bis] is published. Please delete. # Terminology Consider add to the list RFC 9907 as we are using terms =E2=80=9CIANA-maint= ained YANG module=E2=80=9D, =E2=80=9Cpublished=E2=80=9D, etc. that are defined there. # Helps readers CURRENT: =C2=A0 or if revision A would have been listed had it =C2=A0 not been removed (see Section 3.3). Can you please consider rewording as I had difficulty to parse this. Thanks= . # nit OLD: A module's name and revision date identifies a specific NEW: A module's name and revision date identify a specific # Section 3.1.1 CURRENT: =C2=A0 *=C2=A0 A "status" "deprecated" statement MAY be added, or changed f= rom =C2=A0 =C2=A0 =C2=A0 "current" to "deprecated", but adding or changing "sta= tus" to =C2=A0 =C2=A0 =C2=A0 "obsolete" is a non-backwards-compatible change. As there other rules in 9907 for such status transition, especially this pa= rt: =E2=80=9CThe status SHOULD NOT be changed from "current" directly to "obsol= ete". An object SHOULD be available for at least one year after the publication date with a "deprecated" status before it is changed to "obsolete".=E2=80=9D I suggest to update the above bullet to emphasis that such status changes should also be done per the guidance in 9907 and update behavior in Section= 6. # Section 4 CURRENT: =C2=A0 Instead, for conformance purposes (section 5.6 of [RFC7950]), the =C2=A0 recommended approach for defining the relationship between specific =C2=A0 YANG module revisions is to specify the relationships outside of the =C2=A0 YANG modules, Should s/recommended/RECOMMENDED to better highlight the guidance? # Section 4.1 CURRENT: =C2=A0 This module introduces, primarily for modules with a linear revision =C2=A0 history that are versioned using revision dates, Not sure what we meant by =E2=80=9CThis module=E2=80=9D here. Please reword= to make that explicit. # RFC 9907 Guidance and template ## Example prefix CURRENT: prefix "prefix-name"; GUIDANCE: =C2=A0 For convenience, prefix values of example modules SHOULD be prefixed =C2=A0 with "ex" or similar patterns. ## Update TLP to 2026 for all modules ## Module template OLD: =C2=A0 =C2=A0 =C2=A0 =C2=A0 This version of this YANG module is part of RFC= XXXX; see =C2=A0 =C2=A0 =C2=A0 =C2=A0 the RFC itself for full legal notices. NEW: =C2=A0 =C2=A0 =C2=A0 =C2=A0 All revisions of IETF and IANA published module= s can be found =C2=A0 =C2=A0 =C2=A0 =C2=A0 at the YANG Parameters registry group =C2=A0 =C2=A0 =C2=A0 =C2=A0 (https://www.iana.org/assignments/yang-paramete= rs). =C2=A0 =C2=A0 =C2=A0 =C2=A0 This version of this YANG module is part of RFC= XXXX; see =C2=A0 =C2=A0 =C2=A0 =C2=A0 the RFC itself for full legal notices."; ## Sec cons OLD: =C2=A0 This section uses the template described in Section 3.7 of =C2=A0 [I-D.ietf-netmod-rfc8407bis]. NEW: =C2=A0 This section uses the template described in Section 3.7.1 of =C2=A0 [RFC9907]. ## IANA Registrations Please add for both registrations: =C2=A0 =C2=A0 =C2=A0 Maintained by IANA?=C2=A0 N # RFC 9911 CURRENT: =C2=A0 =C2=A0 =C2=A0 The argument to the "recommended-min-date" extension s= tatement is =C2=A0 =C2=A0 =C2=A0 a revision date which uses the "date-no-zone" type def= ined in =C2=A0 =C2=A0 =C2=A0 [I-D.ietf-netmod-rfc6991-bis]. And =C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC YYYY-draft-ietf-netmod-rfc6991-bis: Common= YANG Data Types"; =C2=A0 =C2=A0 } # Default values Shouldn=E2=80=99t a default false statement be better here rather than havi= ng this in the description or by normative text? CURRENT: =C2=A0 deprecated-nodes-implemented:=C2=A0 If set to "true", this leaf indi= cates =C2=A0 =C2=A0 =C2=A0 that all schema nodes with a status "deprecated" are i= mplemented =C2=A0 =C2=A0 =C2=A0 equivalently as if they had status "current"; otherwis= e deviations =C2=A0 =C2=A0 =C2=A0 MUST be used by the server to explicitly remove "depre= cated" nodes =C2=A0 =C2=A0 =C2=A0 from the schema.=C2=A0 If this leaf is set to "false" = or absent, then =C2=A0 =C2=A0 =C2=A0 the behavior is unspecified. =C2=A0 obsolete-nodes-absent:=C2=A0 If set to "true", this leaf indicates t= hat =C2=A0 =C2=A0 =C2=A0 the server does not implement any status "obsolete" sc= hema nodes. =C2=A0 =C2=A0 =C2=A0 If this leaf is set to "false" or absent, then the beh= aviour is =C2=A0 =C2=A0 =C2=A0 unspecified. =E2=80=A6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean; =C2=A0 =C2=A0 =C2=A0 =C2=A0 description =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "If set to true, this leaf indicates tha= t all schema nodes =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with a status 'deprecated' are im= plemented equivalently as =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if they had status 'current'; oth= erwise deviations MUST be =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used to explicitly remove depreca= ted nodes from the schema. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If this leaf is absent or set to = false, then the behavior is =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unspecified."; .. =C2=A0 =C2=A0 =C2=A0 leaf obsolete-nodes-absent { =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean; =C2=A0 =C2=A0 =C2=A0 =C2=A0 description =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "If set to true, this leaf indicates tha= t the server does not =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implement any status 'obsolete' s= chema nodes.=C2=A0 If this leaf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is absent or set to false, then t= he behaviour is =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unspecified."; # Please add an Operational Considerations Section I suggest to add at least some text to basically encourage authors to detai= ls the OPS impacts of changes. # References Please move the following entries from Normative to Informative =C2=A0 [RFC6241]=C2=A0 Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J.= , Ed., =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and A. Bierman, Ed., "Netw= ork Configuration Protocol =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (NETCONF)", RFC 6241, DOI = 10.17487/RFC6241, June 2011, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . =C2=A0 [RFC8040]=C2=A0 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Protocol", RFC 8040, DOI 1= 0.17487/RFC8040, January 2017, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . =C2=A0 [RFC8446]=C2=A0 Rescorla, E., "The Transport Layer Security (TLS) Pr= otocol =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version 1.3", RFC 8446, DO= I 10.17487/RFC8446, August 2018, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . # nits * s/and hence section Section 6.1/and hence Section 6.1 * s/consumers of YANG models/ consumers of YANG data models * s/The author/Authors * s/an author/Authors * s/New ietf-yang-library-status YANG module/The =E2=80=9Cietf-yang-library= -status=E2=80=9D YANG module Cheers, Med _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-leave@ietf.org =20 ------=_Part_384392_1384825797.1780455939777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

Th= anks for the review. Below are responses to the DISCUSS points.
<= br>
=20
=20
On Thursday, May 28, 2026 at 08:32:12 AM EDT, Moham= ed Boucadair via Datatracker <noreply@ietf.org> wrote:


=20 =20
Mohamed Boucadair has entered the following= ballot position for
draft-ietf-netmod-yang-module-versioning-16: Discuss

When responding, please keep the subject l= ine intact and reply to all
email addresses included in the To and CC lines. (Feel free t= o cut this
int= roductory paragraph, however.)


for more information about= how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



=
-----------------= -----------------------------------------------------
DISCUSS:
----------------------------------------= ------------------------------

Hi Rob, Reshad, Bal=C3=A1zs, Joe, and Jason,

Thank you for the effort put into this important piec= e. I will be definitely
balloting YES.

I = have some few points to discuss. Comments are listed following the order in=
the document,= not their importance.

# Au= gmentation and Update

CURRE= NT:
  Th= is document updates [RFC8525] with augmentations to include two
  boolean leafs to = indicate whether status deprecated and status
  obsolete schema nodes are implement= ed by the server.

We don=E2= =80=99t usually update specs with augmented module. Please consider adding<= br>
some text to e= xplain what is special here.

<RR> Un= derstood, but what is different in this case is that we're clarifying RFC85= 25 behaviour. 
Proposed text: Note, an updates tag= is being used to highlight to readers of RFC8525 of the relationship betwe= en these documents because RFC 8525 is a core manageability specification a= nd this document sets the future direction of YANG versioning.

# Authors Guidelines vs Specification

Section 3 is more about refinem= ent of rules in [RFC7950] and [RFC6020], however
there are parts that are move guidance t= o authors, which fall under 9907
updates. An example of such text is the following:

CURENT:
  Removing revision statements = is allowed, but can cause
  issues and SHOULD NOT be done without careful analysis = of the
  = potential impact to users of the module or submodule since it may
  cause loss of = visibility of when non-backwards-compatible changes
  were introduced.

## Wouldn=E2=80=99t be cleaner to move = such parts to be under the section with 9907
updates?

= <RR>=  Could we instead, add a sentence referencing RFC 9907 section 4.= 8 to the list of things being referenced/updated at the beginning of sectio= n 3?  We feel that it might be helpful to keep this text together rath= er than splitting into two sections, particularly because section 6 focuses= on different aspects.  Thoughts?

## The text is more about what can be considered, but ther= e is no guidance/reco
on how/whether the outcome of that analysis is recorded in the modu= le/document
it= self. Can we add some guidance?

&l= t;RR> The guidance in this section is that the revision histories can be= removed, if they don't impact the tracking of NBC changes.  The expec= tation is that there shouldn't be any need for any extra documentation of r= emoving old revision statements that are no longer required, e.g., perhaps = they are in versions that are 5+ years old and are no longer in any shippin= g release.  I guess the authors could add a comment describing the rem= oval to the latest revision change, but we think that probably isn't needed= (or the authors don't have consensus on this point), and this should be ou= t of scope for this document.

## BTW, does this cover published modules or any flavor?

&= lt;RR> Published modules.

# Multiple versions of the same module

CURRENT:
  If a "recommended-min-date" extension statement is igno= red by a YANG
=   parser, the import statement is processed according to the rules
  document= ed in Section 7.1.5 of [RFC7950].

Per 7950, =E2=80=9CMultiple revisions of the same module can be impo= rted, provided that
different prefixes are used=E2=80=9D.

This would allow in theory authors to pick from revisions = of the same modules
but with distinct deprecation status. Do we need to say anything abou= t mixing
versi= ons that deprecate vs. not deprecate a given data node?

<RR> The issue above is orthogonal to th= is document.  The actual behaviour would depend on how the imported da= ta nodes are used (e.g., is it pulling a particular version of a grouping o= r type) and would pick up the deprecated status of whichever version is imp= orted.  Also, it is worth noting that you can only "implement" a singl= e version of a module even if you can import definitions from multiple vers= ions.

# Missing Rationale

CURRENT:
  Servers SHOULD set both the "deprecat= ed-nodes-implemented" and
  "obsolete-nodes-absent" leafs to "true", which allows c= lients to
&nbs= p; determine the exact schema used by the server.

## I don=E2=80=99t understand what is the reasoning= of this reco? Why are we asking an
implem to still support data nodes?

<RR> The core reason is that the schema = is well defined, i.e., so that the clients can know with certainty which no= des are actually implemented by the server.  For any nodes (current or= deprecated) that are not implemented then deviation "not-supported" are a = better and precise mechanism to remove nodes that are not supported.  = Note that in programming languages deprecated APIs often also means that th= e API is supported but not recommended, similarly in YANG, deprecated does = not in itself mean that the node is not supported.

## How setting these Boolean helps know =E2=80= =9Cthe exact schema used by the server=E2=80=9D.
A server may have partial support of th= ose. These nodes are not helpful for
that.

<RR> See ab= ove.

# Incomp= lete Guidance
=
CURRENT:
<= /div>
  A module t= hat includes submodules SHOULD use the "revision-date"
  statement to include speci= fic submodule revisions.  The revision of
  the including module MUST be updat= ed when any included submodule has
  changed.

## Who is the target of the last part of this guidance?

<RR> The key goal/requirement here is that a pa= rticular module version/revision is well defined to a particular schema so = the guidance is for authors, and users of the YANG modules.  But as pe= r the section headline, it is really aimed at ensuring module authors = follow this rule.


## How that update is supposed to work?
=

# I would strengthen the guida= nce to MUST for this part:

= CURRENT:
 = ;     If there is a replacement data node, rpc, action or
     = notification for the deprecated node, this SHOULD be stated in
<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">      th= e "description".

<RR> We had some discussi= ons and our suggestion is to remove the normative language:

      If there is a replacement d= ata node, rpc, action or
      notification for the depre= cated node, then updating the
      description of the de= precated node to highlight the
      replacement may be h= elpful.

FYI, note that this document a= imes to tackle the replacement "issue".

# IANA-maintained modules
<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">
CURRENT:
  In all cases, IANA MUST follow the= versioning guidance specified in
  Section 3.1, and MUST include a "rev:non-backwa= rds-compatible"
  maintain= ed module is updated in a non-backwards-compatible way, as
  described in Section 3= .2.

=
## I don=E2=80=99t see = how these MUSTs can be done by IANA without expert assistance.
This guidance smells like = adding Expert Review to all registries that are
represented with a YANG module.
=

## I guess some of the answers are i= n:

<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">CURRENT:
  See [I-D.ietf-netmod-= iana-yang-guidance] for complete guidance on how
  to handle versioning for IANA ma= intained YANG modules.

Howe= ver, I-D.ietf-netmod-iana-yang-guidance is only listed as Informative.
<= /div>

If the full guidance is what is= recorded in that draft, then
I-D.ietf-netmod-iana-yang-guidance has to be normative.
=

<RR> This document defines the strict rules (normative) = and I-D.ietf-= netmod-iana-yang-guidance is the current guidance of how those rules can be= achieved. 

## The normative language in the IANA section can be avoided per the IE= SG
statement o= n the matter.
=
<RR> Could you clarify which IESG statement = you are referring to? We looked for it...

Regards,
Reshad.


----------------------------------------------------------------------=
COMMENT:
<= /div>
------------------= ----------------------------------------------------

# Applicability

I suggest to add a statement early in the document about t= he target modules (is
it published, unpublished, IETF modules, IANA-maintained, etc.).

# The lifecycle model in 4.7 = of 9907 (also updated here) can also be relaxed
when there are no known implem/deploymnen= ts. Can we include a I have seen bis
doc fixing those. Relax rule is needed.

# RFC 8407

CURRENT:

Internet-Draft                &nbs= p;                     C= isco Systems, Inc.
Updates: 6020, 7950, 8407, 8525 (if approved)      &nbs= p;     R. Rahman, Ed.
Intended status: Standards Track      &nb= sp;                     &= nbsp;   Equinix
Expires: 23 October 2026            &= nbsp;                   B. Le= ngyel, Ed.
=E2=80=A6

  This document updates R= FC 7950, RFC 6020,
  RFC 8407 and RFC 8525.

Please update to RFC9907.

# Ambiguous =E2=80=9Csuggestion=E2=80=9D

CURRENT:
  It extends the YANG import statement with a minimu= m
  revi= sion suggestion to help document inter-module dependencies.
  ^^^^^^^^^^^^^^^^^^^^<= br>

I don=E2=80=99t know how to= interpret the highlighted text.

# Won=E2=80=99t age well

OLD:
 = ; The current YANG [RFC7950] module update rules require that updates
<= /div>
  of YANG mo= dules preserve strict backwards compatibility.

NEW:
  The YANG module update rules per [RFC7950] require that = updates
 = of YANG modules preserve strict backwards compatibility.

# (nit) YANG 1.0

OLD: Refinements to the YANG 1 and YANG 1.1 module re= vision update
=
NEW: Refineme= nts to the YANG 1.0 and YANG 1.1 module revision update

# Stale text:

CURRENT:
1.2.  Editorial Note (To be removed by RFC Editor)

      Note to th= e RFC Editor: This section is to be removed prior to
      publication.

  This document updates= [I-D.ietf-netmod-rfc8407bis].  The header
  metadata for this document should= be updated to the new RFC number
  when [I-D.ietf-netmod-rfc8407bis] is published.=

Please delete.

# Terminology

Consider add to the list RFC 9907 as we are using t= erms =E2=80=9CIANA-maintained YANG
module=E2=80=9D, =E2=80=9Cpublished=E2=80=9D, etc. tha= t are defined there.

# Help= s readers

=
CURRENT:
  or if revision= A would have been listed had it
  not been removed (see Section 3.3).

Can you please consider rewording as I = had difficulty to parse this. Thanks.

# nit

OLD: A mod= ule's name and revision date identifies a specific

NEW: A module's name and revision date identify a s= pecific

# Section 3.1.1
=

CURRENT:
  *  A "status" "depreca= ted" statement MAY be added, or changed from
      "current" to "deprecate= d", but adding or changing "status" to
      "obsolete" is a non-backwards= -compatible change.

As ther= e other rules in 9907 for such status transition, especially this part:
=

=E2=80=9CThe status SHOULD NOT= be changed from "current" directly to "obsolete". An
object SHOULD be available for at l= east one year after the publication date
with a "deprecated" status before it is changed = to "obsolete".=E2=80=9D

I s= uggest to update the above bullet to emphasis that such status changes
<= /div>
should also be don= e per the guidance in 9907 and update behavior in Section 6.

# Section 4

CURRENT:
  Instead, for conformance purposes (section 5.6 of [RF= C7950]), the
&= nbsp; recommended approach for defining the relationship between specific<= br>
  YANG m= odule revisions is to specify the relationships outside of the
  YANG modules,
<= /div>

Should s/recommended/RECOMMENDE= D to better highlight the guidance?

# Section 4.1

CURR= ENT:
  T= his module introduces, primarily for modules with a linear revision
  history that = are versioned using revision dates,

Not sure what we meant by =E2=80=9CThis module=E2=80=9D here. Plea= se reword to make that
explicit.

# RFC 99= 07 Guidance and template

##= Example prefix
CURRENT:
prefix "prefix-= name";

GUIDANCE:
<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">  For convenience,= prefix values of example modules SHOULD be prefixed
  with "ex" or similar pattern= s.

<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">## Update TLP to 2026 fo= r all modules
=
## Module tem= plate

OLD:
        Th= is version of this YANG module is part of RFC XXXX; see
        the= RFC itself for full legal notices.

NEW:
=         All revisions of IETF and IANA published module= s can be found
        at the YANG Parameters registry group
      &= nbsp; (https://www.iana.org/assignments/yang-parameters).

        This version of = this YANG module is part of RFC XXXX; see
        the RFC itself fo= r full legal notices.";

## = Sec cons

<= /div>
OLD:
  This section uses t= he template described in Section 3.7 of
  [I-D.ietf-netmod-rfc8407bis].

NEW:
  This section uses the template descri= bed in Section 3.7.1 of
  [RFC9907].


Ple= ase add for both registrations:

      Maintained by IANA?  N

# RFC 9911

CURRENT:

  =     The argument to the "recommended-min-date" extension statemen= t is
  &n= bsp;   a revision date which uses the "date-no-zone" type defined in
    &= nbsp; [I-D.ietf-netmod-rfc6991-bis].

And
=
   =     "RFC YYYY-draft-ietf-netmod-rfc6991-bis: Common YANG Data T= ypes";
  =   }

=
# Default values<= br>

Shouldn=E2=80=99t a default= false statement be better here rather than having this in
the description or by normativ= e text?

CURRENT:
<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">
  deprecated-nodes-implemented:=   If set to "true", this leaf indicates
      that all schema nodes w= ith a status "deprecated" are implemented
      equivalently as if they = had status "current"; otherwise deviations
      MUST be used by the serv= er to explicitly remove "deprecated" nodes
      from the schema.  I= f this leaf is set to "false" or absent, then
      the behavior is unspec= ified.

  obsolete-nod= es-absent:  If set to "true", this leaf indicates that
      the serv= er does not implement any status "obsolete" schema nodes.
      If this le= af is set to "false" or absent, then the behaviour is
      unspecified.

=E2=80=A6
        ty= pe boolean;
&n= bsp;       description
          "If set to tru= e, this leaf indicates that all schema nodes
            wi= th a status 'deprecated' are implemented equivalently as
        &nb= sp;   if they had status 'current'; otherwise deviations MUST be
     = ;       used to explicitly remove deprecated nodes from the = schema.
 =           If this leaf is absent or set to false,= then the behavior is
            unspecified.";
<= div dir=3D"ltr" style=3D"color: rgb(38, 40, 42); font-size: 13px; font-fami= ly: Helvetica Neue, Helvetica, Arial, sans-serif;">..

      leaf obsolete-nodes-absent= {
  &nbs= p;     type boolean;
        description
        &n= bsp; "If set to true, this leaf indicates that the server does not
      =       implement any status 'obsolete' schema nodes.  If= this leaf
&nb= sp;           is absent or set to false, then the = behaviour is
&= nbsp;           unspecified.";

# Please add an Operational Considerations S= ection

I suggest to add at = least some text to basically encourage authors to details
the OPS impacts of changes.
=

# References

Please move the following entries from Norma= tive to Informative

  = [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,=
   =           and A. Bierman, Ed., "Network Configura= tion Protocol
=               (NETCONF)", RFC 6241, DOI = 10.17487/RFC6241, June 2011,

  [RFC8040]  Bierman, A., Bjorklund, = M., and K. Watsen, "RESTCONF
              Protocol", = RFC 8040, DOI 10.17487/RFC8040, January 2017,
            &= nbsp; <https://www.rfc-editor.org/info/rfc8040>.
<= /div>

  [RFC8446]  Rescorl= a, E., "The Transport Layer Security (TLS) Protocol
          &n= bsp;   Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<= /div>
    &nbs= p;         <https://www.rfc-editor.org/i= nfo/rfc8446>.

# nits=

* s/and hence section Sect= ion 6.1/and hence Section 6.1

* s/consumers of YANG models/ consumers of YANG data models

* s/The author/Authors

* s/an author/Authors

* s/New ietf-yang-library-status YANG module/The= =E2=80=9Cietf-yang-library-status=E2=80=9D
YANG module

Cheers,
Med



______________________________________= _________
netm= od mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-leave@ietf.org<= /a>
------=_Part_384392_1384825797.1780455939777--