Re: [NGO] external module properties

Martin Bjorklund <mbj@tail-f.com> Wed, 30 April 2008 06:23 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 2D8E73A6D47; Tue, 29 Apr 2008 23:23:55 -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 F1F853A6A3F for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 23:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 Hxlbr4iae47o for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 23:23:53 -0700 (PDT)
Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 131D53A6D71 for <ngo@ietf.org>; Tue, 29 Apr 2008 23:23:53 -0700 (PDT)
Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id F3ADF1B80CD; Wed, 30 Apr 2008 08:23:54 +0200 (CEST)
Date: Wed, 30 Apr 2008 08:23:52 +0200
Message-Id: <20080430.082352.151372679.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <200804292243.m3TMhOIC091458@idle.juniper.net>
References: <00e201c8aa35$5a893830$0600a8c0@china.huawei.com> <200804292243.m3TMhOIC091458@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:
> "David Harrington" writes:
> >I think we might need the capability of specifying version in the
> >include statement (if the version dependency is important, but it
> >should be able to be left out when it is not important)
> 
> I keep coming back to this also, for the "import" statement.
> Consider this scenario/timeline:
> 
> - module A defines a cool feature
> - modules B and C import A to use that feature
> - module A gets rev'd to add a new leaf to a grouping
> - module B wants the new leaf
> - module C doesn't want it
> 
> Without revision-specific imports, this scenario is unworkable.
> 
> With revisions, module B would get rev'd to import the new revision
> of A.  Module C would continue to import the previous revision.

But with revisions, you have to explicitly rev all importers of a
module when the module is updated.

Suppose module A rev 1 gets published in an rfc, and module B which
imports A rev 1 in another.  Now, A is updated to rev 2.  If a vendor
wants to implement A rev 2 and B, that doesn't work, unless B is also
updated to rev 2 as soon as A is updated.


/martin
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo