Re: [netmod] Deviations and augmentations

[Ebben Aries <[e-mail]>]

On Nov 12 17:33 PM, Martin Bjorklund wrote:
> Robert Wilton <[e-mail]> wrote:
> > In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> > describe how deviations and augmentations are used in OpenConfig to
> > add functionality into an older YANG model where the semver rules
> > prevent the version number from being incremented.
> > 
> > Further, I think that someone (Martin?) stated on the audio bridge
> > that this was an intended/allowed behavior for deviations.
> 
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
> 
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
> 
> 

Does this not already somewhat exist today by way of each vendors
augments and deviations to OC models?  While branching doesn't exist
within OC directly, each implementation today supports *a* version at a
given point in time and deviations and augments exist within these
"branches". Occasionally the need arises to introduce changes in the
vendor provided modules as a stopgap that are ultimately mapped to a sw
release.

This could be fixes or additional functionality not previously there to
satisfy not having a customer have to upgrade their network element
and/or move to more recent modules

> 
> 
> > This surprised me, because I thought that RFC 7950 was quite explicit
> > that this is not what deviations are intended for.  My reading of RFC
> > 7950 is that the deviation statement represents the case where the
> > server *implementation* does not match the *specification*.  However,
> > the versioning issue that we are discussing are bug fixes/changes in
> > the specification rather than the bug fixes in the implementation.
> > 
> > Personally, I'm really not keen on using deviations to represent bug
> > fixes to older YANG models for three reasons:
> > 
> > (i) It is changing the meaning of deviation.  It is much cleaner to
> > keep the meaning of deviation statements as they are defined today,
> > and not conflate their semantics.
> > (ii) A different mechanism is used to put a bug fix into an older
> > branch rather than in the head of the development.
> > (iii) For clients to track the lifecycle of modules they would not
> > only need to know the module version number but would also need to
> > find and track all associated deviation modules.  This seems
> > significantly more complex for clients than the modified semver that
> > was proposed.
> > 
> > ---
> > 
> > I think that has also been some suggestion that augmentations (or
> > duplicate YANG modules with their major version number changed) can be
> > used to make bug fixes in a completely backwards compatible way. 
> > However, I still don't understand a robust scheme of how this works.
> > 
> > ---
> > 
> > Finally, there were some comments about using augmentation modules for
> > enhancements.  This is fine, where appropriate (e.g. a non trivial
> > number of data nodes are being added as an enhancement) then a
> > separate module may be the right way to go. But here, I presume that
> > the new functionality will always be tracked by that separate module. 
> > If that functionality folds back into the original module at some
> > point in the future, then obviously a non backwards compatible version
> > change is being forced on to the client, along with additional work on
> > the server as well.
> > 
> > I think that there are also many cases where the number of data nodes
> > being added via an enhancement is small compared to the size of the
> > module being updated.  In this case I believe that it better to add
> > these data nodes into the module itself, perhaps predicated under
> > if-feature if appropriate.
> > 
> > Thanks,
> > Rob
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=8si7cLdi3y5avgA6Nvi0V0TixjVoKFudWwp3mJNat5I&s=4OHPx7mvkQdY9-M_M5HEOcYS566LOUuNecztVjp_NFw&e=
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=8si7cLdi3y5avgA6Nvi0V0TixjVoKFudWwp3mJNat5I&s=4OHPx7mvkQdY9-M_M5HEOcYS566LOUuNecztVjp_NFw&e=