[netconf] draft-ietf-netconf-yang-notifications-versioning-16 ietf last call Genart review

[Christer Holmberg via Datatracker <[e-mail]>]

Document: draft-ietf-netconf-yang-notifications-versioning
Title: Support of Versioning in YANG Notifications Subscription
Reviewer: Christer Holmberg
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-netconf-yang-notifications-versioning-16
Reviewer: Christer Holmberg
Review Date: 2026-09-21
IETF LC End Date: 2026-09-29
IESG Telechat date: Not scheduled for a telechat

Summary: The document is easy to read, but I do have some issues (technical and
editorial) that I'd like the authors to address. Some of them may be because I
am not a YANG expert :)

Major issues:

N/A

Minor issues:

GENERAL:
=======

Q1:

In the text, it is unclear whether a change in the semantic version necessarily
requires a change in the revision date.

For example, the text in Section 2 says:

“The YANG-Push Publisher MUST send a subscription-terminated notification if
the ‘revision’ or ‘version’ of the YANG module name in the Subscription policy
configuration no longer matches with the YANG library…”

The use of “or” indicates that a mismatch in either the revision or the version
is sufficient to terminate the subscription. However, it is unclear whether the
semantic version may change while the revision date remains unchanged, or
whether the two values must always change together.

Elsewhere, the text refers to changes in the “revision” AND “version”. Please
clarify the relationship between these values and specify which change
combinations are valid.

----

Q2:

The document uses both “Subscriber” and “Receiver”. Is the reason that these
may be separate entities? E.g., that a Subscriber may create a subscription on
behalf of another entity (Receiver) that then receives the notifications?

If the Subscriber and Receiver are always the SAME entities, would it be
possible to use e.g., only Subscriber? If they can be different entities,
perhaps that should be explicitly clarified.

----

Q3:

The text in Section 2 says:

“The YANG-Push Publisher MUST send a subscription-terminated notification if
the ‘revision’ or ‘version’ of the YANG module name in the Subscription policy
configuration no longer matches with the YANG library [RFC8525] after reboot of
the network node.”

The text in Section 7 says:

“Since this document proposes YANG version and revision extensions in
Subscription configuration and state change notifications, it is expected that
changes in YANG version and revision of a Subscription during Subscription
lifecycle accounts for changes in Subscription policy and therefore MUST
trigger ‘subscription-modified’ Subscription state change Notifications.”

If I understand this correctly, the Publisher behavior differs depending on
whether the mismatch is detected after a reboot or during the subscription
lifecycle? After a reboot subscription-terminated is sent. During the
subscription lifecycle a subscription-modified is sent.

If my understanding is correctly, I think it needs to be more clear, e.g., by
describing the reboot procedure in Section 7.

----

SECTION 1:
==========

Q5:

The text in Section 1 says:

“Hence, when a network node is upgraded, the subscribed YANG module revision
may have changed, and might consequently break the data processing pipeline
since the YANG-Push Receiver may not be aware of this change.”

Is there a reason why the semantic version is not mentioned here? If a semantic
version can change independently of the revision date, the text should include
both values. If a semantic-version change always implies a revision-date
change, this should be clearly defined.

----

SECTION 2:
==========

Q6:

The text in Section 2 says:

“revision: Restricts the Subscription to a specific YANG module revision.
Example: ‘2014-05-08’.”

“version: Restricts the Subscription to the latest compatible YANG module
semantic version referenced to. Example: ‘2.0.0’.”

The meaning of “latest compatible” is unclear. In the example, does 2.0.0 mean
that the Subscription is restricted to exactly version 2.0.0 or that any
version compatible with 2.0.0 is allowed?

----

Nits/editorial comments:

GENERAL:
========

Q4:

The document uses inconsistent terminology, e.g.,: “YANG version”; “YANG module
version”; and “YANG module semantic version”.

The same applies to “revision” and “revision date”.

Please use consistent terminology.

For example, the text in Section 1 says:

“a subscriber cannot constrain the supported YANG module revision or version
and is not notified when the YANG module revision or version associated with
the YANG-Push Subscription changes”

Perhaps this could be changed to:

“a Subscriber cannot constrain the supported YANG module revision date or
semantic version and is not notified when the YANG module revision date or
semantic version associated with the YANG-Push Subscription changes”