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 <mailto: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.
Thanks, Rob
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> <mailto: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/martinThis 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 <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>._______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>-- Balazs Lengyel Ericsson Hungary Ltd.Senior SpecialistMobile: +36-70-330-7909 email:balazs.leng...@ericsson.com <mailto:balazs.leng...@ericsson.com>_______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
