Re: [netmod] Deviations and augmentations

[Andy Bierman <[e-mail]>]

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 ...")
>
> So we still need Semver(or something akin) and the possibility to do NBC
> changes.
>


This aspect of deviations is unfortunate because it really is a good idea to
limit the number of ways to do the same thing in YANG.

It was a mistake to limit so many legitimate schema alterations and also a
mistake
to characterize all schema modifications as a server failure. Maybe if it
was called "patch"
instead of "deviation".

We should encourage servers to provide the most accurate schema possible.
Many vendors already maintain detailed deviations modules.

Balazs
>

Andy


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