[OPS-DIR]Re: draft-ietf-netconf-notif-envelope-03 early Opsdir review

[[e-mail]]

Dear Joe,

On behalf of the authors. Apologies for late reply. Thanks a lot for the review and feedback. 

We have merged your input as following: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-notif-envelope-03&url_2=https://raw.githubusercontent.com/network-analytics/draft-ahuang-netconf-notif-yang/refs/heads/master/draft-ietf-netconf-notif-envelope-04.txt

See inline below some comments.

Please let us know wherever we addressed your comments.

Best wishes
Thomas

-----Original Message-----
From: Joe Clarke via Datatracker <[e-mail]> 
Sent: Wednesday, October 22, 2025 4:13 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: draft-ietf-netconf-notif-envelope-03 early Opsdir review


Be aware: This is an external email.



Document: draft-ietf-netconf-notif-envelope
Title: Extensible YANG Model for YANG-Push Notifications
Reviewer: Joe Clarke
Review result: Has Issues

I have been asked to review this document on behalf of the OPS directorate.
This document specifies a new envelope header for YANG notifications that can be extended with richer metadata beyond eventTime and used in other encodings.
The document is well-written and easy to follow.  As such, I found it easy to spot what I feel are two points to discuss.  I hesitated to mark this "has issues".  I really wanted a DISCUSS-like option just so I could get some authors' and WG members thoughts.

1. I appreciate your Operational Considerations concerning a mix of "new" and "old" collectors.  However, since the knob to control this new envelope is network element-wide, I feel something should be said in this section that separating collectors MUST be done at a network element level.  But that begs the question, why?  Why can't this be controlled at a subscription level?  I'm sure it was considered, but I don't recall seeing text that explained why this was a sub-optimal choice.

TG> Thats a long story which goes back to the origin of RFC 8639, backward compatibility to RFC 5277 (https://datatracker.ietf.org/doc/html/rfc8639#section-1.4) in terms of xml header, the motivation of this document and subsequently many discussions on that subject in the working group on how to enable and disable. We added some editorial comment to reflect that discussion. Speaking as a YANG-Push implementor, having one schema language describing the notification header AND the subscribed content is simpler than having two schemas, XST for the header and YANG for the subscribed content. 

2. MINOR: As it stands, it makes sense that all subscriptions would be terminated when toggling `enable-notification-envelope`, but would it possibly less astonishing to operators that toggle this if implementors force all subscriptions to already be terminated for the config to be accepted?  Baring that, I would strongly recommend you add the text about subscriptions being terminated to the description of this boolean in the YANG module.  And also, see #1 as to why this can't be done more gracefully at a per-subscription or per client level.

Finally, one nit:

Section 1.1: s/messsage/message/