Subject: [Netconf] questions on draft-ietf-netconf-yang-push-00

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Dec 2015 10:22:23 -0800

Hi,

I am trying to understand the YANG Push draft.
It seems massively complicated.  Has anybody implemented
these features in a vendor module?  XPath filtering
is mandatory to implement.  JSON is optional, but JSON
is not supported by NETCONF at all so, not sure why
this YANG feature 'json' is needed.  If a RESTCONF server supports
JSON, then HTTP will make that clear to the client.

Existing NETCONF notifications allow for a shared
implementation strategy, meaning the generated events
could be stored in a common buffer, and individual subscription
filters can be applied to the buffer.  With this draft, every client
can ask for 1 or more very different event streams, making it
difficult to use a common event-store.

I cannot find the controls that cause plain updated (e.g., my-sub on pg 14)
vs. a datastore-changes (my-on-change-sub on same page).
Why should the client need different element names
(datastore-contents vs. datastore-changes-xml).  I cannot find
the controls that would cause YANG Patch formatted events to be sent.
There seem to be many ways to do the same thing, all of them
mandatory-to-implement by the server.

The notification definitions need a lot of work.
There should never be "choice XML or JSON" in a YANG module.
The YANG definition is conceptual.  Only protocol messages
between peers have any encoding at all. Also, the use of leaf
instead of anyxml (or anydata) is incorrect.

The section on reliability seems a little vague.
If a server is getting 1000 edits a second, and the client
subscribes to hourly YANG Patch updates (which all need to be applied
or the replicated datastore will be incorrect) then the server will
buffer and then send that client 3.6 million edits at once.
Seems just a bit resource-intensive to me. The impact on network
congestion could be dramatic.

Since the server might not have infinite resources, what does it
do it if it cannot buffer new edits?  Seems to me that a sequence-id
would allow the client to know there are gaps, but the draft insists
that no notifications can get dropped so a sequence-id is not needed.

If a subscription is altered in between update intervals, does
the server toss all the data it had collected and start fresh
with the new parameters?  Does the interval based on start-time
re-synch to the modify-time? (i.e., toss previous interval completely
and start a new interval?)

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Sat, 12 Dec 2015 03:48:22 +0000

Hi Andy,

thank you for your comments.  Responses inline.

Have a nice weekend
--- Alex
From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, December 11, 2015 10:22 AM
To: Netconf <[email-masked]>
Subject: [Netconf] questions on draft-ietf-netconf-yang-push-00

Hi,

<ALEX> There are a probably a number of clarifications we need to make.   We will edit the document to clarify the separation between the control model (where we configure subscriptions), and the definition how to render the updates and which transport to use (this is where the possibility of supporting different encodings come in.
There is currently an Open Daylight project in progress that provides a client implementation of this for the upcoming Beryllium release.
Making XPath optional and subtree mandator as a filter makes sense.
</ALEX>

<ALEX> For a periodic subscription, the situation is no different from regular gets.  For an on-change, you could have an implementation based on a common buffer with all changes (or all changes on subscribed subtrees).
</ALEX>

<ALEX>  I am not sure I understand this question.  Note there is a difference between periodic subscription, and on-change subscription.  For periodic, we send the datastore contents like we would for a get.  For an on-chage, we don’t send all hte contencts.  To facilitate the differentiation, we use different elements (with different semantics – periodic vs on-change).
</ALEX>

<ALEX> This has to do with separation between control model, and definition of stream contents.  The choice XML or JSON refers to a configurable option about how data streams are encoded, not how the YANG control model is represented.  We could have other options including ASN.1 BER and syslot SD (Structured Data).  We need to clarify this in the the draft.  </ALEX>

<ALEX> Note again the distinction between periodic and on-change.  For periodic, no need for buffering.  For on-change, things are sent immediately, bar dampening periods (expected to be short).  Updates in that case will include the latest value (i.e. not 3.6 million edits, unless there are 3.6 million objects that were edited; dampening periods are in fact intended to limit and reduce the number of updates that might occur over a period of time).  Buffers probably need to be dimensioned proportionally to the size of the data tree, that’s true.
</ALEX>

<ALEX> This is a corner condition which will need clarification.
</ALEX>

Andy