Re: [netmod] Y60 - coexistence with YANG 1.0

Ladislav Lhotka <lhotka@nic.cz> Thu, 10 September 2015 12:20 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CA91B5D53 for <netmod@ietfa.amsl.com>; Thu, 10 Sep 2015 05:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level:
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7ruP5gqOqdX for <netmod@ietfa.amsl.com>; Thu, 10 Sep 2015 05:20:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8303D1B5D50 for <netmod@ietf.org>; Thu, 10 Sep 2015 05:20:07 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id C267B181817; Thu, 10 Sep 2015 14:20:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441887605; bh=Ex0ImkV7hhazz/yOglGCbdj4oQmm+asGePG8D3MYbQ4=; h=From:Date:To; b=FQXNeiL6dpdiLroZyl1fjpllrYCPwXsgVpt6LfLcBrqlxgpVcNLDR5Zu2FE7cF692 k3yiKgmONQa9wGASbtOHYxt/SIp76sC9Zo8eC1V8Ran9yg6rmSjA/h6J5aPVpZgoCs YVAOf93p0n56/JlPdm8R4IN7ij1EkgUS0FkByUcI=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20150910.134500.743921822231000218.mbj@tail-f.com>
Date: Thu, 10 Sep 2015 14:20:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF0D416F-CDFD-46F8-A134-AD7D7308F4C0@nic.cz>
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <DF93C199-5972-405C-97DB-57CE36BE3DF3@nic.cz> <20150910.134500.743921822231000218.mbj@tail-f.com>
To: Martin Björklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/0yTEFVyzyznoSEs_6x39jkWWcrg>
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2015 12:20:10 -0000

> On 10 Sep 2015, at 13:45, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Ladislav Lhotka <lhotka@nic.cz> wrote:
>> 
>>> On 10 Sep 2015, at 12:55, Martin Bjorklund <mbj@tail-f.com> 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.
> 
> Ok.
> 
>>> 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.
> 
> I assume you mean that Y is 1.1.

Yup.

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

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

> 
> 
> /martin
> 
> 
>>> 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
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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