Subject: [netmod] Y60 - coexistence with YANG 1.0

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Sep 2015 12:55:22 +0200 (CEST)

Hi,

I think we agreed that is ok for a YANG 1.1 module to import a YANG
1.0 module.

But should it also be ok for a 1.0 module to import a 1.1 module?

If we make this illegal, we might run into problems.  For example,
ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
and the new version use YANG 1.1.  Is it ok for a server to implement
the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
answer is no, it means that we either have to update all modules to
1.1 more or less at the same time (including vendor models!), or we
keep existing modules on 1.0 "forever".

At the lastest interim, it was suggested that a server that implements
such a combination of models would internally promote the 1.0 module
to 1.1, and thus make this combination legal.

Such a strategy should also be safe for old clients, still treating
the module as being 1.0.

It is a bit unclear what the server should do if the 1.0 module that
it "internally promotes" to 1.1 contains something that is illegal in
1.1, e.g.:

        default "a\xb";

Comments?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Sep 2015 13:20:22 +0200

> On 10 Sep 2015, at 12:55, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

I think it should be illegal for a 1.0 module to import with revision if the requested revision is 1.1.

> to 1.1, and thus make this combination legal.

I think we need a way for the server to identify itself to the client as 1.1-capable, and then:

- 1.1-capable server: if 1.0 module X imports Y *without revision*, and the revision of Y advertised by the server (with default-revision=true), then module X is automatically interpreted as 1.1.

- 1.0-only server: if 1.0 module X import Y without revision, then the latest 1.0 revision of Y is used. If 1.1 revisions exist, they are not used.

> Such a strategy should also be safe for old clients, still treating

I am not sure about this, I think a 1.0-only client cannot work with a 1.1-capable server is some 1.1 additions are used (e.g. if-feature expressions).

>        default "a\xb”;

We should write an erratum to 6020 making this illegal in 1.0, too.

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Sep 2015 13:43:28 +0200

Ladislav Lhotka <[email-masked]> writes:

> - 1.1-capable server: if 1.0 module X imports Y *without revision*,
> and the revision of Y advertised by the server (with
> default-revision=true), then module X is automatically interpreted as
> 1.1.

Correction:

- 1.1-capable server: if 1.0 module X imports Y *without revision*, and
  the revision of Y advertised by the server (with
  default-revision=true) is 1.1, then module X is automatically
  interpreted as 1.1.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Sep 2015 13:45:00 +0200 (CEST)

> if the requested revision is 1.1.

Ok.

>   default-revision=true), then module X is automatically interpreted as

I assume you mean that Y is 1.1.

> - 1.0-only server: if 1.0 module X import Y without revision, then the
>   latest 1.0 revision of Y is used. If 1.1 revisions exist, they are not
>   used.

Yes.

> I am not sure about this, I think a 1.0-only client cannot work with a
> 1.1-capable server is some 1.1 additions are used (e.g. if-feature
> expressions).

Note that the 1.0 client worked with the 1.0 server with 1.0 modules X
and Y before.  Now Y is updated to 1.1.  According to section 10, Y is
not allowed to add if-feature to existing definitions.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Sep 2015 14:20:06 +0200

> On 10 Sep 2015, at 13:45, Martin Bjorklund <[email-masked]> wrote:
> 

Yup.

> not allowed to add if-feature to existing definitions.

New (non-mandatory) nodes may be added to Y that use if-feature expressions, new XPath functions etc., and the old client can actually receive instances of these nodes in the configuration.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Sep 2015 14:29:37 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> New (non-mandatory) nodes may be added to Y that use if-feature
> expressions, new XPath functions etc., and the old client can actually
> receive instances of these nodes in the configuration.

Sure.  But new optional leafs could be added in an upgraded 1.0 model
as well, so the client needs to either be prepared to handle this, or
decide to close the connection when it realizes that it does not
understand all revisions of all data models.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Sep 2015 15:19:14 +0200 (CEST)

