Re: [netmod] Deviations and augmentations

[Robert Wilton <[e-mail]>]

Hi Balazs,

On 13/11/2018 13:46, Balázs Lengyel 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 ...")
>
> So we still need Semver(or something akin) and the possibility to do 
> NBC changes.
>
But one could perhaps argue that nodes should only be removed (i.e. 
obsoleted) at the development head, where semver is allowed.

Do you think that we also need to support obsoleting YANG nodes in 
branches that have already been released?

Thanks,
Rob


> Balazs
>
> On 2018. 11. 12. 18:08, Robert Wilton wrote:
>>
>>
>> On 12/11/2018 16:33, Martin Bjorklund wrote:
>>> Robert Wilton <[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]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: [phone]              email:[e-mail]