Re: [netmod] adoption poll for yang-versioning-reqs-02

[Martin Bjorklund <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> wrote:
> Hi Martin,
> 
> > -----Original Message-----
> > From: Martin Bjorklund <[e-mail]>
> > Sent: 20 March 2019 07:30
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
> > 
> > Hi,
> > 
> > "Rob Wilton (rwilton)" <[e-mail]> wrote:
> > > Hi Martin,
> > >
> > > Thanks for the review and comments.
> > >
> > > A couple of points:
> > >
> > > 1) Lots of models outside those published in SDOs are already not
> > > following the RFC 7950 revision rules.
> > 
> > Right, and I think that is ok.  If vendors want to break backwards
> > compatibility it
> > is up to them.  With the current rules you can have tool that detect
> > this and flags
> > it.  You can then fix the problem or release the new NBC module
> > anyway, but
> > you have been warned.
> > Customers will accept this or not.
> 
> [RW] 
> Revision-dates don't help here, and are not sufficient to indicate the
> true version history of a module when it is not chronologically
> ordered.
> 
> Vendors want a way to accurately communicate to clients how the module
> is actually being changed, in a way that is easier for them to
> understand.

If I'm at 1.0.1M and see 1.0.2M it doesn't help me much.

> > > I think that it is better to
> > > have a versioning scheme that reflects how YANG models are actually
> > > evolving rather than have all vendor and OC YANG modules either just
> > > ignoring the rules, or using clever tricks that strictly conform with
> > > the rules but go against the spirit of them (e.g. just publish an
> > > entirely new set of YANG modules for each release).  Also noting that
> > > having a scheme that allows non-backwards-compatible changes does not
> > > require that everyone uses them - IETF could continue to always
> > > publish backwards compatible modules.  The obvious alternative here is
> > > that each vendor comes up with their own versioning extension and
> > > ignores the RFC 7950 section 11 rules anyway, but I'm not sure how
> > > that really helps client<->server interop.
> > 
> > The client<->server interop will not magically work better if we allow
> > NBC
> > changes.
> [RW] 
> It helps clients understand the nature of the changes.

The draft we talk about does not mention anything about helping
clients understand the diffs, BC or not.

> I don't believe that vendors are making NBC changes to make client
> lives harder, they are trying to fix bugs and make their software
> better.  I obviously agree that it would be better to put more effort
> into producing higher quality models in the first place, but there
> will always be mistakes, particularly for vendor models that have much
> less peer review than YANG modules produced by SDOs.
> 
> 
> > 
> > > 2) I don't understand how the RFC 7950 approach of "deprecate a buggy
> > > node, and replace with a working node" really works in practice,
> > > particularly for configuration data nodes where you have two clients
> > > interacting with a server, one interacting with the old path, and
> > > another using the new path.  Perhaps there is a robust scheme that
> > > works in all cases, but it isn't obvious to me.  Historically, for CLI
> > > we just translate the CLI from old to new format and then return the
> > > new format when the running config is requested.  But that will still
> > > break an old client that doesn't understand how to read the new CLI,
> > > even if the server supports them writing via the old CLI.
> > >
> > > Even if there is a workable solution for this simple case, I suspect
> > > that there are many slightly more complicated cases that don't work
> > > (e.g. rekeying a list, changing defaults, incompatible types).
> > 
> > I fully agree.  This is difficult in the general case.  In the worst
> > case you'll have to
> > give up on backwards compatibility and only implement the new version
> > of the
> > module (I believe this is possible both with the current versioning
> > rules, and with
> > the proposed rules).
> [RW] 
> Implementing a new module and not supporting the old to fix one leaf

This is a strawman; I never recommended changing an entire module to
fix one leaf.


> has a massive impact:
>  - it breaks all clients using that module (regardless of whether they
>    were using the leaf)
>  - it forces updates to all modules that augment or depend on the old
>    module.
> 
> Say we hypothetically decide that "link-up-down-trap-enable" in RFC
> 8343 is wrong should be mandatory true.  Is the right solution here
> really to define a new "ietf-interfaces-2" YANG module and require all
> 50 or so YANG modules that augment IETF interfaces to be updated?
> 
> It seems that this would be a much more impactful change than allowing
> an NBC change to that module, and documenting that as version 2.0.0.
> 
> I am sure that if YANG allows NBC changes then some folks will use
> them for purposes that they should not.  But I also believe that those
> same folk will make those same changes regardless of what an RFC
> states.  But I also think that many vendors will try and use NBC
> changes as a way to make their models better, improve the quality of
> YANG data models.
> 
> 
> > 
> > > In short, I don't agree with the premise that the current YANG
> > > versioning schema using revision dates is working just fine, and no
> > > changes are needed.
> > 
> > But this is not what the draft is about!  There is nothing in the
> > draft that talks
> > about problems introduced by using the revision dates.
> [RW] 
> 
> I think that "revision-date" and RFC 7950 section 11 module update
> rules go hand in hand.
> 
> If your objection is that we don't quite describe the problem clearly
> enough then that can be fixed.
> 
>  My interpretation is that your objection is more fundamental than
>  that.