Hi,

> keep existing modules on 1.0 "forever".

I suggest we add this text:

-------------------

* Coexistence with YANG version 1

A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
and vice versa.

A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision.

A YANG version 1.1 module or submodule MAY import a YANG version
1 module by revision.

A YANG version 1.1 module or submodule MAY import a YANG version 1
module without revision, and vice versa.  This rule exists in order to
allow implementations of existing YANG version 1 modules together with
YANG version 1.1 modules.  Without this rule, updating a single module
to YANG version 1.1 would have a cascading effect on modules that
import it, requiring all of them to also be updated to YANG version
1.1, and so on.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2015 15:43:30 +0200

> I suggest we add this text:

Vice versa? I assume you mean 'a YANG version 1 module MUST NOT
include a YANG version 1.1 submodule. Perhaps it is clearer to spell
this out explicitly?

> import it, requiring all of them to also be updated to YANG version

Again, perhaps expand 'vice versa' to be very clear.

The interesting case here if I understand things correctly is a YANG
version 1 module or submodule importing from a YANG 1.1 module, which
is legal if the import is without a revision. Hm. So in order to avoid
a cascading effect, I have to avoid import by revision and then I am
golden? What about importing by revision the last revision that is
still YANG 1? I heard that may be troublesome with the YANG library
but then perhaps the problem is there? I mean, if I import something
that only exists in a 1.1 version, should I then not really upgrade to
1.1 as well? Would it not work if an import of ietf-interfaces from a
version 1 module simply resolves to the latest ietf-interfaces
revision that is still version 1?

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Sep 2015 15:54:59 +0200 (CEST)

Ok.

Ok.

> golden?

No you don't have to import by revision, according to the proposed rule.

> What about importing by revision the last revision that is
> still YANG 1?

Sure, this is ok.

> I heard that may be troublesome with the YANG library

No, this works fine w/ YANG library.

> 1.1 as well?

Sure.  The use case is for example servers that implement ietf-ip
(which imports ietf-interfaces), and ietf-interfaces.  Suppose we
update ietf-interfaces to 1.1.  It should still be ok for a server to
implement ietf-ip with the new ietf-interfaces.

> Would it not work if an import of ietf-interfaces from a

But that would mean either that a server is stuck implementing version
1 modules, or that the server must implement both the version 1 and
version 1.1 module - and we have already said that this isn't
possible.

A set of simpler rules would be:

   A YANG version 1.1 module MUST NOT include a version 1 module.
   A YANG version 1 module MUST NOT include a version 1.1 module.

   A YANG version 1.1 (sub)module MAY import a version 1 module.
   A YANG version 1 (sub)module MAY import a version 1.1 module.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Sep 2015 16:55:43 +0200

>    A YANG version 1 (sub)module MAY import a version 1.1 module.

What about my proposal

https://mailarchive.ietf.org/arch/msg/netmod/_q3YcPR_KobOlFx5HWDA5Oa9oZo

Its advantage is that it doesn't automatically expose 1.0-only server to
1.1 stuff if a module that's imported without revision is upgraded to
1.1.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Sep 2015 16:59:03 +0200 (CEST)

> 1.1 stuff if a module that's imported without revision is upgraded to

But a 1.0 only server would only implement 1.0 modules so there
wouldn't be any problem there.

The problem with "upgraded to 1.1" is that I don't really understand
what exactly it means, and what does the server do if there are errors
in this process?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2015 17:02:34 +0200

> implement ietf-ip with the new ietf-interfaces.

Is the confusion is between implements and imports here? The module
ietf-ip will _import_ an older version 1 ietf-interfaces while the
server _implements_ a newer version 1.1 ietf-interfaces module. Is
this not going to work?

> version 1.1 module - and we have already said that this isn't

But this seems only true if import === implemented.

>    A YANG version 1 (sub)module MAY import a version 1.1 module.

