Re: [netconf] Mirja Kühlewind's No Objection on draft-ietf-netconf-yang-push-22: (with COMMENT)

["Alexander Clemm" <[e-mail]>]

Hello Mirja, 
Thank you for your review!
Response inline, <ALEX>
--- Alex

-----Original Message-----
From: Mirja Kühlewind via Datatracker <[e-mail]> 
Sent: Tuesday, April 30, 2019 7:46 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Kent Watsen <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Mirja Kühlewind's No Objection on draft-ietf-netconf-yang-push-22: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netconf-yang-push-22: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

<ALEX> 
Your comment is implied by the fact that the solution builds on subscribed-notifications, which spells this out very clearly (e.g. in section 1.3 there).  To make it clearer, we can add the following text to address your concern:
"The solution builds on <xref target=""I-D.draft-ietf-netconf-subscribed-notifications"/>.  As defined there, any loss of underlying transport connection will be detected and result in subscription termination (in case of dynamic subscriptions) or suspension (in case of configured subscriptions), ensuring that situations will not occur in which the loss of update notifications would go unnoticed."
</ALEX>