Re: [netmod] Deviations and augmentations

On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton <rwilton@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.lengyel@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 <rwilton@cisco.com> <rwilton@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.Lengyel@ericsson.com
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>