It is the last one we are discussing, no? I am trying again: Why is
the MAY needed? Why is it not sufficient for a version 1 module to
work with an import for (the latest) version 1 module?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Sep 2015 19:46:58 -0700

> server _implements_ a newer version 1.1 ietf-interfaces module. Is

Here is the guidance put in RFC 6020 for this occasion:

   Handling of the "yang-version" statement for versions other than "1"
   (the version defined here) is out of scope for this specification.
   Any document that defines a higher version will need to define the
   backward compatibility of such a higher version.

All current Yuma based tools see the yang-version 1.1; and exit:

    ietf-entity.yang:54.16: error(314): wrong version

    Error: cannot continue with unknown YANG language version

The solution outlined this morning should mostly work.
A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
even if the server has upgrades some of those modules to YANG 1.1.
Note that a server has total control when it introduces modules
written in YANG 1.1. Not the client.

If module 'foo' is upgraded to a new module revision,
and the new module revision uses YANG 1.1, then
the server will advertise the last YANG 1.0
revision for module 'foo' in the YANG 1.0 <hello>.
The YANG 1.1 library will contain both module revisions,
and the server will set conformance to 'implement' for the 1.1 version.

If the data that existed in the last revision written in YANG 1.0
has changed in the implemented revision written in YANG 1.1,
then the server should not (or must not?) advertise the 'phantom'
YANG 1.0 revision anymore.

 Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Sep 2015 11:31:49 +0200

>     Error: cannot continue with unknown YANG language version

I don't think this has to be a strict rule for clients. After all, a
client can send any request and it is up to the server to decide whether
the request is valid and send a reply or error message.

> and the server will set conformance to 'implement' for the 1.1

Does this apply only to the case when the old and new revisions of "foo" are
identical except for yang-version? 

> YANG 1.0 revision anymore.

But then an old 1.0-only client is stuck, right?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Sep 2015 06:22:29 -0700

> the request is valid and send a reply or error message.
Not sure what you mean.
A tool that does not claim conformance because it does not recognize the
YANG language does not have any rules to follow.

We cannot make any rules whatsoever that a YANG 1.0 tool
must follow wrt/ other YANG language versions.  That much is rather clear.

> identical except for yang-version?

It is up to the server vendor, as Martin said.

> But then an old 1.0-only client is stuck, right?
Yep -- the version written in YANG 1.1 might diverge from the last revision
written in YANG 1.0.  Then forklift upgrades are needed.  And since YANG is
far
from stable, one might expect to go through churn every year until YANG is
stable.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Sep 2015 15:47:07 +0200

> On 15 Sep 2015, at 15:22, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

I don’t want to enforce classification of clients and then require that a 1.0 client MUST exit when seeing yang-version 1.1.

Lada

> written in YANG 1.0.  Then forklift upgrades are needed.  And since YANG is far
> from stable, one might expect to go through churn every year until YANG is stable.
> 
> 
> Lada
> 
> 
> Andy
>  
> 
> >
> >
> >  Andy
> >
> >
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Sep 2015 15:54:58 +0200 (CEST)

> work with an import for (the latest) version 1 module?

How about this:

-------------------

* Coexistence with YANG version 1 @coexistence@

A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
and a YANG version 1 module MUST NOT include a YANG version 1.1
submodule.

If a YANG version 1 module A imports module B without revision, and
module B is updated to YANG version 1.1, a server MAY implement both
these modules at the same time.  In such cases, a NETCONF server MUST
advertise both modules using the rules defined in ^announce^, and
SHOULD advertise module A and the latest revision of module B that is
specified with YANG version 1 according	to the rules defined in
^RFC6020^.

This rule exists in order to allow implementations of existing YANG
version 1 modules together with YANG version 1.1 modules.  Without
this rule, updating a single module to YANG version 1.1 would have a
cascading effect on modules that import it, requiring all of them to
also be updated to YANG version 1.1, and so on.

