Re: [netmod] Deviations and augmentations

[Andy Bierman <[e-mail]>]

On Tue, Nov 13, 2018 at 7:54 AM, Robert Wilton <[e-mail]> wrote:

>
> On 13/11/2018 15:32, Andy Bierman wrote:
>
>
>
> On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton <[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]> 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.
>
>
>
>From RFC 7950, sec 11:

   o  A "status" statement may be added, or changed from "current" to
      "deprecated" or "obsolete", or changed from "deprecated" to
      "obsolete".



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


It is quite easy to check if the status-stmt is set to deprecated or
obsolete.
SEMVER is not very useful, especially if the major version is incremented
even though there were no NBC changes.




> Thanks,
> Rob
>
>
>

Andy


>
>
>> 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]> <[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]
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>
>