Re: [NGO] external module properties
Martin Bjorklund <mbj@tail-f.com> Thu, 01 May 2008 21:26 UTC
Return-Path: <ngo-bounces@ietf.org>
X-Original-To: ngo-archive@optimus.ietf.org
Delivered-To: ietfarch-ngo-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2BA28C152; Thu, 1 May 2008 14:26:41 -0700 (PDT)
X-Original-To: ngo@core3.amsl.com
Delivered-To: ngo@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A4F3A6A19 for <ngo@core3.amsl.com>; Thu, 1 May 2008 14:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.433
X-Spam-Level:
X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+le7wbc1m18 for <ngo@core3.amsl.com>; Thu, 1 May 2008 14:26:39 -0700 (PDT)
Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D820C3A6BD2 for <ngo@ietf.org>; Thu, 1 May 2008 14:26:38 -0700 (PDT)
Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 5536C1B80C7; Thu, 1 May 2008 23:26:40 +0200 (CEST)
Date: Thu, 01 May 2008 23:26:35 +0200
Message-Id: <20080501.232635.78733212.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <200805012045.m41KjmAp009395@idle.juniper.net>
References: <20080501.223155.101151882.mbj@tail-f.com> <200805012045.m41KjmAp009395@idle.juniper.net>
X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Cc: ngo@ietf.org
Subject: Re: [NGO] external module properties
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ngo-bounces@ietf.org
Errors-To: ngo-bounces@ietf.org
Phil Shafer <phil@juniper.net> wrote: > Martin Bjorklund writes: > >The problem is when a vendor needs to implement A rev 2 in a device, > >and also B. B imports A rev 1. So the device needs to implement A > >rev 1 *and* A rev 2. This is something that we have talked about > >before, and dismissed as being too complicated in general. > > I'm hoping (having not implemented it yet ;^) that this won't be that > bad. If I have a hierarchy in my C module that uses a grouping > from B that uses the original revision of A, and another place in > my C that wants to use the new A with a new leaf that has the content > I want, I just need to track the module inclusion and imports to > know which revision of A I am getting the grouping from. A YANG module defines types, groupings, data, rpc, and notifications. All of these can be referenced by an importing modules (types and groupings are obvious; data can be referenced through keyrefs, augments, and must expressions; and rpc/notifs can be augmented). I agree that supporting multiple versions of a module in order to handle types and grouping should be fairly straight-forward. But when it comes to data/rpc/notifs the device must choose one version to implement. It would have to be a version no earlier than the latest version referenced by any other module implemented on the device. For example: module a { revision "2008-04-25"; container foo { ... } } module a { revision "2008-05-01"; container foo { ... } container bar { ... } } module b { revision "2008-04-26"; import a { revision "2008-04-25"; prefix a; } augment "/a:foo" { container baz { ... } } } A device must be allowed to announce that it implements: a:2008-05-01 b:2008-04-26 Maybe it's not a problem... but the schema discovery mechanism will have to support these cases. There would be two separate lists of schemas; one list with the data/rpc/notifs that the device implements, and an extended list which includes older versions and type/grouping-only modules. > >But you talk about behavioural changes. In the current design of > >YANG, the idea has been that a module cannot be updated in a way that > >changes the behaviour for importers and includers. Thus you don't > >have to rev B just b/c A is updated. > > If I add a new leaf to a grouping in A that B doesn't know about, > B will break if I use the new A. If I can't say which A I want, > then the grouping in A cannot be allowed to change. This means > that the contents of groupings, types, etc are locked for all time, > which is a pretty strong limitation. Yes. A couple of solutions have been mentioned already, and another alternative is to keep this limitation, and force people to define new groupings in this case; essentially putting the version into the name: // original definition grouping foo { container bar; } // next revision adds a new item to foo, but since we can't do // that we'll define a new grouping: grouping foo2 { uses foo; container baz { ... } } /martin _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo
- [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Jon Saperia
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund