Re: [netmod] Y60 - coexistence with YANG 1.0

Martin Bjorklund <mbj@tail-f.com> Thu, 10 September 2015 12:29 UTC

Return-Path: <mbj@tail-f.com>
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 6843C1B53C8 for <netmod@ietfa.amsl.com>; Thu, 10 Sep 2015 05:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 SybEx9IZ_m2P for <netmod@ietfa.amsl.com>; Thu, 10 Sep 2015 05:29:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0F1B2C1F for <netmod@ietf.org>; Thu, 10 Sep 2015 05:29:40 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F94C1AE097A; Thu, 10 Sep 2015 14:29:38 +0200 (CEST)
Date: Thu, 10 Sep 2015 14:29:37 +0200
Message-Id: <20150910.142937.1513840100723802033.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <FF0D416F-CDFD-46F8-A134-AD7D7308F4C0@nic.cz>
References: <DF93C199-5972-405C-97DB-57CE36BE3DF3@nic.cz> <20150910.134500.743921822231000218.mbj@tail-f.com> <FF0D416F-CDFD-46F8-A134-AD7D7308F4C0@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/PVWfDoa3iurrMYUPR-gydO56qkg>
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:29:41 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> 
> > 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.

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