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

Mirja Kühlewind via Datatracker <noreply@ietf.org> Tue, 30 April 2019 14:45 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B31E712004E; Tue, 30 Apr 2019 07:45:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= <noreply@ietf.org>
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
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Message-ID: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com>
Date: Tue, 30 Apr 2019 07:45:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/wEbY_yWcRSTjFxDrOrpbSZY4u0w>
Subject: [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
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 14:45:37 -0000

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:


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.