On Nov 12 17:33 PM, Martin Bjorklund wrote: > Robert Wilton <rwil...@cisco.com> 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 > > netmod@ietf.org > > 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 > netmod@ietf.org > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
