Last Call Review of draft-ietf-netconf-yang-push-22
review-ietf-netconf-yang-push-22-secdir-lc-takahashi-2019-04-10-00

Request Review of draft-ietf-netconf-yang-push
Requested rev. no specific revision (document currently at 25)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-04-12
Requested 2019-03-22
Authors Alexander Clemm, Eric Voit
Draft last updated 2019-04-10
Completed reviews Secdir Early review of -00 by Takeshi Takahashi (diff)
Yangdoctors Early review of -06 by Bert Wijnen (diff)
Yangdoctors Last Call review of -15 by Martin Björklund (diff)
Yangdoctors Last Call review of -21 by Martin Björklund (diff)
Rtgdir Last Call review of -22 by Daniele Ceccarelli (diff)
Secdir Last Call review of -22 by Takeshi Takahashi (diff)
Tsvart Last Call review of -22 by Wesley Eddy (diff)
Genart Last Call review of -22 by Stewart Bryant (diff)
Assignment Reviewer Takeshi Takahashi
State Completed
Review review-ietf-netconf-yang-push-22-secdir-lc-takahashi-2019-04-10
Reviewed rev. 22 (document currently at 25)
Review result Has Nits
Review completed: 2019-04-10

Review
review-ietf-netconf-yang-push-22-secdir-lc-takahashi-2019-04-10

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.