----------------

Note that this text again talks about NETCONF in the main text...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Sep 2015 17:00:43 +0200

> On 15 Sep 2015, at 15:54, Martin Bjorklund <[email-masked]> wrote:
> 

Does this apply only to include-by-revision? Because otherwise how can we tell?

> module B is updated to YANG version 1.1, a server MAY implement both

What about imports that are only for groupings/typedefs? “Implement” doesn’t cover this case, and such imported modules don’t appear in hello.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Sep 2015 08:01:59 -0700

On Tue, Sep 15, 2015 at 6:47 AM, Ladislav Lhotka <[email-masked]> wrote:

> I don’t want to enforce classification of clients and then require that a
> 1.0 client MUST exit when seeing yang-version 1.1.
>
>

The YANG 1.0 spec was already published.

For a YANG 1.0 implementation there are no rules for how it must deal
with a yang-version value other than '1'.

The behavior is out of scope.
Anything a YANG 1.0 tool does with 1.1, including exit right away, is
compliant.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Sep 2015 12:39:47 +0200 (CEST)

> Does this apply only to include-by-revision? Because otherwise how can

It is supposed to apply to both; if it is include by revision it is
obvious, but for include w/o revision it means that any tool (server,
client, ...) MUST treat version mismatch as an error.

> What about imports that are only for groupings/typedefs?

They are supposed to be covered.

> “Implement”
> doesn’t cover this case

Do we have a word that covers them as well?

>, and such imported modules don’t appear in
> hello.

Well this is not clear in 6020.  They may or may not appear in the
hello.  (I think most implementations actually do include them in the
hello).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Sep 2015 12:57:33 +0200

> On 17 Sep 2015, at 12:39, Martin Bjorklund <[email-masked]> wrote:
> 

Do you mean that it depends on what revisions are actually available to the tool? The formulation looks like it it aimed at module authors.

> Do we have a word that covers them as well?

Probably not, it would be useful to have it.

> hello.  (I think most implementations actually do include them in the

But that means it is impossible to reuse top-level typedefs/groupings from a module without implementing all its data.
And what if different modules import different revisions of the same module?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Sep 2015 11:55:51 -0700

> client, ...) MUST treat version mismatch as an error.

This is still a problem:

This assumes the tools understand YANG 1.1.
YANG 1 says it is undefined what happens if the YANG 1 compiler
finds a yang-version value other than '1'.

You want to make a distinction between a YANG 1.1 capable tool
and a YANG 1.0 capable tool. Obviously a YANG 1 capable tool
is not required to EVER accept a YANG 1.1 module.

So when the YANG author imports a YANG 1.1 module from a YANG 1 module
and no revision date is given, there really are no rules that YANG 1.1 can
specify
that would apply to a YANG 1 tool.  There is no way to enforce any
interoperability
requirements wrt/ the revision of the imported module that is used in this
case.

> hello.  (I think most implementations actually do include them in the
Yes -- and there is no way we are ever changing this code.
The full list of revision dates is needed so the client and server will
produce the same schema set.  YANG 1 would be unusable without this info.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Sep 2015 16:22:28 +0200 (CEST)

>     A YANG version 1 (sub)module MAY import a version 1.1 module.

But my proposed text doesn't say that.  It was rewritten to:

  If a YANG version 1 module A imports module B without revision, and
  module B is updated to YANG version 1.1, a server MAY implement both
  these modules at the same time.  In such cases, a NETCONF server
  MUST advertise both modules using the rules defined in ^announce^,
  and SHOULD advertise module A and the latest revision of module B
  that is specified with YANG version 1 according to the rules defined
  in ^RFC6020^.

> is not required to EVER accept a YANG 1.1 module.

Agreed.

> requirements wrt/ the revision of the imported module that is used in this

It is not that the version 1 module author imports a 1.1 module w/o
revision; the use case is an implementation that MAY *implement* both.

/martin