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/