[netconf] Secdir last call review of draft-ietf-netconf-yang-push-22

Takeshi Takahashi via Datatracker <noreply@ietf.org> Wed, 10 April 2019 07:13 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 2AE0E1202BC; Wed, 10 Apr 2019 00:13:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Takeshi Takahashi via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-netconf-yang-push.all@ietf.org, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
Message-ID: <155488041402.1083.9565126428194093115@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 00:13:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/G8mBi5orP2_t9wrqNcOJW0KCXAc>
Subject: [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22
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: Wed, 10 Apr 2019 07:13:34 -0000

Reviewer: Takeshi Takahashi
Review result: Has Nits

This draft talks about push-type update notifications of YANG datastore. It
provides two types of subscriptions: periodic and on-change. I have one
comments (item 4) and four clarification questions (items 1-3) below.

1. on the on-change subscription (in sections 3.3 and 3.10)

The draft says "it will be important for client applications to have a way to
identify for which objects on-change notifications are supported and for which
ones they are not supported," but this issue is currently left to the
implementation. It would be nice if you could provide some example solutions to
this problem so that the implementers of this draft will not be confused.

When a publisher accept on-change subscription even when the scope of the
subscription contains objects for which on-change is not supported, I wonder
sending some notification message on the situation could be helpful for the
subscriber. By reading other part of the draft, I feel that the draft is indeed
recommending to implement such comprehensive notifications. If so, it had
better be clearly mentioned in this section. I also think it is not a bad idea
to define such a comprehensive notification in this draft, though it is up to
the authors.

2. on the differing dampening periods for multiple objects(in section 3)

The draft says "In case whether a subscriber wants to have separate dampening
periods for different objects, the subscriber has the option to create multiple
subscriptions with different selection filters." That is a good solution. Then
are the any other options for allowing to have separate dampening periods for
different objects? The sentence gave me the impression that there are multiple
options; so I am asking this question only for clarification.

3. imcomplete-update flag (in sections 3.11.1 and 4.3.2)

I am not sure what would be the expected actions of the subscribers when they
receive a message with incomplete-update flag on. Some navigations would be
appreciated. Meanwhile, according to section 4.3.2, a publisher MAY
subsequently send a push-update containing a full selection snapshot of
subscribed data. If such a push-update is subsequently sent, does the publisher
need to send anoter message with incomplete-update flag on prior to the
push-update with a full selection snapshot of subscribed data?

4. security considerations (in section 7)

This section enumerates four threats that are newly introduced by this draft.
Some countermeasures, or directions to address these threats, had better be
provided here.