Early Review of draft-ietf-netconf-notif-envelope-03
review-ietf-netconf-notif-envelope-03-opsdir-early-clarke-2025-10-22-00

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.

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/