[netconf] Re: draft-wilton-netconf-yang-push-lite-00

[Reshad Rahman <[e-mail]>]

 Hi Rob,
Please see inline.
    On Wednesday, March 19, 2025 at 11:54:49 PM EDT, Rob Wilton (rwilton) <[e-mail]> wrote:  
 
 
Hi Reshad,
 
  
 
Thanks for the quick review and comments.

Please see inline …
 
  
 
From: Reshad Rahman <[e-mail]>
Date: Wednesday, 19 March 2025 at 20:56
To: Rob Wilton (rwilton) <[e-mail]>, NETCONF WG <[e-mail]>
Subject: draft-wilton-netconf-yang-push-lite-00
 
Hi Rob,
 
  
 
Thanks for doing this work!
 
  
 
I have taken a look at the document, not the whole doc, and your slides. Disclaimer: I haven't watched your presentation at IETF122 yet.
 
  
 
Couple of high-level questions/comments:
 
  
 
- There is no text on (the lack of) backwards compatibility with existing RFC8639/41 YP implementations.
 
  
 
These is text in section “3.4.1. RFC 8639 and RFC 8641”, which is also meant to reference “Appendix A. Functional changes between YANG Push Lite and YANG Push”, the reference is broken, so I’ve just fixed that in my local editors copy.  Please can you check whether you think this text, particularly in 3.4.1, is sufficient, or needs further clarification.
 <RR> The text in that section is pretty clear. However I think it'd be useful to have some extra text (maybe in a new section but not necessarily) illustrating e.g how a client supporting both flavours of YP should/can pick which one to use. 
  
 
The intro mentions that they can be implemented alongside each other but how does e.g. a client, which implements both, decide which to pick when subscribing to a server. Is this based on the yp-lite-capabilities in section 12.1? Do we need a new NETCONF capability?
 
  
 

No new NETCONF capability should be needed.
<RR> While the advertised YANG modules indicate what the device supports, it seems somewhat odd that a client would need to get that info from another source (e.g. doing a get from the device or reading from another client service). NC capability exchange seems to be the right fit for this.

Regards,Reshad.
The device will advertise different YANG modules (e.g. ietf-yp-lite) to indicate that it supports YP Lite.  It can also advertise support for vanilla YP as well, if desired.  As you say, the advertised capabilities will also be different between vanilla YP and YP Lite.

 
  
 
- I'm not a fan of the term yp-lite, although I understand why it was chosen. You have removed some functionality from YP, but yp-lite also has extra functionality and looking at the YANG module+tree, it does not seem to be "lite". And if someday we'd need another version of YP, would we call it "yp-liter" or "yp-not-as-lite" :-) Personally I'd go for something as boring as YPv2.
 
  
 
That is a fair comment.  My thinking and goal is to simplify aspects of Yang Push and meeting the requirements of a minimal requirements/implementation of an IETF YANG Push like telemetry protocol.

But you are completely right that we are also extending it in some ways, and maybe YPv2 would be a better name.  I’ll add an issue to track this, but possibly this would be a better discussion to have around adoption time, when we have a more complete view of what it is expected to look like.
 
  
 
Kind regards,

Rob
  
 
  
 
Regards,
 
Reshad.