Re: [NGO] external module properties

Martin Bjorklund <mbj@tail-f.com> Thu, 01 May 2008 20:32 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 66A293A68DC; Thu, 1 May 2008 13:32:01 -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 72C8C3A67FD for <ngo@core3.amsl.com>; Thu, 1 May 2008 13:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.427
X-Spam-Level:
X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=0.068, 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 K5gXOHRgzz9Q for <ngo@core3.amsl.com>; Thu, 1 May 2008 13:31:58 -0700 (PDT)
Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 7E6F63A68DC for <ngo@ietf.org>; Thu, 1 May 2008 13:31:58 -0700 (PDT)
Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id DA2B01B80C7; Thu, 1 May 2008 22:31:59 +0200 (CEST)
Date: Thu, 01 May 2008 22:31:55 +0200
Message-Id: <20080501.223155.101151882.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <001001c8aad2$7256bbc0$6801a8c0@oemcomputer>
References: <200804292243.m3TMhOIC091458@idle.juniper.net> <20080430.082352.151372679.mbj@tail-f.com> <001001c8aad2$7256bbc0$6801a8c0@oemcomputer>
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

Hi,

"Randy Presuhn" <randy_presuhn@mindspring.com> wrote:
> > From: "Martin Bjorklund" <mbj@tail-f.com>
> > 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.
> 
> In my opinion, this is a feature, rather than a bug.
> (But there's no "as soon as" requirement.  There's no need to update
> B until someone wants a version that includes the behavioural changes
> that would result from using the newer version of A.)

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.

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.


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