Re: [netmod] Deviations and augmentations

[Robert Wilton <[e-mail]>]

On 13/11/2018 15:32, Andy Bierman wrote:
>
>
> On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     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.
>
>
> I don't think RFC 7950 says that.

RFC 7950 states '"obsolete" means that the definition is obsolete and 
SHOULD NOT be implemented and/or can be removed from implementations.'

So if there was a client using those definitions it would break, hence 
it is a non-backwards-compatible change.


> Removing outdated functionality is exactly what the status-stmt is for.

Agreed.


> IMO we should learn to use the YANG that is already there.

We are trying to make what we have today better.

Specifically, so that a client can look at a semver numbers between two 
modules revisions and determine whether or not they might be broken by 
that change.

Today, just using the status element alone to mark removed nodes means 
that a client would have to check for all changes in the module between 
two revisions to determine whether or not the new module revision is 
backwards compatible with the old one.

Thanks,
Rob


>     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 <[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>
>>
>>
>