Yes.

>  I.e. you don't think that we should be using semantic
>  versioning at all

My objection is that I don't agree with the problem statement and I
don't think that we should allow NBC in published modules.


/martin


> , and we should keep RFC 7950 section 11 rules and
>  revision dates for versioning YANG models.  But I think that the
>  overwhelming evidence is that the current scheme does not work for
>  everyone, even if it might be sufficient for YANG modules produced in
>  the IETF.
> 
> Thanks,
> Rob
> 
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > -----Original Message-----
> > > From: netmod <[e-mail]> On Behalf Of Martin Bjorklund
> > > Sent: 19 March 2019 15:12
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
> > >
> > > Hi,
> > >
> > > I have read this document, and I do not think it should be adopted.
> > >
> > > I object to the idea that we should allow non-backwards-compatible
> > > changes to published YANG modules.
> > >
> > > The draft motivates this idea with:
> > >
> > >    we must recognize that many YANG
> > >    modules are actually generated YANG modules (for example, from
> > >    internal databases)
> > >
> > > I do not agree that we should change what we allow in published
> > > modules b/c of this.
> > >
> > > It also motivates this idea with:
> > >
> > >    The points made above lead to the logical conclusion that the
> > >    standardized YANG modules have to be perfect on day one (at least the
> > >    structure and meaning), which in turn might explain why IETF YANG
> > >    modules take so long to standardize.
> > >
> > > I disagree with this.  First of all, we have already published
> > > revision two of several YANG modules (ietf-inet-types, ietf-yang-type,
> > > ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that
> > > "standardized YANG modules have to be perfect on day one" is simply
> > > not true.
> > >
> > > Second, I don't think the upgrade rules are the reason it takes a long
> > > time to standardize IETF models (I think it has to do with the process
> > > itself, including the fact that models get reviews from many different
> > > people with different background.)  [BTW, is it true that drafts with
> > > YANG models take longer time from wg -00 to published RFC than other
> > > drafts?]
> > >
> > >
> > > This said, I think there are some important points that the draft
> > > raises, and that I think we should continue to work on; specifically
> > > 2.3, 2.5, 2.6, 2.7.  But I don't think that these areas require
> > > changes to the versioning scheme, and I think it is a mistake to
> > > include these areas in this draft.
> > >
> > > Some comments on section 4, The Problem Statement:
> > >
> > >    o  Any non-backwards-compatible change of a definition requires
> > >       either a new module name or a new path.  This has been found
> > >       costly to support in implementations, in particular on the client
> > >       side.
> > >
> > > Yes I agree there is a cost associated with this.  But I have come
> > > across vendor modules that make NBC changes w/o introducing a new
> > > path, and this is also costly to handle.
> > >
> > >    o  Since non-backwards-compatible changes require either a new module
> > >       name or a new path, such changes will impact other modules that
> > >       import definitions.  In fact, with the current module versioning
> > >       scheme other modules have to opt-in in order to use the new
> > >       version.  This essentially leads to a ripple effect where a non-
> > >       backwards-compatible change of a core module causes updates on a
> > >       potentially large number of dependent modules.
> > >
> > > This is by design.  We cannot have a situation where a legal
> > > modification to a module leads to other modules becoming invalid.
> > >
> > >    o  YANG has a mechanism to mark definitions deprecated but it leaves
> > >       it open whether implementations are expected to implement
> > >       deprecated definitions and there is no way (other than trial and
> > >       error) for a client to find out whether deprecated definitions are
> > >       supported by a given implementation.
> > >
> > > As I wrote above, I agree that this is a problem that should be
> > > solved.  But this is not a motivation for changing YANG versioning.
> > >
> > >    o  YANG does not have a robust mechanism to document which data
> > >       definitions have changed and to provide guidance how
> > >       implementations should deal with the change.  While it is possible
> > >       to have this described in general description statements, having
> > >       these details embedded in general description statements does not
> > >       make this information accessible to tools.
> > >
> > > This might also be worth exploring, but this is not a motivation for
> > > changing YANG versioning.
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > Kent Watsen <[e-mail]> wrote:
> > > > Seeing as how we all need to read this draft anyways, in preparation
> > > > for our meeting in Prague, it seems like a good time for this poll.
> > > > Thusly, this email begins a 1-week adoption poll for:
> > > >
> > > >
> > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-
> > > > 02
> > > > <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs
> > > > -0
> > > > 2>
> > > >
> > > > Please voice your support or objections before March 20.
> > > >
> > > > Note that this draft defines *requirements* and its intended status
> > > > is "Informational."  I believe that it is good for WGs to formalize
> > > > requirements, even taking such drafts thru Last Call, in order to
> > > > ensure consensus on the requirements.  This is the "adoption" call,
> > > > to ascertain if the WG agrees with that statement; if adopted, a
> > > > separate "last call" will be issued to ensure to correctness of the
> > > > draft's content.
> > > >
> > > > Kent (and Lou and Joel)
> > > >
> > > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
>