Return-Path: X-Original-To: netconf@mail2.ietf.org Delivered-To: netconf@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 602C612650061 for ; Sat, 8 Aug 2026 17:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786236667; bh=KHAdtte+M9Lao9u+iVHDdLBhgPFmVzbuq1oNX7/kYfA=; h=From:Subject:Date:Cc:To; b=euR6iZUyhHReKlckEaFunW8L8UDvSgM36E79Nlpe2uDS1QvjR/T6yPp1eS8FKnOwg DtnN4DWBpEmPwblT/fmTPcTFPCiYqf1NCAJB4ndAFSXYx9HY2jJkVZNzSt6Akssm2c qzwfDWNiXrQForBw/IIftueaVoIfckoWSj+vpyAI= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=gmail.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 q6cZ8M22VL00 for ; Sat, 8 Aug 2026 17:51:06 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 A7AF412650059 for ; Sat, 8 Aug 2026 17:51:06 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-2ce87c7e3bbso7893745ad.1 for ; Sat, 08 Aug 2026 17:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786236660; x=1786841460; darn=ietf.org; h=to:cc:date:message-id:subject:mime-version:content-type:from:from :to:cc:subject:date:message-id:reply-to:content-type; bh=KOu80TJ/jDOQfURO8yVHwg4ff7qlEl0Xs4n8cfOkKKQ=; b=iN3nCHcEtNVxsrPlmZ4RNlZTcxD0pjlX0hZKUbR3sAW8DlTGto/zwGyYxkdAgdMQBe +loFQKNYvxSZgWIT3Kp+4mjjCE+0L6qqGBfyHy8lp2XMPEsCVobZ6NAa37pTc1iCmKzP 7HathxBI1RIuZnQ/mLKiBHoVGwPCYvPmUHNlAl0Y8ZIfzSBeCzG0YylYDdU4EBO8jrca gujxsyLzFyAb42709bsxVUpIUtkyXozi2+9z+zynbgNtoIumDP7PXaMr3OytV8JNmqr+ J493xjKTO3Dok8DwWlZPFOgDktKjEUMHuycBLBr0DmKTiAtXJVMwwFo1u3f320Z9/JvR nZIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786236660; x=1786841460; h=to:cc:date:message-id:subject:mime-version:content-type:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=KOu80TJ/jDOQfURO8yVHwg4ff7qlEl0Xs4n8cfOkKKQ=; b=bIEx90R5U1bdbBYgayT15O/g7ak2BfEu7zlgw6cFYA9hsOFEoUZdkGJJVZzQrATZWf SKh6EmkXkvDEZ3eBb4iiQnpZBo0uAfWnRuNvAeeUZxTIP1qAU6NpuWYlO/xE0TavLB0z 9YeS2pUEst5k95Z2BWOZEfhPckljTqDtH8i3ouAmWcK1FiFxQsK+4xsi11wmIs9GBotP uV6q42Qimg690TjtGBG8l7Ke+YrXbKtG4PVoxTWKGP7f/8hcFq3896+x55l8e3tXGZZA RaHbu40bOI7rM4rheVBvK3m4oPSW5k38pjBCv8f2nG10TbJE4M4T/yI3lAUI4CjBdgME qPjg== X-Gm-Message-State: AOJu0YxDf+oa4iSPIp+d6fbdUtzU7oLAx25dImNOsv/vzPEdJgDRqSkZ +ID/i/tBkSL2+a0bHdG5X741PjaCPpFKUjuSD15fTKc4zZl8mkgm+Q2tXbG8XaI3 X-Gm-Gg: AR+sD12YUuSPzUHOh8GzaO0wDnjDLT/1DlW/+JU/GEAi/xd2GClmP4EhVQMM/SD6fOh J53M7sifvUVPihxA/rXJ8dh/ouvkBOQFhY+7QY5B+KuhhKCFeLoN8db6wfRoOmITxITXo2n1Fv5 6FUOlYgpeDIK7vaTmpvyJ92auooA1H1/rpOjOlUvF3GTN2/23AuT4YNFOXP7OnpgNRwCCddOt9j jO+tPQUarDXzHr/Rx23zdJqYg95zSXMECKTrM2Emc3xW+mycbhKi5CK1nXA1pNAlzZ6b0Yz0j0e 04U+bjKewe6q7k1uWKwl9dqPqH5x+HWUo0JMDnlJwrN+3ZGFvF4Iwj5B6lF6/JK23H+yWci7QhF Gou7CBNFzh9newKv2Rc6O2sXNGRyY0bUsY4NohMusfOl6EnbHI9bK6K8Jo91wQuX/+/uzFt7zV1 n42czxb9D7g/ei6Tfqf1vViQ6MH87vDijTBUhP+BzIOwpLfIuOC1hm+A5KzDZwDkQB2YwuR98KD WYlQkTRX5WN/Zk= X-Received: by 2002:a17:90b:3f43:b0:37c:6130:7a5b with SMTP id 98e67ed59e1d1-3903c54302bmr34532833a91.8.1786236659816; Sat, 08 Aug 2026 17:50:59 -0700 (PDT) Received: from smtpclient.apple ([67.174.194.227]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-315bec68468sm26684762eec.31.2026.08.08.17.50.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Aug 2026 17:50:59 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_9875E8C1-0683-4C87-9D37-BDACD606624E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Message-Id: <72457768-A36E-4BA6-993F-0EC29061783C@gmail.com> Date: Sat, 8 Aug 2026 17:50:48 -0700 To: draft-ietf-netconf-yang-notifications-versioning.all@ietf.org X-Mailer: Apple Mail (2.3864.600.51.1.1) Message-ID-Hash: BFOHXN736U7C4R3554EQJYS6QSSDZFSN X-Message-ID-Hash: BFOHXN736U7C4R3554EQJYS6QSSDZFSN X-MailFrom: mjethanandani@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: NETCONF WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_AD_review_of_draft-ietf-netconf-yang-notifications-v?= =?utf-8?q?ersioning-14?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_9875E8C1-0683-4C87-9D37-BDACD606624E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Authors, Thank you for working on this document. I would like to thank the = Shepherd, Mohit, for championing the document through the publication = process; thanks to Gabriele for their OPSDIR review, and Robert Wills = for his YANG Doctors review. I have a MAJOR and a few MINOR/NIT level = comments, all of which I hope will go towards improving the document. MAJOR: Section 2 / Section 7, behavior when a Configured Subscription's = revision or version constraint stops being satisfiable after the subscription is = already established: 204 The YANG-Push Publisher MUST NOT send Notifications if the = 'revision' 205 or 'version' of the YANG module name in the Subscription = policy 206 configuration does not match with the YANG library [RFC8525]. This is the only text in the document that addresses what happens once a Configured Subscription's constraint is violated outside of the establish/modify-subscription RPCs - e.g., a device reboots into a new = YANG library that no longer offers the revision or version the subscription = was configured for. Andy Bierman raised exactly this scenario in WG Last = Call (2025-12-09): module version constraints are fine to check when the subscription is configured, "but not OK after a reboot and the YANG = library changes," since no 'subscription-started' notification is sent on reboot = and the server just disables the subscription. Rob Wilton made essentially = the same point in his review of -10, flagging as a moderate issue that the document needed to define "expected behavior when configured = subscriptions cannot match specified module revisions/versions," particularly after a software upgrade. I don't see either concern resolved in -14 - the "MUST = NOT send Notifications" sentence is still the only relevant text, and it = doesn't say what state the subscription is left in or how the Receiver would = ever learn why data stopped arriving. This matters because RFC 8641 already establishes the pattern for this = kind of situation: when a Configured Subscription can no longer be satisfied = (there, because of a change in access-control), the publisher suspends it and = sends 'subscription-suspended' with a reason identity, rather than just going = quiet. The three identities this document defines (revision-unsupported, version-unsupported, incompatible-revision-and-version) are scoped only = to 'establish-subscription-error' and 'modify-subscription-error': 1052 identity revision-unsupported { 1053 base sn:establish-subscription-error; 1054 base sn:modify-subscription-error; They don't derive from 'subscription-suspended-reason' or 'subscription-terminated-reason' the way RFC 8639's own 'insufficient-resources' identity derives from both the RPC-error bases = and 'subscription-suspended-reason' to cover exactly this dual use. As = written, these identities can only ever appear in an RPC error at = establish/modify time, never as the reason a live Configured Subscription went silent. = I'd ask the authors to specify what happens to an established Configured = Subscription when a schema change makes its revision/version constraint unsatisfiable = - whether that's suspension with a reason (extending the identity bases accordingly), termination, or something else - rather than leaving "MUST = NOT send Notifications" as the last word on it. MINOR: Section 9, Security Considerations: 1336 9. Security Considerations 1337 1338 This section uses the template described in Section 3.7.1 of 1339 [RFC9907]. ... 1353 There are a number of data nodes defined in this YANG module = that are 1354 writable/creatable/deletable (i.e., "config true", which is = the 1355 default). All writable data nodes are likely to be = reasonably 1356 sensitive or vulnerable in some network environments. Write 1357 operations (e.g., edit-config) and delete operations to these = data 1358 nodes without proper protection or authentication can have a = negative 1359 effect on network operations. The following subtrees and = data nodes 1360 have particular sensitivities/vulnerabilities: The document says it follows the RFC 9907 Section 3.7.1 template but = only fills in the writable-nodes part of it. The template has two more parts: readable data nodes that are sensitive (or an explicit "there are no particularly sensitive readable data nodes" if none), and RPC/action operations that could be harmful (or the equivalent explicit "none" = statement). Neither appears here. This module doesn't define any RPCs of its own, = and none of its readable-only nodes look sensitive to me either, but the = template asks for that conclusion to be stated, not left implicit. RFC 9907 gives = the exact fallback sentences to use for the empty cases; I'd just ask the = authors to add them. =E2=80=94=E2=80=94 The imported 'ietf-yang-revisions' and 'ietf-yang-semver' modules' = reference substatements cite older draft revisions than the bibliography does: 967 import ietf-yang-revisions { 968 prefix rev; 969 reference 970 "RFC YYYY: draft-ietf-netmod-yang-module-versioning-13, 971 Updated YANG Module Revision Handling"; 972 } = s/draft-ietf-netmod-yang-module-versioning-13/draft-ietf-netmod-yang-modul= e-versioning-17/ 979 import ietf-yang-semver { 980 prefix ysv; 981 reference 982 "RFC ZZZZ: draft-ietf-netmod-yang-semver-23, YANG = Semantic 983 Versioning"; 984 } The bibliography (Section 11.1) cites -17 and -26 respectively (and = -semver is actually at -28 now). These reference substatements inside the module = text weren't updated when the bibliography was.=20 --- I'd am going to ask for a fresh YANG Doctors look before IETF Last Call. = The existing YANGDOCTORS early review (Robert Wills, 2025-11-19) was against = -09, and the module has been restructured materially since then - the discovery mechanism moved from a top-level 'feature' statement to a = plain boolean leaf under ietf-system-capabilities, and the revision/version selection moved from two separate optional leafs to a 'choice'. Those = are exactly the kind of structural changes a YANG Doctor should get a fresh = look at, even though the earlier review was otherwise clean. NIT: Section 5.2, yang-push-module-version-notif grouping - inconsistent = explicit 'config false': 1120 leaf name { 1121 type yang:yang-identifier; 1122 config false; 1123 mandatory true; ... 1127 leaf revision { 1128 type rev:revision-date; 1129 config false; 1130 mandatory true; ... 1135 leaf version { 1136 type ysv:version; 1137 description 'name' and 'revision' state 'config false;' explicitly; 'version' = doesn't, though it inherits config false anyway from the enclosing list (which = does declare it). Not a bug, just inconsistent - either drop the two = redundant statements or add the third for consistency. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_9875E8C1-0683-4C87-9D37-BDACD606624E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Authors,

Thank you = for working on this document. I would like to thank the Shepherd, Mohit, = for championing the document through the publication process; thanks to = Gabriele for their OPSDIR review, and Robert Wills for his YANG Doctors = review. I have a MAJOR and a few MINOR/NIT level comments, all of = which I hope will go towards improving the = document.

MAJOR:

Se= ction 2 / Section 7, behavior when a Configured Subscription's revision = or
version constraint stops being satisfiable after the = subscription is = already
established:

204   =      The YANG-Push Publisher MUST NOT send Notifications = if the 'revision'
205        or 'version' = of the YANG module name in the Subscription policy
206   =      configuration does not match with the YANG library = [RFC8525].

This is the only text in the = document that addresses what happens once a
Configured = Subscription's constraint is violated outside of = the
establish/modify-subscription RPCs - e.g., a device = reboots into a new YANG
library that no longer offers the = revision or version the subscription was
configured for. Andy = Bierman raised exactly this scenario in WG Last = Call
(2025-12-09): module version constraints are fine to = check when the
subscription is configured, "but not OK after a = reboot and the YANG library
changes," since no = 'subscription-started' notification is sent on reboot and
the = server just disables the subscription. Rob Wilton made essentially = the
same point in his review of -10, flagging as a moderate = issue that the
document needed to define "expected behavior = when configured subscriptions
cannot match specified module = revisions/versions," particularly after a
software upgrade. I = don't see either concern resolved in -14 - the "MUST NOT
send = Notifications" sentence is still the only relevant text, and it = doesn't
say what state the subscription is left in or how the = Receiver would ever
learn why data stopped = arriving.

This matters because RFC 8641 already = establishes the pattern for this kind of
situation: when a = Configured Subscription can no longer be satisfied = (there,
because of a change in access-control), the publisher = suspends it and sends
'subscription-suspended' with a reason = identity, rather than just going quiet.
The three identities = this document defines = (revision-unsupported,
version-unsupported, = incompatible-revision-and-version) are scoped only = to
'establish-subscription-error' and = 'modify-subscription-error':

1052     =   identity revision-unsupported {
1053     =     base sn:establish-subscription-error;
1054 =         base = sn:modify-subscription-error;

They don't derive = from 'subscription-suspended-reason' = or
'subscription-terminated-reason' the way RFC 8639's = own
'insufficient-resources' identity derives from both the = RPC-error bases and
'subscription-suspended-reason' to cover = exactly this dual use. As written,
these identities can only = ever appear in an RPC error at establish/modify
time, never as = the reason a live Configured Subscription went silent. I'd = ask
the authors to specify what happens to an established = Configured Subscription
when a schema change makes its = revision/version constraint unsatisfiable -
whether that's = suspension with a reason (extending the identity = bases
accordingly), termination, or something else - rather = than leaving "MUST NOT
send Notifications" as the last word on = it.

MINOR:

Section = 9, Security Considerations:

1336   =  9.  Security Considerations
1337
1338 =       This section uses the template described in Section = 3.7.1 of
1339       = [RFC9907].
...
1353       There are a = number of data nodes defined in this YANG module that are
1354 =       writable/creatable/deletable (i.e., "config true", = which is the
1355       default).  All = writable data nodes are likely to be reasonably
1356   =     sensitive or vulnerable in some network environments. =  Write
1357       operations (e.g., = edit-config) and delete operations to these data
1358   =     nodes without proper protection or authentication can have = a negative
1359       effect on network = operations.  The following subtrees and data nodes
1360 =       have particular = sensitivities/vulnerabilities:

The document = says it follows the RFC 9907 Section 3.7.1 template but = only
fills in the writable-nodes part of it. The template has = two more parts:
readable data nodes that are sensitive (or an = explicit "there are no
particularly sensitive readable data = nodes" if none), and RPC/action
operations that could be = harmful (or the equivalent explicit "none" statement).
Neither = appears here. This module doesn't define any RPCs of its own, = and
none of its readable-only nodes look sensitive to me = either, but the template
asks for that conclusion to be = stated, not left implicit. RFC 9907 gives the
exact fallback = sentences to use for the empty cases; I'd just ask the = authors
to add = them.

=E2=80=94=E2=80=94

The imported 'ietf-yang-revisions' and 'ietf-yang-semver' = modules' reference
substatements cite older draft revisions = than the bibliography does:

967     =    import ietf-yang-revisions {
968     =      prefix rev;
969       =    reference
970           =  "RFC YYYY: = draft-ietf-netmod-yang-module-versioning-13,
971     =        Updated YANG Module Revision = Handling";
972       =  }

s/draft-ietf-netmod-yang-module-versionin= g-13/draft-ietf-netmod-yang-module-versioning-17/

979        import ietf-yang-semver {
980 =          prefix ysv;
981   =        reference
982       =      "RFC ZZZZ: draft-ietf-netmod-yang-semver-23, YANG = Semantic
983           =  Versioning";
984       =  }

The bibliography (Section 11.1) cites = -17 and -26 respectively (and -semver is
actually at -28 now). = These reference substatements inside the module text
weren't = updated when the bibliography = was. 

---

I'd am = going to ask for a fresh YANG Doctors look before IETF Last Call. = The
existing YANGDOCTORS early review (Robert Wills, = 2025-11-19) was against -09,
and the module has been = restructured materially since then - the
discovery mechanism = moved from a top-level 'feature' statement to a plain
boolean = leaf under ietf-system-capabilities, and the = revision/version
selection moved from two separate optional = leafs to a 'choice'. Those are
exactly the kind of structural = changes a YANG Doctor should get a fresh look
at, even though = the earlier review was otherwise = clean.

NIT:

S= ection 5.2, yang-push-module-version-notif grouping - inconsistent = explicit
'config false':

1120   =     leaf name {
1121         = type yang:yang-identifier;
1122         = config false;
1123         mandatory = true;
...
1127       leaf revision = {
1128         type = rev:revision-date;
1129         config = false;
1130         mandatory = true;
...
1135       leaf version = {
1136         type = ysv:version;
1137         = description

'name' and 'revision' state 'config = false;' explicitly; 'version' doesn't,
though it inherits = config false anyway from the enclosing list (which = does
declare it). Not a bug, just inconsistent - either drop = the two redundant
statements or add the third for = consistency.

Thanks.

Mahesh = Jethanandani
mjethanandani@gmail.com

<= br class=3D"Apple-interchange-newline">




= --Apple-Mail=_9875E8C1-0683-4C87-9D37-BDACD606624E--