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 <[email protected]>
> > Sent: Friday, April 9, 2021 9:53 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>
> > Cc: Rob Wilton (rwilton) <[email protected]>; [email protected]
> > 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 <[email protected]>
> > > > Sent: Friday, April 9, 2021 9:39 AM
> > > > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>
> > > > Cc: Rob Wilton (rwilton) <[email protected]>; [email protected]
> > > > 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to