Subject: [Netconf] Yangdoctors early review of draft-ietf-netconf-yang-push-06

From: Bert Wijnen <[email-masked]>
Date: Tue, 16 May 2017 05:37:51 -0700

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?
- page 41:    

     /* YANG Parser Pyang crashing on the following syntax below

  So does the definition get skipped? Or what needs to happen here?

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?
- top of page 8 I see the words "xpath", "Xpath" and "XPath"
  is there a difference?

Nits

- 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/ ??

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 16 May 2017 20:53:57 +0000

Hi Bert,

Thanks very much for the review.  Some thoughts in-line...

> From: Bert Wijnen, May 16, 2017 8:38 AM
> 
> Reviewer: Bert Wijnen

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. 

>   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

Will remove the word YANG

> - top of page 8 I see the words "xpath", "Xpath" and "XPath"

No.  Will fix.
 
> Nits

Nice catches.  Will fix the items below.

Eric

> - you may want to check the reference/citation occurrences of [subscribe]
>      Enhancements to filters. Specifically the filter MUST at identify at
>      least one targeted yang
>    plus, you are using capitalized MUST with out reference/citation of
>    RFC2119
> - page 36:
> 
>     leaf dependency {
>       type sn:subscription-id;
>       description
>          ready to egress the publisher. In other words, there should be

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 May 2017 14:20:58 -0700

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

> 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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 16 May 2017 21:28:57 +0000

From: Andy Bierman, May 16, 2017 5:21 PM

On Tue, May 16, 2017 at 1:53 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bert,

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.

<evoit> makes sense.  The reference to RFC 6087 is a good one

<evoit> Yes.  We always are aiming with equivalence to <get>

<evoit> Over time, new filter types can be augmented in as identities.  Again, <get> equivalence is the goal.  Certainly adding them into the model here is the easy part vs dimensioning what a platform can support.

Eric

Andy

See

No.  Will fix.

Eric