> On 10 Sep 2015, at 12:55, Martin Bjorklund <[email protected]> wrote:
> 
> 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?

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

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

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
> the module as being 1.0.

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

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

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

Lada

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

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




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

Reply via email to