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