Re: [netconf] Adoption poll for draft-tgraf-netconf-yang-notifications-versioning

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

I think that it would be helpful to decouple the discussion about whether the YANG version number should be changed to the NETMOD WGLC review of the module versioning draft.  I don't think that part of the discussion is particularly relevant to the adoption call for this document.

My understanding of the goal here is to make it easier to export network device telemetry data (exposed via YANG push) in a way that can integrate well with message bus services like Kafka.  I think that this is a good aim for the industry, and thus I support efforts (like this draft) to try and achieve this.

I'm not intimately familiar with Kafka but I understand that it assumes that schema for the data being published can changed over time (e.g., perhaps due to a software upgrade on a publisher, or different instances of publishers running slightly different versions of software).  Hence Kafka maintains a schema registry and allows a reference to the schema to be associated with the published data records.  This allows entities in the data pipeline to check and confirm that the telemetry data conforms to the schema, and potentially to handle the data differently, if needed.

I appreciate that RFC 6020 and RFC 7950 both are defined to try and ensure that YANG definitions only evolve in a backwards compatible way, but I see many examples within the wider industry and some examples in standards bodies where definitions are changed in ways that may impact clients. 

Hence, I think that this problem space, and draft, is about how to easily/robustly connect YANG data sources into Kafka data buses:
- one choice is to do this entirely off the box, having the entities managing the subscriptions also tracking changes to the device schema (e.g., through subscribing to YANG library updates).  Perhaps this can be made to work, but probably adds additional timing complexity relating to when the subscriptions actually start sending data relative to receiving notifications that the content in YANG library has changed.  Another choice here could be to always tear down all subscriptions if the device schema changes at all.
- the alternative is to augment the subscription-started/modified notifications to give an indication that the data for that subscription has changed.  All data sent before this notification uses a previous schema, and all data sent after that notification uses the new schema.  This allows the schema to change without completely tearing down existing subscriptions.

I'm less sure about the ability to restrict subscription requests to particular versions.  At a minimum I would suggest putting this under a feature statement, but I'm not quite sure whether it should be needed at all.

I also agree with Andy's comment that we need to resolve how the revision-date/label applies to all the potential data under a subscription.  To reuse part of Andy's example:

   <A:top>
      <B:list1 />
         <C:container1 />
   <A:top>

If the subscription is to B/list1, but during upgrade the only change was to the contents of C:container1 then for the subscription the revision-date/label for B:list1 wouldn't have changed, but the data received in the subscription would have changed.  I.e., at the moment, YANG has no way to version everything under a subscription.  Hence, I think that the notification would need to list all the module versions that are being used by the subscription, but I'm not convinced that is easy to do in practice.  The alternative would be to just version the entire schema of the datastore (e.g., either a YANG library checksum, or a version label for a YANG package instance that represents the datastore schema), but this has the downside that all subscriptions would see a reported change in schema if any single module is changed on the device, even one that isn't being used (directly or indirectly) by the subscription.  But then an off-device tool can figure out if the actual schema for the subscription has changed.

In summary, I support NETCONF working in this space, and I believe that this draft is a reasonable starting point, but it still requires some refinement, which could be done as part of the WG work on this problem.

Rob

// As an individual contributor.


> -----Original Message-----
> From: netconf <[e-mail]> On Behalf Of Jürgen Schönwälder
> Sent: 22 May 2023 19:25
> To: Camilo Cardona <[e-mail]>
> Cc: netconf <[e-mail]>; netconf-chairs <[e-mail]>
> Subject: Re: [netconf] Adoption poll for draft-tgraf-netconf-yang-notifications-
> versioning
> 
> On Mon, May 22, 2023 at 12:43:20PM -0500, Camilo Cardona wrote:
> 
> > - I like the insights shared by Jürgen and Andy regarding how hacky
> >   versioning is for YANG 1.1. It makes sense, but I guess nobody
> >   wants to start a 1.2 project..
> 
> If it is too hard to change the YANG version number, why should I
> believe it will be easy to change all the future module version
> numbers?
> 
> If people are serious about versioning, the first thing they should
> do is proposing to bump the YANG version number when they make
> incompatible changes.
> 
> /js
> 
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/>
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf