[secdir] Secdir last call review of draft-ietf-netconf-yang-push-22
Takeshi Takahashi via Datatracker <firstname.lastname@example.org> Wed, 10 April 2019 07:13 UTC
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)
Content-Type: text/plain; charset="utf-8"
From: Takeshi Takahashi via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Reply-To: Takeshi Takahashi <firstname.lastname@example.org>
Date: Wed, 10 Apr 2019 00:13:34 -0700
Subject: [secdir] Secdir last call review of draft-ietf-netconf-yang-push-22
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:firstname.lastname@example.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.
- [secdir] Secdir last call review of draft-ietf-... Takeshi Takahashi via Datatracker
- Re: [secdir] [netconf] Secdir last call review ... Alexander Clemm