Skip to main content

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 revision 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
I-D 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
Request Last Call review on draft-ietf-netconf-yang-push by Security Area Directorate Assigned
Reviewed revision 22 (document currently at 25)
Result Has nits
Completed 2019-04-10
review-ietf-netconf-yang-push-22-secdir-lc-takahashi-2019-04-10-00
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.