Ballot for draft-ietf-netconf-yang-push
Yes
No Objection
Note: This ballot was opened for revision 22 and is now closed.
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.