Re: [netmod] Deviations and augmentations

[Robert Wilton <[e-mail]>]

On 13/11/2018 15:17, Andy Bierman wrote:
>
>
> On Tue, Nov 13, 2018 at 5:46 AM, Balázs Lengyel 
> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]> <mailto:[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".
>>     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
>>>>     [e-mail] <mailto:[e-mail]>
>>>>     https://www.ietf.org/mailman/listinfo/netmod
>>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>     .
>>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>     -- 
>     Balazs Lengyel                       Ericsson Hungary Ltd.
>     Senior Specialist
>     Mobile: [phone]              email:[e-mail]  <mailto:[e-mail]>  
>
>
>     _______________________________________________
>     netmod mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>