Early Review of draft-ietf-netconf-yang-push-00
review-ietf-netconf-yang-push-00-secdir-early-takahashi-2015-10-30-00

Request Review of draft-ietf-netconf-yang-push
Requested rev. no specific revision (document currently at 25)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2015-10-30
Requested 2015-10-16
Authors Alexander Clemm, Eric Voit
Draft last updated 2015-10-30
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-00-secdir-early-takahashi-2015-10-30
Reviewed rev. 00 (document currently at 25)
Review result Has Nits
Review completed: 2015-10-30

Review
review-ietf-netconf-yang-push-00-secdir-early-takahashi-2015-10-30

Hello,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.
Document editors and WG chairs should treat these comments just like any
other last call comments.

[overall feeling on this draft]

As an early review, this document is fine.
I believe the topic is very important.

[overview]

This draft deals with the push mechanism of the YANG datastore's updats.
The usability of push mechanism is obvious.
The draft elaborates parameters needed for the mechanism, including filters
and subscription-config.

[questions]

It was fun to read the article, though I am not that familiar with this
area.

Here are several clarification questions.
I would appreciate if you could answer them to deepen my understanding.

1.
Let me assue that I send a create-subscription message with the period=500
parameter. If the server can only send updates with period=1000, what will
happen?
Is the subscription declined? Or is the subscription accepted with
period=1000?

If it is declined, how can I know the supported period value?
I guess the error response message does not explain the minimum value for
the period.

2.
I guess arbitrary value can be set for stop-time.
Then, the updates will be sent periodically for very long time, once the
subscription is accepted.
I am wondering if we need to check whether the subscriber is still alive
(whether the subscriber is still the authorized one).
Would you have any means to check the subscriber status ? (I guess no)
Or, do we need to specify stop-time that is not that far from now to avoid
any accident?

I am not sure how sensitive the update information is, so it could be a
nonsense question...

3.
Are you going to use the IANA tables for the values, such as the "encoding"
field?

4.
Regarding the security consideration, I have got the impression that the
current text focuses on DDoS scenarios.
How about the false update?
Malicious entity may send false update to the subscriber.
The false update may let the subscriber mis-judge the situation and initiate
some operations.
Is it going to be a viable concern?


Thanks, and kind regards,
Take