On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton <rwil...@cisco.com> wrote:
> > On 13/11/2018 15:17, Andy Bierman wrote: > > > > 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. > > Yes, but obsoleting nodes should be regarded as a non-backwards-compatible > change because it can break clients that were relying on those nodes. > I don't think RFC 7950 says that. Removing outdated functionality is exactly what the status-stmt is for. IMO we should learn to use the YANG that is already there. > Thanks, > Rob > > > Andy > > > 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
