Subscription to YANG Notifications for Datastore Updates
draft-ietf-netconf-yang-push-25

Per Section 3.7:
-- Is the re-synchronization behavior/value of patch-id different with dynamic vs. configured subscriptions, especially if the publisher crashed or lost the connection?

-- I’d recommend being explicit about the value by which patch-id gets incremented (1?) so that there won’t be ambiguity on the lost/out-of-sequence detection.

Getting a streaming telemetry for changes in datastore appears quite useful.

Please note that I did not review in depth after the section 4.

Comments
--------

C1) Out of curiosity, it is surprising for a netconf wg document to have 7 errors indicated by the YANG validator. Are they real errors or is the `pyang` validator incorrect or missing references?

C2) 7 authors... the limit is usually 5 authors max. Can you justify?

C3) section 2. It should be RFC 8174 without citing RFC 2119.

C4) section 3.7, why not forcing a resynch (and a patch-id of 0) rather than simply rolling explicitly the patch-id to 0. The latter seems to me as prone to synchronization errors.

Nits
----

N1) unsure why all Cisco Systems authors are not grouped together

N2) "Xpath": should be described (or having a reference) before first use in section 3.6

N3) a couple of "yang" in lowercase while I believe "YANG" is always written in uppercase

Also, there are some changes suggested by the YANG doctor review, which seem relevant.

I found text about YANG validation in the document shepherd's write-up, so I cleared on this point.

Thank you for addressing my Discuss points!

A small comment/question mostly regarding section 3.4:
I wondering what happens if the system crashes or is in a state where not even a notification can be sent anymore...? Is the assumption that a crash could be detected because the transport connection  goes away? However, that would mean that there is requirement that the transport must be connection-oriented and maybe also support some kind of keep-alive mechanism. Given this document tries to be transport-agnostic (as it relies on I-D.draft-ietf-netconf-subscribed-notifications), I don't think that is a safe assumption and should at least be further discussed. My understanding was that I-D.draft-ietf-netconf-subscribed-notifications assumes an active connection for dynamic subscriptions, but I guess this does not have to be the case for a configured subscription...?

Also there seems to be an implicit assumption that the chosen transport is reliable in order for the system to work as expected. If that is the case, I think that it could be good to spelled that out in the document as a requirement as well. I guess all transports available today for YANG (NETCONF/RETSCONF) are reliable but that might not be the case in future.