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

"Alexander Clemm" <ludwig@clemm.org> Tue, 30 April 2019 16:20 UTC

Return-Path: <ludwig@clemm.org>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5FF1202DF; Tue, 30 Apr 2019 09:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p5NpI8exG2A; Tue, 30 Apr 2019 09:20:55 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926961202CC; Tue, 30 Apr 2019 09:20:55 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LtH6j-1gcB761oHD-012qQK; Tue, 30 Apr 2019 18:20:47 +0200
From: "Alexander Clemm" <ludwig@clemm.org>
To: =?utf-8?Q?'Mirja_K=C3=BChlewind'?= <ietf@kuehlewind.net>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-netconf-yang-push@ietf.org>, "'Kent Watsen'" <kent+ietf@watsen.net>, <netconf-chairs@ietf.org>, <netconf@ietf.org>
References: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com>
In-Reply-To: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com>
Date: Tue, 30 Apr 2019 09:20:45 -0700
Message-ID: <03da01d4ff70$ac029f20$0407dd60$@clemm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJLjYSl5UyY4DNo/EqwcNAwrUcmOaVnxaVA
Content-Language: en-us
X-Provags-ID: V03:K1:KJ4VRkQTIP/uTqSlEYjKBQA2pGmF/I5aIGlbCCHJBb5Kgvkaq0w qy4SHhRndxlbFctYUeLKKifAaJKN6Mixt+8oY37mUdh4VyVmjLg4pK6RZuVLiYuY8jDW4uB eP6hQfLy2FZoqdsok7iDTRhYAmwPAKYGFFtqK4GHXyudHEYExn2UiwyJV8hxFKSrAAjUg4l foausNVZWpD4JXDQjqOng==
X-UI-Out-Filterresults: notjunk:1;V03:K0:kNtfRAw7voQ=:pHRhRE5Zm2NKdpD4cds9t6 6eZEECU/ClhxNNF8M0bLdR5Eq/FkdfSdBc4faT9v9BlrSTehK+AYHHUaURxLRG7ZN0+U3fKgN lYPKjKlD4Kqw3/AWCCHZocu0QefwAXn5OPIFesPdmERNacGQ0MrJrKgHnfT2KSlc4U2IeY9iv /2kQ7XEmgQgYA2YfCh+OK4STdBnUBEhSigydx+oMHFCCm0L4uE8btrWR63kBqTMaSgGahe+Yh gdD1Fdvm66kzqNVZlxu/uL82AyGbr8jsArpIs8Q+qow8cRfAp0TDURGzS6Vut706A4WMHzYqn 651fSJzyvu9IwXiA5x0x4TELOmKjsYb9Gj2EeLyHASPXg4WfwP0i1khfIcCmBUgT0koDLjQqX nQYii2mJubicc7TElq31Xj//yl1CuEiIVXZ3R4d5x5lv/mtjrFKc3B5OlWJfwNYV7ltyRCAi4 DDmFI5j1zywSa72mmkHx20SQIFijQX+0GZL67oFVbKKkwKHVep0+qffSkGdeyATGFpIDJrG/x TtUpHlYvrqlPIR5NB63oDnGyuFma7jsYFm74BvXr9TubrnFaA4BYOovPFzZQcN4hHqrCr4vus a9Cf5uP8GsQEfkKHwcUm0C1nYxYncngKDffV5TnZlu0v6kCYG1gTrRYIg4ZFnF638MxK9xXGW f+fU93tcWVW7gi8pnR+pK22llp7qD6EJdPU+1uX5ZTcxPbez60HTT397Zz9iayRsWnZeQyDZt l+aOHbXA/399QeFn1vm/C/743l8GQtL5UXO/oP7LICk+HQqqP3FzkCe3P7Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/AIIzBfUkFri3FvgYKrZfAaUylAk>
Subject: Re: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-yang-push-22=3A_=28with_COMMENT=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2019 16:20:59 -0000

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

-----Original Message-----
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>; 
Sent: Tuesday, April 30, 2019 7:46 AM
To: The IESG <iesg@ietf.org>;
Cc: draft-ietf-netconf-yang-push@ietf.org; Kent Watsen <kent+ietf@watsen.net>;; netconf-chairs@ietf.org; kent+ietf@watsen.net; netconf@ietf.org
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>