Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Juergen,

Yes - it isn't obvious and we've been struggling with what to do about state. It just feels like maybe the 7950 rules were more focussed on config and it might be worthwhile adapting some of them a bit for state for this YANG Revision work we're doing.

The big one is this value space issue. It feels like expanding/reducing value space has different impacts on clients for config vs state.

I think a fairly common use case for this is bug fixes in vendor modules. And note that at least two major router vendors have separate modules for state (Nokia and Cisco).

Jason

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: Friday, April 9, 2021 10:20 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> Subject: Re: [netmod] Client validation text [was RE: YANG Versioning
> Weekly Call Minutes - 2021-04-06]
> 
> Creating lots of special rules makes me feel uncomfortable. Is there
> evidence that people reduce state value spaces a lot and in isolation,
> i.e., they just rev a module to reduce some state value spaces?
> 
> /js
> 
> On Fri, Apr 09, 2021 at 02:00:42PM +0000, Sterne, Jason (Nokia - CA/Ottawa)
> wrote:
> > The key focus here is *if* the author does remove the enum, then how
> should we label the revision -> BC or NBC ?
> >
> > RFC7950 does indeed say that is NBC.  But do we actually want that for
> state for:
> > - removing an enum
> > - shrinking a range
> > - changing a pattern in a manner that reduces the value space
> >
> > We're worried that will create too much "NBC noise" when it really in
> practice won't be an issue at all for clients.  Client just won't receive the old
> values from the larger value space anymore.  So why flag this as NBC and
> make people do work to analyze it ?
> >
> > Jason
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder <[e-mail]>
> > > Sent: Friday, April 9, 2021 9:53 AM
> > > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> > > Cc: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning
> > > Weekly Call Minutes - 2021-04-06]
> > >
> > > I do not recall that removing an enum was ever an issue in
> > > practice. If an enum value is not used anymore, you leave the old enum
> > > value and it will slowly but surely not be used anymore. (An enum
> > > statement even has a status statement, so you can deprecate or
> > > obsolete enum values.) That said, if the module owner decides to
> > > remove the value, then this is indeed non-backwards compatible. (And
> > > removing an enum paves the way to reallocate the associated number,
> > > and be it by accident later again. I suggest people think twice
> > > before removing enums.)
> > >
> > > /js
> > >
> > > On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia -
> CA/Ottawa)
> > > wrote:
> > > > Urghh.  I reversed my example.  I should have said removing an enum.
> Let
> > > me reword:
> > > >
> > > > One key example is this:  7950 says that removing an enum from an
> > > enumeration leaf is NBC (and that applies to state). But that may not
> really
> > > be how most implementations would want to treat state. Would we
> really
> > > want to flag a module as non backwards compatible when a state leaf has
> an
> > > enum removed?  Wouldn't that create a lot of unnecessary noise?
> > > >
> > > > > -----Original Message-----
> > > > > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de>
> > > > > Sent: Friday, April 9, 2021 9:39 AM
> > > > > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> > > > > Cc: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> > > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning
> > > > > Weekly Call Minutes - 2021-04-06]
> > > > >
> > > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia -
> > > CA/Ottawa)
> > > > > wrote:
> > > > >
> > > > > > One key example is this:  7950 says that adding another enum to an
> > > > > enumeration leaf is NBC (and that applies to state). But that may not
> > > really
> > > > > be how most implementations would want to treat state. Would we
> > > really
> > > > > want to flag a module as non backwards compatible when a state leaf
> > > gets an
> > > > > additional enum?  Wouldn't that create a lot of unnecessary noise?
> > > > >
> > > > > I read this in RFC 7950:
> > > > >
> > > > >    o  An "enumeration" type may have new enums added, provided
> the
> > > old
> > > > >       enums's values do not change.  Note that inserting a new enum
> > > > >       before an existing enum or reordering existing enums will result
> > > > >       in new values for the existing enums, unless they have explicit
> > > > >       values assigned to them.
> > > > >
> > > > > What do you want this to change to?
> > > > >
> > > > > /js
> > > > >
> > > > > --
> > > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > > > Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> > > > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>