Dear Christer, Many thanks for the review. We have addressed all your comments as following:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-yang-notifications-versioning-17 See inline below answers to your clarification questions. Best wishes Thomas -----Original Message----- From: Christer Holmberg via Datatracker <[email protected]> Sent: Monday, September 21, 2026 7:50 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-netconf-yang-notifications-versioning-16 ietf last call Genart review Be aware: This is an external email. 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. TG> With https://datatracker.ietf.org/doc/html/rfc7950#section-7.1.9 revision was introduced which uniquely identifies a YANG module. With https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-28#section-4.2 the version statement, not to be confused with revision, is newly introduced for semantic versioning. Allowing the module designer to declare wherever a new version is backward compatible or not. Prior, in YANG 1.1 defined RFC 7950, all YANG revisions MUST be backward compatible. ---- 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. TG> As described in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning#section-1.1, the term receiver is coming from YANG-Push RFC 8639 and is indeed the system component which receives from the Publisher (that the network node) the Notifications. Where Subscriber is coming from the NMDA datastore concept is the system component configuring the subscription. With dynamic subscription, the subscriber and the receiver are indeed usually the same system components but different software routines. Where on configured subscription, these are two different software component (configuration orchestration vs. data collection). ---- 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. TG> Good catch. Andy and Saumya already caught this as well and we are discussing in https://mailarchive.ietf.org/arch/msg/netconf/U12FZi3-kfkuuBLe7zIJTABd8wE/. We ended up by removing "after reboot of the network node" to be compliant with https://datatracker.ietf.org/doc/html/rfc8639#section-2.5.1 ---- 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. TG> Good catch. Version has been added as well. ---- 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? TG> Thats refering to semantic versioning defined in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning ---- Nits/editorial comments: GENERAL: ======== Q4: The document uses inconsistent terminology, e.g.,: "YANG version"; "YANG module version"; and "YANG module semantic version". TG> Good catch. Two occasions "YANG version" should have been "YANG module version". Corrected. "YANG version" would mean the YANG language version which is clearly not the object here. The same applies to "revision" and "revision date". TG> the term revision is used throughout the document. However the YANG node identifying revision is called revision and its typedef is revision-date, which is imported from ietf-yang-revisions.yang (draft-ietf-netmod-yang-module-versioning) to reflect that revision is in the date format as specified in https://datatracker.ietf.org/doc/html/rfc7950#section-7.1.9. 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"
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
