On Tue, Nov 13, 2018 at 5:46 AM, Balázs Lengyel <balazs.leng...@ericsson.com > wrote:
> Hello, > > We also need a method for removing stuff. It does happen that some > functionality is deemed not important enough, outdated, too expensive to > maintain, so we want to remove it. > > - Augment is clearly not the tool for that. > - Deviations are not intended for that (from rfc 7950: "server > deviation: A failure of the server ...") > > Removing nodes is easy with the status-stmt. Update the module and set the status to deprecated or obsolete. Andy > > > So we still need Semver(or something akin) and the possibility to do NBC > changes. > > Balazs > On 2018. 11. 12. 18:08, Robert Wilton wrote: > > > > On 12/11/2018 16:33, Martin Bjorklund wrote: > > Robert Wilton <rwil...@cisco.com> <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". > > Ah, OK. I agree that makes sense. > > > 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. > > So, I think that this probably works for adding enhancements, but not for > the (arguably more important) bug fix case, unless there is a reasonable > solution to having two config data nodes both modifying the same underlying > property. Perhaps under some reasonable constraints this could be made to > work - but I don't know. > > Of course, even for enhancements it is not necessarily a perfect > solution. E.g. backporting some subset of a module already > coded/implemented in latest to an older release. And yes, we really do get > asked to do this sometimes, although it is relatively rare. > > Thanks, > Rob > > > > /martin > > > 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://www.ietf.org/mailman/listinfo/netmod > > . > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
