Hi Bert, Thanks very much for the review. Some thoughts in-line... > From: Bert Wijnen, May 16, 2017 8:38 AM > > Reviewer: Bert Wijnen > Review result: On the Right Track > > > - last para of sect 3.5. > This seems to me to make it difficult to create interoperable > implementations. Or is there a way for a client to figure out what > is or is not support, other than tryal and error? Minimal XPATH syntax support is really a subscription independent issue. At this time, I am not aware of anyone attempting to constrain which XPATH capabilities should be the minimum set for the industry. One of the reasons is that going with a minimum common denominator for a high volume information set (like routing changes) might constrain the availability of low volume, high value filters (like configuration changes). I would very much welcome someone who wanted to attempt work in this area. As David Waltermire said to me on this topic today, it might be possible to identify a minimum XPATH filter capability set for various roles in the network element. But this is non-trivial work. For now, I am assuming any vendor will be able to articulate what the syntax capabilities are for their platforms. And they can do outside the standards arena. A good way to do this would be to pre-populate example filters in the "filters" objects. > - page 41: > > /* YANG Parser Pyang crashing on the following syntax below > > So does the definition get skipped? Or what needs to happen here? There is a coming in pyang 1.7.2 which fixes the bug... https://github.com/mbj4668/pyang/issues/300 See https://github.com/mbj4668/pyang/commit/b891cc3dd3a4547f9eddd83882e9872bc2066c6d All we need to do is await the new version. > Consistency > > - last bullet on page 7 talks about "YANG subtrees". I do not see that term > in netconf or yang documents. Those just talk about "subtrees". > Maybe I am > not looking good enough? Will remove the word YANG > - top of page 8 I see the words "xpath", "Xpath" and "XPath" > is there a difference? No. Will fix. > Nits Nice catches. Will fix the items below. Eric > - you may want to check the reference/citation occurrences of [subscribe] > at several places it points to > draft-ietf-netconf-yang-push-06#ref-subscribe > whereas I think it intends to point to the [subscribe] in the > normative references section > - first bullet on page 5: > Enhancements to filters. Specifically the filter MUST at identify at > least one targeted yang > s/at// -- the first "at" seems superfluous > plus, you are using capitalized MUST with out reference/citation of > RFC2119 > - page 36: > > leaf dependency { > type sn:subscription-id; > description > "Provides the Subscription ID of a parent subscription which > has absolute priority should that parent have push updates > ready to egress the publisher. In other words, there should be > no streaming of objects from the current subscription if of > the parent has something ready to push."; > reference > "RFC-7540, section 5.3.1"; > } > > s/if of/if/ ??