Subject: [netmod] backward compatibility

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2014 11:14:01 +0100

Hi,

it seems that most YANG 1.1 issues where we cannot reach consensus have
to do with old client compatibility requirements in Sec. 11, and similar
rules for augments.

One example: Y25 would become a non-issue if it wasn't for this item in
Sec. 11:

   o An "enumeration" type may have new enums added, provided the old
     enums's values do not change.

Maybe we should really consider lifting or relaxing these rules because:

- they bind our hands and may lead to ugly modules that contain tricky
  workarounds, obsolete nodes or groupings, and/or whose constraints are
  too loose;

- the rules are not fool-proof and backward compatibility may still be
  broken in a number of ways (I can give examples if somebody is
  interested);

- when we upgrade our existing modules to YANG 1.1, there will be no
  backward compatibility;

- vendors wanting to introduce incompatible changes will always have the
  option to rename the module, which is IMO much worse for all clients,
  old or new.

I think it is fully appropriate to demand a strict discipline wrt
revision management and backward compatibility for modules that are
being developed in the IETF, but then corresponding guidelines should go
to 6087bis.

And even then, I believe that at this stage RFCs containing YANG modules
should still be tagged with clearly visible road work signs - everybody
has to understand that incompatible changes may sometimes be necessary.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2014 10:57:18 -0500

>has to understand that incompatible changes may sometimes be necessary.

People are using NETCONF and YANG to perform real work.  Telling
them that this technology isn't stable enough for real work use
will result in them choosing other technologies.

In fact, I would strongly (very strongly) suggest the opposite.
Any change that we are considering that contributes even vaguely to
the perception that this technology isn't stable enough for real
work should be avoided.  Clarifications and coverage of odd corner
cases are acceptable.  Real changes are not.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Dec 2014 17:28:35 +0100

> On 04 Dec 2014, at 16:57, Phil Shafer <[email-masked]> wrote:
> 
> Ladislav Lhotka writes:

As the standard modules go, we are still at the very beginning, so how could the IETF data model base be considered stable enough? Pretending that both the language and the modules can be done at first try, and what remains are only cosmetic changes, is IMO short-sighted.

Routing folks are now evaluating the routing module, and I expect that quite a few things in it may need revamping. The module was already close to becoming an RFC but, in fact, we would be stuck if that had happened. Some of the changes that are being proposed would become impossible due to the Sec. 11 rules. What would you suggest in that case - start a new routing-plus module?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Dec 2014 09:30:16 -0800

> cases are acceptable.  Real changes are not.

This does seem to be the intent of the charter, and the intent of calling
it YANG 1.1 instead of 1.5 or 2.0.  I agree that stability is more important
than new features, especially since customers are not really complaining
about YANG 1.0 and not asking for YANG 1.1.

However, no matter what is in the next version of YANG, all relevant tools
need to be updated in order to use the first YANG 1.1 module.
Tools that are not updated (not just clients) cannot use the new module
or the feature it represents.

IMO this is going to be much more important to vendors than some
clarifications to YANG. Engineers will be asked to justify the use of YANG 1.1,
since tool X will not implement it in time for the software release.
So I support some new features like actions, but nothing that changes
any data types (like optional keys).

>  Phil

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2014 16:08:36 -0500

Ladislav Lhotka writes:
>Routing folks are now evaluating the routing module, and I expect that quite a few thing
>s in it may need revamping. The module was already close to becoming an RFC but, in fact
>, we would be stuck if that had happened. Some of the changes that are being proposed wo
>uld become impossible due to the Sec. 11 rules. What would you suggest in that case - st
>art a new routing-plus module?

Has anyone implemnted the routing module?  If not, there's not
cost.  But many people have implemented YANG engines, so changing
the way it works is not without cost.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Dec 2014 10:45:13 +0100

> cost.  But many people have implemented YANG engines, so changing

Exactly, but sec. 10 in RFC 6020 still applies, hence the update
possibilities are severely limited. That's why I think these
restrictions are counter-productive, and backward compatibility of
module updates should be left to a qualified judgement of a data
modeller or IETF WG.

> the way it works is not without cost.

This thread is not about YANG language upgrade, which is a separate
problem.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Dec 2014 10:52:18 +0100

> This does seem to be the intent of the charter, and the intent of

I am not sure about the intent, but none of the proposed changes violate
the charter's wording. Above that, we also agreed that semantics of
existing statements must not change.

> or the feature it represents.

Agreed.

> any data types (like optional keys).

Well, then almost nothing would be left. For example, the new XPath
functions won't be possible.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Dec 2014 07:06:14 -0800

> module updates should be left to a qualified judgement of a data

Not quite....
The routing modules are not published in RFCs so section 10 does not
apply to them.
In IETF terms, a work-in-progress can be changed at any time and in any way.
We are only concerned with RFC to RFC changes.

> This thread is not about YANG language upgrade, which is a separate

The YANG update rules have a huge impact on the cost of data model maintenance.
Most vendors will want to make engineering tradeoffs that minimize code changes,
even if that makes the YANG module less elegant.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Dec 2014 16:47:07 +0100

> On 05 Dec 2014, at 16:06, Andy Bierman <[email-masked]> wrote:
> 

But that’s what I wrote: The I-D was close to becoming an RFC, and if it had happened it would be impossible to realize some of the recent suggestions such as remove route-filters. I would be *extremely* reluctant to tag them as obsolete and then augment a new implementation of route-filters from another module. If readability is supposed to have the highest priority, why should readers of standard modules be harassed by something like this?

Yes, it hasn’t happened this time but I think it is bound to happen with the routing module (if it ever gets published) or another.

> even if that makes the YANG module less elegant.

Less elegant might be acceptable but incomprehensible is not. I understand it is your priority and why it is so but I think in the long run it may lead to a terrible mess of bloated modules that nobody will understand.

Lada