Subject: [Netmod-ver-dt] do we still need deviations?

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Mar 2019 17:07:18 +0100

Hi,

did you ever consider whether it is feasible to get rid of YANG
deviations once there is a versioning scheme that is flexible enough
to support vendor specific variations (that may not be strictly
backwards compatible)?

Right now, we have A implements foo@<date> + A-foo-deviations, B
implements foo@<date> + B-foo-deviations and C implements foo@<date> +
C-foo-deviations. Proper schema aware clients then have to construct
out of this information three different schema, namely foo'A@<date>,
foo'B@<date>, and foo'C@<date>.

If we move towards version numbers and we accept incompatible changes
in some form, could we perhaps simplify things by having A announce
[email-masked], B announce [email-masked], C announce [email-masked] and then tools
can calculate the deviation by comparing [email-masked] with foo@ver etc.?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 8 Mar 2019 16:19:16 +0000

I can't easily see how we can get rid of deviations. Deviations allow someone else besides the author of the module to declare parts they don't support.

> -----Original Message-----
> From: Netmod-ver-dt <[email-masked]> On Behalf Of
> Juergen Schoenwaelder
> Sent: Friday, March 8, 2019 11:07 AM
> To: [email-masked]
> Subject: [Netmod-ver-dt] do we still need deviations?
> 
> Hi,
> 
> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 8 Mar 2019 17:18:05 +0000

Hi Juergen,

No, this has not been considered or discussed yet, and sounds like it worthy of some discussion.

This sounds to me like a representational question.  I.e. logically the schema [email-masked] should be exactly equivalent to foo@<date> + A-foo-deviations, and sufficiently advanced tooling would be able to convert between the two.

The answer may depend on whether you have a YANG module with a lot of data nodes, and a few deviations, or a YANG module with lots of deviations.

My gut instinct is that deviations are probably still the right answer because:
 - they are intended to be uncommon.  Ideally, there would be none at all.
 - deviations are probably more informative to human readers (without having to go through an extra tooling step)
 - if the underlying module changes over time, then keeping track of a set of deviations is possibly a bit easier, although this is probably very implementation dependent.

FWIW, I can still think of three cases where the concept of deviations are useful:
(1) Where the models are owned by an external entity (e.g. IETF or OpenConfig) and the implementation cannot faithfully match the specification.
(2) Potentially for datastores, e.g. <operational> may not be able to exactly represent configuration, at least in the short/medium term.
(3) If we do manage to convince the WG that a schema selection draft is the right way to version "schema" then it is still the case that if the device implements the latest schema that there may be some data nodes in the old schema that are simply unmappable, or only a partial mapping is possible.  Deviations against the old schema could be used to indicate to client which parts of the old schema cannot be mapped, and hence cannot be supported.

Possibly the representation that you suggest could be better/easier for (2) rather than deviation files.

Thanks,
Rob

-----Original Message-----
From: Netmod-ver-dt <[email-masked]> On Behalf Of Juergen Schoenwaelder
Sent: 08 March 2019 16:07
To: [email-masked]
Subject: [Netmod-ver-dt] do we still need deviations?

Hi,

did you ever consider whether it is feasible to get rid of YANG deviations once there is a versioning scheme that is flexible enough to support vendor specific variations (that may not be strictly backwards compatible)?

Right now, we have A implements foo@<date> + A-foo-deviations, B implements foo@<date> + B-foo-deviations and C implements foo@<date> + C-foo-deviations. Proper schema aware clients then have to construct out of this information three different schema, namely foo'A@<date>, foo'B@<date>, and foo'C@<date>.

If we move towards version numbers and we accept incompatible changes in some form, could we perhaps simplify things by having A announce [email-masked], B announce [email-masked], C announce [email-masked] and then tools can calculate the deviation by comparing [email-masked] with foo@ver etc.?

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 11 Mar 2019 13:00:00 +0000

+1   Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]