From ngo-bounces@ietf.org Thu May 1 13:32:01 2008 Return-Path: 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 ; 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 ; 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 ; 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 (CEST) Message-Id: <20080501.223155.101151882.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" wrote: > > From: "Martin Bjorklund" > > 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 From ngo-bounces@ietf.org Thu May 1 13:47:46 2008 Return-Path: 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 5AADB3A6A8D; Thu, 1 May 2008 13:47:46 -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 A8AB43A69F0 for ; Thu, 1 May 2008 13:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dIKtcODrvu03 for ; Thu, 1 May 2008 13:47:44 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C3B213A6A32 for ; Thu, 1 May 2008 13:47:41 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 01 May 2008 13:47:06 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 13:47:28 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m41KlRx93303; Thu, 1 May 2008 13:47:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m41KjmAp009395; Thu, 1 May 2008 20:45:48 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805012045.m41KjmAp009395@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080501.223155.101151882.mbj@tail-f.com> Date: Thu, 01 May 2008 16:45:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 May 2008 20:47:28.0301 (UTC) FILETIME=[9182DDD0:01C8ABCC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org 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. >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. Thanks, Phil _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 14:26:41 2008 Return-Path: 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 ; 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 ; 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 ; 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 (CEST) Message-Id: <20080501.232635.78733212.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From ngo-bounces@ietf.org Thu May 1 15:09:17 2008 Return-Path: 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 C89633A6923; Thu, 1 May 2008 15:09:17 -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 959CE3A6801 for ; Thu, 1 May 2008 15:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] 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 qxHBbjWXhZRX for ; Thu, 1 May 2008 15:09:15 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id CEF143A6923 for ; Thu, 1 May 2008 15:09:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jOUDHXkYPjB8mkRCyNN0LeJVr3W/XvLI/9Rt+PZwajUJtczw6NFh0c6sEWMneBYe; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.137.170] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jrgxf-0006RV-3V for ngo@ietf.org; Thu, 01 May 2008 18:09:09 -0400 Message-ID: <000e01c8abcf$a158f200$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200804292243.m3TMhOIC091458@idle.juniper.net><20080430.082352.151372679.mbj@tail-f.com><001001c8aad2$7256bbc0$6801a8c0@oemcomputer> <20080501.223155.101151882.mbj@tail-f.com> Date: Thu, 1 May 2008 15:09:17 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891174b25739f2e45ab6912bd19edc5f80784350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.170 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, May 01, 2008 2:31 PM > Subject: Re: [NGO] external module properties ... > 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. Too complicated for what? The only case I can think of would be if some tool were blindly trying to re-use the same code for Arev1 and Arev2, or if some tool failed to account for the possibility that the same identifier might show up in different modules. These are just two ways of describing the same kind of broken-ness, and are easily handled by scoping (whether in one's symbol table management or the way one generates labels for use in code). > 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 an update to a module can't change behaviour (where behaviour includes signatures / interface definitions), then why does it matter? Randy _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 15:20:52 2008 Return-Path: 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 E79CB3A69D4; Thu, 1 May 2008 15:20:52 -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 B5DB53A69D4 for ; Thu, 1 May 2008 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] 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 5w8O5+9O82IU for ; Thu, 1 May 2008 15:20:50 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C39F33A68E7 for ; Thu, 1 May 2008 15:20:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qUdkw5CE4YVZWBp3LdQ7Lw55MTeZSaWWT6z9afEAFR6ihBF+0jyxhNor+2kk2j09; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.137.170] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jrh92-0006LA-HR for ngo@ietf.org; Thu, 01 May 2008 18:20:53 -0400 Message-ID: <002101c8abd1$493e66c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080501.223155.101151882.mbj@tail-f.com><200805012045.m41KjmAp009395@idle.juniper.net> <20080501.232635.78733212.mbj@tail-f.com> Date: Thu, 1 May 2008 15:21:13 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891176a60d45b296ea5b9987af376b7c571d7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.170 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Thursday, May 01, 2008 3:26 PM > Subject: Re: [NGO] external module properties ... > 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. ... This is an excellent example of the consequences of choosing (perhaps unconsiously) a particular meta-model. Consider, for example, what happens if RPCs and notifications are associated not with "the device", but with a particular object class. (One possible object class is a stand-in for "the device" which would be appropriate for those few things like "reboot" which really do apply to the entire device.) If the module defining a particular class imports a pre-defined notification or RPC, versioning would work just like for anything else. Consequently, a "device" would no longer be limited to implementing just one version of an RPC. Ancient use case: consider a "Rewind" RPC. System has several tape drives from various vendors, possibly from different technology generations. Someone updates "Rewind" to include a "energy conservation" option. When a new drive supporting that option in its Rewind RPC is installed, it should not require changing the software for all the other drives. Randy _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 15:26:51 2008 Return-Path: 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 2FB713A6942; Thu, 1 May 2008 15:26:51 -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 5D2763A68E7 for ; Thu, 1 May 2008 15:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] 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 pXoIabkWXTxr for ; Thu, 1 May 2008 15:26:48 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 0B2BD3A699F for ; Thu, 1 May 2008 15:26:47 -0700 (PDT) Received: (qmail 35377 invoked from network); 1 May 2008 22:26:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 1 May 2008 22:26:48 -0000 X-YMail-OSG: YHY4ys8VM1mSWQSjLdn24F8kwRd09FfWEEdbyc6Q2lMLIMSTNKEP.AeAuQD4VNYVZhyfW.M20ZeR6Vz61CZJWBffZOtWha_LKxe0QuHYmt1rXOaObVJXcoPa0ZI4lRSYwg9iVx_tLpksBH_TpXOf4Qwb X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A43A5.5060303@andybierman.com> Date: Thu, 01 May 2008 15:26:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Martin Bjorklund References: <20080501.223155.101151882.mbj@tail-f.com> <200805012045.m41KjmAp009395@idle.juniper.net> <20080501.232635.78733212.mbj@tail-f.com> In-Reply-To: <20080501.232635.78733212.mbj@tail-f.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: I am strongly opposed to any import or include mechanism for a specific version of a module. It seems hard enough to deploy one version of a standard data model at a time. I prefer a simple system in which the agent advertises which version of the module is implemented, and therefore associated with the module namespace URI. The manager must then decide if it can use that version of the module or not. I don't think this has been a problem in SMIv2, and it has not been demonstrated (yet) to be a problem in YANG. This is a good feature to save to YANG 2.0, in the future. I don't see how multiple sub-agents within a single agent can implement different versions of the same module, without using different namespace URIs for each variant. (Maybe somebody can explain it to me;-) Andy >>> 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 mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 15:30:56 2008 Return-Path: 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 AF7853A69F0; Thu, 1 May 2008 15:30:56 -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 75FFD28C420 for ; Thu, 1 May 2008 15:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] 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 fAs5XEcHNLk3 for ; Thu, 1 May 2008 15:30:54 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id A027E3A6881 for ; Thu, 1 May 2008 15:30:52 -0700 (PDT) Received: (qmail 32753 invoked from network); 1 May 2008 22:30:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 1 May 2008 22:30:53 -0000 X-YMail-OSG: IN_m4EwVM1ma4VVbgA7ei6pa0zJuyOcfhXSF1sS60TlmnZalfXmsER3qE.NUDpKdfyAPLyTRGCsWL5f6uDWiuFo.BtHj5Vw8KXRF1ggjZY18LHjDAimVTTBtYaOq8L1N0p4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A449A.6020503@andybierman.com> Date: Thu, 01 May 2008 15:30:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Martin Bjorklund References: <200804291905.m3TJ5ewb090087@idle.juniper.net> <20080429.214810.13543341.mbj@tail-f.com> <00ae01c8aa2b$edee6b40$6801a8c0@oemcomputer> <20080430.082828.120924636.mbj@tail-f.com> In-Reply-To: <20080430.082828.120924636.mbj@tail-f.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Martin Bjorklund wrote: > "Randy Presuhn" wrote: >>> From: "Martin Bjorklund" >>> How about adding an optional counter after the date? So you can do >>> >>> 2008-04-29 >>> 2008-04-29:1 >>> 2008-04-29:2 >>> >>> and so on. >>> >>> It removes the arbitrary timing constraint that worries Wes, and it's >>> still simple enough for the common use case. >> ... >> >> Even simpler - just use RFC 3339 date-time with the option of >> abbreviating it to full-date. That should be enough for even the >> busiest believers in rapid prototyping. > > That was my first thought as well, with the additional CLR to only use > UTC, in order for simple string comparison to work. But I thought a > single integer would be simpler and do the job just fine. > > If we do a single integer, we should use a dot instead of colon, as > Andy suggested. > I prefer the simple integer approach, but I can see how others find the dateTime more 'standards-y'. > > /martin > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 15:44:45 2008 Return-Path: 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 72DD928C1D8; Thu, 1 May 2008 15:44:45 -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 CCB1228C1D8 for ; Thu, 1 May 2008 15:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 2DcgrvqMG-VP for ; Thu, 1 May 2008 15:44:44 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 1BE4F28C1D4 for ; Thu, 1 May 2008 15:44:44 -0700 (PDT) Received: (qmail 36313 invoked from network); 1 May 2008 22:44:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 1 May 2008 22:44:45 -0000 X-YMail-OSG: RGbn.CIVM1kByO.vomCnGkuQ_ciC8ueW4fTna4yLVEVLNxAvfNp.Ur4K.C6P5ZXiR1O7XE7qytMcmJwKQWZD.SjZCsJGxfYuDYri2J1Gos2pUzcmL5iMAEM1KjhI7jKVkwU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A47DA.8090708@andybierman.com> Date: Thu, 01 May 2008 15:44:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ladislav Lhotka References: <481742EF.5030607@andybierman.com> <200804291611.m3TGBTHr088389@idle.juniper.net> <20080429.191023.153396365.mbj@tail-f.com> <48176253.1070102@andybierman.com> <1209495880.15947.5.camel@missotis> <4817740D.5080803@andybierman.com> <1209499369.15947.22.camel@missotis> In-Reply-To: <1209499369.15947.22.camel@missotis> Cc: NETCONF goes on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiDDmnQgMjkuIDA0 LiAyMDA4IHYgMTI6MTYgLTA3MDA6Cj4gCj4+IEV4Y2VsbGVudCBwb2ludC4KPj4gSSBhbSBlbnZp c2lvbmluZyBhIHN5c3RlbSB3aGljaCBpbmNsdWRlcyBhIG1hbmRhdG9yeSBzdGFuZGFyZAo+PiAn c2NoZW1hLWRpc2NvdmVyeScgbWVjaGFuaXNtLiAgVGhlIDxoZWxsbz4gZXhjaGFuZ2UgaXMgYSBi YWQKPj4gcGxhY2UgZm9yIGFsbCB0aGlzIHZlcnNpb25lZCBtb2R1bGUgdG8gbmFtZXNwYWNlIG1h cHBpbmcgaW5mbwo+PiAoZXZlbiB0aG91Z2ggdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGhhdmUgaW1w bGVtZW50ZWQgbm93IDstKQo+IAo+IFdoeSBpcyBpdCBzbyBiYWQ/IFRoZSBiaWcgYWR2YW50YWdl IEkgc2VlIGlzIHRoYXQgaXQgd29ya3Mgd2l0aCB0aGUKPiBleGlzdGluZyBORVRDT05GIGZyYW1l d29yay4KPiAKPj4gVGhlIG5hbWVzcGFjZSBVUkkgc2hvdWxkIGJlIHN0YWJsZS4gIEl0IGlzIGFz c2lnbmVkIGluCj4+IHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBtb2R1bGUuICBJdCBjYW4gbmV2 ZXIgY2hhbmdlLgo+PiBJZiB0aGUgbW9kdWxlIGlzIG9ic29sZXRlLCB0aGUgbmFtZXNwYWNlIGlz IHN0aWxsICd1c2VkIHVwJywKPj4gYW5kIGNhbiBuZXZlciBiZSByZXVzZWQgaW4gYW5vdGhlciBt b2R1bGUuCj4+Cj4+IEluIFhTRCwgdGhlIDxzY2hlbWE+ICd2ZXJzaW9uJyBhdHRyaWJ1dGUgc2hv dWxkIGJlIHVzZWQgaW4gYWRkaXRpb24KPj4gdG8gdGhlIHRhcmdldE5hbWVzcGFjZSwgdG8gZGV0 ZXJtaW5lIHRoZSBleGFjdCBzY2hlbWEgY29udGVudC4KPj4gSW4gWUFORywgZWFjaCBuZXcgdmVy c2lvbiBvZiBhIG1vZHVsZSAoc3RkOk1VU1QvdmVuZG9yOlNIT1VMRCkKPj4gaW5jbHVkZSBhIG5l dyByZXZpc2lvbi1zdG10LCB3aGljaCBoYXMgYSBkYXRlIHN0cmluZyB3aGljaCBiZWNvbWVzCj4+ IHRoZSBuZXcgdmVyc2lvbiBpZGVudGlmaWVyLgo+IAo+IFJFTEFYIE5HIGhhcyBubyBzdWNoIGF0 dHJpYnV0ZSBhbmQgbm9ib2R5IHNlZW1zIHRvIGJlIGNvbXBsYWluaW5nLgo+IFZlcnNpb24gbnVt YmVycyBhcmUgaW5kZWVkIGVuY29kZWQgaW4gbmFtZXNwYWNlIFVSSXMuIEluIG15IHZpZXcsIHRo ZQo+IHJldmlzaW9uIHN0YXRlbWVudCBjb3VsZCBiZSBpbnRlcnByZXRlZCBhcyBhbiBhdXhpbGlh cnkgdmVyc2lvbiBtYXJrZXIKPiBpbnRlbmRlZCBmb3IgaHVtYW4gcmVhZGVycyAtIHRoZSBvbmx5 IGF1dGhvcml0YXRpdmUgaWRlbnRpZmllciBvZiBhIFlBTkcKPiBtb2R1bGUgY29udGVudCB3b3Vs ZCBiZSB0aGUgVVJJLgo+IAoKVGhlIHByb2JsZW0gd2l0aCB0aGlzIGFwcHJvYWNoIGlzIHRoYXQg aXMgaXQgdmVyeSBBUEktdW5mcmllbmRseQpmb3IgTk0gZGV2aWNlcy4gIENvbnNpZGVyIGRvemVu cyBvZiBORVRDT05GIGFwcGxpY2F0aW9ucwp0aGF0IGFyZSBhbGwgdXNpbmcgRk9PLU1JQiB3aXRo IG5hbWVzcGFjZSAiZm9vLW1pYi0xIi4KSWYgYW4gYWdlbnQgaW1wbGVtZW50aW5nIGEgbmV3IHZl cnNpb24gY2hhbmdlcyB0aGUgbmFtZXNwYWNlCnRvICJmb28tbWliLTIiLCBhbGwgdGhlIGFwcGxp Y2F0aW9ucyB0aGF0IGFyZSBjdXJyZW50bHkKdXNpbmcgImZvby1taWItMSIgd2lsbCBicmVhaywg d2hlbiB0YWxraW5nIHRvIHRoYXQgYWdlbnQuCgpTaW5jZSBOTSBtb2R1bGVzIGFyZSBvbmx5IGFs bG93ZWQgdG8gY2hhbmdlIGluIGJhY2t3YXJkLWNvbXBhdGlibGUKd2F5cywgYW5kIHNpbmNlIGJy ZWFraW5nIGV4aXN0aW5nIGFwcGxpY2F0aW9ucyB0byBkZXBsb3kgbmV3IG9uZXMKaXMgbm90IGFj Y2VwdGFibGUsIGl0IGlzIGFjdHVhbGx5IGhhcm1mdWwgdG8gY2hhbmdlIHRoZSBuYW1lc3BhY2Ug VVJJLgoKSWYgdGhlIEZPTy1NSUIgbmVlZHMgdG8gYmUgY2hhbmdlZCBzdWNoIHRoYXQgaXQgYnJl YWtzIGV4aXN0aW5nIEFQSXMsCnRoZW4gYSBuZXcgbW9kdWxlIG11c3QgYmUgZGVmaW5lZCBpbnN0 ZWFkLCB3aXRoIGEgbmV3IG5hbWUgYW5kCmEgbmV3IG5hbWVzcGFjZS4KCgo+IExhZGEKPiAKCkFu ZHkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpOR08g bWFpbGluZyBsaXN0Ck5HT0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25nbwo= From ngo-bounces@ietf.org Thu May 1 19:25:57 2008 Return-Path: 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 D3B483A68E6; Thu, 1 May 2008 19:25:57 -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 E38AE3A68E6 for ; Thu, 1 May 2008 19:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 q0U+qnvL+tTc for ; Thu, 1 May 2008 19:25:56 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6DEA23A684B for ; Thu, 1 May 2008 19:25:53 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 01 May 2008 19:25:49 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 19:25:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m422Prx99806; Thu, 1 May 2008 19:25:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m422OBiX012038; Fri, 2 May 2008 02:24:11 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805020224.m422OBiX012038@idle.juniper.net> To: Andy Bierman In-reply-to: <481A43A5.5060303@andybierman.com> Date: Thu, 01 May 2008 22:24:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 02:25:53.0815 (UTC) FILETIME=[D88A6A70:01C8ABFB] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Andy Bierman writes: >I don't see how multiple sub-agents within a single agent can implement >different versions of the same module, without using different >namespace URIs for each variant. (Maybe somebody can explain >it to me;-) module A { revision 2008-01-01 { ... } grouping one { leaf foo { ... } leaf goo { ... } } } module A { revision 2008-04-01 { ... } grouping one { leaf foo { ... } leaf goo { ... } leaf super-cool { ... } } } module B { import A { revision 2008-01-01; } container zed { uses A:one; } } module C { import A { revision 2008-04-01; } import B { ... } container yancy { uses A:one; } } The use of A's one is a compile time issue, and the revision on the import makes is clear what contents B and C want. yancy will contain super-cool, which zed will not. If there was no revision on import, would zed be forced to contain super-cool as soon as the 2008-04-01 revision of A is published? If you're claiming that this wasn't a problem for MIBs, could you please point me at a couple of MIBs that were rev'd and the history of how successful these were? Thanks, Phil _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 19:40:32 2008 Return-Path: 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 13C263A67AC; Thu, 1 May 2008 19:40:32 -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 B69273A6783 for ; Thu, 1 May 2008 19:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TEw0ogLb5Hc5 for ; Thu, 1 May 2008 19:40:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 70D4B3A69CA for ; Thu, 1 May 2008 19:38:57 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 01 May 2008 19:38:59 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 19:38:25 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m422cOx03034; Thu, 1 May 2008 19:38:24 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m422aij6012087; Fri, 2 May 2008 02:36:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805020236.m422aij6012087@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080501.232635.78733212.mbj@tail-f.com> Date: Thu, 01 May 2008 22:36:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 02:38:25.0086 (UTC) FILETIME=[985545E0:01C8ABFD] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Martin Bjorklund writes: >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. Right, and it may be "none". Consider that I may implement modules that import a module that I simply don't implement. The data/rpc/notifs in the module are not present in my implementation. A module imports another module for four reasons: - to reuse types - to reuse groupings - to augment content - um... er.... wait, I know there was another one In all these cases, I want to reuse/augment a specific revision of the module. I may even implement both a module that imports an older revision of the module and the most modern revision of the module. But the imported revision will make clear what content I'm bringing in. >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. Exactly. And if module B only used groupings/types/etc from A, I could implement B without implementing A at all. >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: This becomes an impediment to readability, and readers are our highest priority. Thanks, Phil _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 19:48:53 2008 Return-Path: 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 EBFB33A69BB; Thu, 1 May 2008 19:48:53 -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 15E563A6921 for ; Thu, 1 May 2008 19:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] 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 9yNOHVf65O6f for ; Thu, 1 May 2008 19:48:47 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 2B8C83A6785 for ; Thu, 1 May 2008 19:48:47 -0700 (PDT) Received: (qmail 2260 invoked from network); 2 May 2008 02:48:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 02:48:47 -0000 X-YMail-OSG: EMnzJFIVM1lX9HwaVem5fFccsn6_D6kWAVIyARuQUnPbpejPfuh.HD.FHWDsk9X2iOQO3vuxUlMBHBHSanhRg1P.M6j1dcVtByPilA8hU6lElS_U8UV8TLAN.xKA6r4A2mQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A810C.1080601@andybierman.com> Date: Thu, 01 May 2008 19:48:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200805020224.m422OBiX012038@idle.juniper.net> In-Reply-To: <200805020224.m422OBiX012038@idle.juniper.net> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > Andy Bierman writes: >> I don't see how multiple sub-agents within a single agent can implement >> different versions of the same module, without using different >> namespace URIs for each variant. (Maybe somebody can explain >> it to me;-) > > module A { > revision 2008-01-01 { ... } > grouping one { > leaf foo { ... } > leaf goo { ... } > } > } > > module A { > revision 2008-04-01 { ... } > grouping one { > leaf foo { ... } > leaf goo { ... } > leaf super-cool { ... } > } > } > > module B { > import A { > revision 2008-01-01; > } > > container zed { > uses A:one; > } > } > > module C { > import A { > revision 2008-04-01; > } > import B { ... } > > container yancy { > uses A:one; > } > } > > The use of A's one is a compile time issue, and the revision > on the import makes is clear what contents B and C want. > yancy will contain super-cool, which zed will not. > > If there was no revision on import, would zed be forced to > contain super-cool as soon as the 2008-04-01 revision of > A is published? > I don't really think this feature is worth the complexity. This seems like it would be better handled in a comprehensive module conformance section, like SMIv2. > If you're claiming that this wasn't a problem for MIBs, > could you please point me at a couple of MIBs that were > rev'd and the history of how successful these were? > IF-MIB, RMON-MIB, RMON2-MIB, ENTITY-MIB This is easy in SMIv2 because the MODULE-CONFORMANCE section can be used to specify the exact leafs in container 'zed' or 'yancy' that are required, optional, deprecated, or obsolete. The module with the uses-stmt needs to specify the conformance for all the grouping contents. Nodes added later to grouping 'one' are not part of the conformance for the 'zed' module. IMO, this is also the only way 'augment-a-grouping' is ever going to work in an inter-operable manner. > Thanks, > Phil > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 19:57:11 2008 Return-Path: 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 AF0B53A6B54; Thu, 1 May 2008 19:57:11 -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 1C6A13A6B68 for ; Thu, 1 May 2008 19:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] 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 EecAtD+DnXqh for ; Thu, 1 May 2008 19:57:09 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 302313A6B45 for ; Thu, 1 May 2008 19:57:09 -0700 (PDT) Received: (qmail 43287 invoked from network); 2 May 2008 02:57:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 2 May 2008 02:57:09 -0000 X-YMail-OSG: DEK0TRkVM1lokphP3Oddu3ty2rOrWg3fEtVtbKBnfNF2uMPF7lVB7UfcDkPUIzNRXxVdaDfT5miU_i.FH0GU1qVwAFoKSq4vi4579hXn7ExH_iHuKQXB0XhztBG0A6LP06o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <481A8302.4050006@andybierman.com> Date: Thu, 01 May 2008 19:57:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200805020224.m422OBiX012038@idle.juniper.net> <481A810C.1080601@andybierman.com> In-Reply-To: <481A810C.1080601@andybierman.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> I don't see how multiple sub-agents within a single agent can implement >>> different versions of the same module, without using different >>> namespace URIs for each variant. (Maybe somebody can explain >>> it to me;-) >> module A { >> revision 2008-01-01 { ... } >> grouping one { >> leaf foo { ... } >> leaf goo { ... } >> } >> } >> >> module A { >> revision 2008-04-01 { ... } >> grouping one { >> leaf foo { ... } >> leaf goo { ... } >> leaf super-cool { ... } >> } >> } >> >> module B { >> import A { >> revision 2008-01-01; >> } >> >> container zed { >> uses A:one; >> } >> } >> >> module C { >> import A { >> revision 2008-04-01; >> } >> import B { ... } >> >> container yancy { >> uses A:one; >> } >> } >> >> The use of A's one is a compile time issue, and the revision >> on the import makes is clear what contents B and C want. >> yancy will contain super-cool, which zed will not. >> >> If there was no revision on import, would zed be forced to >> contain super-cool as soon as the 2008-04-01 revision of >> A is published? >> > > I don't really think this feature is worth the complexity. > This seems like it would be better handled in a comprehensive > module conformance section, like SMIv2. > >> If you're claiming that this wasn't a problem for MIBs, >> could you please point me at a couple of MIBs that were >> rev'd and the history of how successful these were? >> > > IF-MIB, RMON-MIB, RMON2-MIB, ENTITY-MIB > > This is easy in SMIv2 because the MODULE-CONFORMANCE section > can be used to specify the exact leafs in container 'zed' or 'yancy' > that are required, optional, deprecated, or obsolete. The module > with the uses-stmt needs to specify the conformance for all > the grouping contents. Nodes added later to grouping 'one' > are not part of the conformance for the 'zed' module. > > IMO, this is also the only way 'augment-a-grouping' is ever going to > work in an inter-operable manner. > Reason: What if the new 2008-06-01 version of A has another super-cool feature in the 'one' grouping (or anywhere else in the module) that module 'zed' wants to use? The 'import 2008-06-01' would break module zed because it would also pick up the 'super-cool' leaf from version '2008-04-01', and any other changes made in the interim. Explicit module conformance, tied to each module release, is the only way to maintain the flexibility needed by agents and the accuracy needed by applications. >> Thanks, >> Phil >> > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 20:10:54 2008 Return-Path: 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 E57863A69EB; Thu, 1 May 2008 20:10:54 -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 1332B3A686C for ; Thu, 1 May 2008 20:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 e5QyWYFP41Eo for ; Thu, 1 May 2008 20:10:52 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 443DC3A6DAD for ; Thu, 1 May 2008 20:10:14 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 01 May 2008 20:09:54 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 20:10:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m423ACx10716; Thu, 1 May 2008 20:10:12 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m4238Xan012658; Fri, 2 May 2008 03:08:33 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805020308.m4238Xan012658@idle.juniper.net> To: Andy Bierman In-reply-to: <481A810C.1080601@andybierman.com> Date: Thu, 01 May 2008 23:08:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 03:10:13.0379 (UTC) FILETIME=[09C3AD30:01C8AC02] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Andy Bierman writes: >This seems like it would be better handled in a comprehensive >module conformance section, like SMIv2. Can you walk me thru such a comprehensive module conformance section for the example I gave? Thanks, Phil _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Thu May 1 20:20:21 2008 Return-Path: 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 6A69C3A6C25; Thu, 1 May 2008 20:20:21 -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 21CBF3A6B54 for ; Thu, 1 May 2008 20:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] 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 DhgW7Qtp3lij for ; Thu, 1 May 2008 20:20:19 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 034BA3A6DB3 for ; Thu, 1 May 2008 20:19:45 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Thu, 01 May 2008 20:19:38 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 20:19:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m423Jix12400; Thu, 1 May 2008 20:19:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m423I5WB012759; Fri, 2 May 2008 03:18:05 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805020318.m423I5WB012759@idle.juniper.net> To: Andy Bierman In-reply-to: <481A8302.4050006@andybierman.com> Date: Thu, 01 May 2008 23:18:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 May 2008 03:19:45.0430 (UTC) FILETIME=[5EBBBB60:01C8AC03] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Andy Bierman writes: >What if the new 2008-06-01 version of A has another super-cool feature >in the 'one' grouping (or anywhere else in the module) that module 'zed' >wants to use? When the module owner wants to rev their module, they'll need to explicitly update their module to handle it, rev'ing their module to prevent the change from rippling down the import chain to unsuspecting modules that don't have a comprehensive module conformance section. Thanks, Phil _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Sat May 3 13:40:48 2008 Return-Path: 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 DDCB13A6B5B; Sat, 3 May 2008 13:40:48 -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 42B973A6B5B for ; Sat, 3 May 2008 13:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=0.047, 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 a8+zfFUpWcD0 for ; Sat, 3 May 2008 13:40:46 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 1DA8E3A6B31 for ; Sat, 3 May 2008 13:40:46 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 601501B80CA; Sat, 3 May 2008 22:40:41 +0200 (CEST) Date: Sat, 03 May 2008 22:40:32 +0200 (CEST) Message-Id: <20080503.224032.27961815.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <002101c8abd1$493e66c0$6801a8c0@oemcomputer> References: <200805012045.m41KjmAp009395@idle.juniper.net> <20080501.232635.78733212.mbj@tail-f.com> <002101c8abd1$493e66c0$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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: ; > > Sent: Thursday, May 01, 2008 3:26 PM > > Subject: Re: [NGO] external module properties > ... > > 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. > ... > > This is an excellent example of the consequences of choosing (perhaps > unconsiously) a particular meta-model. Consider, for example, what > happens if RPCs and notifications are associated not with "the device", > but with a particular object class. (One possible object class is a stand-in > for "the device" which would be appropriate for those few things like > "reboot" which really do apply to the entire device.) > If the module defining a particular class imports a pre-defined notification > or RPC, versioning would work just like for anything else. Consequently, > a "device" would no longer be limited to implementing just one version > of an RPC. > > Ancient use case: consider a "Rewind" RPC. System has several tape > drives from various vendors, possibly from different technology > generations. Someone updates "Rewind" to include a "energy > conservation" option. When a new drive supporting that option in > its Rewind RPC is installed, it should not require changing the > software for all the other drives. This is an interesting problem, but I think it is separate from the issue about importing w/ or w/o versions? You will have the rewind problem in a single module with a single rpc, when the module gets updated with the new parameter. I don't know if you're suggesting that the client should send version information in the request (rpc rewind-1.0 vs. rpc rewind-1.1)? I don't think this solves the problem anyway. IMO, the server will implement the rpc with the new parameter, and then it will have to translate this into native function calls to the drivers, and in that process reject requests it cannot handle. /martin _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Sat May 3 13:52:42 2008 Return-Path: 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 6017A3A6BB1; Sat, 3 May 2008 13:52:42 -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 A306F3A6A47 for ; Sat, 3 May 2008 13:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=0.044, 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 Tg07ltymD36n for ; Sat, 3 May 2008 13:52:39 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id C1F8E3A6814 for ; Sat, 3 May 2008 13:52:39 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 4054C1B80C7; Sat, 3 May 2008 22:52:34 +0200 (CEST) Date: Sat, 03 May 2008 22:52:27 +0200 (CEST) Message-Id: <20080503.225227.76853664.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805020236.m422aij6012087@idle.juniper.net> References: <20080501.232635.78733212.mbj@tail-f.com> <200805020236.m422aij6012087@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Hi, Phil Shafer wrote: > Martin Bjorklund writes: > >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. > > Right, and it may be "none". Consider that I may implement > modules that import a module that I simply don't implement. > The data/rpc/notifs in the module are not present in my implementation. > > A module imports another module for four reasons: > - to reuse types > - to reuse groupings > - to augment content > - um... er.... wait, I know there was another one > > In all these cases, I want to reuse/augment a specific revision > of the module. Yes, except for augment. What does it mean if B augments version 1 of A, and a device implements B and version 2 of A? IMO it is ok, since the rules for upgrading a module ensures that no nodes are removed and so on. So a versioned import is strict for compile time properties like types and grouping, but for runtime properties the upgrade rules make sure that a later version of the module can be used. This means that in runtime, the device implements one specific version of a module. > >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. > > Exactly. And if module B only used groupings/types/etc from A, > I could implement B without implementing A at all. Right. /martin _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo