Re: [yang-doctors] Yangdoctors early review of draft-ietf-netconf-yang-push-06

[Andy Bierman <[e-mail]>]

On Tue, May 16, 2017 at 1:53 PM, Eric Voit (evoit) <[e-mail]> wrote:

> 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.
>
>

This is not going to be interoperable or easy to debug to find out what a
vendor supports.
Sec 3.5, para 3 & 4 about XPath implementations should be replaced. The
text should say a node-set result
MUST be generated or the result is the empty node-set.
Some XPath constructs SHOULD be avoided, as specified in sec 4.5 of RFC
6087.

Filters need to be well-defined so clients can actually use them.
The same syntax as a NETCONF <get> XPath filter should be used here.
New filters  should be defined if they are really needed.


Andy

> - 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/b891cc3dd3a4547f9eddd83882e987
> 2bc2066c6d
>
> 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/ ??
>
>