Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund <[e-mail]>]

Hi,

Juergen Schoenwaelder <[e-mail]> wrote:
> Let me add that there was large disagreement what a bug fix is in the
> design team. Hence, any text that talks about 'bug fixes' is ambiguous
> and of limited value to achieve consensus. (Or we may find consensus
> but then not agree on what we have found consensus on.)
> 
> To be more concrete, I learned that Rob's notion of a bug fix is very
> different from my notion of a bug fix. I think it is important for
> having a productive discussion to be aware of this.
> 
> For me, a bug fix is rather limited, i.e., fixing something where the
> correct intention was clear but the model did not properly capture the
> intention correctly, i.e., roughly what we can do with errata in the
> IETF. I think Rob understands bug fixes in a much broader sense,
> including fixes to what essentially are in my view module design
> errors.
> 
> With my narrow definition of bug fixes, bug fixes are essentially
> backwards compatible (even if they may violate RFC 7950 rules - but as
> long as the original intention was clear, we can be flexible).

I agree with this interpretation of a bug fix.  For example
fixing incorrect patterns (e.g. errata 3957 that Andy mentioned).



/martin



> With Rob's notion of bug fixes, we have to handle them as part of the
> versioning system since they may be non-backwards compatible.
> 
> /js
> 
> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> > Hi Chris,
> > 
> > 
> > On 25/10/2018 18:42, Christian Hopps wrote:
> > > 
> > > Hi Rob,
> > > 
> > > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > > to it; however, the requirement as written does not restrict itself to
> > > fixing module definition bugs (e.g., a pattern or other value
> > > constraint) in some small but incompatible way -- instead it's wide open
> > > and it will be [ab]used that way.
> > I think that everyone on design team agrees that non-backwards-compatible
> > changes should be minimized and should really only to used for bug fixes
> > where it is anticipated that clients should not be affected.
> > 
> > We want to allow non-backwards-compatible changes at the head of the
> > development tree, but again, I think that everyone agrees that keeping it
> > backwards compatible where possible is a good goal.
> > 
> > However, I think that there will be cases where a vendor decides that it is
> > right for an enhancement or non backwards compatible change to be made to an
> > already released module.  I agree that this is highly undesirable and an
> > abuse of the rules, but I don't believe that whatever versioning scheme we
> > come up with will prevent vendors from doing this.  So then the question
> > becomes: Is it better to pretend that this scenario will never happen,
> > design the versioning scheme so that it cannot be expressed, which probably
> > just means that clients will not be able to detect when vendors do this by
> > cheating the rules!  Or is it better to accept that this will sometimes
> > occur, provide strong guidance as to why this is bad practice and should be
> > avoided, but have a versioning scheme that still allows this to be expressed
> > (in a bounded way)?  I.e. even if the vendors are doing something that is
> > less than ideal, at least the clients can spot where they have done this.
> > 
> > ---
> > 
> > A separate concern that we had about ties this strictly to bug fixes is that
> > some one will ask for a definition of a bug fix.  The design team tried this
> > but we couldn't even agree what a bug fix is, let alone agree with a single
> > definition of a bug fix as it related to a YANG module.  So our conclusion
> > was that perhaps it is better not to tie the requirements themselves to bug
> > fix vs enhancement, because the boundary between the two is too vague, and
> > module writers will bend the rules.
> > 
> > So I see that the rules should be:
> >  - backwards compatible bug fix  - this is fine.
> >  - non backwards compatible bug fix - this is fine if it is pragmatically
> > expected to not impact any clients, but careful consideration is required if
> > it might break clients.
> >  - backwards compatible enhancement - not ideal, but pragmatically OK.
> >  - non backwards compatible enhancement - this is bad and should be avoided.
> > 
> > But if we don't want to define the difference between a bug fix vs
> > enhancement then I think that you end up with the most general requirement
> > being that we do want to allow for non-backwards-compatible changes in
> > released modules to accommodate the bug fix scenario, but the expectation
> > (and guidance) will be that they should only be used for bug fixes.
> > 
> > 
> > > 
> > > For example:
> > > 
> > > > Here is what I am afraid the vendors want here: A developer on
> > > > release train X can easily change some data structure and then push
> > > > the change into an automated system which generates a new YANG
> > > > module definition and revs a version number -- all done! They don't
> > > > have to deal with the inertia of making this change in their release
> > > > train Y or Z and they don't have to treat modules as a stable API
> > > > they are exporting, b/c they now have these new wonderful versions
> > > > from this work. Meanwhile we the users now have to deal with N forks
> > > > with all the various little incompatible changes random developers
> > > > at the company wanted to make without having to coordinate with
> > > > their coworkers/other internal teams. Now multiply this by M
> > > > vendors. It's a nightmare. It shouldn't be what we are optimizing
> > > > for, let alone making a requirement.
> > > 
> > > Regarding enhancements, these are features, and are naturally
> > > augmentative. I find it hard to believe we have a pressing
> > > need/requirement to support non-backward compatible changes to existing
> > > modules in order to support enhancements.
> > I agree.  It was a backwards compatible enhancement that I was considering.
> > 
> > Thanks,
> > Rob
> > 
> > 
> > > 
> > > Thanks,
> > > Chris.
> > > 
> > > 
> > > Robert Wilton <[e-mail]> writes:
> > > 
> > > > Hi Chris,
> > > > 
> > > > I think that there are two things driving this requirement:
> > > > 
> > > > What I regard as the key one, is that we want to be able to support
> > > > the software
> > > > that we have shipped. In particular, we may need to fix bugs
> > > > (perhaps at the
> > > > operators request) to a YANG model that has already been released.
> > > > I.e. I think
> > > > that there are some scenarios, where forking a YANG module, although
> > > > undesirable
> > > > is the right thing to do to include a fix. I don't believe that
> > > > features or
> > > > deviations help solve this problem.
> > > > The two alternative solutions to being able to fix bugs, neither of
> > > > which I
> > > > think is pragmatic, that I can think of are:
> > > > (i) Vendors ensure that their YANG modules are perfect before they
> > > > ship in a
> > > > release.
> > > > (ii) If a bug is reported, operators are happy to wait until the bug
> > > > has been
> > > > fixed in the current development release, and will migrate to that
> > > > latest
> > > > release to pick up the fix.
> > > > 
> > > > The second thing driving this requirement is that vendors sometimes
> > > > get asked
> > > > for enhancements to existing releases, perhaps because the latest
> > > > development
> > > > release is too far out, or ask for an enhancement on the current
> > > > train to be
> > > > back ported to an older release.
> > > > 
> > > > So, aiming to have stable YANG modules, trying a lot harder to avoid
> > > > non-backwards-compatible changes, and keeping new functionality to
> > > > the head of
> > > > the development I completely agree with you on. But I still believe
> > > > that there
> > > > are some valid scenarios, that should be limited as much as
> > > > possible, where it
> > > > is necessary to make changes that sometimes break these rules, and
> > > > having a
> > > > limited scheme that clearly indicates where such breakages have
> > > > occurred is
> > > > probably better that the status quo of where the modules get
> > > > changed, but the
> > > > operator doesn't get any useful indication of what type of changes
> > > > are being
> > > > made.
> > > > 
> > > > Thanks,
> > > > Rob
> > > > 
> > > > 
> > > > On 25/10/2018 16:26, Christian Hopps wrote:
> > > > > 
> > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke <[e-mail]> wrote:
> > > > > > 
> > > > > > * New requirement 1.4 for supporting over-arching software releases
> > > > > [ I read this as supporting various different module versions
> > > > > based on a vendor's different software release trains. If this
> > > > > is wrong then the rest of this doesn't apply and I would just
> > > > > ask for the text to be update to clarify what it means. ]
> > > > > 
> > > > > How many operators/users have asked for this or indicated it's a
> > > > > requirement for them?
> > > > > 
> > > > > What problem is intractable without this requirement being met,
> > > > > and what is the cost of this requirement on the actual users?
> > > > > 
> > > > > I have pushed back multiple times on this b/c I believe this
> > > > > "requirement" is really being pushed to make it easier for
> > > > > vendors (a small affected group) to develop their software at
> > > > > the cost of their users (the much larger affected group) who
> > > > > would then have to deal with multiple trains of the same module.
> > > > > 
> > > > > 
> > > > > We already have features and deviations why are they not enough
> > > > > to deal with functionality that is present or not in various
> > > > > software release/devices?
> > > > > 
> > > > > FWIW I'm not against making it easier to develop software, but
> > > > > we have to be mindful if we are just pushing the cost (and
> > > > > magnifying it greatly) to other people in the community.
> > > > > 
> > > > > Thanks,
> > > > > Chris.
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > .
> > > > > 
> > > 
> > > .
> > > 
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>