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

Mirja Kuehlewind <> Tue, 30 April 2019 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6812112025E; Tue, 30 Apr 2019 09:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ekuvzK1gh2hW; Tue, 30 Apr 2019 09:32:25 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59C2C1200B4; Tue, 30 Apr 2019 09:32:25 -0700 (PDT)
Received: from ([2001:16b8:2c3e:9600:bdad:822f:cb19:daa6]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hLVg4-0000Bo-IO; Tue, 30 Apr 2019 18:32:20 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind <>
In-Reply-To: <03da01d4ff70$ac029f20$0407dd60$>
Date: Tue, 30 Apr 2019 18:32:19 +0200
Cc: The IESG <>,,, Kent Watsen <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <03da01d4ff70$ac029f20$0407dd60$>
To: Alexander Clemm <>
X-Mailer: Apple Mail (2.3445.104.8)
X-HE-SMSGID: 1hLVg4-0000Bo-IO
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Apr 2019 16:32:28 -0000

Hi Alex,

Thanks for double-checking! I guess that should be fine. However, stating this explicitly in the draft, can hurt. Your take!


> On 30. Apr 2019, at 18:20, Alexander Clemm <> wrote:
> Hello Mirja, 
> Thank you for your review!
> Response inline, <ALEX>
> --- Alex
> -----Original Message-----
> From: Mirja Kühlewind via Datatracker <> 
> Sent: Tuesday, April 30, 2019 7:46 AM
> To: The IESG <>
> Cc:; Kent Watsen <>et>;;;
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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>