|
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.
Balazs
On 2018. 11. 12. 18:08, Robert Wilton
wrote:
On 12/11/2018 16:33, Martin Bjorklund wrote:
Robert Wilton <rwil...@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.leng...@ericsson.com
|
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
