[netconf] AD review of draft-ietf-netconf-yang-notifications-versioning-14

[Mahesh Jethanandani <[e-mail]>]

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.

——

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-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:

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
[e-mail]