From netmod-bounces@ietf.org Mon Dec 1 05:31:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0329C3A6809; Mon, 1 Dec 2008 05:31:08 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86993A6C28 for ; Mon, 1 Dec 2008 05:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KCrmzNCh7wgq for ; Mon, 1 Dec 2008 05:31:06 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id CA86C3A6809 for ; Mon, 1 Dec 2008 05:28:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSTPmjEQun2HUA0UtsBj+5DD1TimINJs+@postini.com; Mon, 01 Dec 2008 05:28:45 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 1 Dec 2008 05:24:22 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 05:24:22 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 05:24:21 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 05:24:21 -0800 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 mB1DOKM51554; Mon, 1 Dec 2008 05:24:20 -0800 (PST) (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 mB1DJ7Sl090716; Mon, 1 Dec 2008 13:19:08 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812011319.mB1DJ7Sl090716@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <49339F30.5060905@ericsson.com> Date: Mon, 1 Dec 2008 08:19:07 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 13:24:21.0225 (UTC) FILETIME=[1EC78590:01C953B8] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >IMHO this is not such a rare case. Our designers have been asking for it alrea >dy. >We can live with the current solution, but it's not nice. The current scheme is that your can use submodules, but if you do, you should use them completely, putting nothing in your main module that any submodule might (ever) need. In a way, it's an all or nothing approach. This simple approach avoids many corner issues. I don't see any convincing downside or "not nice" issues. If you want submodules, use them thoroughly. If you don't, avoid them. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 05:58:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E1A3A689F; Mon, 1 Dec 2008 05:58:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE62C3A696B for ; Mon, 1 Dec 2008 05:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 o6LAczH0PCMG for ; Mon, 1 Dec 2008 05:58:45 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E25233A689F for ; Mon, 1 Dec 2008 05:58:44 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E2F45D800D1; Mon, 1 Dec 2008 14:58:40 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200812011319.mB1DJ7Sl090716@idle.juniper.net> References: <200812011319.mB1DJ7Sl090716@idle.juniper.net> Organization: CESNET Date: Mon, 01 Dec 2008 14:58:41 +0100 Message-Id: <1228139921.6259.85.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMDEuIDEyLiAyMDA4IHYgMDg6MTkgLTA1MDA6Cj4gQmFs YXpzIExlbmd5ZWwgd3JpdGVzOgo+ID5JTUhPIHRoaXMgaXMgbm90IHN1Y2ggYSByYXJlIGNhc2Uu IE91ciBkZXNpZ25lcnMgaGF2ZSBiZWVuIGFza2luZyBmb3IgaXQgYWxyZWEKPiA+ZHkuCj4gPldl IGNhbiBsaXZlIHdpdGggdGhlIGN1cnJlbnQgc29sdXRpb24sIGJ1dCBpdCdzIG5vdCBuaWNlLgo+ IAo+IFRoZSBjdXJyZW50IHNjaGVtZSBpcyB0aGF0IHlvdXIgY2FuIHVzZSBzdWJtb2R1bGVzLCBi dXQgaWYgeW91IGRvLAo+IHlvdSBzaG91bGQgdXNlIHRoZW0gY29tcGxldGVseSwgcHV0dGluZyBu b3RoaW5nIGluIHlvdXIgbWFpbiBtb2R1bGUKPiB0aGF0IGFueSBzdWJtb2R1bGUgbWlnaHQgKGV2 ZXIpIG5lZWQuICBJbiBhIHdheSwgaXQncyBhbiBhbGwgb3IKPiBub3RoaW5nIGFwcHJvYWNoLiAg VGhpcyBzaW1wbGUgYXBwcm9hY2ggYXZvaWRzIG1hbnkgY29ybmVyIGlzc3Vlcy4KCkxpa2Ugd2hh dD8gSU1PIHRoZSBvbmx5IGNoYW5nZSB3b3VsZCBiZSB0aGF0IHRoZSBzeW1ib2wgbG9va3VwIHdp bGwKY29udGludWUgZnJvbSB0aGUgc3VibW9kdWxlIHRvIGl0cyBwYXJlbnQgbW9kdWxlJ3MgdG9w IGxldmVsIGNvbnRleHQuIEkKYW0gbm90IGF3YXJlIG9mIGFueSBwcm9ibGVtIHRoaXMgY291bGQg Y2F1c2UuCgo+IEkgZG9uJ3Qgc2VlIGFueSBjb252aW5jaW5nIGRvd25zaWRlIG9yICJub3Qgbmlj ZSIgaXNzdWVzLiAgSWYgeW91Cj4gd2FudCBzdWJtb2R1bGVzLCB1c2UgdGhlbSB0aG9yb3VnaGx5 LiAgSWYgeW91IGRvbid0LCBhdm9pZCB0aGVtLgoKVGhlIGRvd25zaWRlIGlzIG9mIGNvdXJzZSB0 aGF0IGlmIHlvdSBoYXZlIGRlZmluaXRpb25zIHRoYXQgYXJlIGNvbW1vbgp0byB0aGUgbWFpbiBt b2R1bGUgYW5kIHN1Ym1vZHVsZXMsIHlvdSBjYW4ndCB1c2UgdGhlbSBmcm9tIHRoZSBtYWluCm1v ZHVsZSBidXQgcmF0aGVyIHRoZXkgaGF2ZSB0byBiZSBwdXQgdG8gYSBzcGVjaWFsIHN1Ym1vZHVs ZS4gVGhpcyBtZWFucwp0aGF0IGFkZGluZyBhIHN1Ym1vZHVsZSBtYXkgc29tZXRpbWVzIHJlcXVp cmUgcmVmYWN0b3JpbmcgdGhlIG1haW4KbW9kdWxlIG9yIGNvcHlpbmcgdGhlIG5lZWRlZCBkZWZp bml0aW9ucyB1bmRlciBkaWZmZXJlbnQgbmFtZXMgdG8gdGhlCnN1Ym1vZHVsZS4KCkFsc28sIGlm IEkgcmVtZW1iZXIgY29ycmVjdGx5IGZyb20gdGhlIGludGVyaW0sIEJhbGF6cyBkZW1hbmRlZCB0 aGF0IHRoZQoidG9wLWxldmVsIGF1Z21lbnQiIGNvbnRpbnVlIHRvIGJlIGFibGUgdG8gYWRkcmVz cyB0YXJnZXQgbm9kZXMgaW4gdGhlCmxvY2FsIG1vZHVsZSwgbm90IGp1c3QgaW4gZXh0ZXJuYWwg bW9kdWxlcywgYW5kIHRoZSB1c2UgY2FzZSB3YXMgdGhlCnBvc3NpYmlsaXR5IG9mIGF0dGFjaGlu ZyBzdWJtb2R1bGUgY29udGVudCB0byBhIG5vbi1yb290IG5vZGUgaW4gdGhlCm1haW4gbW9kdWxl LiBTbyB0aGlzIGFjdHVhbGx5IGlzIG5vdCBhbGxvd2VkLCByaWdodD8KCkxhZGEKCj4gCj4gVGhh bmtzLAo+ICBQaGlsCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwg Q0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 06:03:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4143A6909; Mon, 1 Dec 2008 06:03:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9EB3A6909 for ; Mon, 1 Dec 2008 06:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 Xk5UV8HVAE+z for ; Mon, 1 Dec 2008 06:03:22 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A48523A689F for ; Mon, 1 Dec 2008 06:03:22 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1AFF0D800CC for ; Mon, 1 Dec 2008 15:03:19 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Mon, 01 Dec 2008 15:03:19 +0100 Message-Id: <1228140199.6259.90.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, is this allowed or is it considered a circular include? module M { ... include S1; include S2; ... } submodule S1 { belongs-to M; include S2; ... } submodule S2 { belongs-to M; ... } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 06:38:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0AE3A67F6; Mon, 1 Dec 2008 06:38:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D63F3A6827 for ; Mon, 1 Dec 2008 06:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 BXtMXu-S4NGB for ; Mon, 1 Dec 2008 06:38:21 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 261A33A67F6 for ; Mon, 1 Dec 2008 06:38:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSTP21++aZKXPkiee1Kw9G9mmph32dQ5t@postini.com; Mon, 01 Dec 2008 06:38:18 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 1 Dec 2008 06:33:47 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 06:33:46 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 06:33:46 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 06:33:46 -0800 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 mB1EXjM81915; Mon, 1 Dec 2008 06:33:45 -0800 (PST) (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 mB1ESW0h091402; Mon, 1 Dec 2008 14:28:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812011428.mB1ESW0h091402@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1228139921.6259.85.camel@missotis> Date: Mon, 1 Dec 2008 09:28:32 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 14:33:46.0061 (UTC) FILETIME=[D1370FD0:01C953C1] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >Like what? One of the use cases for submodules is to allow separate compilation. If submodules include modules which include submodules, this is no longer reasonable. >The downside is of course that if you have definitions that are common >to the main module and submodules, you can't use them from the main >module but rather they have to be put to a special submodule. This isn't a downside, but a requirement that you put definitions that are common into a submodule, so that can be used by other submodules. This gives us a BCP of "don't put anything in the module except the include statements for submodules and any glue needed to tie them together". If you use submodules, you should use them completely, avoiding putting anything in the module that submodules might need. Can you give a use case where this isn't possible? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 07:20:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490FC3A69DE; Mon, 1 Dec 2008 07:20:05 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580D43A6A48 for ; Mon, 1 Dec 2008 07:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 jTrrCA8dZsIG for ; Mon, 1 Dec 2008 07:20:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7D9323A69DE for ; Mon, 1 Dec 2008 07:20:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CFDF6616006; Mon, 1 Dec 2008 16:19:58 +0100 (CET) Date: Mon, 01 Dec 2008 16:19:58 +0100 (CET) Message-Id: <20081201.161958.89109710.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1228140199.6259.90.camel@missotis> References: <1228140199.6259.90.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > is this allowed or is it considered a circular include? This is allowed. /martin > > module M { > ... > include S1; > include S2; > ... > } > > submodule S1 { > belongs-to M; > include S2; > ... > } > > submodule S2 { > belongs-to M; > ... > } > > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 08:04:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5F93A68A9; Mon, 1 Dec 2008 08:04:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDA63A68D0 for ; Mon, 1 Dec 2008 08:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 5LWz6FgBaQEm for ; Mon, 1 Dec 2008 08:04:06 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6FD113A68A9 for ; Mon, 1 Dec 2008 08:04:06 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9179AD800C8; Mon, 1 Dec 2008 17:04:02 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200812011428.mB1ESW0h091402@idle.juniper.net> References: <200812011428.mB1ESW0h091402@idle.juniper.net> Organization: CESNET Date: Mon, 01 Dec 2008 17:04:03 +0100 Message-Id: <1228147443.6259.129.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMDEuIDEyLiAyMDA4IHYgMDk6MjggLTA1MDA6Cj4gTGFk aXNsYXYgTGhvdGthIHdyaXRlczoKPiA+TGlrZSB3aGF0Pwo+IAo+IE9uZSBvZiB0aGUgdXNlIGNh c2VzIGZvciBzdWJtb2R1bGVzIGlzIHRvIGFsbG93IHNlcGFyYXRlIGNvbXBpbGF0aW9uLgo+IElm IHN1Ym1vZHVsZXMgaW5jbHVkZSBtb2R1bGVzIHdoaWNoIGluY2x1ZGUgc3VibW9kdWxlcywgdGhp cyBpcyBubwo+IGxvbmdlciByZWFzb25hYmxlLgoKSG93IHRoaXMgY291bGQgYmUgYSBwcm9ibGVt IGdpdmVuIHRoYXQgbmFtZXNwYWNlcyBvZiBkaWZmZXJlbnQgbW9kdWxlcwphcmUgY29tcGxldGVs eSBzZXBhcmF0ZWQ/IEkgZG9uJ3Qga25vdyB3aGF0IHRoaXMgInNlcGFyYXRlIGNvbXBpbGF0aW9u IgpleGFjdGx5IG1lYW5zLCBidXQgdGhlcmUgY2Fubm90IGJlIGFueSBjb25mbGljdCBiZXR3ZWVu IHVucmVzb2x2ZWQKcmVmZXJlbmNlcyB0byB0aGUgcGFyZW50IG1vZHVsZSBhbmQgZXh0ZXJuYWwg bW9kdWxlICh3aGV0aGVyIGl0IGhhcwpzdWJtb2R1bGVzIG9yIG5vdCkuCgo+IAo+ID5UaGUgZG93 bnNpZGUgaXMgb2YgY291cnNlIHRoYXQgaWYgeW91IGhhdmUgZGVmaW5pdGlvbnMgdGhhdCBhcmUg Y29tbW9uCj4gPnRvIHRoZSBtYWluIG1vZHVsZSBhbmQgc3VibW9kdWxlcywgeW91IGNhbid0IHVz ZSB0aGVtIGZyb20gdGhlIG1haW4KPiA+bW9kdWxlIGJ1dCByYXRoZXIgdGhleSBoYXZlIHRvIGJl IHB1dCB0byBhIHNwZWNpYWwgc3VibW9kdWxlLgo+IAo+IFRoaXMgaXNuJ3QgYSBkb3duc2lkZSwg YnV0IGEgcmVxdWlyZW1lbnQgdGhhdCB5b3UgcHV0IGRlZmluaXRpb25zCj4gdGhhdCBhcmUgY29t bW9uIGludG8gYSBzdWJtb2R1bGUsIHNvIHRoYXQgY2FuIGJlIHVzZWQgYnkgb3RoZXIKPiBzdWJt b2R1bGVzLiAgVGhpcyBnaXZlcyB1cyBhIEJDUCBvZiAiZG9uJ3QgcHV0IGFueXRoaW5nIGluIHRo ZQo+IG1vZHVsZSBleGNlcHQgdGhlIGluY2x1ZGUgc3RhdGVtZW50cyBmb3Igc3VibW9kdWxlcyBh bmQgYW55IGdsdWUKPiBuZWVkZWQgdG8gdGllIHRoZW0gdG9nZXRoZXIiLiAgSWYgeW91IHVzZSBz dWJtb2R1bGVzLCB5b3Ugc2hvdWxkCj4gdXNlIHRoZW0gY29tcGxldGVseSwgYXZvaWRpbmcgcHV0 dGluZyBhbnl0aGluZyBpbiB0aGUgbW9kdWxlIHRoYXQKPiBzdWJtb2R1bGVzIG1pZ2h0IG5lZWQu ICBDYW4geW91IGdpdmUgYSB1c2UgY2FzZSB3aGVyZSB0aGlzIGlzbid0Cj4gcG9zc2libGU/CgpU aGUgZGVjaXNpb24gdG8gdXNlIHN1Ym1vZHVsZXMgbWF5IGNvbWUgaW4gYSBsYXRlciBwaGFzZS4g SSBhbSBub3QKc2F5aW5nIHNvbWV0aGluZyBpcyBpbXBvc3NpYmxlLCBqdXN0IHRoYXQgaXQgaXMg Y2x1bXN5IGFuZCBub3QgZm9yIGEKZ29vZCByZWFzb24uIFRoZSBiZXN0IHBsYWNlIGZvciBjb21t b24gZGVmaW5pdGlvbnMgaXMgdGhlIHBhcmVudCBvZiBhbGwKc3VibW9kdWxlcy4KCkxhZGEKCj4g Cj4gVGhhbmtzLAo+ICBQaGlsCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElE OiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 1 08:13:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40913A6AAE; Mon, 1 Dec 2008 08:13:04 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ECEC3A6AF4 for ; Mon, 1 Dec 2008 08:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 aGk0eK5hD2k3 for ; Mon, 1 Dec 2008 08:13:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C58383A6AAE for ; Mon, 1 Dec 2008 08:13:02 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 282D4D800CE; Mon, 1 Dec 2008 17:12:59 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081201.161958.89109710.mbj@tail-f.com> References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> Organization: CESNET Date: Mon, 01 Dec 2008 17:12:59 +0100 Message-Id: <1228147979.6259.134.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwMS4gMTIuIDIwMDggdiAxNjoxOSArMDEwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gSGksCj4gPiAK PiA+IGlzIHRoaXMgYWxsb3dlZCBvciBpcyBpdCBjb25zaWRlcmVkIGEgY2lyY3VsYXIgaW5jbHVk ZT8KPiAKPiBUaGlzIGlzIGFsbG93ZWQuCgpCdXQgdGhlIG1haW4gbW9kdWxlIGdldHMgdGhlIGRl ZmluaXRpb25zIGZyb20gUzEgdHdpY2UuIFdoeSBpcyB0aGlzCmRpZmZlcmVudCBmcm9tIHRoZSBj YXNlIG9mIGEgc2hvcnRlciBjaXJjbGUsIG5hbWVseSB3aGVuIFMyIGFsc28KaW5jbHVkZXMgUzE/ IFRoaXMgaXMgZXhwbGljaXRseSBmb3JiaWRkZW4gaW4gdGhlIGRyYWZ0LgoKTGFkYQoKPiAKPiAK PiAvbWFydGluCj4gCj4gCj4gCj4gPiAKPiA+IG1vZHVsZSBNIHsKPiA+ICAgLi4uCj4gPiAgIGlu Y2x1ZGUgUzE7Cj4gPiAgIGluY2x1ZGUgUzI7Cj4gPiAgIC4uLgo+ID4gfQo+ID4gCj4gPiBzdWJt b2R1bGUgUzEgewo+ID4gICBiZWxvbmdzLXRvIE07Cj4gPiAgIGluY2x1ZGUgUzI7Cj4gPiAgIC4u Lgo+ID4gfQo+ID4gCj4gPiBzdWJtb2R1bGUgUzIgewo+ID4gICBiZWxvbmdzLXRvIE07Cj4gPiAg IC4uLgo+ID4gfQo+ID4gCj4gPiBMYWRhCj4gPiAKPiA+IC0tIAo+ID4gTGFkaXNsYXYgTGhvdGth LCBDRVNORVQKPiA+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDCj4gPiAKPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0 Cj4gPiBuZXRtb2RAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kCj4gPiAKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6 IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 09:32:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492813A6876; Mon, 1 Dec 2008 09:32:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EE03A6ACE for ; Mon, 1 Dec 2008 09:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.465, 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 xirHgla8khgM for ; Mon, 1 Dec 2008 09:32:13 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 778933A6B3C for ; Mon, 1 Dec 2008 09:31:12 -0800 (PST) Received: (qmail 55450 invoked from network); 1 Dec 2008 17:31:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 17:31:06 -0000 X-YMail-OSG: A_Ui0cAVM1nB6yFA0OSih5qJl5hIke2G.KXJq8nEO6xP5iScgKPhaF_3iDroxPLB5WCDP1lxYJwBM8TtjP3zR92DL7gsyPTm_NQYW5QttPkO0drSPwh3rZZOehzOyUCHDUeqDIcou6AfuGPnM0z9mIIK X-Yahoo-Newman-Property: ymail-3 Message-ID: <49341F58.6030100@netconfcentral.com> Date: Mon, 01 Dec 2008 09:31:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> <1228147979.6259.134.camel@missotis> In-Reply-To: <1228147979.6259.134.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IE1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgUG8gMDEu IDEyLiAyMDA4IHYgMTY6MTkgKzAxMDA6Cj4+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQGNlc25l dC5jej4gd3JvdGU6Cj4+PiBIaSwKPj4+Cj4+PiBpcyB0aGlzIGFsbG93ZWQgb3IgaXMgaXQgY29u c2lkZXJlZCBhIGNpcmN1bGFyIGluY2x1ZGU/Cj4+IFRoaXMgaXMgYWxsb3dlZC4KPiAKPiBCdXQg dGhlIG1haW4gbW9kdWxlIGdldHMgdGhlIGRlZmluaXRpb25zIGZyb20gUzEgdHdpY2UuIFdoeSBp cyB0aGlzCj4gZGlmZmVyZW50IGZyb20gdGhlIGNhc2Ugb2YgYSBzaG9ydGVyIGNpcmNsZSwgbmFt ZWx5IHdoZW4gUzIgYWxzbwo+IGluY2x1ZGVzIFMxPyBUaGlzIGlzIGV4cGxpY2l0bHkgZm9yYmlk ZGVuIGluIHRoZSBkcmFmdC4KPiAKCkl0IGlzIGRpZmZlcmVudCBiZWNhdXNlIG5vIGluY2x1ZGUg bG9vcHMgYXJlIGNyZWF0ZWQuClRoZSBjb21waWxlciBoYXMgdG8gYmUgY2xldmVyIGVub3VnaCB0 byBkZXRlY3QgbG9vcHMKYWNyb3NzIE4gZmlsZXMsIGFuZCBub3QgZ2VuZXJhdGUgb3V0cHV0IGZv ciBkdXBsaWNhdGUKc3ViLW1vZHVsZSBpbmNsdWRlcy4gIEkgZG91YnQgYW55IFBMIG9yIERNTCBl dmVyIGNyZWF0ZWQgcGVybWl0cwppbmNsdWRlIG9yIGltcG9ydCBsb29wcy4KCkFsdGhvdWdoIG5v dCBpbnR1aXRpdmUsIGEgc3VibW9kdWxlIG5lc3RlZCAxMDAwIGxheWVycwpkZWVwIChTMSBpbmMg UzIgaW5jIFMzLi4uKSBnZW5lcmF0ZXMgdGhlIHNhbWUgdG9wLWxldmVsCm9iamVjdHMgYW5kIHR5 cGVkZWZzIGFzIGlmIHRoZSBkZWZpbml0aW9ucyB3ZXJlIGluIHRoZQptYWluIG1vZHVsZS4gIFRo ZXJlIGlzIG5vIG9iamVjdCBoaWVyYXJjaHkgY3JlYXRlZCBvciBpbXBsaWVkCmJ5IHRoZSBzdWJt b2R1bGUgaGllcmFyY2h5LiAgU3VibW9kdWxlcyBhcmUgbWVyZWx5IGNvbnRhaW5lcnMKb2YgZGVm aW5pdGlvbnMsIGFsbG93aW5nIERNIGRlc2lnbmVycyB0byBkZWNvdXBsZSB0aGUgbW9kdWxlCm5h bWVzcGFjZSBmcm9tIHRoZSBwaHlzaWNhbCBmaWxlLiAgVGhlIGNvdXBsaW5nIGNhbiBiZSAxOk4K aW5zdGVhZCBvZiAxOjEsIGlmIHNvIGRlc2lyZWQuCgoKPiBMYWRhCj4gCgpBbmR5Cgo+Pgo+PiAv bWFydGluCj4+Cj4+Cj4+Cj4+PiBtb2R1bGUgTSB7Cj4+PiAgIC4uLgo+Pj4gICBpbmNsdWRlIFMx Owo+Pj4gICBpbmNsdWRlIFMyOwo+Pj4gICAuLi4KPj4+IH0KPj4+Cj4+PiBzdWJtb2R1bGUgUzEg ewo+Pj4gICBiZWxvbmdzLXRvIE07Cj4+PiAgIGluY2x1ZGUgUzI7Cj4+PiAgIC4uLgo+Pj4gfQo+ Pj4KPj4+IHN1Ym1vZHVsZSBTMiB7Cj4+PiAgIGJlbG9uZ3MtdG8gTTsKPj4+ICAgLi4uCj4+PiB9 Cj4+Pgo+Pj4gTGFkYQo+Pj4KPj4+IC0tIAo+Pj4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKPj4+ IFBHUCBLZXkgSUQ6IEU3NEU4QzBDCj4+Pgo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4+IG5ldG1vZEBp ZXRmLm9yZwo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK Pj4+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0 bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 1 09:44:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0C03A6AF4; Mon, 1 Dec 2008 09:44:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C5A3A6B3D for ; Mon, 1 Dec 2008 09:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.310, 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 1DWwZCq3SoVO for ; Mon, 1 Dec 2008 09:44:50 -0800 (PST) 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 5DEC93A6B25 for ; Mon, 1 Dec 2008 09:44:50 -0800 (PST) Received: (qmail 2970 invoked from network); 1 Dec 2008 17:44:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 17:44:44 -0000 X-YMail-OSG: w8Q1_koVM1nBJ0iEiyZR2i.SbR68UfKeGW7O1DVhvAEfOKjSARSMT0FIgGwqIVeqgyKKdw9Z66uxpC9rHoaRt_KJ4Qob89bR8QRUrnuzT7miO5b1eqdpLMQxMgu_wvQnDFM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4934228B.2010901@netconfcentral.com> Date: Mon, 01 Dec 2008 09:44:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <200812011319.mB1DJ7Sl090716@idle.juniper.net> <1228139921.6259.85.camel@missotis> In-Reply-To: <1228139921.6259.85.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IFBvIDAxLiAxMi4g MjAwOCB2IDA4OjE5IC0wNTAwOgo+PiBCYWxhenMgTGVuZ3llbCB3cml0ZXM6Ci4uLi4KPiBBbHNv LCBpZiBJIHJlbWVtYmVyIGNvcnJlY3RseSBmcm9tIHRoZSBpbnRlcmltLCBCYWxhenMgZGVtYW5k ZWQgdGhhdCB0aGUKPiAidG9wLWxldmVsIGF1Z21lbnQiIGNvbnRpbnVlIHRvIGJlIGFibGUgdG8g YWRkcmVzcyB0YXJnZXQgbm9kZXMgaW4gdGhlCj4gbG9jYWwgbW9kdWxlLCBub3QganVzdCBpbiBl eHRlcm5hbCBtb2R1bGVzLCBhbmQgdGhlIHVzZSBjYXNlIHdhcyB0aGUKPiBwb3NzaWJpbGl0eSBv ZiBhdHRhY2hpbmcgc3VibW9kdWxlIGNvbnRlbnQgdG8gYSBub24tcm9vdCBub2RlIGluIHRoZQo+ IG1haW4gbW9kdWxlLiBTbyB0aGlzIGFjdHVhbGx5IGlzIG5vdCBhbGxvd2VkLCByaWdodD8KPiAK ClJlYWxseT8KSW4gdGhhdCBjYXNlIHRoZXJlIGlzIG5vIHBvaW50IHRvIHRoZSBDTFIgdGhhdCBh dWdtZW50LXN0bXQgb25seSBhcHBlYXIKYXQgdGhlIHRvcC1sZXZlbCBvciBpbnNpZGVzIHVzZXMt c3RtdC4gIFRoZSBvbmx5IHVzZS1jYXNlIHdhcyB0aGUgd2hlbgpjbGF1c2UsIGJ1dCB0aGF0IGlz IG5vdyBhbGxvd2VkIGV2ZXJ5d2hlcmUsIG5vdCBqdXN0IGluc2lkZSBhdWdtZW50LXN0bXQuCgpV bmxlc3MgdGhlIHRvcC1sZXZlbCBhdWdtZW50IGlzICdleHRlcm5hbCBuYW1lc3BhY2Ugb25seScs CnRoZW4gYXVnbWVudC1zdG10IHNob3VsZCBiZSBhbGxvd2VkIGV2ZXJ5d2hlcmUuICBOb3RoaW5n IHdoYXRzb2V2ZXIKaXMgc2ltcGxpZmllZCBpbiB0aGUgY29kZSBidXQgcmVtb3Zpbmcgb25seSBv bmUgb2YgdGhlIHR3bwpsb2NhbCBhdWdtZW50IHZhcmlhbnRzLiAgSXQganVzdCBnaXZlcyB1c2Vy cyBvbmUgbW9yZSBDTFIKdG8gcmVtZW1iZXIgYW5kIHdvcmsgYXJvdW5kLgoKCj4gTGFkYQo+IAo+ PiBUaGFua3MsCj4+ICBQaGlsCgpBbmR5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 11:21:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943C43A682E; Mon, 1 Dec 2008 11:21:17 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF21A3A6843 for ; Mon, 1 Dec 2008 11:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 Mukjjne3RpEI for ; Mon, 1 Dec 2008 11:21:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0640F3A687C for ; Mon, 1 Dec 2008 11:21:15 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A00F5D800C8; Mon, 1 Dec 2008 20:21:10 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49341F58.6030100@netconfcentral.com> References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> <1228147979.6259.134.camel@missotis> <49341F58.6030100@netconfcentral.com> Organization: CESNET Date: Mon, 01 Dec 2008 20:21:11 +0100 Message-Id: <1228159272.6259.167.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDAxLiAxMi4gMjAwOCB2IDA5OjMxIC0wODAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IE1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgUG8gMDEu IDEyLiAyMDA4IHYgMTY6MTkgKzAxMDA6Cj4gPj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2Vz bmV0LmN6PiB3cm90ZToKPiA+Pj4gSGksCj4gPj4+Cj4gPj4+IGlzIHRoaXMgYWxsb3dlZCBvciBp cyBpdCBjb25zaWRlcmVkIGEgY2lyY3VsYXIgaW5jbHVkZT8KPiA+PiBUaGlzIGlzIGFsbG93ZWQu Cj4gPiAKPiA+IEJ1dCB0aGUgbWFpbiBtb2R1bGUgZ2V0cyB0aGUgZGVmaW5pdGlvbnMgZnJvbSBT MSB0d2ljZS4gV2h5IGlzIHRoaXMKPiA+IGRpZmZlcmVudCBmcm9tIHRoZSBjYXNlIG9mIGEgc2hv cnRlciBjaXJjbGUsIG5hbWVseSB3aGVuIFMyIGFsc28KPiA+IGluY2x1ZGVzIFMxPyBUaGlzIGlz IGV4cGxpY2l0bHkgZm9yYmlkZGVuIGluIHRoZSBkcmFmdC4KPiA+IAo+IAo+IEl0IGlzIGRpZmZl cmVudCBiZWNhdXNlIG5vIGluY2x1ZGUgbG9vcHMgYXJlIGNyZWF0ZWQuCgpTbyB0aGlzIGlzIG5v dCBpbmNsdWRlIGxvb3AKCiAgICArLS0tLTwtLS0tLSsKICAgIHwgICAgICAgICAgfAogICAgTSA8 LSBTMSA8LSBTMgoKd2hpbGUgdGhpcyBpcyAod2hlcmUgUzAgaXMgYW5vdGhlciBzdWJtb2R1bGUp PwoKICAgICstLS0tPC0tLS0tLSsKICAgIHwgICAgICAgICAgIHwKICAgIFMwIDwtIFMxIDwtIFMy CgpXaGF0J3MgdGhlIGRpZmZlcmVuY2U/IE1haW4gbW9kdWxlIE0gaW4gdGhlIGZpcnN0IGNhc2Ug Z2V0cyBldmVuIG1vcmUKc3R1ZmYgZnJvbSB0aGUgc3VibW9kdWxlcyB0aGFuIFMwIGluIHRoZSBz ZWNvbmQgY2FzZS4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElE OiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 1 11:41:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF5D28C0CF; Mon, 1 Dec 2008 11:41:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FBD28C0CF for ; Mon, 1 Dec 2008 11:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.186, 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 NJCPJvVG4sK8 for ; Mon, 1 Dec 2008 11:41:57 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id E7DA228C0F9 for ; Mon, 1 Dec 2008 11:41:57 -0800 (PST) Received: (qmail 41522 invoked from network); 1 Dec 2008 19:41:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 19:41:52 -0000 X-YMail-OSG: xChgeAsVM1knwf9i9s.NifKgpuNuhUbSdyJ5gM4Ui8n1w1_4nKFsatlJK6J2sC1vNxscbX8wHqqo76ROGFmy01bDoV1PQBMXXUAwFmZmaFfAyj3HUXo6oCkSjFKbNyT6_7HSfg7R7U_O9_uzFPVlmZWq X-Yahoo-Newman-Property: ymail-3 Message-ID: <49343DFF.70501@netconfcentral.com> Date: Mon, 01 Dec 2008 11:41:51 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> <1228147979.6259.134.camel@missotis> <49341F58.6030100@netconfcentral.com> <1228159272.6259.167.camel@missotis> In-Reply-To: <1228159272.6259.167.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAwMS4gMTIu IDIwMDggdiAwOTozMSAtMDgwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gTWFydGlu IEJqb3JrbHVuZCBww63FoWUgdiBQbyAwMS4gMTIuIDIwMDggdiAxNjoxOSArMDEwMDoKPj4+PiBM YWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+Pj4+PiBIaSwKPj4+Pj4K Pj4+Pj4gaXMgdGhpcyBhbGxvd2VkIG9yIGlzIGl0IGNvbnNpZGVyZWQgYSBjaXJjdWxhciBpbmNs dWRlPwo+Pj4+IFRoaXMgaXMgYWxsb3dlZC4KPj4+IEJ1dCB0aGUgbWFpbiBtb2R1bGUgZ2V0cyB0 aGUgZGVmaW5pdGlvbnMgZnJvbSBTMSB0d2ljZS4gV2h5IGlzIHRoaXMKPj4+IGRpZmZlcmVudCBm cm9tIHRoZSBjYXNlIG9mIGEgc2hvcnRlciBjaXJjbGUsIG5hbWVseSB3aGVuIFMyIGFsc28KPj4+ IGluY2x1ZGVzIFMxPyBUaGlzIGlzIGV4cGxpY2l0bHkgZm9yYmlkZGVuIGluIHRoZSBkcmFmdC4K Pj4+Cj4+IEl0IGlzIGRpZmZlcmVudCBiZWNhdXNlIG5vIGluY2x1ZGUgbG9vcHMgYXJlIGNyZWF0 ZWQuCj4gCj4gU28gdGhpcyBpcyBub3QgaW5jbHVkZSBsb29wCj4gCj4gICAgICstLS0tPC0tLS0t Kwo+ICAgICB8ICAgICAgICAgIHwKPiAgICAgTSA8LSBTMSA8LSBTMgo+IAoKdGhlcmUgaXMgbm8g bG9vcCBoZXJlCgo+IHdoaWxlIHRoaXMgaXMgKHdoZXJlIFMwIGlzIGFub3RoZXIgc3VibW9kdWxl KT8KPiAKPiAgICAgKy0tLS08LS0tLS0tKwo+ICAgICB8ICAgICAgICAgICB8Cj4gICAgIFMwIDwt IFMxIDwtIFMyCj4gCgoKCj4gV2hhdCdzIHRoZSBkaWZmZXJlbmNlPyBNYWluIG1vZHVsZSBNIGlu IHRoZSBmaXJzdCBjYXNlIGdldHMgZXZlbiBtb3JlCj4gc3R1ZmYgZnJvbSB0aGUgc3VibW9kdWxl cyB0aGFuIFMwIGluIHRoZSBzZWNvbmQgY2FzZS4KPiAKCm1vZHVsZSBNIHsKICAgLi4uCiAgIGlu Y2x1ZGUgUzA7CiAgIGluY2x1ZGUgUzE7CiAgIGluY2x1ZGUgUzI7CiAgIC4uLgp9CgoKc3VibW9k dWxlIFMwIHsKICAgYmVsb25ncy10byBNOwogICBpbmNsdWRlIFMxOwogICBpbmNsdWRlIFMyOwog ICAuLi4KfQoKc3VibW9kdWxlIFMxIHsKICAgYmVsb25ncy10byBNOwogICBpbmNsdWRlIFMyOwog ICAuLi4KfQoKc3VibW9kdWxlIFMyIHsKICAgYmVsb25ncy10byBNOwogICAuLi4KfQoKClRoaXMg aXMgZmluZS4KIEZyb20gYSBtb2R1bGUgcGVyc3BlY3RpdmUsIE0sIFMwLCBTMSwgUzIsIGFuZCBT MwphcmUgYWxsIGF0IHRoZSBzYW1lICdsZXZlbCcuICBUaGUgaGllcmFyY2h5IG9mCmluY2x1ZGUt c3RtdHMgb25seSBtYWtlcyBzeW1ib2xzIHZpc2libGUgaW4gdGhlCmluY2x1ZGluZyBmaWxlLCBp dCBkb2VzIG5vdCByZWRlZmluZSB0aGVtIG92ZXIgYW5kIG92ZXIuCgpUaGlzIHdvdWxkIGNhdXNl IGFuIGluY2x1ZGUgbG9vcCBiZXR3ZWVuIFMxIDwtLT4gUzI6CgoKc3VibW9kdWxlIFMyIHsKICAg YmVsb25ncy10byBNOwogICBpbmNsdWRlIFMxOyAgIC8vIGlsbGVnYWwKICAgLi4uCn0KCgo+IExh ZGEKPiAKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Dec 1 12:09:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9BB3A67A4; Mon, 1 Dec 2008 12:09:05 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8009E3A6972 for ; Mon, 1 Dec 2008 12:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 Mdk4kIwFKQib for ; Mon, 1 Dec 2008 12:09:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9FD983A67DD for ; Mon, 1 Dec 2008 12:09:03 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5ECE8D800C8; Mon, 1 Dec 2008 21:08:59 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49343DFF.70501@netconfcentral.com> References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> <1228147979.6259.134.camel@missotis> <49341F58.6030100@netconfcentral.com> <1228159272.6259.167.camel@missotis> <49343DFF.70501@netconfcentral.com> Organization: CESNET Date: Mon, 01 Dec 2008 21:09:00 +0100 Message-Id: <1228162140.6259.185.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDAxLiAxMi4gMjAwOCB2IDExOjQxIC0wODAwOgoKPiBU aGlzIGlzIGZpbmUuCj4gIEZyb20gYSBtb2R1bGUgcGVyc3BlY3RpdmUsIE0sIFMwLCBTMSwgUzIs IGFuZCBTMwo+IGFyZSBhbGwgYXQgdGhlIHNhbWUgJ2xldmVsJy4gIFRoZSBoaWVyYXJjaHkgb2YK PiBpbmNsdWRlLXN0bXRzIG9ubHkgbWFrZXMgc3ltYm9scyB2aXNpYmxlIGluIHRoZQo+IGluY2x1 ZGluZyBmaWxlLCBpdCBkb2VzIG5vdCByZWRlZmluZSB0aGVtIG92ZXIgYW5kIG92ZXIuCgpJIHNl ZSwgc28gd2hlbiBhIChzdWIpbW9kdWxlIHRyaWVzIHRvIGxvb2stdXAgYSBzeW1ib2wsIHRoZXJl IG1heSBiZQptdWx0aXBsZSBpbmNsdWRlIGNoYWlucyB0aGF0IGxlYWQgdG8gaXQsIHByb3ZpZGVk IHRoZXkgZW5kIHVwIGF0IHRoZQpzYW1lIGRlZmluaXRpb24gaW4gdGhlIHNhbWUgc3VibW9kdWxl LiBCdXQgY2FuIHRoZSBjb21waWxlciB0aGVuCmRpc2NvdmVyIGFuIGVycm9yIHdoZW4gdHdvIGlu Y2x1ZGUgY2hhaW5zIGluIGZhY3QgZ2l2ZSB0d28gZGlmZmVyZW50CmRlZmluaXRpb25zIG9mIHRo ZSBzYW1lIHN5bWJvbD8KCkxhZGEKCj4gCj4gVGhpcyB3b3VsZCBjYXVzZSBhbiBpbmNsdWRlIGxv b3AgYmV0d2VlbiBTMSA8LS0+IFMyOgo+IAo+IAo+IHN1Ym1vZHVsZSBTMiB7Cj4gICAgYmVsb25n cy10byBNOwo+ICAgIGluY2x1ZGUgUzE7ICAgLy8gaWxsZWdhbAo+ICAgIC4uLgo+IH0KPiAKPiAK PiA+IExhZGEKPiA+IAo+IAo+IEFuZHkKPiAKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBH UCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 12:24:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48013A687D; Mon, 1 Dec 2008 12:24:44 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937A13A690A for ; Mon, 1 Dec 2008 12:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.155, 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 5ZxlNg-aqojv for ; Mon, 1 Dec 2008 12:24:43 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id E96203A687D for ; Mon, 1 Dec 2008 12:24:42 -0800 (PST) Received: (qmail 29736 invoked from network); 1 Dec 2008 20:24:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 20:24:37 -0000 X-YMail-OSG: kNUT__gVM1mwJu9RKk8S7bKzfikx4NcIPB1qZjU3FR50J7IZh6V9Cv7Bo7GgvezkNS8Gkk9lJTyZFioUaHc6hX1siQQ.Vpv_HiOabFkMtC3Kipbc_3_vA9bCcuf6_W.VMH0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49344804.2060704@netconfcentral.com> Date: Mon, 01 Dec 2008 12:24:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> <1228147979.6259.134.camel@missotis> <49341F58.6030100@netconfcentral.com> <1228159272.6259.167.camel@missotis> <49343DFF.70501@netconfcentral.com> <1228162140.6259.185.camel@missotis> In-Reply-To: <1228162140.6259.185.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAwMS4gMTIu IDIwMDggdiAxMTo0MSAtMDgwMDoKPiAKPj4gVGhpcyBpcyBmaW5lLgo+PiAgRnJvbSBhIG1vZHVs ZSBwZXJzcGVjdGl2ZSwgTSwgUzAsIFMxLCBTMiwgYW5kIFMzCj4+IGFyZSBhbGwgYXQgdGhlIHNh bWUgJ2xldmVsJy4gIFRoZSBoaWVyYXJjaHkgb2YKPj4gaW5jbHVkZS1zdG10cyBvbmx5IG1ha2Vz IHN5bWJvbHMgdmlzaWJsZSBpbiB0aGUKPj4gaW5jbHVkaW5nIGZpbGUsIGl0IGRvZXMgbm90IHJl ZGVmaW5lIHRoZW0gb3ZlciBhbmQgb3Zlci4KPiAKPiBJIHNlZSwgc28gd2hlbiBhIChzdWIpbW9k dWxlIHRyaWVzIHRvIGxvb2stdXAgYSBzeW1ib2wsIHRoZXJlIG1heSBiZQo+IG11bHRpcGxlIGlu Y2x1ZGUgY2hhaW5zIHRoYXQgbGVhZCB0byBpdCwgcHJvdmlkZWQgdGhleSBlbmQgdXAgYXQgdGhl Cj4gc2FtZSBkZWZpbml0aW9uIGluIHRoZSBzYW1lIHN1Ym1vZHVsZS4gQnV0IGNhbiB0aGUgY29t cGlsZXIgdGhlbgo+IGRpc2NvdmVyIGFuIGVycm9yIHdoZW4gdHdvIGluY2x1ZGUgY2hhaW5zIGlu IGZhY3QgZ2l2ZSB0d28gZGlmZmVyZW50Cj4gZGVmaW5pdGlvbnMgb2YgdGhlIHNhbWUgc3ltYm9s Pwo+IAoKWW91IGNhbiBkaXNjb3ZlciBhbGwgZHVwbGljYXRlcyBieSBjb21waWxpbmcgdGhlIG1h aW4gbW9kdWxlLgpJZiB5b3UgZm9yZ2V0IHRoZSAiaW5jbHVkZSBzdWJYIiBpbiB0aGUgbWFpbiBt b2R1bGUsIHRoZW4KdGhvc2Ugc3ltYm9scyB3aWxsIG5vdCBiZSBleHBvcnRlZCB0byBvdGhlciBt b2R1bGVzLgoKCj4gTGFkYQoKQW5keQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 1 12:28:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814CC3A69F4; Mon, 1 Dec 2008 12:28:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D9628C0D8 for ; Mon, 1 Dec 2008 12:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.133, 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 mNBfafZVgfMH for ; Mon, 1 Dec 2008 12:28:26 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 6CB223A69F4 for ; Mon, 1 Dec 2008 12:28:26 -0800 (PST) Received: (qmail 60994 invoked from network); 1 Dec 2008 20:28:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 20:28:21 -0000 X-YMail-OSG: 332KkgQVM1k_Q2QSCp9M6ylr9JxDTFpJEBSvrd_tmW2mrrIyOiKDD5mQYCEASgWj3QCa2Pe46PSWjKnP6EpkbXV6VZek6nVlzuzf01ov_d5iVf67wXT1qYgZ20RnhJhxaaY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493448E3.8020407@netconfcentral.com> Date: Mon, 01 Dec 2008 12:28:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1228140199.6259.90.camel@missotis> <20081201.161958.89109710.mbj@tail-f.com> <1228147979.6259.134.camel@missotis> <49341F58.6030100@netconfcentral.com> <1228159272.6259.167.camel@missotis> <49343DFF.70501@netconfcentral.com> <1228162140.6259.185.camel@missotis> <49344804.2060704@netconfcentral.com> In-Reply-To: <49344804.2060704@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHdyb3RlOgo+IExhZGlzbGF2IExob3RrYSB3cm90ZToKPj4gQW5keSBCaWVy bWFuIHDDrcWhZSB2IFBvIDAxLiAxMi4gMjAwOCB2IDExOjQxIC0wODAwOgo+Pgo+Pj4gVGhpcyBp cyBmaW5lLgo+Pj4gIEZyb20gYSBtb2R1bGUgcGVyc3BlY3RpdmUsIE0sIFMwLCBTMSwgUzIsIGFu ZCBTMwo+Pj4gYXJlIGFsbCBhdCB0aGUgc2FtZSAnbGV2ZWwnLiAgVGhlIGhpZXJhcmNoeSBvZgo+ Pj4gaW5jbHVkZS1zdG10cyBvbmx5IG1ha2VzIHN5bWJvbHMgdmlzaWJsZSBpbiB0aGUKPj4+IGlu Y2x1ZGluZyBmaWxlLCBpdCBkb2VzIG5vdCByZWRlZmluZSB0aGVtIG92ZXIgYW5kIG92ZXIuCj4+ Cj4+IEkgc2VlLCBzbyB3aGVuIGEgKHN1Yiltb2R1bGUgdHJpZXMgdG8gbG9vay11cCBhIHN5bWJv bCwgdGhlcmUgbWF5IGJlCj4+IG11bHRpcGxlIGluY2x1ZGUgY2hhaW5zIHRoYXQgbGVhZCB0byBp dCwgcHJvdmlkZWQgdGhleSBlbmQgdXAgYXQgdGhlCj4+IHNhbWUgZGVmaW5pdGlvbiBpbiB0aGUg c2FtZSBzdWJtb2R1bGUuIEJ1dCBjYW4gdGhlIGNvbXBpbGVyIHRoZW4KPj4gZGlzY292ZXIgYW4g ZXJyb3Igd2hlbiB0d28gaW5jbHVkZSBjaGFpbnMgaW4gZmFjdCBnaXZlIHR3byBkaWZmZXJlbnQK Pj4gZGVmaW5pdGlvbnMgb2YgdGhlIHNhbWUgc3ltYm9sPwo+Pgo+IAo+IFlvdSBjYW4gZGlzY292 ZXIgYWxsIGR1cGxpY2F0ZXMgYnkgY29tcGlsaW5nIHRoZSBtYWluIG1vZHVsZS4KPiBJZiB5b3Ug Zm9yZ2V0IHRoZSAiaW5jbHVkZSBzdWJYIiBpbiB0aGUgbWFpbiBtb2R1bGUsIHRoZW4KPiB0aG9z ZSBzeW1ib2xzIHdpbGwgbm90IGJlIGV4cG9ydGVkIHRvIG90aGVyIG1vZHVsZXMuCj4gCgpJIG1l YW50IGlmIHN1Ym1vZHVsZSAnWCcgaXMgbm90IGluY2x1ZGVkIGFueXdoZXJlLApub3QgaW5jbHVk ZWQgZGlyZWN0bHkuCgpFLmcuLCAgTSA8LS0gUzAgPC0tIFMxIDwtLSBTWAoKU1ggd2lsbCBiZSBl eHBvcnRlZCBldmVuIHRob3VnaCBNIGRvZXMgbm90IGluY2x1ZGUgaXQgZGlyZWN0bHkuCgoKPiAK Pj4gTGFkYQo+IAo+IEFuZHkKPiAKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Dec 1 12:28:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9713C28C0E0; Mon, 1 Dec 2008 12:28:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF7C28C0E3 for ; Mon, 1 Dec 2008 12:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Cleck0z1GIIk for ; Mon, 1 Dec 2008 12:28:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 866C328C0E0 for ; Mon, 1 Dec 2008 12:28:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 989A861600D; Mon, 1 Dec 2008 21:28:27 +0100 (CET) Date: Mon, 01 Dec 2008 21:28:25 +0100 (CET) Message-Id: <20081201.212825.137113488.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49344804.2060704@netconfcentral.com> References: <49343DFF.70501@netconfcentral.com> <1228162140.6259.185.camel@missotis> <49344804.2060704@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > If you forget the "include subX" in the main module, then > those symbols will not be exported to other modules. I don't think this should be allowed: module M { inlcude S1; ... } submodule S1 { belongs-to M; include S2; ... } submodule S2 { belongs-to M; // (*) ... } You can argue that (*) is wrong - S2 claims it belongs to M, but M does not include it. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 12:31:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED69F3A69AF; Mon, 1 Dec 2008 12:31:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9233A69AF for ; Mon, 1 Dec 2008 12:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 NTBEjiN5O-kt for ; Mon, 1 Dec 2008 12:31:13 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E817128C0D6 for ; Mon, 1 Dec 2008 12:31:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DD3C7616006; Mon, 1 Dec 2008 21:31:07 +0100 (CET) Date: Mon, 01 Dec 2008 21:31:05 +0100 (CET) Message-Id: <20081201.213105.219588612.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493448E3.8020407@netconfcentral.com> References: <1228162140.6259.185.camel@missotis> <49344804.2060704@netconfcentral.com> <493448E3.8020407@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I meant if submodule 'X' is not included anywhere, > not included directly. > > E.g., M <-- S0 <-- S1 <-- SX > > SX will be exported even though M does not include it directly. Ah. Yes, I agree. Forget my other email. M does not have to list all submodules recursively. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 12:36:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F1E3A696B; Mon, 1 Dec 2008 12:36:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B7D3A698F for ; Mon, 1 Dec 2008 12:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 eM8R7pGPSi48 for ; Mon, 1 Dec 2008 12:36:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8DD933A696B for ; Mon, 1 Dec 2008 12:36:46 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A02CF616006; Mon, 1 Dec 2008 21:36:42 +0100 (CET) Date: Mon, 01 Dec 2008 21:36:40 +0100 (CET) Message-Id: <20081201.213640.60317019.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4934228B.2010901@netconfcentral.com> References: <200812011319.mB1DJ7Sl090716@idle.juniper.net> <1228139921.6259.85.camel@missotis> <4934228B.2010901@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIDxhbmR5QG5ldGNvbmZjZW50cmFsLmNvbT4gd3JvdGU6DQo+IExhZGlzbGF2 IExob3RrYSB3cm90ZToNCj4gPiBQaGlsIFNoYWZlciBww63FoWUgdiBQbyAwMS4gMTIuIDIwMDgg diAwODoxOSAtMDUwMDoNCj4gPj4gQmFsYXpzIExlbmd5ZWwgd3JpdGVzOg0KPiAuLi4uDQo+ID4g QWxzbywgaWYgSSByZW1lbWJlciBjb3JyZWN0bHkgZnJvbSB0aGUgaW50ZXJpbSwgQmFsYXpzIGRl bWFuZGVkIHRoYXQgdGhlDQo+ID4gInRvcC1sZXZlbCBhdWdtZW50IiBjb250aW51ZSB0byBiZSBh YmxlIHRvIGFkZHJlc3MgdGFyZ2V0IG5vZGVzIGluIHRoZQ0KPiA+IGxvY2FsIG1vZHVsZSwgbm90 IGp1c3QgaW4gZXh0ZXJuYWwgbW9kdWxlcywgYW5kIHRoZSB1c2UgY2FzZSB3YXMgdGhlDQo+ID4g cG9zc2liaWxpdHkgb2YgYXR0YWNoaW5nIHN1Ym1vZHVsZSBjb250ZW50IHRvIGEgbm9uLXJvb3Qg bm9kZSBpbiB0aGUNCj4gPiBtYWluIG1vZHVsZS4gU28gdGhpcyBhY3R1YWxseSBpcyBub3QgYWxs b3dlZCwgcmlnaHQ/DQo+ID4gDQo+IA0KPiBSZWFsbHk/DQoNCldlbGwsIHRoZSBpZGVhIHdhcyB0 aGF0IGEgc2J1bW9kdWxlIGNhbiBzdGlsbCBhdWdtZW50ICh0b3AtbGV2ZWwpIGENCm5vZGUgd2hp Y2ggaXMgZGVmaW5lZCBpbiBhbm90aGVyIHN1Ym1vZHVsZToNCg0KICBzdWJtb2R1bGUgUzEgew0K ICAgIGNvbnRhaW5lciByb3V0aW5nIHsgLi4uIH0NCiAgfQ0KDQogIHN1Ym1vZHVsZSBTMiB7DQog ICAgaW5jbHVkZSBTMTsNCiAgICBhdWdtZW50IC9yb3V0aW5nIHsNCiAgICAgIGNvbnRhaW5lciBv c3BmIHsgLi4uIH0NCiAgICB9DQogIH0NCg0KPiBJbiB0aGF0IGNhc2UgdGhlcmUgaXMgbm8gcG9p bnQgdG8gdGhlIENMUiB0aGF0IGF1Z21lbnQtc3RtdCBvbmx5IGFwcGVhcg0KPiBhdCB0aGUgdG9w LWxldmVsIG9yIGluc2lkZXMgdXNlcy1zdG10LiAgVGhlIG9ubHkgdXNlLWNhc2Ugd2FzIHRoZSB3 aGVuDQo+IGNsYXVzZSwgYnV0IHRoYXQgaXMgbm93IGFsbG93ZWQgZXZlcnl3aGVyZSwgbm90IGp1 c3QgaW5zaWRlIGF1Z21lbnQtc3RtdC4NCj4gDQo+IFVubGVzcyB0aGUgdG9wLWxldmVsIGF1Z21l bnQgaXMgJ2V4dGVybmFsIG5hbWVzcGFjZSBvbmx5JywNCj4gdGhlbiBhdWdtZW50LXN0bXQgc2hv dWxkIGJlIGFsbG93ZWQgZXZlcnl3aGVyZS4gIE5vdGhpbmcgd2hhdHNvZXZlcg0KPiBpcyBzaW1w bGlmaWVkIGluIHRoZSBjb2RlIGJ1dCByZW1vdmluZyBvbmx5IG9uZSBvZiB0aGUgdHdvDQo+IGxv Y2FsIGF1Z21lbnQgdmFyaWFudHMuDQoNCkkgYWdyZWUgdGhhdCB0aGUgY29kZSBtaWdodCBub3Qg YmUgc2ltcGxpZmllZCwgYnV0IEknbSBub3Qgc3VyZSB3ZQ0Kc2hvdWxkIGFsbG93IGF1Z21lbnQg YW55d2hlcmUgYW55d2F5Lg0KDQo+IEl0IGp1c3QgZ2l2ZXMgdXNlcnMgb25lIG1vcmUgQ0xSDQo+ IHRvIHJlbWVtYmVyIGFuZCB3b3JrIGFyb3VuZC4NCg0KJ2F1Z21lbnQnIGNhbiBiZSB1c2VkIG9u IHRoZSB0b3AtbGV2ZWwgb25seS4NCidleHRlbmQnIChvciB3aGF0ZXZlciBpdCB3aWxsIGJlIGNh bGxlZCkgY2FuIGJlIHVzZWQgaW4gJ3VzZXMnIG9ubHkNCg0KDQovbWFydGluDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0 Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 12:40:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C653A696B; Mon, 1 Dec 2008 12:40:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFED3A696B for ; Mon, 1 Dec 2008 12:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 jHiJpf052MZF for ; Mon, 1 Dec 2008 12:40:41 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BC1203A6808 for ; Mon, 1 Dec 2008 12:40:41 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B6BAAD800C8; Mon, 1 Dec 2008 21:40:37 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081201.213105.219588612.mbj@tail-f.com> References: <1228162140.6259.185.camel@missotis> <49344804.2060704@netconfcentral.com> <493448E3.8020407@netconfcentral.com> <20081201.213105.219588612.mbj@tail-f.com> Organization: CESNET Date: Mon, 01 Dec 2008 21:40:39 +0100 Message-Id: <1228164039.6259.190.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwMS4gMTIuIDIwMDggdiAyMTozMSArMDEwMDoK PiBBbmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPiB3cm90ZToKPiA+IEkgbWVh bnQgaWYgc3VibW9kdWxlICdYJyBpcyBub3QgaW5jbHVkZWQgYW55d2hlcmUsCj4gPiBub3QgaW5j bHVkZWQgZGlyZWN0bHkuCj4gPiAKPiA+IEUuZy4sICBNIDwtLSBTMCA8LS0gUzEgPC0tIFNYCj4g PiAKPiA+IFNYIHdpbGwgYmUgZXhwb3J0ZWQgZXZlbiB0aG91Z2ggTSBkb2VzIG5vdCBpbmNsdWRl IGl0IGRpcmVjdGx5Lgo+IAo+IEFoLiAgWWVzLCBJIGFncmVlLiAgRm9yZ2V0IG15IG90aGVyIGVt YWlsLiAgTSBkb2VzIG5vdCBoYXZlIHRvIGxpc3QKPiBhbGwgc3VibW9kdWxlcyByZWN1cnNpdmVs eS4KClNvIG1heWJlIHRoZSBkcmFmdCBjb3VsZCBzYXkgaXQgZXhwbGljaXRseSB0aGF0IHRoZSBp bmNsdXNpb24gb2YKZGVmaW5pdGlvbnMgKHN5bWJvbHMpIGZyb20gc3VibW9kdWxlcyBpcyB0cmFu c2l0aXZlLiAKCkxhZGEKCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNO RVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Dec 1 12:50:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6384F28C0D7; Mon, 1 Dec 2008 12:50:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA57A28C0D8 for ; Mon, 1 Dec 2008 12:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116, 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 vsGmJgKwBI8o for ; Mon, 1 Dec 2008 12:50:38 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 094CF28C0D7 for ; Mon, 1 Dec 2008 12:50:38 -0800 (PST) Received: (qmail 60371 invoked from network); 1 Dec 2008 20:50:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 20:50:33 -0000 X-YMail-OSG: xLfKs3cVM1ml6aXvkN2yzFDdtuvko16Kpl_kzmRvtz4lEMwJFdV2zpLHnJLW0RlS_DeKFj20ZvQZvYjam65slp15rlkLfV7Z.XIkFRVZpKAMU0EFqvmeKNGNdJeLWcdL8Mylq7k28rNAryt9WOpzYwUe X-Yahoo-Newman-Property: ymail-3 Message-ID: <49344E17.1020307@netconfcentral.com> Date: Mon, 01 Dec 2008 12:50:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49343DFF.70501@netconfcentral.com> <1228162140.6259.185.camel@missotis> <49344804.2060704@netconfcentral.com> <20081201.212825.137113488.mbj@tail-f.com> In-Reply-To: <20081201.212825.137113488.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] submodules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> If you forget the "include subX" in the main module, then >> those symbols will not be exported to other modules. > > I don't think this should be allowed: > > module M { > inlcude S1; > ... > } > > submodule S1 { > belongs-to M; > include S2; > ... > } > > submodule S2 { > belongs-to M; // (*) > ... > } > > You can argue that (*) is wrong - S2 claims it belongs to M, but M > does not include it. > When you compile S2 you do not know if M includes it or not. Since belongs-to-stmt was changed to avoid the compiler looking at the main module (for the prefix), it seems strange to make the compiler read the main module looking for an include-stmt. This check is not needed, because another module importing M will flag the missing definition if an include-stmt is missing from M. IMO, this is valid YANG because submodules are not really nested at the object level, but they are nested at the abstraction level. Since M <-- S1 <-- S2, no submodule is 'orphaned'. Whatever submodules get included down the tree (S2 here) are visible to outside modules. This allows S1 or S2 to expand over time and be further fragmented into more submodules. In my code, a stack of 'breadcrumb' records keeps track of loops, and a Q of back-ptr records keeps a list of all includes in M, so extra re-compiles of submodules are avoided, and the same Q provides an external search path through all the submodules. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 12:51:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740353A6BB3; Mon, 1 Dec 2008 12:51:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D553A6BB3 for ; Mon, 1 Dec 2008 12:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 iZBHPx5IZBIQ for ; Mon, 1 Dec 2008 12:51:38 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 432123A6BAD for ; Mon, 1 Dec 2008 12:51:38 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7C3F9D800E8; Mon, 1 Dec 2008 21:51:34 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081201.213640.60317019.mbj@tail-f.com> References: <200812011319.mB1DJ7Sl090716@idle.juniper.net> <1228139921.6259.85.camel@missotis> <4934228B.2010901@netconfcentral.com> <20081201.213640.60317019.mbj@tail-f.com> Organization: CESNET Date: Mon, 01 Dec 2008 21:51:36 +0100 Message-Id: <1228164696.6259.195.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwMS4gMTIuIDIwMDggdiAyMTozNiArMDEwMDoK PiBBbmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPiB3cm90ZToKPiA+IExhZGlz bGF2IExob3RrYSB3cm90ZToKPiA+ID4gUGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMDEuIDEyLiAy MDA4IHYgMDg6MTkgLTA1MDA6Cj4gPiA+PiBCYWxhenMgTGVuZ3llbCB3cml0ZXM6Cj4gPiAuLi4u Cj4gPiA+IEFsc28sIGlmIEkgcmVtZW1iZXIgY29ycmVjdGx5IGZyb20gdGhlIGludGVyaW0sIEJh bGF6cyBkZW1hbmRlZCB0aGF0IHRoZQo+ID4gPiAidG9wLWxldmVsIGF1Z21lbnQiIGNvbnRpbnVl IHRvIGJlIGFibGUgdG8gYWRkcmVzcyB0YXJnZXQgbm9kZXMgaW4gdGhlCj4gPiA+IGxvY2FsIG1v ZHVsZSwgbm90IGp1c3QgaW4gZXh0ZXJuYWwgbW9kdWxlcywgYW5kIHRoZSB1c2UgY2FzZSB3YXMg dGhlCj4gPiA+IHBvc3NpYmlsaXR5IG9mIGF0dGFjaGluZyBzdWJtb2R1bGUgY29udGVudCB0byBh IG5vbi1yb290IG5vZGUgaW4gdGhlCj4gPiA+IG1haW4gbW9kdWxlLiBTbyB0aGlzIGFjdHVhbGx5 IGlzIG5vdCBhbGxvd2VkLCByaWdodD8KPiA+ID4gCj4gPiAKPiA+IFJlYWxseT8KPiAKPiBXZWxs LCB0aGUgaWRlYSB3YXMgdGhhdCBhIHNidW1vZHVsZSBjYW4gc3RpbGwgYXVnbWVudCAodG9wLWxl dmVsKSBhCj4gbm9kZSB3aGljaCBpcyBkZWZpbmVkIGluIGFub3RoZXIgc3VibW9kdWxlOgo+IAo+ ICAgc3VibW9kdWxlIFMxIHsKPiAgICAgY29udGFpbmVyIHJvdXRpbmcgeyAuLi4gfQo+ICAgfQo+ IAo+ICAgc3VibW9kdWxlIFMyIHsKPiAgICAgaW5jbHVkZSBTMTsKPiAgICAgYXVnbWVudCAvcm91 dGluZyB7Cj4gICAgICAgY29udGFpbmVyIG9zcGYgeyAuLi4gfQo+ICAgICB9Cj4gICB9CgpUaGUg ZHJhZnQgc2F5czogIldoZW4gYSBzdWJtb2R1bGUgaW5jbHVkZXMgYW5vdGhlciBzdWJtb2R1bGUs IHRoZSB0YXJnZXQKc3VibW9kdWxlJ3MgZGVmaW5pdGlvbnMgYXJlIG1hZGUgYXZhaWxhYmxlIHRv IHRoZSBjdXJyZW50IHN1Ym1vZHVsZS4iClRoaXMgZXhhbXBsZSBzZWVtcyB0byBpbXBseSB0aGF0 IG5vdCBvbmx5IGRlZmluaXRpb25zIGJ1dCBhbHNvIGRhdGEKbm9kZXMgKHJvdXRpbmcpIGFyZSBt YWRlIGF2YWlsYWJsZS4KCj4gCj4gPiBJbiB0aGF0IGNhc2UgdGhlcmUgaXMgbm8gcG9pbnQgdG8g dGhlIENMUiB0aGF0IGF1Z21lbnQtc3RtdCBvbmx5IGFwcGVhcgo+ID4gYXQgdGhlIHRvcC1sZXZl bCBvciBpbnNpZGVzIHVzZXMtc3RtdC4gIFRoZSBvbmx5IHVzZS1jYXNlIHdhcyB0aGUgd2hlbgo+ ID4gY2xhdXNlLCBidXQgdGhhdCBpcyBub3cgYWxsb3dlZCBldmVyeXdoZXJlLCBub3QganVzdCBp bnNpZGUgYXVnbWVudC1zdG10Lgo+ID4gCj4gPiBVbmxlc3MgdGhlIHRvcC1sZXZlbCBhdWdtZW50 IGlzICdleHRlcm5hbCBuYW1lc3BhY2Ugb25seScsCj4gPiB0aGVuIGF1Z21lbnQtc3RtdCBzaG91 bGQgYmUgYWxsb3dlZCBldmVyeXdoZXJlLiAgTm90aGluZyB3aGF0c29ldmVyCj4gPiBpcyBzaW1w bGlmaWVkIGluIHRoZSBjb2RlIGJ1dCByZW1vdmluZyBvbmx5IG9uZSBvZiB0aGUgdHdvCj4gPiBs b2NhbCBhdWdtZW50IHZhcmlhbnRzLgo+IAo+IEkgYWdyZWUgdGhhdCB0aGUgY29kZSBtaWdodCBu b3QgYmUgc2ltcGxpZmllZCwgYnV0IEknbSBub3Qgc3VyZSB3ZQo+IHNob3VsZCBhbGxvdyBhdWdt ZW50IGFueXdoZXJlIGFueXdheS4KCk15IHByZWZlcmVuY2UgaXMgdG8gaGF2ZSB0aGUgdG9wLWxl dmVsIGF1Z21lbnQgb25seSBmb3IgZXh0ZXJuYWwKdGFyZ2V0cy4KCj4gCj4gPiBJdCBqdXN0IGdp dmVzIHVzZXJzIG9uZSBtb3JlIENMUgo+ID4gdG8gcmVtZW1iZXIgYW5kIHdvcmsgYXJvdW5kLgo+ IAo+ICdhdWdtZW50JyBjYW4gYmUgdXNlZCBvbiB0aGUgdG9wLWxldmVsIG9ubHkuCj4gJ2V4dGVu ZCcgKG9yIHdoYXRldmVyIGl0IHdpbGwgYmUgY2FsbGVkKSBjYW4gYmUgdXNlZCBpbiAndXNlcycg b25seQoKJ2FwcGVuZCc/CgpMYWRhCgo+IAo+IAo+IC9tYXJ0aW4KLS0gCkxhZGlzbGF2IExob3Rr YSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 12:56:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432303A6B9F; Mon, 1 Dec 2008 12:56:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214A73A6BA6 for ; Mon, 1 Dec 2008 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 WpKlyhQvLDiq for ; Mon, 1 Dec 2008 12:56:39 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4F8193A6B9F for ; Mon, 1 Dec 2008 12:56:39 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 538B3616006; Mon, 1 Dec 2008 21:56:35 +0100 (CET) Date: Mon, 01 Dec 2008 21:56:33 +0100 (CET) Message-Id: <20081201.215633.09865912.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1228164696.6259.195.camel@missotis> References: <4934228B.2010901@netconfcentral.com> <20081201.213640.60317019.mbj@tail-f.com> <1228164696.6259.195.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > > submodule S1 { > > container routing { ... } > > } > > > > submodule S2 { > > include S1; > > augment /routing { > > container ospf { ... } > > } > > } > > The draft says: "When a submodule includes another submodule, the target > submodule's definitions are made available to the current submodule." > This example seems to imply that not only definitions but also data > nodes (routing) are made available. We need to define the term "definition"... The definition of the node is available (i.e. the name 'routing' is available as a container). This does *not* mean that the definition is duplicated. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 13:03:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1CC28C0FA; Mon, 1 Dec 2008 13:03:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B6F28C0FA for ; Mon, 1 Dec 2008 13:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.103, 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 1wqCaaBWbYhH for ; Mon, 1 Dec 2008 13:03:53 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 94B4D28C16F for ; Mon, 1 Dec 2008 13:03:15 -0800 (PST) Received: (qmail 17025 invoked from network); 1 Dec 2008 21:03:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 21:03:10 -0000 X-YMail-OSG: 5wMxV7YVM1lF0bXpMFJV8hehksp3ygsJY7Yby7Uad0F2PuLRhJTd6bWWDIhJNVS.EGGGZVyZjPXtxyHTiWc1hxaxOwq82nJwRHps0oM3dP8z3Z7Xt1KmfJmWwYUEe_vzrXmYF1WzdlIT_trW3quymhCJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4934510D.3010102@netconfcentral.com> Date: Mon, 01 Dec 2008 13:03:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <200812011319.mB1DJ7Sl090716@idle.juniper.net> <1228139921.6259.85.camel@missotis> <4934228B.2010901@netconfcentral.com> <20081201.213640.60317019.mbj@tail-f.com> In-Reply-To: <20081201.213640.60317019.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCB3cm90ZToKPiBBbmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRy YWwuY29tPiB3cm90ZToKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgUG8gMDEuIDEyLiAyMDA4IHYgMDg6MTkgLTA1MDA6Cj4+Pj4gQmFsYXpzIExlbmd5 ZWwgd3JpdGVzOgo+PiAuLi4uCj4+PiBBbHNvLCBpZiBJIHJlbWVtYmVyIGNvcnJlY3RseSBmcm9t IHRoZSBpbnRlcmltLCBCYWxhenMgZGVtYW5kZWQgdGhhdCB0aGUKPj4+ICJ0b3AtbGV2ZWwgYXVn bWVudCIgY29udGludWUgdG8gYmUgYWJsZSB0byBhZGRyZXNzIHRhcmdldCBub2RlcyBpbiB0aGUK Pj4+IGxvY2FsIG1vZHVsZSwgbm90IGp1c3QgaW4gZXh0ZXJuYWwgbW9kdWxlcywgYW5kIHRoZSB1 c2UgY2FzZSB3YXMgdGhlCj4+PiBwb3NzaWJpbGl0eSBvZiBhdHRhY2hpbmcgc3VibW9kdWxlIGNv bnRlbnQgdG8gYSBub24tcm9vdCBub2RlIGluIHRoZQo+Pj4gbWFpbiBtb2R1bGUuIFNvIHRoaXMg YWN0dWFsbHkgaXMgbm90IGFsbG93ZWQsIHJpZ2h0Pwo+Pj4KPj4gUmVhbGx5Pwo+IAo+IFdlbGws IHRoZSBpZGVhIHdhcyB0aGF0IGEgc2J1bW9kdWxlIGNhbiBzdGlsbCBhdWdtZW50ICh0b3AtbGV2 ZWwpIGEKPiBub2RlIHdoaWNoIGlzIGRlZmluZWQgaW4gYW5vdGhlciBzdWJtb2R1bGU6Cj4gCj4g ICBzdWJtb2R1bGUgUzEgewo+ICAgICBjb250YWluZXIgcm91dGluZyB7IC4uLiB9Cj4gICB9Cj4g Cj4gICBzdWJtb2R1bGUgUzIgewo+ICAgICBpbmNsdWRlIFMxOwo+ICAgICBhdWdtZW50IC9yb3V0 aW5nIHsKPiAgICAgICBjb250YWluZXIgb3NwZiB7IC4uLiB9Cj4gICAgIH0KPiAgIH0KPiAKCgpT byB0aGVyZSBpcyBnb2luZyB0byBiZSBhIENMUiB0aGF0IHRoaXMgaXMgb25seSBhbGxvd2VkIGlu IHN1Ym1vZHVsZXMsCndoZW4gYXVnbWVudGluZyBvdGhlciBzdWJtb2R1bGVzPyAgU2VlbXMgcmF0 aGVyIGFyY2FuZSB0byBtZS4KCkkgZG9uJ3QgcmVhbGx5IGNhcmUuICBJIGFscmVhZHkgd2VudCB0 byB0aGUgdHJvdWJsZSBvZgptYWtpbmcgZXZlcnkgYXNwZWN0IG9mIFlBTkcgdmFsaWRhdGlvbiAn c3RtdCBvcmRlciBwcm9vZicsCnNvIG1hZ2ljYWwgYXVnbWVudCBub2RlcyB0aGF0IGRyb3AgaW4g ZnJvbSB3aG8ta25vd3Mtd2hlcmUgYXJlIG5vdCBhIHByb2JsZW0uCgpJIGd1ZXNzIHRoaXMgY291 bnRzIGFzIGEgdXNlLWNhc2UsIHNvIEkgZHJvcCBteSBvYmplY3Rpb24uCkp1c3QgZG9jdW1lbnQg aXQgd2VsbCBiZWNhdXNlIHRoaXMgaXMgY29uZnVzaW5nLgoKPj4gSW4gdGhhdCBjYXNlIHRoZXJl IGlzIG5vIHBvaW50IHRvIHRoZSBDTFIgdGhhdCBhdWdtZW50LXN0bXQgb25seSBhcHBlYXIKPj4g YXQgdGhlIHRvcC1sZXZlbCBvciBpbnNpZGVzIHVzZXMtc3RtdC4gIFRoZSBvbmx5IHVzZS1jYXNl IHdhcyB0aGUgd2hlbgo+PiBjbGF1c2UsIGJ1dCB0aGF0IGlzIG5vdyBhbGxvd2VkIGV2ZXJ5d2hl cmUsIG5vdCBqdXN0IGluc2lkZSBhdWdtZW50LXN0bXQuCj4+Cj4+IFVubGVzcyB0aGUgdG9wLWxl dmVsIGF1Z21lbnQgaXMgJ2V4dGVybmFsIG5hbWVzcGFjZSBvbmx5JywKPj4gdGhlbiBhdWdtZW50 LXN0bXQgc2hvdWxkIGJlIGFsbG93ZWQgZXZlcnl3aGVyZS4gIE5vdGhpbmcgd2hhdHNvZXZlcgo+ PiBpcyBzaW1wbGlmaWVkIGluIHRoZSBjb2RlIGJ1dCByZW1vdmluZyBvbmx5IG9uZSBvZiB0aGUg dHdvCj4+IGxvY2FsIGF1Z21lbnQgdmFyaWFudHMuCj4gCj4gSSBhZ3JlZSB0aGF0IHRoZSBjb2Rl IG1pZ2h0IG5vdCBiZSBzaW1wbGlmaWVkLCBidXQgSSdtIG5vdCBzdXJlIHdlCj4gc2hvdWxkIGFs bG93IGF1Z21lbnQgYW55d2hlcmUgYW55d2F5Lgo+IAo+PiBJdCBqdXN0IGdpdmVzIHVzZXJzIG9u ZSBtb3JlIENMUgo+PiB0byByZW1lbWJlciBhbmQgd29yayBhcm91bmQuCj4gCj4gJ2F1Z21lbnQn IGNhbiBiZSB1c2VkIG9uIHRoZSB0b3AtbGV2ZWwgb25seS4KPiAnZXh0ZW5kJyAob3Igd2hhdGV2 ZXIgaXQgd2lsbCBiZSBjYWxsZWQpIGNhbiBiZSB1c2VkIGluICd1c2VzJyBvbmx5Cj4gCgpXZWxs LCB3aGF0IGlzIGl0IGNhbGxlZD8KSWYgaXQgY2FuIG9ubHkgYXBwZWFyIGluIHVzZXMsIHRoZW4g YSBkaWZmZXJlbnQgbmFtZQp0aGFuIGF1Z21lbnQgaXMgYSBnb29kIGlkZWEuICBJTU8sICdleHRl bmQnIGlzIGZpbmUuCgoKPiAKPiAvbWFydGluCgpBbmR5CgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 13:06:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FED43A6BAF; Mon, 1 Dec 2008 13:06:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA353A6BAF for ; Mon, 1 Dec 2008 13:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 oikbpZDzLqSg for ; Mon, 1 Dec 2008 13:06:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6A8333A6BAE for ; Mon, 1 Dec 2008 13:06:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 56112616006; Mon, 1 Dec 2008 22:06:07 +0100 (CET) Date: Mon, 01 Dec 2008 22:06:05 +0100 (CET) Message-Id: <20081201.220605.248233839.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4934510D.3010102@netconfcentral.com> References: <4934228B.2010901@netconfcentral.com> <20081201.213640.60317019.mbj@tail-f.com> <4934510D.3010102@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > > 'augment' can be used on the top-level only. > > 'extend' (or whatever it will be called) can be used in 'uses' only > > > > Well, what is it called? > If it can only appear in uses, then a different name > than augment is a good idea. IMO, 'extend' is fine. One worry is that it might be confused with 'extension'. But if people don't think that will be a problem, then I think 'extend' is fine. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 13:10:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF9B3A6937; Mon, 1 Dec 2008 13:10:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E683A6937 for ; Mon, 1 Dec 2008 13:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 sbYzYspSVgUp for ; Mon, 1 Dec 2008 13:10:48 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 131BA3A6B25 for ; Mon, 1 Dec 2008 13:10:48 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 43D62D800C8; Mon, 1 Dec 2008 22:10:44 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081201.215633.09865912.mbj@tail-f.com> References: <4934228B.2010901@netconfcentral.com> <20081201.213640.60317019.mbj@tail-f.com> <1228164696.6259.195.camel@missotis> <20081201.215633.09865912.mbj@tail-f.com> Organization: CESNET Date: Mon, 01 Dec 2008 22:10:45 +0100 Message-Id: <1228165845.6259.204.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwMS4gMTIuIDIwMDggdiAyMTo1NiArMDEwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gPiAgIHN1Ym1v ZHVsZSBTMSB7Cj4gPiA+ICAgICBjb250YWluZXIgcm91dGluZyB7IC4uLiB9Cj4gPiA+ICAgfQo+ ID4gPiAKPiA+ID4gICBzdWJtb2R1bGUgUzIgewo+ID4gPiAgICAgaW5jbHVkZSBTMTsKPiA+ID4g ICAgIGF1Z21lbnQgL3JvdXRpbmcgewo+ID4gPiAgICAgICBjb250YWluZXIgb3NwZiB7IC4uLiB9 Cj4gPiA+ICAgICB9Cj4gPiA+ICAgfQo+ID4gCj4gPiBUaGUgZHJhZnQgc2F5czogIldoZW4gYSBz dWJtb2R1bGUgaW5jbHVkZXMgYW5vdGhlciBzdWJtb2R1bGUsIHRoZSB0YXJnZXQKPiA+IHN1Ym1v ZHVsZSdzIGRlZmluaXRpb25zIGFyZSBtYWRlIGF2YWlsYWJsZSB0byB0aGUgY3VycmVudCBzdWJt b2R1bGUuIgo+ID4gVGhpcyBleGFtcGxlIHNlZW1zIHRvIGltcGx5IHRoYXQgbm90IG9ubHkgZGVm aW5pdGlvbnMgYnV0IGFsc28gZGF0YQo+ID4gbm9kZXMgKHJvdXRpbmcpIGFyZSBtYWRlIGF2YWls YWJsZS4KPiAKPiBXZSBuZWVkIHRvIGRlZmluZSB0aGUgdGVybSAiZGVmaW5pdGlvbiIuLi4gIFRo ZSBkZWZpbml0aW9uIG9mIHRoZSBub2RlCj4gaXMgYXZhaWxhYmxlIChpLmUuIHRoZSBuYW1lICdy b3V0aW5nJyBpcyBhdmFpbGFibGUgYXMgYSBjb250YWluZXIpLgoKT2gsIHNpbmNlIHRoZSAiaW5j bHVkZSIgc3RhdGVtZW50IGlzIGV4cGxhaW5lZCBzZXBhcmF0ZWx5IGZvciBtb2R1bGVzCmFuZCBz dWJtb2R1bGVzLCBJIHRob3VnaHQgImRlZmluaXRpb24iIGluIHRoZSBsYXR0ZXIgY2FzZSBtZWFu dCBlaXRoZXIKZGVmaW5pdGlvbiBvZiBhIGdyb3VwaW5nIG9yIHR5cGVkZWYuIFBlcmhhcHMgaXQg aXMgYmV0dGVyIHRvIHRhbGsgYWJvdXQKaW5jbHVzaW9uIG9mIHN5bWJvbHMuCgpMYWRhCgo+IAo+ IFRoaXMgZG9lcyAqbm90KiBtZWFuIHRoYXQgdGhlIGRlZmluaXRpb24gaXMgZHVwbGljYXRlZC4K PiAKPiAKPiAvbWFydGluCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBF NzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 1 13:17:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D875A3A680E; Mon, 1 Dec 2008 13:17:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A05F3A683D for ; Mon, 1 Dec 2008 13:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 skZEPV8w46hb for ; Mon, 1 Dec 2008 13:17:39 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 946A03A680E for ; Mon, 1 Dec 2008 13:17:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSTRUbHa37bBSW2uSZH0HMJQmJcjreLpt@postini.com; Mon, 01 Dec 2008 13:17:36 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 1 Dec 2008 13:14:57 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:14:56 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:14:56 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:14:56 -0800 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 mB1LEtM64304; Mon, 1 Dec 2008 13:14:55 -0800 (PST) (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 mB1L9gmw094288; Mon, 1 Dec 2008 21:09:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812012109.mB1L9gmw094288@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081201.215633.09865912.mbj@tail-f.com> Date: Mon, 1 Dec 2008 16:09:42 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 21:14:56.0020 (UTC) FILETIME=[DC075540:01C953F9] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >This does *not* mean that the definition is duplicated. Nor that it is transitive. If s1 includes s2 which includes s3, typedefs in s3 are not available to s1. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 13:27:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858A228C0F2; Mon, 1 Dec 2008 13:27:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9E928C0FA for ; Mon, 1 Dec 2008 13:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 r4qknhQ0mGqc for ; Mon, 1 Dec 2008 13:27:53 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D222E28C0F9 for ; Mon, 1 Dec 2008 13:27:52 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E758AD800C7; Mon, 1 Dec 2008 22:27:48 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200812012109.mB1L9gmw094288@idle.juniper.net> References: <200812012109.mB1L9gmw094288@idle.juniper.net> Organization: CESNET Date: Mon, 01 Dec 2008 22:27:50 +0100 Message-Id: <1228166870.6259.216.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMDEuIDEyLiAyMDA4IHYgMTY6MDkgLTA1MDA6Cj4gTWFy dGluIEJqb3JrbHVuZCB3cml0ZXM6Cj4gPlRoaXMgZG9lcyAqbm90KiBtZWFuIHRoYXQgdGhlIGRl ZmluaXRpb24gaXMgZHVwbGljYXRlZC4KPiAKPiBOb3IgdGhhdCBpdCBpcyB0cmFuc2l0aXZlLiAg SWYgczEgaW5jbHVkZXMgczIgd2hpY2ggaW5jbHVkZXMgczMsCj4gdHlwZWRlZnMgaW4gczMgYXJl IG5vdCBhdmFpbGFibGUgdG8gczEuCgpXaHkgYm90aGVyIHRoZW4gd2l0aCBmb3JiaWRkaW5nIGNp cmN1bGFyIGluY2x1ZGVzPyBXaXRob3V0IHRyYW5zaXRpdml0eSwKbm8gbG9vcHMgaW4gc3ltYm9s IGxvb2t1cCBjYW4gYnVpbGQgdXAuCgpMYWRhCgo+IAo+IFRoYW5rcywKPiAgUGhpbAotLSAKTGFk aXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0 bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k Cg== From netmod-bounces@ietf.org Mon Dec 1 13:49:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90553A6808; Mon, 1 Dec 2008 13:49:01 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C0F3A683D for ; Mon, 1 Dec 2008 13:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 EodqgTTFxWNp for ; Mon, 1 Dec 2008 13:48:59 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 871D43A67A4 for ; Mon, 1 Dec 2008 13:48:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSTRbxOq0MNt2OHFclp1XEXuwDe1lhk5B@postini.com; Mon, 01 Dec 2008 13:48:56 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 1 Dec 2008 13:44:38 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:44:37 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:44:37 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:44:36 -0800 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 mB1LiaM86441; Mon, 1 Dec 2008 13:44:36 -0800 (PST) (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 mB1LdIFm094635; Mon, 1 Dec 2008 21:39:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812012139.mB1LdIFm094635@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1228166870.6259.216.camel@missotis> Date: Mon, 1 Dec 2008 16:39:18 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 21:44:36.0892 (UTC) FILETIME=[0182D5C0:01C953FE] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >Why bother then with forbidding circular includes? Without transitivity, >no loops in symbol lookup can build up. Sure they can. S1 includes S2 which includes S3 which includes S1. Each submodules defines a grouping that uses a grouping from the included submodule. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 13:52:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6664B3A6874; Mon, 1 Dec 2008 13:52:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3893A6A37 for ; Mon, 1 Dec 2008 13:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 VsglAsrQZMRo for ; Mon, 1 Dec 2008 13:52:52 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id E489A3A69EE for ; Mon, 1 Dec 2008 13:52:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSTRcroBzWZ1rmXvojLKW5FMBJkN9Le3D@postini.com; Mon, 01 Dec 2008 13:52:48 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 1 Dec 2008 13:47:15 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:47:15 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:47:14 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 13:47:14 -0800 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 mB1LlDM89451; Mon, 1 Dec 2008 13:47:13 -0800 (PST) (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 mB1Lg1t1094678; Mon, 1 Dec 2008 21:42:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812012142.mB1Lg1t1094678@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1228147443.6259.129.camel@missotis> Date: Mon, 1 Dec 2008 16:42:00 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 21:47:14.0608 (UTC) FILETIME=[5F846300:01C953FE] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I don't know what this "separate compilation" >exactly means... This refers to allowing the toolset to compile each module or submodule independently. You needn't compile all submodules at the same time. This reduces the footprint of the compile in terms of memory and cpu. Unchanged submodules need not be recompiled when they (and anything they've included) does not change. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 1 14:06:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FAB3A6808; Mon, 1 Dec 2008 14:06:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E798D3A6808 for ; Mon, 1 Dec 2008 14:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 CohV2RYMZ3-y for ; Mon, 1 Dec 2008 14:06:17 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 31D563A6A5D for ; Mon, 1 Dec 2008 14:06:17 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 61BB0D800C7; Mon, 1 Dec 2008 23:06:13 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200812012139.mB1LdIFm094635@idle.juniper.net> References: <200812012139.mB1LdIFm094635@idle.juniper.net> Organization: CESNET Date: Mon, 01 Dec 2008 23:06:14 +0100 Message-Id: <1228169174.6259.232.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMDEuIDEyLiAyMDA4IHYgMTY6MzkgLTA1MDA6Cj4gTGFk aXNsYXYgTGhvdGthIHdyaXRlczoKPiA+V2h5IGJvdGhlciB0aGVuIHdpdGggZm9yYmlkZGluZyBj aXJjdWxhciBpbmNsdWRlcz8gV2l0aG91dCB0cmFuc2l0aXZpdHksCj4gPm5vIGxvb3BzIGluIHN5 bWJvbCBsb29rdXAgY2FuIGJ1aWxkIHVwLgo+IAo+IFN1cmUgdGhleSBjYW4uICBTMSBpbmNsdWRl cyBTMiB3aGljaCBpbmNsdWRlcyBTMyB3aGljaAo+IGluY2x1ZGVzIFMxLiAgRWFjaCBzdWJtb2R1 bGVzIGRlZmluZXMgYSBncm91cGluZyB0aGF0Cj4gdXNlcyBhIGdyb3VwaW5nIGZyb20gdGhlIGlu Y2x1ZGVkIHN1Ym1vZHVsZS4KCldoYXQgeW91IHByb2JhYmx5IG1lYW4gaXMganVzdCBpbmZpbml0 ZSByZWN1cnNpb24gaW4gZGVmaW5pdGlvbnMgYW5kIHlvdQpjYW4gbWFrZSBpdCBpbiBhIHNpbmds ZSBtb2R1bGUsIHRvby4gSXQncyBub3QgYSBwcm9ibGVtIG9mIGNpcmN1bGFyCmluY2x1ZGVzLgoK TGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Dec 1 14:45:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24933A6BB3; Mon, 1 Dec 2008 14:45:43 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2483A6BB5 for ; Mon, 1 Dec 2008 14:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, 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 AxYGgAMYudWD for ; Mon, 1 Dec 2008 14:45:42 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 1E6D63A6BB3 for ; Mon, 1 Dec 2008 14:45:42 -0800 (PST) Received: (qmail 56720 invoked from network); 1 Dec 2008 22:45:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 1 Dec 2008 22:45:37 -0000 X-YMail-OSG: qv_Yv7cVM1m3b.DU9p3mlIRJSSkMHbP4ziqgcJekV.asx2q_Smdc6Ta2j1u3E_V7neEjD9quMhJuG2dNlEDqjRTct.MoxCys7kjtF5n4OdCj2DSMdvXQXmbxcS5bBMLpeic- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4934690F.5060909@netconfcentral.com> Date: Mon, 01 Dec 2008 14:45:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <200812012139.mB1LdIFm094635@idle.juniper.net> <1228169174.6259.232.camel@missotis> In-Reply-To: <1228169174.6259.232.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IFBvIDAxLiAxMi4g MjAwOCB2IDE2OjM5IC0wNTAwOgo+PiBMYWRpc2xhdiBMaG90a2Egd3JpdGVzOgo+Pj4gV2h5IGJv dGhlciB0aGVuIHdpdGggZm9yYmlkZGluZyBjaXJjdWxhciBpbmNsdWRlcz8gV2l0aG91dCB0cmFu c2l0aXZpdHksCj4+PiBubyBsb29wcyBpbiBzeW1ib2wgbG9va3VwIGNhbiBidWlsZCB1cC4KPj4g U3VyZSB0aGV5IGNhbi4gIFMxIGluY2x1ZGVzIFMyIHdoaWNoIGluY2x1ZGVzIFMzIHdoaWNoCj4+ IGluY2x1ZGVzIFMxLiAgRWFjaCBzdWJtb2R1bGVzIGRlZmluZXMgYSBncm91cGluZyB0aGF0Cj4+ IHVzZXMgYSBncm91cGluZyBmcm9tIHRoZSBpbmNsdWRlZCBzdWJtb2R1bGUuCj4gCj4gV2hhdCB5 b3UgcHJvYmFibHkgbWVhbiBpcyBqdXN0IGluZmluaXRlIHJlY3Vyc2lvbiBpbiBkZWZpbml0aW9u cyBhbmQgeW91Cj4gY2FuIG1ha2UgaXQgaW4gYSBzaW5nbGUgbW9kdWxlLCB0b28uIEl0J3Mgbm90 IGEgcHJvYmxlbSBvZiBjaXJjdWxhcgo+IGluY2x1ZGVzLgo+IAoKVGhlcmUgYXJlIHNldmVyYWwg b3Bwb3J0dW5pdGllcyBmb3IgdGhlIERNIHdyaXRlciB0bwptZXNzIHVwIGFuZCBkZWZpbmUgc29t ZSBzb3J0IG9mIGludGVyLW1vZHVsZQpvciBpbnRyYS1tb2R1bGUgZGVmaW5pdGlvbiBsb29wLgpZ b3Ugc2hvdWxkIGRldGVjdCBhbGwgb2YgdGhlbS4KCllvdXIgY29tcGlsZXIgY2Fubm90IGJsaW5k bHkgc3RhcnQgUzEgd2hpbGUgY29tcGlsaW5nIFMzLAphbmQgdGhlbiBvZmYgaW50byBTMiwgYW5k IHRoZW4gUzMsIGFuZCByb3VuZCBhbmQgcm91bmQuClRoZXNlIHNob3VsZCBiZSBlcnJvcnMgYmVj YXVzZSB3aGVuIHlvdSBnZXQgdG8gJ2luY2x1ZGUgUzEnCmluc2lkZSBTMywgeW91IGJldHRlciBr bm93IG5vdCB0byBob25vciBpdCwgb3IgeW91IHdpbGwgc3RhcnQgYSBsb29wLgpTaW5jZSB5b3Ug Y2Fubm90IGhvbm9yIGl0LCBpdCBzaG91bGQgYmUgYW4gZXJyb3IuCgo+IExhZGEKPiAKCkFuZHkK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBt YWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Tue Dec 2 08:10:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D173A68FD; Tue, 2 Dec 2008 08:10:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CE43A6953 for ; Tue, 2 Dec 2008 08:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 2PVezQWapHlK for ; Tue, 2 Dec 2008 08:10:24 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B0A8F3A69D3 for ; Tue, 2 Dec 2008 08:10:23 -0800 (PST) Received: (qmail 155 invoked from network); 2 Dec 2008 16:10:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.225.29 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 2 Dec 2008 16:10:18 -0000 X-YMail-OSG: xJmQTJwVM1kb0coB5nLPA06qshev0sRsIsnewSjH6Efd4.VMNoxhoVL4WpgoEoiu_rQtnksYn0LLjF__8MhjEEY3UtVwIErnXfC7No5vMD6Cx6hEsHpfcg5XEKlAjhUcUYnvF0VUZ6Bk61W.dC0LVwZi X-Yahoo-Newman-Property: ymail-3 Message-ID: <49355DE8.1030408@netconfcentral.com> Date: Tue, 02 Dec 2008 08:10:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] sec. 7.16.2; identity base X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, 1) Can any identity be a base for another one? From 17.6.3: module des { namespace "http://example.com/des"; prefix "des"; import "crypto-base" { prefix "crypto"; } identity des { base "crypto:crypto-alg"; description "DES crypto algorithm"; } identity des3 { base "crypto:crypto-alg"; description "Triple DES crypto algorithm"; } } What if the 'des' module defined its own base? Is this allowed? module des { namespace "http://example.com/des"; prefix "des"; import "crypto-base" { prefix "crypto"; } identity des-base { base "crypto:crypto-alg"; description "identity base for all identities in this module"; } identity des { base "des-base"; description "DES crypto algorithm"; } identity des3 { base "des-base"; description "Triple DES crypto algorithm"; } } 2) Is a base-reference loop a fatal error? (I hope so) identity A { base B; } identity B { base C; } identity C { base A; } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 08:19:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5F23A69D3; Tue, 2 Dec 2008 08:19:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCA43A69E7 for ; Tue, 2 Dec 2008 08:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.745, 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 A13HTQknL0lj for ; Tue, 2 Dec 2008 08:19:11 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id C40343A69D3 for ; Tue, 2 Dec 2008 08:19:11 -0800 (PST) Received: (qmail 34045 invoked from network); 2 Dec 2008 16:19:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.225.29 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 2 Dec 2008 16:19:06 -0000 X-YMail-OSG: 7B2CS4gVM1nv_vRu0EZME15I.4LKctUrwzCM.bIK6iRiv6RfHUIyLAjcxZGb5lpLpvh.u5tz9KVdhSBNgRVaMtZ58wyifQJluM7KVZnJe1aFxse8N.nu6An2niAHKw.qj90- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49355FF9.2090809@netconfcentral.com> Date: Tue, 02 Dec 2008 08:19:05 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200811301937.mAUJbZbK085399@idle.juniper.net> In-Reply-To: <200811301937.mAUJbZbK085399@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] yang-02 examples nits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> 1) pg 91.: augment example uses type ChannelNumber, which is not >> defined anywhere > > Given that examples are not meant to be fully self-contained, I'm > not sure I see an issue here. ChannelNumber may be defined elsewhere > in the module, not all of which is included in the example. > Most of them are self-contained, or they reference previous examples. Somebody might think ChannelNumber is a builtin type, because they are the only types that get used without any associated YANG definition. >> 2) sec. 9.4.5: 2nd and 3rd constructs should be legal YANG. >> The type clause cannot appear alone, and this example is confusing. > > This type clause can appear inside a leaf or a typedef. The examples > aren't meant to be self-contained, so the enclosing statements are > not included. > The examples need to be self-explanatory. As a co-author, you have no idea how many details your brain is filling in (correctly) for each example. For somebody looking at the spec the very first time, the details will likely get filled in differently. How about a short sentence before the 2 'type' statements: Another typedef or a leaf statement may refine the previous typedef range statement. For example: >> 3) sec. 9.6.5: it would be good to show an enumeration example >> that has complex identifiers, to point out how different >> they are from bit names. >> typedef my-display-duplex { >> type enumeration { >> enum 'half duplex'; >> enum 'full duplex'; >> enum 'unknown duplex'; >> } >> } > > If we need this, we should use a better example, since > half is a better encoding. Personally I think > this (the ability of a enum to contain a space) is a minor point > nor worthy of an example. > Fine -- pick a better example. Show just 1 enum with quotes. I think that some developers will miss this important detail and not allow 'inside' whitespace. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 10:24:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC0E3A691A; Tue, 2 Dec 2008 10:24:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A233A691A for ; Tue, 2 Dec 2008 10:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 NCYwYC4Vhn4N for ; Tue, 2 Dec 2008 10:24:22 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id A0A673A67D0 for ; Tue, 2 Dec 2008 10:24:21 -0800 (PST) X-Trace: 113491427/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.200/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.200 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAJsLNUk+vGnI/2dsb2JhbACDRIlUxVcHgng X-IronPort-AV: E=Sophos;i="4.33,702,1220223600"; d="scan'208";a="113491427" X-IP-Direction: IN Received: from 1cust200.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.200]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Dec 2008 18:24:15 +0000 Message-ID: <002101c954a2$e31662a0$0601a8c0@allison> From: "tom.petch" To: "Balazs Lengyel" , "NETMOD Working Group" References: <4907A049.10709@ericsson.com> Date: Tue, 2 Dec 2008 18:07:44 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] defaults - needed updates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I haven't seen a follow up to this which seems a shame since it (re-)raises something already much discussed but about which a consensus seems hard to reach. I refer to the section at the end (before the text repeats itself) describing three incompatible views of config and defaults, and then saying that YANG must accommodate them all. This does seem to me to be rather optimistic for YANG, where there are already murmurings about constraining the options because it is so complex and yet, post interim, still wanting to be all things to all (or at least three) men. How this specific issue gets resolved I do not know. That it is unresolved - and it has occurred several times on this list - seems a flaw in YANG, or perhaps in the process of this WG. For myself, the approach attributed to Mr Juniper (we are all of course here as individuals) seems closest to sensible, that of Mr Cisco the least. Tom Petch ----- Original Message ----- From: "Balazs Lengyel" To: "NETMOD Working Group" Sent: Wednesday, October 29, 2008 12:29 AM Subject: [netmod] defaults - needed updates > We agreed on the Reston interim on the following about the handling > of defaults > > Management agents report default data in different ways. > o Report all: All default data is always reported. > o Trim: Values are not reported if they match the default. > o Explicit: Report values if they are explicitly set. > > We want to accommodate all in YANG. > > I got the task of proposing some specific additions to the draft. Here they are with some explanation. > Balazs > > ---------------------------------------------------------------- > > Defaults potentially effect the following stuff: > > 1) concept of the default > Solution: > ==== ADD: > Add to "7.6 The leaf Statement" > "Leafs with a default value, may or may not exist in the conceptual datastore. " > > 2) get-config/get reply content > - Implement the Netconf with-defaults extension, this can > force all default values to be returned. I will take the draft to NETCONF. > ===== ADD: > reference to the with-defaults draft. > > 3) evaluation of the must/when/unique constraints > - "7.8.3 The list's unique Statement" must be extended: > ===== ADD: > "The unique constraint is conceptually evaluated on all nodes in the > data tree, and all leafs with default values." > > must and when are already OK > leafs with defaults are considered as existing during the evaluation > of must/when > > 4) Are the must constraints on a default leafs evaluated > Already OK > > 5) success of edit-config create/delete > Different nodes might give different answers to an edit-config > operation, but this is not crucial. Error on delete is > not important. Instead of create: replace or merge can be used. > The different behavior is a consequence of 1). It can be described as a > capability in the with-defaults draft. > (The manager has the option to just ignore the capability.) > > 6) Existence of np-containers > Already OK > Depends on whether default leafs exist. No additional text needed. > > > 3 models of handling defaults: > > Juniper) defaults don't exist, but if you explicitly set a leaf > to its default it exists. Configuration is what you have sent in > edit-config. > > Cisco) defaults don't exist. if you explicitly set a leaf to its > default it disappears. Configuration is everything without defaults. > > Ericsson) Defaults always exist. Configuration is what drives > the device. > > We want to accomodate all in YANG. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 11:00:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6DD3A680D; Tue, 2 Dec 2008 11:00:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30453A6B57 for ; Tue, 2 Dec 2008 11:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LFB6NGn9q5rA for ; Tue, 2 Dec 2008 11:00:51 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 0C6473A680D for ; Tue, 2 Dec 2008 11:00:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSTWF2hr8+i9cwYeOuGwjVvmyUyadnx6+@postini.com; Tue, 02 Dec 2008 11:00:48 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 10:57:19 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 10:57:19 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 10:57:19 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 10:57:18 -0800 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 mB2IvBM47489; Tue, 2 Dec 2008 10:57:12 -0800 (PST) (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 mB2Ipw7U002645; Tue, 2 Dec 2008 18:51:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812021851.mB2Ipw7U002645@idle.juniper.net> To: "tom.petch" In-Reply-To: <002101c954a2$e31662a0$0601a8c0@allison> Date: Tue, 2 Dec 2008 13:51:57 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Dec 2008 18:57:18.0796 (UTC) FILETIME=[CCC0B0C0:01C954AF] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] defaults - needed updates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "tom.petch" writes: >How this specific issue gets resolved I do not know. That it is >unresolved - and it has occurred several times on this list - seems >a flaw in YANG, or perhaps in the process of this WG. The plan is to give wiggle room for servers to behave in their native manner. When the current (or incoming) value is identical to the declared default, the server can ignore it. For , this means if the leaf was previously set to the default value, the value need not be present in the reply, and if the leaf was deleted (or never created) the default value is allowed to appear in the reply. For , this means if the value is equal to the default, the server can avoid creating it. It also means that create and delete operations need to not give errors in circumstances where defaults are involved. Create operations should not fail if the leaf exists but contains the default value, and delete operations should not fail if the leaf does not exist, since if could have been set to the default value. These are odd rules, but seem to cover default-related behavior in a way that allows all three default-handling models in a workable compromise. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 11:47:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617373A6B3A; Tue, 2 Dec 2008 11:47:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341D93A6B52 for ; Tue, 2 Dec 2008 11:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 ACBwprqDbLF3 for ; Tue, 2 Dec 2008 11:47:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4BDED3A6B58 for ; Tue, 2 Dec 2008 11:46:15 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7FBD276C310; Tue, 2 Dec 2008 20:46:09 +0100 (CET) Date: Tue, 02 Dec 2008 20:46:09 +0100 (CET) Message-Id: <20081202.204609.115092829.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49355DE8.1030408@netconfcentral.com> References: <49355DE8.1030408@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] sec. 7.16.2; identity base X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > > 1) Can any identity be a base for another one? [...] > What if the 'des' module defined its own base? > Is this allowed? Yes. Do you think it needs to be explicitly stated? Today it says: The base statement, which is optional, takes as an argument a string which is the name of an existing identity, from which the new identity is derived. Without any constraints on the existing identity. > 2) Is a base-reference loop a fatal error? (I hope so) > > > identity A { base B; } > identity B { base C; } > identity C { base A; } Yes. I will add the same text we have for groupings and typedefs: An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 11:54:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81803A6B58; Tue, 2 Dec 2008 11:54:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817133A6B65 for ; Tue, 2 Dec 2008 11:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 eeshrr3e80VH for ; Tue, 2 Dec 2008 11:54:22 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 47E293A6B58 for ; Tue, 2 Dec 2008 11:54:22 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1606776C310; Tue, 2 Dec 2008 20:54:18 +0100 (CET) Date: Tue, 02 Dec 2008 20:54:15 +0100 (CET) Message-Id: <20081202.205415.134364559.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200812021851.mB2Ipw7U002645@idle.juniper.net> References: <002101c954a2$e31662a0$0601a8c0@allison> <200812021851.mB2Ipw7U002645@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] defaults - needed updates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > "tom.petch" writes: > >How this specific issue gets resolved I do not know. That it is > >unresolved - and it has occurred several times on this list - seems > >a flaw in YANG, or perhaps in the process of this WG. > > The plan is to give wiggle room for servers to behave in their > native manner. And I think that the draft now does that. The missing piece of the puzzle is the :with-defaults capability, which is worked on in the NETCONF WG. It is needed for the device to report to the manager how it handles default values natively. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 12:12:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0FD03A67BD; Tue, 2 Dec 2008 12:12:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906223A6B5D for ; Tue, 2 Dec 2008 12:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.372, 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 t-TS3ttb87sl for ; Tue, 2 Dec 2008 12:12:44 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id DFCCB3A67BD for ; Tue, 2 Dec 2008 12:12:44 -0800 (PST) Received: (qmail 99549 invoked from network); 2 Dec 2008 20:12:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.225.29 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 2 Dec 2008 20:12:39 -0000 X-YMail-OSG: MMxThp0VM1kf2ngZezw6pByEODhxB052eh0aLI4b6dA0BBtysYLtdn4Ze3CtW_P_a84z5VyEU67wpmyd0qApfi5P5USPlRkPv_e.xuH_VJaA00H3lfBErAISlxZ1V4YG_.Q- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493596B5.9030604@netconfcentral.com> Date: Tue, 02 Dec 2008 12:12:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I've been waiting for others to implement this, so I can let them ask these questions, but too late... pg 97, last para in 7.18.1: The "if-feature" statement can be used in many places within the YANG syntax. Definitions tagged with "if-feature" are ignored when the device does not support that feature. We need a much more precise definition of 'ignored'. The portion of the data model tagged conditional is not ignored within all the compile-time YANG validation. In fact, if-feature is ignored then because the compiler cannot know which features will be enables at runtime. pg 98, sec. 7.18.2 This section looks rather cut-and-pasted. It never actually mentions what it means for a feature to exist only if these other features exist. It does not mean what the text says, but rather is intended to indicate the dependencies for a feature. feature foo; feature bar { if-feature foo; } Since feature 'bar' does not actually exist anywhere except a tiny substring within a capability URI, the draft needs to specify what this construct means. I assume it means "an implementation MUST support 'foo' if it supports 'bar'. You also need the same 'anti-loop text' here as for identity. feature foo { if-feature baz; } feature bar { if-feature foo; } feature baz { if-feature bar; } Is this sort of loop legal or not? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 12:31:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D17A3A6B3D; Tue, 2 Dec 2008 12:31:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22B83A6B7D for ; Tue, 2 Dec 2008 12:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 gulC2MogYXIu for ; Tue, 2 Dec 2008 12:31:36 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D40533A6B3D for ; Tue, 2 Dec 2008 12:31:35 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 397E476C310; Tue, 2 Dec 2008 21:31:31 +0100 (CET) Date: Tue, 02 Dec 2008 21:31:29 +0100 (CET) Message-Id: <20081202.213129.227665121.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493596B5.9030604@netconfcentral.com> References: <493596B5.9030604@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > I've been waiting for others to implement this, so I can let > them ask these questions, but too late... > > pg 97, last para in 7.18.1: > > The "if-feature" statement can be used in many places within the YANG > syntax. Definitions tagged with "if-feature" are ignored when the > device does not support that feature. > > We need a much more precise definition of 'ignored'. Ok. What we want to say is that if the device does not the feature, it behaves as if the definition (which was tagged with if-feature) was not there at all. > The portion of the data model tagged conditional is > not ignored within all the compile-time YANG validation. > In fact, if-feature is ignored then because the compiler > cannot know which features will be enables at runtime. This is an implementation detail. Some compilers might require the feature list at compile time, and others at run time. > pg 98, sec. 7.18.2 > > This section looks rather cut-and-pasted. > It never actually mentions what it means for a feature > to exist only if these other features exist. It does > not mean what the text says I don't understand which text you refer to? >, but rather is intended to > indicate the dependencies for a feature. > > > feature foo; > > feature bar { > if-feature foo; > } > > > Since feature 'bar' does not actually exist anywhere > except a tiny substring within a capability URI, > the draft needs to specify what this construct means. > I assume it means "an implementation MUST support 'foo' > if it supports 'bar'. Yes. This follows from the fact that if the device does not implement 'foo', then the 'feature bar' statement is ignored. > You also need the same 'anti-loop text' here as for identity. Yep, I added it just after publishing -02 ;-) /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 12:57:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF053A6778; Tue, 2 Dec 2008 12:57:08 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D323A6B91 for ; Tue, 2 Dec 2008 12:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 BOzdaB7VwL8G for ; Tue, 2 Dec 2008 12:57:07 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 831963A6BD5 for ; Tue, 2 Dec 2008 12:56:19 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DE4976C310 for ; Tue, 2 Dec 2008 21:56:14 +0100 (CET) Date: Tue, 02 Dec 2008 21:56:12 +0100 (CET) Message-Id: <20081202.215612.124335277.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, We have been talking several times about adding a statement "assigned-by system" to the "leaf" statement. I believe that the chairs will send out a call for consenus to the list. The idea is that if a leaf is marked as assigned-by system, then the client MAY choose to not set a value for the leaf when its parent instance is created. In this case the system will assign a suitable value for the leaf. In Minneapolis the question was raised how this interacts with 'mandatory' and 'default', and also if the server MUST or MAY assign a value. Since we already have 'mandatory' which means that a leaf MUST exist in a valid data store, it makes sense to use it also for this purpose: leaf foo { type string; mandatory true; assigned-by system; } leaf bar { type string; assigned-by system; } With these definitions, if the client does not assign a value to "foo", the server MUST assign a value, but if the client does not set "bar", the server MAY assign a value. I'm a bit worried that this interpretation is not ... obvious. An alternative could be to go with one (MUST or MAY), and say that "assigned-by system" and "mandatory true" must not be used at the same time, but that might be too restrictive, and it adds a CLR. As for 'default' and assigned-by system, with the interpretation above, we could stick with the rules we have. I.e. a 'default' statement on "foo" would not be allowed (since "foo" is mandatory), but it would be allowed in "bar" - if "bar" is not set by either the client or server, the default value is used internally. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 16:50:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5D228C227; Tue, 2 Dec 2008 16:50:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112FC28C23A for ; Tue, 2 Dec 2008 16:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.085, 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 1nvBKoqU5tt9 for ; Tue, 2 Dec 2008 16:50:38 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 5D95628C227 for ; Tue, 2 Dec 2008 16:50:38 -0800 (PST) Received: (qmail 5812 invoked from network); 3 Dec 2008 00:50:34 -0000 Received: from unknown (HELO andymac.local) (andy@67.127.234.25 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 3 Dec 2008 00:50:34 -0000 X-YMail-OSG: gSfIV3cVM1k75w._2ycG62RMmwlRPQf43T5kuRjMUvHXnNIFtbzmVPFoUWyckt6UuzVU45BCrvrn.o2uBbjXpQ1_ULZMcqnfsNgOCHy1IKXnM_4To5IslO2Fgn5JrDRVENi8FDQ3UgyJiETasvAGINir X-Yahoo-Newman-Property: ymail-3 Message-ID: <4935D7D9.7040900@netconfcentral.com> Date: Tue, 02 Dec 2008 16:50:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493596B5.9030604@netconfcentral.com> <20081202.213129.227665121.mbj@tail-f.com> In-Reply-To: <20081202.213129.227665121.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: > >> Hi, >> >> I've been waiting for others to implement this, so I can let >> them ask these questions, but too late... >> >> pg 97, last para in 7.18.1: >> >> The "if-feature" statement can be used in many places within the YANG >> syntax. Definitions tagged with "if-feature" are ignored when the >> device does not support that feature. >> >> We need a much more precise definition of 'ignored'. >> > > Ok. What we want to say is that if the device does not the feature, > it behaves as if the definition (which was tagged with if-feature) was > not there at all. > > >> The portion of the data model tagged conditional is >> not ignored within all the compile-time YANG validation. >> In fact, if-feature is ignored then because the compiler >> cannot know which features will be enables at runtime. >> > > This is an implementation detail. Some compilers might require the > feature list at compile time, and others at run time. > > This needs to be specified in the draft, which way it works. I do not agree that the feature list should be given at compile-time. For only 4 features, a developer would need to compile the same file 16 times to check all the combinations. >> pg 98, sec. 7.18.2 >> >> This section looks rather cut-and-pasted. >> It never actually mentions what it means for a feature >> to exist only if these other features exist. It does >> not mean what the text says >> > > I don't understand which text you refer to? > > >> , but rather is intended to >> indicate the dependencies for a feature. >> >> >> feature foo; >> >> feature bar { >> if-feature foo; >> } >> >> >> Since feature 'bar' does not actually exist anywhere >> except a tiny substring within a capability URI, >> the draft needs to specify what this construct means. >> I assume it means "an implementation MUST support 'foo' >> if it supports 'bar'. >> > > Yes. This follows from the fact that if the device does not implement > 'foo', then the 'feature bar' statement is ignored. > > >> You also need the same 'anti-loop text' here as for identity. >> > > Yep, I added it just after publishing -02 ;-) > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 2 23:36:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6850E3A6AFF; Tue, 2 Dec 2008 23:36:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEFD3A6B0F for ; Tue, 2 Dec 2008 23:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 YPJbs83jKNNb for ; Tue, 2 Dec 2008 23:36:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 205243A6AFF for ; Tue, 2 Dec 2008 23:36:41 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 93C1E76C528; Wed, 3 Dec 2008 08:36:34 +0100 (CET) Date: Wed, 03 Dec 2008 08:36:34 +0100 (CET) Message-Id: <20081203.083634.96759531.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4935D7D9.7040900@netconfcentral.com> References: <493596B5.9030604@netconfcentral.com> <20081202.213129.227665121.mbj@tail-f.com> <4935D7D9.7040900@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > >> The portion of the data model tagged conditional is > >> not ignored within all the compile-time YANG validation. > >> In fact, if-feature is ignored then because the compiler > >> cannot know which features will be enables at runtime. > >> > > > > This is an implementation detail. Some compilers might require the > > feature list at compile time, and others at run time. > > > > > > > This needs to be specified in the draft, which way it works. > I do not agree that the feature list should be given at compile-time. > For only 4 features, a developer would need to compile the same file > 16 times to check all the combinations. Sorry, I misunderstood what you meant. A decent YANG validator should of course not require the designer to run the thing 16 times. But a code generator might generate code for just the features supported on the box, as specified by the developer at compile/implementation time. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 00:38:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848AF3A66B4; Wed, 3 Dec 2008 00:38:38 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7006D3A6B16 for ; Wed, 3 Dec 2008 00:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 u-QUCP3y+7LL for ; Wed, 3 Dec 2008 00:38:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 268AA3A66B4 for ; Wed, 3 Dec 2008 00:38:35 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E3648D800BD for ; Wed, 3 Dec 2008 09:38:26 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081202.215612.124335277.mbj@tail-f.com> References: <20081202.215612.124335277.mbj@tail-f.com> Organization: CESNET Date: Wed, 03 Dec 2008 09:38:26 +0100 Message-Id: <1228293506.6315.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGkgTWFydGluLAoKYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gaXMgd2hhdCAic3lzdGVtIiBtZWFu cyBhbmQgd2hldGhlciB0aGUgYXV0b21hdGljCmFzc2lnbm1lbnQgbWF5IGRlcGVuZCBvbiBvdGhl ciBjaXJjdW1zdGFuY2VzLiBBc3NpZ25pbmcgdW5pcXVlIGxpc3Qga2V5cwppcyBhIHJlbGF0aXZl bHkgZWFzeSwgYnV0IGhvdyBhYm91dCBlLmcuLCBpbnRlcmZhY2UgYWRkcmVzc2VzOiBUaGV5IG1h eQpiZSBzZXQgbWFudWFsbHkgYnkgdGhlIG1hbmFnZXIsIG9yIGFzc2lnbmVkIGJ5ICJzeXN0ZW0i IHZpYSBESENQIG9yCnJvdXRlciBhZHZlcnRpc2VtZW50cy4gSW4gdGhlIGxhdHRlciBjYXNlLCB0 aGUgYXV0by1hc3NpZ25tZW50IG1heSBvcgptYXkgbm90IGhhcHBlbiBkZXBlbmRpbmcgb24gY29u ZGl0aW9ucyB0aGF0IGFyZSBleHRlcm5hbCB0byB0aGUgYm94LgoKTGFkYQoKTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMDIuIDEyLiAyMDA4IHYgMjE6NTYgKzAxMDA6Cj4gSGksCj4gCj4g V2UgaGF2ZSBiZWVuIHRhbGtpbmcgc2V2ZXJhbCB0aW1lcyBhYm91dCBhZGRpbmcgYSBzdGF0ZW1l bnQKPiAiYXNzaWduZWQtYnkgc3lzdGVtIiB0byB0aGUgImxlYWYiIHN0YXRlbWVudC4gIEkgYmVs aWV2ZSB0aGF0IHRoZQo+IGNoYWlycyB3aWxsIHNlbmQgb3V0IGEgY2FsbCBmb3IgY29uc2VudXMg dG8gdGhlIGxpc3QuCj4gCj4gVGhlIGlkZWEgaXMgdGhhdCBpZiBhIGxlYWYgaXMgbWFya2VkIGFz IGFzc2lnbmVkLWJ5IHN5c3RlbSwgdGhlbiB0aGUKPiBjbGllbnQgTUFZIGNob29zZSB0byBub3Qg c2V0IGEgdmFsdWUgZm9yIHRoZSBsZWFmIHdoZW4gaXRzIHBhcmVudAo+IGluc3RhbmNlIGlzIGNy ZWF0ZWQuICBJbiB0aGlzIGNhc2UgdGhlIHN5c3RlbSB3aWxsIGFzc2lnbiBhIHN1aXRhYmxlCj4g dmFsdWUgZm9yIHRoZSBsZWFmLgo+IAo+IEluIE1pbm5lYXBvbGlzIHRoZSBxdWVzdGlvbiB3YXMg cmFpc2VkIGhvdyB0aGlzIGludGVyYWN0cyB3aXRoCj4gJ21hbmRhdG9yeScgYW5kICdkZWZhdWx0 JywgYW5kIGFsc28gaWYgdGhlIHNlcnZlciBNVVNUIG9yIE1BWSBhc3NpZ24gYQo+IHZhbHVlLgo+ IAo+IFNpbmNlIHdlIGFscmVhZHkgaGF2ZSAnbWFuZGF0b3J5JyB3aGljaCBtZWFucyB0aGF0IGEg bGVhZiBNVVNUIGV4aXN0Cj4gaW4gYSB2YWxpZCBkYXRhIHN0b3JlLCBpdCBtYWtlcyBzZW5zZSB0 byB1c2UgaXQgYWxzbyBmb3IgdGhpcyBwdXJwb3NlOgo+IAo+ICAgbGVhZiBmb28gewo+ICAgICAg IHR5cGUgc3RyaW5nOwo+ICAgICAgIG1hbmRhdG9yeSB0cnVlOwo+ICAgICAgIGFzc2lnbmVkLWJ5 IHN5c3RlbTsKPiAgIH0KPiAKPiAgIGxlYWYgYmFyIHsKPiAgICAgICB0eXBlIHN0cmluZzsKPiAg ICAgICBhc3NpZ25lZC1ieSBzeXN0ZW07Cj4gICB9Cj4gCj4gV2l0aCB0aGVzZSBkZWZpbml0aW9u cywgaWYgdGhlIGNsaWVudCBkb2VzIG5vdCBhc3NpZ24gYSB2YWx1ZSB0bwo+ICJmb28iLCB0aGUg c2VydmVyIE1VU1QgYXNzaWduIGEgdmFsdWUsIGJ1dCBpZiB0aGUgY2xpZW50IGRvZXMgbm90IHNl dAo+ICJiYXIiLCB0aGUgc2VydmVyIE1BWSBhc3NpZ24gYSB2YWx1ZS4KPiAKPiBJJ20gYSBiaXQg d29ycmllZCB0aGF0IHRoaXMgaW50ZXJwcmV0YXRpb24gaXMgbm90IC4uLiBvYnZpb3VzLgo+IAo+ IEFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIGdvIHdpdGggb25lIChNVVNUIG9yIE1BWSksIGFu ZCBzYXkgdGhhdAo+ICJhc3NpZ25lZC1ieSBzeXN0ZW0iIGFuZCAibWFuZGF0b3J5IHRydWUiIG11 c3Qgbm90IGJlIHVzZWQgYXQgdGhlIHNhbWUKPiB0aW1lLCBidXQgdGhhdCBtaWdodCBiZSB0b28g cmVzdHJpY3RpdmUsIGFuZCBpdCBhZGRzIGEgQ0xSLgo+IAo+IEFzIGZvciAnZGVmYXVsdCcgYW5k IGFzc2lnbmVkLWJ5IHN5c3RlbSwgd2l0aCB0aGUgaW50ZXJwcmV0YXRpb24KPiBhYm92ZSwgd2Ug Y291bGQgc3RpY2sgd2l0aCB0aGUgcnVsZXMgd2UgaGF2ZS4gIEkuZS4gYSAnZGVmYXVsdCcKPiBz dGF0ZW1lbnQgb24gImZvbyIgd291bGQgbm90IGJlIGFsbG93ZWQgKHNpbmNlICJmb28iIGlzIG1h bmRhdG9yeSksCj4gYnV0IGl0IHdvdWxkIGJlIGFsbG93ZWQgaW4gImJhciIgLSBpZiAiYmFyIiBp cyBub3Qgc2V0IGJ5IGVpdGhlciB0aGUKPiBjbGllbnQgb3Igc2VydmVyLCB0aGUgZGVmYXVsdCB2 YWx1ZSBpcyB1c2VkIGludGVybmFsbHkuCj4gCj4gCj4gL21hcnRpbgo+IAo+IAo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcg bGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRF OEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0 bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Dec 3 00:48:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0C23A66B4; Wed, 3 Dec 2008 00:48:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7EA3A6A6A for ; Wed, 3 Dec 2008 00:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 KXN0bBmZh3zp for ; Wed, 3 Dec 2008 00:48:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D59CA3A66B4 for ; Wed, 3 Dec 2008 00:48:52 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A053176C51F; Wed, 3 Dec 2008 09:48:47 +0100 (CET) Date: Wed, 03 Dec 2008 09:48:47 +0100 (CET) Message-Id: <20081203.094847.62858977.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1228293506.6315.25.camel@missotis> References: <20081202.215612.124335277.mbj@tail-f.com> <1228293506.6315.25.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi Martin, > > an interesting question is what "system" means and whether the automatic > assignment may depend on other circumstances. Assigning unique list keys > is a relatively easy, but how about e.g., interface addresses: They may > be set manually by the manager, or assigned by "system" via DHCP or > router advertisements. I don't think such an object would be defined as "assigned-by system", since an address received by DHCP is dynamic and does not modify the configuration. If the leaf is "assigned-by system", the system fills in a valus in the configuration, and from then it behaves just as if the user had entered this value from the start. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 01:19:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA7C3A6B33; Wed, 3 Dec 2008 01:19:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA763A6B42 for ; Wed, 3 Dec 2008 01:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 5riuMsfUgTU3 for ; Wed, 3 Dec 2008 01:18:58 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E7D413A6B33 for ; Wed, 3 Dec 2008 01:18:57 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 79C3FD800C5; Wed, 3 Dec 2008 10:18:53 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081203.094847.62858977.mbj@tail-f.com> References: <20081202.215612.124335277.mbj@tail-f.com> <1228293506.6315.25.camel@missotis> <20081203.094847.62858977.mbj@tail-f.com> Organization: CESNET Date: Wed, 03 Dec 2008 10:18:53 +0100 Message-Id: <1228295933.6315.37.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAwMy4gMTIuIDIwMDggdiAwOTo0OCArMDEwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gSGkgTWFydGlu LAo+ID4gCj4gPiBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiBpcyB3aGF0ICJzeXN0ZW0iIG1lYW5z IGFuZCB3aGV0aGVyIHRoZSBhdXRvbWF0aWMKPiA+IGFzc2lnbm1lbnQgbWF5IGRlcGVuZCBvbiBv dGhlciBjaXJjdW1zdGFuY2VzLiBBc3NpZ25pbmcgdW5pcXVlIGxpc3Qga2V5cwo+ID4gaXMgYSBy ZWxhdGl2ZWx5IGVhc3ksIGJ1dCBob3cgYWJvdXQgZS5nLiwgaW50ZXJmYWNlIGFkZHJlc3Nlczog VGhleSBtYXkKPiA+IGJlIHNldCBtYW51YWxseSBieSB0aGUgbWFuYWdlciwgb3IgYXNzaWduZWQg YnkgInN5c3RlbSIgdmlhIERIQ1Agb3IKPiA+IHJvdXRlciBhZHZlcnRpc2VtZW50cy4KPiAKPiBJ IGRvbid0IHRoaW5rIHN1Y2ggYW4gb2JqZWN0IHdvdWxkIGJlIGRlZmluZWQgYXMgImFzc2lnbmVk LWJ5Cj4gc3lzdGVtIiwgc2luY2UgYW4gYWRkcmVzcyByZWNlaXZlZCBieSBESENQIGlzIGR5bmFt aWMgYW5kIGRvZXMgbm90Cj4gbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9uLgoKRG8geW91IG1lYW4g dGhhdCBpdCBiZWNvbWVzICJjb25maWcgZmFsc2UiIHR5cGUgb2YgZGF0YSBpbiB0aGlzIGNhc2U/ CkJ1dCB0aGUgbWFuYWdlciBtdXN0IGFsc28gYmUgYWJsZSB0byBzZXQgdGhlIGFkZHJlc3MgbWFu dWFsbHksIHNvIHRoZXJlCmhhcyB0byBiZSBhIHNsb3QgZm9yIGl0IGluIHRoZSBjb25maWcgZGF0 YXN0b3JlIGFuZCBpdCBzaG91bGQgSU1PIGJlCmZpbGxlZCB3aXRoIHRoZSBhdXRvY29uZmlndXJl ZCBhZGRyZXNzIHdoZW4gdGhlIGR5bmFtaWMgYXNzaWdubWVudCB0YWtlcwpwbGFjZS4KCkxhZGEK Cj4gCj4gSWYgdGhlIGxlYWYgaXMgImFzc2lnbmVkLWJ5IHN5c3RlbSIsIHRoZSBzeXN0ZW0gZmls bHMgaW4gYSB2YWx1cyBpbgo+IHRoZSBjb25maWd1cmF0aW9uLCBhbmQgZnJvbSB0aGVuIGl0IGJl aGF2ZXMganVzdCBhcyBpZiB0aGUgdXNlciBoYWQKPiBlbnRlcmVkIHRoaXMgdmFsdWUgZnJvbSB0 aGUgc3RhcnQuCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQ IEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Dec 3 01:29:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED313A68B1; Wed, 3 Dec 2008 01:29:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C59F3A6A35 for ; Wed, 3 Dec 2008 01:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 fPmbQWBt9OJp for ; Wed, 3 Dec 2008 01:29:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 113E33A68B1 for ; Wed, 3 Dec 2008 01:29:32 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AD44C0094; Wed, 3 Dec 2008 10:29:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sr7ep-A93pPf; Wed, 3 Dec 2008 10:29:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61737C008C; Wed, 3 Dec 2008 10:29:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 50B2C89C942; Wed, 3 Dec 2008 10:29:21 +0100 (CET) Date: Wed, 3 Dec 2008 10:29:21 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20081203092921.GB8656@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20081202.215612.124335277.mbj@tail-f.com> <1228293506.6315.25.camel@missotis> <20081203.094847.62858977.mbj@tail-f.com> <1228295933.6315.37.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1228295933.6315.37.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Dec 03, 2008 at 10:18:53AM +0100, Ladislav Lhotka wrote: > Do you mean that it becomes "config false" type of data in this > case? But the manager must also be able to set the address > manually, so there has to be a slot for it in the config datastore > and it should IMO be filled with the autoconfigured address when the > dynamic assignment takes place. An IP address assigned by DHCP is for me operational state, not configuration state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 01:38:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7960B28C11C; Wed, 3 Dec 2008 01:38:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0578628C0DC for ; Wed, 3 Dec 2008 01:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 rz5vkPL+feor for ; Wed, 3 Dec 2008 01:38:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3A6F828C0F5 for ; Wed, 3 Dec 2008 01:38:36 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 09A68D800C5; Wed, 3 Dec 2008 10:38:32 +0100 (CET) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081203092921.GB8656@elstar.local> References: <20081202.215612.124335277.mbj@tail-f.com> <1228293506.6315.25.camel@missotis> <20081203.094847.62858977.mbj@tail-f.com> <1228295933.6315.37.camel@missotis> <20081203092921.GB8656@elstar.local> Organization: CESNET Date: Wed, 03 Dec 2008 10:38:31 +0100 Message-Id: <1228297111.6315.57.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFN0IDAzLiAxMi4gMjAwOCB2IDEwOjI5ICsw MTAwOgo+IE9uIFdlZCwgRGVjIDAzLCAyMDA4IGF0IDEwOjE4OjUzQU0gKzAxMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiAgCj4gPiBEbyB5b3UgbWVhbiB0aGF0IGl0IGJlY29tZXMgImNvbmZp ZyBmYWxzZSIgdHlwZSBvZiBkYXRhIGluIHRoaXMKPiA+IGNhc2U/ICBCdXQgdGhlIG1hbmFnZXIg bXVzdCBhbHNvIGJlIGFibGUgdG8gc2V0IHRoZSBhZGRyZXNzCj4gPiBtYW51YWxseSwgc28gdGhl cmUgaGFzIHRvIGJlIGEgc2xvdCBmb3IgaXQgaW4gdGhlIGNvbmZpZyBkYXRhc3RvcmUKPiA+IGFu ZCBpdCBzaG91bGQgSU1PIGJlIGZpbGxlZCB3aXRoIHRoZSBhdXRvY29uZmlndXJlZCBhZGRyZXNz IHdoZW4gdGhlCj4gPiBkeW5hbWljIGFzc2lnbm1lbnQgdGFrZXMgcGxhY2UuCj4gCj4gQW4gSVAg YWRkcmVzcyBhc3NpZ25lZCBieSBESENQIGlzIGZvciBtZSBvcGVyYXRpb25hbCBzdGF0ZSwgbm90 Cj4gY29uZmlndXJhdGlvbiBzdGF0ZS4KClRoZSBtYW5hZ2VyIG11c3QgYWx3YXlzIGJlIGFibGUg dG8gbGVhcm4gaXQgKHZpYSBORVRDT05GLCBJIHByZXN1bWUpLApidXQgYWxzbyB0dXJuIG9mZiBE SENQIGFuZCBzZXQgaXQgbWFudWFsbHkuIFNvIEkgd29uZGVyIGhvdyB0aGUgZGF0YQptb2RlbCBj YW4gbG9vayBsaWtlIGluIG9yZGVyIHRvIGFjY29tb2RhdGUgYm90aCByZXF1aXJlbWVudHMuCgpM YWRhCgo+IAo+IC9qcwo+IAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDog RTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Dec 3 05:31:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C532E3A683B; Wed, 3 Dec 2008 05:31:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5A53A68C6 for ; Wed, 3 Dec 2008 05:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 aHxqCk3o4iUi for ; Wed, 3 Dec 2008 05:31:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 260973A683B for ; Wed, 3 Dec 2008 05:31:02 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EEBFE21436; Wed, 3 Dec 2008 14:30:56 +0100 (CET) X-AuditID: c1b4fb3e-ad783bb00000537b-5e-49368a10a1e4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D1039212B6; Wed, 3 Dec 2008 14:30:56 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 14:30:56 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 14:30:56 +0100 Message-ID: <49368A0F.3070105@ericsson.com> Date: Wed, 03 Dec 2008 14:30:55 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200811232056.mANKuNMW020600@idle.juniper.net> In-Reply-To: <200811232056.mANKuNMW020600@idle.juniper.net> X-OriginalArrivalTime: 03 Dec 2008 13:30:56.0641 (UTC) FILETIME=[5F4AB710:01C9554B] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I like Andy's idea. IMHO capabilities and features are too similar. Capabilities are modular: Nothing prevents me even today from having a capability that modifies the behavior of a single leaf element. If-capability is needed: E.g. the XPath capability should have been included in the data model both in the notifications RFC and the partial-locking draft. Vendors can easily define their own fine-grain capability Capabilities are dual-use already today. Advertising complete modules and advertising slight behavior changes (usually but not strictly protocol related). Balazs Phil Shafer wrote: > Andy Bierman writes: >> It is not clear at all in the YANG draft how NETCONF capabilities >> are managed. Actually, they are ignored completely and features >> are introduced instead. > > Capabilites are discuseed in the draft. There's a one-to-one mapping > between modules and capabilities. > > Features allow a more granular approach than capabilities. They > are a mechanism for introducing hiearchy into the mix. IMHO if > features were available during the NETCONF design, we would have > used them for many of the feature-like capabilties in NETCONF's > base operations. > >> IMO, there should be a global substitution: >> * s/feature/capability >> * s/if-feature/if-capability >> * remove special capability encoding, just use > > Wasn't this suggested (and rejected) previously? > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 07:29:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18C53A68C3; Wed, 3 Dec 2008 07:29:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6894C3A690B for ; Wed, 3 Dec 2008 07:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rpB1YfwrtMav for ; Wed, 3 Dec 2008 07:29:58 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id F174E3A68C3 for ; Wed, 3 Dec 2008 07:29:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSTal7VN0xbIPdNJ3A08eBwjgRv4N2lmR@postini.com; Wed, 03 Dec 2008 07:29:54 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 3 Dec 2008 07:26:03 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 07:26:03 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 07:26:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 07:26:03 -0800 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 mB3FQ2M79180; Wed, 3 Dec 2008 07:26:02 -0800 (PST) (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 mB3FKmJ4020272; Wed, 3 Dec 2008 15:20:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812031520.mB3FKmJ4020272@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <49368A0F.3070105@ericsson.com> Date: Wed, 3 Dec 2008 10:20:48 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Dec 2008 15:26:03.0221 (UTC) FILETIME=[73EF3050:01C9555B] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >Capabilities are dual-use already today. Advertising complete >modules and advertising slight behavior changes (usually but not >strictly protocol related). This is exactly the duality features address. Fine-grained control over the features in a module allows these features to be scoped inside the module. Consider your partial lock draft, which reuses the :xpath capability from 4741. If I support :xpath in the basic netconf operations, I cannot support partial locks without fully supporting it's xpath needs. If your module used a "feature xpath", the two could be supported independently. Also consider this was part of the requests from both of the early yang users (dns and ipfix). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 07:44:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D82A3A6893; Wed, 3 Dec 2008 07:44:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260F73A6822 for ; Wed, 3 Dec 2008 07:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 tFCgDgT5bfGF for ; Wed, 3 Dec 2008 07:44:32 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 20B413A680A for ; Wed, 3 Dec 2008 07:44:32 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A7CAB2079C; Wed, 3 Dec 2008 16:44:26 +0100 (CET) X-AuditID: c1b4fb3c-adf5ebb00000304c-79-4936a95a4e7b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C79920487; Wed, 3 Dec 2008 16:44:26 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 16:44:26 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 16:44:26 +0100 Message-ID: <4936A959.8070109@ericsson.com> Date: Wed, 03 Dec 2008 16:44:25 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200812031520.mB3FKmJ4020272@idle.juniper.net> In-Reply-To: <200812031520.mB3FKmJ4020272@idle.juniper.net> X-OriginalArrivalTime: 03 Dec 2008 15:44:26.0094 (UTC) FILETIME=[054C40E0:01C9555E] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Phil, Phil Shafer wrote: > Balazs Lengyel writes: >> Capabilities are dual-use already today. Advertising complete >> modules and advertising slight behavior changes (usually but not >> strictly protocol related). > > This is exactly the duality features address. Fine-grained > control over the features in a module allows these features > to be scoped inside the module. BALAZS: But capabilities are already dual use, and this wont change with adding features. > > Consider your partial lock draft, which reuses the :xpath > capability from 4741. If I support :xpath in the basic > netconf operations, I cannot support partial locks without > fully supporting it's xpath needs. If your module used a > "feature xpath", the two could be supported independently. BALAZS: I could do that with introducing a new xpath-for-partial-lock capability. It is not more difficult to handle, then introducing "feature xpath" in the partial lock module. (On the other hand I don't want to control XPath handling for partial locking separately. It would be confusing.) > > Also consider this was part of the requests from both of > the early yang users (dns and ipfix). > BALAZS: We could serve the needs of ipfix and dns with if-capability as well. We introduce a new concept "feature", with the following main differences: - inherently scoped to a module - is this good? needed? - using simpler QNames instead of the hierarchical URNs Is this worth the complication? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 08:55:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D6C3A6930; Wed, 3 Dec 2008 08:55:08 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0363A6886 for ; Wed, 3 Dec 2008 08:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.186, 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 XnwYuaLrrGXe for ; Wed, 3 Dec 2008 08:55:07 -0800 (PST) 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 403BC3A6930 for ; Wed, 3 Dec 2008 08:55:07 -0800 (PST) Received: (qmail 84465 invoked from network); 3 Dec 2008 16:55:03 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 3 Dec 2008 16:55:02 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4936B9E5.7010904@netconfcentral.com> Date: Wed, 03 Dec 2008 08:55:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Balazs Lengyel References: <200812031520.mB3FKmJ4020272@idle.juniper.net> <4936A959.8070109@ericsson.com> In-Reply-To: <4936A959.8070109@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello Phil, > Phil Shafer wrote: >> Balazs Lengyel writes: >>> Capabilities are dual-use already today. Advertising complete >>> modules and advertising slight behavior changes (usually but not >>> strictly protocol related). >> >> This is exactly the duality features address. Fine-grained >> control over the features in a module allows these features >> to be scoped inside the module. > > BALAZS: But capabilities are already dual use, and this wont change > with adding features. Capabilities already do everything that features do, except a feature is implicitly coupled to a namespace. One could easily encode the module as parameter in a regular capability URI like: http://example.com/feature-X?module=foo Instead of encoding the feature as a parameter of the module URI: http://example.com/module-foo?feature=X Protocol capabilities should be visible to the YANG DM designer but they are ignored instead. Features are not confined to a single module either. You can reference features in any module: leaf A { if-feature bar:Y; type string; } But to me the biggest issue with features is the notion that the features that will be supported will be supplied at YANG module compile-time. This is a seriously broken tools architecture. There are no #ifdefs in YANG. All the symbols are visible all the time in the YANG module. The if-feature and when conditionals are set by the agent implementation and the running configuration. A YANG module must be valid syntax regardless of the if-feature or when conditionals present. For example, a mandatory leaf inside the default case is still an error, whether there are if-feature-stmts in the case-stmt or not. >> >> Consider your partial lock draft, which reuses the :xpath >> capability from 4741. If I support :xpath in the basic >> netconf operations, I cannot support partial locks without >> fully supporting it's xpath needs. If your module used a >> "feature xpath", the two could be supported independently. > > BALAZS: I could do that with introducing a new xpath-for-partial-lock > capability. It is not more difficult to handle, then introducing > "feature xpath" in the partial lock module. (On the other hand I don't > want to control XPath handling for partial locking separately. It > would be confusing.) >> >> Also consider this was part of the requests from both of >> the early yang users (dns and ipfix). >> > > BALAZS: We could serve the needs of ipfix and dns with if-capability > as well. > > We introduce a new concept "feature", with the following main > differences: > - inherently scoped to a module - is this good? needed? > - using simpler QNames instead of the hierarchical URNs > > Is this worth the complication? > > Balazs > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 09:40:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829D83A6AD6; Wed, 3 Dec 2008 09:40:57 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EEE3A6B85 for ; Wed, 3 Dec 2008 09:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.149, 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 fRjfk5xcn9O1 for ; Wed, 3 Dec 2008 09:40:55 -0800 (PST) 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 E360F3A6AD6 for ; Wed, 3 Dec 2008 09:40:55 -0800 (PST) Received: (qmail 89738 invoked from network); 3 Dec 2008 17:40:51 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 3 Dec 2008 17:40:51 -0000 X-YMail-OSG: 8ev4xkIVM1lJlNAFxi_pxtwc3FsZH9rPQJuXH4ag28zvdwoNXwHZekMwGnBUr.ZJZVC2cq060CmI8IIKYYNBW7qeVU27Oj4Kre6iVG.9JIMEyggU1otlUOiX7GojPTJylfM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4936C4A2.2020101@netconfcentral.com> Date: Wed, 03 Dec 2008 09:40:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] if-feature details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, There needs to be some clarifications in the draft about some if-feature (and when-stmt) corner-cases. The set of conditionals must match or be a proper subset in some scenarios. That is the criteria -- not whether any conditionals exist at all or not. Some issues: - conditionals not matched for the default case with its parent choice - conditionals not matched for a key leaf and its parent list - conditionals not matched for a unique leaf and its parent list - conditionals in an augment node which are not also in the the augment target node These should be fatal errors because some combinations will generate illegal YANG schema. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 09:52:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C067628C0E9; Wed, 3 Dec 2008 09:52:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D1128C13E for ; Wed, 3 Dec 2008 09:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 CrI3bsvf5T1n for ; Wed, 3 Dec 2008 09:52:35 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 21C7428C0E9 for ; Wed, 3 Dec 2008 09:52:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSTbHXWhlYoSsQqU56yYNDiRjdeumEYqt@postini.com; Wed, 03 Dec 2008 09:52:31 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 3 Dec 2008 09:51:15 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 09:51:15 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 09:51:15 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 09:51:14 -0800 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 mB3HpEM47598; Wed, 3 Dec 2008 09:51:14 -0800 (PST) (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 mB3Hjx92021510; Wed, 3 Dec 2008 17:45:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812031745.mB3Hjx92021510@idle.juniper.net> To: Andy Bierman In-Reply-To: <4936B9E5.7010904@netconfcentral.com> Date: Wed, 3 Dec 2008 12:45:59 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Dec 2008 17:51:14.0866 (UTC) FILETIME=[BC7AB920:01C9556F] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >Balazs Lengyel wrote: >> BALAZS: But capabilities are already dual use, and this wont change >> with adding features. Hopefully it will. By providing a mechanism more tailored to the needs of the modelers, I expect to see this dual use of capabilities disappear. (IMHO If we had the feature mechanism during the original xmlconf/netconf design work, there would have been no dual use.) >Andy Bierman writes: >But to me the biggest issue with features is the notion that >the features that will be supported will be supplied >at YANG module compile-time. If I compile a YANG module for a box that does not support the "xpath" feature, the tools can trim this knowledge from the meta-data they put on the box. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 09:56:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319D13A67E4; Wed, 3 Dec 2008 09:56:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015C13A683F for ; Wed, 3 Dec 2008 09:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 iO-53Egp0awH for ; Wed, 3 Dec 2008 09:56:47 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 41DBE28C145 for ; Wed, 3 Dec 2008 09:56:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSTbIVCjwnMgrv4zmTYPVqKOdzEQMsCX5@postini.com; Wed, 03 Dec 2008 09:56:38 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 3 Dec 2008 09:54:28 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 09:54:27 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 09:54:27 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 09:54:27 -0800 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 mB3HsQM48892; Wed, 3 Dec 2008 09:54:26 -0800 (PST) (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 mB3HnBIA021558; Wed, 3 Dec 2008 17:49:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812031749.mB3HnBIA021558@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4936A959.8070109@ericsson.com> Date: Wed, 3 Dec 2008 12:49:11 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Dec 2008 17:54:27.0018 (UTC) FILETIME=[2F02CAA0:01C95570] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >BALAZS: I could do that with introducing a new xpath-for-partial-lock capability. It is >not >more difficult to handle, then introducing "feature xpath" in the partial lock module. ( >On the >other hand I don't want to control XPath handling for partial locking separately. It wou >ld be >confusing.) Confusing .vs. not implementable. In your current scheme, you force devices that do one to do both. I feel we're beating the same horse again. Do we need a concensus call to move forward? Didn't we already have (at least) one? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 10:05:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C14D3A683F; Wed, 3 Dec 2008 10:05:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB083A68D3 for ; Wed, 3 Dec 2008 10:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.124, 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 6hitvSBaAHQW for ; Wed, 3 Dec 2008 10:05:54 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 0C07F3A68B4 for ; Wed, 3 Dec 2008 10:05:54 -0800 (PST) Received: (qmail 32047 invoked from network); 3 Dec 2008 18:05:49 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 3 Dec 2008 18:05:47 -0000 X-YMail-OSG: EeCjMpoVM1mrWKbRkzAwQBFgXD65u0YuZaBXZgm8itA3Hr2csReo_N2wHBiQRSH8_34u4q0.WE9p6CA6qR31nu4xKt230MVDIxjFdcqgXR3p6q_LqKML6hUUojt2RZH_c4k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4936CA7A.8060105@netconfcentral.com> Date: Wed, 03 Dec 2008 10:05:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812031749.mB3HnBIA021558@idle.juniper.net> In-Reply-To: <200812031749.mB3HnBIA021558@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Balazs Lengyel writes: > >> BALAZS: I could do that with introducing a new xpath-for-partial-lock capability. It is >> not >> more difficult to handle, then introducing "feature xpath" in the partial lock module. ( >> On the >> other hand I don't want to control XPath handling for partial locking separately. It wou >> ld be >> confusing.) >> > > Confusing .vs. not implementable. In your current scheme, you > force devices that do one to do both. > > I feel we're beating the same horse again. Do we need a concensus > call to move forward? Didn't we already have (at least) one? > > I support Phil on this one. We do not want to force vendors to remove their :xpath advertisement for their compliant 4741 implementations, because they choose to implement :partial-lock but cannot adhere to all the bells and whistles that the partial lock draft adds to the :xpath capability. To be more clear: A new capability MUST NOT add any requirements to an existing capability. This rule is being violated by the partial-lock draft. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 11:05:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE45B3A6958; Wed, 3 Dec 2008 11:05:32 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062793A69EC for ; Wed, 3 Dec 2008 11:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 it+d3ML244y5 for ; Wed, 3 Dec 2008 11:05:31 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id D8E2D3A69E2 for ; Wed, 3 Dec 2008 11:05:30 -0800 (PST) X-Trace: 58254883/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.91 X-SBRS: None X-RemoteIP: 62.188.105.91 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEALRmNkk+vGlb/2dsb2JhbACDRCUUiRzGFgeCeA X-IronPort-AV: E=Sophos;i="4.33,709,1220223600"; d="scan'208";a="58254883" X-IP-Direction: IN Received: from 1cust91.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.91]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Dec 2008 19:05:23 +0000 Message-ID: <000201c95571$cc5d45e0$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <20081202.215612.124335277.mbj@tail-f.com> Date: Wed, 3 Dec 2008 18:41:06 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Martin Bjorklund" To: Sent: Tuesday, December 02, 2008 9:56 PM Subject: [netmod] assigned-by > We have been talking several times about adding a statement > "assigned-by system" to the "leaf" statement. I believe that the > chairs will send out a call for consenus to the list. > > The idea is that if a leaf is marked as assigned-by system, then the > client MAY choose to not set a value for the leaf when its parent > instance is created. In this case the system will assign a suitable > value for the leaf. > > In Minneapolis the question was raised how this interacts with > 'mandatory' and 'default', and also if the server MUST or MAY assign a > value. And in previous discussions on this list, how it would interact with 'config'. When you have drawn up 8-way charts and tried to assign meanings to the different combinations, the message I got was that this is a nonsense. You say below that mandatory means it MUST exist and must not have a default. Why? seems like a nonsense to me. It must exist and if no value is written, here is a default instead. And Juergen's post, that a DHCP assigned value was not config (but if I wrote in the value I imagine he would agree that it was config) again says to me this is a nonsense. I do not know what you are trying to achieve with this metadata, config/mandatory/assigned by/default, but it just seems confused, ill-thought out, creating confusion where none need exist. I would scrap the lot until I saw a good case for anything in this area. And I do see this, the interactions of this metadata, as a significant issue whose resolution is long overdue. Tom Petch > Since we already have 'mandatory' which means that a leaf MUST exist > in a valid data store, it makes sense to use it also for this purpose: > > leaf foo { > type string; > mandatory true; > assigned-by system; > } > > leaf bar { > type string; > assigned-by system; > } > > With these definitions, if the client does not assign a value to > "foo", the server MUST assign a value, but if the client does not set > "bar", the server MAY assign a value. > > I'm a bit worried that this interpretation is not ... obvious. > > An alternative could be to go with one (MUST or MAY), and say that > "assigned-by system" and "mandatory true" must not be used at the same > time, but that might be too restrictive, and it adds a CLR. > > As for 'default' and assigned-by system, with the interpretation > above, we could stick with the rules we have. I.e. a 'default' > statement on "foo" would not be allowed (since "foo" is mandatory), > but it would be allowed in "bar" - if "bar" is not set by either the > client or server, the default value is used internally. > > /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 11:49:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9123A6820; Wed, 3 Dec 2008 11:49:32 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64523A6892 for ; Wed, 3 Dec 2008 11:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 E7+K55+PYt4c for ; Wed, 3 Dec 2008 11:49:31 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 95A1C3A6820 for ; Wed, 3 Dec 2008 11:49:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSTbiwZAsQk3klPJ/hvC1r5SjsWQ+SMPB@postini.com; Wed, 03 Dec 2008 11:49:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 3 Dec 2008 11:48:26 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 11:48:26 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 11:48:26 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 11:48:25 -0800 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 mB3JmOM04813; Wed, 3 Dec 2008 11:48:25 -0800 (PST) (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 mB3JhAQV022414; Wed, 3 Dec 2008 19:43:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812031943.mB3JhAQV022414@idle.juniper.net> To: "tom.petch" In-Reply-To: <000201c95571$cc5d45e0$0601a8c0@allison> Date: Wed, 3 Dec 2008 14:43:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 03 Dec 2008 19:48:25.0684 (UTC) FILETIME=[1B2C6940:01C95580] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "tom.petch" writes: >You say >below that mandatory means it MUST exist and must not have a default. Why? >seems like a nonsense to me. It must exist and if no value is written, here is >a default instead. View the module as a contract between client and server, and these properties as terms of that contract. "mandatory true" means the client must make this leaf. "default" means if the client does not make the leaf, there is a value that the server will automatically use. These are mutually exclusive. If you have to make it, there's not point in saying what happens if you don't. >And Juergen's post, that a DHCP assigned value was not config (but if I wrote in >the value I imagine he would agree that it was config) again says to me this is >a nonsense. This example strengthens my view that config and operational data are very different things. The SNMP view of mixing them into a simple hierarchy misses this (and other) cases. Joining config data with non-config data makes modeling harder than it needs to be. >I do not know what you are trying to achieve with this metadata, >config/mandatory/assigned by/default, but it just seems confused, ill-thought >out, creating confusion where none need exist. I would scrap the lot until I >saw a good case for anything in this area. IMHO there are many existing use cases for the config, mandatory, and default properties. We use them (the JUNOS equivalents) every day. In all of JUNOS there is exactly one case where we would use assigned-by (if we have it). This is the case of assigning a uid to a user, which needs to persist in future instantiations of a particular user, but which we don't want to burden the CLI user with the assignment of. When you create a user, the next free/unused uid is automatically assigned to the "uid" leaf. We also match the uid for the user if that user currently exists. Given the small need for assigned-by, I'd happily postpone it as future work (y2:assigned-by ;^). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 12:16:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6DE3A696D; Wed, 3 Dec 2008 12:16:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98BB3A6892 for ; Wed, 3 Dec 2008 12:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.106, 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 N2gDEfPrwksE for ; Wed, 3 Dec 2008 12:16:50 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 618B428C173 for ; Wed, 3 Dec 2008 12:16:32 -0800 (PST) Received: (qmail 16141 invoked from network); 3 Dec 2008 20:16:27 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 3 Dec 2008 20:16:27 -0000 X-YMail-OSG: c8vfPUMVM1lf2s6t30RYraatynnyWY7zfIq82PgoMtc5BBv2DQ08R7XZPc1CapAYIK_jsmp00KlgtEVGWSjiLiCcKaPh1gbHqMNF6lRbyIv03b_TNHgrK_uWtJDyQ2B5SRs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4936E91A.6000104@netconfcentral.com> Date: Wed, 03 Dec 2008 12:16:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812031943.mB3JhAQV022414@idle.juniper.net> In-Reply-To: <200812031943.mB3JhAQV022414@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > .... > This example strengthens my view that config and operational > data are very different things. The SNMP view of mixing them > into a simple hierarchy misses this (and other) cases. Joining > config data with non-config data makes modeling harder than it > needs to be. > > .... > amen! mixing config leafs and non-config nodes is a bad SNMP habit that NETMOD should not embrace. (IMO, a node with min-access=read-only is a different problem). > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 14:03:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192763A69CC; Wed, 3 Dec 2008 14:03:35 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5583F3A6A3C for ; Wed, 3 Dec 2008 14:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, 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 J1Z0WtSUadFu for ; Wed, 3 Dec 2008 14:03:33 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id AB8CC3A69CC for ; Wed, 3 Dec 2008 14:03:33 -0800 (PST) Received: (qmail 41780 invoked from network); 3 Dec 2008 22:03:28 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 3 Dec 2008 22:03:28 -0000 X-YMail-OSG: dO46odwVM1mVR9egOubTe6YY3ntCXnm7G24oEFpnAlbqEJdBlbAdbfl62FGpIPUU0Xzfm7V8NyZfMv41pRfgotePXjXYPjojOXuACcuMqghPQTY5H.4Pp5wmPMfeEgwz..M- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4937022F.8070908@netconfcentral.com> Date: Wed, 03 Dec 2008 14:03:27 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Here is another way to solve the capabilities vs. features problems, using (mostly) existing mechanisms. It also solves one of the problems with if-feature in XPath. Proposal: Add 2 functions to the YANG XPath context: boolean capability (QName); Returns 'true' if the capability identified by the QName string parameter is enabled. False if capability is unknown or not enabled. Protocol capabilities are identified by the prefix for the NETCONF base namespace and the name of the capability. Vendor capabilities must use a different namespace. boolean feature (QName); Returns 'true' if the feature identified by the QName string parameter is enabled. False if feature is unknown or not enabled. E.g.: when "capability('nc:candidate') and feature('acme:candidate-extensions')"; when "capability('nc:partial-lock') and feature('pl:xpath')"; I know feature('foo') is the same thing as 'if-feature foo', but it serves a purpose in XPath. You are not supposed to continue AND expression evaluation once you hit a false result (just like C). E.g., a a leaf augmenting the edit-config/input node: leaf my-test-mode { when "capability('nc:rollback-on-error') and ../test-option='test-then-set'"; type enumeration { ... } } The feature() function allows when expressions to be platform independent, and test conditional nodes only if the feature is first enabled. The capability() function allows access to protocol and vendor capabilities in conditional schema nodes, without getting rid of features or adding a YANG capability-stmt and if-capability. E.g., a leaf augmenting the commit/input node: leaf my-rollback-options { when "capability('nc:confirmed-commit')"; type bits { ... } } Both functions together provide a DM designer with complete control over the NETCONF environment, and XPath provides for much more powerful expressions than if-feature alone. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 18:05:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B69B3A65A5; Wed, 3 Dec 2008 18:05:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA90A3A677D for ; Wed, 3 Dec 2008 18:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 9z3wM50gHj0a for ; Wed, 3 Dec 2008 18:05:40 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id D7CA73A65A5 for ; Wed, 3 Dec 2008 18:05:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSTc67XXeyAgLiHaxNUh1DSERvt9aPdlz@postini.com; Wed, 03 Dec 2008 18:05:36 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 3 Dec 2008 18:01:43 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 18:01:43 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 18:01:43 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 18:01:42 -0800 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 mB421gM92089; Wed, 3 Dec 2008 18:01:42 -0800 (PST) (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 mB41uPTf024908; Thu, 4 Dec 2008 01:56:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812040156.mB41uPTf024908@idle.juniper.net> To: Andy Bierman In-Reply-To: <4937022F.8070908@netconfcentral.com> Date: Wed, 3 Dec 2008 20:56:25 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2008 02:01:42.0993 (UTC) FILETIME=[41028C10:01C955B4] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: > boolean capability (QName); > boolean feature (QName); This would move features from a first class language construct to a second (or third?) class one. By using an explicit YANG statement, we allow tools visibility into features without parsing XPath strings. This allows features to be handled directly without waiting til runtime to evaluate "when" expressions. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 19:01:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4723F3A6407; Wed, 3 Dec 2008 19:01:04 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F77C3A65A5 for ; Wed, 3 Dec 2008 19:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, 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 9k5j0C4CXUFl for ; Wed, 3 Dec 2008 19:01:02 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 9C6813A6407 for ; Wed, 3 Dec 2008 19:01:02 -0800 (PST) Received: (qmail 46108 invoked from network); 4 Dec 2008 03:00:58 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2008 03:00:57 -0000 X-YMail-OSG: ExgRYd0VM1neEpunpCIHXNLKaVHEdrxOZyjg2XeRE_IrNuz8vUX5VIbH9YxobhuO.NgONSXgswEIMX4_MZl14yVUSH6_X3QkVsqO07KlKMlt1FWOHlm5ENMXVmJxt22ER8s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493747E9.6070801@netconfcentral.com> Date: Wed, 03 Dec 2008 19:00:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812040156.mB41uPTf024908@idle.juniper.net> In-Reply-To: <200812040156.mB41uPTf024908@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >> boolean capability (QName); >> boolean feature (QName); >> > > This would move features from a first class language construct to > a second (or third?) class one. By using an explicit YANG statement, > we allow tools visibility into features without parsing XPath > strings. This allows features to be handled directly without waiting > til runtime to evaluate "when" expressions. > > I think XPath is a big part of YANG, and not 3rd order. The DM writer can choose not to use the feature() function. There is no option available for the capability() function except define features for all the protocol capabilities. XPath can prevent the definition of artificial features: leaf default-storage { description "Defines the default storage location if the local-storage feature is not supported."; when "not(feature('local-storage'))"; type "yang:uri"; } IMO, this is better than defining a feature called 'not-local-storage'. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 3 19:36:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28E03A6808; Wed, 3 Dec 2008 19:36:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135563A689C for ; Wed, 3 Dec 2008 19:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 aUji4fDQm6zJ for ; Wed, 3 Dec 2008 19:36:16 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 61FD03A6808 for ; Wed, 3 Dec 2008 19:36:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSTdQK7/YM9/+lkp5YfYANzgwWZA8ewms@postini.com; Wed, 03 Dec 2008 19:36:12 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 3 Dec 2008 19:33:20 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 19:33:20 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 19:33:20 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 19:33:20 -0800 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 mB43XJM24585; Wed, 3 Dec 2008 19:33:19 -0800 (PST) (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 mB43S2Q7025731; Thu, 4 Dec 2008 03:28:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812040328.mB43S2Q7025731@idle.juniper.net> To: Andy Bierman In-Reply-To: <493747E9.6070801@netconfcentral.com> Date: Wed, 3 Dec 2008 22:28:02 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2008 03:33:20.0295 (UTC) FILETIME=[0DA84370:01C955C1] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: > when "not(feature('local-storage'))"; Consider the "when" expression: when "pigs > fly && feature('local')"; To know if this applies, I need to either (a) evaluate it (using a XPath library), (b) break it apart (using an XPath parser), or (c) "know" via human inspection. (a) is how most implementations will process XPath expressions unless they are hard-coding for their particular device, in which case (c) will be used. But in many cases, I'd like to know at build time whether I need to carry information about schema nodes on to my products. If the product doesn't support 'local', I never need to ship that part of the compiled YANG modules onto that device. Making "if-feature" an explicit, first class YANG statement allows me to do this. Putting this into "when" means I'll need to do (b) and some additional heavy lifting. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 00:52:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0F73A69C9; Thu, 4 Dec 2008 00:52:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB313A69C3 for ; Thu, 4 Dec 2008 00:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 lBi8HVxhoPCw for ; Thu, 4 Dec 2008 00:52:34 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 23A3D3A63CB for ; Thu, 4 Dec 2008 00:52:34 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E3DC76C30E; Thu, 4 Dec 2008 09:52:29 +0100 (CET) Date: Thu, 04 Dec 2008 09:52:27 +0100 (CET) Message-Id: <20081204.095227.75091888.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4936B9E5.7010904@netconfcentral.com> References: <200812031520.mB3FKmJ4020272@idle.juniper.net> <4936A959.8070109@ericsson.com> <4936B9E5.7010904@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > But to me the biggest issue with features is the notion that > the features that will be supported will be supplied > at YANG module compile-time. > This is a seriously broken tools architecture. There's nothing in the draft that says when an implementation chooses to enforce its features. This is an implementation issue. One implementation might to it dynamically in run time, and another can do it when it generates code from the model (i.e. it can choose to not generate code for the unsupported features). > A YANG module must be valid syntax > regardless of the if-feature or when conditionals present. Absolutely! /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 01:25:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD573A67F4; Thu, 4 Dec 2008 01:25:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7663A6893 for ; Thu, 4 Dec 2008 01:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 wcHLIwlJltep for ; Thu, 4 Dec 2008 01:25:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1FD2C3A67F4 for ; Thu, 4 Dec 2008 01:25:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D02F976C30E; Thu, 4 Dec 2008 10:24:57 +0100 (CET) Date: Thu, 04 Dec 2008 10:24:55 +0100 (CET) Message-Id: <20081204.102455.214236411.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4936CA7A.8060105@netconfcentral.com> References: <200812031749.mB3HnBIA021558@idle.juniper.net> <4936CA7A.8060105@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I moved the part of the thread that discussed :partial-lock and :xpath to the netconf ML. But read on. Andy Bierman wrote: > A new capability MUST NOT add any requirements to an existing capability. > This rule is being violated by the partial-lock draft. If this is the case, then you're suggestion to introduce a 'if-capability' statement will not work, since if you use e.g. leaf select { if-capability ":xpath"; ... } you really add a requirement to an existing capability. Continuing this logic, we should do the same for feature, and not allow a feature to be exported/imported from another module, as was suggested by Andy earlier. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 01:41:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE99D3A63CB; Thu, 4 Dec 2008 01:41:47 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1913A68D2 for ; Thu, 4 Dec 2008 01:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 N+KTW9OEfNeC for ; Thu, 4 Dec 2008 01:41:45 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1AC273A69D4 for ; Thu, 4 Dec 2008 01:41:18 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D6C9576C30E; Thu, 4 Dec 2008 10:41:12 +0100 (CET) Date: Thu, 04 Dec 2008 10:41:10 +0100 (CET) Message-Id: <20081204.104110.129525820.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200812031943.mB3JhAQV022414@idle.juniper.net> References: <000201c95571$cc5d45e0$0601a8c0@allison> <200812031943.mB3JhAQV022414@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > >I do not know what you are trying to achieve with this metadata, > >config/mandatory/assigned by/default, but it just seems confused, ill-thought > >out, creating confusion where none need exist. I would scrap the lot until I > >saw a good case for anything in this area. > > IMHO there are many existing use cases for the config, mandatory, > and default properties. We use them (the JUNOS equivalents) every > day. Same here. We use them and our customers use them all the time. IMO they are absolutely essential. Just as one example, how would anyone know what's possible to send in an edit-config if we simply removed the 'config' statement? > In all of JUNOS there is exactly one case where we would use > assigned-by (if we have it). The ipfix YANG module has 5 objects which would use it if we had it. Currently they use the description clause: leaf observationPointId { description "If omitted, the Observation Point ID is assigned by the monitoring device."; type uint32; } > Given the small need for assigned-by, I'd happily postpone it > as future work (y2:assigned-by ;^). I can live with postponing this as well. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 01:51:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115853A67F4; Thu, 4 Dec 2008 01:51:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995D53A67F4 for ; Thu, 4 Dec 2008 01:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 pV7-88Hwo55x for ; Thu, 4 Dec 2008 01:51:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 71B853A683A for ; Thu, 4 Dec 2008 01:51:39 -0800 (PST) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 7B305D800C8; Thu, 4 Dec 2008 10:51:34 +0100 (CET) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <000201c95571$cc5d45e0$0601a8c0@allison> References: <20081202.215612.124335277.mbj@tail-f.com> <000201c95571$cc5d45e0$0601a8c0@allison> Organization: CESNET Date: Thu, 04 Dec 2008 10:51:33 +0100 Message-Id: <1228384294.6440.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org dG9tLnBldGNoIHDDrcWhZSB2IFN0IDAzLiAxMi4gMjAwOCB2IDE4OjQxICswMTAwOgo+IC0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0 YWlsLWYuY29tPgo+IFRvOiA8bmV0bW9kQGlldGYub3JnPgo+IFNlbnQ6IFR1ZXNkYXksIERlY2Vt YmVyIDAyLCAyMDA4IDk6NTYgUE0KPiBTdWJqZWN0OiBbbmV0bW9kXSBhc3NpZ25lZC1ieQo+IAo+ IAo+ID4gV2UgaGF2ZSBiZWVuIHRhbGtpbmcgc2V2ZXJhbCB0aW1lcyBhYm91dCBhZGRpbmcgYSBz dGF0ZW1lbnQKPiA+ICJhc3NpZ25lZC1ieSBzeXN0ZW0iIHRvIHRoZSAibGVhZiIgc3RhdGVtZW50 LiAgSSBiZWxpZXZlIHRoYXQgdGhlCj4gPiBjaGFpcnMgd2lsbCBzZW5kIG91dCBhIGNhbGwgZm9y IGNvbnNlbnVzIHRvIHRoZSBsaXN0Lgo+ID4KPiA+IFRoZSBpZGVhIGlzIHRoYXQgaWYgYSBsZWFm IGlzIG1hcmtlZCBhcyBhc3NpZ25lZC1ieSBzeXN0ZW0sIHRoZW4gdGhlCj4gPiBjbGllbnQgTUFZ IGNob29zZSB0byBub3Qgc2V0IGEgdmFsdWUgZm9yIHRoZSBsZWFmIHdoZW4gaXRzIHBhcmVudAo+ ID4gaW5zdGFuY2UgaXMgY3JlYXRlZC4gIEluIHRoaXMgY2FzZSB0aGUgc3lzdGVtIHdpbGwgYXNz aWduIGEgc3VpdGFibGUKPiA+IHZhbHVlIGZvciB0aGUgbGVhZi4KPiA+Cj4gPiBJbiBNaW5uZWFw b2xpcyB0aGUgcXVlc3Rpb24gd2FzIHJhaXNlZCBob3cgdGhpcyBpbnRlcmFjdHMgd2l0aAo+ID4g J21hbmRhdG9yeScgYW5kICdkZWZhdWx0JywgYW5kIGFsc28gaWYgdGhlIHNlcnZlciBNVVNUIG9y IE1BWSBhc3NpZ24gYQo+ID4gdmFsdWUuCj4gCj4gQW5kIGluIHByZXZpb3VzIGRpc2N1c3Npb25z IG9uIHRoaXMgbGlzdCwgaG93IGl0IHdvdWxkIGludGVyYWN0IHdpdGggJ2NvbmZpZycuCj4gV2hl biB5b3UgaGF2ZSBkcmF3biB1cCA4LXdheSBjaGFydHMgYW5kIHRyaWVkIHRvIGFzc2lnbiBtZWFu aW5ncyB0byB0aGUKPiBkaWZmZXJlbnQgY29tYmluYXRpb25zLCB0aGUgbWVzc2FnZSBJIGdvdCB3 YXMgdGhhdCB0aGlzIGlzIGEgbm9uc2Vuc2UuICBZb3Ugc2F5Cj4gYmVsb3cgdGhhdCBtYW5kYXRv cnkgbWVhbnMgaXQgTVVTVCBleGlzdCBhbmQgbXVzdCBub3QgaGF2ZSBhIGRlZmF1bHQuICBXaHk/ Cj4gc2VlbXMgbGlrZSBhIG5vbnNlbnNlIHRvIG1lLiAgSXQgbXVzdCBleGlzdCBhbmQgaWYgbm8g dmFsdWUgaXMgd3JpdHRlbiwgaGVyZSBpcwo+IGEgZGVmYXVsdCBpbnN0ZWFkLgo+IAo+IEFuZCBK dWVyZ2VuJ3MgcG9zdCwgdGhhdCBhIERIQ1AgYXNzaWduZWQgdmFsdWUgd2FzIG5vdCBjb25maWcg KGJ1dCBpZiBJIHdyb3RlIGluCj4gdGhlIHZhbHVlIEkgaW1hZ2luZSBoZSB3b3VsZCBhZ3JlZSB0 aGF0IGl0IHdhcyBjb25maWcpIGFnYWluIHNheXMgdG8gbWUgdGhpcyBpcwo+IGEgbm9uc2Vuc2Uu Cj4gCj4gSSBkbyBub3Qga25vdyB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGFjaGlldmUgd2l0aCB0 aGlzIG1ldGFkYXRhLAo+IGNvbmZpZy9tYW5kYXRvcnkvYXNzaWduZWQgYnkvZGVmYXVsdCwgYnV0 IGl0IGp1c3Qgc2VlbXMgY29uZnVzZWQsIGlsbC10aG91Z2h0Cj4gb3V0LCBjcmVhdGluZyBjb25m dXNpb24gd2hlcmUgbm9uZSBuZWVkIGV4aXN0LiAgSSB3b3VsZCBzY3JhcCB0aGUgbG90IHVudGls IEkKPiBzYXcgYSBnb29kIGNhc2UgZm9yIGFueXRoaW5nIGluIHRoaXMgYXJlYS4KPiAKPiBBbmQg SSBkbyBzZWUgdGhpcywgdGhlIGludGVyYWN0aW9ucyBvZiB0aGlzIG1ldGFkYXRhLCBhcyBhIHNp Z25pZmljYW50IGlzc3VlCj4gd2hvc2UgcmVzb2x1dGlvbiBpcyBsb25nIG92ZXJkdWUuCgpJIGZ1 bGx5IGFncmVlIHdpdGggeW91ciB2aWV3LiBUaGVyZSBhcmUgbWFueSBjYXNlcyB3aGVuIHRoZSBz YW1lCmNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIG1heSBiZSwgZGVwZW5kaW5nIG9uIGNpcmN1bXN0 YW5jZXMsIGV4cGxpY2l0bHkKY29uZmlndXJlZCwgb3Igc3VwcGxpZWQgZnJvbSBkYXRhIG1vZGVs IGRlZmF1bHQsIHZlbmRvciBkZWZhdWx0IG9yCm5ldHdvcmsgcHJvdG9jb2wuCgpHaXZlbiB0aGF0 IHdlIGRvbid0IGV2ZW4gYWdyZWUgb24gd2hhdCBhIGNvbmZpZ3VyYXRpb24gY29udGFpbnMgKGFy ZSB0aGUKdmFsdWVzIHRoYXQgaGF2ZW4ndCBiZWVuIGV4cGxpY2l0bHkgc2V0IGJ5IHRoZSBtYW5h Z2VyIHRoZXJlIG9yIG5vdD8pLCBJCnRoaW5rIGl0IGlzIGhvcGVsZXNzIHRvIHRyeSB0byBkaXN0 aW5ndWlzaCBhbGwgdGhlc2UgY2FzZXMgaW4gdGhlIERNTC4KCkxhZGEKCj4gCj4gVG9tIFBldGNo Cj4gCj4gCj4gPiBTaW5jZSB3ZSBhbHJlYWR5IGhhdmUgJ21hbmRhdG9yeScgd2hpY2ggbWVhbnMg dGhhdCBhIGxlYWYgTVVTVCBleGlzdAo+ID4gaW4gYSB2YWxpZCBkYXRhIHN0b3JlLCBpdCBtYWtl cyBzZW5zZSB0byB1c2UgaXQgYWxzbyBmb3IgdGhpcyBwdXJwb3NlOgo+ID4KPiA+ICAgbGVhZiBm b28gewo+ID4gICAgICAgdHlwZSBzdHJpbmc7Cj4gPiAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKPiA+ ICAgICAgIGFzc2lnbmVkLWJ5IHN5c3RlbTsKPiA+ICAgfQo+ID4KPiA+ICAgbGVhZiBiYXIgewo+ ID4gICAgICAgdHlwZSBzdHJpbmc7Cj4gPiAgICAgICBhc3NpZ25lZC1ieSBzeXN0ZW07Cj4gPiAg IH0KPiA+Cj4gPiBXaXRoIHRoZXNlIGRlZmluaXRpb25zLCBpZiB0aGUgY2xpZW50IGRvZXMgbm90 IGFzc2lnbiBhIHZhbHVlIHRvCj4gPiAiZm9vIiwgdGhlIHNlcnZlciBNVVNUIGFzc2lnbiBhIHZh bHVlLCBidXQgaWYgdGhlIGNsaWVudCBkb2VzIG5vdCBzZXQKPiA+ICJiYXIiLCB0aGUgc2VydmVy IE1BWSBhc3NpZ24gYSB2YWx1ZS4KPiA+Cj4gPiBJJ20gYSBiaXQgd29ycmllZCB0aGF0IHRoaXMg aW50ZXJwcmV0YXRpb24gaXMgbm90IC4uLiBvYnZpb3VzLgo+ID4KPiA+IEFuIGFsdGVybmF0aXZl IGNvdWxkIGJlIHRvIGdvIHdpdGggb25lIChNVVNUIG9yIE1BWSksIGFuZCBzYXkgdGhhdAo+ID4g ImFzc2lnbmVkLWJ5IHN5c3RlbSIgYW5kICJtYW5kYXRvcnkgdHJ1ZSIgbXVzdCBub3QgYmUgdXNl ZCBhdCB0aGUgc2FtZQo+ID4gdGltZSwgYnV0IHRoYXQgbWlnaHQgYmUgdG9vIHJlc3RyaWN0aXZl LCBhbmQgaXQgYWRkcyBhIENMUi4KPiA+Cj4gPiBBcyBmb3IgJ2RlZmF1bHQnIGFuZCBhc3NpZ25l ZC1ieSBzeXN0ZW0sIHdpdGggdGhlIGludGVycHJldGF0aW9uCj4gPiBhYm92ZSwgd2UgY291bGQg c3RpY2sgd2l0aCB0aGUgcnVsZXMgd2UgaGF2ZS4gIEkuZS4gYSAnZGVmYXVsdCcKPiA+IHN0YXRl bWVudCBvbiAiZm9vIiB3b3VsZCBub3QgYmUgYWxsb3dlZCAoc2luY2UgImZvbyIgaXMgbWFuZGF0 b3J5KSwKPiA+IGJ1dCBpdCB3b3VsZCBiZSBhbGxvd2VkIGluICJiYXIiIC0gaWYgImJhciIgaXMg bm90IHNldCBieSBlaXRoZXIgdGhlCj4gPiBjbGllbnQgb3Igc2VydmVyLCB0aGUgZGVmYXVsdCB2 YWx1ZSBpcyB1c2VkIGludGVybmFsbHkuCj4gPgo+ID4gL21hcnRpbgo+IAo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlz dAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMw QwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9k IG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Dec 4 01:57:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4139A3A68C1; Thu, 4 Dec 2008 01:57:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456F53A6851 for ; Thu, 4 Dec 2008 01:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 BuFFLpHKCUo9 for ; Thu, 4 Dec 2008 01:57:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 750543A6885 for ; Thu, 4 Dec 2008 01:57:30 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C59C776C30E; Thu, 4 Dec 2008 10:57:25 +0100 (CET) Date: Thu, 04 Dec 2008 10:57:23 +0100 (CET) Message-Id: <20081204.105723.94620406.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200812040328.mB43S2Q7025731@idle.juniper.net> References: <493747E9.6070801@netconfcentral.com> <200812040328.mB43S2Q7025731@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > > when "not(feature('local-storage'))"; > > Consider the "when" expression: > > when "pigs > fly && feature('local')"; > > To know if this applies, I need to either > (a) evaluate it (using a XPath library), > (b) break it apart (using an XPath parser), or > (c) "know" via human inspection. > > (a) is how most implementations will process XPath expressions > unless they are hard-coding for their particular device, in > which case (c) will be used. > > But in many cases, I'd like to know at build time whether I > need to carry information about schema nodes on to my products. > If the product doesn't support 'local', I never need to ship > that part of the compiled YANG modules onto that device. > > Making "if-feature" an explicit, first class YANG statement > allows me to do this. Putting this into "when" means I'll > need to do (b) and some additional heavy lifting. I agree with this, and can add that moving this function into 'when' fundamentally changes what a when expression is. Currently, the 'when' expression can only reference data in the data tree. So given the expression and the entire data tree, the when expression evaluates to the same value regardless of the device type. By adding 'feature' and/or 'capability' functions, this would no longer be true. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 02:03:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2483A6832; Thu, 4 Dec 2008 02:03:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E70C3A68C2 for ; Thu, 4 Dec 2008 02:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 4Va43LdDIk-f for ; Thu, 4 Dec 2008 02:03:06 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 53DED3A683A for ; Thu, 4 Dec 2008 02:03:06 -0800 (PST) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 36521D800CC; Thu, 4 Dec 2008 11:03:02 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4936E91A.6000104@netconfcentral.com> References: <200812031943.mB3JhAQV022414@idle.juniper.net> <4936E91A.6000104@netconfcentral.com> Organization: CESNET Date: Thu, 04 Dec 2008 11:03:01 +0100 Message-Id: <1228384981.6440.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDAzLiAxMi4gMjAwOCB2IDEyOjE2IC0wODAwOgo+IFBo aWwgU2hhZmVyIHdyb3RlOgo+ID4gLi4uLgo+ID4gVGhpcyBleGFtcGxlIHN0cmVuZ3RoZW5zIG15 IHZpZXcgdGhhdCBjb25maWcgYW5kIG9wZXJhdGlvbmFsCj4gPiBkYXRhIGFyZSB2ZXJ5IGRpZmZl cmVudCB0aGluZ3MuICBUaGUgU05NUCB2aWV3IG9mIG1peGluZyB0aGVtCj4gPiBpbnRvIGEgc2lt cGxlIGhpZXJhcmNoeSBtaXNzZXMgdGhpcyAoYW5kIG90aGVyKSBjYXNlcy4gIEpvaW5pbmcKPiA+ IGNvbmZpZyBkYXRhIHdpdGggbm9uLWNvbmZpZyBkYXRhIG1ha2VzIG1vZGVsaW5nIGhhcmRlciB0 aGFuIGl0Cj4gPiBuZWVkcyB0byBiZS4KPiA+Cj4gPiAuLi4uCj4gPiAgIAo+IAo+IAo+IGFtZW4h Cj4gCj4gbWl4aW5nIGNvbmZpZyBsZWFmcyBhbmQgbm9uLWNvbmZpZyBub2RlcyBpcyBhIGJhZCBT Tk1QIGhhYml0Cj4gdGhhdCBORVRNT0Qgc2hvdWxkIG5vdCBlbWJyYWNlLgoKU28gc2hvdWxkIGFu IElQdjYgYWRkcmVzcyBvbiBhbiBpbnRlcmZhY2UgYmUgbW9kZWxlZCBhcyBjb25maWcgb3IKbm9u LWNvbmZpZyAob3BlcmF0aW9uYWwgcGFyYW1ldGVyKT8gU2hvdWxkIGl0IGRlcGVuZCBlLmcuLCBv biB3aGV0aGVyIGFuCmFkamFjZW50IHJvdXRlciBzZW5kcyByb3V0ZXIgYWR2ZXJ0aXNlbWVudHM/ IFNob3VsZCBhIGxpbmstbG9jYWwgYWRkcmVzcwpiZSBoYW5kbGVkIGRpZmZlcmVudGx5IHRoYW4g YSBnbG9iYWwgb25lPwoKPiAKPiAoSU1PLCBhIG5vZGUgd2l0aCBtaW4tYWNjZXNzPXJlYWQtb25s eSBpcyBhIGRpZmZlcmVudCBwcm9ibGVtKS4KClllcywgYSBNVFUgcGFyYW1ldGVyIGlzIGVzc2Vu dGlhbGx5IGNvbmZpZyBidXQgaWYgaXQgaXMgaGFyZHdpcmVkIGluIGEKZGV2aWNlLCBpdCBzaG91 bGQgc3RheSBjb25maWcgYnV0IGJlIGRlY2xhcmVkIGFzIHJlYWQtb25seS4KCkxhZGEKCj4gCj4g PiBUaGFua3MsCj4gPiAgUGhpbAo+ID4gICAKPiAKPiBBbmR5Cj4gCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4g bmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Dec 4 02:34:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15CB3A694E; Thu, 4 Dec 2008 02:34:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC2F3A69BF for ; Thu, 4 Dec 2008 02:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 SoEiumEbCdgz for ; Thu, 4 Dec 2008 02:34:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8F7B63A694E for ; Thu, 4 Dec 2008 02:34:18 -0800 (PST) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 0950BD800CC; Thu, 4 Dec 2008 11:34:14 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081204.104110.129525820.mbj@tail-f.com> References: <000201c95571$cc5d45e0$0601a8c0@allison> <200812031943.mB3JhAQV022414@idle.juniper.net> <20081204.104110.129525820.mbj@tail-f.com> Organization: CESNET Date: Thu, 04 Dec 2008 11:34:13 +0100 Message-Id: <1228386853.6440.34.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMDQuIDEyLiAyMDA4IHYgMTA6NDEgKzAxMDA6 Cj4gUGhpbCBTaGFmZXIgPHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOgo+ID4gPkkgZG8gbm90IGtu b3cgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBhY2hpZXZlIHdpdGggdGhpcyBtZXRhZGF0YSwKPiA+ ID5jb25maWcvbWFuZGF0b3J5L2Fzc2lnbmVkIGJ5L2RlZmF1bHQsIGJ1dCBpdCBqdXN0IHNlZW1z IGNvbmZ1c2VkLCBpbGwtdGhvdWdodAo+ID4gPm91dCwgY3JlYXRpbmcgY29uZnVzaW9uIHdoZXJl IG5vbmUgbmVlZCBleGlzdC4gIEkgd291bGQgc2NyYXAgdGhlIGxvdCB1bnRpbCBJCj4gPiA+c2F3 IGEgZ29vZCBjYXNlIGZvciBhbnl0aGluZyBpbiB0aGlzIGFyZWEuCj4gPiAKPiA+IElNSE8gdGhl cmUgYXJlIG1hbnkgZXhpc3RpbmcgdXNlIGNhc2VzIGZvciB0aGUgY29uZmlnLCBtYW5kYXRvcnks Cj4gPiBhbmQgZGVmYXVsdCBwcm9wZXJ0aWVzLiAgV2UgdXNlIHRoZW0gKHRoZSBKVU5PUyBlcXVp dmFsZW50cykgZXZlcnkKPiA+IGRheS4KPiAKPiBTYW1lIGhlcmUuICBXZSB1c2UgdGhlbSBhbmQg b3VyIGN1c3RvbWVycyB1c2UgdGhlbSBhbGwgdGhlIHRpbWUuCj4gSU1PIHRoZXkgYXJlIGFic29s dXRlbHkgZXNzZW50aWFsLgo+IAo+IEp1c3QgYXMgb25lIGV4YW1wbGUsIGhvdyB3b3VsZCBhbnlv bmUga25vdyB3aGF0J3MgcG9zc2libGUgdG8gc2VuZCBpbgo+IGFuIGVkaXQtY29uZmlnIGlmIHdl IHNpbXBseSByZW1vdmVkIHRoZSAnY29uZmlnJyBzdGF0ZW1lbnQ/CgpJIHRoaW5rIG5vYm9keSBz dWdnZXN0cyB0byByZW1vdmUgdGhpcyBkaXN0aW5jdGlvbi4gVGhlcmUgYXJlIHBhcmFtZXRlcnMK bGlrZSBieXRlIGNvdW50ZXJzIHRoYXQgY2FuIG5ldmVyIGJlIGNvbmZpZy4gSG93ZXZlciwgdGhv c2UgdGhhdCBjYW4gYmUsCmF0IGxlYXN0IHNvbWV0aW1lcywgc2hvdWxkIGJlIGRlY2xhcmVkIGFz IGNvbmZpZyBhbmQgYWxsb3dlZCBpbgplZGl0LWNvbmZpZy4gSG93ZXZlciwgdGhlIG1hbmFnZXIg bXVzdCBiZSBwcmVwYXJlZCB0aGF0IGluIHNvbWUgY2FzZXMgYW4KYXR0ZW1wdCB0byBjaGFuZ2Ug YSBjb25maWcgcGFyYW1ldGVyIHdpbGwgYmUgcmVmdXNlZC4KClBlcmhhcHMgYSBjb25maWd1cmF0 aW9uIHBhcmFtZXRlciBjb3VsZCBjYXJyeSBhbiBvcHRpb25hbCBhdHRyaWJ1dGUKdGVsbGluZyBo b3cgaXQgd2FzIHNldCAtIGV4cGxpY2l0bHkgKGRlZmF1bHQgY2hvaWNlKSwgZnJvbSBhIERNIGRl ZmF1bHQsCnZlbmRvciBkZWZhdWx0IG9yIHByb3RvY29sLgoKTGFkYQoKPiAKPiAKPiA+IEluIGFs bCBvZiBKVU5PUyB0aGVyZSBpcyBleGFjdGx5IG9uZSBjYXNlIHdoZXJlIHdlIHdvdWxkIHVzZQo+ ID4gYXNzaWduZWQtYnkgKGlmIHdlIGhhdmUgaXQpLgo+IAo+IFRoZSBpcGZpeCBZQU5HIG1vZHVs ZSBoYXMgNSBvYmplY3RzIHdoaWNoIHdvdWxkIHVzZSBpdCBpZiB3ZSBoYWQgaXQuCj4gQ3VycmVu dGx5IHRoZXkgdXNlIHRoZSBkZXNjcmlwdGlvbiBjbGF1c2U6Cj4gCj4gICAgICAgbGVhZiBvYnNl cnZhdGlvblBvaW50SWQgewo+ICAgICAgICAgZGVzY3JpcHRpb24gIklmIG9taXR0ZWQsIHRoZSBP YnNlcnZhdGlvbiBQb2ludCBJRCBpcyBhc3NpZ25lZAo+ICAgICAgICAgICBieSB0aGUgbW9uaXRv cmluZyBkZXZpY2UuIjsKPiAgICAgICAgIHR5cGUgdWludDMyOwo+ICAgICAgIH0KPiAKPiA+IEdp dmVuIHRoZSBzbWFsbCBuZWVkIGZvciBhc3NpZ25lZC1ieSwgSSdkIGhhcHBpbHkgcG9zdHBvbmUg aXQKPiA+IGFzIGZ1dHVyZSB3b3JrICh5Mjphc3NpZ25lZC1ieSA7XikuCj4gCj4gSSBjYW4gbGl2 ZSB3aXRoIHBvc3Rwb25pbmcgdGhpcyBhcyB3ZWxsLgo+IAo+IAo+IC9tYXJ0aW4KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5n IGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0 RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5l dG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Dec 4 02:48:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD1F28C0E3; Thu, 4 Dec 2008 02:48:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008EB3A69BB for ; Thu, 4 Dec 2008 02:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 q-at5HopEFCj for ; Thu, 4 Dec 2008 02:48:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E6F303A6851 for ; Thu, 4 Dec 2008 02:48:17 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E511C76C30E; Thu, 4 Dec 2008 11:48:12 +0100 (CET) Date: Thu, 04 Dec 2008 11:48:10 +0100 (CET) Message-Id: <20081204.114810.116703874.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1228386853.6440.34.camel@missotis> References: <200812031943.mB3JhAQV022414@idle.juniper.net> <20081204.104110.129525820.mbj@tail-f.com> <1228386853.6440.34.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMDQuIDEyLiAyMDA4IHYgMTA6NDEgKzAxMDA6DQo+ID4gUGhpbCBT aGFmZXIgPHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+ID4gPkkgZG8gbm90IGtub3cgd2hh dCB5b3UgYXJlIHRyeWluZyB0byBhY2hpZXZlIHdpdGggdGhpcyBtZXRhZGF0YSwNCj4gPiA+ID5j b25maWcvbWFuZGF0b3J5L2Fzc2lnbmVkIGJ5L2RlZmF1bHQsIGJ1dCBpdCBqdXN0IHNlZW1zIGNv bmZ1c2VkLA0KPiA+ID4gPmlsbC10aG91Z2h0DQo+ID4gPiA+b3V0LCBjcmVhdGluZyBjb25mdXNp b24gd2hlcmUgbm9uZSBuZWVkIGV4aXN0LiAgSSB3b3VsZCBzY3JhcCB0aGUgbG90DQo+ID4gPiA+ dW50aWwgSQ0KPiA+ID4gPnNhdyBhIGdvb2QgY2FzZSBmb3IgYW55dGhpbmcgaW4gdGhpcyBhcmVh Lg0KPiA+ID4gDQo+ID4gPiBJTUhPIHRoZXJlIGFyZSBtYW55IGV4aXN0aW5nIHVzZSBjYXNlcyBm b3IgdGhlIGNvbmZpZywgbWFuZGF0b3J5LA0KPiA+ID4gYW5kIGRlZmF1bHQgcHJvcGVydGllcy4g IFdlIHVzZSB0aGVtICh0aGUgSlVOT1MgZXF1aXZhbGVudHMpIGV2ZXJ5DQo+ID4gPiBkYXkuDQo+ ID4gDQo+ID4gU2FtZSBoZXJlLiAgV2UgdXNlIHRoZW0gYW5kIG91ciBjdXN0b21lcnMgdXNlIHRo ZW0gYWxsIHRoZSB0aW1lLg0KPiA+IElNTyB0aGV5IGFyZSBhYnNvbHV0ZWx5IGVzc2VudGlhbC4N Cj4gPiANCj4gPiBKdXN0IGFzIG9uZSBleGFtcGxlLCBob3cgd291bGQgYW55b25lIGtub3cgd2hh dCdzIHBvc3NpYmxlIHRvIHNlbmQgaW4NCj4gPiBhbiBlZGl0LWNvbmZpZyBpZiB3ZSBzaW1wbHkg cmVtb3ZlZCB0aGUgJ2NvbmZpZycgc3RhdGVtZW50Pw0KPiANCj4gSSB0aGluayBub2JvZHkgc3Vn Z2VzdHMgdG8gcmVtb3ZlIHRoaXMgZGlzdGluY3Rpb24uDQoNClNvcnJ5IGlmIEkgbWlzdW5kcmVz dG9vZCwgYnV0IFRvbSBQZXRjaCB3cm90ZToNCg0KICBJIGRvIG5vdCBrbm93IHdoYXQgeW91IGFy ZSB0cnlpbmcgdG8gYWNoaWV2ZSB3aXRoIHRoaXMgbWV0YWRhdGEsDQogIGNvbmZpZy9tYW5kYXRv cnkvYXNzaWduZWQgYnkvZGVmYXVsdCwgYnV0IGl0IGp1c3Qgc2VlbXMgY29uZnVzZWQsDQogIGls bC10aG91Z2h0IG91dCwgY3JlYXRpbmcgY29uZnVzaW9uIHdoZXJlIG5vbmUgbmVlZCBleGlzdC4g IEkgd291bGQNCiAgc2NyYXAgdGhlIGxvdA0KDQpJIHRob3VnaHQgInRoZSBsb3QiIHJlZmVyZWQg dG8gInRoaXMgbWV0YWRhdGEiLCB3aGljaCBpbmNsdWRlZA0KJ2NvbmZpZycuDQoNCj4gVGhlcmUg YXJlIHBhcmFtZXRlcnMNCj4gbGlrZSBieXRlIGNvdW50ZXJzIHRoYXQgY2FuIG5ldmVyIGJlIGNv bmZpZy4gSG93ZXZlciwgdGhvc2UgdGhhdCBjYW4gYmUsDQo+IGF0IGxlYXN0IHNvbWV0aW1lcywg c2hvdWxkIGJlIGRlY2xhcmVkIGFzIGNvbmZpZyBhbmQgYWxsb3dlZCBpbg0KPiBlZGl0LWNvbmZp Zy4gSG93ZXZlciwgdGhlIG1hbmFnZXIgbXVzdCBiZSBwcmVwYXJlZCB0aGF0IGluIHNvbWUgY2Fz ZXMgYW4NCj4gYXR0ZW1wdCB0byBjaGFuZ2UgYSBjb25maWcgcGFyYW1ldGVyIHdpbGwgYmUgcmVm dXNlZC4NCg0KSSBhZ3JlZSB3aXRoIHdoYXQgQW5keSwgUGhpbCBhbmQgb3RoZXJzIHNhaWQgdGhh dCB3ZSBzaG91bGQgbm90IG1peA0KY29uZmlnIGFuZCBub24tY29uZmlnIGluIHRoZSBzYW1lIG9i amVjdHMuICBBbmQgdGhpcyBpcyBvZiBjb3Vyc2UNCndoYXQncyBpbiB0aGUgZHJhZnQgdG9kYXkg LSBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYW55IGNvbmZ1c2lvbiBpbiB0aGUNCmRyYWZ0IGFib3V0 IHRoaXMuDQoNCkZvciB0aGUgaXAgYWRkcmVzcyBleGFtcGxlIHlvdSBoYWQsIEkgd291bGQgaGF2 ZSBhIGNvbmZpZ3VyYXRpb24gd2hpY2gNCmlzIGEgY2hvaWNlIGJldHdlZW4gdXNpbmcgZGhjcCBh bmQgc2V0dGluZyBhIHN0YXRpYyBhZGRyZXNzLiAgVGhlbiBhDQpzZXBhcmF0ZSBub24tY29uZmln IG9iamVjdCB3b3VsZCByZXBvcnQgdGhlIGFkZHJlc3MuDQoNCg0KDQovbWFydGluDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Thu Dec 4 03:14:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A4D3A692D; Thu, 4 Dec 2008 03:14:04 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC14D3A69C9 for ; Thu, 4 Dec 2008 03:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 mTSxdOvajFRH for ; Thu, 4 Dec 2008 03:14:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E83CF3A692D for ; Thu, 4 Dec 2008 03:14:01 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48E98C00C7; Thu, 4 Dec 2008 12:13:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id C5JYy8VfZGHD; Thu, 4 Dec 2008 12:13:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3637C00B9; Thu, 4 Dec 2008 12:13:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 964FA89DC30; Thu, 4 Dec 2008 12:13:50 +0100 (CET) Date: Thu, 4 Dec 2008 12:13:50 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20081204111350.GA11610@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , netmod@ietf.org References: <200812031943.mB3JhAQV022414@idle.juniper.net> <4936E91A.6000104@netconfcentral.com> <1228384981.6440.26.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1228384981.6440.26.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 04, 2008 at 11:03:01AM +0100, Ladislav Lhotka wrote: > So should an IPv6 address on an interface be modeled as config or > non-config (operational parameter)? On my Debian system, ifconfig or ip reports the operational state of an interface including the assigned IP addresses. The configured IP addresses are stored in a file (/etc/network/interfaces) and assigned when the configuration file is loaded. In other words, you need to model the operational state of an interface and the configuration state of an interface; they are not the same thing. And yes, if all you have is the output of ifconfig, you can't decide which IP address is configuration state and which is not. So it requires efforts to make this distinction on the device. Pushing this effort to the manager (the way SNMP works) is not a solution since the manager has no chance to figure this distinction out. > Should it depend e.g., on whether an adjacent router sends router > advertisements? IP addresses obtained via router advertisements are operational state. > Should a link-local address be handled differently than a global > one? The scope does not matter. If the address is assigned via static configuration, it should be reported as part of configuration state. If the address is automatically generated, then it should not be reported as configuration state. /js PS: For some background, please consult RFC 3535 and in particular section 3 "Operator Requirements". Separation of configuration state from operational state was one of the operator's main concerns and part of the reason for having NETCONF. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 06:22:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EC33A6A7B; Thu, 4 Dec 2008 06:22:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C7C3A6A7D for ; Thu, 4 Dec 2008 06:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QneBiRq8RGy4 for ; Thu, 4 Dec 2008 06:22:50 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id E2BCD3A6A7B for ; Thu, 4 Dec 2008 06:22:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSTfnq8Vw2R0tjXId+8FqHYh7aRPb+kPH@postini.com; Thu, 04 Dec 2008 06:22:45 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 4 Dec 2008 06:19:50 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 06:19:50 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 06:19:50 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 06:19:49 -0800 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 mB4EJnM84223; Thu, 4 Dec 2008 06:19:49 -0800 (PST) (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 mB4EEVsL055702; Thu, 4 Dec 2008 14:14:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812041414.mB4EEVsL055702@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1228384294.6440.16.camel@missotis> Date: Thu, 4 Dec 2008 09:14:31 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2008 14:19:49.0927 (UTC) FILETIME=[5E146370:01C9561B] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >Given that we don't even agree on what a configuration contains (are the >values that haven't been explicitly set by the manager there or not?), I >think it is hopeless to try to distinguish all these cases in the DML. Given that this problem has been solved multiple times in real world products, I see no point in calling it hopeless. The question is can we find a workable compromise that gives us sufficient common ground to allow clients and servers with differing views to interoperate. If the server forces defaults to exist and the client doesn't care, they should be able to talk to each other. If the server discards explicit values and the client panics when it sees its value "disappear", then they won't be able to work together. I believe we can write rules that allow this sort of interaction to occur between clients and servers, even when they differ on some implementation points. Sure, I'd rather everyone did it my way, but that's not going to happen. But we can leave sufficient flexibility to allow differing viewpoints to interoperate. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 06:33:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CC53A6A9C; Thu, 4 Dec 2008 06:33:10 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5964E3A6A9C for ; Thu, 4 Dec 2008 06:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.074, 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 CggTskZhSKFm for ; Thu, 4 Dec 2008 06:33:07 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id AA30C3A6A7B for ; Thu, 4 Dec 2008 06:33:07 -0800 (PST) Received: (qmail 96429 invoked from network); 4 Dec 2008 14:33:03 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2008 14:33:03 -0000 X-YMail-OSG: CXhQ.B4VM1kr7pqb9bhGJ5aiRS8qJdcS8KtRU4me56E4MPahdA1do3xK1LUx_US2vTeEf4byECoWhKUMoxQIPmA2lMlyGh.FVi1kCKcd_si0bEMrzlrSQLjuuJGSCzJhZIuniQo6CAGZ2Wonoqe7SwS8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4937EA1F.6060806@netconfcentral.com> Date: Thu, 04 Dec 2008 06:33:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493747E9.6070801@netconfcentral.com> <200812040328.mB43S2Q7025731@idle.juniper.net> <20081204.105723.94620406.mbj@tail-f.com> In-Reply-To: <20081204.105723.94620406.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Phil Shafer wrote: > >> Andy Bierman writes: >> >>> when "not(feature('local-storage'))"; >>> >> Consider the "when" expression: >> >> when "pigs > fly && feature('local')"; >> >> To know if this applies, I need to either >> (a) evaluate it (using a XPath library), >> (b) break it apart (using an XPath parser), or >> (c) "know" via human inspection. >> >> (a) is how most implementations will process XPath expressions >> unless they are hard-coding for their particular device, in >> which case (c) will be used. >> >> But in many cases, I'd like to know at build time whether I >> need to carry information about schema nodes on to my products. >> If the product doesn't support 'local', I never need to ship >> that part of the compiled YANG modules onto that device. >> >> Making "if-feature" an explicit, first class YANG statement >> allows me to do this. Putting this into "when" means I'll >> need to do (b) and some additional heavy lifting. >> > > I agree with this, and can add that moving this function into 'when' > fundamentally changes what a when expression is. Currently, the > 'when' expression can only reference data in the data tree. So given > the expression and the entire data tree, the when expression evaluates > to the same value regardless of the device type. By adding 'feature' > and/or 'capability' functions, this would no longer be true. > > Actually, these XPath conditionals can be used in notificaions and RPC input/output also. IMO, feature() is cleaner and much more versatile than if-feature. Why invent yet another filtering mechanism with if-feature or if-capability? XPath provides a function library, so why not use it? This 1st order vs. 3rd-order YANG clause doesn't seem very compelling to me. Looks a lot like 'not invented here' syndrome instead. XPath also provides a variable binding mechanism that I support with extensions. So I will implement $rollback-on-error=true instead of capability('nc:rollback-on-error') = true. That way, no new mechanisms need to be invented at all. > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 06:44:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749363A6AF9; Thu, 4 Dec 2008 06:44:57 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6773A6AF7 for ; Thu, 4 Dec 2008 06:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 06w31UbpxXpd for ; Thu, 4 Dec 2008 06:44:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7CEBF3A6A3B for ; Thu, 4 Dec 2008 06:44:54 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00017C001C; Thu, 4 Dec 2008 15:44:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5oZxz4bGveHb; Thu, 4 Dec 2008 15:44:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8827C00BD; Thu, 4 Dec 2008 15:44:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 91E7A89DEA8; Thu, 4 Dec 2008 15:44:43 +0100 (CET) Date: Thu, 4 Dec 2008 15:44:43 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081204144443.GA11879@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <493747E9.6070801@netconfcentral.com> <200812040328.mB43S2Q7025731@idle.juniper.net> <20081204.105723.94620406.mbj@tail-f.com> <4937EA1F.6060806@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4937EA1F.6060806@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 04, 2008 at 06:33:03AM -0800, Andy Bierman wrote: > IMO, feature() is cleaner and much more versatile than if-feature. > Why invent yet another filtering mechanism with if-feature > or if-capability? I am with Phil and Martin on this. The when expression is conceptually evaluated against the data tree at runtime as far as I can tell. The feature mechanism is conceptually evaluated at compile time and not really against the data tree if I understand things correctly. If your argument is that a simple feature selection is not expressive enough, then the solution should be to make the if-feature argument an (xpath?) expression rather than a qname. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 06:58:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1DD3A6B07; Thu, 4 Dec 2008 06:58:04 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF353A6B15 for ; Thu, 4 Dec 2008 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.068, 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 tLNdRqRSQFBj for ; Thu, 4 Dec 2008 06:58:02 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 6541F3A6B07 for ; Thu, 4 Dec 2008 06:58:02 -0800 (PST) Received: (qmail 48519 invoked from network); 4 Dec 2008 14:57:58 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2008 14:57:57 -0000 X-YMail-OSG: B7CQfUgVM1mFfVNtF1W_x7YqQXMYAW4XnXx69C6CjTZNkULOoxe5jgjwEnOmPcj8_FTQxqlikUcGD29cs0TySktL5buJJ8Fk5wrXzMzrP9Nm_h2ucsRV1YoUShQIvRnlajP2T_6nCc15lEj2G81O62c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4937EFF6.2050905@netconfcentral.com> Date: Thu, 04 Dec 2008 06:57:58 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <493747E9.6070801@netconfcentral.com> <200812040328.mB43S2Q7025731@idle.juniper.net> <20081204.105723.94620406.mbj@tail-f.com> <4937EA1F.6060806@netconfcentral.com> <20081204144443.GA11879@elstar.local> In-Reply-To: <20081204144443.GA11879@elstar.local> Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Dec 04, 2008 at 06:33:03AM -0800, Andy Bierman wrote: > > >> IMO, feature() is cleaner and much more versatile than if-feature. >> Why invent yet another filtering mechanism with if-feature >> or if-capability? >> > > I am with Phil and Martin on this. The when expression is conceptually > evaluated against the data tree at runtime as far as I can tell. The > feature mechanism is conceptually evaluated at compile time and not > really against the data tree if I understand things correctly. > > If your argument is that a simple feature selection is not expressive > enough, then the solution should be to make the if-feature argument an > (xpath?) expression rather than a qname. > > Then I strongly oppose the if-feature mechanism. I do not want #ifdef in YANG. I thought if-feature was just like the when-stmt, except instead of the agent evaluating an XPath expression against the target configuration, the agent evaluates a boolean test based on the features actually supported at runtime. Now if-feature seems to be an extremely crude version of the C pre-compiler construct #ifdef. Changing it to #if (what about #else and #elif) is not a good option -- I want to get rid of compile-time conditionals, not make them 10X more complicated. > /js > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 07:01:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96F53A6AEC; Thu, 4 Dec 2008 07:01:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D361C3A6B07 for ; Thu, 4 Dec 2008 07:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 asq4mCDM-PNH for ; Thu, 4 Dec 2008 07:01:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A24923A6AEC for ; Thu, 4 Dec 2008 07:01:48 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24734C0025; Thu, 4 Dec 2008 16:01:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VKokilMYXjcf; Thu, 4 Dec 2008 16:01:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD34AC00C1; Thu, 4 Dec 2008 16:01:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A5C5D89E02F; Thu, 4 Dec 2008 16:01:36 +0100 (CET) Date: Thu, 4 Dec 2008 16:01:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081204150136.GA12516@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <493747E9.6070801@netconfcentral.com> <200812040328.mB43S2Q7025731@idle.juniper.net> <20081204.105723.94620406.mbj@tail-f.com> <4937EA1F.6060806@netconfcentral.com> <20081204144443.GA11879@elstar.local> <4937EFF6.2050905@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4937EFF6.2050905@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 04, 2008 at 06:57:58AM -0800, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Thu, Dec 04, 2008 at 06:33:03AM -0800, Andy Bierman wrote: >> >> >>> IMO, feature() is cleaner and much more versatile than if-feature. >>> Why invent yet another filtering mechanism with if-feature >>> or if-capability? >>> >> >> I am with Phil and Martin on this. The when expression is conceptually >> evaluated against the data tree at runtime as far as I can tell. The >> feature mechanism is conceptually evaluated at compile time and not >> really against the data tree if I understand things correctly. >> >> If your argument is that a simple feature selection is not expressive >> enough, then the solution should be to make the if-feature argument an >> (xpath?) expression rather than a qname. > > Then I strongly oppose the if-feature mechanism. > I do not want #ifdef in YANG. I thought if-feature was just > like the when-stmt, except instead of the agent evaluating > an XPath expression against the target configuration, the > agent evaluates a boolean test based on the features > actually supported at runtime. > > Now if-feature seems to be an extremely crude version of the C pre-compiler > construct #ifdef. Changing it to #if (what about #else and #elif) is not > a good option -- I want to get rid of compile-time conditionals, not > make them 10X more complicated. Features in data models that do not apply to all implementations are a reality. I am unsure how you want to deal with this reality. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 07:13:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7223A6AF9; Thu, 4 Dec 2008 07:13:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A99E3A6B4E for ; Thu, 4 Dec 2008 07:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, 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 ncP5RUAu1aP7 for ; Thu, 4 Dec 2008 07:13:52 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id A368E3A6AF9 for ; Thu, 4 Dec 2008 07:13:52 -0800 (PST) Received: (qmail 51248 invoked from network); 4 Dec 2008 15:13:48 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2008 15:13:48 -0000 X-YMail-OSG: 98Ll6NAVM1li_1H_M4VogDLFWZ.YWhTTmbtD_xjc6x.J1X8D09apooFzgt8RPOBrGQKDRW4urBFEoa2PZemu56hGeAgtZB51lRTBMfKv8eVvByAbMsZouo6O0V6g9cBHaJQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4937F3AC.4020001@netconfcentral.com> Date: Thu, 04 Dec 2008 07:13:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <493747E9.6070801@netconfcentral.com> <200812040328.mB43S2Q7025731@idle.juniper.net> <20081204.105723.94620406.mbj@tail-f.com> <4937EA1F.6060806@netconfcentral.com> <20081204144443.GA11879@elstar.local> <4937EFF6.2050905@netconfcentral.com> <20081204150136.GA12516@elstar.local> In-Reply-To: <20081204150136.GA12516@elstar.local> Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Dec 04, 2008 at 06:57:58AM -0800, Andy Bierman wrote: > >> Juergen Schoenwaelder wrote: >> >>> On Thu, Dec 04, 2008 at 06:33:03AM -0800, Andy Bierman wrote: >>> >>> >>> >>>> IMO, feature() is cleaner and much more versatile than if-feature. >>>> Why invent yet another filtering mechanism with if-feature >>>> or if-capability? >>>> >>>> >>> I am with Phil and Martin on this. The when expression is conceptually >>> evaluated against the data tree at runtime as far as I can tell. The >>> feature mechanism is conceptually evaluated at compile time and not >>> really against the data tree if I understand things correctly. >>> >>> If your argument is that a simple feature selection is not expressive >>> enough, then the solution should be to make the if-feature argument an >>> (xpath?) expression rather than a qname. >>> >> Then I strongly oppose the if-feature mechanism. >> I do not want #ifdef in YANG. I thought if-feature was just >> like the when-stmt, except instead of the agent evaluating >> an XPath expression against the target configuration, the >> agent evaluates a boolean test based on the features >> actually supported at runtime. >> >> Now if-feature seems to be an extremely crude version of the C pre-compiler >> construct #ifdef. Changing it to #if (what about #else and #elif) is not >> a good option -- I want to get rid of compile-time conditionals, not >> make them 10X more complicated. >> > > Features in data models that do not apply to all implementations are a > reality. I am unsure how you want to deal with this reality. > > What a toolset does with the YANG modules is outside the scope of the standard. In fact, the only official purpose or use for YANG is to convert it to YIN or DSDL. So, do the if-feature statements cause part of the DSDL translation to be skipped if a feature is disabled? The feature advertisement by a NETCONF agent addresses the "I only support this much" problem, but that it at run-time. To the NETMOD WG, compile-time means validation of the YANG module, and translation to YIN or DSDL. It has nothing to do with NETCONF agents or managers. Why does YANG need #ifdef? > /js > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 07:42:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC4F3A6A8F; Thu, 4 Dec 2008 07:42:38 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FEC3A6A8F for ; Thu, 4 Dec 2008 07:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] 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 spzIiSzNVtnb for ; Thu, 4 Dec 2008 07:42:36 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id E982E3A6A58 for ; Thu, 4 Dec 2008 07:42:36 -0800 (PST) Received: (qmail 82086 invoked from network); 4 Dec 2008 15:42:32 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2008 15:42:31 -0000 X-YMail-OSG: 4qDPpScVM1l_UP.NfBW5Qgy_r6_Q0BbPZjx553_cl3IZzwM6HDMSb6.RrwyYuZkk8PPNgUaouDQqmtt1uFB_d0IPCWDuiQzHAgspdRA8aNNdsTD7BLOOHhFmYp3dXqiSh3lLSK2wqo2gcXYj7_NC0Q86 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4937FA68.6060507@netconfcentral.com> Date: Thu, 04 Dec 2008 07:42:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <200812031749.mB3HnBIA021558@idle.juniper.net> <4936CA7A.8060105@netconfcentral.com> <20081204.102455.214236411.mbj@tail-f.com> In-Reply-To: <20081204.102455.214236411.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > I moved the part of the thread that discussed :partial-lock and :xpath > to the netconf ML. > > But read on. > > Andy Bierman wrote: > >> A new capability MUST NOT add any requirements to an existing capability. >> This rule is being violated by the partial-lock draft. >> > > If this is the case, then you're suggestion to introduce a > 'if-capability' statement will not work, since if you use e.g. > > leaf select { > if-capability ":xpath"; > ... > } > > you really add a requirement to an existing capability. > > Yes. But that has nothing to do with YANG. The protocol if-capability variables would be used in netconf.yang to describe existing RPCs. I agree this is not a priority for the WG. I think if-feature is probably fine, and we just have a disconnect on the term 'compile-time'. I don't want if-feature and if-capability both, and there are plenty of work-arounds available for capability checking. feature confirmed-commit { if-feature candidate; } leaf confirm-timeout { if-feature confirmed-commit; type uint32 { range "1..max"; } default 600; units seconds; reference "RFC 4741, sec. 8.4.5.1"; } > Continuing this logic, we should do the same for feature, and not > allow a feature to be exported/imported from another module, as was > suggested by Andy earlier. > > > /martin > > > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 08:31:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10923A6AB6; Thu, 4 Dec 2008 08:31:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4BA3A6B8E for ; Thu, 4 Dec 2008 08:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 fzG+ctzZbUn4 for ; Thu, 4 Dec 2008 08:31:30 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id C67243A6AB6 for ; Thu, 4 Dec 2008 08:31:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSTgF14U6T/nwyt0kOEgYaq6rw1ZWC3jD@postini.com; Thu, 04 Dec 2008 08:31:26 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 4 Dec 2008 08:27:30 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 08:27:30 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 08:27:29 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 08:27:29 -0800 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 mB4GRSM38212; Thu, 4 Dec 2008 08:27:28 -0800 (PST) (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 mB4GMDi1059229; Thu, 4 Dec 2008 16:22:13 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812041622.mB4GMDi1059229@idle.juniper.net> To: Andy Bierman In-Reply-To: <4937F3AC.4020001@netconfcentral.com> Date: Thu, 4 Dec 2008 11:22:13 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Dec 2008 16:27:29.0082 (UTC) FILETIME=[334AB1A0:01C9562D] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >In fact, the only official purpose or use >for YANG is to convert it to YIN or DSDL. This is simply not true. YANG is a language that allows data models for netconf to be defined. There data models can be manipulated via NETCONF. YIN and DSDL are by-products that can be generated from YANG, but are not the main purpose, let alone the "only official purpose or use". If you have gotten this idea from the YANG draft, the netmod-arch draft, or the working group charter, please let me know and we can address them. >The feature advertisement by a NETCONF agent addresses >the "I only support this much" problem, but that it at run-time. For a device, this isn't a runtime issue. If my products won't have disks, not supporting 'local-storage' isn't something available at runtime. >Why does YANG need #ifdef? Your use of #ifdef is a strawman. YANG needs the feature mechanism to allow the data modelers to express the fact that portions of their data model are optional. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 08:47:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7007B3A6961; Thu, 4 Dec 2008 08:47:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F833A69C3 for ; Thu, 4 Dec 2008 08:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 JUauomzt1VcT for ; Thu, 4 Dec 2008 08:47:18 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id BAD8A3A6961 for ; Thu, 4 Dec 2008 08:47:18 -0800 (PST) Received: (qmail 66094 invoked from network); 4 Dec 2008 16:47:14 -0000 Received: from unknown (HELO andymac.local) (andy@68.120.231.104 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 4 Dec 2008 16:47:13 -0000 X-YMail-OSG: RXcoTkYVM1mpkSVmz99lmrFkaaC5C7TUMX4ObROTC3B2My8PkTjirbv8tLaLr_zRJp7cnL8eePwQsGYQX7JkJ7RrmcdKKS1bohFsP0.Zx7mgfisN2gX7XxtAW8ZSHO6UokA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49380992.9030508@netconfcentral.com> Date: Thu, 04 Dec 2008 08:47:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812041622.mB4GMDi1059229@idle.juniper.net> In-Reply-To: <200812041622.mB4GMDi1059229@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >> In fact, the only official purpose or use >> for YANG is to convert it to YIN or DSDL. >> > > This is simply not true. YANG is a language that allows data models > for netconf to be defined. There data models can be manipulated > via NETCONF. YIN and DSDL are by-products that can be generated > from YANG, but are not the main purpose, let alone the "only official > purpose or use". > > If you have gotten this idea from the YANG draft, the netmod-arch > draft, or the working group charter, please let me know and we can > address them. > > >> The feature advertisement by a NETCONF agent addresses >> the "I only support this much" problem, but that it at run-time. >> > > For a device, this isn't a runtime issue. If my products won't > have disks, not supporting 'local-storage' isn't something available > at runtime. > > >> Why does YANG need #ifdef? >> > > Your use of #ifdef is a strawman. YANG needs the feature mechanism > to allow the data modelers to express the fact that portions of > their data model are optional. > > IMO, we can close this issue. When validating a YANG module, or converting it to YIN or DSDL, the supported features on a particular NETCONF agent implementation are not relevant. I never said the ability to specify partial module conformance was not needed. That is a strawman. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 09:33:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B965E3A6AAF; Thu, 4 Dec 2008 09:33:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A1D3A6B5C for ; Thu, 4 Dec 2008 09:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 ZgLxG-bxrqWP for ; Thu, 4 Dec 2008 09:33:53 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 817353A6AAF for ; Thu, 4 Dec 2008 09:33:53 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9D3CAD800CC; Thu, 4 Dec 2008 18:33:48 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081204.114810.116703874.mbj@tail-f.com> References: <200812031943.mB3JhAQV022414@idle.juniper.net> <20081204.104110.129525820.mbj@tail-f.com> <1228386853.6440.34.camel@missotis> <20081204.114810.116703874.mbj@tail-f.com> Organization: CESNET Date: Thu, 04 Dec 2008 18:33:47 +0100 Message-Id: <1228412027.6548.1.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMDQuIDEyLiAyMDA4IHYgMTE6NDggKzAxMDA6 Cgo+IFNvcnJ5IGlmIEkgbWlzdW5kcmVzdG9vZCwgYnV0IFRvbSBQZXRjaCB3cm90ZToKPiAKPiAg IEkgZG8gbm90IGtub3cgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBhY2hpZXZlIHdpdGggdGhpcyBt ZXRhZGF0YSwKPiAgIGNvbmZpZy9tYW5kYXRvcnkvYXNzaWduZWQgYnkvZGVmYXVsdCwgYnV0IGl0 IGp1c3Qgc2VlbXMgY29uZnVzZWQsCj4gICBpbGwtdGhvdWdodCBvdXQsIGNyZWF0aW5nIGNvbmZ1 c2lvbiB3aGVyZSBub25lIG5lZWQgZXhpc3QuICBJIHdvdWxkCj4gICBzY3JhcCB0aGUgbG90Cj4g Cj4gSSB0aG91Z2h0ICJ0aGUgbG90IiByZWZlcmVkIHRvICJ0aGlzIG1ldGFkYXRhIiwgd2hpY2gg aW5jbHVkZWQKPiAnY29uZmlnJy4KClRvbSBjYW4gcHJvYmFibHkgaW50ZXJwcmV0IGhpbXNlbGYg YmV0dGVyIHRoYW4gSSwgYnV0IG15IHVuZGVyc3RhbmRpbmcgd2FzICJ0aGUKd2hvbGUgbG90Ii4K Cj4gCj4gPiBUaGVyZSBhcmUgcGFyYW1ldGVycwo+ID4gbGlrZSBieXRlIGNvdW50ZXJzIHRoYXQg Y2FuIG5ldmVyIGJlIGNvbmZpZy4gSG93ZXZlciwgdGhvc2UgdGhhdCBjYW4gYmUsCj4gPiBhdCBs ZWFzdCBzb21ldGltZXMsIHNob3VsZCBiZSBkZWNsYXJlZCBhcyBjb25maWcgYW5kIGFsbG93ZWQg aW4KPiA+IGVkaXQtY29uZmlnLiBIb3dldmVyLCB0aGUgbWFuYWdlciBtdXN0IGJlIHByZXBhcmVk IHRoYXQgaW4gc29tZSBjYXNlcyBhbgo+ID4gYXR0ZW1wdCB0byBjaGFuZ2UgYSBjb25maWcgcGFy YW1ldGVyIHdpbGwgYmUgcmVmdXNlZC4KPiAKPiBJIGFncmVlIHdpdGggd2hhdCBBbmR5LCBQaGls IGFuZCBvdGhlcnMgc2FpZCB0aGF0IHdlIHNob3VsZCBub3QgbWl4Cj4gY29uZmlnIGFuZCBub24t Y29uZmlnIGluIHRoZSBzYW1lIG9iamVjdHMuICBBbmQgdGhpcyBpcyBvZiBjb3Vyc2UKPiB3aGF0 J3MgaW4gdGhlIGRyYWZ0IHRvZGF5IC0gSSBkb24ndCB0aGluayB0aGVyZSdzIGFueSBjb25mdXNp b24gaW4gdGhlCj4gZHJhZnQgYWJvdXQgdGhpcy4KPiAKPiBGb3IgdGhlIGlwIGFkZHJlc3MgZXhh bXBsZSB5b3UgaGFkLCBJIHdvdWxkIGhhdmUgYSBjb25maWd1cmF0aW9uIHdoaWNoCj4gaXMgYSBj aG9pY2UgYmV0d2VlbiB1c2luZyBkaGNwIGFuZCBzZXR0aW5nIGEgc3RhdGljIGFkZHJlc3MuICBU aGVuIGEKPiBzZXBhcmF0ZSBub24tY29uZmlnIG9iamVjdCB3b3VsZCByZXBvcnQgdGhlIGFkZHJl c3MuCgpBc3N1bWUgdGhlIGRldmljZSBpcyBjb25maWd1cmVkIHdpdGggREhDUCBhbmQgbm93IHRo ZSBtYW5hZ2VyIHNlbmRzIGFuCmVkaXQtY29uZmlnIGNvbnRhaW5pbmcgYSBzdGF0aWMgYWRkcmVz cy4gU2hvdWxkIHRoZSBkZXZpY2UgcmVqZWN0IGl0IGFzCmludmFsaWQ/IEkgdGhpbmsgaXQgd291 bGQgYmUgYSBiYWQgaWRlYS4gU28gaXQgbWVhbnMgdGhlIGFkZHJlc3MgaXMKc3RpbGwgYSBjb25m aWd1cmFibGUgcGFyYW1ldGVyLgoKTGFkYQoKPiAKPiAKPiAKPiAvbWFydGluCi0tIApMYWRpc2xh diBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Dec 4 09:35:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29C13A6AAF; Thu, 4 Dec 2008 09:35:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4476D3A6B68 for ; Thu, 4 Dec 2008 09:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 PPCiWVV1WVvu for ; Thu, 4 Dec 2008 09:34:58 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3B4A63A6AAF for ; Thu, 4 Dec 2008 09:34:58 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B169ED800EE; Thu, 4 Dec 2008 18:34:53 +0100 (CET) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081204111350.GA11610@elstar.local> References: <200812031943.mB3JhAQV022414@idle.juniper.net> <4936E91A.6000104@netconfcentral.com> <1228384981.6440.26.camel@missotis> <20081204111350.GA11610@elstar.local> Organization: CESNET Date: Thu, 04 Dec 2008 18:34:53 +0100 Message-Id: <1228412093.6548.2.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAwNC4gMTIuIDIwMDggdiAxMjoxMyAr MDEwMDogCj4gT24gVGh1LCBEZWMgMDQsIDIwMDggYXQgMTE6MDM6MDFBTSArMDEwMCwgTGFkaXNs YXYgTGhvdGthIHdyb3RlOgo+ICAKPiA+IFNvIHNob3VsZCBhbiBJUHY2IGFkZHJlc3Mgb24gYW4g aW50ZXJmYWNlIGJlIG1vZGVsZWQgYXMgY29uZmlnIG9yCj4gPiBub24tY29uZmlnIChvcGVyYXRp b25hbCBwYXJhbWV0ZXIpPwo+IAo+IE9uIG15IERlYmlhbiBzeXN0ZW0sIGlmY29uZmlnIG9yIGlw IHJlcG9ydHMgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIG9mCj4gYW4gaW50ZXJmYWNlIGluY2x1ZGlu ZyB0aGUgYXNzaWduZWQgSVAgYWRkcmVzc2VzLiBUaGUgY29uZmlndXJlZCBJUAo+IGFkZHJlc3Nl cyBhcmUgc3RvcmVkIGluIGEgZmlsZSAoL2V0Yy9uZXR3b3JrL2ludGVyZmFjZXMpIGFuZCBhc3Np Z25lZAo+IHdoZW4gdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSBpcyBsb2FkZWQuIEluIG90aGVyIHdv cmRzLCB5b3UgbmVlZCB0bwo+IG1vZGVsIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBvZiBhbiBpbnRl cmZhY2UgYW5kIHRoZSBjb25maWd1cmF0aW9uCj4gc3RhdGUgb2YgYW4gaW50ZXJmYWNlOyB0aGV5 IGFyZSBub3QgdGhlIHNhbWUgdGhpbmcuIEFuZCB5ZXMsIGlmIGFsbAo+IHlvdSBoYXZlIGlzIHRo ZSBvdXRwdXQgb2YgaWZjb25maWcsIHlvdSBjYW4ndCBkZWNpZGUgd2hpY2ggSVAgYWRkcmVzcwo+ IGlzIGNvbmZpZ3VyYXRpb24gc3RhdGUgYW5kIHdoaWNoIGlzIG5vdC4gU28gaXQgcmVxdWlyZXMg ZWZmb3J0cyB0bwo+IG1ha2UgdGhpcyBkaXN0aW5jdGlvbiBvbiB0aGUgZGV2aWNlLiBQdXNoaW5n IHRoaXMgZWZmb3J0IHRvIHRoZQo+IG1hbmFnZXIgKHRoZSB3YXkgU05NUCB3b3JrcykgaXMgbm90 IGEgc29sdXRpb24gc2luY2UgdGhlIG1hbmFnZXIgaGFzCj4gbm8gY2hhbmNlIHRvIGZpZ3VyZSB0 aGlzIGRpc3RpbmN0aW9uIG91dC4KCkNvbnRpbnVpbmcgdGhlIExpbnV4IGV4YW1wbGUsIHdlIGFs c28gaGF2ZSB0aGlzIG5pY2UgL3Byb2MgZmlsZXN5c3RlbS4KSXQgY29udGFpbnMgb3BlcmF0aW9u YWwgZGF0YSBidXQgaW4gZmFjdCBhbHNvIHNvbWV0aGluZyBsaWtlIHRoZQoicnVubmluZyIgZGF0 YXN0b3JlIC0gc29tZSBvZiB0aGUgcGFyYW1ldGVycyBhcmUgd3JpdGFibGUuIFNvIEkgdGVuZCB0 bwppZGVudGlmeSB0aGUgY29uZmlndXJhYmxlIHBvcnRpb24gb2YgdGhlIG9wZXJhdGlvbmFsIHN0 YXRlIHdpdGggdGhlCiJydW5uaW5nIiBkYXRhc3RvcmUuIFRoZXkgY2FuIGJlIGluIHR3byBkaWZm ZXJlbnQgcGxhY2VzIGJ1dCB0aGVuCnByb2JhYmx5IHNvbWUga2luZCBvZiBzeW5jaHJvbml6YXRp b24gaXMgbmVlZGVkLgoKPiAKPiA+IFNob3VsZCBpdCBkZXBlbmQgZS5nLiwgb24gd2hldGhlciBh biBhZGphY2VudCByb3V0ZXIgc2VuZHMgcm91dGVyCj4gPiBhZHZlcnRpc2VtZW50cz8KPiAKPiBJ UCBhZGRyZXNzZXMgb2J0YWluZWQgdmlhIHJvdXRlciBhZHZlcnRpc2VtZW50cyBhcmUgb3BlcmF0 aW9uYWwgc3RhdGUuCj4gCj4gPiBTaG91bGQgYSBsaW5rLWxvY2FsIGFkZHJlc3MgYmUgaGFuZGxl ZCBkaWZmZXJlbnRseSB0aGFuIGEgZ2xvYmFsCj4gPiBvbmU/Cj4gCj4gVGhlIHNjb3BlIGRvZXMg bm90IG1hdHRlci4gSWYgdGhlIGFkZHJlc3MgaXMgYXNzaWduZWQgdmlhIHN0YXRpYwoKV2hhdCBt YXR0ZXJzIGlzIGhvdyBlYWNoIHBhcmFtZXRlciBnZXRzIGl0cyB2YWx1ZS4gTGluay1sb2NhbCBh ZGRyZXNzZXMKYXJlIG5vcm1hbGx5IHNldCB0byBhbiBFVUktNjQgYmFzZWQgYWRkcmVzcy4gSXMg dGhpcyBhc3NpZ25lZC1ieSBzeXN0ZW0sCm9yIG9wZXJhdGlvbmFsIHN0YXRlPyBUaGVuIGhvdyBh Ym91dCB0aGUgZ2xvYmFsIGFkZHJlc3Mgd2hvc2UgbGVmdCBoYWxmCmlzIG9idGFpbmVkIHZpYSBS QSAoPW9wZXJhdGlvbmFsIHN0YXRlPykgYW5kIHJpZ2h0IGhhbGYgaW5pdGlhbGl6ZWQKYWdhaW4g dXNpbmcgRVVJLTY0ICg9YXNzaWduZWQtYnkgc3lzdGVtPykKCkxhZGEKCj4gY29uZmlndXJhdGlv biwgaXQgc2hvdWxkIGJlIHJlcG9ydGVkIGFzIHBhcnQgb2YgY29uZmlndXJhdGlvbiBzdGF0ZS4K PiBJZiB0aGUgYWRkcmVzcyBpcyBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCwgdGhlbiBpdCBzaG91 bGQgbm90IGJlCj4gcmVwb3J0ZWQgYXMgY29uZmlndXJhdGlvbiBzdGF0ZS4KPiAKPiAvanMKPiAK PiBQUzogRm9yIHNvbWUgYmFja2dyb3VuZCwgcGxlYXNlIGNvbnN1bHQgUkZDIDM1MzUgYW5kIGlu IHBhcnRpY3VsYXIKPiBzZWN0aW9uIDMgIk9wZXJhdG9yIFJlcXVpcmVtZW50cyIuIFNlcGFyYXRp b24gb2YgY29uZmlndXJhdGlvbgo+IHN0YXRlIGZyb20gb3BlcmF0aW9uYWwgc3RhdGUgd2FzIG9u ZSBvZiB0aGUgb3BlcmF0b3IncyBtYWluCj4gICAgIGNvbmNlcm5zIGFuZCBwYXJ0IG9mIHRoZSBy ZWFzb24gZm9yIGhhdmluZyBORVRDT05GLgoKCj4gCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05F VApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Dec 4 10:52:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49303A6A64; Thu, 4 Dec 2008 10:52:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C8F3A6B7E for ; Thu, 4 Dec 2008 10:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 aVgBRFjQhSHB for ; Thu, 4 Dec 2008 10:52:26 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 31CCE3A6B78 for ; Thu, 4 Dec 2008 10:52:26 -0800 (PST) X-Trace: 114185673/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.224/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.224 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAKG1N0k+vGTg/2dsb2JhbACDRDmJHsNDB4J+ X-IronPort-AV: E=Sophos;i="4.33,715,1220223600"; d="scan'208";a="114185673" X-IP-Direction: IN Received: from 1cust224.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.224]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Dec 2008 18:52:19 +0000 Message-ID: <002401c95639$22107bc0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <002101c954a2$e31662a0$0601a8c0@allison><200812021851.mB2Ipw7U002645@idle.juniper.net> <20081202.205415.134364559.mbj@tail-f.com> Date: Thu, 4 Dec 2008 18:50:30 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] defaults - needed updates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Tuesday, December 02, 2008 8:54 PM Subject: Re: [netmod] defaults - needed updates > Phil Shafer wrote: > > "tom.petch" writes: > > >How this specific issue gets resolved I do not know. That it is > > >unresolved - and it has occurred several times on this list - seems > > >a flaw in YANG, or perhaps in the process of this WG. > > > > The plan is to give wiggle room for servers to behave in their > > native manner. > > And I think that the draft now does that. If declaring three incompatible approaches all part of the spec, then yes, you are right. But I think that your other post on 'assigned-by' and responses thereto show that this metadata - config, mandatory, defaults etc - lacks consensus and makes work on the :with-defaults capability somewhat speculative. Tom Petch > > /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 4 12:18:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A8E3A67AB; Thu, 4 Dec 2008 12:18:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1713A682B for ; Thu, 4 Dec 2008 12:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 KU8p0v22eDNr for ; Thu, 4 Dec 2008 12:18:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B5FA3A67AB for ; Thu, 4 Dec 2008 12:18:38 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8B02C002A; Thu, 4 Dec 2008 21:18:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eBQPRygkJiX2; Thu, 4 Dec 2008 21:18:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C5B7C001D; Thu, 4 Dec 2008 21:18:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4195489E487; Thu, 4 Dec 2008 21:18:27 +0100 (CET) Date: Thu, 4 Dec 2008 21:18:27 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20081204201827.GA12757@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , netmod@ietf.org References: <200812031943.mB3JhAQV022414@idle.juniper.net> <4936E91A.6000104@netconfcentral.com> <1228384981.6440.26.camel@missotis> <20081204111350.GA11610@elstar.local> <1228412093.6548.2.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1228412093.6548.2.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] assigned-by X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 04, 2008 at 06:34:53PM +0100, Ladislav Lhotka wrote: > What matters is how each parameter gets its value. Link-local > addresses are normally set to an EUI-64 based address. Is this > assigned-by system, or operational state? I consider such an address operational state. > Then how about the global address whose left half is obtained via RA > (=operational state?) and right half initialized again using EUI-64 > (=assigned-by system?) I consider this operational state as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 5 14:58:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C093A6836; Fri, 5 Dec 2008 14:58:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976FF3A692A for ; Fri, 5 Dec 2008 14:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.061, 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 8I3vRfOufaGG for ; Fri, 5 Dec 2008 14:58:55 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id F356B3A6836 for ; Fri, 5 Dec 2008 14:58:54 -0800 (PST) Received: (qmail 52881 invoked from network); 5 Dec 2008 22:58:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.104 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 5 Dec 2008 22:58:48 -0000 X-YMail-OSG: 72MwA1EVM1me13FWLU9NNSBfq8n57rMAu7FJqD8Gsrncvh2ELuYVFd4lV6nOtdWVZZ6z7SKQlm1_dsC0sddPZTilajs9ITuecUHbae9AcUdVAyP3t1sQbKLMIMAjYbT1Zz4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4939B227.3010701@netconfcentral.com> Date: Fri, 05 Dec 2008 14:58:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The ABNF for the refinement statement leads to another one of those mandatory empty curly braces '{ }', since all of the variants contain optional clauses. So this is illegal: uses foo { refine a/b/c; } But this is not: uses foo { refine a/b/c { } } Not sure what you want to do about it. (I just code 'em as I see 'em :-) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 5 19:19:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89153A6800; Fri, 5 Dec 2008 19:19:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0537F3A6800 for ; Fri, 5 Dec 2008 19:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, 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 3diH196jLzCX for ; Fri, 5 Dec 2008 19:19:17 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id AB3953A6811 for ; Fri, 5 Dec 2008 19:19:17 -0800 (PST) Received: (qmail 16338 invoked from network); 6 Dec 2008 03:19:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.104 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 6 Dec 2008 03:19:11 -0000 X-YMail-OSG: 7NoXMSMVM1mLJiAaNa2SV_Y4ipSkjAtVDm4oS1lx5hpZ_6p9eNa.D8AdXrZJt0tniP_oPYZJg5HFINay0jtzaHU98meUncmvwf_kZnAAHV1bDqkVQYPKcAqjml7SufzxyiY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4939EF2D.8020509@netconfcentral.com> Date: Fri, 05 Dec 2008 19:19:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] repeat refine-stmts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Sec. 7.2.12 should specify what to do when conflicting refinements are found. Is it an error or is it 'last one wins' or what? grouping foo { leaf bar { type string; } } container X { uses foo { refine bar { config false; } refine bar { config true; } } } The ABNF clearly allows this, but I doubt that it the intent. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 06:49:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406C73A68E1; Sun, 7 Dec 2008 06:49:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626A43A6907 for ; Sun, 7 Dec 2008 06:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 UfcgQyv4h6wZ for ; Sun, 7 Dec 2008 06:49:52 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9BF203A68F0 for ; Sun, 7 Dec 2008 06:49:52 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2289276C310; Sun, 7 Dec 2008 15:49:46 +0100 (CET) Date: Sun, 07 Dec 2008 15:49:45 +0100 (CET) Message-Id: <20081207.154945.183905838.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4939B227.3010701@netconfcentral.com> References: <4939B227.3010701@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > The ABNF for the refinement statement leads to another > one of those mandatory empty curly braces '{ }', > since all of the variants contain optional clauses. > > So this is illegal: > > uses foo { > refine a/b/c; > } > > But this is not: > > uses foo { > refine a/b/c { } > } > > Not sure what you want to do about it. There's no obvious solution... We could state in the text that at least one refinement sub statement must be present. It does not seem right to allow "refine a/b/c;" since it doesn't really mean anything. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 06:51:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6D03A68F0; Sun, 7 Dec 2008 06:51:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F653A6932 for ; Sun, 7 Dec 2008 06:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 eCCip7wa4Tn3 for ; Sun, 7 Dec 2008 06:51:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E83BD3A690D for ; Sun, 7 Dec 2008 06:51:00 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A4B6D76C310; Sun, 7 Dec 2008 15:50:55 +0100 (CET) Date: Sun, 07 Dec 2008 15:50:55 +0100 (CET) Message-Id: <20081207.155055.05394164.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4939EF2D.8020509@netconfcentral.com> References: <4939EF2D.8020509@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] repeat refine-stmts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Sec. 7.2.12 should specify what to do when conflicting refinements > are found. Is it an error or is it 'last one wins' or what? The old text (i.e. draft -01) made this an error (it said A node can be refined only once in "uses".) Unless anyone objects, I will put this text back. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 08:30:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D783A68DF; Sun, 7 Dec 2008 08:30:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C176C3A69BF for ; Sun, 7 Dec 2008 08:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.077, 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 L03sxlAkthBm for ; Sun, 7 Dec 2008 08:30:33 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 263B33A68DF for ; Sun, 7 Dec 2008 08:30:33 -0800 (PST) Received: (qmail 22143 invoked from network); 7 Dec 2008 16:30:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2008 16:30:26 -0000 X-YMail-OSG: QlP9bG0VM1le7.bl90yEvyVauODg7o69irieCNITYg.nY0od.zBEumncG2R_goYxbsT2ndUNZIPbweG74rBzHRp1sCKn2rdDGCvV6DnBVUO2C7RpNkdm4gn63jpQAjIiYaIAqxEcbwQortvvTBP4O_Zl X-Yahoo-Newman-Property: ymail-3 Message-ID: <493BFA1F.80805@netconfcentral.com> Date: Sun, 07 Dec 2008 08:30:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4939EF2D.8020509@netconfcentral.com> <20081207.155055.05394164.mbj@tail-f.com> In-Reply-To: <20081207.155055.05394164.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] repeat refine-stmts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Sec. 7.2.12 should specify what to do when conflicting refinements >> are found. Is it an error or is it 'last one wins' or what? > > The old text (i.e. draft -01) made this an error (it said A node can > be refined only once in "uses".) > > Unless anyone objects, I will put this text back. > Is it an error to set a sub-stmt to the same value? A duplicate with the same value == warning. A duplicate with a conflicting value == error. Or any duplicate is an error is OK too, since there isn't any reason to do this. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 08:34:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E493A677E; Sun, 7 Dec 2008 08:34:10 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B270E3A6827 for ; Sun, 7 Dec 2008 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.072, 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 mYeMa-fQ3Ifg for ; Sun, 7 Dec 2008 08:34:09 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 113503A677E for ; Sun, 7 Dec 2008 08:34:09 -0800 (PST) Received: (qmail 82991 invoked from network); 7 Dec 2008 16:34:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2008 16:34:01 -0000 X-YMail-OSG: KbKFXzsVM1nbwMHc1reNZk6oPcZ7McLf4JziCjLnlfNGKLmDwFIHdDe60x3keKsP_XLTiZwPgnfbJfSQ7xo6YkKaYg.TGB0rU8.dYII5o_Yig72UzPkbNsWI7je1Y9WyytUHBa0kglxNagxyNqXWEubF X-Yahoo-Newman-Property: ymail-3 Message-ID: <493BFAF7.2000804@netconfcentral.com> Date: Sun, 07 Dec 2008 08:33:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4939B227.3010701@netconfcentral.com> <20081207.154945.183905838.mbj@tail-f.com> In-Reply-To: <20081207.154945.183905838.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The ABNF for the refinement statement leads to another >> one of those mandatory empty curly braces '{ }', >> since all of the variants contain optional clauses. >> >> So this is illegal: >> >> uses foo { >> refine a/b/c; >> } >> >> But this is not: >> >> uses foo { >> refine a/b/c { } >> } >> >> Not sure what you want to do about it. > > There's no obvious solution... We could state in the text that at > least one refinement sub statement must be present. It does not seem > right to allow "refine a/b/c;" since it doesn't really mean anything. > I coded it the same as grouping -- which allows empty groupings. grouping foo; this reserves the name 'foo' at least. a 'uses foo' will amount to a NO-OP. refine a/b/c; this doesn't do anything at all, but it doesn't hurt anything either (just a waste of bytes) > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 12:59:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700C03A689E; Sun, 7 Dec 2008 12:59:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B853A68C4 for ; Sun, 7 Dec 2008 12:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 VUtqX-PhUMcj for ; Sun, 7 Dec 2008 12:59:57 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B80B53A689E for ; Sun, 7 Dec 2008 12:59:57 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5258376C310; Sun, 7 Dec 2008 21:59:51 +0100 (CET) Date: Sun, 07 Dec 2008 21:59:48 +0100 (CET) Message-Id: <20081207.215948.231603619.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493BFAF7.2000804@netconfcentral.com> References: <4939B227.3010701@netconfcentral.com> <20081207.154945.183905838.mbj@tail-f.com> <493BFAF7.2000804@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> The ABNF for the refinement statement leads to another > >> one of those mandatory empty curly braces '{ }', > >> since all of the variants contain optional clauses. > >> > >> So this is illegal: > >> > >> uses foo { > >> refine a/b/c; > >> } > >> > >> But this is not: > >> > >> uses foo { > >> refine a/b/c { } > >> } > >> > >> Not sure what you want to do about it. > > There's no obvious solution... We could state in the text that at > > least one refinement sub statement must be present. It does not seem > > right to allow "refine a/b/c;" since it doesn't really mean anything. > > > > I coded it the same as grouping -- which allows empty groupings. You're right. So maybe we should do the same for refine then. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 13:37:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30EA3A69C5; Sun, 7 Dec 2008 13:37:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268313A69CA for ; Sun, 7 Dec 2008 13:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, 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 GUIZyuV4-exD for ; Sun, 7 Dec 2008 13:37:29 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 7E39F3A69C6 for ; Sun, 7 Dec 2008 13:37:29 -0800 (PST) Received: (qmail 59735 invoked from network); 7 Dec 2008 21:37:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2008 21:37:22 -0000 X-YMail-OSG: yCUIKgkVM1muPcciol7qpoHg490l7VQSRcBtBCdz6jshZ_sXMQrNMArmqzSOoDRcsINdgcCS5IV0fj5wDaU0f23YZngWvEgy86VTRcPhSmDdTIf0OKarSB1fjO40dbdxoS5x6OzPFJH0Kp9SoybiTCIs X-Yahoo-Newman-Property: ymail-3 Message-ID: <493C4210.8070504@netconfcentral.com> Date: Sun, 07 Dec 2008 13:37:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4939B227.3010701@netconfcentral.com> <20081207.154945.183905838.mbj@tail-f.com> <493BFAF7.2000804@netconfcentral.com> <20081207.215948.231603619.mbj@tail-f.com> In-Reply-To: <20081207.215948.231603619.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> The ABNF for the refinement statement leads to another >>>> one of those mandatory empty curly braces '{ }', >>>> since all of the variants contain optional clauses. >>>> >>>> So this is illegal: >>>> >>>> uses foo { >>>> refine a/b/c; >>>> } >>>> >>>> But this is not: >>>> >>>> uses foo { >>>> refine a/b/c { } >>>> } >>>> >>>> Not sure what you want to do about it. >>> There's no obvious solution... We could state in the text that at >>> least one refinement sub statement must be present. It does not seem >>> right to allow "refine a/b/c;" since it doesn't really mean anything. >>> >> I coded it the same as grouping -- which allows empty groupings. > > You're right. So maybe we should do the same for refine then. > yes. I collapse all the refines with the same target together. We treat duplicate clauses like config-stmt (inside a leaf) as an error (e.g., [config-stmt] means zero or one), so I guess we should treat any duplicate refinement-stmt sub-clauses (after combining all refinements with the same target) as an error. E.g., this is an error: refine a/b/c { config true; } refine a/b/c { config true; } This is just as much of an error: refine a/b/c { config true; config true; } The exception of course is must-stmt, because zero or more are allowed of them. There is no rule against having the same (redundant) must-stmt (or unique-stmt) either. It is just a warning. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 13:49:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A923A69D0; Sun, 7 Dec 2008 13:49:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC9E3A69D6 for ; Sun, 7 Dec 2008 13:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 F2LSVXJkEDOl for ; Sun, 7 Dec 2008 13:49:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7BA4F3A69D0 for ; Sun, 7 Dec 2008 13:49:17 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 263FA76C310; Sun, 7 Dec 2008 22:49:12 +0100 (CET) Date: Sun, 07 Dec 2008 22:49:08 +0100 (CET) Message-Id: <20081207.224908.252617370.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493C4210.8070504@netconfcentral.com> References: <493BFAF7.2000804@netconfcentral.com> <20081207.215948.231603619.mbj@tail-f.com> <493C4210.8070504@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > >> I coded it the same as grouping -- which allows empty groupings. > > You're right. So maybe we should do the same for refine then. > > > > yes. ok. > I collapse all the refines with the same target together. I treat multiple refines of the same target as an error. This was the behavior of the old spec, see the thread "repeat refine-stmts". /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 14:51:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EEC3A6452; Sun, 7 Dec 2008 14:51:17 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22FE3A67D0 for ; Sun, 7 Dec 2008 14:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, 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 9kygQvy9WsBp for ; Sun, 7 Dec 2008 14:51:15 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 175683A6452 for ; Sun, 7 Dec 2008 14:51:15 -0800 (PST) Received: (qmail 20496 invoked from network); 7 Dec 2008 22:51:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2008 22:51:08 -0000 X-YMail-OSG: Hd6U404VM1nX41Tzm4OhFvvydb.cfpSADJBYyJstK0ZpJxq5jK0FKqRq7MKwYGCbvuPJngMIGGTRlPNfKIduy26K9yL6ZFU7KpUnjxoCq9DNgiICIyzhuaT9D4O9Juvb88tth2cruwnvp8to7l1xRdPP X-Yahoo-Newman-Property: ymail-3 Message-ID: <493C535B.5050903@netconfcentral.com> Date: Sun, 07 Dec 2008 14:51:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493BFAF7.2000804@netconfcentral.com> <20081207.215948.231603619.mbj@tail-f.com> <493C4210.8070504@netconfcentral.com> <20081207.224908.252617370.mbj@tail-f.com> In-Reply-To: <20081207.224908.252617370.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>>> I coded it the same as grouping -- which allows empty groupings. >>> You're right. So maybe we should do the same for refine then. >>> >> yes. > > ok. > >> I collapse all the refines with the same target together. > > I treat multiple refines of the same target as an error. This was the > behavior of the old spec, see the thread "repeat refine-stmts". > > I only saw 2 emails, and I do object to this CLR: refine a/b/c { mandatory false; } refine a/b/c { description "leaf c constrained as follows..."; } This should not be an error. Consider applications (like the awesome smidump) that generate YANG. What if different sub-apps are responsible for generating their own refinement-stmts? (E.g., a conformance sub-app tweaks mandatory-stmt and must-stmt, and some other sub-app generates description refinements.) I realize this is a stretch, but why have a CLR if the practice being forbidden by the rule does not really hurt anything? > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 15:04:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A693A69F0; Sun, 7 Dec 2008 15:04:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AA13A69F0 for ; Sun, 7 Dec 2008 15:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 r713PK8-DD0E for ; Sun, 7 Dec 2008 15:04:38 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A68763A69EE for ; Sun, 7 Dec 2008 15:04:38 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A3D3E76C310; Mon, 8 Dec 2008 00:04:32 +0100 (CET) Date: Mon, 08 Dec 2008 00:04:32 +0100 (CET) Message-Id: <20081208.000432.86896353.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493C535B.5050903@netconfcentral.com> References: <493C4210.8070504@netconfcentral.com> <20081207.224908.252617370.mbj@tail-f.com> <493C535B.5050903@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I only saw 2 emails, and I do object to this CLR: > > refine a/b/c { > mandatory false; > } > > refine a/b/c { > description "leaf c constrained as follows..."; > } > > This should not be an error. [...] > I realize this is a stretch, but why have a CLR if the > practice being forbidden by the rule does not really > hurt anything? The rules that define this "merging" behavior will be non-trivial. Is it really worth it? And the use case you mentioned - tools have the lowest priority, and the code in the tool that generates the refine can do the merging itself. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 15:14:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1BF3A67C1; Sun, 7 Dec 2008 15:14:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E05F3A69B3 for ; Sun, 7 Dec 2008 15:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, 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 NV4UNVrFF30u for ; Sun, 7 Dec 2008 15:14:23 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 60AC63A693C for ; Sun, 7 Dec 2008 15:14:23 -0800 (PST) Received: (qmail 31780 invoked from network); 7 Dec 2008 23:14:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2008 23:14:17 -0000 X-YMail-OSG: lam4J_QVM1m9z.9uzYX014COPlsM7PK79evm1k8xu.ewAv5.vv.9Jw4LYZD.bXB57vjTWQGdrt5E5LMEZlPVSyNiJyt7IjpcTh2XEiyTGa2GQmhXQGJ.x4eC6xOUws5Tv6ln2k0g19in_LU6vTkDUfhy X-Yahoo-Newman-Property: ymail-3 Message-ID: <493C58C7.1010405@netconfcentral.com> Date: Sun, 07 Dec 2008 15:14:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493C4210.8070504@netconfcentral.com> <20081207.224908.252617370.mbj@tail-f.com> <493C535B.5050903@netconfcentral.com> <20081208.000432.86896353.mbj@tail-f.com> In-Reply-To: <20081208.000432.86896353.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I only saw 2 emails, and I do object to this CLR: >> >> refine a/b/c { >> mandatory false; >> } >> >> refine a/b/c { >> description "leaf c constrained as follows..."; >> } >> >> This should not be an error. > > [...] > >> I realize this is a stretch, but why have a CLR if the >> practice being forbidden by the rule does not really >> hurt anything? > > The rules that define this "merging" behavior will be non-trivial. Is > it really worth it? They are trivial -- just a sentence that says that no matter how many refinement-stmts are entered that refer to the same target object within the grouping, each sub-statement may only be entered at most once. The ABNF cannot express it either way. > > And the use case you mentioned - tools have the lowest priority, and > the code in the tool that generates the refine can do the merging > itself. > What if it is a human and not a tool? The compiler can be clever and merge the refine clauses. IMO, in general, it is always a bad idea to force implementations to generate errors for things that are not problems. (I object to MUST NOT instead of SHOULD NOT). > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 17:26:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C093A6925; Sun, 7 Dec 2008 17:26:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F243A696D for ; Sun, 7 Dec 2008 17:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_20=-0.74, 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 pJDyze5pCCuN for ; Sun, 7 Dec 2008 17:26:18 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id DC4433A6925 for ; Sun, 7 Dec 2008 17:26:17 -0800 (PST) Received: (qmail 38623 invoked from network); 8 Dec 2008 01:26:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 8 Dec 2008 01:26:09 -0000 X-YMail-OSG: HxT9AnYVM1lxeDiLbcHRNKBd87xOskngc1WFEBso_6EIU4Gxitk6GRyqq7Mdn3.2IuOlT9SPRRuvMhE2GdjqTDG9EpS8._Avi9jGrUnWpbhgTWyV9Z5f.nTNfI7kr6FhwyA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493C77B0.3080203@netconfcentral.com> Date: Sun, 07 Dec 2008 17:26:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] 7.18.1 example X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The if-feature example on pg. 97 is very nice but the 'local-storage-limit' leaf is missing a type. I know the examples are not meant to be complete, but it would be nice if there was one to remind people that leafs always need a type-stmt. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 17:57:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FC63A691C; Sun, 7 Dec 2008 17:57:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381A13A69E9 for ; Sun, 7 Dec 2008 17:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.103, 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 kAfoBIrgYCFU for ; Sun, 7 Dec 2008 17:57:17 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 99A093A691C for ; Sun, 7 Dec 2008 17:57:17 -0800 (PST) Received: (qmail 62657 invoked from network); 8 Dec 2008 01:57:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 8 Dec 2008 01:57:10 -0000 X-YMail-OSG: 2OQNQlsVM1kaQuinu_GD_xHrcZFhDvt9MfwTH2u.IJllwWzsyoDn0K0KsDzPqd1hy5PmKgYMwAqRj5LOSHk8Dz7kyT1Ymuxfr6PaXCgkivE6wlJwZ55Ie744G_Id_pVA.h8TBEuUQYAKgpUyCpvqKK6FpxvnOHCvmFN2NeAcS0NI8ASXvOhPRZVvk0S_K7ZsTssKXQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493C7EF5.50804@netconfcentral.com> Date: Sun, 07 Dec 2008 17:57:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, 5.9.4: The encoding examples are pretty weak and confusing. Perhaps they could match examples later in the draft. 7.18.3, para 5: However in some cases the cost of following the standard is heavy and the payoff may be small. I suggest removing this sentence before the IESG sees it. Including this mechanism is bad enough -- there is no need to explore the motivations of the vendors who use it. 7.18.3.1: Why isn't there any status-stmt (just description and reference)? General: There is very little discussion of how these deviations are managed. The target platform(s) associated with the deviations are completely left out of the data model. It is expected that a vendor will create a different module name for each set of deviations. All deviations within a module are assumed to apply to all platforms that 'support' the module. I strongly suggest adding a standard way to associate vendor platform identifier(s) (URI leaf-list?) with a set of deviations, instead of magically figuring it out from the module name. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 23:36:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579B13A67FB; Sun, 7 Dec 2008 23:36:01 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5963A6935 for ; Sun, 7 Dec 2008 23:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 sxidb0S-U09w for ; Sun, 7 Dec 2008 23:36:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3DD5C3A67FB for ; Sun, 7 Dec 2008 23:36:00 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C328476C50A; Mon, 8 Dec 2008 08:35:53 +0100 (CET) Date: Mon, 08 Dec 2008 08:35:53 +0100 (CET) Message-Id: <20081208.083553.115798085.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493C58C7.1010405@netconfcentral.com> References: <493C535B.5050903@netconfcentral.com> <20081208.000432.86896353.mbj@tail-f.com> <493C58C7.1010405@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I only saw 2 emails, and I do object to this CLR: > >> > >> refine a/b/c { > >> mandatory false; > >> } > >> > >> refine a/b/c { > >> description "leaf c constrained as follows..."; > >> } > >> > >> This should not be an error. > > [...] > > > >> I realize this is a stretch, but why have a CLR if the > >> practice being forbidden by the rule does not really > >> hurt anything? > > The rules that define this "merging" behavior will be non-trivial. Is > > it really worth it? > > They are trivial -- just a sentence that says that no matter > how many refinement-stmts are entered that refer to the same > target object within the grouping, each sub-statement may > only be entered at most once. So this is illegal by your rule: refine a/b { must ". > ../c"; must ". > ../d"; } Whatabout: refine a/b { config false; } refine a/b { config false; } And whatabout must: refine a/b { must ". > ../c"; } refine a/b { must ". > ../d"; } > > And the use case you mentioned - tools have the lowest priority, and > > the code in the tool that generates the refine can do the merging > > itself. > > > > What if it is a human and not a tool? > > The compiler can be clever and merge the refine clauses. > > IMO, in general, it is always a bad idea to force implementations > to generate errors for things that are not problems. Sure, but I think that this is a problem... This merging is imo confusing. So why don't we this merging for other statements as well? Why isn't this ok: leaf a { type int32; } leaf a { deafult 42; } Or at least this should be ok? leaf a { type int32; } leaf a { type int32; } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 7 23:36:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0F23A67A3; Sun, 7 Dec 2008 23:36:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2543A67FB for ; Sun, 7 Dec 2008 23:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] 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 uQ+MX-Muoptk for ; Sun, 7 Dec 2008 23:36:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F3CC13A67A3 for ; Sun, 7 Dec 2008 23:36:19 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9690C76C50A; Mon, 8 Dec 2008 08:36:14 +0100 (CET) Date: Mon, 08 Dec 2008 08:36:14 +0100 (CET) Message-Id: <20081208.083614.127585147.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493C77B0.3080203@netconfcentral.com> References: <493C77B0.3080203@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] 7.18.1 example X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > The if-feature example on pg. 97 is very nice but > the 'local-storage-limit' leaf is missing a type. Fixed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 8 01:43:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924A428C0E7; Mon, 8 Dec 2008 01:43:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5669428C0E8 for ; Mon, 8 Dec 2008 01:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.098, 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 BtqdKwrpXUrv for ; Mon, 8 Dec 2008 01:43:28 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id AAA6C28C0E7 for ; Mon, 8 Dec 2008 01:43:28 -0800 (PST) Received: (qmail 78851 invoked from network); 8 Dec 2008 09:43:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 8 Dec 2008 09:43:21 -0000 X-YMail-OSG: 8.bqaIUVM1nkapon1bXA8Sz_94xinnEP2cOzy4VTQRnbUBxc4M5y0qAWg_L_wDxqPnqYQq6Ggzwx5w52rwq5EJLJbK4iOomSxDjwTC2XmzS1R2qkDvc7PC3Wk_GplVJvdUITicY8ZTGj_ic7GNW_5M2C X-Yahoo-Newman-Property: ymail-3 Message-ID: <493CEC37.1000507@netconfcentral.com> Date: Mon, 08 Dec 2008 01:43:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493C535B.5050903@netconfcentral.com> <20081208.000432.86896353.mbj@tail-f.com> <493C58C7.1010405@netconfcentral.com> <20081208.083553.115798085.mbj@tail-f.com> In-Reply-To: <20081208.083553.115798085.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> I only saw 2 emails, and I do object to this CLR: >>>> >>>> refine a/b/c { >>>> mandatory false; >>>> } >>>> >>>> refine a/b/c { >>>> description "leaf c constrained as follows..."; >>>> } >>>> >>>> This should not be an error. >>> [...] >>> >>>> I realize this is a stretch, but why have a CLR if the >>>> practice being forbidden by the rule does not really >>>> hurt anything? >>> The rules that define this "merging" behavior will be non-trivial. Is >>> it really worth it? >> They are trivial -- just a sentence that says that no matter >> how many refinement-stmts are entered that refer to the same >> target object within the grouping, each sub-statement may >> only be entered at most once. > > So this is illegal by your rule: > no because this rule is *(must-stmt) and N are allowed > refine a/b { > must ". > ../c"; > must ". > ../d"; > } > > Whatabout: > > refine a/b { > config false; > } > refine a/b { > config false; > } > this is an error. Any duplicate sub-clause that is [sub-clause] ABNF. > And whatabout must: > > refine a/b { > must ". > ../c"; > } > refine a/b { > must ". > ../d"; > } > > > >>> And the use case you mentioned - tools have the lowest priority, and >>> the code in the tool that generates the refine can do the merging >>> itself. >>> >> What if it is a human and not a tool? >> >> The compiler can be clever and merge the refine clauses. >> >> IMO, in general, it is always a bad idea to force implementations >> to generate errors for things that are not problems. > > Sure, but I think that this is a problem... This merging is imo > confusing. > > So why don't we this merging for other statements as well? Why isn't > this ok: > > leaf a { > type int32; > } > leaf a { > deafult 42; > } > The refine-stmt and augment-stmt are consistent now. The augment-stmt does not have this CLR. The leaf-stmt does not have an XPath target. Obviously, 2 'leaf a' statements are an error. This has nothing to do with refine-stmt. > Or at least this should be ok? > > leaf a { > type int32; > } > leaf a { > type int32; > } > > What does this have to do with the refine-stmt sub-clause of uses-stmt? > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 8 01:58:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC153A6953; Mon, 8 Dec 2008 01:58:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B196B3A6A7B for ; Mon, 8 Dec 2008 01:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 65acWV6h4veo for ; Mon, 8 Dec 2008 01:58:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E51ED3A6A63 for ; Mon, 8 Dec 2008 01:58:36 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A4DBE76C50A; Mon, 8 Dec 2008 10:58:30 +0100 (CET) Date: Mon, 08 Dec 2008 10:58:30 +0100 (CET) Message-Id: <20081208.105830.93742655.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493CEC37.1000507@netconfcentral.com> References: <493C58C7.1010405@netconfcentral.com> <20081208.083553.115798085.mbj@tail-f.com> <493CEC37.1000507@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> I only saw 2 emails, and I do object to this CLR: > >>>> > >>>> refine a/b/c { > >>>> mandatory false; > >>>> } > >>>> > >>>> refine a/b/c { > >>>> description "leaf c constrained as follows..."; > >>>> } > >>>> > >>>> This should not be an error. > >>> [...] > >>> > >>>> I realize this is a stretch, but why have a CLR if the > >>>> practice being forbidden by the rule does not really > >>>> hurt anything? > >>> The rules that define this "merging" behavior will be non-trivial. Is > >>> it really worth it? > >> They are trivial -- just a sentence that says that no matter > >> how many refinement-stmts are entered that refer to the same > >> target object within the grouping, each sub-statement may > >> only be entered at most once. > > So this is illegal by your rule: > > > > no because this rule is *(must-stmt) and N are allowed Your rule says "each sub-statement may only be entered at most once". 'must' is a sub-statement, and thus may only be entered at most once according to your rule. This is why I said that a trivial rule like yours won't work. > The refine-stmt and augment-stmt are consistent now. > The augment-stmt does not have this CLR. Augment behaves in another way. Each augment adds a block of child nodes to the target node. The child nodes to add MUST NOT exist in the target node. But refine modifies properties, and you're saying that a property can be changed once, but not twice. Seems like an arbitrary rule. I think we can end this discussion here. You and I obviously have differing opinion on this issue. Does anyone else have an opinion? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 8 02:08:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACD83A67CC; Mon, 8 Dec 2008 02:08:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A42E3A67CC for ; Mon, 8 Dec 2008 02:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, 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 UW0SFlFKH9pI for ; Mon, 8 Dec 2008 02:08:28 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id BFAA93A69ED for ; Mon, 8 Dec 2008 02:08:28 -0800 (PST) Received: (qmail 88158 invoked from network); 8 Dec 2008 10:08:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 8 Dec 2008 10:08:21 -0000 X-YMail-OSG: alwy6jwVM1kqYUap7upfXQk45up0RSz.tU_ptoB2cwKtMm2tqFmjyuhwyN1zB1GA02sECLGmXaVxM1hywnr59nXubj_f5u3p3x_BueygslQ9505oB1Dv0lO97lpG6REUklIIBuUhFyQlCcHFLCG7F_0L X-Yahoo-Newman-Property: ymail-3 Message-ID: <493CF213.8050904@netconfcentral.com> Date: Mon, 08 Dec 2008 02:08:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493C58C7.1010405@netconfcentral.com> <20081208.083553.115798085.mbj@tail-f.com> <493CEC37.1000507@netconfcentral.com> <20081208.105830.93742655.mbj@tail-f.com> In-Reply-To: <20081208.105830.93742655.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>>>> I only saw 2 emails, and I do object to this CLR: >>>>>> >>>>>> refine a/b/c { >>>>>> mandatory false; >>>>>> } >>>>>> >>>>>> refine a/b/c { >>>>>> description "leaf c constrained as follows..."; >>>>>> } >>>>>> >>>>>> This should not be an error. >>>>> [...] >>>>> >>>>>> I realize this is a stretch, but why have a CLR if the >>>>>> practice being forbidden by the rule does not really >>>>>> hurt anything? >>>>> The rules that define this "merging" behavior will be non-trivial. Is >>>>> it really worth it? >>>> They are trivial -- just a sentence that says that no matter >>>> how many refinement-stmts are entered that refer to the same >>>> target object within the grouping, each sub-statement may >>>> only be entered at most once. >>> So this is illegal by your rule: >>> >> no because this rule is *(must-stmt) and N are allowed > > Your rule says "each sub-statement may only be entered at most once". > 'must' is a sub-statement, and thus may only be entered at most once > according to your rule. > > This is why I said that a trivial rule like yours won't work. > Add 3 words to previous simple sentence (except the must-stmt). > >> The refine-stmt and augment-stmt are consistent now. >> The augment-stmt does not have this CLR. > > Augment behaves in another way. Each augment adds a block of child > nodes to the target node. The child nodes to add MUST NOT exist in > the target node. But refine modifies properties, and you're saying > that a property can be changed once, but not twice. Seems like an > arbitrary rule. No, changing 'leaf foo' to 'refine leaf foo' was arbitrary. The point of that exercise was to make the refinements look just like the augments. uses foo { augment a/b/c { leaf x { type string; } } augment a/b/c { leaf y { type string; } } } This is legal YANG. It would be confusing to treat refine-stmt as an error if it did the same sort of thing. > > I think we can end this discussion here. You and I obviously have > differing opinion on this issue. Does anyone else have an opinion? > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 8 02:52:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56AF93A67CC; Mon, 8 Dec 2008 02:52:21 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E0228C0EE for ; Mon, 8 Dec 2008 02:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.089, 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 a65PccWfdGjo for ; Mon, 8 Dec 2008 02:52:19 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 82A053A67CC for ; Mon, 8 Dec 2008 02:52:19 -0800 (PST) Received: (qmail 78355 invoked from network); 8 Dec 2008 10:52:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 8 Dec 2008 10:52:12 -0000 X-YMail-OSG: ealc9XIVM1kU.TQeJEQecJ_40d4arUCOIv4et_3wVgRkfNsnZWwEVWkDlNn6o76LlOze6TaMQWhbHy4RYbDbdX4r0eGGoPsK91Iduo1taUpVjq_mW54jTdHSsCqy1TdKx4Y- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493CFC5B.2000806@netconfcentral.com> Date: Mon, 08 Dec 2008 02:52:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] must-stmt in a refinement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, What are the use-cases for allowing must-stmt within a refinement? This clause is not like all the others that can be refined, because it does not refine the must expression conditional, but simply adds additional AND sub-expressions. The must-stmt does not have a name. There is no way to say "replace that must rule with this one". IMO, this is also a way to 'break the contract' that the original data object defined. The must-stmt should be part of the deviations, not part of the refinements. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 8 06:56:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C26E3A684C; Mon, 8 Dec 2008 06:56:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3DD3A696C for ; Mon, 8 Dec 2008 06:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 69YVaHuaB6ya for ; Mon, 8 Dec 2008 06:55:58 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 13FBE3A684C for ; Mon, 8 Dec 2008 06:55:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKST01cHSHe+mYajYiBLO7S4FaEejyQzEb@postini.com; Mon, 08 Dec 2008 06:55:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 8 Dec 2008 06:53:35 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 06:53:35 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 06:53:35 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 06:53:35 -0800 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 mB8ErYM66640; Mon, 8 Dec 2008 06:53:34 -0800 (PST) (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 mB8EmCkV089343; Mon, 8 Dec 2008 14:48:13 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812081448.mB8EmCkV089343@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081207.154945.183905838.mbj@tail-f.com> Date: Mon, 8 Dec 2008 09:48:12 -0500 From: Phil Shafer X-OriginalArrivalTime: 08 Dec 2008 14:53:35.0039 (UTC) FILETIME=[BECAF4F0:01C95944] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] refinement-stmt ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >There's no obvious solution... We could state in the text that at >least one refinement sub statement must be present. It does not seem >right to allow "refine a/b/c;" since it doesn't really mean anything. For tools that generate YANG from other content (like our internal DDL), it is always nice to not have to sweat these "at least one" requirements. In this case, the expense is minimal (since you wouldn't even start a "refine" without planning content), but in general, allowing empty substatements is a help to YANG generators. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 8 11:17:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8173A679F; Mon, 8 Dec 2008 11:17:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951613A6933 for ; Mon, 8 Dec 2008 11:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.072, 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 pbYvFxPTB10x for ; Mon, 8 Dec 2008 11:17:31 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id C5DC83A679F for ; Mon, 8 Dec 2008 11:17:31 -0800 (PST) Received: (qmail 68103 invoked from network); 8 Dec 2008 19:17:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 8 Dec 2008 19:17:24 -0000 X-YMail-OSG: d7.Ua6cVM1l1_1_1sVq48WSyWvdhloEo57gBF8fJ0vnp8yFpeKFZE.xteo42gwtzREpptssNL1aDMcjfj3Re8Tgzt1B8qIE4BxlO9Gdn.14u1zybXBAElI3PW7xBX3S8nRk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493D72C3.2070502@netconfcentral.com> Date: Mon, 08 Dec 2008 11:17:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] identityref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, sec. 9.10.3 has an editors note: how to handle prefixes? IMO, we just follow the XML 'expanded name' example, and declare that the canonical form for an identityref value within an XML instance document does not have a fixed prefix. It must be evaluated according to XML. (We do not officially care about representations other than XML.) It should be more clear in 9.10.3 that the prefix in the QName content is an XML prefix associated with the XML Namespace (which has the same value as the module 'namespace-stmt'). It is NOT the module prefix. There is no module name or namespace-stmt in the example in 9.10.4, so the reader really has no clue that is where the particular xmlns value came from. The prefix is for the namespace URI of the module that contains the 'des3' identity, which may be different than the namespace for the 'crypto' leaf itself. (That's obvious in the example to people who really know XML, but stating in text might help as well.) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 9 09:58:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4383A68C5; Tue, 9 Dec 2008 09:58:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1444E3A68C5 for ; Tue, 9 Dec 2008 09:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.069, 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 g6GR20TXlzWn for ; Tue, 9 Dec 2008 09:58:40 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 749823A6967 for ; Tue, 9 Dec 2008 09:58:39 -0800 (PST) Received: (qmail 20053 invoked from network); 9 Dec 2008 17:58:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.99.53 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 9 Dec 2008 17:58:31 -0000 X-YMail-OSG: OvbyBBgVM1kupxWOGpdc1JZuBFG8vOs9_paBkaeMD.L0LsCTMNMb3TZqSn0tBtdPFiDi95YyGoCuZWjxFht2z2z68H2Wel9wRZvh39YxjzByl6YsRocXLZ6BdKywIzGRFx0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <493EB1C6.8090707@netconfcentral.com> Date: Tue, 09 Dec 2008 09:58:30 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group References: <493D72C3.2070502@netconfcentral.com> In-Reply-To: <493D72C3.2070502@netconfcentral.com> Subject: Re: [netmod] identityref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > sec. 9.10.3 has an editors note: how to handle prefixes? > > IMO, we just follow the XML 'expanded name' example, > and declare that the canonical form for an identityref > value within an XML instance document does not have a fixed prefix. > It must be evaluated according to XML. > > (We do not officially care about representations other than XML.) > > It should be more clear in 9.10.3 that the prefix > in the QName content is an XML prefix associated with > the XML Namespace (which has the same value as the > module 'namespace-stmt'). It is NOT the module prefix. > > There is no module name or namespace-stmt in the example in 9.10.4, > so the reader really has no clue that is where the particular > xmlns value came from. > > The prefix is for the namespace URI of the module > that contains the 'des3' identity, which may be different than > the namespace for the 'crypto' leaf itself. > > (That's obvious in the example to people who really know XML, > but stating in text might help as well.) > > Some more details for the identityref section on the not so obvious 'default-stmt' for an identityref leaf or leaf-list: module foo { namespace "foo-ns"; prefix foo; import "crypto-base" { prefix "crypto"; } import des { prefix des; } identity my-des3 { base "des:des3"; } leaf crypto { type identityref { base "crypto:crypto-alg"; } default "des:des"; } leaf crypto2 { type identityref { base "crypto:crypto-alg"; } default "my-des3"; } } In a YANG module, the identityref prefix is a module prefix, not an XML prefix. (No prefix means the local module.) I really like the extensibility and distributed tree design of the identityref. (Thanks Juergen!) The only problem is that the canonical form depends on the context in which it appears. Text config files are out of scope, which is good. Since module prefixes are not required to be unique, yet another format might be needed for that. Only CLR: the canonical form(s) MUST have a prefix. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 10 14:42:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62223A6944; Wed, 10 Dec 2008 14:42:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AEB3A6973 for ; Wed, 10 Dec 2008 14:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6] 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 ru44RGiD-tPf for ; Wed, 10 Dec 2008 14:42:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7E2863A6944 for ; Wed, 10 Dec 2008 14:42:25 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DF0076C50A for ; Wed, 10 Dec 2008 23:42:18 +0100 (CET) Date: Wed, 10 Dec 2008 23:42:17 +0100 (CET) Message-Id: <20081210.234217.140956221.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, In Minneapolis we talked about the canonical form of some data types. It seems consensus was to try to find a way to formally specify the canonical form. In some hallway discussions, we talked about the following idea. First, an observation. The need to specify a canonical form is typically needed when the type is a string with pattern restrictions. For example, ipv6 address, domain name. Another observation is that both XSD and RNG allows multiple patterns. In XSD, the patterns are OR:ed and in RNG they are AND:ed. It is straightforward to map between these forms. Suppose there are two patterns, and . If they are OR:ed, a single pattern (|) can be used. If they are AND:ed, an extra type with a single pattern can be introduced, and derived from while adding the pattern . In YANG we first allowed a single pattern only (since both forms can be done with a single pattern and type chains), and later we chose to AND multiple pattern, just like RNG. The idea we discussed for the canonical form is to change the rules so that multiple patterns are OR:ed, and introduce a statement 'canonical true' which can be specificed on one of the patterns. Example: typedef ipv6-address { type string { pattern /* full */ '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' + '(%[\p{N}\p{L}]+)?)' { canonical true; } pattern /* mixed */ + '((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + '(%[\p{N}\p{L}]+)?)'; pattern /* shortened */ + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' + '(%[\p{N}\p{L}]+)?)'; pattern /* shortened mixed */ + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + '(%[\p{N}\p{L}]+)?)'; } } typedef domain-name { type string { pattern '([a-z0-9][a-z0-9\-]*[a-z0-9]\.)*' + '[a-z0-9][a-z0-9\-]*[a-z0-9]' { // lower case canonical true; } pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 10 15:04:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C173A683D; Wed, 10 Dec 2008 15:04:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ED928C180 for ; Wed, 10 Dec 2008 15:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6] 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 E-L90nThlyqN for ; Wed, 10 Dec 2008 15:04:28 -0800 (PST) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id B90A53A683D for ; Wed, 10 Dec 2008 15:04:28 -0800 (PST) Received: (qmail 25961 invoked from network); 10 Dec 2008 23:04:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.196 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2008 23:04:21 -0000 X-YMail-OSG: 5Ywme.EVM1lzybLbZ9QJNzPeTax6FHUBb7hlOHV0_kqB9bE4OWJBBULsnj6mEYtPBfIV5BsH3.nsjIQJHM794iffL4kZ3P0i.oooAcQooVysV5GFZ2zDIclnGn1bhWUF.abo50V9tqSMP1tSqbtfsFVE X-Yahoo-Newman-Property: ymail-3 Message-ID: <49404AF3.9080406@netconfcentral.com> Date: Wed, 10 Dec 2008 15:04:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081210.234217.140956221.mbj@tail-f.com> In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > In Minneapolis we talked about the canonical form of some data types. > It seems consensus was to try to find a way to formally specify the > canonical form. In some hallway discussions, we talked about the > following idea. > > First, an observation. The need to specify a canonical form is > typically needed when the type is a string with pattern restrictions. > For example, ipv6 address, domain name. > > Another observation is that both XSD and RNG allows multiple > patterns. In XSD, the patterns are OR:ed and in RNG they are > AND:ed. It is straightforward to map between these forms. Suppose > there are two patterns, and . If they are OR:ed, a single > pattern (|) can be used. If they are AND:ed, an extra type with > a single pattern can be introduced, and derived from while adding > the pattern . > > In YANG we first allowed a single pattern only (since both forms can > be done with a single pattern and type chains), and later we chose to > AND multiple pattern, just like RNG. > > The idea we discussed for the canonical form is to change the rules so > that multiple patterns are OR:ed, and introduce a statement 'canonical > true' which can be specificed on one of the patterns. > We cannot go back to OR-ing the patterns, as per XSD. We changed it to AND-ing the patterns because RelaxNG does it that way. Although elegant, the solution below will not work with RelaxNG. Andy > Example: > > typedef ipv6-address { > type string { > pattern > /* full */ > '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' > + '(%[\p{N}\p{L}]+)?)' { > canonical true; > } > pattern > /* mixed */ > + '((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' > + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' > + '(%[\p{N}\p{L}]+)?)'; > pattern > /* shortened */ > + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' > + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' > + '(%[\p{N}\p{L}]+)?)'; > pattern > /* shortened mixed */ > + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' > + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' > + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' > + '(%[\p{N}\p{L}]+)?)'; > } > } > > typedef domain-name { > type string { > pattern '([a-z0-9][a-z0-9\-]*[a-z0-9]\.)*' > + '[a-z0-9][a-z0-9\-]*[a-z0-9]' { > // lower case > canonical true; > } > pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' > + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; > } > } > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 10 15:14:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEC83A68AD; Wed, 10 Dec 2008 15:14:25 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B27F3A69DC for ; Wed, 10 Dec 2008 15:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6] 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 yhInr1j4hoRM for ; Wed, 10 Dec 2008 15:14:24 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 973613A68AD for ; Wed, 10 Dec 2008 15:14:24 -0800 (PST) Received: (qmail 17826 invoked from network); 10 Dec 2008 23:14:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.196 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 10 Dec 2008 23:14:16 -0000 X-YMail-OSG: bQCSGKEVM1kryIz8KfTfVwVdjZFijQ0zqOieGz6pTaUQ9ni1nvYddJmoaQuSNbpjwWTu4bOcYxhrjvMZ2CW9vBwPtksgkCZ6u5DmkBPB6.ucJpuhwVgW4vvsUOKhjN5NG_jI8nDxPiQSjURZgLZvnNWT X-Yahoo-Newman-Property: ymail-3 Message-ID: <49404D47.4040700@netconfcentral.com> Date: Wed, 10 Dec 2008 15:14:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081210.234217.140956221.mbj@tail-f.com> In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > In Minneapolis we talked about the canonical form of some data types. > It seems consensus was to try to find a way to formally specify the > canonical form. In some hallway discussions, we talked about the > following idea. > > First, an observation. The need to specify a canonical form is > typically needed when the type is a string with pattern restrictions. > For example, ipv6 address, domain name. > > Another observation is that both XSD and RNG allows multiple > patterns. In XSD, the patterns are OR:ed and in RNG they are > AND:ed. It is straightforward to map between these forms. Suppose > there are two patterns, and . If they are OR:ed, a single > pattern (|) can be used. If they are AND:ed, an extra type with > a single pattern can be introduced, and derived from while adding > the pattern . > > In YANG we first allowed a single pattern only (since both forms can > be done with a single pattern and type chains), and later we chose to > AND multiple pattern, just like RNG. > > The idea we discussed for the canonical form is to change the rules so > that multiple patterns are OR:ed, and introduce a statement 'canonical > true' which can be specificed on one of the patterns. > > Example: > How about a new statement called 'canonical-pattern' that is not used along with all the other AND-ed patterns? In fact, it really is not used in NETCONF PDUs at all. It is available on the side for applications to check if a value has the canonical form. typedef domain-name { type string { canonical-pattern '([a-z0-9][a-z0-9\-]*[a-z0-9]\.)*' + '[a-z0-9][a-z0-9\-]*[a-z0-9]'; pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; } } Andy > typedef ipv6-address { > type string { > pattern > /* full */ > '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' > + '(%[\p{N}\p{L}]+)?)' { > canonical true; > } > pattern > /* mixed */ > + '((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' > + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' > + '(%[\p{N}\p{L}]+)?)'; > pattern > /* shortened */ > + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' > + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' > + '(%[\p{N}\p{L}]+)?)'; > pattern > /* shortened mixed */ > + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' > + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' > + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' > + '(%[\p{N}\p{L}]+)?)'; > } > } > > typedef domain-name { > type string { > pattern '([a-z0-9][a-z0-9\-]*[a-z0-9]\.)*' > + '[a-z0-9][a-z0-9\-]*[a-z0-9]' { > // lower case > canonical true; > } > pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' > + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; > } > } > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 10 22:50:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D523A69FA; Wed, 10 Dec 2008 22:50:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D394F3A6A2F for ; Wed, 10 Dec 2008 22:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 ERhPDVPle4LN for ; Wed, 10 Dec 2008 22:50:47 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 22A983A69FA for ; Wed, 10 Dec 2008 22:50:47 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AE620D800C0; Thu, 11 Dec 2008 07:50:38 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49404AF3.9080406@netconfcentral.com> References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> Organization: CESNET Date: Thu, 11 Dec 2008 07:50:38 +0100 Message-Id: <1228978238.27811.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDEwLiAxMi4gMjAwOCB2IDE1OjA0IC0wODAwOgoKPiAK PiBXZSBjYW5ub3QgZ28gYmFjayB0byBPUi1pbmcgdGhlIHBhdHRlcm5zLCBhcyBwZXIgWFNELgo+ IFdlIGNoYW5nZWQgaXQgdG8gQU5ELWluZyB0aGUgcGF0dGVybnMgYmVjYXVzZSBSZWxheE5HIGRv ZXMgaXQKPiB0aGF0IHdheS4gIEFsdGhvdWdoIGVsZWdhbnQsIHRoZSBzb2x1dGlvbiBiZWxvdyB3 aWxsIG5vdCB3b3JrCj4gd2l0aCBSZWxheE5HLgo+IAoKKzEuIFdlIGhhdmVuJ3QgZm91bmQgYSBy ZWFsbHkgc2F0aXNmYWN0b3J5IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIG9mCmNhbm9uaWNhbCBm b3JtIHlldCwgc28gSSB0aGluayBpdCBpcyBub3Qgd2lzZSB0byBpbmR1Y2UgY2hhbmdlcyB0byBv dGhlcgpwYXJ0cyBvZiBZQU5HIHdoZXJlIGNvbnNlbnN1cyBoYXMgYmVlbiByZWFjaGVkLgoKSSBz dGlsbCBwcmVmZXIgYSBtb3JlIGxpZ2h0d2VpZ2h0IHNvbHV0aW9uIChzcGVjaWFsIGRlc2NyaXB0 aW9uKSBhcyBhbgppbnRlcmltIG1lYXN1cmUgZm9yIFlBTkcgMS4wLgoKTGFkYQoKLS0gCkxhZGlz bGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Dec 10 23:20:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D1B3A6874; Wed, 10 Dec 2008 23:20:11 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D7C3A68B2 for ; Wed, 10 Dec 2008 23:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 o9n5bAsref6D for ; Wed, 10 Dec 2008 23:20:10 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EA3243A6874 for ; Wed, 10 Dec 2008 23:20:09 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D4F4FD800C0 for ; Thu, 11 Dec 2008 08:20:03 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> References: <20081210.234217.140956221.mbj@tail-f.com> Organization: CESNET Date: Thu, 11 Dec 2008 08:20:03 +0100 Message-Id: <1228980003.27811.28.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxMC4gMTIuIDIwMDggdiAyMzo0MiArMDEwMDoK PiBGaXJzdCwgYW4gb2JzZXJ2YXRpb24uICBUaGUgbmVlZCB0byBzcGVjaWZ5IGEgY2Fub25pY2Fs IGZvcm0gaXMKPiB0eXBpY2FsbHkgbmVlZGVkIHdoZW4gdGhlIHR5cGUgaXMgYSBzdHJpbmcgd2l0 aCBwYXR0ZXJuIHJlc3RyaWN0aW9ucy4KPiBGb3IgZXhhbXBsZSwgaXB2NiBhZGRyZXNzLCBkb21h aW4gbmFtZS4KPiAKSSBkb24ndCB0aGluayB0aGlzIGlzIHRydWUuIFdlIGhhdmUgZGlzY3Vzc2Vk IHRoZSBwcm9ibGVtIG9mICIzIiB2ZXJzdXMKIiszIiBhbmQsIGluIGZhY3QsIGZvciBJUCBhZGRy ZXNzZXMgYWxsIHRoZSBkaWZmZXJlbnQgbGV4aWNhbCBmb3JtcyBjb21lCmRvd24gdG8gYW4gMzIg b3IgMTI4LWJpdCBpbnRlZ2VyLiBJdCB3aWxsIGJlIHF1aXRlIGhhcmQgdG8gcG9zdHVsYXRlIGEK c2luZ2xlICJyaWdodCIgY2Fub25pY2FsIGZvcm0gZm9yIGFuIElQdjYgYWRkcmVzcy4KCkkgc29y dCBvZiBsaWtlIHRoZSBhcHByb2FjaCBvZiBEVExMLCB5ZXMsIGl0IHN0aWxsIGhhcyByb3VnaCBl ZGdlcywgdG9vLApidXQgYXQgbGVhc3QgaXMgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZXJlIGFyZSBv dGhlciBwb3NzaWJsZSBzb2x1dGlvbnMKb3V0IHRoZXJlLgoKTGFkYQoKCi0tIApMYWRpc2xhdiBM aG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Dec 10 23:41:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184EC3A6874; Wed, 10 Dec 2008 23:41:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE8B3A69F4 for ; Wed, 10 Dec 2008 23:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 5FSl9Ndh46wB for ; Wed, 10 Dec 2008 23:40:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 20CA53A6874 for ; Wed, 10 Dec 2008 23:40:58 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CE0FA76C310; Thu, 11 Dec 2008 08:40:51 +0100 (CET) Date: Thu, 11 Dec 2008 08:40:49 +0100 (CET) Message-Id: <20081211.084049.236479140.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1228978238.27811.10.camel@missotis> References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <1228978238.27811.10.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFN0IDEwLiAxMi4gMjAwOCB2IDE1OjA0IC0wODAwOg0KPiANCj4gPiANCj4gPiBX ZSBjYW5ub3QgZ28gYmFjayB0byBPUi1pbmcgdGhlIHBhdHRlcm5zLCBhcyBwZXIgWFNELg0KPiA+ IFdlIGNoYW5nZWQgaXQgdG8gQU5ELWluZyB0aGUgcGF0dGVybnMgYmVjYXVzZSBSZWxheE5HIGRv ZXMgaXQNCj4gPiB0aGF0IHdheS4gIEFsdGhvdWdoIGVsZWdhbnQsIHRoZSBzb2x1dGlvbiBiZWxv dyB3aWxsIG5vdCB3b3JrDQo+ID4gd2l0aCBSZWxheE5HLg0KPiA+IA0KDQpZZXMgaXQgd2lsbC4g ICBKdXN0IGxpa2UgdGhlIHNvbHV0aW9uIHdlIGhhdmUgdG9kYXkgd29ya3Mgd2l0aCBYU0QgLQ0K aXQgaXMgdXAgdG8gdGhlIHRvb2xzIHRvIHRyYW5zbGF0ZSBwcm9wZXJseS4NCg0KPiBJIHN0aWxs IHByZWZlciBhIG1vcmUgbGlnaHR3ZWlnaHQgc29sdXRpb24gKHNwZWNpYWwgZGVzY3JpcHRpb24p IGFzIGFuDQo+IGludGVyaW0gbWVhc3VyZSBmb3IgWUFORyAxLjAuDQoNClNvIGRvIEksIGJ1dCBt b3N0IHBlb3BsZSBhdCB0aGUgbWVldGluZyB3YW50ZWQgYSBmb3JtYWwgc3BlY2lmaWNhdGlvbi4N Cg0KDQovbWFydGluDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Dec 11 00:46:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732D13A67A3; Thu, 11 Dec 2008 00:46:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8370D3A67DF for ; Thu, 11 Dec 2008 00:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 zZtSsz6wilBB for ; Thu, 11 Dec 2008 00:46:23 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BF44D3A67A3 for ; Thu, 11 Dec 2008 00:46:23 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4099FD800C5; Thu, 11 Dec 2008 09:46:17 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081211.084049.236479140.mbj@tail-f.com> References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <1228978238.27811.10.camel@missotis> <20081211.084049.236479140.mbj@tail-f.com> Organization: CESNET Date: Thu, 11 Dec 2008 09:46:16 +0100 Message-Id: <1228985176.27811.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMTEuIDEyLiAyMDA4IHYgMDg6NDAgKzAxMDA6 Cj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToKPiA+IEFuZHkgQmll cm1hbiBww63FoWUgdiBTdCAxMC4gMTIuIDIwMDggdiAxNTowNCAtMDgwMDoKPiA+IAo+ID4gPiAK PiA+ID4gV2UgY2Fubm90IGdvIGJhY2sgdG8gT1ItaW5nIHRoZSBwYXR0ZXJucywgYXMgcGVyIFhT RC4KPiA+ID4gV2UgY2hhbmdlZCBpdCB0byBBTkQtaW5nIHRoZSBwYXR0ZXJucyBiZWNhdXNlIFJl bGF4TkcgZG9lcyBpdAo+ID4gPiB0aGF0IHdheS4gIEFsdGhvdWdoIGVsZWdhbnQsIHRoZSBzb2x1 dGlvbiBiZWxvdyB3aWxsIG5vdCB3b3JrCj4gPiA+IHdpdGggUmVsYXhORy4KPiA+ID4gCj4gCj4g WWVzIGl0IHdpbGwuICAgSnVzdCBsaWtlIHRoZSBzb2x1dGlvbiB3ZSBoYXZlIHRvZGF5IHdvcmtz IHdpdGggWFNEIC0KPiBpdCBpcyB1cCB0byB0aGUgdG9vbHMgdG8gdHJhbnNsYXRlIHByb3Blcmx5 LgoKTWF5YmUsIGJ1dCBpdCB3aWxsIGdldCB2ZXJ5IGNvbXBsaWNhdGVkIGluIFlBTkcgYW5kIGV2 ZW4gbW9yZSBzbyBpbgpSRUxBWCBORy4gVGhpbmsgYWJvdXQgY2FzZXMgbGlrZQoKUDEgb3IgKFAy IGFuZCBQMykKCndoZXJlIChQMiBhbmQgUDMpIGlzIHdoYXQgcmVwcmVzZW50cyB0aGUgY2Fub25p Y2FsIGZvcm0uCgo+IAo+ID4gSSBzdGlsbCBwcmVmZXIgYSBtb3JlIGxpZ2h0d2VpZ2h0IHNvbHV0 aW9uIChzcGVjaWFsIGRlc2NyaXB0aW9uKSBhcyBhbgo+ID4gaW50ZXJpbSBtZWFzdXJlIGZvciBZ QU5HIDEuMC4KPiAKPiBTbyBkbyBJLCBidXQgbW9zdCBwZW9wbGUgYXQgdGhlIG1lZXRpbmcgd2Fu dGVkIGEgZm9ybWFsIHNwZWNpZmljYXRpb24uCgpJcyB0aGVyZSBhbnkgcHJlc3NpbmcgbmVlZCB0 byBoYXZlIGl0IGluIFlBTkcgMS4wPyBNYW55IHBlb3BsZSB3aXNoIHRvCnN0b3AgdGhlIGZlYXR1 cml0aXMgYW5kIHRoaXMgaXMgbm90aGluZyBlbHNlLgoKSSB3aWxsIGJlIGhhcHB5IHRvIHdvcmsg b24gdGhpcyBhZnRlciBTZXB0ZW1iZXIgMDkgdGhvdWdoLgoKTGFkYQoKPiAKPiAKPiAvbWFydGlu Ci0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcg bGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QK From netmod-bounces@ietf.org Thu Dec 11 00:47:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899973A6A11; Thu, 11 Dec 2008 00:47:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6803A6A1E for ; Thu, 11 Dec 2008 00:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 COowuBQTTqa9 for ; Thu, 11 Dec 2008 00:47:13 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AF3ED3A6A11 for ; Thu, 11 Dec 2008 00:47:13 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C68BED800C0 for ; Thu, 11 Dec 2008 09:47:07 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> References: <20081210.234217.140956221.mbj@tail-f.com> Organization: CESNET Date: Thu, 11 Dec 2008 09:47:07 +0100 Message-Id: <1228985227.27811.66.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxMC4gMTIuIDIwMDggdiAyMzo0MiArMDEwMDoK PiAgICAgICAgIC8qIHNob3J0ZW5lZCAqLwo+ICAgICAgICAgKyAgJygoKFswLTlhLWZBLUZdezEs NH06KSooWzAtOWEtZkEtRl17MSw0fSkpKig6OiknCj4gICAgICAgICArICAgICcoKFswLTlhLWZB LUZdezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKicKPiAgICAgICAgICsgICAgJyglW1xwe059 XHB7TH1dKyk/KSc7CgpOb3RlIHRoYXQgdGhpcyBpcyBpbmNvcnJlY3Q6IFRoZSBzaG9ydGVuZWQg Zm9ybSBhbGxvd3MgdGhlIHBhcnRzIHRvIHRoZQpsZWZ0IGFuZCByaWdodCBvZiAnOjonIHRvIGJl IGFyYml0cmFyaWx5IGxvbmcuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQ IEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Dec 11 01:42:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C423A6A3A; Thu, 11 Dec 2008 01:42:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A6E3A6B34 for ; Thu, 11 Dec 2008 01:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6] 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 6QuY4LOwbC1o for ; Thu, 11 Dec 2008 01:42:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 60F193A6A3A for ; Thu, 11 Dec 2008 01:42:11 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B41DC00F8; Thu, 11 Dec 2008 10:42:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ri3yzvAPtJhp; Thu, 11 Dec 2008 10:41:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A192C00FC; Thu, 11 Dec 2008 10:41:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C77B18ACE51; Thu, 11 Dec 2008 10:41:57 +0100 (CET) Date: Thu, 11 Dec 2008 10:41:57 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20081211094157.GD27646@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20081210.234217.140956221.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Dec 10, 2008 at 11:42:17PM +0100, Martin Bjorklund wrote: > In Minneapolis we talked about the canonical form of some data types. > It seems consensus was to try to find a way to formally specify the > canonical form. In some hallway discussions, we talked about the > following idea. > > First, an observation. The need to specify a canonical form is > typically needed when the type is a string with pattern restrictions. > For example, ipv6 address, domain name. > > Another observation is that both XSD and RNG allows multiple > patterns. In XSD, the patterns are OR:ed and in RNG they are > AND:ed. It is straightforward to map between these forms. Suppose > there are two patterns, and . If they are OR:ed, a single > pattern (|) can be used. If they are AND:ed, an extra type with > a single pattern can be introduced, and derived from while adding > the pattern . > > In YANG we first allowed a single pattern only (since both forms can > be done with a single pattern and type chains), and later we chose to > AND multiple pattern, just like RNG. > > The idea we discussed for the canonical form is to change the rules so > that multiple patterns are OR:ed, and introduce a statement 'canonical > true' which can be specificed on one of the patterns. There were technical reasons to prefer ANDing of pattern and I do not think the need to define a canonical form does change any of these reasons. In other words, lets not make arbitrary changes to things we already sorted out. My preference at the moment is still to do nothing except adding clarifying text to the description clauses. If we want to create syntax, then we should do the following: typedef foo { type string; pattern "..."; pattern "..."; canonical { pattern "..."; pattern "..."; } } The canonical statement would actually create a derived type only allowing canonical formats, that is this is roughly equivalent to: typedef foo { type string; pattern "..."; pattern "..."; description "The canonical format is given by foo-c."; } typedef foo-c { type foo; pattern "..."; pattern "..."; } The only benefit of the canonical statement really is that the types are linked together in a machine readable format. So yet another version would be: typedef foo { type string; pattern "..."; pattern "..."; canonical foo-c; } typedef foo-c { type foo; pattern "..."; pattern "..."; } The nice aspect of this solution is that it is only one new keyword and everything else reuses YANG mechanisms. This approach might even be expanded to handle normalization of groupings or such things in case this ever becomes necessary. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 05:29:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85AC3A6C19; Thu, 11 Dec 2008 05:29:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D213A6C54 for ; Thu, 11 Dec 2008 05:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QRH7FurdE+XI for ; Thu, 11 Dec 2008 05:29:39 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id CDB073A6C19 for ; Thu, 11 Dec 2008 05:29:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSUEVtoJXTYZFd0SB/cy2lecACG27HNns@postini.com; Thu, 11 Dec 2008 05:29:33 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 11 Dec 2008 05:26:54 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 05:26:54 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 05:26:53 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 05:26:53 -0800 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 mBBDQqM46176; Thu, 11 Dec 2008 05:26:52 -0800 (PST) (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 mBBDLUrf014353; Thu, 11 Dec 2008 13:21:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812111321.mBBDLUrf014353@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> Date: Thu, 11 Dec 2008 08:21:30 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2008 13:26:53.0355 (UTC) FILETIME=[219637B0:01C95B94] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: > typedef domain-name { > type string { > pattern '([a-z0-9][a-z0-9\-]*[a-z0-9]\.)*' > + '[a-z0-9][a-z0-9\-]*[a-z0-9]' { > // lower case > canonical true; > } > pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' > + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; > } +1 I like the ORs and the explicit canonical statement. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 05:35:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1760B3A6A66; Thu, 11 Dec 2008 05:35:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1763528C1FB for ; Thu, 11 Dec 2008 05:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Ny9tMj6G+Geb for ; Thu, 11 Dec 2008 05:35:35 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 77DF43A6A66 for ; Thu, 11 Dec 2008 05:35:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSUEXHglE2yDalAP4Ni2mhaYR0yGndoXt@postini.com; Thu, 11 Dec 2008 05:35:29 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 11 Dec 2008 05:32:47 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 05:31:30 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 05:31:29 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 05:31:29 -0800 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 mBBDVSM49882; Thu, 11 Dec 2008 05:31:28 -0800 (PST) (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 mBBDQ6CO014407; Thu, 11 Dec 2008 13:26:06 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812111326.mBBDQ6CO014407@idle.juniper.net> To: Andy Bierman In-Reply-To: <49404AF3.9080406@netconfcentral.com> Date: Thu, 11 Dec 2008 08:26:06 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2008 13:31:29.0475 (UTC) FILETIME=[C62AC930:01C95B94] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >We cannot go back to OR-ing the patterns, as per XSD. >We changed it to AND-ing the patterns because RelaxNG does it >that way. Although elegant, the solution below will not work >with RelaxNG. I agree the proposed solution is elegant, but disagree about moving to ORs. The DSDL generation can translate ORs into whatever RNG needs (and in a much less painful way than we'll need to translate ANDs into XSD). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 05:58:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980EC3A6927; Thu, 11 Dec 2008 05:58:45 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECE13A6927 for ; Thu, 11 Dec 2008 05:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 fFASr+b+8LLs for ; Thu, 11 Dec 2008 05:58:43 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7AF2B3A68FC for ; Thu, 11 Dec 2008 05:58:43 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 08F03D800BD; Thu, 11 Dec 2008 14:58:32 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200812111326.mBBDQ6CO014407@idle.juniper.net> References: <200812111326.mBBDQ6CO014407@idle.juniper.net> Organization: CESNET Date: Thu, 11 Dec 2008 14:58:32 +0100 Message-Id: <1229003912.27811.102.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDExLiAxMi4gMjAwOCB2IDA4OjI2IC0wNTAwOgo+IEFu ZHkgQmllcm1hbiB3cml0ZXM6Cj4gPldlIGNhbm5vdCBnbyBiYWNrIHRvIE9SLWluZyB0aGUgcGF0 dGVybnMsIGFzIHBlciBYU0QuCj4gPldlIGNoYW5nZWQgaXQgdG8gQU5ELWluZyB0aGUgcGF0dGVy bnMgYmVjYXVzZSBSZWxheE5HIGRvZXMgaXQKPiA+dGhhdCB3YXkuICBBbHRob3VnaCBlbGVnYW50 LCB0aGUgc29sdXRpb24gYmVsb3cgd2lsbCBub3Qgd29yawo+ID53aXRoIFJlbGF4TkcuCj4gCj4g SSBhZ3JlZSB0aGUgcHJvcG9zZWQgc29sdXRpb24gaXMgZWxlZ2FudCwgYnV0IGRpc2FncmVlIGFi b3V0IG1vdmluZwoKV2VsbCwgaXQncyBqdXN0IGEgc2luZ2xlIGV4YW1wbGUgd2hpY2ggaXMgbW9y ZW92ZXIgYnJva2VuLiBTbyBsZXQncwpmaXJzdCBmaXggdGhlIElQdjYgcGF0dGVybnMgYW5kIHRo ZW4gZGlzY3VzcyBob3cgdGhlIGNhbm9uaWNhbCBmb3JtIGNhbgpiZSBzcGVjaWZpZWQgaW4gaXQu CgpBIGJldHRlciBkYXRhdHlwaW5nIGxhbmd1YWdlIGlzIGNsZWFybHkgbmVlZGVkIG5vdCBvbmx5 IGZvciBZQU5HLCBidXQKaXQncyBub3QgYSBsb3ctaGFuZ2luZyBmcnVpdCwgc28gSSB0aGluayBp dCdzIGJldHRlciB0byBjb25zaWRlciBpdApyZWFsbHkgY2FyZWZ1bGx5IGJlZm9yZSBpbXBsZW1l bnRpbmcgYW55dGhpbmcuIFRoaXMgaXMgSU1PIHRvcGljIGZvcgpZQU5HIDIuMC4KCj4gdG8gT1Jz LiAgVGhlIERTREwgZ2VuZXJhdGlvbiBjYW4gdHJhbnNsYXRlIE9ScyBpbnRvIHdoYXRldmVyIFJO Rwo+IG5lZWRzIChhbmQgaW4gYSBtdWNoIGxlc3MgcGFpbmZ1bCB3YXkgdGhhbiB3ZSdsbCBuZWVk IHRvIHRyYW5zbGF0ZQo+IEFORHMgaW50byBYU0QpLgoKSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBj aGFuZ2UgZnJvbSBBTkQgdG8gT1IuIEFzIEp1ZXJnZW4gc2FpZCwgdGhlcmUgYXJlCnRlY2huaWNh bCByZWFzb25zIC0gb25lIG9mIHRoZW0gd2FzIGFjdHVhbGx5IGZpeGluZyB0aGUgSVB2NiBwYXR0 ZXJucy4KCkxhZGEKCj4gCj4gVGhhbmtzLAo+ICBQaGlsCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9k QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Thu Dec 11 06:02:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15403A69DA; Thu, 11 Dec 2008 06:02:12 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA0D3A69DA for ; Thu, 11 Dec 2008 06:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 VY5qJwHQDIPU for ; Thu, 11 Dec 2008 06:02:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A403F3A69E2 for ; Thu, 11 Dec 2008 06:02:10 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81D6CC0104; Thu, 11 Dec 2008 15:02:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mKi3UK3TY9sA; Thu, 11 Dec 2008 15:01:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97D72C0044; Thu, 11 Dec 2008 15:01:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E0A1A8AD358; Thu, 11 Dec 2008 15:01:54 +0100 (CET) Date: Thu, 11 Dec 2008 15:01:54 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20081211140154.GA28216@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , netmod@ietf.org References: <49404AF3.9080406@netconfcentral.com> <200812111326.mBBDQ6CO014407@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200812111326.mBBDQ6CO014407@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 11, 2008 at 08:26:06AM -0500, Phil Shafer wrote: > I agree the proposed solution is elegant, but disagree about moving > to ORs. The DSDL generation can translate ORs into whatever RNG > needs (and in a much less painful way than we'll need to translate > ANDs into XSD). Since pattern OR pattern = pattern|pattern, there is no real value in having pattern OR pattern. However, translating pattern AND pattern into a single pattern is really hard so having patterns ANDed has real value. This is why we decided in favour of ANDing pattern and it does not matter what XSD or RNG do since translations are possible in all combinations. I am wondering on what grounds we open up a previously closed debate. The question whether multiple pattern are ANDed or ORed is completely independent of the canonicalization issue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 06:07:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E70F3A6A2B; Thu, 11 Dec 2008 06:07:05 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A8B3A6A2B for ; Thu, 11 Dec 2008 06:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6] 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 dIGAsalY2SfX for ; Thu, 11 Dec 2008 06:07:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 26D643A69E2 for ; Thu, 11 Dec 2008 06:07:03 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1413C76C53A; Thu, 11 Dec 2008 15:06:56 +0100 (CET) Message-ID: <49411E7F.4060905@tail-f.com> Date: Thu, 11 Dec 2008 15:06:55 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Martin Bjorklund References: <20081210.234217.140956221.mbj@tail-f.com> In-Reply-To: <20081210.234217.140956221.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On 12/10/08 23:42, Martin Bjorklund wrote: > > Another observation is that both XSD and RNG allows multiple > patterns. In XSD, the patterns are OR:ed and in RNG they are > AND:ed. It is straightforward to map between these forms. Suppose > there are two patterns, and . If they are OR:ed, a single > pattern (|) can be used. If they are AND:ed, an extra type with > a single pattern can be introduced, and derived from while adding > the pattern . But there's a significant difference in the straightforwardness, which means that AND:ed patterns give more expressive power. With OR:ed patterns, every 'pattern' after the first is just a useless verbose form of '|', while AND:ing requires the definition of "dummy" intermediary types. With AND:ed patterns, you just use '|' or multiple patterns, within the single type definition where you actually want them. > The idea we discussed for the canonical form is to change the rules so > that multiple patterns are OR:ed, and introduce a statement 'canonical > true' which can be specificed on one of the patterns. I think the canonical form as a pattern in general is doubtful - sure it is formal, but it can't actually be used for anything other than parsing by a human, since the canonical form is generally something that you need to *produce* (from an internal or non-canonical form) - a regexp is no help for that. That's not to say that I can think of an alternative that *is* useful though... OR:ing a pattern for the canonical form with pattern(s) covering both the canonical and non-canonical forms seems useless and wasteful - what's the point of simultaneously (or maybe even sequentially) matching against two patterns where one is a superset of the other, when you don't have an interest in which one of them matches? --Per Hedeland _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 06:38:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608FB3A6784; Thu, 11 Dec 2008 06:38:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27B23A6BE4 for ; Thu, 11 Dec 2008 06:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6] 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 1yhU+9rfixbe for ; Thu, 11 Dec 2008 06:38:27 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 0699E3A6784 for ; Thu, 11 Dec 2008 06:38:27 -0800 (PST) Received: (qmail 67779 invoked from network); 11 Dec 2008 14:38:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2008 14:38:18 -0000 X-YMail-OSG: l8QqvL0VM1lX4lT.lCd2oegHRuP2Oh3oWgRXRc2UIR0Wm7_ADBfjWAMFapap8Z1WbQCDzT8XpQqIJ0FqcN9MQrwauPsYZjsAv_P_U1BULgWFT5coUTiE6smCxJBTw3iQydM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494125CE.9020600@netconfcentral.com> Date: Thu, 11 Dec 2008 06:38:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Per Hedeland References: <20081210.234217.140956221.mbj@tail-f.com> <49411E7F.4060905@tail-f.com> In-Reply-To: <49411E7F.4060905@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Per Hedeland wrote: >.... > I think the canonical form as a pattern in general is doubtful - sure it > is formal, but it can't actually be used for anything other than parsing > by a human, since the canonical form is generally something that you > need to *produce* (from an internal or non-canonical form) - a regexp is > no help for that. That's not to say that I can think of an alternative > that *is* useful though... > +1 I don't see why other toolmakers find this canonical pattern interesting. Do you plan some clever way to analyze patterns and figure out how to change one arbitrary string into a different string? Do you plan to brute-force try a billion times until you randomly generate the canonical form? Is the point "once you convert by hand, the correct result will match this pattern"? For integers, isn't it just as useful to state "the optional plus sign is removed" than to put in a cryptic canonical=true pattern? > OR:ing a pattern for the canonical form with pattern(s) covering both > the canonical and non-canonical forms seems useless and wasteful - > what's the point of simultaneously (or maybe even sequentially) matching > against two patterns where one is a superset of the other, when you > don't have an interest in which one of them matches? > exactly > --Per Hedeland Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 07:04:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F4A3A6C53; Thu, 11 Dec 2008 07:04:03 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5333A6C53 for ; Thu, 11 Dec 2008 07:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 m7eWDs1HlvBM for ; Thu, 11 Dec 2008 07:04:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A58AC3A6C3E for ; Thu, 11 Dec 2008 07:04:00 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 72EF876C53A; Thu, 11 Dec 2008 16:03:54 +0100 (CET) Date: Thu, 11 Dec 2008 16:03:52 +0100 (CET) Message-Id: <20081211.160352.03567992.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <494125CE.9020600@netconfcentral.com> References: <20081210.234217.140956221.mbj@tail-f.com> <49411E7F.4060905@tail-f.com> <494125CE.9020600@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I don't see why other toolmakers find this canonical pattern > interesting. Neither do I. In Minneapolis we had three alternatives for how to specify the canonical rule: 1) as text, in the description clause 2) as text, in a new 'canonical' clause (like 'reference') 3) in some kind of formal way Personally, I preferred 2 (and still do). I like 2 b/c it makes the canonical property stand out for readers to notice it. However, most people at that time preferred alternative 3. If we are going to do that, I like the "simple" solution in my original email. But maybe this discussion shows that we should not do 3, at least not now. If so, we're back to 1 or 2 above. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 07:09:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7843A6C5A; Thu, 11 Dec 2008 07:09:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685B33A6C5C for ; Thu, 11 Dec 2008 07:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, 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 DbbIDykFOLDP for ; Thu, 11 Dec 2008 07:09:16 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 8CE7C3A6C5A for ; Thu, 11 Dec 2008 07:09:16 -0800 (PST) Received: (qmail 8968 invoked from network); 11 Dec 2008 15:09:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2008 15:09:09 -0000 X-YMail-OSG: oq0kNqYVM1mtrAAw0KF3Gtk9n7BtzFbS2IA_ZjEwkeRovhr.Ph5k5ZXoyLnMiiRTa98eSGSmocRZT6wqbPqE4_OtiLnTHIlpOzroIoCb6JOWhwmDt4tBYMzpT0nDpHNqeSoUnaDxx2lbl9ZNxdPB95QW X-Yahoo-Newman-Property: ymail-3 Message-ID: <49412D13.7050908@netconfcentral.com> Date: Thu, 11 Dec 2008 07:09:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081210.234217.140956221.mbj@tail-f.com> <49411E7F.4060905@tail-f.com> <494125CE.9020600@netconfcentral.com> <20081211.160352.03567992.mbj@tail-f.com> In-Reply-To: <20081211.160352.03567992.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I don't see why other toolmakers find this canonical pattern >> interesting. > > Neither do I. > > In Minneapolis we had three alternatives for how to specify the > canonical rule: > > 1) as text, in the description clause > 2) as text, in a new 'canonical' clause (like 'reference') > 3) in some kind of formal way > > Personally, I preferred 2 (and still do). I like 2 b/c it makes the > canonical property stand out for readers to notice it. > > However, most people at that time preferred alternative 3. If we are > going to do that, I like the "simple" solution in my original email. > > But maybe this discussion shows that we should not do 3, at least not > now. If so, we're back to 1 or 2 above. > > I prefer (1) but the group at the interim meeting did not think about (or agree to) undoing the AND vs. OR decision on patterns within the same type-stmt. A formal solution would need to work with ANDed patterns we have now. > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 07:13:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6193A68B6; Thu, 11 Dec 2008 07:13:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AC03A6903 for ; Thu, 11 Dec 2008 07:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 W7Sq9xddzh9N for ; Thu, 11 Dec 2008 07:13:35 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4FE8D3A68B6 for ; Thu, 11 Dec 2008 07:13:35 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3FDBED800CE; Thu, 11 Dec 2008 16:13:29 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081211.160352.03567992.mbj@tail-f.com> References: <20081210.234217.140956221.mbj@tail-f.com> <49411E7F.4060905@tail-f.com> <494125CE.9020600@netconfcentral.com> <20081211.160352.03567992.mbj@tail-f.com> Organization: CESNET Date: Thu, 11 Dec 2008 16:13:29 +0100 Message-Id: <1229008409.27811.114.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMTEuIDEyLiAyMDA4IHYgMTY6MDMgKzAxMDA6 Cgo+ICAgMSkgYXMgdGV4dCwgaW4gdGhlIGRlc2NyaXB0aW9uIGNsYXVzZQo+ICAgMikgYXMgdGV4 dCwgaW4gYSBuZXcgJ2Nhbm9uaWNhbCcgY2xhdXNlIChsaWtlICdyZWZlcmVuY2UnKQo+ICAgMykg aW4gc29tZSBraW5kIG9mIGZvcm1hbCB3YXkKPiAKPiBQZXJzb25hbGx5LCBJIHByZWZlcnJlZCAy IChhbmQgc3RpbGwgZG8pLiAgSSBsaWtlIDIgYi9jIGl0IG1ha2VzIHRoZQo+IGNhbm9uaWNhbCBw cm9wZXJ0eSBzdGFuZCBvdXQgZm9yIHJlYWRlcnMgdG8gbm90aWNlIGl0LgoKSSBwcmVmZXIgKDIp IGFzIHdlbGwuCgpMYWRhCgo+IAo+IEhvd2V2ZXIsIG1vc3QgcGVvcGxlIGF0IHRoYXQgdGltZSBw cmVmZXJyZWQgYWx0ZXJuYXRpdmUgMy4gIElmIHdlIGFyZQo+IGdvaW5nIHRvIGRvIHRoYXQsIEkg bGlrZSB0aGUgInNpbXBsZSIgc29sdXRpb24gaW4gbXkgb3JpZ2luYWwgZW1haWwuCj4gCj4gQnV0 IG1heWJlIHRoaXMgZGlzY3Vzc2lvbiBzaG93cyB0aGF0IHdlIHNob3VsZCBub3QgZG8gMywgYXQg bGVhc3Qgbm90Cj4gbm93LiAgSWYgc28sIHdlJ3JlIGJhY2sgdG8gMSBvciAyIGFib3ZlLgo+IAo+ IAo+IC9tYXJ0aW4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBD RVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Dec 11 10:21:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DE628C0FC; Thu, 11 Dec 2008 10:21:38 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E47528C110 for ; Thu, 11 Dec 2008 10:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 B76WP0JCi7Av for ; Thu, 11 Dec 2008 10:21:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 421BF28C0FC for ; Thu, 11 Dec 2008 10:21:35 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3E8CC0055; Thu, 11 Dec 2008 19:21:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qewfkahaYVnS; Thu, 11 Dec 2008 19:21:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CFC0C003C; Thu, 11 Dec 2008 19:21:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9DA448AD683; Thu, 11 Dec 2008 19:21:22 +0100 (CET) Date: Thu, 11 Dec 2008 19:21:22 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20081211182122.GA28388@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <20081210.234217.140956221.mbj@tail-f.com> <49411E7F.4060905@tail-f.com> <494125CE.9020600@netconfcentral.com> <20081211.160352.03567992.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081211.160352.03567992.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 11, 2008 at 04:03:52PM +0100, Martin Bjorklund wrote: > In Minneapolis we had three alternatives for how to specify the > canonical rule: > > 1) as text, in the description clause > 2) as text, in a new 'canonical' clause (like 'reference') > 3) in some kind of formal way > > Personally, I preferred 2 (and still do). I like 2 b/c it makes the > canonical property stand out for readers to notice it. I preferred (1) at the meeting, then (3) and me least preferrence would be (2). I see no value breaking description clauses in lots of different clauses so that they all stand out and at the end just clutter up everything. > However, most people at that time preferred alternative 3. If we are > going to do that, I like the "simple" solution in my original email. > > But maybe this discussion shows that we should not do 3, at least not > now. If so, we're back to 1 or 2 above. The good news is that consensus is reached on the mailing list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 19:54:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A403A682D; Thu, 11 Dec 2008 19:54:58 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763983A682D for ; Thu, 11 Dec 2008 19:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 A-ULKr63Km-b for ; Thu, 11 Dec 2008 19:54:56 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 9C4043A6774 for ; Thu, 11 Dec 2008 19:54:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSUHgfQ1QUQVOR9OqzxHTLMUzgTK9Nbk1@postini.com; Thu, 11 Dec 2008 19:54:51 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 11 Dec 2008 19:51:21 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 19:51:20 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 19:51:20 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 19:51:20 -0800 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 mBC3pJM70221; Thu, 11 Dec 2008 19:51:19 -0800 (PST) (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 mBC3jsVg020337; Fri, 12 Dec 2008 03:45:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812120345.mBC3jsVg020337@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081211182122.GA28388@elstar.local> Date: Thu, 11 Dec 2008 22:45:54 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Dec 2008 03:51:20.0312 (UTC) FILETIME=[E4B3C780:01C95C0C] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >I preferred (1) at the meeting, then (3) and me least preferrence >would be (2). I see no value breaking description clauses in lots of >different clauses so that they all stand out and at the end just >clutter up everything. My concern is that if I have a "valid" value that's _not_ in canonical form, I can't use it in my client application to match existing list entries. If "+1" is valid by the list of patterns, I've no clue if this is a new entry or if it matches "0x01", "1", "1e0", etc. If I at least know there's a canonical form, I can force the user to use it so I can match existing entries. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 22:30:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E673A6800; Thu, 11 Dec 2008 22:30:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6822E3A6937 for ; Thu, 11 Dec 2008 22:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 dmDQ-aub4e1E for ; Thu, 11 Dec 2008 22:30:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3BBC93A6800 for ; Thu, 11 Dec 2008 22:30:46 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3EF5C0049; Fri, 12 Dec 2008 07:30:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8OFo9EX9Nfa2; Fri, 12 Dec 2008 07:30:34 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D779C0048; Fri, 12 Dec 2008 07:30:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5275E8ADF91; Fri, 12 Dec 2008 07:30:33 +0100 (CET) Date: Fri, 12 Dec 2008 07:30:33 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20081212063033.GA28906@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20081211182122.GA28388@elstar.local> <200812120345.mBC3jsVg020337@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200812120345.mBC3jsVg020337@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Dec 11, 2008 at 10:45:54PM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >I preferred (1) at the meeting, then (3) and me least preferrence > >would be (2). I see no value breaking description clauses in lots of > >different clauses so that they all stand out and at the end just > >clutter up everything. > > My concern is that if I have a "valid" value that's _not_ in canonical > form, I can't use it in my client application to match existing > list entries. If "+1" is valid by the list of patterns, I've no > clue if this is a new entry or if it matches "0x01", "1", "1e0", > etc. If I at least know there's a canonical form, I can force the > user to use it so I can match existing entries. I fail to see the difference between description "... The canoncial form is decimal without a plus sign."; and canoncial "The canoncial form is decimal without a plus sign."; since in both cases a human is required to read the text and do the right thing. And yes, for true automation, you really want to have everything in canonical form at the end (and I think we already agreed that a server should return canonical form anyways). Perhaps I don't understand your point. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 23:14:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2F93A63EB; Thu, 11 Dec 2008 23:14:25 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2053A6832 for ; Thu, 11 Dec 2008 23:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NprmW+TV9im5 for ; Thu, 11 Dec 2008 23:14:23 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3EC393A63EB for ; Thu, 11 Dec 2008 23:14:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSUIPPzJbuOQhXzcQjo+e6wevBGctXUUr@postini.com; Thu, 11 Dec 2008 23:14:17 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 11 Dec 2008 23:11:29 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 23:11:28 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 23:11:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 23:11:27 -0800 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 mBC7BRM54272; Thu, 11 Dec 2008 23:11:27 -0800 (PST) (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 mBC764NS021327; Fri, 12 Dec 2008 07:06:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812120706.mBC764NS021327@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081212063033.GA28906@elstar.local> Date: Fri, 12 Dec 2008 02:06:04 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Dec 2008 07:11:27.0956 (UTC) FILETIME=[D9D0D940:01C95C28] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >Perhaps I don't understand your point. Sorry. Let me try again. Suppose I have YANG like: typedef positive { type string { description "The canonical form trims leading pluses"; pattern "0|[1-9][0-9]*"; pattern "+[1-9][0-9]*"; } } list thing { key name; leaf name { type positive; } ... } In my client application, I need to prompt the user for a thing name and find it in my local database. If I allow the user to enter "+1", I won't find the data. I need a mechanism to tell me the canonical form so I can restrict the user to that pattern when I have no other choice. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 11 23:28:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E863A68CD; Thu, 11 Dec 2008 23:28:14 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3BF3A691E for ; Thu, 11 Dec 2008 23:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 clCFlDIoEcUZ for ; Thu, 11 Dec 2008 23:28:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A9D4C3A68CD for ; Thu, 11 Dec 2008 23:28:12 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13FCFC0059; Fri, 12 Dec 2008 08:28:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SFnt6Y7tJQMw; Fri, 12 Dec 2008 08:28:00 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C25C9C0048; Fri, 12 Dec 2008 08:28:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DC2208AE098; Fri, 12 Dec 2008 08:27:59 +0100 (CET) Date: Fri, 12 Dec 2008 08:27:59 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20081212072759.GA28977@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20081212063033.GA28906@elstar.local> <200812120706.mBC764NS021327@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200812120706.mBC764NS021327@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Dec 12, 2008 at 02:06:04AM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Perhaps I don't understand your point. > > Sorry. Let me try again. Suppose I have YANG like: > > typedef positive { > type string { > description "The canonical form trims leading pluses"; > pattern "0|[1-9][0-9]*"; > pattern "+[1-9][0-9]*"; > } > } > list thing { > key name; > leaf name { > type positive; > } > ... > } > > In my client application, I need to prompt the user for a thing > name and find it in my local database. If I allow the user to enter > "+1", I won't find the data. I need a mechanism to tell me the > canonical form so I can restrict the user to that pattern when I > have no other choice. OK - got it. But in that case, you really want to force the user to comply to a type that is canonical by nature: typedef positive-ca { type positive; pattern "0|[1-9][0-9]*"; } I start to like the solution of defining separate types and to link them together in case we want to do more than just textual descriptions. This allows us to use all existing and future YANG mechanisms for type derivations and not just patterns and it allows data model writers to pick the type they find appropriate. In general, I believe it is desirable to avoid types that have non-canonical formats. Exceptions to this rule are those cases where different formats are widely used (such as IPv6 addresses). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 00:22:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F35E3A6994; Fri, 12 Dec 2008 00:22:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3737B3A6A9F for ; Fri, 12 Dec 2008 00:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 qOSyCj-ucnPu for ; Fri, 12 Dec 2008 00:22:18 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 5EC213A6994 for ; Fri, 12 Dec 2008 00:22:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSUIfLn+7S+fzNLNFAtdzq/ASt129QZbx@postini.com; Fri, 12 Dec 2008 00:22:12 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 12 Dec 2008 00:18:40 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 00:18:40 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 00:18:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 00:18:39 -0800 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 mBC8IcM82292; Fri, 12 Dec 2008 00:18:38 -0800 (PST) (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 mBC8DF2A021706; Fri, 12 Dec 2008 08:13:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812120813.mBC8DF2A021706@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081212072759.GA28977@elstar.local> Date: Fri, 12 Dec 2008 03:13:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Dec 2008 08:18:39.0254 (UTC) FILETIME=[3CA81B60:01C95C32] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >OK - got it. But in that case, you really want to force the user >to comply to a type that is canonical by nature: I want anyone who understands the type to be liberal and allow anything that matches any of the patterns. This is normally fine, but for keys, the canonical form matters more. If my app doesn't have the type implemented explicitly, then forcing data into the canonical form is good enough. >In general, I believe it is desirable to avoid types that have >non-canonical formats. Exceptions to this rule are those cases where >different formats are widely used (such as IPv6 addresses). Or integers (0xfe, 0755, 1e4). Or strings (utf-8). Or ... We're transmitting data in text, so canonicalization's part of life. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 01:30:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EC83A6887; Fri, 12 Dec 2008 01:30:08 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EE93A6937 for ; Fri, 12 Dec 2008 01:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Htkh8z52hgMn for ; Fri, 12 Dec 2008 01:30:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 54F2C3A6887 for ; Fri, 12 Dec 2008 01:30:06 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7799876C53E; Fri, 12 Dec 2008 10:29:59 +0100 (CET) Message-ID: <49422F17.6030404@tail-f.com> Date: Fri, 12 Dec 2008 10:29:59 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200812120813.mBC8DF2A021706@idle.juniper.net> In-Reply-To: <200812120813.mBC8DF2A021706@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On 12/12/08 09:13, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> OK - got it. But in that case, you really want to force the user >> to comply to a type that is canonical by nature: > > I want anyone who understands the type to be liberal > and allow anything that matches any of the patterns. > This is normally fine, but for keys, the canonical > form matters more. If my app doesn't have the type > implemented explicitly, then forcing data into the > canonical form is good enough. Could you elaborate on how this would work in practice? E.g. I'm a netconf client and send you a non-canonical-but-allowed-by-the-pattern "+1" as a key value, you're the server, now what do you do? --Per Hedeland _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 04:02:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD293A6A83; Fri, 12 Dec 2008 04:02:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B1D3A6AAB for ; Fri, 12 Dec 2008 04:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 X4rMU4H0XBYh for ; Fri, 12 Dec 2008 04:02:11 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 30E443A6A83 for ; Fri, 12 Dec 2008 04:02:11 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 923ABD800C0 for ; Fri, 12 Dec 2008 13:02:02 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200812120345.mBC3jsVg020337@idle.juniper.net> References: <200812120345.mBC3jsVg020337@idle.juniper.net> Organization: CESNET Date: Fri, 12 Dec 2008 13:02:06 +0100 Message-Id: <1229083326.27811.137.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDExLiAxMi4gMjAwOCB2IDIyOjQ1IC0wNTAwOgo+IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciB3cml0ZXM6Cj4gPkkgcHJlZmVycmVkICgxKSBhdCB0aGUgbWVl dGluZywgdGhlbiAoMykgYW5kIG1lIGxlYXN0IHByZWZlcnJlbmNlCj4gPndvdWxkIGJlICgyKS4g IEkgc2VlIG5vIHZhbHVlIGJyZWFraW5nIGRlc2NyaXB0aW9uIGNsYXVzZXMgaW4gbG90cyBvZgo+ ID5kaWZmZXJlbnQgY2xhdXNlcyBzbyB0aGF0IHRoZXkgYWxsIHN0YW5kIG91dCBhbmQgYXQgdGhl IGVuZCBqdXN0Cj4gPmNsdXR0ZXIgdXAgZXZlcnl0aGluZy4KPiAKPiBNeSBjb25jZXJuIGlzIHRo YXQgaWYgSSBoYXZlIGEgInZhbGlkIiB2YWx1ZSB0aGF0J3MgX25vdF8gaW4gY2Fub25pY2FsCj4g Zm9ybSwgSSBjYW4ndCB1c2UgaXQgaW4gbXkgY2xpZW50IGFwcGxpY2F0aW9uIHRvIG1hdGNoIGV4 aXN0aW5nCj4gbGlzdCBlbnRyaWVzLiAgSWYgIisxIiBpcyB2YWxpZCBieSB0aGUgbGlzdCBvZiBw YXR0ZXJucywgSSd2ZSBubwo+IGNsdWUgaWYgdGhpcyBpcyBhIG5ldyBlbnRyeSBvciBpZiBpdCBt YXRjaGVzICIweDAxIiwgIjEiLCAiMWUwIiwKPiBldGMuICBJZiBJIGF0IGxlYXN0IGtub3cgdGhl cmUncyBhIGNhbm9uaWNhbCBmb3JtLCBJIGNhbiBmb3JjZSB0aGUKPiB1c2VyIHRvIHVzZSBpdCBz byBJIGNhbiBtYXRjaCBleGlzdGluZyBlbnRyaWVzLgoKWUFORyBsZWFmcyBhcmUgdHlwZWQgYW5k IHRoZSBzdGFuZGFyZCB0eXBlcyBzdWNoIGFzIGludGVnZXIgaGVyZSBkZWZpbmUKYW5kIGRpc3Rp bmd1aXNoIGxleGljYWwgc3BhY2UgYW5kIHZhbHVlIHNwYWNlLiBTbyBpbiBYU0xUIEkgY2FuIHdy aXRlCmV2ZW4KCjx4c2w6dmFsdWUtb2Ygc2VsZWN0PSJmb29ba2V5PTIqMS41XS92YWx1ZSIvPgoK dG8gYWRkcmVzcyB0aGUga2V5ICIzIi4gQSBzYW5lIGFuZCBQb3N0ZWwtbGlrZSBhcHByb2FjaCBm b3IgWUFORyB3b3VsZApiZSB0byBkbyB0aGUgc2FtZSwgaS5lLiwgY29tcGFyZSBsZWFmcyB3aXRo IG51bWVyaWMgdHlwZXMgYXMgbnVtYmVycy4KCkkgdGhpbmsgaXMgd291bGQgYmUgYmV0dGVyIGlu IGdlbmVyYWwgdG8gc3BlY2lmeSB2YWx1ZS1zcGFjZSB2YWx1ZXMgZm9yCnR5cGVzIHJhdGhlciB0 aGFuIHRoZSBjYW5vbmljYWwgbGV4aWNhbCBmb3JtLiAKCkxhZGEKCj4gCj4gVGhhbmtzLAo+ICBQ aGlsCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBu ZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBH UCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Dec 12 06:08:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262AB3A689B; Fri, 12 Dec 2008 06:08:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0CD28C0EF for ; Fri, 12 Dec 2008 06:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, 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 mHqPKUmsYE0G for ; Fri, 12 Dec 2008 06:08:24 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 27E1E3A689B for ; Fri, 12 Dec 2008 06:08:23 -0800 (PST) Received: (qmail 68266 invoked from network); 12 Dec 2008 14:08:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 12 Dec 2008 14:08:16 -0000 X-YMail-OSG: bZmKJe4VM1mi159shPoX5wrpJhwe17HDayB0qcgyVERmJxcUZDwD1M0Cv97dTk.Vu1Y8GomAOorf4teQs8S4qXl3Xxk7tNjzVRoh80anDh0a23IoLmvWjY_3iWTGJLoNAho- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4942704E.5030807@netconfcentral.com> Date: Fri, 12 Dec 2008 06:08:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812120706.mBC764NS021327@idle.juniper.net> In-Reply-To: <200812120706.mBC764NS021327@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Juergen Schoenwaelder writes: >> Perhaps I don't understand your point. > > Sorry. Let me try again. Suppose I have YANG like: > > typedef positive { > type string { > description "The canonical form trims leading pluses"; > pattern "0|[1-9][0-9]*"; > pattern "+[1-9][0-9]*"; > } > } > list thing { > key name; > leaf name { > type positive; > } > ... > } > > In my client application, I need to prompt the user for a thing > name and find it in my local database. If I allow the user to enter > "+1", I won't find the data. I need a mechanism to tell me the > canonical form so I can restrict the user to that pattern when I > have no other choice. > I do not think we should worry at all about dumb applications which do not utilize the YANG files to process the YANG data models carried in NETCONF PDUs. You cannot do very much at all without the YANG file, such as comparing the value-space instead of the raw XML content. Since a real YANG app knows the data type is 'int32', it knows how to deal with the '+' character. I do not see why the NMS app needs the values by the user to exactly match the values returned in . The NMS has the YANG files, and can convert the data to its canonical form. MIB walker programs still work fine. Real CM applications are going to need the YANG files to work at all. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 08:05:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D213A67AA; Fri, 12 Dec 2008 08:05:43 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFEA3A67F7 for ; Fri, 12 Dec 2008 08:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LkCF9K5fBaRD for ; Fri, 12 Dec 2008 08:05:41 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id D63F93A67AA for ; Fri, 12 Dec 2008 08:05:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSUKLydIkG4hVG8WPoV4MwtN0uybtN0W9@postini.com; Fri, 12 Dec 2008 08:05:36 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 12 Dec 2008 08:02:54 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 08:02:54 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 08:02:54 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 08:02:53 -0800 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 mBCG2qM82511; Fri, 12 Dec 2008 08:02:52 -0800 (PST) (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 mBCFvTXE023810; Fri, 12 Dec 2008 15:57:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812121557.mBCFvTXE023810@idle.juniper.net> To: Andy Bierman In-Reply-To: <4942704E.5030807@netconfcentral.com> Date: Fri, 12 Dec 2008 10:57:29 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Dec 2008 16:02:53.0458 (UTC) FILETIME=[170E5720:01C95C73] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Real CM applications >are going to need the YANG files to work at all. Which is why we need to be able to see the canonical form via the YANG file. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 08:17:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9395B3A6821; Fri, 12 Dec 2008 08:17:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2103A699A for ; Fri, 12 Dec 2008 08:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OgrxCzVi7t+b for ; Fri, 12 Dec 2008 08:17:32 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 775A23A6821 for ; Fri, 12 Dec 2008 08:17:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSUKOlMqdL3YQoqsE8oVoQRhH7W64pciJ@postini.com; Fri, 12 Dec 2008 08:17:26 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 12 Dec 2008 08:13:19 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 08:13:19 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 08:13:19 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 08:13:18 -0800 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 mBCGDIM86754; Fri, 12 Dec 2008 08:13:18 -0800 (PST) (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 mBCG7tJ5023914; Fri, 12 Dec 2008 16:07:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812121607.mBCG7tJ5023914@idle.juniper.net> To: Per Hedeland In-Reply-To: <49422F17.6030404@tail-f.com> Date: Fri, 12 Dec 2008 11:07:54 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Dec 2008 16:13:18.0711 (UTC) FILETIME=[8BBC6070:01C95C74] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Per Hedeland writes: >Could you elaborate on how this would work in practice? E.g. I'm a >netconf client and send you a non-canonical-but-allowed-by-the-pattern >"+1" as a key value, you're the server, now what do you do? The server is required to send the content in canonical form. One could use the canonical statement to enforce that, but that's not the use case I was seeing. My use case is where the type allows a casual form that is translated into the canonical form. A client application downloads a list of entries which includes one named "15". The user says "edit entry +15". (I know the "+" is not entirely real world, since everyone needs to implement integers, but it makes a simple case). If my application does not have the hardcoded logic to know how to translate user input into canonical form, it will accidentally make a new "+15" entry instead of using the existing "15" one. The user becomes lost, confused, annoyed, or violent. Not good. If there were an indication in the YANG file which pattern is canonical, my application can see "+15" and know enough to tell the user that this is not a canonical form and that it's not smart enough to translate it, so the user will need to re-enter using the canonical form. The user may still be annoying, but it's a better outcome. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 08:45:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDA83A6984; Fri, 12 Dec 2008 08:45:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88673A6984 for ; Fri, 12 Dec 2008 08:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 on3grCz+-m-a for ; Fri, 12 Dec 2008 08:45:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1CFF03A68D6 for ; Fri, 12 Dec 2008 08:45:32 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 249ED76C537; Fri, 12 Dec 2008 17:45:25 +0100 (CET) Message-ID: <49429524.8080906@tail-f.com> Date: Fri, 12 Dec 2008 17:45:24 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200812121607.mBCG7tJ5023914@idle.juniper.net> In-Reply-To: <200812121607.mBCG7tJ5023914@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On 12/12/08 17:07, Phil Shafer wrote: > Per Hedeland writes: >> Could you elaborate on how this would work in practice? E.g. I'm a >> netconf client and send you a non-canonical-but-allowed-by-the-pattern >> "+1" as a key value, you're the server, now what do you do? > > The server is required to send the content in canonical form. But the client isn't, right? > If there were an indication in the YANG file which pattern is > canonical, my application can see "+15" and know enough to tell the > user that this is not a canonical form and that it's not smart > enough to translate it, so the user will need to re-enter using the > canonical form. The user may still be annoying, but it's a better > outcome. Yes, however my question was not about a user but about a Netconf client. --Per Hedeland _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 08:57:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924283A6A8F; Fri, 12 Dec 2008 08:57:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A0D3A6B12 for ; Fri, 12 Dec 2008 08:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 Ffutk5PjkVoL for ; Fri, 12 Dec 2008 08:57:05 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 487803A6A8F for ; Fri, 12 Dec 2008 08:57:04 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6C580D800CC for ; Fri, 12 Dec 2008 17:56:58 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49429524.8080906@tail-f.com> References: <200812121607.mBCG7tJ5023914@idle.juniper.net> <49429524.8080906@tail-f.com> Organization: CESNET Date: Fri, 12 Dec 2008 17:57:02 +0100 Message-Id: <1229101022.27811.163.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGVyIEhlZGVsYW5kIHDDrcWhZSB2IFDDoSAxMi4gMTIuIDIwMDggdiAxNzo0NSArMDEwMDoKPiBP biAxMi8xMi8wOCAxNzowNywgUGhpbCBTaGFmZXIgd3JvdGU6Cj4gPiBQZXIgSGVkZWxhbmQgd3Jp dGVzOgo+ID4+IENvdWxkIHlvdSBlbGFib3JhdGUgb24gaG93IHRoaXMgd291bGQgd29yayBpbiBw cmFjdGljZT8gRS5nLiBJJ20gYQo+ID4+IG5ldGNvbmYgY2xpZW50IGFuZCBzZW5kIHlvdSBhIG5v bi1jYW5vbmljYWwtYnV0LWFsbG93ZWQtYnktdGhlLXBhdHRlcm4KPiA+PiAiKzEiIGFzIGEga2V5 IHZhbHVlLCB5b3UncmUgdGhlIHNlcnZlciwgbm93IHdoYXQgZG8geW91IGRvPwo+ID4KPiA+IFRo ZSBzZXJ2ZXIgaXMgcmVxdWlyZWQgdG8gc2VuZCB0aGUgY29udGVudCBpbiBjYW5vbmljYWwgZm9y bS4KPiAKPiBCdXQgdGhlIGNsaWVudCBpc24ndCwgcmlnaHQ/CgpJIHRoaW5rIHRoZSBjbGllbnQg bXVzdCBiZSByZXF1aXJlZCBpbiBzb21lIGNhc2VzLCB0b28sIGZvciBleGFtcGxlLAp3aGVuIHNw ZWNpZnlpbmcgYSBsaXN0IGtleS4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQ R1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Dec 12 09:18:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7993A67AE; Fri, 12 Dec 2008 09:18:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E723A684C for ; Fri, 12 Dec 2008 09:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.038, 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 JUrrsIb1k9tB for ; Fri, 12 Dec 2008 09:18:11 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 8A2333A67AE for ; Fri, 12 Dec 2008 09:18:11 -0800 (PST) Received: (qmail 52569 invoked from network); 12 Dec 2008 17:18:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 12 Dec 2008 17:18:03 -0000 X-YMail-OSG: o7voYu8VM1nz.SGApak8Qbmgz.8AMfaxBewNtY1KYMZio9BjiGIWTBxQ7P1hXX5KuxLv0CBpTVVa8uLJZlX5JE1YedP90pxrbc.KzUjJIUqAHIlMMGLdU_kmrnHPSDkCsrM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49429CC9.6000807@netconfcentral.com> Date: Fri, 12 Dec 2008 09:18:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812121557.mBCFvTXE023810@idle.juniper.net> In-Reply-To: <200812121557.mBCFvTXE023810@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Real CM applications >> are going to need the YANG files to work at all. > > Which is why we need to be able to see the canonical > form via the YANG file. > Then it needs to be done in a way that doesn't change the way pattern-stmt works now. I prefer a separate canonical-pattern statement instead of a 'canonical' container around the existing pattern-stmt, because it is more clear to the human and the parser that this is not part of the patterns for validating input. The canonical form for non-string types needs to be specified in the draft. So the "+4" or "0x04" into "4" problem is handled by normative text, not by applying patterns to numbers. For string types (which already accept the pattern-stmt) adding a separate canonical-pattern-stmt is useful to generate warnings or errors, if you want to force the user to enter the canonical form. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 09:31:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF9F3A6821; Fri, 12 Dec 2008 09:31:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DFB3A6821 for ; Fri, 12 Dec 2008 09:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.033, 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 csmDgwozU9Ii for ; Fri, 12 Dec 2008 09:31:13 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 7DD773A686C for ; Fri, 12 Dec 2008 09:31:13 -0800 (PST) Received: (qmail 74738 invoked from network); 12 Dec 2008 17:31:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 12 Dec 2008 17:31:06 -0000 X-YMail-OSG: 8Vp0ngQVM1nI_pBlkP7s8lW570vEJwcrz.SSD_VzKfx6YX5TBT4MMIA4_U3fOSHT2r_JPWpF0zY.FlhABi2PRCXI7vzOuVFzbXrz_OgZlhc1o3Boej67OfnXaHR5Y_718NY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49429FD8.7090200@netconfcentral.com> Date: Fri, 12 Dec 2008 09:31:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I just noticed that sec. 9.2.1 says that octal numbers are encoded as a zero followed by more octal digits. But an integer value is a sign (+/-) followed by a sequence of decimal digits. These rules overlap. E.g.: 052 octal is a legal representation of 52 decimal. Do we really need to support octal numbers in YANG? I mean, talk about legacy. There are already 10 numeric data types, and plenty of ways to specify defaults for them with decimal, hexadecimal, and floating point formats. If yes, then a deterministic prefix is needed instead of what is there now. IMO, octal should be removed from YANG. BTW, it might be good to mention in this section that these number formats do not apply to XPath expressions. Those are IEEE 754 FP numbers, not YANG numbers (no hex!) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 09:57:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95DA3A6923; Fri, 12 Dec 2008 09:57:11 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4EA83A6B0D for ; Fri, 12 Dec 2008 09:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OaiA1bLsfFsR for ; Fri, 12 Dec 2008 09:57:09 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 2474D28B23E for ; Fri, 12 Dec 2008 09:56:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSUKlw1V5cCipYZICmSIfzMkKvKXNPn4M@postini.com; Fri, 12 Dec 2008 09:56:29 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 12 Dec 2008 09:53:59 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 09:53:59 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 09:53:59 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 09:53:58 -0800 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 mBCHrwM30141; Fri, 12 Dec 2008 09:53:58 -0800 (PST) (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 mBCHmYmh025972; Fri, 12 Dec 2008 17:48:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812121748.mBCHmYmh025972@idle.juniper.net> To: Per Hedeland In-Reply-To: <49429524.8080906@tail-f.com> Date: Fri, 12 Dec 2008 12:48:34 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Dec 2008 17:53:58.0892 (UTC) FILETIME=[9BF6DAC0:01C95C82] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Per Hedeland writes: >But the client isn't, right? Right. >> If there were an indication in the YANG file which pattern is >> canonical, my application can see "+15" and know enough to tell the >> user that this is not a canonical form and that it's not smart >> enough to translate it, so the user will need to re-enter using the >> canonical form. The user may still be annoying, but it's a better >> outcome. > >Yes, however my question was not about a user but about a Netconf >client. Sure, but an the other end of my application is a user typing in data. Without the canonical statement, my app can't use that data effectively. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 10:33:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00B128C0E3; Fri, 12 Dec 2008 10:33:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF8228C11B for ; Fri, 12 Dec 2008 10:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7l3ydurwdpE0 for ; Fri, 12 Dec 2008 10:33:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C713128C0E3 for ; Fri, 12 Dec 2008 10:33:16 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C8DFC000A; Fri, 12 Dec 2008 19:33:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qvytvNXdwVGx; Fri, 12 Dec 2008 19:33:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DEA2C0124; Fri, 12 Dec 2008 19:33:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 88BFB8B13E5; Fri, 12 Dec 2008 19:33:03 +0100 (CET) Date: Fri, 12 Dec 2008 19:33:03 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081212183303.GA22611@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <49429FD8.7090200@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49429FD8.7090200@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Dec 12, 2008 at 09:31:04AM -0800, Andy Bierman wrote: > I just noticed that sec. 9.2.1 says that octal numbers are encoded > as a zero followed by more octal digits. But an integer value > is a sign (+/-) followed by a sequence of decimal digits. > These rules overlap. E.g.: > > 052 octal is a legal representation of 52 decimal. > > Do we really need to support octal numbers in YANG? > I mean, talk about legacy. There are already 10 numeric > data types, and plenty of ways to specify defaults for them > with decimal, hexadecimal, and floating point formats. > > If yes, then a deterministic prefix is needed instead of > what is there now. IMO, octal should be removed from YANG. SMIng supported numbers following precisely the C language standard and standard conversion library functions such as strtod() etc. I believe this a reasonable choice. And in C, an integral number starting with a leading zero is considered to be an octal number. In other words, 052 is not a legal representation of 52 decimal and your C compiler is going to reject 082 as a constant. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 10:34:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A63228C11B; Fri, 12 Dec 2008 10:34:44 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F17028C11B for ; Fri, 12 Dec 2008 10:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 7gg1rwbPRxsn for ; Fri, 12 Dec 2008 10:34:42 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 3948728C13F for ; Fri, 12 Dec 2008 10:34:42 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBCIYZfn002924 for ; Fri, 12 Dec 2008 13:34:35 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBCIYZSB002920 for ; Fri, 12 Dec 2008 13:34:35 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 12 Dec 2008 13:34:35 -0500 From: "Natale, Bob" To: NETMOD Working Group Date: Fri, 12 Dec 2008 13:34:33 -0500 Thread-Topic: [netmod] octal numbers Thread-Index: AclciBe2E//J6Ea7TqmSZlx8ijuigwAACMwA Message-ID: <17969D855F28964C88D177D45B6CDF11E186E69B@IMCMBX2.MITRE.ORG> References: <49429FD8.7090200@netconfcentral.com> <20081212183303.GA22611@elstar.local> In-Reply-To: <20081212183303.GA22611@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org +1 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, December 12, 2008 1:33 PM To: Andy Bierman Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers On Fri, Dec 12, 2008 at 09:31:04AM -0800, Andy Bierman wrote: > I just noticed that sec. 9.2.1 says that octal numbers are encoded > as a zero followed by more octal digits. But an integer value > is a sign (+/-) followed by a sequence of decimal digits. > These rules overlap. E.g.: > > 052 octal is a legal representation of 52 decimal. > > Do we really need to support octal numbers in YANG? > I mean, talk about legacy. There are already 10 numeric > data types, and plenty of ways to specify defaults for them > with decimal, hexadecimal, and floating point formats. > > If yes, then a deterministic prefix is needed instead of > what is there now. IMO, octal should be removed from YANG. SMIng supported numbers following precisely the C language standard and standard conversion library functions such as strtod() etc. I believe this a reasonable choice. And in C, an integral number starting with a leading zero is considered to be an octal number. In other words, 052 is not a legal representation of 52 decimal and your C compiler is going to reject 082 as a constant. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 11:08:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A883A68E8; Fri, 12 Dec 2008 11:08:14 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143793A6B0D for ; Fri, 12 Dec 2008 11:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Q8VJ+TtB1Qzm for ; Fri, 12 Dec 2008 11:08:12 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 642E73A68E8 for ; Fri, 12 Dec 2008 11:08:12 -0800 (PST) Received: (qmail 62250 invoked from network); 12 Dec 2008 19:08:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 12 Dec 2008 19:08:04 -0000 X-YMail-OSG: dClaW0oVM1kV5PdAQ2jBw_ubbHSBrlxP4fWDpaPGFNPV2y3TrgDc9TpmEJs_l0NJOUuyhZW7JeV1ANCf.NSx_3eeJT0AZ7gMEuoTRVyQLgYU4ztdAJIo1RoSi1MbhCCXUYg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4942B693.3030204@netconfcentral.com> Date: Fri, 12 Dec 2008 11:08:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group References: <49429FD8.7090200@netconfcentral.com> <20081212183303.GA22611@elstar.local> In-Reply-To: <20081212183303.GA22611@elstar.local> Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Dec 12, 2008 at 09:31:04AM -0800, Andy Bierman wrote: > >> I just noticed that sec. 9.2.1 says that octal numbers are encoded >> as a zero followed by more octal digits. But an integer value >> is a sign (+/-) followed by a sequence of decimal digits. >> These rules overlap. E.g.: >> >> 052 octal is a legal representation of 52 decimal. >> >> Do we really need to support octal numbers in YANG? >> I mean, talk about legacy. There are already 10 numeric >> data types, and plenty of ways to specify defaults for them >> with decimal, hexadecimal, and floating point formats. >> >> If yes, then a deterministic prefix is needed instead of >> what is there now. IMO, octal should be removed from YANG. > > SMIng supported numbers following precisely the C language standard > and standard conversion library functions such as strtod() etc. I > believe this a reasonable choice. And in C, an integral number > starting with a leading zero is considered to be an octal number. In > other words, 052 is not a legal representation of 52 decimal and your > C compiler is going to reject 082 as a constant. > Well the YANG spec needs to be fixed then. Doesn't seem like a great use-case to me though. The ABNF does not mention octal numbers at all. It does show that leading zeros are not allowed on decimal numbers, but "-0" is valid. (I thought that was FP only). The text in 9.2.1 should be fixed so it matches the ABNF. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 13:01:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF053A68B4; Fri, 12 Dec 2008 13:01:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEF93A68B4 for ; Fri, 12 Dec 2008 13:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 byzdjgyhIR1e for ; Fri, 12 Dec 2008 13:01:48 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0C4C828C152 for ; Fri, 12 Dec 2008 13:01:47 -0800 (PST) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 78D7F76C523; Fri, 12 Dec 2008 22:01:40 +0100 (CET) Message-ID: <4942D12F.3070109@tail-f.com> Date: Fri, 12 Dec 2008 22:01:35 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200812121748.mBCHmYmh025972@idle.juniper.net> In-Reply-To: <200812121748.mBCHmYmh025972@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On 2008-12-12 18:48, Phil Shafer wrote: > > Sure, but an the other end of my application is a user > typing in data. Without the canonical statement, my > app can't use that data effectively. Aha, so your application is a Netconf client. OK, this seems to be a good argument - the server that actually uses the type needs to "understand" it, and it's reasonable to expect it to "know" how to do the non-canonical -> canonical transformation, even though it can't actually use the canonical pattern for that - but expecting a client working off an arbitrary data model spec to know that is not reasonable, and it *can* use the canonical pattern. --Per Hedeland _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 12 15:44:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A48C3A6AFC; Fri, 12 Dec 2008 15:44:53 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F8B3A6B0C for ; Fri, 12 Dec 2008 15:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] 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 FczOPModPa5Y for ; Fri, 12 Dec 2008 15:44:52 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3A06A3A6AFC for ; Fri, 12 Dec 2008 15:44:52 -0800 (PST) Received: (qmail 86193 invoked from network); 12 Dec 2008 23:44:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.130.78 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 12 Dec 2008 23:44:27 -0000 X-YMail-OSG: 1jtSWc8VM1lyXZfxZXmm93jBSCh.58KmZaHCeb.1jmXyRi0oNWreZE5sOBwy0A_9OUJCKrQDc5S1RMPbFKfyaUbcINQzbuSyFkmg6Il2stoRQwIEiNOYxqiQ39pYq5Op8MaZSV9N_PZhdge7MvKmrglX X-Yahoo-Newman-Property: ymail-3 Message-ID: <4942F75A.9060406@netconfcentral.com> Date: Fri, 12 Dec 2008 15:44:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] must/mandatory on non-config database node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The must-stmt and mandatory=true applied to a read-only data node is merely a schema reminder to the manager, like rpc/output, right? There is no actual protocol processing point associated with a config=false database node. If there is a violation, it is an agent bug. There won't be any reported. (Hey, that would be cool -- an agent that could run all the validation tests and report "I'm a buggy implementation." ;-) The draft should not imply that generation of an for these restraints will be done for or PDU processing on config=false nodes. That would be bad. All it takes is one buggy (or non-compliant) mandatory read-only object and all edits and commits would fail from then on, and there's nothing the NMS can do about it. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 04:16:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585D93A6969; Mon, 15 Dec 2008 04:16:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EC13A6989 for ; Mon, 15 Dec 2008 04:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 cpud4JvGJREM for ; Mon, 15 Dec 2008 04:16:49 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9643A3A6969 for ; Mon, 15 Dec 2008 04:16:47 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 04BC020F8E for ; Mon, 15 Dec 2008 13:16:39 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-ba-49464966f6be Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08CC322546 for ; Mon, 15 Dec 2008 13:11:18 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 13:11:17 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 13:11:17 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 15 Dec 2008 13:11:16 +0100 User-Agent: KMail/1.9.10 References: <49404AF3.9080406@netconfcentral.com> <200812111326.mBBDQ6CO014407@idle.juniper.net> <20081211140154.GA28216@elstar.local> In-Reply-To: <20081211140154.GA28216@elstar.local> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812151311.17170.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Dec 2008 12:11:17.0807 (UTC) FILETIME=[3BD783F0:01C95EAE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thursday 11 December 2008 15.01.54 Juergen Schoenwaelder wrote: > On Thu, Dec 11, 2008 at 08:26:06AM -0500, Phil Shafer wrote: > > I agree the proposed solution is elegant, but disagree about moving > > to ORs. The DSDL generation can translate ORs into whatever RNG > > needs (and in a much less painful way than we'll need to translate > > ANDs into XSD). > > Since pattern OR pattern =3D pattern|pattern, there is no real value in > having pattern OR pattern. However, translating pattern AND pattern > into a single pattern is really hard so having patterns ANDed has real > value. This is why we decided in favour of ANDing pattern and it does > not matter what XSD or RNG do since translations are possible in all > combinations. > > I am wondering on what grounds we open up a previously closed debate. > The question whether multiple pattern are ANDed or ORed is completely > independent of the canonicalization issue. Hi, I agree with J=FCrgen. Let's try to keep the two issues separate if at all = possible. I really don't want to re-open issues that are closed unless = there's a very good reason to do so. We decided to AND patterns. Do we really have to change that to solve = the "canonical form" issue? I sure hope not. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 06:01:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD76F3A69DF; Mon, 15 Dec 2008 06:01:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3673A6A10 for ; Mon, 15 Dec 2008 06:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 kG1ROi8nqyt1 for ; Mon, 15 Dec 2008 06:01:14 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8F08F3A6A12 for ; Mon, 15 Dec 2008 06:01:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2007C20BAE for ; Mon, 15 Dec 2008 15:00:37 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-20-494662f746f3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC69C2142F for ; Mon, 15 Dec 2008 15:00:23 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 15:00:01 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 15:00:01 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 15 Dec 2008 15:00:00 +0100 User-Agent: KMail/1.9.10 References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> In-Reply-To: <49404AF3.9080406@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812151500.01010.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Dec 2008 14:00:01.0632 (UTC) FILETIME=[6C583600:01C95EBD] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I'm trying to figure out where this thread is... Let's see if I have some = of = it right... As Martin wrote, we seem to have three options on the table. "In Minneapolis we had three alternatives for how to specify the canonical rule: 1) as text, in the description clause 2) as text, in a new 'canonical' clause (like 'reference') 3) in some kind of formal way" The "direction" in Minneapolis was 3, although the result wasn't overwhelmi= ng. = Martin was asked to take this to the list, which he has done. Thanks! >From this thread: 1. Andy & Lada have said that they do not want to go back to OR-ing the = patterns. As technical contributor, I agree with J=FCrgen that I haven't s= een = any reason to change this decision. 2. A few voices are saying "wait till after Sep 2009". I'd personally like= to = settle this now but understand the sentiment... The "compromise" ground = could be that we go with "2" above. 3. Andy suggests using a new statement called 'canonical-pattern' that is n= ot = used along with all the other AND-ed patterns. This doesn't change the way pattern-stmt works now. 4. J=FCrgen has offered a new alternative solution (link to type), but have= n't = seen any discussion on that alternative. 5. Phil's made the argument that this is needed on the "manager application= " = (client) side, which Per seems to agree with. By having something in the = YANG model, = That seems to be where we are. My interpretation is that this is the "conservative in what you send" field = whether you're sending from a client or a server. Seems an important featu= re = to me and it seems to capture the problem we're trying to solve. So we need to reach some kind of rough consensus on this. There clearly is= n't = one right now. I guess we'll keep talking. If we don't reach a seeming = consensus soon, I'm going to suggest a jabber session to discuss it. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 07:07:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E0E3A67F0; Mon, 15 Dec 2008 07:07:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED8E3A68D7 for ; Mon, 15 Dec 2008 07:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 cxbysogjY05R for ; Mon, 15 Dec 2008 07:07:49 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A69B63A67F0 for ; Mon, 15 Dec 2008 07:07:48 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2D6A2098B for ; Mon, 15 Dec 2008 16:07:39 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-99-494672697790 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 29B33207AC for ; Mon, 15 Dec 2008 16:06:17 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 16:06:16 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 16:06:16 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 15 Dec 2008 16:06:15 +0100 User-Agent: KMail/1.9.10 References: <49429FD8.7090200@netconfcentral.com> <20081212183303.GA22611@elstar.local> <4942B693.3030204@netconfcentral.com> In-Reply-To: <4942B693.3030204@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812151606.15714.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Dec 2008 15:06:16.0312 (UTC) FILETIME=[AD703F80:01C95EC6] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Friday 12 December 2008 20.08.03 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Dec 12, 2008 at 09:31:04AM -0800, Andy Bierman wrote: > >> I just noticed that sec. 9.2.1 says that octal numbers are encoded > >> as a zero followed by more octal digits. But an integer value > >> is a sign (+/-) followed by a sequence of decimal digits. > >> These rules overlap. E.g.: > >> > >> 052 octal is a legal representation of 52 decimal. > >> > >> Do we really need to support octal numbers in YANG? > >> I mean, talk about legacy. There are already 10 numeric > >> data types, and plenty of ways to specify defaults for them > >> with decimal, hexadecimal, and floating point formats. > >> > >> If yes, then a deterministic prefix is needed instead of > >> what is there now. IMO, octal should be removed from YANG. > > > > SMIng supported numbers following precisely the C language standard > > and standard conversion library functions such as strtod() etc. I > > believe this a reasonable choice. And in C, an integral number > > starting with a leading zero is considered to be an octal number. In > > other words, 052 is not a legal representation of 52 decimal and your > > C compiler is going to reject 082 as a constant. > > Well the YANG spec needs to be fixed then. > Doesn't seem like a great use-case to me though. > The ABNF does not mention octal numbers at all. > It does show that leading zeros are not allowed > on decimal numbers, but "-0" is valid. (I thought that was FP only). > The text in 9.2.1 should be fixed so it matches the ABNF. Looks like a good catch by Andy. Let's make it consistent throughout the document, one way or another. I personally see no reason to disallow octals, so I'd prefer that the doc be made consistent to include them. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 07:41:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089573A689D; Mon, 15 Dec 2008 07:41:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E6728C0F4 for ; Mon, 15 Dec 2008 07:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 8dfyoY1P5-+H for ; Mon, 15 Dec 2008 07:41:11 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2A2F73A689D for ; Mon, 15 Dec 2008 07:41:11 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4265776C521; Mon, 15 Dec 2008 16:41:03 +0100 (CET) Date: Mon, 15 Dec 2008 16:41:00 +0100 (CET) Message-Id: <20081215.164100.188577045.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200812151606.15714.david.partain@ericsson.com> References: <20081212183303.GA22611@elstar.local> <4942B693.3030204@netconfcentral.com> <200812151606.15714.david.partain@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > On Friday 12 December 2008 20.08.03 Andy Bierman wrote: > > Well the YANG spec needs to be fixed then. > > Doesn't seem like a great use-case to me though. > > The ABNF does not mention octal numbers at all. > > It does show that leading zeros are not allowed > > on decimal numbers, but "-0" is valid. (I thought that was FP only). > > The text in 9.2.1 should be fixed so it matches the ABNF. > > Looks like a good catch by Andy. Let's make it consistent throughout the > document, one way or another. I personally see no reason to disallow octals, > so I'd prefer that the doc be made consistent to include them. Note that octal and hexadecimals can be used only for default values in the YANG module, NOT in NETCONF PDUs. The reason for not allowing them on the wire is compatibility with XSD and RNG. But this maybe makes the use case for octals and hexadecimals pretty minor... Anyway, the grammar today just says: default-stmt = default-keyword sep string stmtend There is no grammar specifying what the details of the default value string (it will depend on the type). The rule 'decimal-value' is used in ranges only. So I think the current text and grammar is consistent. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 07:54:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF22D3A679C; Mon, 15 Dec 2008 07:54:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8483A6886 for ; Mon, 15 Dec 2008 07:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oTppawR3wGx1 for ; Mon, 15 Dec 2008 07:54:39 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D966D3A679C for ; Mon, 15 Dec 2008 07:54:38 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1742C206A6; Mon, 15 Dec 2008 16:54:31 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-f6-49467db6d5aa Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E96A920438; Mon, 15 Dec 2008 16:54:30 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 16:54:30 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 16:54:30 +0100 From: David Partain Organization: Ericsson AB To: Martin Bjorklund Date: Mon, 15 Dec 2008 16:54:29 +0100 User-Agent: KMail/1.9.10 References: <20081212183303.GA22611@elstar.local> <200812151606.15714.david.partain@ericsson.com> <20081215.164100.188577045.mbj@tail-f.com> In-Reply-To: <20081215.164100.188577045.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812151654.30054.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Dec 2008 15:54:30.0564 (UTC) FILETIME=[6A8C0E40:01C95ECD] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Monday 15 December 2008 16.41.00 Martin Bjorklund wrote: > David Partain wrote: > > On Friday 12 December 2008 20.08.03 Andy Bierman wrote: > > > Well the YANG spec needs to be fixed then. > > > Doesn't seem like a great use-case to me though. > > > The ABNF does not mention octal numbers at all. > > > It does show that leading zeros are not allowed > > > on decimal numbers, but "-0" is valid. (I thought that was FP only). > > > The text in 9.2.1 should be fixed so it matches the ABNF. > > > > Looks like a good catch by Andy. Let's make it consistent throughout the > > document, one way or another. I personally see no reason to disallow > > octals, so I'd prefer that the doc be made consistent to include them. > > Note that octal and hexadecimals can be used only for default values > in the YANG module, NOT in NETCONF PDUs. The reason for not allowing > them on the wire is compatibility with XSD and RNG. But this maybe > makes the use case for octals and hexadecimals pretty minor... > > Anyway, the grammar today just says: > > default-stmt = default-keyword sep string stmtend > > There is no grammar specifying what the details of the default value > string (it will depend on the type). The rule 'decimal-value' is used > in ranges only. > > So I think the current text and grammar is consistent. I'm happy if others are happy.... Octal is pretty ... um ... ancient (but so am I), so I don't think this is a big deal :-) David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 08:01:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD443A6816; Mon, 15 Dec 2008 08:01:57 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA383A68CD for ; Mon, 15 Dec 2008 08:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.055, 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 FSDMSgFm0ZQ9 for ; Mon, 15 Dec 2008 08:01:55 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 3F9A83A6886 for ; Mon, 15 Dec 2008 08:01:55 -0800 (PST) Received: (qmail 54385 invoked from network); 15 Dec 2008 16:01:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 15 Dec 2008 16:01:46 -0000 X-YMail-OSG: TCb5QL4VM1n8rlT8dax4Zkqvl7VldGL_4106y2BhdGVr_tWCRR88fiAd7ifZb.CZHRTs9naX5tYw9_tudHPoybu_YTTV7TkdnTp5DEGJmA8ILewq8O7kVj7wBOH.QtQvGJxwn10CKAZ69RVp_vBMoWwX2ksDAt37nbqn0cxFuKS0EWSY8M4Wgqu3R_xKag-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49467F68.1040705@netconfcentral.com> Date: Mon, 15 Dec 2008 08:01:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081212183303.GA22611@elstar.local> <4942B693.3030204@netconfcentral.com> <200812151606.15714.david.partain@ericsson.com> <20081215.164100.188577045.mbj@tail-f.com> In-Reply-To: <20081215.164100.188577045.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > David Partain wrote: >> On Friday 12 December 2008 20.08.03 Andy Bierman wrote: >>> Well the YANG spec needs to be fixed then. >>> Doesn't seem like a great use-case to me though. >>> The ABNF does not mention octal numbers at all. >>> It does show that leading zeros are not allowed >>> on decimal numbers, but "-0" is valid. (I thought that was FP only). >>> The text in 9.2.1 should be fixed so it matches the ABNF. >> Looks like a good catch by Andy. Let's make it consistent throughout the >> document, one way or another. I personally see no reason to disallow octals, >> so I'd prefer that the doc be made consistent to include them. > > Note that octal and hexadecimals can be used only for default values > in the YANG module, NOT in NETCONF PDUs. The reason for not allowing > them on the wire is compatibility with XSD and RNG. But this maybe > makes the use case for octals and hexadecimals pretty minor... > > Anyway, the grammar today just says: > > default-stmt = default-keyword sep string stmtend > > There is no grammar specifying what the details of the default value > string (it will depend on the type). The rule 'decimal-value' is used > in ranges only. > > So I think the current text and grammar is consistent. > There is no ABNF for an octal or hexadecimal numbers. Sec. 9.2.1 could be more clear that: - a leading zero in a number without a decimal point means it MUST be interpreted as an octal number - XML and XPath encoding of numbers are always IEEE 754 floating point. This section is only for YANG numbers in default-stmt strings. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 08:05:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D86A3A6816; Mon, 15 Dec 2008 08:05:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472173A68E3 for ; Mon, 15 Dec 2008 08:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 AvldiNKIY1vk for ; Mon, 15 Dec 2008 08:05:46 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E2E0E3A6816 for ; Mon, 15 Dec 2008 08:05:45 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ED8EF20A33 for ; Mon, 15 Dec 2008 17:05:37 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-3e-49468051cb14 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D4E4420450 for ; Mon, 15 Dec 2008 17:05:37 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 17:05:37 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 17:05:37 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 15 Dec 2008 17:05:37 +0100 User-Agent: KMail/1.9.10 References: <493747E9.6070801@netconfcentral.com> <20081204144443.GA11879@elstar.local> <4937EFF6.2050905@netconfcentral.com> In-Reply-To: <4937EFF6.2050905@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812151705.37161.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Dec 2008 16:05:37.0616 (UTC) FILETIME=[F8241D00:01C95ECE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, > Juergen Schoenwaelder wrote: > > On Thu, Dec 04, 2008 at 06:33:03AM -0800, Andy Bierman wrote: > >> IMO, feature() is cleaner and much more versatile than if-feature. > >> Why invent yet another filtering mechanism with if-feature > >> or if-capability? > > > > I am with Phil and Martin on this. The when expression is conceptually > > evaluated against the data tree at runtime as far as I can tell. The > > feature mechanism is conceptually evaluated at compile time and not > > really against the data tree if I understand things correctly. > > > > If your argument is that a simple feature selection is not expressive > > enough, then the solution should be to make the if-feature argument an > > (xpath?) expression rather than a qname. I agree with J=FCrgen. On Thursday 04 December 2008 15.57.58 Andy Bierman wrote: > Then I strongly oppose the if-feature mechanism. > I do not want #ifdef in YANG. That's exactly how I've thought of if-feature (despite the fact that #ifdef = might be something people are allergic to) and think that it's a reality th= at = the language should deal with. As Phil wrote, I think that "YANG needs the feature mechanism to allow the data modelers to express the fact that portions of their data model are optional." (Chair hat on) I agree with Andy that this issue can be closed... Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 08:30:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A4D3A6816; Mon, 15 Dec 2008 08:30:21 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E123A687A for ; Mon, 15 Dec 2008 08:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.053, 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 tdxwkkbw9z0U for ; Mon, 15 Dec 2008 08:30:19 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 82FDB3A6816 for ; Mon, 15 Dec 2008 08:30:19 -0800 (PST) Received: (qmail 72375 invoked from network); 15 Dec 2008 16:30:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 15 Dec 2008 16:30:10 -0000 X-YMail-OSG: 4K56OAYVM1m3Iz4pIpnTpK_Uyo7b1XK2qsnUgt2p7hkIQYPZ61henJcOZmS2XyHCIYKEuf7eFFpoN0P2gsXo.Xdvr88xB628SLE8idAJnN1ZUhMiskbzZNWaWuHlFgylPmvosOP5ohy7rPwAakIBPTFQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <49468610.10407@netconfcentral.com> Date: Mon, 15 Dec 2008 08:30:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: David Partain References: <493747E9.6070801@netconfcentral.com> <20081204144443.GA11879@elstar.local> <4937EFF6.2050905@netconfcentral.com> <200812151705.37161.david.partain@ericsson.com> In-Reply-To: <200812151705.37161.david.partain@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] capability() and feature() X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Hi, > = >> Juergen Schoenwaelder wrote: >>> On Thu, Dec 04, 2008 at 06:33:03AM -0800, Andy Bierman wrote: >>>> IMO, feature() is cleaner and much more versatile than if-feature. >>>> Why invent yet another filtering mechanism with if-feature >>>> or if-capability? >>> I am with Phil and Martin on this. The when expression is conceptually >>> evaluated against the data tree at runtime as far as I can tell. The >>> feature mechanism is conceptually evaluated at compile time and not >>> really against the data tree if I understand things correctly. >>> >>> If your argument is that a simple feature selection is not expressive >>> enough, then the solution should be to make the if-feature argument an >>> (xpath?) expression rather than a qname. > = > I agree with J=FCrgen. > = > On Thursday 04 December 2008 15.57.58 Andy Bierman wrote: >> Then I strongly oppose the if-feature mechanism. >> I do not want #ifdef in YANG. > = > That's exactly how I've thought of if-feature (despite the fact that #ifd= ef = > might be something people are allergic to) and think that it's a reality = that = > the language should deal with. > = > As Phil wrote, I think that "YANG needs the feature mechanism > to allow the data modelers to express the fact that portions of > their data model are optional." > = > (Chair hat on) I agree with Andy that this issue can be closed... > = I think #ifdef was a non-issue; just a mis-understanding by me on Martin's use of the term compile-time. Most of the clever things a toolset can do with YANG are traditionally out of scope in the IETF. For the purpose of YANG file validation and translation to YIN or DSDL, the if-feature-stmt has some affect. One of the valid permutations of the feature-set is 'all enabled', so it falls out that validation of the entire YANG file is required. In order to check all permutations of the if-features for a node, a compiler needs to find certain nodes that have more features attached to them than some of their ancestor nodes. yangdump checks that the child nodes specified in a key or unique statement are not 'more conditional' than their ancestors (back to the list). Also, the default case in a choice cannot be more conditional than its parent. I should do the same checks for must-stmt but that is TBD (and complicated). > Cheers, > = > David Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 09:19:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB4D3A6A22; Mon, 15 Dec 2008 09:19:47 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFDB3A6A28 for ; Mon, 15 Dec 2008 09:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 qs2HAeByyvli for ; Mon, 15 Dec 2008 09:19:45 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 26BB03A6A22 for ; Mon, 15 Dec 2008 09:19:45 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6C1B6D800C8; Mon, 15 Dec 2008 18:19:37 +0100 (CET) From: Ladislav Lhotka To: David Partain In-Reply-To: <200812151500.01010.david.partain@ericsson.com> References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <200812151500.01010.david.partain@ericsson.com> Organization: CESNET Date: Mon, 15 Dec 2008 18:19:37 +0100 Message-Id: <1229361577.7204.50.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGkgRGF2aWQsCgpmb3IgcmVjb3JkLCBJIGFsc28gc3VnZ2VzdGVkIHRvIGNvbnNpZGVyIGRlZmlu aW5nIHZhbHVlLXNwYWNlIHZhbHVlCmluc3RlYWQgb2YgY2Fub25pY2FsIGxleGljYWwgdmFsdWUu IFRoaXMgaXMgaG93IHRoZSBidWlsdC1pbiB0eXBlcyBhcmUKc3VwcG9zZWQgdG8gYmUgaW50ZXJw cmV0ZWQgYW5kIGFsc28sIGZvciBleGFtcGxlLCBSRkMgNDI5MSBkZWZpbmVzIHRoZQp2YWx1ZS1z cGFjZSB2YWx1ZSBvZiBhbiBJUHY2IGFkZHJlc3MgcXVpdGUgY2xlYXJseSBhcyAiMTI4LWJpdApp ZGVudGlmaWVyIi4gSW4gY29udHJhc3QsIGEgY2Fub25pY2FsIGxleGljYWwgZm9ybSBvZiBhbiBJ UHY2IGFkZHJlc3MKc2VlbXMgcmF0aGVyIGNvbnRyb3ZlcnNpYWwgKCI6OjEiIGlzIHZlcnkgdXNl ZnVsKS4KCkZvciB0aGUgdGltZSBiZWluZywgdGhlIHZhbHVlLXNwYWNlIHZhbHVlIGNvdWxkIGJl IHNwZWNpZmllZCBzaW1wbHkgaW4gYQooc3BlY2lhbCkgZGVzY3JpcHRpb24gY2xhdXNlLgoKTGFk YQoKRGF2aWQgUGFydGFpbiBww63FoWUgdiBQbyAxNS4gMTIuIDIwMDggdiAxNTowMCArMDEwMDoK PiBIaSwKPiAKPiBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hlcmUgdGhpcyB0aHJlYWQgaXMu Li4gIExldCdzIHNlZSBpZiBJIGhhdmUgc29tZSBvZiAKPiBpdCByaWdodC4uLgo+IAo+IEFzIE1h cnRpbiB3cm90ZSwgd2Ugc2VlbSB0byBoYXZlIHRocmVlIG9wdGlvbnMgb24gdGhlIHRhYmxlLgo+ IAo+ICJJbiBNaW5uZWFwb2xpcyB3ZSBoYWQgdGhyZWUgYWx0ZXJuYXRpdmVzIGZvciBob3cgdG8g c3BlY2lmeSB0aGUKPiBjYW5vbmljYWwgcnVsZToKPiAKPiAgIDEpIGFzIHRleHQsIGluIHRoZSBk ZXNjcmlwdGlvbiBjbGF1c2UKPiAgIDIpIGFzIHRleHQsIGluIGEgbmV3ICdjYW5vbmljYWwnIGNs YXVzZSAobGlrZSAncmVmZXJlbmNlJykKPiAgIDMpIGluIHNvbWUga2luZCBvZiBmb3JtYWwgd2F5 Igo+IAo+IFRoZSAiZGlyZWN0aW9uIiBpbiBNaW5uZWFwb2xpcyB3YXMgMywgYWx0aG91Z2ggdGhl IHJlc3VsdCB3YXNuJ3Qgb3ZlcndoZWxtaW5nLiAgCj4gTWFydGluIHdhcyBhc2tlZCB0byB0YWtl IHRoaXMgdG8gdGhlIGxpc3QsIHdoaWNoIGhlIGhhcyBkb25lLiAgVGhhbmtzIQo+IAo+IEZyb20g dGhpcyB0aHJlYWQ6Cj4gCj4gMS4gQW5keSAmIExhZGEgaGF2ZSBzYWlkIHRoYXQgdGhleSBkbyBu b3Qgd2FudCB0byBnbyBiYWNrIHRvIE9SLWluZyB0aGUgCj4gcGF0dGVybnMuICBBcyB0ZWNobmlj YWwgY29udHJpYnV0b3IsIEkgYWdyZWUgd2l0aCBKw7xyZ2VuIHRoYXQgSSBoYXZlbid0IHNlZW4g Cj4gYW55IHJlYXNvbiB0byBjaGFuZ2UgdGhpcyBkZWNpc2lvbi4KPiAyLiBBIGZldyB2b2ljZXMg YXJlIHNheWluZyAid2FpdCB0aWxsIGFmdGVyIFNlcCAyMDA5Ii4gIEknZCBwZXJzb25hbGx5IGxp a2UgdG8gCj4gc2V0dGxlIHRoaXMgbm93IGJ1dCB1bmRlcnN0YW5kIHRoZSBzZW50aW1lbnQuLi4g IFRoZSAiY29tcHJvbWlzZSIgZ3JvdW5kIAo+IGNvdWxkIGJlIHRoYXQgd2UgZ28gd2l0aCAiMiIg YWJvdmUuCj4gMy4gQW5keSBzdWdnZXN0cyB1c2luZyBhIG5ldyBzdGF0ZW1lbnQgY2FsbGVkICdj YW5vbmljYWwtcGF0dGVybicgdGhhdCBpcyBub3QgCj4gdXNlZCBhbG9uZyB3aXRoIGFsbCB0aGUg b3RoZXIgQU5ELWVkIHBhdHRlcm5zLiAgVGhpcyBkb2Vzbid0IGNoYW5nZQo+IHRoZSB3YXkgcGF0 dGVybi1zdG10IHdvcmtzIG5vdy4KPiA0LiBKw7xyZ2VuIGhhcyBvZmZlcmVkIGEgbmV3IGFsdGVy bmF0aXZlIHNvbHV0aW9uIChsaW5rIHRvIHR5cGUpLCBidXQgaGF2ZW4ndCAKPiBzZWVuIGFueSBk aXNjdXNzaW9uIG9uIHRoYXQgYWx0ZXJuYXRpdmUuCj4gNS4gUGhpbCdzIG1hZGUgdGhlIGFyZ3Vt ZW50IHRoYXQgdGhpcyBpcyBuZWVkZWQgb24gdGhlICJtYW5hZ2VyIGFwcGxpY2F0aW9uIiAKPiAo Y2xpZW50KSBzaWRlLCB3aGljaCBQZXIgc2VlbXMgdG8gYWdyZWUgd2l0aC4gIEJ5IGhhdmluZyBz b21ldGhpbmcgaW4gdGhlIAo+IFlBTkcgbW9kZWwsIAo+IAo+IFRoYXQgc2VlbXMgdG8gYmUgd2hl cmUgd2UgYXJlLgo+IAo+IE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgdGhpcyBpcyB0aGUgImNv bnNlcnZhdGl2ZSBpbiB3aGF0IHlvdSBzZW5kIiBmaWVsZCAKPiB3aGV0aGVyIHlvdSdyZSBzZW5k aW5nIGZyb20gYSBjbGllbnQgb3IgYSBzZXJ2ZXIuICBTZWVtcyBhbiBpbXBvcnRhbnQgZmVhdHVy ZSAKPiB0byBtZSBhbmQgaXQgc2VlbXMgdG8gY2FwdHVyZSB0aGUgcHJvYmxlbSB3ZSdyZSB0cnlp bmcgdG8gc29sdmUuCj4gCj4gU28gd2UgbmVlZCB0byByZWFjaCBzb21lIGtpbmQgb2Ygcm91Z2gg Y29uc2Vuc3VzIG9uIHRoaXMuICBUaGVyZSBjbGVhcmx5IGlzbid0IAo+IG9uZSByaWdodCBub3cu ICBJIGd1ZXNzIHdlJ2xsIGtlZXAgdGFsa2luZy4gIElmIHdlIGRvbid0IHJlYWNoIGEgc2VlbWlu ZyAKPiBjb25zZW5zdXMgc29vbiwgSSdtIGdvaW5nIHRvIHN1Z2dlc3QgYSBqYWJiZXIgc2Vzc2lv biB0byBkaXNjdXNzIGl0Lgo+IAo+IENoZWVycywKPiAKPiBEYXZpZAo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+ IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1h aWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 15 13:36:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBEE3A6A41; Mon, 15 Dec 2008 13:36:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15E23A6A41 for ; Mon, 15 Dec 2008 13:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 ggvvfbrCsQuS for ; Mon, 15 Dec 2008 13:36:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A5FE93A6A43 for ; Mon, 15 Dec 2008 13:36:52 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C36FC0039; Mon, 15 Dec 2008 22:36:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mFWuPa1yrnSX; Mon, 15 Dec 2008 22:36:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00427C001A; Mon, 15 Dec 2008 22:36:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6F3348B4326; Mon, 15 Dec 2008 22:36:39 +0100 (CET) Date: Mon, 15 Dec 2008 22:36:39 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20081215213639.GB27047@elstar.local> Mail-Followup-To: Ladislav Lhotka , David Partain , netmod@ietf.org References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <200812151500.01010.david.partain@ericsson.com> <1229361577.7204.50.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1229361577.7204.50.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Dec 15, 2008 at 06:19:37PM +0100, Ladislav Lhotka wrote: > Hi David, > > for record, I also suggested to consider defining value-space value > instead of canonical lexical value. I have trouble to follow you. The value space is for most of the types clear - the canonicalization problem comes from the fact that XML ship lexical representations and not binary data. The pattern statement applies to the lexical representation - so how does normalization of the value space help us? > This is how the built-in types are supposed to be interpreted and > also, for example, RFC 4291 defines the value-space value of an IPv6 > address quite clearly as "128-bit identifier". In contrast, a > canonical lexical form of an IPv6 address seems rather controversial > ("::1" is very useful). It is possible to normalize IPv6 addresses such that the 0 compression is applied to the longest possible sequence and if there is a tie to the first one. This seems to be what several OSes seem to generate and this leads to ::1. > For the time being, the value-space value could be specified simply > in a (special) description clause. But the value space is clear - a 128 bit quantity for IPv6. The whole canonicalization issue are the many different lexical representations and moving to the value space may not help us with that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 14:42:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605FF3A687A; Mon, 15 Dec 2008 14:42:10 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F973A68FE for ; Mon, 15 Dec 2008 14:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 opC6FIn9uShM for ; Mon, 15 Dec 2008 14:42:08 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0E9C13A687A for ; Mon, 15 Dec 2008 14:42:08 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CA7C76C521; Mon, 15 Dec 2008 23:42:00 +0100 (CET) Date: Mon, 15 Dec 2008 23:41:57 +0100 (CET) Message-Id: <20081215.234157.06260201.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49467F68.1040705@netconfcentral.com> References: <200812151606.15714.david.partain@ericsson.com> <20081215.164100.188577045.mbj@tail-f.com> <49467F68.1040705@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > David Partain wrote: > >> On Friday 12 December 2008 20.08.03 Andy Bierman wrote: > >>> Well the YANG spec needs to be fixed then. > >>> Doesn't seem like a great use-case to me though. > >>> The ABNF does not mention octal numbers at all. > >>> It does show that leading zeros are not allowed > >>> on decimal numbers, but "-0" is valid. (I thought that was FP only). > >>> The text in 9.2.1 should be fixed so it matches the ABNF. > >> Looks like a good catch by Andy. Let's make it consistent throughout the > >> document, one way or another. I personally see no reason to disallow > >> octals, so I'd prefer that the doc be made consistent to include them. > > Note that octal and hexadecimals can be used only for default values > > in the YANG module, NOT in NETCONF PDUs. The reason for not allowing > > them on the wire is compatibility with XSD and RNG. But this maybe > > makes the use case for octals and hexadecimals pretty minor... > > Anyway, the grammar today just says: > > default-stmt = default-keyword sep string stmtend > > There is no grammar specifying what the details of the default value > > string (it will depend on the type). The rule 'decimal-value' is used > > in ranges only. > > So I think the current text and grammar is consistent. > > > > There is no ABNF for an octal or hexadecimal numbers. > Sec. 9.2.1 could be more clear that: > > - a leading zero in a number without a decimal point > means it MUST be interpreted as an octal number If we want to be compatible with XSD/RNG, we need to allow leading zeros in the non-canonical form. So we'll have to say that when specifying default values, leading zeros are not allowed for decimal numbers. > - XML and XPath encoding of numbers are always IEEE 754 floating point. XPath 1.0 always interprets numbers as 64 bit floating point, but I don't think we need to say anything about that here. The XML encoding is specified in the first paragraph of 9.2.1. > This section is only for YANG numbers in default-stmt strings. The second paragraph of 9.2.1 is only for defaults. The first is for XML as well. Maybe we should put the default stuff in its own subsection, to make the distinction clear. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 15:12:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50F43A6A3B; Mon, 15 Dec 2008 15:12:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE563A6A3E for ; Mon, 15 Dec 2008 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 a7WED0uGgJuj for ; Mon, 15 Dec 2008 15:12:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D151F3A6A3B for ; Mon, 15 Dec 2008 15:12:17 -0800 (PST) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F98076C521; Tue, 16 Dec 2008 00:12:09 +0100 (CET) Message-ID: <4946E448.4060705@tail-f.com> Date: Tue, 16 Dec 2008 00:12:08 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <200812151500.01010.david.partain@ericsson.com> <1229361577.7204.50.camel@missotis> <20081215213639.GB27047@elstar.local> In-Reply-To: <20081215213639.GB27047@elstar.local> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On 2008-12-15 22:36, Juergen Schoenwaelder wrote: > On Mon, Dec 15, 2008 at 06:19:37PM +0100, Ladislav Lhotka wrote: > >> This is how the built-in types are supposed to be interpreted and >> also, for example, RFC 4291 defines the value-space value of an IPv6 >> address quite clearly as "128-bit identifier". In contrast, a >> canonical lexical form of an IPv6 address seems rather controversial >> ("::1" is very useful). > > It is possible to normalize IPv6 addresses such that the 0 compression > is applied to the longest possible sequence and if there is a tie to > the first one. This seems to be what several OSes seem to generate and > this leads to ::1. [Not really a comment on value vs lexical space, but rather on the feasibility of "canonical rule as a pattern (only)".] True - but can this be expressed with a pattern? I think it just might be possible to come up with a horribly complex set of regexps that would reject all forms that didn't follow this rule, but even if it is, I'm sure that it wouldn't be possible to arrive at the rule by studying those regexps. I.e. an (informal) textual description is needed in a case like this. --Per Hedeland _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 15 15:31:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184533A69E6; Mon, 15 Dec 2008 15:31:41 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CDD3A6A1A for ; Mon, 15 Dec 2008 15:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 zBRefYVir184 for ; Mon, 15 Dec 2008 15:31:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C51083A69E6 for ; Mon, 15 Dec 2008 15:31:38 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA0F2C001A; Tue, 16 Dec 2008 00:31:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iKK-w5-8ad4Q; Tue, 16 Dec 2008 00:31:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 938F8C0070; Tue, 16 Dec 2008 00:31:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 137F48B44DF; Tue, 16 Dec 2008 00:31:22 +0100 (CET) Date: Tue, 16 Dec 2008 00:31:21 +0100 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20081215233121.GA27218@elstar.local> Mail-Followup-To: Per Hedeland , netmod@ietf.org References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <200812151500.01010.david.partain@ericsson.com> <1229361577.7204.50.camel@missotis> <20081215213639.GB27047@elstar.local> <4946E448.4060705@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4946E448.4060705@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Dec 16, 2008 at 12:12:08AM +0100, Per Hedeland wrote: > On 2008-12-15 22:36, Juergen Schoenwaelder wrote: > > On Mon, Dec 15, 2008 at 06:19:37PM +0100, Ladislav Lhotka wrote: > > > >> This is how the built-in types are supposed to be interpreted and > >> also, for example, RFC 4291 defines the value-space value of an IPv6 > >> address quite clearly as "128-bit identifier". In contrast, a > >> canonical lexical form of an IPv6 address seems rather controversial > >> ("::1" is very useful). > > > > It is possible to normalize IPv6 addresses such that the 0 compression > > is applied to the longest possible sequence and if there is a tie to > > the first one. This seems to be what several OSes seem to generate and > > this leads to ::1. > > [Not really a comment on value vs lexical space, but rather on the > feasibility of "canonical rule as a pattern (only)".] > > True - but can this be expressed with a pattern? I think it just might > be possible to come up with a horribly complex set of regexps that would > reject all forms that didn't follow this rule, but even if it is, I'm > sure that it wouldn't be possible to arrive at the rule by studying > those regexps. I.e. an (informal) textual description is needed in a > case like this. Yes. And my preference always has been to add appropriate text to the existing description clause. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 01:03:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F2E28C146; Tue, 16 Dec 2008 01:03:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0FD28C146 for ; Tue, 16 Dec 2008 01:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 zBY2ugGM9udK for ; Tue, 16 Dec 2008 01:03:57 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4D17028C13B for ; Tue, 16 Dec 2008 01:03:57 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B2BA9D800BD; Tue, 16 Dec 2008 10:03:49 +0100 (CET) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081215213639.GB27047@elstar.local> References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <200812151500.01010.david.partain@ericsson.com> <1229361577.7204.50.camel@missotis> <20081215213639.GB27047@elstar.local> Organization: CESNET Date: Tue, 16 Dec 2008 10:03:49 +0100 Message-Id: <1229418229.6694.15.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFBvIDE1LiAxMi4gMjAwOCB2IDIyOjM2ICsw MTAwOgo+IE9uIE1vbiwgRGVjIDE1LCAyMDA4IGF0IDA2OjE5OjM3UE0gKzAxMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiA+IEhpIERhdmlkLAo+ID4gCj4gPiBmb3IgcmVjb3JkLCBJIGFsc28g c3VnZ2VzdGVkIHRvIGNvbnNpZGVyIGRlZmluaW5nIHZhbHVlLXNwYWNlIHZhbHVlCj4gPiBpbnN0 ZWFkIG9mIGNhbm9uaWNhbCBsZXhpY2FsIHZhbHVlLiAKPiAKPiBJIGhhdmUgdHJvdWJsZSB0byBm b2xsb3cgeW91LiBUaGUgdmFsdWUgc3BhY2UgaXMgZm9yIG1vc3Qgb2YgdGhlIHR5cGVzCj4gY2xl YXIgLSB0aGUgY2Fub25pY2FsaXphdGlvbiBwcm9ibGVtIGNvbWVzIGZyb20gdGhlIGZhY3QgdGhh dCBYTUwgc2hpcAo+IGxleGljYWwgcmVwcmVzZW50YXRpb25zIGFuZCBub3QgYmluYXJ5IGRhdGEu IFRoZSBwYXR0ZXJuIHN0YXRlbWVudAo+IGFwcGxpZXMgdG8gdGhlIGxleGljYWwgcmVwcmVzZW50 YXRpb24gLSBzbyBob3cgZG9lcyBub3JtYWxpemF0aW9uIG9mCj4gdGhlIHZhbHVlIHNwYWNlIGhl bHAgdXM/CgpCb3RoIHBhcnRpZXMgaW4gYSBORVRDT05GIHNlc3Npb24gd2lsbCBiZSBhbGxvd2Vk IHRvIHVzZSBhbnkgbGV4aWNhbApmb3JtIGFsbG93ZWQgYnkgdGhlIGRhdGF0eXBlIChwYXR0ZXJu KSBidXQgYWxzbyByZXF1aXJlZCB0byB1c2UgdGhlCnZhbHVlLXNwYWNlIHZhbHVlIGludGVybmFs bHkgZm9yIGFsbCBjb21wYXJpc29ucywga2V5IGxvb2t1cCBldGMuCgo+IAo+ID4gVGhpcyBpcyBo b3cgdGhlIGJ1aWx0LWluIHR5cGVzIGFyZSBzdXBwb3NlZCB0byBiZSBpbnRlcnByZXRlZCBhbmQK PiA+IGFsc28sIGZvciBleGFtcGxlLCBSRkMgNDI5MSBkZWZpbmVzIHRoZSB2YWx1ZS1zcGFjZSB2 YWx1ZSBvZiBhbiBJUHY2Cj4gPiBhZGRyZXNzIHF1aXRlIGNsZWFybHkgYXMgIjEyOC1iaXQgaWRl bnRpZmllciIuIEluIGNvbnRyYXN0LCBhCj4gPiBjYW5vbmljYWwgbGV4aWNhbCBmb3JtIG9mIGFu IElQdjYgYWRkcmVzcyBzZWVtcyByYXRoZXIgY29udHJvdmVyc2lhbAo+ID4gKCI6OjEiIGlzIHZl cnkgdXNlZnVsKS4KPiAKPiBJdCBpcyBwb3NzaWJsZSB0byBub3JtYWxpemUgSVB2NiBhZGRyZXNz ZXMgc3VjaCB0aGF0IHRoZSAwIGNvbXByZXNzaW9uCj4gaXMgYXBwbGllZCB0byB0aGUgbG9uZ2Vz dCBwb3NzaWJsZSBzZXF1ZW5jZSBhbmQgaWYgdGhlcmUgaXMgYSB0aWUgdG8KPiB0aGUgZmlyc3Qg b25lLiBUaGlzIHNlZW1zIHRvIGJlIHdoYXQgc2V2ZXJhbCBPU2VzIHNlZW0gdG8gZ2VuZXJhdGUg YW5kCj4gdGhpcyBsZWFkcyB0byA6OjEuCj4gCj4gPiBGb3IgdGhlIHRpbWUgYmVpbmcsIHRoZSB2 YWx1ZS1zcGFjZSB2YWx1ZSBjb3VsZCBiZSBzcGVjaWZpZWQgc2ltcGx5Cj4gPiBpbiBhIChzcGVj aWFsKSBkZXNjcmlwdGlvbiBjbGF1c2UuCj4gCj4gQnV0IHRoZSB2YWx1ZSBzcGFjZSBpcyBjbGVh ciAtIGEgMTI4IGJpdCBxdWFudGl0eSBmb3IgSVB2Ni4gVGhlIHdob2xlCj4gY2Fub25pY2FsaXph dGlvbiBpc3N1ZSBhcmUgdGhlIG1hbnkgZGlmZmVyZW50IGxleGljYWwgcmVwcmVzZW50YXRpb25z Cj4gYW5kIG1vdmluZyB0byB0aGUgdmFsdWUgc3BhY2UgbWF5IG5vdCBoZWxwIHVzIHdpdGggdGhh dC4KClRoaXMgZGlzc2N1c3Npb24gc3RhcnRlZCB3aXRoIHRoZSBwcm9ibGVtIG9mIGNvbXBhcmlu ZyBsaXN0IGtleXMgdGhhdApoYXZlIGRpZmZlcmVudCBsZXhpY2FsIHJlcHJlc2VudGF0aW9ucyBi dXQgaWRlbnRpY2FsIHZhbHVlLiBTbyBpdCBzZWVtcwpsb2dpY2FsIHRvIHVzZSB0aGUgdmFsdWUg YXMgdGhlIGRpc2NyaW1pbmF0aW5nIGZhY3Rvci4gQSBsaXN0IGl0ZW0gd2l0aAprZXkgIjMiIGNv dWxkIHRoZW4gYmUgYWRkcmVzc2VkIHdpdGggZWl0aGVyICIzIiBvciAiKzMiIG9yICIwMyIsIGlm IGFsbAp0aHJlZSBmb3JtcyBhcmUgbGVnYWwgbGV4aWNhbCByZXByZXNlbnRhdGlvbnMgZm9yIHRo ZSBnaXZlbiB0eXBlLiBOb3RlCnRoYXQgWFBhdGggZXZlbiBhbGxvd3MgdG8gdXNlICIyKjEuNSIg aW4gdGhpcyBjYXNlLgoKTGFkYQoKPiAKPiAvanMKPiAKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VT TkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Dec 16 01:19:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135AD3A67AD; Tue, 16 Dec 2008 01:19:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADFB3A6830 for ; Tue, 16 Dec 2008 01:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 CcDhIN8m4e9m for ; Tue, 16 Dec 2008 01:19:35 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C54B93A67AD for ; Tue, 16 Dec 2008 01:19:35 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8E784D800EE for ; Tue, 16 Dec 2008 10:19:28 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4946E448.4060705@tail-f.com> References: <20081210.234217.140956221.mbj@tail-f.com> <49404AF3.9080406@netconfcentral.com> <200812151500.01010.david.partain@ericsson.com> <1229361577.7204.50.camel@missotis> <20081215213639.GB27047@elstar.local> <4946E448.4060705@tail-f.com> Organization: CESNET Date: Tue, 16 Dec 2008 10:19:28 +0100 Message-Id: <1229419168.6694.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGVyIEhlZGVsYW5kIHDDrcWhZSB2IMOadCAxNi4gMTIuIDIwMDggdiAwMDoxMiArMDEwMDoKPiBP biAyMDA4LTEyLTE1IDIyOjM2LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6Cj4gPiBPbiBN b24sIERlYyAxNSwgMjAwOCBhdCAwNjoxOTozN1BNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3Jv dGU6Cj4gPiAKPiA+PiBUaGlzIGlzIGhvdyB0aGUgYnVpbHQtaW4gdHlwZXMgYXJlIHN1cHBvc2Vk IHRvIGJlIGludGVycHJldGVkIGFuZAo+ID4+IGFsc28sIGZvciBleGFtcGxlLCBSRkMgNDI5MSBk ZWZpbmVzIHRoZSB2YWx1ZS1zcGFjZSB2YWx1ZSBvZiBhbiBJUHY2Cj4gPj4gYWRkcmVzcyBxdWl0 ZSBjbGVhcmx5IGFzICIxMjgtYml0IGlkZW50aWZpZXIiLiBJbiBjb250cmFzdCwgYQo+ID4+IGNh bm9uaWNhbCBsZXhpY2FsIGZvcm0gb2YgYW4gSVB2NiBhZGRyZXNzIHNlZW1zIHJhdGhlciBjb250 cm92ZXJzaWFsCj4gPj4gKCI6OjEiIGlzIHZlcnkgdXNlZnVsKS4KPiA+IAo+ID4gSXQgaXMgcG9z c2libGUgdG8gbm9ybWFsaXplIElQdjYgYWRkcmVzc2VzIHN1Y2ggdGhhdCB0aGUgMCBjb21wcmVz c2lvbgo+ID4gaXMgYXBwbGllZCB0byB0aGUgbG9uZ2VzdCBwb3NzaWJsZSBzZXF1ZW5jZSBhbmQg aWYgdGhlcmUgaXMgYSB0aWUgdG8KPiA+IHRoZSBmaXJzdCBvbmUuIFRoaXMgc2VlbXMgdG8gYmUg d2hhdCBzZXZlcmFsIE9TZXMgc2VlbSB0byBnZW5lcmF0ZSBhbmQKPiA+IHRoaXMgbGVhZHMgdG8g OjoxLgo+IAo+IFtOb3QgcmVhbGx5IGEgY29tbWVudCBvbiB2YWx1ZSB2cyBsZXhpY2FsIHNwYWNl LCBidXQgcmF0aGVyIG9uIHRoZQo+IGZlYXNpYmlsaXR5IG9mICJjYW5vbmljYWwgcnVsZSBhcyBh IHBhdHRlcm4gKG9ubHkpIi5dCj4gCj4gVHJ1ZSAtIGJ1dCBjYW4gdGhpcyBiZSBleHByZXNzZWQg d2l0aCBhIHBhdHRlcm4/IEkgdGhpbmsgaXQganVzdCBtaWdodAo+IGJlIHBvc3NpYmxlIHRvIGNv bWUgdXAgd2l0aCBhIGhvcnJpYmx5IGNvbXBsZXggc2V0IG9mIHJlZ2V4cHMgdGhhdCB3b3VsZAo+ IHJlamVjdCBhbGwgZm9ybXMgdGhhdCBkaWRuJ3QgZm9sbG93IHRoaXMgcnVsZSwgYnV0IGV2ZW4g aWYgaXQgaXMsIEknbQo+IHN1cmUgdGhhdCBpdCB3b3VsZG4ndCBiZSBwb3NzaWJsZSB0byBhcnJp dmUgYXQgdGhlIHJ1bGUgYnkgc3R1ZHlpbmcKPiB0aG9zZSByZWdleHBzLiBJLmUuIGFuIChpbmZv cm1hbCkgdGV4dHVhbCBkZXNjcmlwdGlvbiBpcyBuZWVkZWQgaW4gYQo+IGNhc2UgbGlrZSB0aGlz LgoKSW4gbXkgdmlldyB0aGUgcGF0dGVybiBzdGF0ZW1lbnRzIHdpbGwgY29udGludWUgdG8gcmVz dHJpY3QganVzdCB0aGUKbGV4aWNhbCByZXByZXNlbnRhdGlvbiwgYXMgaXQgaXMgbm93LiBBY3R1 YWxseSwgZ2l2ZW4gdGhhdCB0aGUKdmFsdWUtc3BhY2UgdmFsdWUgbXVzdCBiZSBrbm93biBmb3Ig YW55IGRhdGF0eXBlIGFueXdheSwgdGhlIG9ubHkgbmV3CnRoaW5nIHdvdWxkIGJlIHRoZSByZXF1 aXJlbWVudCBvbiBib3RoIGNsaWVudCBhbmQgc2VydmVyIHRvIHVzZSB0aGlzCnZhbHVlIGludGVy bmFsbHkuIFlBTkcgaXMgc3Ryb25nbHkgdHlwZWQsIHNvIGl0IHNob3VsZG4ndCBsZWFkIHRvIGFu eQphbWJpZ3VpdGllcy4KCkxhZGEKCgo+IAo+IC0tUGVyIEhlZGVsYW5kCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0 Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBD CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2Qg bWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Dec 16 08:59:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1272F28C0F4; Tue, 16 Dec 2008 08:59:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7353028C103 for ; Tue, 16 Dec 2008 08:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.046, 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 zphHVEIXr5tc for ; Tue, 16 Dec 2008 08:58:57 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id B88D028C0F4 for ; Tue, 16 Dec 2008 08:58:57 -0800 (PST) Received: (qmail 61163 invoked from network); 16 Dec 2008 16:58:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 16 Dec 2008 16:58:48 -0000 X-YMail-OSG: eDuFHbQVM1kE3JmPQEG9PTdxzHyVqMKfc4LYpywPWvApBIU7_xfJE6J5vNS1g0DSEbrnHAFTO7_MRhHejf.ZAF_T4FFGqgH.5MxGmxJcXhlokn7BmF5TCycTqEmyYz1k8QMkPmZJbZqvnciEH_NiIk8I X-Yahoo-Newman-Property: ymail-3 Message-ID: <4947DE47.8010003@netconfcentral.com> Date: Tue, 16 Dec 2008 08:58:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I've already commented on the text needing a bit of work, but as I'm trying to implement it, I notice the text and ABNF are extremely sloppy and need to be redone. As with augment and refine, there is no text wrt/ multiple deviation statements that refer to the same target. There is no normative text to declare which deviate-arg-str values can be used with which deviate-stmt sub-clauses. deviation /foo/bar { deviate not-supported { type string; } deviate delete { type string; } } There needs to be separate ABNF sections for each of the 4 argument types. Too many nonsense permutations exist for it to be ignored. Is it an error to specify an illegal sub-clause for a target object type, or just a warning, or a silent NO-OP? leaf some-leaf { type float32; } deviation /some-leaf { deviate add { min-elements 4; } } Is it an error to specify an legal sub-clause for a target object type that doesn't exist, or just a warning, or a silent NO-OP? deviation /some-leaf { deviate delete { units "seconds"; } } What does it even mean to not support or delete the units clause? What operations are supported for type-stmt, besides the one I strongly objected to all along? deviation /some-leaf { deviate replace { type enumeration { enum on; enum off; } } } I fail to accept that devices that do this sort of thing should be tolerated and supported by the standard. One sentence that shouts in caps that this is STRONGLY DISCOURAGED is not good enough. I know we need to strike a balance between standards-value and vendors' freedom to innovate, but this is out of balance. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 10:39:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA5E3A6A80; Tue, 16 Dec 2008 10:39:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50BF3A6A80 for ; Tue, 16 Dec 2008 10:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.044, 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 v6hTiqjUzPtu for ; Tue, 16 Dec 2008 10:39:47 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 1BFEC3A6A86 for ; Tue, 16 Dec 2008 10:39:47 -0800 (PST) Received: (qmail 24371 invoked from network); 16 Dec 2008 18:39:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 16 Dec 2008 18:39:32 -0000 X-YMail-OSG: HasTRw4VM1mvQD76049GDixKgMMMDZm8F2srs91RekR2k3b2CVkZRQeqQfiCvBfMt8AKVl2k699yXPpRqsiIoL9zL7NIdwcva8WwpGV.5V36Sgdz_z4yJILWqfhggj6LNCRRVtgYH5Q3N3dtb_9TJwj1 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4947F5E2.7070100@netconfcentral.com> Date: Tue, 16 Dec 2008 10:39:30 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] empty deviation and deviate stmts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The ABNF for deviation-stmt may require empty curly braces, since all its contents are optional. Options: 1) let deviation-stmt be empty with the usual semi-colon, even though it means nothing: deviation /does/nothing; 2) add text that at least 1 clause must be entered; cannot easily represent this in the ABNF deviation /at/least/one { description | reference | deviate ... } 3) require at least 1 deviate-stmt change *(deviate-stmt stmtsep) to 1*(deviate-stmt stmtsep) deviation /does/something { deviate replace { max-elements 42; } } The same issue exists for the deviate-stmt, since all of its contents are optional, and only some are even available, based on the target object type. I think the ABNF is supposed to support this, but it doesn't: deviation /leaf/too/hard { deviate not-supported; } The must-stmt and unique-stmt deviations are confusing, except for 'add'. They do not have names, so 'delete' and 'replace' make no sense. Not-supported makes no sense for any of the sub-clauses, and only the form above seems relevant. BTW, it is not clear whether the description and reference are meant to replace to those clauses in the target, or if they are meant for the deviation-stmt itself. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 11:16:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA143A6800; Tue, 16 Dec 2008 11:16:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3283A690D for ; Tue, 16 Dec 2008 11:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 kwqrS5DXVHwR for ; Tue, 16 Dec 2008 11:16:29 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 1197F3A67F1 for ; Tue, 16 Dec 2008 11:16:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VreFR08DNTKPCivEQ1V8ogdr9FNoxDPlHFGMuecG6V1Xw7mLys4QfHW8ur5U+vPH; 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.35.88] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LCfOr-0005K5-O8 for netmod@ietf.org; Tue, 16 Dec 2008 14:16:10 -0500 Message-ID: <004c01c95fb2$f519dca0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200812151606.15714.david.partain@ericsson.com><20081215.164100.188577045.mbj@tail-f.com><49467F68.1040705@netconfcentral.com> <20081215.234157.06260201.mbj@tail-f.com> Date: Tue, 16 Dec 2008 11:17:11 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4713085f06b368c05b889161952ff3261350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.88 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, December 15, 2008 2:41 PM > Subject: Re: [netmod] octal numbers ... > XPath 1.0 always interprets numbers as 64 bit floating point, but I > don't think we need to say anything about that here. The XML encoding > is specified in the first paragraph of 9.2.1. ... What happens when the bit pattern corresponding to the octal (or hex) number would be a denormalized floating point value? Would a comparison succeed when performed against another value that happens to equal what the denormalized value would become if subjected to floating point normalization? Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 13:46:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47273A6817; Tue, 16 Dec 2008 13:46:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F203A693D for ; Tue, 16 Dec 2008 13:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] 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 9G2Wwu3NH2kq for ; Tue, 16 Dec 2008 13:46:57 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BB7313A686B for ; Tue, 16 Dec 2008 13:46:56 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A55076C51F; Tue, 16 Dec 2008 22:46:47 +0100 (CET) Date: Tue, 16 Dec 2008 22:46:45 +0100 (CET) Message-Id: <20081216.224645.51196206.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4942F75A.9060406@netconfcentral.com> References: <4942F75A.9060406@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] must/mandatory on non-config database node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > The must-stmt and mandatory=true applied to a read-only data node is > merely a schema reminder to the manager, like rpc/output, right? It is like rpc output, yes. If it is mandatory=true is must be present in an unfiltered, full-access reply to , if its parent exists. > There is no actual protocol processing point associated > with a config=false database node. If there is a violation, > it is an agent bug. Yes. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 13:49:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C8528C1AF; Tue, 16 Dec 2008 13:49:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5622928C1AA for ; Tue, 16 Dec 2008 13:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 kstPgOYVhDxn for ; Tue, 16 Dec 2008 13:49:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 76AE728C1AE for ; Tue, 16 Dec 2008 13:49:00 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1AFB376C51F; Tue, 16 Dec 2008 22:48:53 +0100 (CET) Date: Tue, 16 Dec 2008 22:48:51 +0100 (CET) Message-Id: <20081216.224851.38618640.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <004c01c95fb2$f519dca0$6801a8c0@oemcomputer> References: <49467F68.1040705@netconfcentral.com> <20081215.234157.06260201.mbj@tail-f.com> <004c01c95fb2$f519dca0$6801a8c0@oemcomputer> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Monday, December 15, 2008 2:41 PM > > Subject: Re: [netmod] octal numbers > ... > > XPath 1.0 always interprets numbers as 64 bit floating point, but I > > don't think we need to say anything about that here. The XML encoding > > is specified in the first paragraph of 9.2.1. > ... > > What happens when the bit pattern corresponding to the octal > (or hex) number would be a denormalized floating point value? I don't understand what you mean. But note that the octal and hex notation is merely syntactic sugar for default values specified in the YANG module. They are never used on-the-wire. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:05:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2012428C1A5; Tue, 16 Dec 2008 14:05:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76C328C1BC for ; Tue, 16 Dec 2008 14:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 J7Ui8RLxanCZ for ; Tue, 16 Dec 2008 14:05:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CA49C28C1A5 for ; Tue, 16 Dec 2008 14:05:27 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 52FEA76C51F; Tue, 16 Dec 2008 23:05:20 +0100 (CET) Date: Tue, 16 Dec 2008 23:05:18 +0100 (CET) Message-Id: <20081216.230518.149303067.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <493C7EF5.50804@netconfcentral.com> References: <493C7EF5.50804@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > 5.9.4: > > The encoding examples are pretty weak > and confusing. Perhaps they could match examples later in > the draft. Agreed. I have reworked them a bit, and I used the "local-storage" feature from another example in the text. > 7.18.3, para 5: > > However in some cases the cost of following the standard is heavy and > the payoff may be small. > > I suggest removing this sentence before the IESG sees it. > Including this mechanism is bad enough -- there is no need > to explore the motivations of the vendors who use it. I'm fine w/ removing this sentence. > 7.18.3.1: > > Why isn't there any status-stmt (just description and reference)? B/c a deviatation doesn't have the same life span as the other definitions. What does it mean to tell a client that I have an obsolete deviation of an object? > General: > > > There is very little discussion of how these deviations are managed. > The target platform(s) associated with the deviations are > completely left out of the data model. It is expected that > a vendor will create a different module name for each set of > deviations. All deviations within a module are assumed > to apply to all platforms that 'support' the module. > > I strongly suggest adding a standard way to associate vendor > platform identifier(s) (URI leaf-list?) with a set of deviations, > instead of magically figuring it out from the module name. I'm not sure where the magic is today? Can you make a proposal for something better than what we have now? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:13:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4338C28B797; Tue, 16 Dec 2008 14:13:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF70A28C0DD for ; Tue, 16 Dec 2008 14:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 Atz83Vek214s for ; Tue, 16 Dec 2008 14:13:24 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5C64C28B797 for ; Tue, 16 Dec 2008 14:13:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FBVuIUaZKBDc2Ly6R+GojaVziEZcmpLN1V6XfO3tcyrYNsUJdEQRdP1711jRbF/X; 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.35.88] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LCiAF-0000h4-1T for netmod@ietf.org; Tue, 16 Dec 2008 17:13:15 -0500 Message-ID: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <49467F68.1040705@netconfcentral.com><20081215.234157.06260201.mbj@tail-f.com><004c01c95fb2$f519dca0$6801a8c0@oemcomputer> <20081216.224851.38618640.mbj@tail-f.com> Date: Tue, 16 Dec 2008 14:15:02 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4660b5b05e99c285ebec89e4b6ab0d27e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.88 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, December 16, 2008 1:48 PM > Subject: Re: [netmod] octal numbers > > "Randy Presuhn" wrote: > > Hi - > > > > > From: "Martin Bjorklund" > > > To: > > > Cc: > > > Sent: Monday, December 15, 2008 2:41 PM > > > Subject: Re: [netmod] octal numbers > > ... > > > XPath 1.0 always interprets numbers as 64 bit floating point, but I > > > don't think we need to say anything about that here. The XML encoding > > > is specified in the first paragraph of 9.2.1. > > ... > > > > What happens when the bit pattern corresponding to the octal > > (or hex) number would be a denormalized floating point value? > > I don't understand what you mean. But note that the octal and hex > notation is merely syntactic sugar for default values specified in the > YANG module. They are never used on-the-wire. Tutorial picked at random: http://www.randelshofer.ch/fhw/gri/float.html#sectionnormalizednumbers http://www.randelshofer.ch/fhw/gri/float.html#chapterencodings The point is that several different 64-bit patterns (whether specified in hex or in octal) may correspond to exactly the same floating point number. Still other 64-bit patters will correspond to things which are not numbers at all. This will cause great difficulty in performing comparisons with things that are integers that happen to have these bit patterns, much less actually using the value as configuration data. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:20:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C2F28C0D7; Tue, 16 Dec 2008 14:20:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C5F28C116 for ; Tue, 16 Dec 2008 14:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 qgLr091ftIkC for ; Tue, 16 Dec 2008 14:20:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EDC7F28C0D7 for ; Tue, 16 Dec 2008 14:20:24 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5394F76C51F; Tue, 16 Dec 2008 23:20:17 +0100 (CET) Date: Tue, 16 Dec 2008 23:20:14 +0100 (CET) Message-Id: <20081216.232014.150699396.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> References: <004c01c95fb2$f519dca0$6801a8c0@oemcomputer> <20081216.224851.38618640.mbj@tail-f.com> <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Randy Presuhn" wrote: > The point is that several different 64-bit patterns (whether specified in hex > or in octal) may correspond to exactly the same floating point > number. But the octal and hexadecimal form are only used to specify default values for integer types. They are not used for floating point numbers. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:30:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99F128C19D; Tue, 16 Dec 2008 14:30:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2491428C1A7 for ; Tue, 16 Dec 2008 14:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 ETQMmkQBnrba for ; Tue, 16 Dec 2008 14:30:40 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 6AE6C28C19D for ; Tue, 16 Dec 2008 14:30:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fi7ULJuFH97RyJthmN71kwYk9QO5h0PVpykaS9gFLbamASM6Z+6PQUhBp04eeo/j; 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.35.88] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LCiQx-0003el-3x for netmod@ietf.org; Tue, 16 Dec 2008 17:30:31 -0500 Message-ID: <000801c95fce$2a1b3e60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004c01c95fb2$f519dca0$6801a8c0@oemcomputer><20081216.224851.38618640.mbj@tail-f.com><000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> Date: Tue, 16 Dec 2008 14:32:19 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e41fd798a4aa6ab949db353fbed7b8be3e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.88 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, December 16, 2008 2:20 PM > Subject: Re: [netmod] octal numbers > > "Randy Presuhn" wrote: > > The point is that several different 64-bit patterns (whether specified in hex > > or in octal) may correspond to exactly the same floating point > > number. > > But the octal and hexadecimal form are only used to specify default > values for integer types. They are not used for floating point > numbers. Ok. I'll assume the earlier comments about Xpath using floating point are a red herring. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:31:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91B628C116; Tue, 16 Dec 2008 14:31:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E0E28C116 for ; Tue, 16 Dec 2008 14:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 wx6+pTQHeDz0 for ; Tue, 16 Dec 2008 14:31:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3384F28C126 for ; Tue, 16 Dec 2008 14:31:28 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8740A76C51F; Tue, 16 Dec 2008 23:31:20 +0100 (CET) Date: Tue, 16 Dec 2008 23:31:17 +0100 (CET) Message-Id: <20081216.233117.148311949.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4947DE47.8010003@netconfcentral.com> References: <4947DE47.8010003@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > I've already commented on the text needing a bit of work, > but as I'm trying to implement it, I notice the text and > ABNF are extremely sloppy and need to be redone. > > As with augment and refine, there is no text wrt/ > multiple deviation statements that refer to the same target. I would like to state that an object MUST NOT occur in more than one deviation statement in a module, and that a property MUST NOT be deviated more than once. > There is no normative text to declare which deviate-arg-str > values can be used with which deviate-stmt sub-clauses. > > deviation /foo/bar { > deviate not-supported { > type string; > } > > deviate delete { > type string; > } > } > > There needs to be separate ABNF sections for each of the 4 > argument types. Too many nonsense permutations exist for > it to be ignored. Ok. See below for a restructured version. > Is it an error to specify an illegal sub-clause for a target > object type, or just a warning, or a silent NO-OP? > > leaf some-leaf { > type float32; > } > > deviation /some-leaf { > deviate add { > min-elements 4; > } > } Error. > Is it an error to specify an legal sub-clause for a target > object type that doesn't exist, or just a warning, or a silent NO-OP? > > deviation /some-leaf { > deviate delete { > units "seconds"; > } > } Error. > What does it even mean to not support or delete the units clause? I don't know. I removed the possibility to deviate it. /martin New grammar for deviations: deviation-stmt = deviation-keyword sep deviation-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] (deviate-not-supported-stmt / 1*(deviate-add-stmt / deviate-replace-stmt / deviate-delete-stmt)) "}" deviation-arg-str = < a string which matches the rule deviation-arg > deviation-arg = absolute-schema-nodeid deviate-not-supported-stmt = deviate-keyword sep not-supported-keyword optsep (";" / "{" stmtsep "}") deviate-add-stmt = deviate-keyword sep add-keyword optsep "{" stmtsep *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}" deviate-delete-stmt = deviate-keyword sep delete-keyword optsep "{" stmtsep *(must-stmt stmtsep) *(unique-stmt stmtsep) "}" deviate-replace-stmt = deviate-keyword sep replace-keyword optsep "{" stmtsep [type-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}" _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:33:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D53928C110; Tue, 16 Dec 2008 14:33:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35FCD28C110 for ; Tue, 16 Dec 2008 14:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Q6wCGHjR1JnW for ; Tue, 16 Dec 2008 14:33:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C79FA28C119 for ; Tue, 16 Dec 2008 14:33:23 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 47DE976C51F; Tue, 16 Dec 2008 23:33:16 +0100 (CET) Date: Tue, 16 Dec 2008 23:33:13 +0100 (CET) Message-Id: <20081216.233313.211462803.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4947F5E2.7070100@netconfcentral.com> References: <4947F5E2.7070100@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] empty deviation and deviate stmts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > > The ABNF for deviation-stmt may require empty curly braces, > since all its contents are optional. [...] > The must-stmt and unique-stmt deviations are confusing, > except for 'add'. They do not have names, so 'delete' > and 'replace' make no sense. Not-supported makes no > sense for any of the sub-clauses, and only the form above > seems relevant. I think I covered your issues in the new grammar I just sent in the other thread. > BTW, it is not clear whether the description and reference > are meant to replace to those clauses in the target, or if > they are meant for the deviation-stmt itself. They are meant for the deviation-stmt. Otherwise they would have been within a deviate add/replace. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 14:39:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5193A682B; Tue, 16 Dec 2008 14:39:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929463A68A9 for ; Tue, 16 Dec 2008 14:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 6zXoRZaPhvxy for ; Tue, 16 Dec 2008 14:39:38 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D1A003A682B for ; Tue, 16 Dec 2008 14:39:36 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4355276C51F; Tue, 16 Dec 2008 23:39:29 +0100 (CET) Date: Tue, 16 Dec 2008 23:39:27 +0100 (CET) Message-Id: <20081216.233927.158917585.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000801c95fce$2a1b3e60$6801a8c0@oemcomputer> References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "Randy Presuhn" wrote: > Ok. I'll assume the earlier comments about Xpath using floating point > are a red herring. I just wanted to understand Andy's comment: - XML and XPath encoding of numbers are always IEEE 754 floating point. I probably still don't understand what change to the text he was looking for. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 15:47:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A01B28C1CE; Tue, 16 Dec 2008 15:47:11 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAE428C1D0 for ; Tue, 16 Dec 2008 15:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, 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 n1F1GD1WnhBg for ; Tue, 16 Dec 2008 15:47:08 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id EE6CF28C1CF for ; Tue, 16 Dec 2008 15:47:08 -0800 (PST) Received: (qmail 93764 invoked from network); 16 Dec 2008 23:47:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 16 Dec 2008 23:47:00 -0000 X-YMail-OSG: n8WW41UVM1nhxna.NsVI07b8KD_el7n1JIc6ODvabZgQEut2Zgx0KWsUHUUr4i4P0jSuCF1B3NVmM1cbSP..9Wf8N6iLZhUf2nAHiP5PLyrww_o5u3lk_iQzU6Gh2uIMRJuPDXVHVQEKiW.902Tj1f5mvnLEUEuKFt8IMDpU449wU9iLgwaEFPI.m6TCW6oqQfLRpM4ZsaKLMOQMQ5G88g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49483DF0.6090100@netconfcentral.com> Date: Tue, 16 Dec 2008 15:46:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493C7EF5.50804@netconfcentral.com> <20081216.230518.149303067.mbj@tail-f.com> In-Reply-To: <20081216.230518.149303067.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: .... >> General: >> >> >> There is very little discussion of how these deviations are managed. >> The target platform(s) associated with the deviations are >> completely left out of the data model. It is expected that >> a vendor will create a different module name for each set of >> deviations. All deviations within a module are assumed >> to apply to all platforms that 'support' the module. >> >> I strongly suggest adding a standard way to associate vendor >> platform identifier(s) (URI leaf-list?) with a set of deviations, >> instead of magically figuring it out from the module name. > > I'm not sure where the magic is today? Can you make a proposal for > something better than what we have now? > I am understanding deviations a bit more now. If there is any magic, then it would have to be encoded into the module name of the deviations module. module foo { } module dev-foo-platform-A { } module dev-foo-platform-B { } If we had some NETMOD content, then we might have a standard way to distinguish platform A from B, but without that, there isn't much that can be done to make this better. IMO it would be better to provide some guidance in this area, so people understand at least one of the potentially many use-cases. A compiler also may need to special-case a deviations-only module. It is not clear if these modules should be included in the PDU. The namespace-stmt has no other purpose in this kind of module. It is not clear at all why the NETMOD WG has decided (within the syntax on the capability-URI) that all deviations are grouped by module in a tight 1:1 mapping. It might make better sense for some vendors to maintain one deviations file per platform. The deviation target implicitly specifies the module, so there is no need for a CLR to prevent this: module dev-platform-A { namespace "does-not-matter"; prefix "not-used"; revision 2008-12-16; import foo { prefix foo; revision 2008-12-01; } import bar { prefix bar; revision 2008-11-14; } deviation /foo:some-leaf { ... } deviation /bar:some-container { ... } } > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 16:09:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBE628C137; Tue, 16 Dec 2008 16:09:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFBAF28C1A5 for ; Tue, 16 Dec 2008 16:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.042, 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 ZWARUUzI841c for ; Tue, 16 Dec 2008 16:09:25 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 124A028C137 for ; Tue, 16 Dec 2008 16:09:24 -0800 (PST) Received: (qmail 228 invoked from network); 17 Dec 2008 00:09:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 00:09:15 -0000 X-YMail-OSG: HY4J9G0VM1mlmrY2OEtC8PbgzTANV9LU0Wb3qH97jjtV661dCK9NYc2yE2jlxE.tf64YBCYjglVlIWZMNZbRmg1UmEGiDuLnO2qM8rDDEJg95ZaQVaoUutjPfDJyRr36jMixuHmqEFKQEDVXFyFBq22Euje.KwEyHXFjYrCmqGEJZUaZrAViPHWZwfDbsST.f6a8xLmiQnrsQJ7zxieRJw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4948432A.6020401@netconfcentral.com> Date: Tue, 16 Dec 2008 16:09:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4947DE47.8010003@netconfcentral.com> <20081216.233117.148311949.mbj@tail-f.com> In-Reply-To: <20081216.233117.148311949.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I've already commented on the text needing a bit of work, >> but as I'm trying to implement it, I notice the text and >> ABNF are extremely sloppy and need to be redone. >> >> As with augment and refine, there is no text wrt/ >> multiple deviation statements that refer to the same target. > > I would like to state that an object MUST NOT occur in more than one > deviation statement in a module, and that a property MUST NOT be > deviated more than once. > >> There is no normative text to declare which deviate-arg-str >> values can be used with which deviate-stmt sub-clauses. >> >> deviation /foo/bar { >> deviate not-supported { >> type string; >> } >> >> deviate delete { >> type string; >> } >> } >> >> There needs to be separate ABNF sections for each of the 4 >> argument types. Too many nonsense permutations exist for >> it to be ignored. > > Ok. See below for a restructured version. > much much better >> Is it an error to specify an illegal sub-clause for a target >> object type, or just a warning, or a silent NO-OP? >> >> leaf some-leaf { >> type float32; >> } >> >> deviation /some-leaf { >> deviate add { >> min-elements 4; >> } >> } > > Error. > >> Is it an error to specify an legal sub-clause for a target >> object type that doesn't exist, or just a warning, or a silent NO-OP? >> >> deviation /some-leaf { >> deviate delete { >> units "seconds"; >> } >> } > > Error. > >> What does it even mean to not support or delete the units clause? > > I don't know. I removed the possibility to deviate it. > > > /martin > > > New grammar for deviations: > > > > > deviation-stmt = deviation-keyword sep > deviation-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > [description-stmt stmtsep] > [reference-stmt stmtsep] > (deviate-not-supported-stmt / > 1*(deviate-add-stmt / > deviate-replace-stmt / > deviate-delete-stmt)) > "}" > > deviation-arg-str = < a string which matches the rule > deviation-arg > > > deviation-arg = absolute-schema-nodeid > > deviate-not-supported-stmt = > deviate-keyword sep > not-supported-keyword optsep > (";" / > "{" stmtsep > "}") > > deviate-add-stmt = deviate-keyword sep add-keyword optsep > "{" stmtsep > *(must-stmt stmtsep) > *(unique-stmt stmtsep) > [default-stmt stmtsep] > [config-stmt stmtsep] > [mandatory-stmt stmtsep] > [min-elements-stmt stmtsep] > [max-elements-stmt stmtsep] > "}" > > deviate-delete-stmt = deviate-keyword sep delete-keyword optsep > "{" stmtsep > *(must-stmt stmtsep) > *(unique-stmt stmtsep) > "}" > This one is tricky. How are the comparisons of two must-stmts or two unique-stmts done? Is whitespace normalized somehow? Are prefix differences ignored? Are different representations of the same object ignored? (e.g., ../foo vs. /top/foo). Does unique order matter? (e.g., does unique "foo bar" match unique "bar foo") Implementing this in a interoperable way seems difficult. > deviate-replace-stmt = deviate-keyword sep replace-keyword optsep > "{" stmtsep > [type-stmt stmtsep] > [default-stmt stmtsep] > [config-stmt stmtsep] > [mandatory-stmt stmtsep] > [min-elements-stmt stmtsep] > [max-elements-stmt stmtsep] > "}" > > > Are there going to be any rules or guidelines on type-stmt? This one looks real easy in the 1 line ABNF, but the type-stmt is massive. In the worst use-case, a vendor could claim partial conformance to a standard data model by implementing the shells of the data nodes, and then using deviations to replace all the guts of all the objects with their proprietary versions. As far as figuring out the true contents of the module that the agent implements -- that gets much harder to do with just eyeballs, thanks to this deviation-stmt. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 18:12:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C33B3A68F9; Tue, 16 Dec 2008 18:12:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BD13A69C5 for ; Tue, 16 Dec 2008 18:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.041, 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 bU-WpyCHftRn for ; Tue, 16 Dec 2008 18:12:04 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id B07543A68F9 for ; Tue, 16 Dec 2008 18:12:04 -0800 (PST) Received: (qmail 43237 invoked from network); 17 Dec 2008 02:11:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 02:11:55 -0000 X-YMail-OSG: tRc91QoVM1lURoxZkHGRRteTA1X19Oyvj3ocIpjFNzW3JwHtwl874.nMhpUXTASrl_vR6_QNX0JkpU99KpaFoKtXmbUQnAaV8wMBsm7.HFUe0WBB0iy_C1qua7sfrFIZBnlyPUvCk1bS6aX71prZ.4GPMGsx.Whj21nGuwWH_uD1GJuqe0r4ZVzrVRSVof6m X-Yahoo-Newman-Property: ymail-3 Message-ID: <49485FEA.8070809@netconfcentral.com> Date: Tue, 16 Dec 2008 18:11:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer> <20081216.233927.158917585.mbj@tail-f.com> In-Reply-To: <20081216.233927.158917585.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > "Randy Presuhn" wrote: >> Ok. I'll assume the earlier comments about Xpath using floating point >> are a red herring. > > I just wanted to understand Andy's comment: > > - XML and XPath encoding of numbers are always IEEE 754 floating point. > > I probably still don't understand what change to the text he was > looking for. > I am trying to clarify the text. If a smart guy like Randy can get confused by the YANG vs. XPath expression number representations, then lots of people will get confused. http://www.w3.org/TR/xpath#numbers BTW, it is not just the default-stmt. Numbers also show up in min-elements, max-elements, ranges, and patterns. Inside XPath strings like the must-stmt or when-stmt argument, the YANG rules do not apply, just the XPath rules. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 16 22:13:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEA43A689C; Tue, 16 Dec 2008 22:13:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604933A6963 for ; Tue, 16 Dec 2008 22:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 LCNK1YSkw+Nt for ; Tue, 16 Dec 2008 22:13:34 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 2D62B3A689C for ; Tue, 16 Dec 2008 22:13:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JYYkzOUbLbLOC0djdRGEq7thzuDJk1Laer0816fwh6AN8b3PFUsoJPRL4ruse28C; 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 [66.167.206.7] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LCpew-0004py-Gm for netmod@ietf.org; Wed, 17 Dec 2008 01:13:26 -0500 Message-ID: <010a01c9600e$d4e732a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer> <20081216.233927.158917585.mbj@tail-f.com> <49485FEA.8070809@netconfcentral.com> Date: Tue, 16 Dec 2008 22:15:16 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4a78364dbdf391a7c085d81b3aacfc787350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.7 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Martin Bjorklund" > Cc: ; > Sent: Tuesday, December 16, 2008 6:11 PM > Subject: Re: [netmod] octal numbers ... > I am trying to clarify the text. > If a smart guy like Randy can get confused by the YANG vs. XPath > expression number representations, then lots of people will get confused. > > http://www.w3.org/TR/xpath#numbers > > BTW, it is not just the default-stmt. > Numbers also show up in min-elements, max-elements, ranges, > and patterns. > > Inside XPath strings like the must-stmt or when-stmt argument, > the YANG rules do not apply, just the XPath rules. I admit to being rather confused here. If XPath uses IEE 754, then there are plenty of 64-bit integers that cannot be represented, or, worse still, will be treated as being equal to other 64-bit integers that have different bit patterns. This would seem to be a potential trap for the unwary. Limiting the use of integer values to only those values that will survive the IEEE 754 <-> integer round trip unscathed seems a scary prospect. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 01:01:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFF23A681D; Wed, 17 Dec 2008 01:01:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83EB3A6831 for ; Wed, 17 Dec 2008 01:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 tQ0zmRCBDkie for ; Wed, 17 Dec 2008 01:01:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6B6473A681D for ; Wed, 17 Dec 2008 01:01:46 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FDCF76C531; Wed, 17 Dec 2008 10:01:36 +0100 (CET) Date: Wed, 17 Dec 2008 10:01:36 +0100 (CET) Message-Id: <20081217.100136.179413214.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49483DF0.6090100@netconfcentral.com> References: <493C7EF5.50804@netconfcentral.com> <20081216.230518.149303067.mbj@tail-f.com> <49483DF0.6090100@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > It is not clear if these modules should be > included in the PDU. The namespace-stmt has no > other purpose in this kind of module. That is the idea. The text is reworked to make this more clear in the upcoming -03 draft. > It is not clear at all why the NETMOD WG has decided > (within the syntax on the capability-URI) that all > deviations are grouped by module in a tight 1:1 mapping. > > It might make better sense for some vendors to maintain > one deviations file per platform. This is supported already, see below. The mapping between modules and deviations is actually N:M. > The deviation target > implicitly specifies the module, so there is no need > for a CLR to prevent this: > > module dev-platform-A { > > namespace "does-not-matter"; > prefix "not-used"; > > revision 2008-12-16; > > import foo { > prefix foo; > revision 2008-12-01; > } > > import bar { > prefix bar; > revision 2008-11-14; > } > > deviation /foo:some-leaf { ... } > > deviation /bar:some-container { ... } > > } So in this case, the would include: http://example.com/foo?deviations=dev-platform-A http://example.com/bar?deviations=dev-platform-A does-not-matter?module=dev-platform-A Also note that a module can have multiple deviations: http://example.com/foo?deviations=dev-platform-A,dev-common /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 01:18:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972473A6AFC; Wed, 17 Dec 2008 01:18:05 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DEF28C0DE for ; Wed, 17 Dec 2008 01:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 WgjFhqFyf3av for ; Wed, 17 Dec 2008 01:17:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 310D63A6AC8 for ; Wed, 17 Dec 2008 01:17:59 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id ADF6A76C521; Wed, 17 Dec 2008 10:17:51 +0100 (CET) Date: Wed, 17 Dec 2008 10:17:49 +0100 (CET) Message-Id: <20081217.101749.22020128.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4948432A.6020401@netconfcentral.com> References: <4947DE47.8010003@netconfcentral.com> <20081216.233117.148311949.mbj@tail-f.com> <4948432A.6020401@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > > deviate-delete-stmt = deviate-keyword sep delete-keyword optsep > > "{" stmtsep > > *(must-stmt stmtsep) > > *(unique-stmt stmtsep) > > "}" > > > > This one is tricky. > How are the comparisons of two must-stmts or two unique-stmts done? > Is whitespace normalized somehow? Are prefix differences ignored? > Are different representations of the same object ignored? > (e.g., ../foo vs. /top/foo). The spec says: the argument's string MUST be equal to the corresponding keyword's argument string in the target node. I.e. the string values (after normal YANG string interpretation rules, concatenation etc) must match exactly, including prefixes etc. This is IMO the only workable solution - yes it might be cumbersome for the writer of the 'deviate' statement, but this is a corner case that is not recommended anyway, so I don't think we need to optimize for this case. > > deviate-replace-stmt = deviate-keyword sep replace-keyword optsep > > "{" stmtsep > > [type-stmt stmtsep] > > [default-stmt stmtsep] > > [config-stmt stmtsep] > > [mandatory-stmt stmtsep] > > [min-elements-stmt stmtsep] > > [max-elements-stmt stmtsep] > > "}" > > > > Are there going to be any rules or guidelines on type-stmt? > This one looks real easy in the 1 line ABNF, > but the type-stmt is massive. > > In the worst use-case, a vendor could claim partial conformance > to a standard data model by implementing the shells of the > data nodes, and then using deviations to replace all the guts > of all the objects with their proprietary versions. But a vendor can claim anything, regardless of the deviation statement. Just b/c they specify how broken they are does not make them more compliant. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 03:27:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F261928C191; Wed, 17 Dec 2008 03:27:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F1828C191 for ; Wed, 17 Dec 2008 03:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.040, 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 k9WvV2pe-w28 for ; Wed, 17 Dec 2008 03:27:48 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 59DB928C1A9 for ; Wed, 17 Dec 2008 03:27:48 -0800 (PST) Received: (qmail 64638 invoked from network); 17 Dec 2008 11:27:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 11:27:38 -0000 X-YMail-OSG: ZyU6yNkVM1mJEX5kDk98tlsXlP_LxXy7PLNlVsFfX1bln3IH3RJPd.almwkFwXghgLvYEGF5dgvIcHF1sVO1cy8D6svjvATQQPpgKV.iLeYALZx89ZK5bdHtU_fP0bkDhPW9Jx50pgTeWov1ccdusqmIDUHJPE_ZgAB2Np8BmfaI9yOsGi5oA5O2hLwm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4948E228.40604@netconfcentral.com> Date: Wed, 17 Dec 2008 03:27:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <493C7EF5.50804@netconfcentral.com> <20081216.230518.149303067.mbj@tail-f.com> <49483DF0.6090100@netconfcentral.com> <20081217.100136.179413214.mbj@tail-f.com> In-Reply-To: <20081217.100136.179413214.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> It is not clear if these modules should be >> included in the PDU. The namespace-stmt has no >> other purpose in this kind of module. > > That is the idea. The text is reworked to make this more clear in the > upcoming -03 draft. > >> It is not clear at all why the NETMOD WG has decided >> (within the syntax on the capability-URI) that all >> deviations are grouped by module in a tight 1:1 mapping. >> >> It might make better sense for some vendors to maintain >> one deviations file per platform. > > This is supported already, see below. The mapping between modules and > deviations is actually N:M. > >> The deviation target >> implicitly specifies the module, so there is no need >> for a CLR to prevent this: >> >> module dev-platform-A { >> >> namespace "does-not-matter"; >> prefix "not-used"; >> >> revision 2008-12-16; >> >> import foo { >> prefix foo; >> revision 2008-12-01; >> } >> >> import bar { >> prefix bar; >> revision 2008-11-14; >> } >> >> deviation /foo:some-leaf { ... } >> >> deviation /bar:some-container { ... } >> >> } > > So in this case, the would include: > > http://example.com/foo?deviations=dev-platform-A > http://example.com/bar?deviations=dev-platform-A > does-not-matter?module=dev-platform-A > > Also note that a module can have multiple deviations: > > > http://example.com/foo?deviations=dev-platform-A,dev-common > > > Also note that the ?deviatations=a,b,c encoding is completely redundant and pointless. The namespace URI of the deviations module does matter. It is just one more capability getting advertised: http://example.com/foo http://example.com/bar does-not-matter Simply advertising the deviations module is enough. Since any module can contain any deviation (they are not constrained to local objects), the only way to gather all of them is to read in all the modules anyway. The deviation target completely identifies the object being altered. The extra "deviations=blah,blah" is completely useless. > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 04:16:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B765F3A691F; Wed, 17 Dec 2008 04:16:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A67D3A693A for ; Wed, 17 Dec 2008 04:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 6YmetWX0XwN8 for ; Wed, 17 Dec 2008 04:16:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9D0D63A6452 for ; Wed, 17 Dec 2008 04:16:17 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 68D6976C521 for ; Wed, 17 Dec 2008 13:16:09 +0100 (CET) Date: Wed, 17 Dec 2008 13:16:09 +0100 (CET) Message-Id: <20081217.131609.55656045.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1229419168.6694.25.camel@missotis> References: <20081215213639.GB27047@elstar.local> <4946E448.4060705@tail-f.com> <1229419168.6694.25.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Our problem is that there are three different comparisons being done, and we want them all to do the right thing. The three are: 1. Comparing key values in edit-config. We want to use the value-space value here, not any lexical representation. This should not be a problem, but we don't use the term "value space" currently. Maybe we should. 2. XPath 1.0 comparison in filtering and must/when expressions. This is by definition done on the string representation of the value (possibly interpreted as a number by XPath). By always using the canonical lexical form, we ensure that comparisons can be done consistently. (*) 3. Subtree filtering content match comparisons. Same as (2) above, except that it defines its own whitespace trimming rules (leading and trailing whitespaces are removed). (*) This works well as long as all types have a canonical lexical form. Unfortunately, we have two types that don't, 'instance-identifier' and 'identityref'. The lexical representation of values of these types depend on the XML context in which they occur. Specifically they both use namespace prefixes defined in surrounding XML elements. For (1) above, where comparisons are done in the value space, this is not a problem. But for (2) and (3) these types cannot be correctly compared (unless the client uses the same prefixes as the server, which we cannot assume.) I think we need to introduce the term "value space" in the spec, to cover (1) above. (if all types could have a canonical lexical form we wouldn't need this). A derived data type by default inherits the value space and canonical lexical form from its base type (constrained by any restrictions). A derived data type might have to specify the value space and, if applicable, the canonical form. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 04:27:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9003A6452; Wed, 17 Dec 2008 04:27:04 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD893A6905 for ; Wed, 17 Dec 2008 04:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 KL3fwcqq7BRi for ; Wed, 17 Dec 2008 04:26:58 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B7C213A6452 for ; Wed, 17 Dec 2008 04:26:57 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D89C76C531; Wed, 17 Dec 2008 13:26:50 +0100 (CET) Date: Wed, 17 Dec 2008 13:26:47 +0100 (CET) Message-Id: <20081217.132647.193292739.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4948E228.40604@netconfcentral.com> References: <49483DF0.6090100@netconfcentral.com> <20081217.100136.179413214.mbj@tail-f.com> <4948E228.40604@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> It is not clear if these modules should be > >> included in the PDU. The namespace-stmt has no > >> other purpose in this kind of module. > > That is the idea. The text is reworked to make this more clear in the > > upcoming -03 draft. > > > >> It is not clear at all why the NETMOD WG has decided > >> (within the syntax on the capability-URI) that all > >> deviations are grouped by module in a tight 1:1 mapping. > >> > >> It might make better sense for some vendors to maintain > >> one deviations file per platform. > > This is supported already, see below. The mapping between modules and > > deviations is actually N:M. > > > >> The deviation target > >> implicitly specifies the module, so there is no need > >> for a CLR to prevent this: > >> > >> module dev-platform-A { > >> > >> namespace "does-not-matter"; > >> prefix "not-used"; > >> > >> revision 2008-12-16; > >> > >> import foo { > >> prefix foo; > >> revision 2008-12-01; > >> } > >> > >> import bar { > >> prefix bar; > >> revision 2008-11-14; > >> } > >> > >> deviation /foo:some-leaf { ... } > >> > >> deviation /bar:some-container { ... } > >> > >> } > > So in this case, the would include: > > http://example.com/foo?deviations=dev-platform-A > > http://example.com/bar?deviations=dev-platform-A > > does-not-matter?module=dev-platform-A > > Also note that a module can have multiple deviations: > > > > http://example.com/foo?deviations=dev-platform-A,dev-common > > > > > > > Also note that the ?deviatations=a,b,c encoding is > completely redundant and pointless. > > The namespace URI of the deviations module does matter. > It is just one more capability getting advertised: > > http://example.com/foo > http://example.com/bar > does-not-matter > > Simply advertising the deviations module is enough. So when I am a client, I read this advertisement, and I know that understad http://example.com/bar. I even have this standard data model locally. But I don't understand the data model http://example.com/foo, so I skip it. I also don't understand does-not-matter, so I skip it as well. Now I just missed the device's deviations. If we don't encode the deviations a client will have to check all modules in the schema discovery list, download them all, and search for deviations. In most cases it won't even find any. With the explicit encoding, a client can immediately tell when the device does not have any deviations, and easily find them when it does. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 04:58:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC1C3A67D0; Wed, 17 Dec 2008 04:58:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AE43A6929 for ; Wed, 17 Dec 2008 04:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 2wj3PCDCGTp8 for ; Wed, 17 Dec 2008 04:58:22 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8CC6E3A68A6 for ; Wed, 17 Dec 2008 04:58:22 -0800 (PST) Received: from [195.113.219.233] (eduroam-233.cesnet.cz [195.113.219.233]) by office2.cesnet.cz (Postfix) with ESMTP id 82A77D800EE for ; Wed, 17 Dec 2008 13:58:14 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081217.131609.55656045.mbj@tail-f.com> References: <20081215213639.GB27047@elstar.local> <4946E448.4060705@tail-f.com> <1229419168.6694.25.camel@missotis> <20081217.131609.55656045.mbj@tail-f.com> Organization: CESNET Date: Wed, 17 Dec 2008 13:58:11 +0100 Message-Id: <1229518691.6175.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxMzoxNiArMDEwMDoK PiBIaSwKPiAKPiBPdXIgcHJvYmxlbSBpcyB0aGF0IHRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbnQg Y29tcGFyaXNvbnMgYmVpbmcgZG9uZSwKPiBhbmQgd2Ugd2FudCB0aGVtIGFsbCB0byBkbyB0aGUg cmlnaHQgdGhpbmcuICBUaGUgdGhyZWUgYXJlOgo+IAo+ICAgMS4gIENvbXBhcmluZyBrZXkgdmFs dWVzIGluIGVkaXQtY29uZmlnLiAgIFdlIHdhbnQgdG8gdXNlIHRoZQo+ICAgICAgIHZhbHVlLXNw YWNlIHZhbHVlIGhlcmUsIG5vdCBhbnkgbGV4aWNhbCByZXByZXNlbnRhdGlvbi4KPiAKPiAgICAg ICBUaGlzIHNob3VsZCBub3QgYmUgYSBwcm9ibGVtLCBidXQgd2UgZG9uJ3QgdXNlIHRoZSB0ZXJt ICJ2YWx1ZQo+ICAgICAgIHNwYWNlIiBjdXJyZW50bHkuICBNYXliZSB3ZSBzaG91bGQuCgorMS4g QW5kIGZvciBjZXJ0YWluIG5ldyB0eXBlcywgaXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBkZWZpbmUg d2hhdCB0aGUKKHZhbHVlLXNwYWNlKSB2YWx1ZSBpcy4KCj4gCj4gICAyLiAgWFBhdGggMS4wIGNv bXBhcmlzb24gaW4gZmlsdGVyaW5nIGFuZCBtdXN0L3doZW4gZXhwcmVzc2lvbnMuCj4gICAgICAg VGhpcyBpcyBieSBkZWZpbml0aW9uIGRvbmUgb24gdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbiBv ZiB0aGUKPiAgICAgICB2YWx1ZSAocG9zc2libHkgaW50ZXJwcmV0ZWQgYXMgYSBudW1iZXIgYnkg WFBhdGgpLgo+IAo+ICAgICAgIEJ5IGFsd2F5cyB1c2luZyB0aGUgY2Fub25pY2FsIGxleGljYWwg Zm9ybSwgd2UgZW5zdXJlIHRoYXQKPiAgICAgICBjb21wYXJpc29ucyBjYW4gYmUgZG9uZSBjb25z aXN0ZW50bHkuICgqKQoKVGhpcyBpcyBob3dldmVyIGFub3RoZXIgZGV2aWF0aW9uIGZyb20gWFBh dGggc3BlYyBhbmQgcHJhY3RpY2UuIFhQYXRoCmhhcyBub24tc3RyaW5nIHR5cGVzLCBzdXBwb3J0 cyBudW1lcmljIG9wZXJhdGlvbnMgZXRjLgogCj4gCj4gICAzLiAgU3VidHJlZSBmaWx0ZXJpbmcg Y29udGVudCBtYXRjaCBjb21wYXJpc29ucy4gIFNhbWUgYXMgKDIpIGFib3ZlLAo+ICAgICAgIGV4 Y2VwdCB0aGF0IGl0IGRlZmluZXMgaXRzIG93biB3aGl0ZXNwYWNlIHRyaW1taW5nIHJ1bGVzCj4g ICAgICAgKGxlYWRpbmcgYW5kIHRyYWlsaW5nIHdoaXRlc3BhY2VzIGFyZSByZW1vdmVkKS4KCkJ1 dCB3aGF0IGlmIHhwYXRoIGNhcGFiaWxpdHkgaXMgdXNlZD8gSXQgd2lsbCBiZSB2ZXJ5IGNvbmZ1 c2luZyBpZiB0aGUKY29tcGFyaXNvbi9tYXRjaGluZyBzZW1hbnRpY3MgaXMgZGlmZmVyZW50LgoK PiAKPiAKPiAoKikgVGhpcyB3b3JrcyB3ZWxsIGFzIGxvbmcgYXMgYWxsIHR5cGVzIGhhdmUgYSBj YW5vbmljYWwgbGV4aWNhbAo+IGZvcm0uICBVbmZvcnR1bmF0ZWx5LCB3ZSBoYXZlIHR3byB0eXBl cyB0aGF0IGRvbid0LAo+ICdpbnN0YW5jZS1pZGVudGlmaWVyJyBhbmQgJ2lkZW50aXR5cmVmJy4g IFRoZSBsZXhpY2FsIHJlcHJlc2VudGF0aW9uCj4gb2YgdmFsdWVzIG9mIHRoZXNlIHR5cGVzIGRl cGVuZCBvbiB0aGUgWE1MIGNvbnRleHQgaW4gd2hpY2ggdGhleQo+IG9jY3VyLiAgU3BlY2lmaWNh bGx5IHRoZXkgYm90aCB1c2UgbmFtZXNwYWNlIHByZWZpeGVzIGRlZmluZWQgaW4KPiBzdXJyb3Vu ZGluZyBYTUwgZWxlbWVudHMuICBGb3IgKDEpIGFib3ZlLCB3aGVyZSBjb21wYXJpc29ucyBhcmUg ZG9uZQo+IGluIHRoZSB2YWx1ZSBzcGFjZSwgdGhpcyBpcyBub3QgYSBwcm9ibGVtLiAgQnV0IGZv ciAoMikgYW5kICgzKSB0aGVzZQo+IHR5cGVzIGNhbm5vdCBiZSBjb3JyZWN0bHkgY29tcGFyZWQg KHVubGVzcyB0aGUgY2xpZW50IHVzZXMgdGhlIHNhbWUKPiBwcmVmaXhlcyBhcyB0aGUgc2VydmVy LCB3aGljaCB3ZSBjYW5ub3QgYXNzdW1lLikKPiAKPiBJIHRoaW5rIHdlIG5lZWQgdG8gaW50cm9k dWNlIHRoZSB0ZXJtICJ2YWx1ZSBzcGFjZSIgaW4gdGhlIHNwZWMsIHRvCj4gY292ZXIgKDEpIGFi b3ZlLiAgKGlmIGFsbCB0eXBlcyBjb3VsZCBoYXZlIGEgY2Fub25pY2FsIGxleGljYWwgZm9ybSB3 ZQo+IHdvdWxkbid0IG5lZWQgdGhpcykuCgpPbiB0aGUgb3RoZXIgaGFuZCwgaWYgYWxsIGNvbXBh cmlzb25zIHdlcmUgYmFzZWQgb24gdmFsdWUgc3BhY2UsIHdlCndvdWxkbid0IG5lZWQgdGhlIGNh bm9uaWNhbCBsZXhpY2FsIGZvcm0uCgpMYWRhCgo+IAo+IEEgZGVyaXZlZCBkYXRhIHR5cGUgYnkg ZGVmYXVsdCBpbmhlcml0cyB0aGUgdmFsdWUgc3BhY2UgYW5kIGNhbm9uaWNhbAo+IGxleGljYWwg Zm9ybSBmcm9tIGl0cyBiYXNlIHR5cGUgKGNvbnN0cmFpbmVkIGJ5IGFueSByZXN0cmljdGlvbnMp LiAgQQo+IGRlcml2ZWQgZGF0YSB0eXBlIG1pZ2h0IGhhdmUgdG8gc3BlY2lmeSB0aGUgdmFsdWUg c3BhY2UgYW5kLCBpZgo+IGFwcGxpY2FibGUsIHRoZSBjYW5vbmljYWwgZm9ybS4KPiAKPiAKPiAv bWFydGluCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU ClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Dec 17 05:06:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5493A6452; Wed, 17 Dec 2008 05:06:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24B428C1AA for ; Wed, 17 Dec 2008 05:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 kPTIZ9p2Ze9S for ; Wed, 17 Dec 2008 05:06:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 53EF23A693D for ; Wed, 17 Dec 2008 05:06:30 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D385D76C521; Wed, 17 Dec 2008 14:06:22 +0100 (CET) Date: Wed, 17 Dec 2008 14:06:20 +0100 (CET) Message-Id: <20081217.140620.125651739.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1229518691.6175.24.camel@missotis> References: <1229419168.6694.25.camel@missotis> <20081217.131609.55656045.mbj@tail-f.com> <1229518691.6175.24.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > > 2. XPath 1.0 comparison in filtering and must/when expressions. > > This is by definition done on the string representation of the > > value (possibly interpreted as a number by XPath). > > > > By always using the canonical lexical form, we ensure that > > comparisons can be done consistently. (*) > > This is however another deviation from XPath spec and practice. XPath > has non-string types, supports numeric operations etc. I do not try to introduce anything new here, just documenting what XPath does. Did I get it wrong? XPath has strings, numbers (64 bit float) and boolean. > > 3. Subtree filtering content match comparisons. Same as (2) above, > > except that it defines its own whitespace trimming rules > > (leading and trailing whitespaces are removed). > > But what if xpath capability is used? It will be very confusing if the > comparison/matching semantics is different. I agree. I don't like the whitespace trimming rule, but it is there in rfc4741. (it is also incompatible with the three whitespace rules XSD defines...) > > (*) This works well as long as all types have a canonical lexical > > form. Unfortunately, we have two types that don't, > > 'instance-identifier' and 'identityref'. The lexical representation > > of values of these types depend on the XML context in which they > > occur. Specifically they both use namespace prefixes defined in > > surrounding XML elements. For (1) above, where comparisons are done > > in the value space, this is not a problem. But for (2) and (3) these > > types cannot be correctly compared (unless the client uses the same > > prefixes as the server, which we cannot assume.) > > > > I think we need to introduce the term "value space" in the spec, to > > cover (1) above. (if all types could have a canonical lexical form we > > wouldn't need this). > > On the other hand, if all comparisons were based on value space, we > wouldn't need the canonical lexical form. Are you (!) suggesting that we change our usage of XPath to do comparisons based on the value-space value? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 06:03:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F38A3A6B23; Wed, 17 Dec 2008 06:03:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788C128C199 for ; Wed, 17 Dec 2008 06:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_35=0.6] 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 Nj2ZY4PeNfpS for ; Wed, 17 Dec 2008 06:03:30 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EC3D83A6B28 for ; Wed, 17 Dec 2008 06:03:29 -0800 (PST) Received: from [195.113.219.233] (eduroam-233.cesnet.cz [195.113.219.233]) by office2.cesnet.cz (Postfix) with ESMTP id 955F2D800BD; Wed, 17 Dec 2008 15:03:22 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081217.140620.125651739.mbj@tail-f.com> References: <1229419168.6694.25.camel@missotis> <20081217.131609.55656045.mbj@tail-f.com> <1229518691.6175.24.camel@missotis> <20081217.140620.125651739.mbj@tail-f.com> Organization: CESNET Date: Wed, 17 Dec 2008 15:03:22 +0100 Message-Id: <1229522602.6175.45.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxNDowNiArMDEwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gPiAgIDIuICBY UGF0aCAxLjAgY29tcGFyaXNvbiBpbiBmaWx0ZXJpbmcgYW5kIG11c3Qvd2hlbiBleHByZXNzaW9u cy4KPiA+ID4gICAgICAgVGhpcyBpcyBieSBkZWZpbml0aW9uIGRvbmUgb24gdGhlIHN0cmluZyBy ZXByZXNlbnRhdGlvbiBvZiB0aGUKPiA+ID4gICAgICAgdmFsdWUgKHBvc3NpYmx5IGludGVycHJl dGVkIGFzIGEgbnVtYmVyIGJ5IFhQYXRoKS4KPiA+ID4gCj4gPiA+ICAgICAgIEJ5IGFsd2F5cyB1 c2luZyB0aGUgY2Fub25pY2FsIGxleGljYWwgZm9ybSwgd2UgZW5zdXJlIHRoYXQKPiA+ID4gICAg ICAgY29tcGFyaXNvbnMgY2FuIGJlIGRvbmUgY29uc2lzdGVudGx5LiAoKikKPiA+IAo+ID4gVGhp cyBpcyBob3dldmVyIGFub3RoZXIgZGV2aWF0aW9uIGZyb20gWFBhdGggc3BlYyBhbmQgcHJhY3Rp Y2UuIFhQYXRoCj4gPiBoYXMgbm9uLXN0cmluZyB0eXBlcywgc3VwcG9ydHMgbnVtZXJpYyBvcGVy YXRpb25zIGV0Yy4KCldpdGggZ2VudWluZSBYUGF0aCwgYW4gYXNzZXJ0IGxpa2UKCm11c3QgImZv bzpjb3VudCA9IDErMSI7Cgp3b3VsZCBiZSBzYXRpc2ZpZWQgd2hldGhlciB0aGUgZm9vOmNvdW50 IHZhbHVlIHdhcyBzZXQgaW4gZWRpdC1jb25maWcgYXMKMiBvciAyLjAuIEkgZG9uJ3Qgc2VlIHdo ZXJlIHRoZSBjYW5vbmljYWwgZm9ybSBjb3VsZCBjb21lIGludG8gcGxheS4KIAo+IAo+IEkgZG8g bm90IHRyeSB0byBpbnRyb2R1Y2UgYW55dGhpbmcgbmV3IGhlcmUsIGp1c3QgZG9jdW1lbnRpbmcg d2hhdAo+IFhQYXRoIGRvZXMuICBEaWQgSSBnZXQgaXQgd3Jvbmc/ICBYUGF0aCBoYXMgc3RyaW5n cywgbnVtYmVycyAoNjQgYml0Cj4gZmxvYXQpIGFuZCAgYm9vbGVhbi4KPiAKPiA+ID4gICAzLiAg U3VidHJlZSBmaWx0ZXJpbmcgY29udGVudCBtYXRjaCBjb21wYXJpc29ucy4gIFNhbWUgYXMgKDIp IGFib3ZlLAo+ID4gPiAgICAgICBleGNlcHQgdGhhdCBpdCBkZWZpbmVzIGl0cyBvd24gd2hpdGVz cGFjZSB0cmltbWluZyBydWxlcwo+ID4gPiAgICAgICAobGVhZGluZyBhbmQgdHJhaWxpbmcgd2hp dGVzcGFjZXMgYXJlIHJlbW92ZWQpLgo+ID4gCj4gPiBCdXQgd2hhdCBpZiB4cGF0aCBjYXBhYmls aXR5IGlzIHVzZWQ/IEl0IHdpbGwgYmUgdmVyeSBjb25mdXNpbmcgaWYgdGhlCj4gPiBjb21wYXJp c29uL21hdGNoaW5nIHNlbWFudGljcyBpcyBkaWZmZXJlbnQuCgo+IAo+IEFyZSB5b3UgKCEpIHN1 Z2dlc3RpbmcgdGhhdCB3ZSBjaGFuZ2Ugb3VyIHVzYWdlIG9mIFhQYXRoIHRvIGRvCj4gY29tcGFy aXNvbnMgYmFzZWQgb24gdGhlIHZhbHVlLXNwYWNlIHZhbHVlPwoKTm90IG1lICghKSwgaXQncyBJ TU8gdGhlIFhQYXRoIGl0c2VsZiB0aGF0IHN1Z2dlc3RzIHRoaXMgKHNlZSBhYm92ZSkuCgpMYWRh CgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5n IGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Dec 17 06:10:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A84428C0DE; Wed, 17 Dec 2008 06:10:04 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE5D3A67A1 for ; Wed, 17 Dec 2008 06:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6] 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 3JJDg2f0nK1V for ; Wed, 17 Dec 2008 06:09:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AB4A028C1E6 for ; Wed, 17 Dec 2008 06:09:55 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F77B76C521; Wed, 17 Dec 2008 15:09:47 +0100 (CET) Date: Wed, 17 Dec 2008 15:09:47 +0100 (CET) Message-Id: <20081217.150947.103583855.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1229522602.6175.45.camel@missotis> References: <1229518691.6175.24.camel@missotis> <20081217.140620.125651739.mbj@tail-f.com> <1229522602.6175.45.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxNDowNiArMDEwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gPiAgIDIuICBYUGF0aCAx LjAgY29tcGFyaXNvbiBpbiBmaWx0ZXJpbmcgYW5kIG11c3Qvd2hlbiBleHByZXNzaW9ucy4NCj4g PiA+ID4gICAgICAgVGhpcyBpcyBieSBkZWZpbml0aW9uIGRvbmUgb24gdGhlIHN0cmluZyByZXBy ZXNlbnRhdGlvbiBvZiB0aGUNCj4gPiA+ID4gICAgICAgdmFsdWUgKHBvc3NpYmx5IGludGVycHJl dGVkIGFzIGEgbnVtYmVyIGJ5IFhQYXRoKS4NCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgIEJ5IGFs d2F5cyB1c2luZyB0aGUgY2Fub25pY2FsIGxleGljYWwgZm9ybSwgd2UgZW5zdXJlIHRoYXQNCj4g PiA+ID4gICAgICAgY29tcGFyaXNvbnMgY2FuIGJlIGRvbmUgY29uc2lzdGVudGx5LiAoKikNCj4g PiA+IA0KPiA+ID4gVGhpcyBpcyBob3dldmVyIGFub3RoZXIgZGV2aWF0aW9uIGZyb20gWFBhdGgg c3BlYyBhbmQgcHJhY3RpY2UuIFhQYXRoDQo+ID4gPiBoYXMgbm9uLXN0cmluZyB0eXBlcywgc3Vw cG9ydHMgbnVtZXJpYyBvcGVyYXRpb25zIGV0Yy4NCj4gDQo+IFdpdGggZ2VudWluZSBYUGF0aCwg YW4gYXNzZXJ0IGxpa2UNCj4gDQo+IG11c3QgImZvbzpjb3VudCA9IDErMSI7DQo+IA0KPiB3b3Vs ZCBiZSBzYXRpc2ZpZWQgd2hldGhlciB0aGUgZm9vOmNvdW50IHZhbHVlIHdhcyBzZXQgaW4gZWRp dC1jb25maWcgYXMNCj4gMiBvciAyLjAuIEkgZG9uJ3Qgc2VlIHdoZXJlIHRoZSBjYW5vbmljYWwg Zm9ybSBjb3VsZCBjb21lIGludG8gcGxheS4NCg0KVGhpcyBqdXN0IHdvcmtzIGZvciB0aGUgWFBh dGggZGF0YXR5cGVzIChpLmUuIG51bWJlcnMpLiAgQnV0IGl0IHdvbid0DQp3b3JrIGZvciBlLmcu IGlwdjYgY29tcGFyaXNvbnMuICBUaGUgY2Fub25pY2FsIGxleGljYWwgZm9ybSBpcyBuZWVkZWQg Zm9yDQppcHY2IChhbmQgb3RoZXJzIG9mIGNvdXJzZSkuDQoNCg0KDQovbWFydGluDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Wed Dec 17 06:32:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462ED3A6801; Wed, 17 Dec 2008 06:32:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8781C3A6801 for ; Wed, 17 Dec 2008 06:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 JrUimDxkVUZx for ; Wed, 17 Dec 2008 06:32:37 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id ADE463A68EF for ; Wed, 17 Dec 2008 06:32:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSUkNe2Q38zGmVapOumqzciVxjbqDKI5u@postini.com; Wed, 17 Dec 2008 06:32:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 17 Dec 2008 06:28:16 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 06:28:16 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 06:28:15 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 06:28:15 -0800 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 mBHESEM51296; Wed, 17 Dec 2008 06:28:14 -0800 (PST) (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 mBHEMkvV068008; Wed, 17 Dec 2008 14:22:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812171422.mBHEMkvV068008@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081217.131609.55656045.mbj@tail-f.com> Date: Wed, 17 Dec 2008 09:22:46 -0500 From: Phil Shafer X-OriginalArrivalTime: 17 Dec 2008 14:28:15.0541 (UTC) FILETIME=[B2D1B650:01C96053] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: > 1. Comparing key values in edit-config. We want to use the > value-space value here, not any lexical representation. > This should not be a problem, but we don't use the term "value > space" currently. Maybe we should. Does this mean that an app that doesn't grok lexical space -> value space mapping for a (new) type can't do key matches? Will an app be aware that it can't (and shouldn't) attempt such matches? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 06:43:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7602D3A67A1; Wed, 17 Dec 2008 06:43:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F0C3A682E for ; Wed, 17 Dec 2008 06:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 L87CZgZ7JTDj for ; Wed, 17 Dec 2008 06:43:22 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3BB8B3A67E6 for ; Wed, 17 Dec 2008 06:43:22 -0800 (PST) Received: from [195.113.219.233] (eduroam-233.cesnet.cz [195.113.219.233]) by office2.cesnet.cz (Postfix) with ESMTP id B6CDFD800C0; Wed, 17 Dec 2008 15:43:14 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081217.150947.103583855.mbj@tail-f.com> References: <1229518691.6175.24.camel@missotis> <20081217.140620.125651739.mbj@tail-f.com> <1229522602.6175.45.camel@missotis> <20081217.150947.103583855.mbj@tail-f.com> Organization: CESNET Date: Wed, 17 Dec 2008 15:43:15 +0100 Message-Id: <1229524995.6175.59.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxNTowOSArMDEwMDoK PiBUaGlzIGp1c3Qgd29ya3MgZm9yIHRoZSBYUGF0aCBkYXRhdHlwZXMgKGkuZS4gbnVtYmVycyku ICBCdXQgaXQgd29uJ3QKPiB3b3JrIGZvciBlLmcuIGlwdjYgY29tcGFyaXNvbnMuICBUaGUgY2Fu b25pY2FsIGxleGljYWwgZm9ybSBpcyBuZWVkZWQgZm9yCj4gaXB2NiAoYW5kIG90aGVycyBvZiBj b3Vyc2UpLgoKWWVzLCB0aGF0J3MgdHJ1ZS4gQnV0IHRoZSBvZnQtY2l0ZWQgZXhhbXBsZSBvZiAi MyIgdmVyc3VzICIrMyIgaXMgbm90IGFuCmlzc3VlLCByaWdodD8gSSBoYWQgdGhlIGltcHJlc3Np b24gdGhhdCB0aGVzZSB0d28gd29uJ3QgbWF0Y2guCgpMYWRhCgo+IAo+IAo+IAo+IC9tYXJ0aW4K LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Wed Dec 17 06:53:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7043A6452; Wed, 17 Dec 2008 06:53:32 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78603A67A5 for ; Wed, 17 Dec 2008 06:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 GBTic87V0hii for ; Wed, 17 Dec 2008 06:53:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0BD783A6452 for ; Wed, 17 Dec 2008 06:53:30 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C2A776C521; Wed, 17 Dec 2008 15:53:23 +0100 (CET) Date: Wed, 17 Dec 2008 15:53:19 +0100 (CET) Message-Id: <20081217.155319.81608391.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200812171422.mBHEMkvV068008@idle.juniper.net> References: <20081217.131609.55656045.mbj@tail-f.com> <200812171422.mBHEMkvV068008@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > > 1. Comparing key values in edit-config. We want to use the > > value-space value here, not any lexical representation. > > This should not be a problem, but we don't use the term "value > > space" currently. Maybe we should. > > Does this mean that an app that doesn't grok lexical space -> value > space mapping for a (new) type can't do key matches? Yes. For example, assume we add a new type 'qname'. An app that doesn't understand this type will not know that these two are equivalent: a:bar and b:bar > Will an app > be aware that it can't (and shouldn't) attempt such matches? If we have a special clause in the typedef, then the app can check if this new clause is present. If it is not present, the app can do the matching, provided it understand the base type. If the clause is present, it knows that it cannot do the match. But the name 'canonical' is not good... is there a term that covers both "canonical" and "value-space"? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 07:01:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1438F3A67F2; Wed, 17 Dec 2008 07:01:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17E83A6452 for ; Wed, 17 Dec 2008 07:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 bO9IsgouwQzu for ; Wed, 17 Dec 2008 07:01:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0599D3A6809 for ; Wed, 17 Dec 2008 07:01:43 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7002176C521; Wed, 17 Dec 2008 16:01:36 +0100 (CET) Date: Wed, 17 Dec 2008 16:01:34 +0100 (CET) Message-Id: <20081217.160134.29422868.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1229524995.6175.59.camel@missotis> References: <1229522602.6175.45.camel@missotis> <20081217.150947.103583855.mbj@tail-f.com> <1229524995.6175.59.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxNTowOSArMDEwMDoNCj4gPiBUaGlzIGp1 c3Qgd29ya3MgZm9yIHRoZSBYUGF0aCBkYXRhdHlwZXMgKGkuZS4gbnVtYmVycykuICBCdXQgaXQg d29uJ3QNCj4gPiB3b3JrIGZvciBlLmcuIGlwdjYgY29tcGFyaXNvbnMuICBUaGUgY2Fub25pY2Fs IGxleGljYWwgZm9ybSBpcyBuZWVkZWQgZm9yDQo+ID4gaXB2NiAoYW5kIG90aGVycyBvZiBjb3Vy c2UpLg0KPiANCj4gWWVzLCB0aGF0J3MgdHJ1ZS4gQnV0IHRoZSBvZnQtY2l0ZWQgZXhhbXBsZSBv ZiAiMyIgdmVyc3VzICIrMyIgaXMgbm90IGFuDQo+IGlzc3VlLCByaWdodD8gSSBoYWQgdGhlIGlt cHJlc3Npb24gdGhhdCB0aGVzZSB0d28gd29uJ3QgbWF0Y2guDQoNCkFjdHVhbGx5LCBpdCBzZWVt cyAiKzMiIGlzIG5vdCBhIE51bWJlciBhY2NvcmRpbmcgdG8gWFBhdGguICBJZiB0aGlzDQpyZWFs bHkgaXMgdHJ1ZSwgYW5kIHdlIGRpZCBub3QgaGF2ZSB0aGUgcnVsZSBhYm91dCBjYW5vbmljYWwg Zm9ybSwgYW4NCmFwcGxpY2F0aW9uIG1pZ2h0IHN0b3JlICIrMyIgaW4gdGhlIGRiLCBhbmQgYW4g eHBhdGggY29tcGFyaXNvbiB3aXRoDQoiMyIgd291bGQgdGhlbiBmYWlsLg0KDQoNCi9tYXJ0aW4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBt YWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Dec 17 07:23:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A76E3A6825; Wed, 17 Dec 2008 07:23:57 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348F23A6954 for ; Wed, 17 Dec 2008 07:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 zCApo44vpuC9 for ; Wed, 17 Dec 2008 07:23:56 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6DEDF3A6825 for ; Wed, 17 Dec 2008 07:23:56 -0800 (PST) Received: from [195.113.219.233] (eduroam-233.cesnet.cz [195.113.219.233]) by office2.cesnet.cz (Postfix) with ESMTP id C03E1D800EF; Wed, 17 Dec 2008 16:23:48 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081217.160134.29422868.mbj@tail-f.com> References: <1229522602.6175.45.camel@missotis> <20081217.150947.103583855.mbj@tail-f.com> <1229524995.6175.59.camel@missotis> <20081217.160134.29422868.mbj@tail-f.com> Organization: CESNET Date: Wed, 17 Dec 2008 16:23:49 +0100 Message-Id: <1229527429.6175.63.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxNjowMSArMDEwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gTWFydGluIEJq b3JrbHVuZCBww63FoWUgdiBTdCAxNy4gMTIuIDIwMDggdiAxNTowOSArMDEwMDoKPiA+ID4gVGhp cyBqdXN0IHdvcmtzIGZvciB0aGUgWFBhdGggZGF0YXR5cGVzIChpLmUuIG51bWJlcnMpLiAgQnV0 IGl0IHdvbid0Cj4gPiA+IHdvcmsgZm9yIGUuZy4gaXB2NiBjb21wYXJpc29ucy4gIFRoZSBjYW5v bmljYWwgbGV4aWNhbCBmb3JtIGlzIG5lZWRlZCBmb3IKPiA+ID4gaXB2NiAoYW5kIG90aGVycyBv ZiBjb3Vyc2UpLgo+ID4gCj4gPiBZZXMsIHRoYXQncyB0cnVlLiBCdXQgdGhlIG9mdC1jaXRlZCBl eGFtcGxlIG9mICIzIiB2ZXJzdXMgIiszIiBpcyBub3QgYW4KPiA+IGlzc3VlLCByaWdodD8gSSBo YWQgdGhlIGltcHJlc3Npb24gdGhhdCB0aGVzZSB0d28gd29uJ3QgbWF0Y2guCj4gCj4gQWN0dWFs bHksIGl0IHNlZW1zICIrMyIgaXMgbm90IGEgTnVtYmVyIGFjY29yZGluZyB0byBYUGF0aC4gIElm IHRoaXMKPiByZWFsbHkgaXMgdHJ1ZSwgYW5kIHdlIGRpZCBub3QgaGF2ZSB0aGUgcnVsZSBhYm91 dCBjYW5vbmljYWwgZm9ybSwgYW4KPiBhcHBsaWNhdGlvbiBtaWdodCBzdG9yZSAiKzMiIGluIHRo ZSBkYiwgYW5kIGFuIHhwYXRoIGNvbXBhcmlzb24gd2l0aAo+ICIzIiB3b3VsZCB0aGVuIGZhaWwu CgpJbmRlZWQsIEkganVzdCBjaGVja2VkIGl0LCAiKzMiIGlzIG5vdCBhIHZhbGlkIG51bWJlciBp biBYUGF0aC4KCkxhZGEKCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNO RVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Dec 17 07:26:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6672E3A689E; Wed, 17 Dec 2008 07:26:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FD428C0F5 for ; Wed, 17 Dec 2008 07:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.040, 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 2ZRRrzOFeAfE for ; Wed, 17 Dec 2008 07:26:54 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 0476A3A695E for ; Wed, 17 Dec 2008 07:26:54 -0800 (PST) Received: (qmail 43947 invoked from network); 17 Dec 2008 15:26:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 15:26:45 -0000 X-YMail-OSG: ZvNNFyQVM1mOjQplq2WFfY7e5b75OFWlh0aiviJ2JnjkPDS44DGfn596Z8Uvhg346jpyfw9ubSq6LS17t0hgN6fG8cqYflR8AfPG7g.B6UqORrNhKRP2N_J619OPluLhg78qehHrkgmtEj4IN9zH6v40FNAJUiZzgYu0RBpvYnsTUSaQxwS8IG9tdfiSw1g7f6BUSVN.niBvedHb X-Yahoo-Newman-Property: ymail-3 Message-ID: <49491A34.5010001@netconfcentral.com> Date: Wed, 17 Dec 2008 07:26:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49483DF0.6090100@netconfcentral.com> <20081217.100136.179413214.mbj@tail-f.com> <4948E228.40604@netconfcentral.com> <20081217.132647.193292739.mbj@tail-f.com> In-Reply-To: <20081217.132647.193292739.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> It is not clear if these modules should be >>>> included in the PDU. The namespace-stmt has no >>>> other purpose in this kind of module. >>> That is the idea. The text is reworked to make this more clear in the >>> upcoming -03 draft. >>> >>>> It is not clear at all why the NETMOD WG has decided >>>> (within the syntax on the capability-URI) that all >>>> deviations are grouped by module in a tight 1:1 mapping. >>>> >>>> It might make better sense for some vendors to maintain >>>> one deviations file per platform. >>> This is supported already, see below. The mapping between modules and >>> deviations is actually N:M. >>> >>>> The deviation target >>>> implicitly specifies the module, so there is no need >>>> for a CLR to prevent this: >>>> >>>> module dev-platform-A { >>>> >>>> namespace "does-not-matter"; >>>> prefix "not-used"; >>>> >>>> revision 2008-12-16; >>>> >>>> import foo { >>>> prefix foo; >>>> revision 2008-12-01; >>>> } >>>> >>>> import bar { >>>> prefix bar; >>>> revision 2008-11-14; >>>> } >>>> >>>> deviation /foo:some-leaf { ... } >>>> >>>> deviation /bar:some-container { ... } >>>> >>>> } >>> So in this case, the would include: >>> http://example.com/foo?deviations=dev-platform-A >>> http://example.com/bar?deviations=dev-platform-A >>> does-not-matter?module=dev-platform-A >>> Also note that a module can have multiple deviations: >>> >>> http://example.com/foo?deviations=dev-platform-A,dev-common >>> >>> >> >> Also note that the ?deviatations=a,b,c encoding is >> completely redundant and pointless. >> >> The namespace URI of the deviations module does matter. >> It is just one more capability getting advertised: >> >> http://example.com/foo >> http://example.com/bar >> does-not-matter >> >> Simply advertising the deviations module is enough. > > So when I am a client, I read this advertisement, and I know that > understad http://example.com/bar. I even have this standard data > model locally. But I don't understand the data model > http://example.com/foo, so I skip it. I also don't understand > does-not-matter, so I skip it as well. Now I just missed the device's > deviations. > http://example.com/foo?module=foo&revision=2008-12-01 http://example.com/bar?module=bar&revision=2008-01-04 does-not-matter Huh? How does "deviations=blah" get understood but the base URI "blah-namespace" does not? Why can't the implementation search around using the base URI instead of just a parameter attached to the base URI? That's what they did before YANG invented this new cruft. > If we don't encode the deviations a client will have to check all > modules in the schema discovery list, download them all, and search > for deviations. In most cases it won't even find any. With the > explicit encoding, a client can immediately tell when the device does > not have any deviations, and easily find them when it does. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 07:44:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1373C3A6999; Wed, 17 Dec 2008 07:44:09 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C1B3A6999 for ; Wed, 17 Dec 2008 07:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 0UhrYGAFP63i for ; Wed, 17 Dec 2008 07:44:06 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 1F8293A6AB3 for ; Wed, 17 Dec 2008 07:44:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSUkeOy+Z8ycg/34cR+7NYpIr2O+h4ewK@postini.com; Wed, 17 Dec 2008 07:43:59 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 17 Dec 2008 07:39:42 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 07:39:42 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 07:39:41 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 07:39:41 -0800 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 mBHFdeM80951; Wed, 17 Dec 2008 07:39:40 -0800 (PST) (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 mBHFYC1h068700; Wed, 17 Dec 2008 15:34:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812171534.mBHFYC1h068700@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1229527429.6175.63.camel@missotis> Date: Wed, 17 Dec 2008 10:34:12 -0500 From: Phil Shafer X-OriginalArrivalTime: 17 Dec 2008 15:39:41.0297 (UTC) FILETIME=[AD542E10:01C9605D] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >Indeed, I just checked it, "+3" is not a valid number in XPath. FWIW: If I read their grammar correctly, the unary "-" can be repeated, making "--3" a valid number. http://www.w3.org/TR/xpath#NT-UnaryExpr [27] UnaryExpr ::= UnionExpr | '-' UnaryExpr So is "--3" <=> "-3"? In any case the lex->value issue remains. I would like to hope that we can at least clue in apps that lack the specifics for new types to force them into some sort of not-so-liberal parsing of user input. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 07:54:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124E53A6825; Wed, 17 Dec 2008 07:54:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA9528C0DC for ; Wed, 17 Dec 2008 07:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 QL1gsqkedbVp for ; Wed, 17 Dec 2008 07:54:48 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C230A3A6825 for ; Wed, 17 Dec 2008 07:54:48 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DCAE376C521; Wed, 17 Dec 2008 16:54:39 +0100 (CET) Date: Wed, 17 Dec 2008 16:54:37 +0100 (CET) Message-Id: <20081217.165437.43995503.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200812171534.mBHFYC1h068700@idle.juniper.net> References: <1229527429.6175.63.camel@missotis> <200812171534.mBHFYC1h068700@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > In any case the lex->value issue remains. I would like to hope > that we can at least clue in apps that lack the specifics for new > types to force them into some sort of not-so-liberal parsing of > user input. Do you have something in mind? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 08:02:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAF93A68D3; Wed, 17 Dec 2008 08:02:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5267E3A6AFB for ; Wed, 17 Dec 2008 08:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.039, 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 O9mli30wwi9R for ; Wed, 17 Dec 2008 08:02:38 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 5189D3A68D3 for ; Wed, 17 Dec 2008 08:02:38 -0800 (PST) Received: (qmail 40824 invoked from network); 17 Dec 2008 16:02:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 16:02:29 -0000 X-YMail-OSG: zOWbE8IVM1njcyt0PeYor5EUecA2PYNTKagPBNbE.ABHr.NhI2k3EfPXFtsS_IIrUJ4lx4KvB3XtzFR2SNpPLfA.ErHGGYqm4HtPkYrSs0qqkpEk_CggBehkU48DEBzQAlZMaRsln4m4joiDjX6idqwOQ5ViPlb2oMh.9AI9_yszJjdIejMrhNMTYamP X-Yahoo-Newman-Property: ymail-3 Message-ID: <49492295.2000102@netconfcentral.com> Date: Wed, 17 Dec 2008 08:02:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49483DF0.6090100@netconfcentral.com> <20081217.100136.179413214.mbj@tail-f.com> <4948E228.40604@netconfcentral.com> <20081217.132647.193292739.mbj@tail-f.com> In-Reply-To: <20081217.132647.193292739.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Here is the revised capability encoding. All YANG modules are the same. They all begin with the keyword 'module'. They can can contain an arbitrary mix of any YANG body-stmts. A deviations-only module is just a corner-case. Why doesn't the agent advertise every module that has a deviation-stmt in it as a deviation? Because it is not needed. Neither is deviations=blah Why not just advertise the deviations module just like any other module? http://example.com/foo?module=foo&revision=2008-12-01 http://example.com/bar?module=bar&revision=2008-01-04 http://example.com/dev-pA?module=dev-platform-A&revision=2008-12-16 What happens if the vendor adds a leaf to module dev-platform-A? Does the 'deviations=dev-module-A' get dropped from all the other capability URIs at that point, and the module get advertised instead? This seems unstable to me. Advertising the module capability would be stable and consistent, instead of creating special capability URI parameters, based on the current contents of the module. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 08:09:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806E23A68D3; Wed, 17 Dec 2008 08:09:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0223A6B09 for ; Wed, 17 Dec 2008 08:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 eIlCOddzYdd8 for ; Wed, 17 Dec 2008 08:09:37 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 21CB93A6B03 for ; Wed, 17 Dec 2008 08:09:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSUkkNgEJorg7vYChpcHjc+4XbxKlaDOx@postini.com; Wed, 17 Dec 2008 08:09:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 17 Dec 2008 08:06:40 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 08:06:39 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 08:06:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 08:06:38 -0800 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 mBHG6bM92802; Wed, 17 Dec 2008 08:06:38 -0800 (PST) (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 mBHG197e068957; Wed, 17 Dec 2008 16:01:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812171601.mBHG197e068957@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081217.165437.43995503.mbj@tail-f.com> Date: Wed, 17 Dec 2008 11:01:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 17 Dec 2008 16:06:38.0678 (UTC) FILETIME=[715CEF60:01C96061] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Do you have something in mind? I think the canonical statement does the job for the 80% case. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 08:32:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4063A683D; Wed, 17 Dec 2008 08:32:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C5B3A68D3 for ; Wed, 17 Dec 2008 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.038, 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 TrcjStb1WUks for ; Wed, 17 Dec 2008 08:32:19 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 383A23A683D for ; Wed, 17 Dec 2008 08:32:19 -0800 (PST) Received: (qmail 24676 invoked from network); 17 Dec 2008 16:32:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 16:32:10 -0000 X-YMail-OSG: RrJkHM4VM1mSaXZPgHwgEGiuPv27AAJQVjkWrscfzIld.pZKUC_NaXxfWA4t77S.0QPZt93auvAj91e4UalxrJOtO06yWKTweLJoVs8qXnZUCbu6rPqMpfj5A.DLlNOGDaofpVWWe1htZKvri75Xz3IsnPuq7xN3CTnr3nkkmoLGUfnG.pMZs4rkZ9qfwMBTYmOD9MIg9F6FHDApDDVzPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49492989.3060002@netconfcentral.com> Date: Wed, 17 Dec 2008 08:32:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4947DE47.8010003@netconfcentral.com> <20081216.233117.148311949.mbj@tail-f.com> <4948432A.6020401@netconfcentral.com> <20081217.101749.22020128.mbj@tail-f.com> In-Reply-To: <20081217.101749.22020128.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>> deviate-delete-stmt = deviate-keyword sep delete-keyword optsep >>> "{" stmtsep >>> *(must-stmt stmtsep) >>> *(unique-stmt stmtsep) >>> "}" >>> >> This one is tricky. >> How are the comparisons of two must-stmts or two unique-stmts done? >> Is whitespace normalized somehow? Are prefix differences ignored? >> Are different representations of the same object ignored? >> (e.g., ../foo vs. /top/foo). > > The spec says: > > the argument's string MUST be equal to the corresponding keyword's > argument string in the target node. > > I.e. the string values (after normal YANG string interpretation rules, > concatenation etc) must match exactly, including prefixes etc. > > This is IMO the only workable solution - yes it might be cumbersome > for the writer of the 'deviate' statement, but this is a corner case > that is not recommended anyway, so I don't think we need to optimize > for this case. > >>> deviate-replace-stmt = deviate-keyword sep replace-keyword optsep >>> "{" stmtsep >>> [type-stmt stmtsep] >>> [default-stmt stmtsep] >>> [config-stmt stmtsep] >>> [mandatory-stmt stmtsep] >>> [min-elements-stmt stmtsep] >>> [max-elements-stmt stmtsep] >>> "}" >>> >> Are there going to be any rules or guidelines on type-stmt? >> This one looks real easy in the 1 line ABNF, >> but the type-stmt is massive. >> >> In the worst use-case, a vendor could claim partial conformance >> to a standard data model by implementing the shells of the >> data nodes, and then using deviations to replace all the guts >> of all the objects with their proprietary versions. > > But a vendor can claim anything, regardless of the deviation > statement. Just b/c they specify how broken they are does not make > them more compliant. > This is the first time an IETF standard would be helping the vendor 'claim anything'. Vendors are always looking to lower costs. If I'm implementing some YANG CM module, and I tell my boss "it will take 15 weeks until code-complete, because it took 12 weeks to add our proprietary version, and I have to come up with some way that they can work together now, because we can't remove our module." When my boss asks me if there's anything we can do to bring in the schedule (never heard that one before! ;-) I have to mention the deviation-stmt. "It will take me 2 weeks to 'plug in' our DM into the standard one, but most of the standard knobs won't really do what they are supposed to do". We all know that the vendor is going to take the easy path. This issue is especially important for configuration because multiple write objects for the same thing requires coordination. The standard model always lags the proprietary model. The temptation to just plug in part or all of the proprietary model will always be compelling to the vendor, and of no value whatsoever to the customer of IETF standards. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 11:43:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AFD28C1E4; Wed, 17 Dec 2008 11:43:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FAE28C1E6 for ; Wed, 17 Dec 2008 11:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 a4EXRhtqEUN6 for ; Wed, 17 Dec 2008 11:43:30 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 667C628C1E4 for ; Wed, 17 Dec 2008 11:43:30 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA04621; Wed, 17 Dec 2008 14:43:17 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA11158; Wed, 17 Dec 2008 14:43:16 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 17 Dec 2008 14:43:16 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org Message-ID: MIME-Version: 1.0 Subject: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I would like to suggest a change to the text in Section 8, paragraph 2 for draft-ietf-netmod-yang-03.txt. ------------ BEFORE ------------ 8. Constraints Several YANG statements define constraints on valid data. These constraints are enforced at different times, depending on what type of data the statement defines. If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. If the constraint is defined on state data, it MUST be true in a reply to the command. ------------ AFTER ------------ 8. Constraints Several YANG statements define constraints on valid data. These constraints are enforced at different times, depending on what type of data the statement defines. If the constraint is defined on configuration data, it MUST be true in an command in order for the command to succeed. If the constraint is defined on state data, it MUST be true in a reply to the command. ------------ Rationale ------------ The change affects the application of a "must" statement on a deviate where the underlying system might return some data as valid configuration for but where an operation would not succeed. Below is an example. I have been looking recently at how an SMIv2 AGENT-CAPABILITIES document might map onto a Yang module containing deviation statements. For test cases, I have been using existing AGENT-CAPABILITIES documents describing MIB-II variations in SNMP Research agents. On the AIX platform, the SNMP agent is currently able to fetch information from the kernel for both IPv4 and IPv6 routes, and it can add/delete/modify an IPv4 route, but it is currently unable to add/delete/modify an IPv6 route. Here is a relavant portion of the AGENT-CAPABILITIES document: SUPPORTS IP-FORWARD-MIB -- RFC 4292 INCLUDES { inetForwardCidrRouteGroup } VARIATION inetCidrRouteTable DESCRIPTION "This table supports read, write, and row creation, but currently, SNMP sets have no effect on the underlying IP stack(s) on the system if the inetCidrRouteDestType or inetCidrRouteNextHopType is ipv6(2) or ipv6z(4)." VARIATION inetCidrRouteDestType SYNTAX INTEGER { ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } WRITE-SYNTAX INTEGER { ipv4(1), ipv4z(3) } DESCRIPTION "The implementation does not support unknown(0) or dns(16)." In a Yang document intended to be equivalent to the definitions in RFC 4292 combined with the above AGENT-CAPABILITIES text, I have produced Yang statements as follows: /**************************** * Text describing /ipForward/inetCidrRouteTable deviation: * "This table supports read, write, and row creation, but currently, SNMP sets have no effect on the underlying IP stack(s) on the system if the inetCidrRouteDestType or inetCidrRouteNextHopType is ipv6(2) or ipv6z(4)." * ****************************/ deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { deviate replace { type enumeration { enum ipv4 { value 1; } enum ipv6 { value 2; } enum ipv4z { value 3; } enum ipv6z { value 4; } } } deviate add { must "ipv4 or ipv4z" { error-message "The implementation does not support unknown(0) or dns(16)." } } } The scope of the constraint applied by the "must" should be limited only to the . A command sent to this agent might return data describing IPv6 configuration data, but an command containing IPv6 configuration data would fail. Regards, David ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 12:02:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6464728C209; Wed, 17 Dec 2008 12:02:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC45328C209 for ; Wed, 17 Dec 2008 12:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] 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 z8PBmaJNJR98 for ; Wed, 17 Dec 2008 12:02:21 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id CB89B28C1F8 for ; Wed, 17 Dec 2008 12:02:03 -0800 (PST) Received: (qmail 85148 invoked from network); 17 Dec 2008 20:01:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 20:01:54 -0000 X-YMail-OSG: Ig8geNkVM1ntLgU3dEGKJrcNQx1qdDyS7k9AqgLJS5xAF2.iSc03tvbHay9vekTpb7LQ.gXLl5HJntOQ.TUfNmc7imevtZuoIF_z5tp1uKcMa1MkEikgRTCIQjy6.8LE8huCUVwDAr0JnxBJYwL1UtcBbTaxGhsj4qLdP8KuoPQUzwaYcprVX5yM X-Yahoo-Newman-Property: ymail-3 Message-ID: <49495AB0.4010102@netconfcentral.com> Date: Wed, 17 Dec 2008 12:01:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: David Spakes References: In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Spakes wrote: > I would like to suggest a change to the text in Section 8, paragraph 2 > for draft-ietf-netmod-yang-03.txt. > This will not for work . The manager is allowed to make incremental changes that do not meet the constraints. The constraints do not always apply to a delete operation, since the content may be absent in the PDU. It is not the contents of the request that matters. It is the resulting database that would occur after the edit is applied that matters. When the operation is applied to the , it is the resulting config that matters. Only the config is ever in use by the agent, so it is the only one required to be valid and present. BTW, I think you want this XPath in your must-stmt example: must ". = 'ipv4' or . = 'ipv4z'"; Andy > > ------------ > BEFORE > ------------ > 8. Constraints > > Several YANG statements define constraints on valid data. These > constraints are enforced at different times, depending on what type > of data the statement defines. > > If the constraint is defined on configuration data, it MUST be true > in a valid configuration data tree. > > If the constraint is defined on state data, it MUST be true in a > reply to the command. > > ------------ > AFTER > ------------ > 8. Constraints > > Several YANG statements define constraints on valid data. These > constraints are enforced at different times, depending on what type > of data the statement defines. > > If the constraint is defined on configuration data, it MUST be true > in an command in order for the command to succeed. > > If the constraint is defined on state data, it MUST be true in a > reply to the command. > > ------------ > Rationale > ------------ > The change affects the application of a "must" statement on a deviate > where the underlying system might return some data as valid configuration > for but where an operation would not succeed. > Below is an example. > > > > I have been looking recently at how an SMIv2 AGENT-CAPABILITIES > document might map onto a Yang module containing deviation statements. > For test cases, I have been using existing AGENT-CAPABILITIES documents > describing MIB-II variations in SNMP Research agents. > > On the AIX platform, the SNMP agent is currently able to fetch > information from the kernel for both IPv4 and IPv6 routes, and it can > add/delete/modify an IPv4 route, but it is currently unable to > add/delete/modify an IPv6 route. Here is a relavant portion of > the AGENT-CAPABILITIES document: > > > SUPPORTS IP-FORWARD-MIB -- RFC 4292 > INCLUDES { inetForwardCidrRouteGroup } > > VARIATION inetCidrRouteTable > DESCRIPTION > "This table supports read, write, and row creation, but > currently, SNMP sets have no effect on the underlying > IP stack(s) on the system if the inetCidrRouteDestType or > inetCidrRouteNextHopType is ipv6(2) or ipv6z(4)." > > VARIATION inetCidrRouteDestType > SYNTAX INTEGER { > ipv4(1), > ipv6(2), > ipv4z(3), > ipv6z(4) > } > WRITE-SYNTAX INTEGER { > ipv4(1), > ipv4z(3) > } > DESCRIPTION > "The implementation does not support unknown(0) or dns(16)." > > > > In a Yang document intended to be equivalent to the definitions in > RFC 4292 combined with the above AGENT-CAPABILITIES text, I have > produced Yang statements as follows: > > > > /**************************** > * Text describing /ipForward/inetCidrRouteTable deviation: > * > "This table supports read, write, and row creation, but > currently, SNMP sets have no effect on the underlying > IP stack(s) on the system if the inetCidrRouteDestType or > inetCidrRouteNextHopType is ipv6(2) or ipv6z(4)." > * > ****************************/ > > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv6 { value 2; } > enum ipv4z { value 3; } > enum ipv6z { value 4; } > } > } > deviate add { > must "ipv4 or ipv4z" { > error-message > "The implementation does not support unknown(0) or dns(16)." > } > } > } > > > The scope of the constraint applied by the "must" should be limited only > to the . A command sent to this agent might > return data describing IPv6 configuration data, but an > command containing IPv6 configuration data would fail. > > > Regards, > David > > > > ------------------------------------------------------------- > David Spakes email: spakes@snmp.com > SNMP Research voice: +1 865 573 1434 > 3001 Kimberlin Heights Road fax: +1 865 573 9197 > Knoxville, TN 37920-9716 USA http://www.snmp.com > ------------------------------------------------------------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 12:50:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04C553A68B0; Wed, 17 Dec 2008 12:50:22 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E403A68F7 for ; Wed, 17 Dec 2008 12:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] 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 IIin-vQPpdea for ; Wed, 17 Dec 2008 12:50:20 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B7D523A68B0 for ; Wed, 17 Dec 2008 12:50:18 -0800 (PST) Received: (qmail 12550 invoked from network); 17 Dec 2008 20:50:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 20:50:09 -0000 X-YMail-OSG: 6E.EfDAVM1kQTyeW0m0PNIR90bEKfeWqIXTKjVFF_yOy_12aEpEYop_NxkpEd7P3eIWsXxeEibmFIbN1WEA2j44hsIfy7hFGS_tx07MvckmcogRCErQGaFcjdzFKeuAHAcXtxbxllrD.hc5ji3sLnSz_z.HnQjPXpY4pSyzz2AyF X-Yahoo-Newman-Property: ymail-3 Message-ID: <49496600.2040902@netconfcentral.com> Date: Wed, 17 Dec 2008 12:50:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: David Spakes References: In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Spakes wrote: > I would like to suggest a change to the text in Section 8, paragraph 2 > for draft-ietf-netmod-yang-03.txt. > .... > > SUPPORTS IP-FORWARD-MIB -- RFC 4292 > INCLUDES { inetForwardCidrRouteGroup } > > VARIATION inetCidrRouteTable > DESCRIPTION > "This table supports read, write, and row creation, but > currently, SNMP sets have no effect on the underlying > IP stack(s) on the system if the inetCidrRouteDestType or > inetCidrRouteNextHopType is ipv6(2) or ipv6z(4)." > > VARIATION inetCidrRouteDestType > SYNTAX INTEGER { > ipv4(1), > ipv6(2), > ipv4z(3), > ipv6z(4) > } > WRITE-SYNTAX INTEGER { > ipv4(1), > ipv4z(3) > } > DESCRIPTION > "The implementation does not support unknown(0) or dns(16)." > ..... > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv6 { value 2; } > enum ipv4z { value 3; } > enum ipv6z { value 4; } > } > } > deviate add { > must "ipv4 or ipv4z" { > error-message > "The implementation does not support unknown(0) or dns(16)." > } > } > } > > Actually, in your example, all that is needed is: deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { deviate replace { type enumeration { enum ipv4 { value 1; } enum ipv4z { value 3; } } } } You do not want a must-stmt there. That (. = 'ipv4') makes the node mandatory, since '.' must exist for the expression to be true. > The scope of the constraint applied by the "must" should be limited only > to the . A command sent to this agent might > return data describing IPv6 configuration data, but an > command containing IPv6 configuration data would fail. > > > Regards, > David > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 13:45:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B994E3A67D2; Wed, 17 Dec 2008 13:45:01 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514303A68D3 for ; Wed, 17 Dec 2008 13:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 CWMjtLrm797g for ; Wed, 17 Dec 2008 13:45:00 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7E6E83A67D2 for ; Wed, 17 Dec 2008 13:44:59 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA12911; Wed, 17 Dec 2008 16:44:46 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA13308; Wed, 17 Dec 2008 16:44:45 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 17 Dec 2008 16:44:45 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <49496600.2040902@netconfcentral.com> Message-ID: References: <49496600.2040902@netconfcentral.com> MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, 17 Dec 2008, Andy Bierman wrote: > David Spakes wrote: > .... > > VARIATION inetCidrRouteTable > > DESCRIPTION > > "This table supports read, write, and row creation, but > > currently, SNMP sets have no effect on the underlying > > IP stack(s) on the system if the inetCidrRouteDestType or > > inetCidrRouteNextHopType is ipv6(2) or ipv6z(4)." > > > > VARIATION inetCidrRouteDestType > > SYNTAX INTEGER { > > ipv4(1), > > ipv6(2), > > ipv4z(3), > > ipv6z(4) > > } > > WRITE-SYNTAX INTEGER { > > ipv4(1), > > ipv4z(3) > > } At my current level of understanding of Yang, "deviation replace" is eqivalent to SMIv2's "VARIATION...SYNTAX". What I am trying to figure out is how one expresses SMIv2's "VARIATION...WRITE-SYNTAX" in Yang. > Actually, in your example, all that is needed is: > > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv4z { value 3; } > } > } > } I considered this possibility, but it does not seem to fully express the AIX agent implementation. The above "deviation replace" reduces the list of enumerations supported by the device to just ipv4 and ipv4z. However, the configuration data in the AIX agent implementation also includes ipv6 and ipv6z data. The ipv6/ipv6z configuration data in the implementation is effectively read-only. Conceptually, what I'm looking for is something like this (I know this isn't legal Yang syntax)... deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { deviate replace { type enumeration { enum ipv4 { value 1; } enum ipv6 { value 2; } enum ipv4z { value 3; } enum ipv6z { value 4; } } when ". = 'ipv6' or . = 'ipv6z'" { config false; } } } Regards, David ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 13:47:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192093A698A; Wed, 17 Dec 2008 13:47:53 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7920A3A6B03 for ; Wed, 17 Dec 2008 13:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6] 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 zxSq2fyLzoa7 for ; Wed, 17 Dec 2008 13:47:51 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AA03D3A698A for ; Wed, 17 Dec 2008 13:47:51 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EABDA76C521; Wed, 17 Dec 2008 22:47:42 +0100 (CET) Date: Wed, 17 Dec 2008 22:47:42 +0100 (CET) Message-Id: <20081217.224742.121207995.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49496600.2040902@netconfcentral.com> References: <49496600.2040902@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Actually, in your example, all that is needed is: > > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv4z { value 3; } > } > } > } > > You do not want a must-stmt there. > That (. = 'ipv4') makes the node mandatory, > since '.' must exist for the expression to be true. No, the must expression does not make the node mandatory. The must expression is evaluated only if the node exists. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 13:54:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F37D3A67BD; Wed, 17 Dec 2008 13:54:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9909F3A68B0 for ; Wed, 17 Dec 2008 13:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 faE7Ig0qoE6T for ; Wed, 17 Dec 2008 13:54:22 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D462D3A67BD for ; Wed, 17 Dec 2008 13:54:21 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 36D1B76C521; Wed, 17 Dec 2008 22:54:14 +0100 (CET) Date: Wed, 17 Dec 2008 22:54:11 +0100 (CET) Message-Id: <20081217.225411.59447952.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49492989.3060002@netconfcentral.com> References: <4948432A.6020401@netconfcentral.com> <20081217.101749.22020128.mbj@tail-f.com> <49492989.3060002@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > > But a vendor can claim anything, regardless of the deviation > > statement. Just b/c they specify how broken they are does not make > > them more compliant. > > > > This is the first time an IETF standard would be helping > the vendor 'claim anything'. As David S. pointed out in another thread, this concept is supported today in SMIv2 with AGENT-CAPABILITIES. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 14:03:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18063A67D2; Wed, 17 Dec 2008 14:03:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2153A6B47 for ; Wed, 17 Dec 2008 14:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.047, 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 jucmTX8j2lV0 for ; Wed, 17 Dec 2008 14:03:57 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id A3AA43A67D2 for ; Wed, 17 Dec 2008 14:03:57 -0800 (PST) Received: (qmail 69710 invoked from network); 17 Dec 2008 22:03:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 22:03:48 -0000 X-YMail-OSG: nUkr9bAVM1mrQ8m1tZE1_Q5mL6j6BOG7SX5gcQL6hs3uHwnO9UtdDiJBT6jB2EGOhrHU.iITVWdsMoZ1S8O7fwS8fblIjpUIIz0mnNkt0VAQWg4J09jnwdmNMfxOUa9z47wVx.mY9h.4L92k7RMtbyG5VmlqlfZpbwsNZRIGcTtOowgDsiYbbrBA9j9N34zbg10_ZL2vevM_6GTrCv2V_g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49497742.3040205@netconfcentral.com> Date: Wed, 17 Dec 2008 14:03:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4948432A.6020401@netconfcentral.com> <20081217.101749.22020128.mbj@tail-f.com> <49492989.3060002@netconfcentral.com> <20081217.225411.59447952.mbj@tail-f.com> In-Reply-To: <20081217.225411.59447952.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>> But a vendor can claim anything, regardless of the deviation >>> statement. Just b/c they specify how broken they are does not make >>> them more compliant. >>> >> This is the first time an IETF standard would be helping >> the vendor 'claim anything'. > > As David S. pointed out in another thread, this concept is supported > today in SMIv2 with AGENT-CAPABILITIES. > There are many constraints placed on AGENT-CAPABILITIES sub-clauses such as WRITE-SYNTAX. You cannot replace the data type with a completely different type like YANG. YANG allows all the semantics to be changed, not just constrained. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 14:10:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580C628C143; Wed, 17 Dec 2008 14:10:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CA828C1BB for ; Wed, 17 Dec 2008 14:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 EitUphCvgtle for ; Wed, 17 Dec 2008 14:10:11 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4171928C143 for ; Wed, 17 Dec 2008 14:10:10 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 83F8776C521; Wed, 17 Dec 2008 23:10:02 +0100 (CET) Date: Wed, 17 Dec 2008 23:09:59 +0100 (CET) Message-Id: <20081217.230959.200367540.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49492295.2000102@netconfcentral.com> References: <4948E228.40604@netconfcentral.com> <20081217.132647.193292739.mbj@tail-f.com> <49492295.2000102@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Here is the revised capability encoding. > All YANG modules are the same. They all > begin with the keyword 'module'. They can can > contain an arbitrary mix of any YANG body-stmts. > > A deviations-only module is just a corner-case. > Why doesn't the agent advertise every module that > has a deviation-stmt in it as a deviation? It would. > Because it is not needed. Neither is deviations=blah > > Why not just advertise the deviations module just like > any other module? I tried to explain that in my earlier email. I will try to rephrase: If we don't specify the deviations=..., the client will not know if there are any deviations in place for a particular module. So it has to assume that there might be deviations. Thus, it would have to download all modules found in the schema discovery list, and scan them all for deviation statetements for the particular module. > > http://example.com/foo?module=foo&revision=2008-12-01 > > > http://example.com/bar?module=bar&revision=2008-01-04 > > > http://example.com/dev-pA?module=dev-platform-A&revision=2008-12-16 > > > What happens if the vendor adds a leaf to module dev-platform-A? > Does the 'deviations=dev-module-A' get dropped from all the other > capability URIs at that point, and the module get advertised > instead? No, the deviations=... will not be dropped, and the module is advertised already in your example. So nothing changes in the hello message. The deviations= tells a client that the module being advertised has some deviation statements in the modules in the list. It does not say that the modules in the list *only* has deviations. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 14:17:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D08E3A6B21; Wed, 17 Dec 2008 14:17:47 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1EF3A6B46 for ; Wed, 17 Dec 2008 14:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 zQQi6x2xit2h for ; Wed, 17 Dec 2008 14:17:45 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A8BEB3A6B21 for ; Wed, 17 Dec 2008 14:17:45 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B942276C521; Wed, 17 Dec 2008 23:17:37 +0100 (CET) Date: Wed, 17 Dec 2008 23:17:35 +0100 (CET) Message-Id: <20081217.231735.193026122.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49497742.3040205@netconfcentral.com> References: <49492989.3060002@netconfcentral.com> <20081217.225411.59447952.mbj@tail-f.com> <49497742.3040205@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>> But a vendor can claim anything, regardless of the deviation > >>> statement. Just b/c they specify how broken they are does not make > >>> them more compliant. > >>> > >> This is the first time an IETF standard would be helping > >> the vendor 'claim anything'. > > As David S. pointed out in another thread, this concept is supported > > today in SMIv2 with AGENT-CAPABILITIES. > > > > There are many constraints placed on AGENT-CAPABILITIES > sub-clauses such as WRITE-SYNTAX. You cannot replace > the data type with a completely different type like YANG. > YANG allows all the semantics to be changed, not just constrained. I think it would be appropriate to have the same kind of restrictions in YANG. If you really want to completely change the type you will have to specify that you don't support the standard object, and add a brand new object (through augmentation). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 14:51:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C6F3A688C; Wed, 17 Dec 2008 14:51:22 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C893A688C for ; Wed, 17 Dec 2008 14:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.046, 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 WH7N+BOZhxjx for ; Wed, 17 Dec 2008 14:51:20 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id B7BDC3A689F for ; Wed, 17 Dec 2008 14:51:20 -0800 (PST) Received: (qmail 83855 invoked from network); 17 Dec 2008 22:51:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 22:51:11 -0000 X-YMail-OSG: Ge8zsMgVM1nXEFggLnGk5.gPzcOMF1uoGwr8AyDhG9RS4A_Ly2sCKCyrVrc04tThPIbyLZl0pZ3jAAivJh2csiP4NgZPZ7UWwHiN8ogOPX9Q6QQaJAT5U5PpYisZhgyM0v6ZYhFdupEVucscUXBfYG_6QAzUI9Lf8s3GRWE1B6W_vkGGM8sLsV5dsTVt X-Yahoo-Newman-Property: ymail-3 Message-ID: <4949825E.3000001@netconfcentral.com> Date: Wed, 17 Dec 2008 14:51:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4948E228.40604@netconfcentral.com> <20081217.132647.193292739.mbj@tail-f.com> <49492295.2000102@netconfcentral.com> <20081217.230959.200367540.mbj@tail-f.com> In-Reply-To: <20081217.230959.200367540.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Here is the revised capability encoding. >> All YANG modules are the same. They all >> begin with the keyword 'module'. They can can >> contain an arbitrary mix of any YANG body-stmts. >> >> A deviations-only module is just a corner-case. >> Why doesn't the agent advertise every module that >> has a deviation-stmt in it as a deviation? > > It would. > >> Because it is not needed. Neither is deviations=blah >> >> Why not just advertise the deviations module just like >> any other module? > > I tried to explain that in my earlier email. I will try to rephrase: > > If we don't specify the deviations=..., the client will not know if > there are any deviations in place for a particular module. So it has > to assume that there might be deviations. Thus, it would have to > download all modules found in the schema discovery list, and scan them > all for deviation statetements for the particular module. > >> >> http://example.com/foo?module=foo&revision=2008-12-01 >> >> >> http://example.com/bar?module=bar&revision=2008-01-04 >> >> >> http://example.com/dev-pA?module=dev-platform-A&revision=2008-12-16 >> >> >> What happens if the vendor adds a leaf to module dev-platform-A? >> Does the 'deviations=dev-module-A' get dropped from all the other >> capability URIs at that point, and the module get advertised >> instead? > > No, the deviations=... will not be dropped, and the module is > advertised already in your example. So nothing changes in the > hello message. > > The deviations= tells a client that the module being advertised has > some deviation statements in the modules in the list. It does > not say that the modules in the list *only* has deviations. > I do not think the draft explains much of this procedure. The manager is going to get N module capabilities from the agent, processed by a machine. Why would the manager ignore some modules and not others? As soon as the manager does a or it is going to want all the modules anyway, so it recognizes the nodes in the reply. A list of deviation module names (maybe the same one) attached to potentially many capability URIs is complicated. There is no way to get some of the capabilities but not all of them. There seems to be no reason to optimize for something not even supported by NETCONF anyway. Since the message is the only opportunity for the manager to process agent capabilities, I suggest not ignoring some of them. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 15:03:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA9028C1E1; Wed, 17 Dec 2008 15:03:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FE428C1E2 for ; Wed, 17 Dec 2008 15:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 6l59L1OcVx7O for ; Wed, 17 Dec 2008 15:03:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 41BF128C1BB for ; Wed, 17 Dec 2008 15:03:18 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 53F0076C521; Thu, 18 Dec 2008 00:03:09 +0100 (CET) Date: Thu, 18 Dec 2008 00:03:07 +0100 (CET) Message-Id: <20081218.000307.169295304.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4949825E.3000001@netconfcentral.com> References: <49492295.2000102@netconfcentral.com> <20081217.230959.200367540.mbj@tail-f.com> <4949825E.3000001@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I do not think the draft explains much of this procedure. > The manager is going to get N module capabilities from > the agent, processed by a machine. Why would the manager > ignore some modules and not others? It all depends on the client application. Suppose I write a little management application that configures ipfix on devices. My app connects to the device, parses the and scans for the ipfix URI, ignoring the other capabilities. If the ipfix URI is not found, my app disconnects. If it is found, and does not have any deviations, my app will do its normal job. However, if the ipfix URI has a deviation statement, my app will try to download the modules with deviation statements, parse them and apply the deviations (e.g. it might make sure that the user does not try to create more observationPoints than the device support). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 15:58:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118B63A688C; Wed, 17 Dec 2008 15:58:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241423A6B1A for ; Wed, 17 Dec 2008 15:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.046, 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 lFsHpqgj-9yp for ; Wed, 17 Dec 2008 15:58:52 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 8AEF23A688C for ; Wed, 17 Dec 2008 15:58:52 -0800 (PST) Received: (qmail 26846 invoked from network); 17 Dec 2008 23:58:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.8 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 17 Dec 2008 23:58:43 -0000 X-YMail-OSG: u8SFP_IVM1lWmjZb2518U5ICKWQT6.q1xe5NtEhnjJMeMadJW3MJ6pWb3k_BkZO_Tvc.J9pUTOAX2MGj05tybDy_IFI4kFgp4fgrtja6e6wbDwGzaeZEIz7a65SezaoVIQ5WNCE9oWMMORaWWWGkcUwGFitiL7rnLdLcXS1.L7WXWRFszNQW3bliqf8rdmZsqleieBEY0FmvWCItXutjcA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49499230.5040500@netconfcentral.com> Date: Wed, 17 Dec 2008 15:58:40 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49492295.2000102@netconfcentral.com> <20081217.230959.200367540.mbj@tail-f.com> <4949825E.3000001@netconfcentral.com> <20081218.000307.169295304.mbj@tail-f.com> In-Reply-To: <20081218.000307.169295304.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I do not think the draft explains much of this procedure. >> The manager is going to get N module capabilities from >> the agent, processed by a machine. Why would the manager >> ignore some modules and not others? > > It all depends on the client application. Suppose I write a little > management application that configures ipfix on devices. My app > connects to the device, parses the and scans for the ipfix > URI, ignoring the other capabilities. If the ipfix URI is not found, > my app disconnects. If it is found, and does not have any deviations, > my app will do its normal job. However, if the ipfix URI has a > deviation statement, my app will try to download the modules with > deviation statements, parse them and apply the deviations (e.g. it > might make sure that the user does not try to create more > observationPoints than the device support). > You should look at all the modules in case any of them augment the ipfix model. I do not think this is a strong use-case. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 17 23:54:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C4228C201; Wed, 17 Dec 2008 23:54:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6611228C202 for ; Wed, 17 Dec 2008 23:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 T3VEIsEzjjXi for ; Wed, 17 Dec 2008 23:54:26 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9918F28C205 for ; Wed, 17 Dec 2008 23:54:26 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EC3CC76C51F; Thu, 18 Dec 2008 08:54:17 +0100 (CET) Date: Thu, 18 Dec 2008 08:54:17 +0100 (CET) Message-Id: <20081218.085417.65089208.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49499230.5040500@netconfcentral.com> References: <4949825E.3000001@netconfcentral.com> <20081218.000307.169295304.mbj@tail-f.com> <49499230.5040500@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I do not think the draft explains much of this procedure. > >> The manager is going to get N module capabilities from > >> the agent, processed by a machine. Why would the manager > >> ignore some modules and not others? > > It all depends on the client application. Suppose I write a little > > management application that configures ipfix on devices. My app > > connects to the device, parses the and scans for the ipfix > > URI, ignoring the other capabilities. If the ipfix URI is not found, > > my app disconnects. If it is found, and does not have any deviations, > > my app will do its normal job. However, if the ipfix URI has a > > deviation statement, my app will try to download the modules with > > deviation statements, parse them and apply the deviations (e.g. it > > might make sure that the user does not try to create more > > observationPoints than the device support). > > > > You should look at all the modules in case any of them augment > the ipfix model. Why would I do that. My app doesn't care about them anyway. It can configure standard ipfix. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 00:29:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCF63A688F; Thu, 18 Dec 2008 00:29:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CD33A6867 for ; Thu, 18 Dec 2008 00:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 WO4zPQZUPki1 for ; Thu, 18 Dec 2008 00:29:50 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DD6253A682A for ; Thu, 18 Dec 2008 00:29:49 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6893176C310; Thu, 18 Dec 2008 09:29:40 +0100 (CET) Date: Thu, 18 Dec 2008 09:29:37 +0100 (CET) Message-Id: <20081218.092937.147059533.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <49496600.2040902@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Spakes wrote: > At my current level of understanding of Yang, "deviation replace" is > eqivalent to SMIv2's "VARIATION...SYNTAX". > > What I am trying to figure out is how one expresses SMIv2's > "VARIATION...WRITE-SYNTAX" in Yang. NETCONF and YANG differentiates between config and non-config data. Only config data can be modified directly with standard NETCONF operations. For config data, what can be read must be possible to write as well (to support config save and load). Thus, a config object cannot have different types for read and write. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 04:28:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F0E3A6844; Thu, 18 Dec 2008 04:28:35 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9D93A6933 for ; Thu, 18 Dec 2008 04:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, 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 zeS5nbfiwYPZ for ; Thu, 18 Dec 2008 04:28:32 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 87FB03A6885 for ; Thu, 18 Dec 2008 04:28:32 -0800 (PST) Received: (qmail 38915 invoked from network); 18 Dec 2008 12:28:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 12:28:22 -0000 X-YMail-OSG: LffGxNUVM1nUygUyxjBYtmMmvmiIUyI9WcCRpumkylaqO9D.rux6l701tb.sjz_2XuN7TH_2GVRTbJo89JzkEt1znqwj9DaxfLEpfaESs_HB9PcP.sni3h3Kb5Lvdedfb_S0mAThXIqlWInssfgy4NJKtseYQZbiOCnv2_X9ms86lX2YcfZCB2GAksqXROi_VVAcYV_vsk_dN9J8y8SkqQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A41E5.2070309@netconfcentral.com> Date: Thu, 18 Dec 2008 04:28:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4949825E.3000001@netconfcentral.com> <20081218.000307.169295304.mbj@tail-f.com> <49499230.5040500@netconfcentral.com> <20081218.085417.65089208.mbj@tail-f.com> In-Reply-To: <20081218.085417.65089208.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> I do not think the draft explains much of this procedure. >>>> The manager is going to get N module capabilities from >>>> the agent, processed by a machine. Why would the manager >>>> ignore some modules and not others? >>> It all depends on the client application. Suppose I write a little >>> management application that configures ipfix on devices. My app >>> connects to the device, parses the and scans for the ipfix >>> URI, ignoring the other capabilities. If the ipfix URI is not found, >>> my app disconnects. If it is found, and does not have any deviations, >>> my app will do its normal job. However, if the ipfix URI has a >>> deviation statement, my app will try to download the modules with >>> deviation statements, parse them and apply the deviations (e.g. it >>> might make sure that the user does not try to create more >>> observationPoints than the device support). >>> >> You should look at all the modules in case any of them augment >> the ipfix model. > > Why would I do that. My app doesn't care about them anyway. It can > configure standard ipfix. > Because YANG is too complicated already, and stuff like this makes it even more complicated. I strongly object to the mandatory ?deviations=blah change to the capability exchange defined in 4741. I do not think YANG has the right to change it. This should be done in 4741-bis, if at all. The deviations=blah is not only redundant, it puts a huge maintenance burden on the agent developer to track down every single deviation-stmt is every module, find the target (in perhaps another module) and adjust the capability URI for that module. All this, instead of simply advertising a list of modules that the NMS can choose to use or choose to ignore. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 04:42:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A1A3A6975; Thu, 18 Dec 2008 04:42:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F423A6960 for ; Thu, 18 Dec 2008 04:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 VN6B3zNatURY for ; Thu, 18 Dec 2008 04:42:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6028A3A6844 for ; Thu, 18 Dec 2008 04:42:47 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CF59776C310; Thu, 18 Dec 2008 13:42:38 +0100 (CET) Date: Thu, 18 Dec 2008 13:42:38 +0100 (CET) Message-Id: <20081218.134238.259366881.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <494A41E5.2070309@netconfcentral.com> References: <49499230.5040500@netconfcentral.com> <20081218.085417.65089208.mbj@tail-f.com> <494A41E5.2070309@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I strongly object to the mandatory ?deviations=blah > change to the capability exchange defined in 4741. > I do not think YANG has the right to change it. > This should be done in 4741-bis, if at all. I disagree. This is not a violation of rfc4741. 4741 says that the capability to advertise is a URI. This is a URI. 4741 actually uses the "query parameter" in the :url capability. > The deviations=blah is not only redundant, it > puts a huge maintenance burden on the agent developer > to track down every single deviation-stmt is every module, > find the target (in perhaps another module) and adjust > the capability URI for that module. This can be done once in the agent. The alternative of not specifying this puts the huge burden on the manager, and the manager must do this dynamically! > All this, instead of simply advertising a list of modules > that the NMS can choose to use or choose to ignore. The point is that unless the deviations parameter is advertised, an NMS cannot choose to ignore unknown capabilities! It must download and parse the modules b/c they might contain a deviation statament. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 05:42:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AC33A691A; Thu, 18 Dec 2008 05:42:59 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185E23A69D6 for ; Thu, 18 Dec 2008 05:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 mv9x8RqZa7sE for ; Thu, 18 Dec 2008 05:42:57 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 776723A691A for ; Thu, 18 Dec 2008 05:42:57 -0800 (PST) Received: (qmail 73644 invoked from network); 18 Dec 2008 13:42:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 13:42:47 -0000 X-YMail-OSG: 821RqS0VM1kXXxU8fN_AsZQiNHExtYzGKvMAg.OugvPsGBM1yKga_qtx_yxvKqmw.zxvBEEqzyuevaEj0rWwBQKM1oSvFX476tFNVZPTqHYusv7yLyGzZ3JIc3dvjcqgTlkS3XttanReSFwV4RWmugiORMyw8oLnxrHOjeqwMaKPYvLVsVFAN_093iZG2ryPpvTBxY7p8tB5YfGRMNHKvg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A5356.8080807@netconfcentral.com> Date: Thu, 18 Dec 2008 05:42:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4947DE47.8010003@netconfcentral.com> <20081216.233117.148311949.mbj@tail-f.com> In-Reply-To: <20081216.233117.148311949.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: ... >> As with augment and refine, there is no text wrt/ >> multiple deviation statements that refer to the same target. > > I would like to state that an object MUST NOT occur in more than one > deviation statement in a module, and that a property MUST NOT be > deviated more than once. > I do not see how this helps, since an arbitrary subset of modules can have deviation-stmts, for which the targets may overlap. So the agent has to combine deviation-stmts anyway (just like augment across submodules). Restricting the DM writer to 1-per-module does not solve any problem. It just creates a CLR. It is more work for the compiler to generate errors for this, than it is to just combine the sub-clauses. It is fine to be strict about adding existing subclauses, deleting nonexistent subclauses, and declaring the same subclause twice. But if one submodule changes min-elements and another one changes the default-stmt, why should this be illegal? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 05:52:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9451E3A681C; Thu, 18 Dec 2008 05:52:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86133A691A for ; Thu, 18 Dec 2008 05:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 gApT8YzksgF2 for ; Thu, 18 Dec 2008 05:52:38 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 03AF13A681C for ; Thu, 18 Dec 2008 05:52:37 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5ACC776C310; Thu, 18 Dec 2008 14:52:29 +0100 (CET) Date: Thu, 18 Dec 2008 14:52:29 +0100 (CET) Message-Id: <20081218.145229.89764533.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <494A5356.8080807@netconfcentral.com> References: <4947DE47.8010003@netconfcentral.com> <20081216.233117.148311949.mbj@tail-f.com> <494A5356.8080807@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > ... > >> As with augment and refine, there is no text wrt/ > >> multiple deviation statements that refer to the same target. > > I would like to state that an object MUST NOT occur in more than one > > deviation statement in a module, and that a property MUST NOT be > > deviated more than once. > > > > I do not see how this helps Ok. Should the deviations be done in sequence? So would this (stupid) example be legal: deviation /foo/bar { deviate add { must ". > baz"; } deviate delete { must ". > baz"; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 06:11:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE7C3A686A; Thu, 18 Dec 2008 06:11:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7BA3A686A for ; Thu, 18 Dec 2008 06:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Pm+p4+uvYZpM for ; Thu, 18 Dec 2008 06:11:49 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 47FA93A6784 for ; Thu, 18 Dec 2008 06:11:49 -0800 (PST) Received: (qmail 55081 invoked from network); 18 Dec 2008 14:11:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 14:11:38 -0000 X-YMail-OSG: 21jZnh8VM1nXIp9cO2M_3H.eZcLcjSObW3P.iG7ZN5bbei37EX79EMC39gH4B5Mv5GM0fmK5_kAcK1meXyfnvsVex0pAf3i1.CdV_.ykdSd_8mAbi6PjpeWrWtT2lUcr3ffPySxQuI_TsaJmUa5.AuuOHL5DLmQ1NLHd8EE46H5EDJnY4D_5AvmVZBrCWoGbSv3XxweVmDpp5iUnePOPLw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A5A19.3010101@netconfcentral.com> Date: Thu, 18 Dec 2008 06:11:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <4947DE47.8010003@netconfcentral.com> <20081216.233117.148311949.mbj@tail-f.com> <494A5356.8080807@netconfcentral.com> <20081218.145229.89764533.mbj@tail-f.com> In-Reply-To: <20081218.145229.89764533.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >> ... >>>> As with augment and refine, there is no text wrt/ >>>> multiple deviation statements that refer to the same target. >>> I would like to state that an object MUST NOT occur in more than one >>> deviation statement in a module, and that a property MUST NOT be >>> deviated more than once. >>> >> I do not see how this helps > > Ok. > > Should the deviations be done in sequence? > > So would this (stupid) example be legal: > > deviation /foo/bar { > deviate add { > must ". > baz"; > } > deviate delete { > must ". > baz"; > } > } > No, because the compiler cannot possibly satisfy both the 'add' and 'delete' requests. According to the text, one of them MUST fail. The existing target node either has the must-stmt or not. You can only add if it is not there. You can only delete if it is there. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 06:29:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F313A681C; Thu, 18 Dec 2008 06:29:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7063A686A for ; Thu, 18 Dec 2008 06:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.073, 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 87VYhrN5+ZQ4 for ; Thu, 18 Dec 2008 06:29:26 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 6FF473A681C for ; Thu, 18 Dec 2008 06:29:26 -0800 (PST) Received: (qmail 89878 invoked from network); 18 Dec 2008 14:29:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 14:29:17 -0000 X-YMail-OSG: HuK6c_kVM1mnWUOqtKodmjq4FlBLVJfF27k37_NNSwAhPwvlqdFMMixHXJ..QBYzRrKKcoV_YBZTQXp8QQzg5aUpEfLhvNfulplJfDWpbVOVUpfgrO92QffwSEybWRL38tlKchLLcpTGGWgR0jaVQqtRF4MAn0Kx.VmMZnvcJXQt1zn0yRMHHIKg4fSjtpIltqglV.7lKnE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A5E3C.2070102@netconfcentral.com> Date: Thu, 18 Dec 2008 06:29:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49496600.2040902@netconfcentral.com> <20081218.092937.147059533.mbj@tail-f.com> In-Reply-To: <20081218.092937.147059533.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > David Spakes wrote: >> At my current level of understanding of Yang, "deviation replace" is >> eqivalent to SMIv2's "VARIATION...SYNTAX". >> >> What I am trying to figure out is how one expresses SMIv2's >> "VARIATION...WRITE-SYNTAX" in Yang. > > NETCONF and YANG differentiates between config and non-config data. > Only config data can be modified directly with standard NETCONF > operations. For config data, what can be read must be possible to > write as well (to support config save and load). Thus, a config > object cannot have different types for read and write. > > This is one of those SMIv2 mechanisms to deal with WG consensus. The WRITE-SYNTAX is supposed to be a subset of the SYNTAX. The agent is saying "I support all the values, but you can only set 2 of them and I can set the rest." I agree this should not be supported in YANG. > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 06:33:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5898828C0D8; Thu, 18 Dec 2008 06:33:03 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7622628C173 for ; Thu, 18 Dec 2008 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, FRT_LITTLE=1.555, 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 gJl6Kclft1Ui for ; Thu, 18 Dec 2008 06:33:01 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id BF50428C0D8 for ; Thu, 18 Dec 2008 06:33:01 -0800 (PST) Received: (qmail 881 invoked from network); 18 Dec 2008 14:32:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 14:32:52 -0000 X-YMail-OSG: xazF.NQVM1l1fQLECrgaKehJ_BYBwrh8vW1ixVvyL1dQf6zNvKHNCLsGv73DjXmwghsVANOV31dMBiLBiyYmqI5yV4oXbn5egRXIDco46o3bL97zeVkXesYN5DEzRpImIVKFo4v999N1nHLFd_xh84OxA.dkBUsPMOB1ia9zo6i4VO11QBv_EnFNp74TUTtOluJXWIvLstfDuhjjRIRRTQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A5F13.9030304@netconfcentral.com> Date: Thu, 18 Dec 2008 06:32:51 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49492989.3060002@netconfcentral.com> <20081217.225411.59447952.mbj@tail-f.com> <49497742.3040205@netconfcentral.com> <20081217.231735.193026122.mbj@tail-f.com> In-Reply-To: <20081217.231735.193026122.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>>> But a vendor can claim anything, regardless of the deviation >>>>> statement. Just b/c they specify how broken they are does not make >>>>> them more compliant. >>>>> >>>> This is the first time an IETF standard would be helping >>>> the vendor 'claim anything'. >>> As David S. pointed out in another thread, this concept is supported >>> today in SMIv2 with AGENT-CAPABILITIES. >>> >> There are many constraints placed on AGENT-CAPABILITIES >> sub-clauses such as WRITE-SYNTAX. You cannot replace >> the data type with a completely different type like YANG. >> YANG allows all the semantics to be changed, not just constrained. > > I think it would be appropriate to have the same kind of restrictions > in YANG. If you really want to completely change the type you will > have to specify that you don't support the standard object, and > add a brand new object (through augmentation). > This will make it much less controversial. The builtin type MUST NOT change if you replace the type-stmt. (1 little CLR :-) > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 08:13:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A40F3A68E4; Thu, 18 Dec 2008 08:13:21 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC92E3A6B46 for ; Thu, 18 Dec 2008 08:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 3QLngJVkf8zS for ; Thu, 18 Dec 2008 08:13:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9F3113A68E4 for ; Thu, 18 Dec 2008 08:13:19 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B281EC0130 for ; Thu, 18 Dec 2008 17:13:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vuyjJIPG+nGp; Thu, 18 Dec 2008 17:13:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 844D3C0150; Thu, 18 Dec 2008 17:13:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81AA98BB059; Thu, 18 Dec 2008 17:13:05 +0100 (CET) Date: Thu, 18 Dec 2008 17:13:05 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081218161305.GA6703@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] types-012: date-and-time normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Description: The time-offset Z and +00:00 mean the same thing (but note that -00:00 means unknown time zone according to RFC 3339 but the same as Z according to XSD). Discussion: XSD says the canonical time-offset format is Z. Proposal: * Make Z the canonical time-offset format * Clarify that -00:00 means unknown time zone * Clarify that 00:00 and Z mean the same thing /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 08:13:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20C928C0F5; Thu, 18 Dec 2008 08:13:44 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C742128C0F6 for ; Thu, 18 Dec 2008 08:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-1.741, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 YfPWmiDXk34C for ; Thu, 18 Dec 2008 08:13:43 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F1BA228C101 for ; Thu, 18 Dec 2008 08:13:42 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7A98C0146 for ; Thu, 18 Dec 2008 17:13:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8Nq0RIEql03d; Thu, 18 Dec 2008 17:13:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74C25C007B; Thu, 18 Dec 2008 17:13:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8156C8BB072; Thu, 18 Dec 2008 17:13:27 +0100 (CET) Date: Thu, 18 Dec 2008 17:13:27 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081218161327.GB6703@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] types-013: zone index =?unknown-8bit?Q?nor?= =?unknown-8bit?Q?malization_=C2=B6?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Description: The zone index allows numeric (interface index) and string (interface name) representations. Discussion: Assuming that the native identification of interfaces in YANG will be interface names instead of interface index numbers, make the name representation the canonical format. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 08:14:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1258E28C0E4; Thu, 18 Dec 2008 08:14:09 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0327728C0F5 for ; Thu, 18 Dec 2008 08:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=-1.701, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 irJeexMOtKQs for ; Thu, 18 Dec 2008 08:14:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AE30828C0E4 for ; Thu, 18 Dec 2008 08:14:05 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4958C0083 for ; Thu, 18 Dec 2008 17:13:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dMeIsao6D1Ee; Thu, 18 Dec 2008 17:13:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE371C012D; Thu, 18 Dec 2008 17:13:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CBA8A8BB08F; Thu, 18 Dec 2008 17:13:52 +0100 (CET) Date: Thu, 18 Dec 2008 17:13:52 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081218161352.GC6703@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] ipv6 address =?unknown-8bit?Q?normalizatio?= =?unknown-8bit?Q?n_=C2=B6?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Description: The type currently supports full, shortened,mixed, and shortened mixed formats. Discussion: Proposal: * Allow multiple formats and representations * Make the shortened format the canonical format * The :: substitution must be applied to the longest sequence of zeros in an IPv6 address (if there is a tie, the first sequence of zeros is replaced by ::) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 08:14:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA8928C0E4; Thu, 18 Dec 2008 08:14:43 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199C828C0F6 for ; Thu, 18 Dec 2008 08:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 wNzIm5AeG5QM for ; Thu, 18 Dec 2008 08:14:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3DEE028C0E4 for ; Thu, 18 Dec 2008 08:14:41 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77CA6C0143 for ; Thu, 18 Dec 2008 17:14:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6bEqH7qzBK1N; Thu, 18 Dec 2008 17:14:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B46CC0119; Thu, 18 Dec 2008 17:14:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 407F18BB0C9; Thu, 18 Dec 2008 17:14:26 +0100 (CET) Date: Thu, 18 Dec 2008 17:14:26 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081218161426.GD6703@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] ipv4-prefix / ipv6-prefix normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Description: The two representations 192.0.2.0/24 and 192.0.2.8/24 mean the same thing. Discussion: Proposal: * Require that all bits that are not part of the prefix are set to zero (192.0.2.8/24 becomes an invalid representation of an IPv4 prefix) * For IPv6, the shortened form will be the canonical format, other representations are allowed * Results in a 1:1 mapping between lexical representation and the value space for IPv4 but not for IPv6 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 08:15:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE6128C0E4; Thu, 18 Dec 2008 08:15:09 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E1628C106 for ; Thu, 18 Dec 2008 08:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 4U0DMc-QbPXf for ; Thu, 18 Dec 2008 08:15:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7410E28C0E4 for ; Thu, 18 Dec 2008 08:15:07 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABFE9C0118 for ; Thu, 18 Dec 2008 17:14:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 69JS7PFA3SkG; Thu, 18 Dec 2008 17:14:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 777F1C0131; Thu, 18 Dec 2008 17:14:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 852B58BB0E2; Thu, 18 Dec 2008 17:14:54 +0100 (CET) Date: Thu, 18 Dec 2008 17:14:54 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081218161454.GE6703@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] types-016: domain name normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Description: The domain-name type currently allows upper-case and lower-case characters in the domain name. Discussion: Proposal: * Follow the text in the description clause of the uri data type which requires that all case-insensitive characters are set to lowercase * Results in a 1:1 mapping between lexical space and value space * Implementations can still be lenient in what they accept /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 09:16:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E003A6778; Thu, 18 Dec 2008 09:16:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE3C3A6778 for ; Thu, 18 Dec 2008 09:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 le1WjzPocYQm for ; Thu, 18 Dec 2008 09:16:38 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B4DB428C106 for ; Thu, 18 Dec 2008 09:16:23 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 32B1720A4F; Thu, 18 Dec 2008 18:16:15 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-e1-494a855fc0e8 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 16CE6207A0; Thu, 18 Dec 2008 18:16:15 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 18:16:14 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 18:16:14 +0100 Message-ID: <494A855D.2000709@ericsson.com> Date: Thu, 18 Dec 2008 18:16:13 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <49492989.3060002@netconfcentral.com> <20081217.225411.59447952.mbj@tail-f.com> <49497742.3040205@netconfcentral.com> <20081217.231735.193026122.mbj@tail-f.com> <494A5F13.9030304@netconfcentral.com> In-Reply-To: <494A5F13.9030304@netconfcentral.com> X-OriginalArrivalTime: 18 Dec 2008 17:16:14.0182 (UTC) FILETIME=[54920860:01C96134] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, Reading the thread some comments: 1) I hope that the order of evaluating the deviation statements does not influence the end result or the success/acceptability of deviation statements. However today it does. This could be a problem if the statements are in different modules, so the evaluation order is uncertain. E.g. add the subtree myInterfaces later add subtree myInterfaces/specialCounters Is this valid? If myInterfaces is evaluated first, it looks fine. If myInterfaces/specialCounters is evaluated first then it is trying to add something to a non-existing node .../myInterfaces, so it must fail. You could come up with a lot of other examples as well. 2) I think we should have a generic statement somewhere: "The model changed according to the deviation statements MUST be a valid YANG model." That cuts down a lot of corner cases. 3) Why is it not allowed to delete the default statement? 4) If we don't advertise models that only provide typedefs and groupings, why do we need to advertise pure deviation modules? (Actually I can live with advertising them.) Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 09:28:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A973A67F0; Thu, 18 Dec 2008 09:28:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD563A67F0 for ; Thu, 18 Dec 2008 09:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, 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 CBXeoMs0MHxD for ; Thu, 18 Dec 2008 09:28:54 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id D36F33A687F for ; Thu, 18 Dec 2008 09:28:54 -0800 (PST) Received: (qmail 23377 invoked from network); 18 Dec 2008 17:28:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 17:28:44 -0000 X-YMail-OSG: M2.Q3WUVM1lHhuiRlU5otkpTVrWHJWwVds.nYOGho5IeAqqyA6rArVglERA5cpXaV73EwZThQqdY5HnjVRvKmaMQNhs1kTJoMUmmYZz.K4CLDwQhTXATsPkDlJdQ4DD1sTcK78rGM6YRb2jb45bQ7MNv X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A884A.9090505@netconfcentral.com> Date: Thu, 18 Dec 2008 09:28:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Balazs Lengyel References: <49492989.3060002@netconfcentral.com> <20081217.225411.59447952.mbj@tail-f.com> <49497742.3040205@netconfcentral.com> <20081217.231735.193026122.mbj@tail-f.com> <494A5F13.9030304@netconfcentral.com> <494A855D.2000709@ericsson.com> In-Reply-To: <494A855D.2000709@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Reading the thread some comments: > > 1) I hope that the order of evaluating the deviation statements does not > influence the end result or the success/acceptability of deviation > statements. However today it does. This could be a problem if the > statements are in different modules, so the evaluation order is uncertain. > > E.g. add the subtree myInterfaces later add subtree > myInterfaces/specialCounters > Is this valid? > If myInterfaces is evaluated first, it looks fine. > If myInterfaces/specialCounters is evaluated first then it is trying to > add something to a non-existing node .../myInterfaces, so it must fail. > You could come up with a lot of other examples as well. > It does not matter. Just like augment, the targets can appear in any order, including out of order. The deviation-stmt is validated wrt/ the real object specified in the XPath target. The other deviation statements have nothing to do with it. The XPath target node will exist or not, regardless of how many deviation-stmts are present. Also, you cannot add objects via deviation-stmt. You can add sub-clauses to existing objects. > 2) I think we should have a generic statement somewhere: "The model > changed according to the deviation statements MUST be a valid YANG > model." That cuts down a lot of corner cases. > The new ABNF from Martin fixes that > 3) Why is it not allowed to delete the default statement? > > 4) If we don't advertise models that only provide typedefs and > groupings, why do we need to advertise pure deviation modules? (Actually > I can live with advertising them.) > You should advertise all the modules, especially when import-by-revision is added. > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 09:54:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82563A679C; Thu, 18 Dec 2008 09:54:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA793A679C for ; Thu, 18 Dec 2008 09:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 MjYsNT6VhgKp for ; Thu, 18 Dec 2008 09:54:13 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 8B7673A68D8 for ; Thu, 18 Dec 2008 09:54:13 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA08.westchester.pa.mail.comcast.net with comcast id sem41a06X17dt5G58hu6Th; Thu, 18 Dec 2008 17:54:06 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id shu61a0020UQ6dC3Zhu6Cx; Thu, 18 Dec 2008 17:54:06 +0000 From: "David Harrington" To: Date: Thu, 18 Dec 2008 12:54:05 -0500 Message-ID: <042f01c96139$9ed5c650$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0430_01C9610F.B5FFBE50" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclhOZ6VToM24sTrSYCvHghLjm04MA== Subject: [netmod] ietf73 netmod minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0430_01C9610F.B5FFBE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here are the netmod minutes from ietf73. Please speka up if you think anything is wrong. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0430_01C9610F.B5FFBE50 Content-Type: text/plain; name="IETF73-netmod-minutes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IETF73-netmod-minutes.txt" NETMOD WG=20 IETF 73, Minneapolis MN WG Chairs:=20 David Partain (david.partain@ericsson.com) David Harrington (ietfdbh@comcast.net)=20 THURSDAY, Nov 20, 2008 1520-1720 MP3 recording at ftp://videolab.uoregon.edu/pub/videolab/media/ietf73 = file:ietf73-ch5-thurs-noon2.mp3 Jabber: http://jabber.ietf.org/logs/netmod/2008-11-20.txt WG status review (15 minutes) David Partain we are in good shape; most documents on time. architecture and DSDL draft a bit behind Session goal: Conformation of consensus reached at interim meeting and = on ML: 1. NETMOD Architecture=20 Phil Shafer (15 min) http://tools.ietf.org/html/draft-shafer-netmod-arch-00 = =20 3/4 of the room have read this significant list of comments have not been addressed yet consensus to accept as WG draft, with required changes 2. Common YANG Data Types=20 M. Bjorklund (5 min) =20 http://tools.ietf.org/html/draft-ietf-netmod-yang-types-01 slides: = http://www.ietf.org/proceedings/08nov/slides/netmod-4.pdf 3. YANG - A data modeling language for NETCONF=20 M. Bjorklund (40 min) http://tools.ietf.org/html/draft-ietf-netmod-yang-02 This presentation will include YIN and XML deliverables (40 min) slides: = http://www.ietf.org/proceedings/08nov/slides/netmod-3.pdf Discussion of changes to document since last version. Canonical form: consensus to return the canonical form to = allow comparisons Refinement, when, and augment: consensus to accept Features: consensus to accept this feature Deviations: consensus to add this to document deviations from = standard agent-capabilities in SNMP failed, but adding this in the = beginning might work Identity and identityref: reusable enumerations=20 Update rules: two basic rules: protect old clients, import by = revision draft contains long list of specific update rules=20 4. Mapping of YANG to DSDL Ladislav Lhotka (15 min) http://tools.ietf.org/html/draft-lhotka-yang-dsdl-map-01=20 slides: = http://www.ietf.org/proceedings/08nov/slides/netmod-0.pdf MP3: ~54 minutes into MP3 description of how DSDL fits in the architecture: single full output DSDL "supermodel" or individual = models supplemented with XSLT to generate validation rules the supermodel will largely be dependent on device = support individual models (CF: single yang models) doesn't make = much sense extension mechanism if very different than yang = extension mechanism cannot keep same modularity as in yang expectation was that modularity would be the same, = similar to MIB consensus to build individual module translations, if = possible Lada will try to do this, and discuss further tomorrow if DSDL cannot do this, then maybe we should scrap DSDL DSDL is designed to do validation, not data modeling positioning: charter calls for a mapping from YANG to DSDL YANG is normative; DSDL converts to machine-friendly = format One way mapping from YANG to DSDL; no DSDL-to-YANG = mapping consensus to adopt this as a WG draft need ML confirmation Open mic (30 minutes)=20 New co-chair;=20 David H resigned as co-chair to work in other areas;=20 David Kessens is new co-chair Interim in Malta: netmod not interested;=20 IESG cancelling Malta meeting Desire to improve virtual meeting support ML consensus is enough is enough Chairs declare consensus that new features will not be accepted=20 after this two-session meeting. Consensus must be reached by = close of meeting on Friday to be accepted for yang 1.0. =20 Focus should be to get documents completed. Targeting WGLC following next IETF meeting. We need fresh eyes to review to verify we are on the right track Feature freeze is in effect FRIDAY, Nov 21, 2008 0900-1130=20 MP3 recording at ftp://videolab.uoregon.edu/pub/videolab/media/ietf73 = file:ietf73-ch4-fri-am.mp3 Jabber: http://jabber.ietf.org/logs/netmod/2008-11-21.txt Session goal: Open Issues in NETMOD, and proposals for added = functionality Open issues and questions for YANG/YIN/XML/LIB - Martin (60 min) slides: http://www.ietf.org/proceedings/08nov/slides/netmod-5.pdf how do we represent canonical form? consensus - alternative 3 keyref: consensus to support keyrefs conformance: consensus - wait until later release schema discovery format: consensus - Yang draft must say how and=20 what to advertise in the hello message inline rpc errors: concensus option 2 assigned-by: consensus - add this create-only for leafs: no consensus actions: no consensus to add this typed extensions: consensus - not in 1.0 Open issues and questions for DSDL (30 min) slides: http://www.ietf.org/proceedings/08nov/slides/netmod-2.pdf modularity can be emulated; it may be complicated XML syntax acceoted Copy all meta data agreed ------=_NextPart_000_0430_01C9610F.B5FFBE50 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0430_01C9610F.B5FFBE50-- From netmod-bounces@ietf.org Thu Dec 18 10:09:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B923A6984; Thu, 18 Dec 2008 10:09:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B683A6A4B for ; Thu, 18 Dec 2008 10:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 Z50lu3FntmDo for ; Thu, 18 Dec 2008 10:09:55 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E71233A6984 for ; Thu, 18 Dec 2008 10:09:54 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA19224; Thu, 18 Dec 2008 13:09:46 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA23102; Thu, 18 Dec 2008 13:09:46 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 18 Dec 2008 13:09:45 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund , andy@netconfcentral.com In-Reply-To: <20081218.092937.147059533.mbj@tail-f.com> Message-ID: References: <49496600.2040902@netconfcentral.com> <20081218.092937.147059533.mbj@tail-f.com> MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, 18 Dec 2008, Martin Bjorklund wrote: > NETCONF and YANG differentiates between config and non-config data. > Only config data can be modified directly with standard NETCONF > operations. For config data, what can be read must be possible to > write as well (to support config save and load). Thus, a config > object cannot have different types for read and write. Martin, I do understand and have appreciation for this difference between SMIv2/SNMP and Yang/Netconf. Thank you. On Thu, 18 Dec 2008, Andy Bierman wrote: > This is one of those SMIv2 mechanisms to deal with WG consensus. > The WRITE-SYNTAX is supposed to be a subset of the SYNTAX. > The agent is saying "I support all the values, but you > can only set 2 of them and I can set the rest." > > I agree this should not be supported in YANG. Andy, while I think you're right about this mechanism existing because of WG concensus, that's not to say that WRITE-SYNTAX doesn't serve a useful purpose. However, the usefulness may not [nor may need to] extend to Yang. I agree with your statements. On Thu, 18 Dec 2008, Andy Bierman wrote: > Actually, in your example, all that is needed is: > > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv4z { value 3; } > } > } > } Andy, here is how I interpret your response. 1. A contract between manager and agent based on the Yang equivalent to the MIB in RFC 4292 would state that the leaf inetCidrRouteDestType can take on any of the values 'unknown', 'ipv4', 'ipv6', 'ipv4z', 'ipv6z', or 'dns'. 2. The deviation statement above regarding a particular implementation tells the manager that the agent AT MINIMUM supports only instances of inetCidrRouteDestType with values of 'ipv4' and 'ipv4z'. Therefore: (a) If the manager sends a command to the agent, the reply from the agent includes only the rows having inetCidrRouteDestType = 'ipv4' or inetCidrRouteDestType = 'ipv4z' because those are the only configurable instances. The agent's behavior is the CAUSE of the "deviate replace" statement, not the result of it. (b) The manager must assume that the agent only supports the minimum advertised behavior (ipv4/4z) when it constructs an command. So, if the manager sends an command to the agent, the configuration data must include only rows that have inetCidrRouteDestType = 'ipv4' or inetCidrRouteDestType = 'ipv4z'. The manager's behavior is the RESULT of the "deviate replace" statement. 3. If the agent has some non-configuration data (read-only instances) in the list inetCidrRouteEntry for rows that have inetCidrRouteDestType = 'ipv6' or inetCidrRouteDestType = 'ipv6z', and if the manager sends a command to the agent, the reply from the agent may include this read-only data. In this case, the agent exceeds the minimum expectations that it set for itself and communicated to the manager in the "deviate replace" statement. The ipv6/6z rows are still valid for a response to the command because the original contract (in point 1) would state that 'ipv6' and 'ipv6z' are valid enumerations for inetCidrRouteDestType. Is this a correct understanding of your response, Andy? Regards, David ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 10:21:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8438128C0EB; Thu, 18 Dec 2008 10:21:01 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27D228C0EB for ; Thu, 18 Dec 2008 10:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 VhyOpWWJwf3k for ; Thu, 18 Dec 2008 10:20:59 -0800 (PST) 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 9B30028C0FB for ; Thu, 18 Dec 2008 10:20:59 -0800 (PST) Received: (qmail 6822 invoked from network); 18 Dec 2008 18:20:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 18 Dec 2008 18:20:49 -0000 X-YMail-OSG: s4H9aLMVM1lHlEEcVVxidXFayXkk7rr3B6Jy41ejuz1PtL.k23Dak9O.b9xgvnsfRN_PJ9lyRrMrdLp92w.MpncItsHMGoSml8ENdDbL7EGhvF9qyUSXvp40sBfWB2g6O4EYSUyhNQgV2ikSRp6KRuO6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <494A947F.5010303@netconfcentral.com> Date: Thu, 18 Dec 2008 10:20:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: David Spakes References: <49496600.2040902@netconfcentral.com> <20081218.092937.147059533.mbj@tail-f.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Spakes wrote: > On Thu, 18 Dec 2008, Martin Bjorklund wrote: > >> NETCONF and YANG differentiates between config and non-config data. >> Only config data can be modified directly with standard NETCONF >> operations. For config data, what can be read must be possible to >> write as well (to support config save and load). Thus, a config >> object cannot have different types for read and write. > > > Martin, I do understand and have appreciation for this difference > between SMIv2/SNMP and Yang/Netconf. Thank you. > > > On Thu, 18 Dec 2008, Andy Bierman wrote: > >> This is one of those SMIv2 mechanisms to deal with WG consensus. >> The WRITE-SYNTAX is supposed to be a subset of the SYNTAX. >> The agent is saying "I support all the values, but you >> can only set 2 of them and I can set the rest." >> >> I agree this should not be supported in YANG. > > > Andy, while I think you're right about this mechanism existing because > of WG concensus, that's not to say that WRITE-SYNTAX doesn't serve a > useful purpose. However, the usefulness may not [nor may need to] > extend to Yang. I agree with your statements. > > > On Thu, 18 Dec 2008, Andy Bierman wrote: > >> Actually, in your example, all that is needed is: >> >> deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { >> deviate replace { >> type enumeration { >> enum ipv4 { value 1; } >> enum ipv4z { value 3; } >> } >> } >> } > > > Andy, here is how I interpret your response. > > 1. A contract between manager and agent based on the Yang equivalent to > the MIB in RFC 4292 would state that the leaf inetCidrRouteDestType > can take on any of the values 'unknown', 'ipv4', 'ipv6', 'ipv4z', > 'ipv6z', or 'dns'. > > 2. The deviation statement above regarding a particular implementation > tells the manager that the agent AT MINIMUM supports only instances > of inetCidrRouteDestType with values of 'ipv4' and 'ipv4z'. > Therefore: > > (a) If the manager sends a command to the agent, > the reply from the agent includes only the rows having > inetCidrRouteDestType = 'ipv4' or inetCidrRouteDestType = 'ipv4z' > because those are the only configurable instances. The agent's > behavior is the CAUSE of the "deviate replace" statement, > not the result of it. > > (b) The manager must assume that the agent only supports the > minimum advertised behavior (ipv4/4z) when it constructs > an command. So, if the manager sends an > command to the agent, the configuration data > must include only rows that have inetCidrRouteDestType = 'ipv4' > or inetCidrRouteDestType = 'ipv4z'. The manager's behavior > is the RESULT of the "deviate replace" statement. > > 3. If the agent has some non-configuration data (read-only instances) > in the list inetCidrRouteEntry for rows that have > inetCidrRouteDestType = 'ipv6' or inetCidrRouteDestType = 'ipv6z', > and if the manager sends a command to the agent, the reply > from the agent may include this read-only data. In this case, > the agent exceeds the minimum expectations that it set for itself > and communicated to the manager in the "deviate replace" statement. > The ipv6/6z rows are still valid for a response to the command > because the original contract (in point 1) would state that 'ipv6' > and 'ipv6z' are valid enumerations for inetCidrRouteDestType. > > > Is this a correct understanding of your response, Andy? > sort of... YANG has no concept of read-only configuration. Or rather, if it is read-only, it isn't configuration data. So there is no chance that the agent can have some instances of ipv6 if declares a deviation like your example. The deviations are likely to be set at code-compile-time, not at code-runtime. The deviation is not a minimum conformance like MIN-ACCESS. It is a conceptual edit to the YANG definition specified by the target. > > Regards, > David > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 13:34:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A5E3A67F4; Thu, 18 Dec 2008 13:34:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E233A6A3F for ; Thu, 18 Dec 2008 13:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 Wd8wt4QOXLKR for ; Thu, 18 Dec 2008 13:34:46 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 50BCD3A67F4 for ; Thu, 18 Dec 2008 13:34:46 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA07817; Thu, 18 Dec 2008 16:34:38 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA25143; Thu, 18 Dec 2008 16:34:37 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 18 Dec 2008 16:34:37 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <494A947F.5010303@netconfcentral.com> Message-ID: References: <49496600.2040902@netconfcentral.com> <20081218.092937.147059533.mbj@tail-f.com> <494A947F.5010303@netconfcentral.com> MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, 18 Dec 2008, Andy Bierman wrote: > YANG has no concept of read-only configuration. > Or rather, if it is read-only, it isn't configuration data. I understand and agree, but that is one aspect of Yang that is troubling to me. My perception is that many real-world devices have some initial configuration that you can build on but not delete. Usually not good if you're talking about security configuration, but for application data there may be a lot of pros compared to the cons. Vendors want their devices to work out-of-the-box with little or no setup. Support teams want a valid configuration to always be present on a device so they can work around problems created by users. And so on. > The deviations are likely to be set at code-compile-time, > not at code-runtime. I'm not sure that really matters. The main point for me is that you might have a lot of leaf data items that are sometimes configurable and sometimes not but otherwise identical. One _could_ define everything as a grouping and then have two uses, one "config true;" and another "config false;". This doesn't seem "natural" to me though. If it is routing entry, I want to see it in the same table for a whether it is a configurable routing entry or a permanent routing entry. > So there is no chance that the agent can have some instances > of ipv6 if declares a deviation like your example. I think you are referring to your revision on my example... Andy Bierman wrote: > Actually, in your example, all that is needed is: > > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv4z { value 3; } > } > } > } ...and yes, if defined this way (above), I concede that there would be no chance that the agent could have ipv6 instances. No one has commented yet on the conceptual syntax that I included in an earlier message. I would like to repeat it again (below) and invite comments. On Wed, 17 Dec 2008, David Spakes wrote: > Conceptually, what I'm looking for is something like this (I know this > isn't legal Yang syntax)... > > > deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { > deviate replace { > type enumeration { > enum ipv4 { value 1; } > enum ipv6 { value 2; } > enum ipv4z { value 3; } > enum ipv6z { value 4; } > } > when ". = 'ipv6' or . = 'ipv6z'" { > config false; > } > } > } If it is legal to have a deviation that changes "config true;" to "config false;" for all instances (Section 7.18.3.2), why not allow a deviation that does the same for a subset of instances? Regards, David ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 13:47:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718EB28C0F0; Thu, 18 Dec 2008 13:47:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C52B28C108 for ; Thu, 18 Dec 2008 13:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 203lMCTBp1uv for ; Thu, 18 Dec 2008 13:47:35 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 34EB928C0F0 for ; Thu, 18 Dec 2008 13:47:35 -0800 (PST) X-Trace: 206343444/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.210/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.210 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIEAHpTSkk+vGTS/2dsb2JhbACDQ4lusWFYkFoHgn8 X-IronPort-AV: E=Sophos;i="4.36,245,1228089600"; d="scan'208";a="206343444" X-IP-Direction: IN Received: from 1cust210.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.210]) by smtp.pipex.tiscali.co.uk with SMTP; 18 Dec 2008 21:47:24 +0000 Message-ID: <003f01c96151$dcac62a0$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer> Date: Thu, 18 Dec 2008 21:47:28 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Having verified that XPath 1.0 does indeed specify that IEEE 754 shall be used when comparing numbers (and warns that this may lose precision when converting from decimal) I thought I would look up the precise text of IEEE 754. Oh dear. Google 'IEEE 754' brings up a sponsored link to the ANSI web site promising a free download of IEEE 754. Click on it and you do indeed get the ANSI web site with a message that what you have selected is not available and suggests modifying your search (whatever that was). Go to IEEE and you find that IEEE 754 was reissued in August 2008 and so is not yet out of purdah. The 1985 version that XPath references is listed, .pdf and size, but click on it and .... 'not available'. Try for the summary and ... , 'not available' Oh dear. Perhaps we need a deviation from XPath 1.0 (I note that XPath 2.0 - yes, noone implements it but as has been pointed out several times on this list, we do not need an implementation - has dropped all reference to IEEE 754 and adopted the common sense approach to comparisons that most other languages I know of use) like the adoption of XPath 2.0 Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Wednesday, December 17, 2008 7:15 AM Subject: Re: [netmod] octal numbers > Hi - > > > From: "Andy Bierman" > > To: "Martin Bjorklund" > > Cc: ; > > Sent: Tuesday, December 16, 2008 6:11 PM > > Subject: Re: [netmod] octal numbers > ... > > I am trying to clarify the text. > > If a smart guy like Randy can get confused by the YANG vs. XPath > > expression number representations, then lots of people will get confused. > > > > http://www.w3.org/TR/xpath#numbers > > > > BTW, it is not just the default-stmt. > > Numbers also show up in min-elements, max-elements, ranges, > > and patterns. > > > > Inside XPath strings like the must-stmt or when-stmt argument, > > the YANG rules do not apply, just the XPath rules. > > I admit to being rather confused here. If XPath uses IEE 754, then > there are plenty of 64-bit integers that cannot be represented, or, > worse still, will be treated as being equal to other 64-bit integers > that have different bit patterns. This would seem to be a potential > trap for the unwary. Limiting the use of integer values to only those > values that will survive the IEEE 754 <-> integer round trip unscathed > seems a scary prospect. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 14:08:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478C23A692D; Thu, 18 Dec 2008 14:08:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7D23A692D for ; Thu, 18 Dec 2008 14:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] 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 SHseBi5THmRg for ; Thu, 18 Dec 2008 14:08:12 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id C23B93A6889 for ; Thu, 18 Dec 2008 14:08:12 -0800 (PST) Received: (qmail 59258 invoked from network); 18 Dec 2008 22:08:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 22:08:03 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <494AC9C1.7090809@netconfcentral.com> Date: Thu, 18 Dec 2008 14:08:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: David Spakes References: <49496600.2040902@netconfcentral.com> <20081218.092937.147059533.mbj@tail-f.com> <494A947F.5010303@netconfcentral.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] Constraints section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Spakes wrote: ... >> deviation /ipForward/inetCidrRouteEntry/inetCidrRouteDestType { >> deviate replace { >> type enumeration { >> enum ipv4 { value 1; } >> enum ipv6 { value 2; } >> enum ipv4z { value 3; } >> enum ipv6z { value 4; } >> } >> when ". = 'ipv6' or . = 'ipv6z'" { >> config false; >> } >> } >> } > > > If it is legal to have a deviation that changes "config true;" to > "config false;" for all instances (Section 7.18.3.2), why not allow a > deviation that does the same for a subset of instances? > Isn't YANG complicated enough without evaluating XPath expressions to see which sub-clauses are present in a node? I don't think the NETCONF community wants a complicated definition of configuration data. In the NETCONF view of the world, if the agent has a bunch of data that the manager cannot change, that is called state data. Corner-cases such as this, or create-only, or write-only, are not supported. > Regards, > David Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 14:21:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F353A63EB; Thu, 18 Dec 2008 14:21:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA493A683E for ; Thu, 18 Dec 2008 14:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.098, 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 ofqWkQFVwwZH for ; Thu, 18 Dec 2008 14:21:47 -0800 (PST) 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 816E13A63EB for ; Thu, 18 Dec 2008 14:21:47 -0800 (PST) Received: (qmail 21265 invoked from network); 18 Dec 2008 22:21:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 18 Dec 2008 22:21:38 -0000 X-YMail-OSG: ko1QSZwVM1nV7aL7r5xq6QeO9eUxaJ.R0DS_2FKQLyDBojBewZiiBO2j5V8pX4sOjd6LgFpA7Rfvwe9cT55lkOBerQAB7MrnDFCm6HZPxWUwG9ASBW20jHmLtCDkTGL_hG3V8H0yjYkP7YxLiiP9kV.eq7ezSc5Raht0yeUOSrpKqr9tejf72HjT X-Yahoo-Newman-Property: ymail-3 Message-ID: <494ACCF0.9030309@netconfcentral.com> Date: Thu, 18 Dec 2008 14:21:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "tom.petch" References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer> <003f01c96151$dcac62a0$0601a8c0@allison> In-Reply-To: <003f01c96151$dcac62a0$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org tom.petch wrote: > Having verified that XPath 1.0 does indeed specify that IEEE 754 shall be used > when comparing numbers (and warns that this may lose precision when converting > from decimal) I thought I would look up the precise text of IEEE 754. > > Oh dear. > > Google 'IEEE 754' brings up a sponsored link to the ANSI web site promising a > free download of IEEE 754. Click on it and you do indeed get the ANSI web site > with a message that what you have selected is not available and suggests > modifying your search (whatever that was). > > Go to IEEE and you find that IEEE 754 was reissued in August 2008 and so is not > yet out of purdah. The 1985 version that XPath references is listed, .pdf and > size, but click on it and .... 'not available'. Try for the summary and ... , > 'not available' > > Oh dear. Perhaps we need a deviation from XPath 1.0 (I note that XPath 2.0 - > yes, noone implements it but as has been pointed out several times on this list, > we do not need an implementation - has dropped all reference to IEEE 754 and > adopted the common sense approach to comparisons that most other languages I > know of use) like the adoption of XPath 2.0 > > Tom Petch > > ----- Original Message ----- > From: "Randy Presuhn" > To: > Sent: Wednesday, December 17, 2008 7:15 AM > Subject: Re: [netmod] octal numbers > > >> Hi - >> Juergen pointed out the compelling factor in this area, which is whether widely and freely available software libraries exist or not. If glibc FP functions don't do the right thing, I am not writing my own, so that better be good enough. Nobody is going to write custom FP code for YANG. Get real (sic). Andy >>> From: "Andy Bierman" >>> To: "Martin Bjorklund" >>> Cc: ; >>> Sent: Tuesday, December 16, 2008 6:11 PM >>> Subject: Re: [netmod] octal numbers >> ... >>> I am trying to clarify the text. >>> If a smart guy like Randy can get confused by the YANG vs. XPath >>> expression number representations, then lots of people will get confused. >>> >>> http://www.w3.org/TR/xpath#numbers >>> >>> BTW, it is not just the default-stmt. >>> Numbers also show up in min-elements, max-elements, ranges, >>> and patterns. >>> >>> Inside XPath strings like the must-stmt or when-stmt argument, >>> the YANG rules do not apply, just the XPath rules. >> I admit to being rather confused here. If XPath uses IEE 754, then >> there are plenty of 64-bit integers that cannot be represented, or, >> worse still, will be treated as being equal to other 64-bit integers >> that have different bit patterns. This would seem to be a potential >> trap for the unwary. Limiting the use of integer values to only those >> values that will survive the IEEE 754 <-> integer round trip unscathed >> seems a scary prospect. >> >> Randy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 15:03:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5F03A63EB; Thu, 18 Dec 2008 15:03:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8730B3A692D for ; Thu, 18 Dec 2008 15:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 ZkTBBbrfb0I3 for ; Thu, 18 Dec 2008 15:03:17 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id C60A33A63EB for ; Thu, 18 Dec 2008 15:03:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=m3l4alEokWxGQnPMCzQgGSO02yblC9sNLu8PtoixH8C+6Z0u4WVeNXf6WVZuQ7rg; 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 [68.164.80.20] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LDRtb-0001wE-Tr for netmod@ietf.org; Thu, 18 Dec 2008 18:03:08 -0500 Message-ID: <004001c96165$117bffa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer> <003f01c96151$dcac62a0$0601a8c0@allison> <494ACCF0.9030309@netconfcentral.com> Date: Thu, 18 Dec 2008 15:05:05 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4daddcfb6b1631567d0c8e3665baf68a5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.20 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "tom.petch" > Cc: "Randy Presuhn" ; > Sent: Thursday, December 18, 2008 2:21 PM > Subject: Re: [netmod] octal numbers ... > Juergen pointed out the compelling factor in this area, > which is whether widely and freely available software > libraries exist or not. If glibc FP functions don't > do the right thing, I am not writing my own, > so that better be good enough. Nobody is going to > write custom FP code for YANG. Get real (sic). ... I heartily agree that requiring custom floating point code is a non-starter. The problem is that requiring comparisons to be done in floating point may not give the results that most humans would expect. Your epsilon may vary. :-) Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Dec 18 17:30:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B096F3A687A; Thu, 18 Dec 2008 17:30:22 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6833A687B for ; Thu, 18 Dec 2008 17:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.095, 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 JNg1bzCPF0g2 for ; Thu, 18 Dec 2008 17:30:21 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 26CE83A687A for ; Thu, 18 Dec 2008 17:30:21 -0800 (PST) Received: (qmail 15345 invoked from network); 19 Dec 2008 01:30:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 19 Dec 2008 01:30:11 -0000 X-YMail-OSG: sHqyTZwVM1kpoqDkcfk4GhsAr3BTM3KQK9WJzVCUIrIyN5_npQCpGDirZrLF2zfEsGEyEwxrfdj.ci9cBxWm8kzhYArBKFHTw3zfthLY9hGRbnx3mVvv4JpiBvtzrXF8rhNekzCvFq.3tz7gBRswNk0H X-Yahoo-Newman-Property: ymail-3 Message-ID: <494AF921.9010203@netconfcentral.com> Date: Thu, 18 Dec 2008 17:30:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] another XPath tip X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I just found another difference between YANG and XPath syntax by studying the EBNF. XPath expressions do not have negative numbers, only the unary operator '-' (see rule [30]). For example: child::para[position()=last()-1] Make sure you don't parse a '-1' instead of the correct '-' '1'. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 00:55:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CAF3A69D3; Fri, 19 Dec 2008 00:55:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86403A69E7 for ; Fri, 19 Dec 2008 00:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 sYCY7XnmYvsM for ; Fri, 19 Dec 2008 00:55:21 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 54E463A69D3 for ; Fri, 19 Dec 2008 00:55:21 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4FCD221198; Fri, 19 Dec 2008 09:55:12 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-00-494b61703e2f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3265A20FB3; Fri, 19 Dec 2008 09:55:12 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 09:55:11 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 09:55:11 +0100 Message-ID: <494B616F.30006@ericsson.com> Date: Fri, 19 Dec 2008 09:55:11 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <49492989.3060002@netconfcentral.com> <20081217.225411.59447952.mbj@tail-f.com> <49497742.3040205@netconfcentral.com> <20081217.231735.193026122.mbj@tail-f.com> <494A5F13.9030304@netconfcentral.com> <494A855D.2000709@ericsson.com> <494A884A.9090505@netconfcentral.com> In-Reply-To: <494A884A.9090505@netconfcentral.com> X-OriginalArrivalTime: 19 Dec 2008 08:55:11.0727 (UTC) FILETIME=[805D2FF0:01C961B7] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> Reading the thread some comments: >> >> 1) I hope that the order of evaluating the deviation statements does >> not influence the end result or the success/acceptability of deviation >> statements. However today it does. This could be a problem if the >> statements are in different modules, so the evaluation order is >> uncertain. >> >> E.g. add the subtree myInterfaces later add subtree >> myInterfaces/specialCounters >> Is this valid? >> If myInterfaces is evaluated first, it looks fine. >> If myInterfaces/specialCounters is evaluated first then it is trying >> to add something to a non-existing node .../myInterfaces, so it must >> fail. >> You could come up with a lot of other examples as well. >> > > It does not matter. > Just like augment, the targets can appear in any order, > including out of order. > > The deviation-stmt is validated wrt/ the real > object specified in the XPath target. You are right about the previous example, but there are other cases, when the order of evaluation could matter. E.g.: leaf foo { type int8; mandatory true; } deviation ../foo { deviate replace { mandatory false; } } deviation ../foo { deviate add { default 5; } } If the replace is evaluated first it is fine. If the add (default) is evaluated first, it fails. Or do you have to collect all deviation and evaluate them together? Similar conflicts can arise with type and default, type(leafref/keyref) and config(false), must and config(false). > The other > deviation statements have nothing to do with it. > The XPath target node will exist or not, regardless of > how many deviation-stmts are present. > > Also, you cannot add objects via deviation-stmt. > You can add sub-clauses to existing objects. > > >> 2) I think we should have a generic statement somewhere: "The model >> changed according to the deviation statements MUST be a valid YANG >> model." That cuts down a lot of corner cases. >> > > The new ABNF from Martin fixes that IMHO it is good to state basic ideas, like the one I proposed, clearly and not just imply them. (Writing a perfect ABNF is a tough job.) > >> 3) Why is it not allowed to delete the default statement? Please make this possible, otherwise switching mandatory to true will often not be possible. >> >> 4) If we don't advertise models that only provide typedefs and >> groupings, why do we need to advertise pure deviation modules? >> (Actually I can live with advertising them.) >> > > You should advertise all the modules, especially when > import-by-revision is added. > Earlier IMHO the consensus was that if you only use typedefs from an imported module you should not advertise it. Do we have a way of differentiating between: - I only use types from module bar - I use types from module bar, but I also implement it's data nodes Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 05:53:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38E73A6842; Fri, 19 Dec 2008 05:53:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250603A68F3 for ; Fri, 19 Dec 2008 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 iHwvm3rjWIAk for ; Fri, 19 Dec 2008 05:53:03 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BA78D3A6842 for ; Fri, 19 Dec 2008 05:53:02 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E85C82180E for ; Fri, 19 Dec 2008 14:52:53 +0100 (CET) X-AuditID: c1b4fb3c-ad75dbb00000304c-29-494ba735fc7f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ABEA720979 for ; Fri, 19 Dec 2008 14:52:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 14:52:53 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 14:52:53 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 19 Dec 2008 14:52:52 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812191452.52768.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Dec 2008 13:52:53.0072 (UTC) FILETIME=[168E2500:01C961E1] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Preliminary IETF73 meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I realize these are late (and they have to be submitted today ...) but here = are the minutes. I will give the list a few hours to look through them = before submitting them to the Secretariat. Cheers, David ---------------------------------------------------------------------------= ------------------------------------ NETMOD WG = IETF 73, Minneapolis MN WG Chairs: = David Partain (david.partain@ericsson.com) David Harrington (ietfdbh@comcast.net) = THURSDAY, Nov 20, 2008 1520-1720 MP3 recording at ftp://videolab.uoregon.edu/pub/videolab/media/ietf73 = file:ietf73-ch5-thurs-noon2.mp3 Jabber: http://jabber.ietf.org/logs/netmod/2008-11-20.txt Session goal: Conformation of consensus reached at interim meeting and on ML. 0. WG status review (15 minutes) (David Partain) - "Darn good shape" - YANG draft published - Common data types moving along - DSDL and architecture drafts needed - Dan Romascanu * isn't concerned about the architecture * is concerned about the DSDL document being late. Charter included DSDL, that is part of the work. DSDL should be approved together with YANG document, not delayed. - David Partain: Not too worried, DSDL must wait for YANG itself anyway. 1. NETMOD Architecture (Phil Shafer (15 min)) http://tools.ietf.org/html/draft-shafer-netmod-arch-00 = - Consensus to become WG doc at interim, but waiting to become official - Feedback needed - Poll: 3/4 of room have read it - 10 people believe it should be the starting point of the architecture for the WG and 1 person opposed. - Mehmet Ersue: would be happy for it to become the WG architecture, but wants to wait for the next version to fix problems. - David Partain response: the WG document versions can address issues. David Harrington: We only are deciding if this is suitable as a starting point. - Mehmet Ersue: it should be more formal (less John Wayne comments) - David Harrington: Too many informal comment (e.g., John Wayne). Make it more formal/official. (For the record, no one asked Phil to remove the John Wayne comment.) - Significant list of comments have not been addressed yet. - Consensus to accept as WG draft, with required changes. Phil will publish as NETMOD draft ASAP. 2. Common YANG Data Types = M. Bj=F6rklund (5 min) = http://tools.ietf.org/html/draft-ietf-netmod-yang-types-01 slides: http://www.ietf.org/proceedings/08nov/slides/netmod-4.pdf - Summary of changes since last shown * Fixed a missing backslash escape * Identified the type definitions needed of a normalization discussion * Generated XSD and RNG using a newer version of pyang * Editorial changes - No discussion 3. YANG - A data modelling language for NETCONF = M. Bj=F6rklund (40 min) http://tools.ietf.org/html/draft-ietf-netmod-yang-02 This presentation will include YIN and XML deliverables (40 min) slides: http://www.ietf.org/proceedings/08nov/slides/netmod-3.pdf - Discussion of changes to document since last version. - Status * draft -02 available * interim was in October - Canonical form of data-types * issues with 42 and +42 needing to be comparatively equal * especially important for indexes - don't want to create two list entries for 42 and +42 * Wes Hardaker: what is sent back: the straight copy or the canonical form? - the canonical form can be sent back * Must the canonical form be sent back for a get-config? - there is consensus that it's likely this was consensus - David Harrington. Discussion was about the many different representation of IPV6 addresses. Looking up the interim it seems that we did have consensus. - J=FCrgen Sch=F6nw=E4lder: Is pretty sure interim consensus was devices must return canonical (as are David Partain, Bal=E1zs Lengyel). - Consensus in this meeting to return the canonical form to allow comparisons. * Bernd Linowski: Is this a complete solution? - Martin Bj=F6rklund: Yes it is used in keys, and all other comparisons. - Bernd Linowski: What is the problem we are solving? - Martin Bj=F6rklund: Is the key "42" and "+42" the same? We need a device independent answer. - Refine, when and augment * newer augment, refine, when syntax and structures * Refinement, when, and augment: consensus to accept - Features * supported features are advertised in hello capabilities * Bal=E1zs Lengyel: if-capability seems to be needed - Martin Bj=F6rklund: agreed it might be needed - No proposal at this time to bring about such a if-capability feature - David Harrington: would features be separated by commas, or? - Answer: commas - Andy Bierman: Are features exported to other modules? (no answer recorded.) - Consensus to accept this feature - Deviations * All devices cannot necessarily support everything * A deviation statement has been added. * EGs shown: not supported, or maximum supported is 3 * Device deviations are shown in capabilities * Wes Hardaker: SNMP/SMI-v2's hated offline reference is being done again? - Answer: at least it can be done online via monitoring (Using the NETCONF monitoring model / schema discovery method) - Martin Bj=F6rklund: SMIv2 deviations were added later and that was half the problem. If we have this from the beginning it might work. - David Partain: We know deviations didn't work in SNMP, but we should try. Better than nothing. Deviations: consensus to add this to document deviations from standard. AGENT-CAPABILITIES in SNMP failed, but adding this in the beginning might work. - Identity and identityref * need to distribute reusable enumerations * identity's are define and others can be derived from it - Update rules * long discussions about what you're allowed to do when updating rules * goals and resulting rules derived from: - Protect old clients - Protect importers * Draft contains long list of specific update rules = * Two basic rules: protect old clients, import by revision. - Import by revision * not yet in the draft * will be able to specify a "revision" token to indicate the exact version to import * Bal=E1zs Lengyel:: is this mandatory or optional? Answer: optional 4. Mapping of YANG to DSDL Ladislav Lhotka (15 min) http://tools.ietf.org/html/draft-lhotka-yang-dsdl-map-01 = slides: http://www.ietf.org/proceedings/08nov/slides/netmod-0.pdf MP3: ~54 minutes into MP3 - Strong consensus: DSDL mapping should be able to generate schemas for both the full datastore and particular PDUs - Rough consensus: mapping will be divided into two steps 1. map one more YANG modules to a conceptual tree 2. From conceptual tree generate full schemas Description of how DSDL fits in the architecture (Ladislav Lhotka): (Editor: overview of this whole discussion, details below) Single full output DSDL "super-model" (combination of all of the models on a system) or individual models supplemented with XSLT to generate validation rules The "super-model" will largely be dependent on device support. Translations of individual models (CF: single YANG models) don't make much sense. Extension mechanism is very different than YANG extension mechanism and cannot keep same modularity as in YANG. The expectation was that modularity would be the same, similar to MIB modules. The consensus is to build individual module translations, if possible Ladislav Lhotka will try to do this, and discuss further in the second session. If DSDL cannot do this, then maybe we should scrap DSDL. DSDL is designed to do validation, not data modelling. Positioning: charter calls for a mapping from YANG to DSDL YANG is normative; DSDL converts to machine-friendly format One way mapping from YANG to DSDL; no DSDL-to-YANG mapping The consensus is to adopt this as a WG draft, but this will be confirmed on the mailing list. Details: - Issues: 1. DSDL is to be used as one of: a. a data modelling language b. ad-hoc DSDL schemas for specific mostly short-term purposes like PDU validation 2. DSDL mapping will be developed as one of: a. mere convenience for those who don't understand YANG b. interim validation method before native YANG tools are written c. substantial component of the NETMOD box = - Phil Shafer: Problems I see; the tree you're building is a combination of YANG modules for a box. You can't reuse it to a different box. Isn't there a way to do it in a per-YANG module way? - Answer: I don't see it as a benefit to publishing yet another language (in addition to the existing schemas). - David Partain: so you're saying you don't see the utility of a YANG module translated into DSDL by itself. - Answer: It depends on the situation - Phil Shafer: can't you create one DSDL file of the base stuff and import it into the second and combined they should be able to validate successfully? - Answer: it doesn't have that functionality [importing] - Phil Shafer: we were told this was possible in the bakeoff when we selected DSDL - Answer: you can do it, just not in the same way as you can in YANG modules. This is intended for ad-hoc combinations of schemas. - Sharon Chisholm: I think it is possible because you could do it by hand; the question is how toolable it is. - David Partain: we need to make it work because people are assuming it. - Martin Bj=F6rklund: can you take the hand crafted version of each and validate what comes from the box? I don't think it's possible. - Andy Bierman: separate modules are possible in XSD - Ladislav Lhotka: we are not building a DSDL data modelling language so we need to cope with the language restrictions. - Phil Shafer: so you disagree it's possible in XSD? - Ladislav Lhotka: what would you do with the top level augment in XSD? - Martin Bj=F6rklund: I think it does work in XSD - Phil Shafer: so if we assume it's possible XSD you're still not sure if it's possible in RelaxNG? - Ladislav Lhotka: It's explained in the draft why this was chosen - Sharon Chisholm: I hear consensus is that we should see if it's achievable and we should try unless we run into problems - Bernd Linowski: What does DSDL guarantee? Does it assure me that what's handled by DSDL will be accepted by the agent? - Ladislav Lhotka: Yes it should be; that's the goal. - Bernd Linowski: Is it the goal or guaranteed? - Ladislav Lhotka: The mapping is not finished so I can't promise; as far as I can tell it'll be possible - Bal=E1zs Lengyel: How can you achieve that validation? I doubt that can be done without the knowledge of the current datastore. - Ladislav Lhotka: This has to be clarified for YANG itself too. - Sharon Chisholm: Client side conformance needs to be marked in the document. There can be a first level check defining what the client must include in a request. - Ladislav Lhotka: I'd like to see [DSDL mapping] this as a long term component of YANG - Phil Shafer: I think the problem is that the mapping is a top-down system. Maybe it's possible to translate a YANG module into a fixed set of patterns into a non-standalone RelaxNG file and then in a per-device sort of schema tree make a single top-level file that imports all the piece that that particular device implements (DSDL files). Then the rules are put into the appropriate place in your schema tree. IE, do a per-YANG module translation once but building the tree as needed based on each translation. - Ladislav Lhotka: I was not going to create a bunch of DSDL files to be done to be published to be reused. You have to tell it in the schema what exists in the device. - David Partain: we have a fundamental decision we need to make. Is the target a union of all the YANG documents on the box, or create each YANG document and translate it into something that can be reused. Or some hybrid. - David Harrington: in SNMP we have MIB modules. putting them together into a DB is the job of an application. Trying to build a "super-model" is the job of an app; we should be striving to do a translation of a YANG module into a dsdl module. - Bert Wijnen: same statement. One module to one module and don't build a "super-model". If we have 5 different boxes from 5 different vendors we need to build 5 different DSDL modules. - Phil Shafer: responding to David Harrington: the validator is the application. We need to build this for it. - Bal=E1zs Lengyel: it would be nicer to have a 1-1 mapping, that's not the question. The questions is can it be done? - Bert Wijnen: if it can't be done, then lets not waste our time on it. - David Partain: reads from the charter and declares the charter says it's a mapping item not a modelling item. - Phil Shafer: this all seems to be saying we don't know enough about relaxng - David Harrington: it was the intention of this working group to create a substantial component of the NETMOD tools. DSDL is a data-modelling language actually. We're trying to convert YANG to DSDL so apps can use it internally as a model. - Ladislav Lhotka: We do modelling in YANG, after that DSDL can be used for validation and for this it is good. DSDL is not so good for modelling, we have YANG for modelling - David Harrington: so are you saying DSDL limits the choice of applications? The data modelling has to be done in YANG; then the DSDL mapping can be used to translate things. If you can use the schema then go ahead. - Sharon Chisholm: I've never understood defining this as a mapping. If you just define DSDL as a verification method then you don't need to worry about readability. - David Partain: as long as you don't put anything into the DSDL stuff that isn't in YANG, then you're fine. - Sharon Chisholm: it's a real one way mapping and a theoretically bi-directional mapping - David Partain: I think that's the criteria that should be used. If it's not in YANG, it doesn't go into the mapping work. - Technical issues * Identify parts of mapping that can be done quickly * Start WG discussion remaining parts * Pending changes to YANG will affect the results * RelaxNG syntax: XML vs compact - proposal is to use XML for specification - does not preclude compact from being used though * annotated RelaxNG vs standalone schema * Should all YANG module metadata (contact info) be copied to DSDL schemas. - Sharon Chisholm: copying multiple fields into a single core field? - Ladislav Lhotka: two options: put a reference or a straight copy - Sharon Chisholm: copying everything makes the most sense - David Partain: agree - Martin Bj=F6rklund: should be done, but tools could turn it off - Consensus for adoption of DSDL as starting WG item - How many have read the DSDL draft: 11 - How many believe it should be adopted: 8 - Anyone oppose adopting this: 1 - Abstain: 1 - We have rough consensus in the room; verify on list. Open mic (30 minutes) = - David Harrington: I'm stepping down as co-chair due to day-job requirements. David Kessens will be the new chair which keeps the dave and dave chairs consistent and first names don't break. - Dan Romascanu: Interim meetings are being heavily discussed and there is a procedure for organizing future meetings. Interim in Malta: NETMOD not interested, but didn't matter since IESG cancelling Malta meeting. Desire to improve virtual meeting support - Bal=E1zs Lengyel: There is a substantial change between -01 and -02. 'must' and 'when' can't check state data. * Martin Bj=F6rklund: this is an open issue for tomorrow - David Partain: there has been a lot of stuff on the list. But people are now saying that enough-is-enough. It's time to stop adding stuff to YANG. I think we can safely declare consensus that there won't be any more features added to YANG after this week. we will instead focus on finishing the document after today and we will fix bugs and get the document out the door. - David Harrington: that doesn't mean you should get all your new features proposed by tomorrow. - David Partain: as things go right now we want WG last call after the next IETF. Feature freeze is in effect! - David Partain: Important things that need to happen with YANG: - Fresh eyes needed outside the core team - Hopefully without doing this through last call - We'd greatly appreciate full reviews of the YANG document - David Harrington: I'm disappointed in the decision to do it after the next IETF. I'd rather see it go to last call before the next meeting. If it's stable, it should go quickly. FRIDAY, Nov 21, 2008 0900-1130 = MP3 recording at ftp://videolab.uoregon.edu/pub/videolab/media/ietf73 = file:ietf73-ch4-fri-am.mp3 Jabber: http://jabber.ietf.org/logs/netmod/2008-11-21.txt Session goal: Open Issues in NETMOD, and proposals for added functionality Open issues and questions for YANG/YIN/XML/LIB - Martin (60 min) slides: http://www.ietf.org/proceedings/08nov/slides/netmod-5.pdf 1. How do we represent canonical form? = - David Harrington: concern that all the patterns don't clarify which format is returned; prefer is just a single pattern. - Suggestion that in a standard a single form should be goal, not flexibility - The more patterns supported the more likely a mismatch between lenient/non-lenient implementations Dan Romascanu agrees. - J=FCrgen Sch=F6nw=E4lder: there are no IETF standards for canonical forms of some of these data types today - Bernd Linowski: prefers alternative 3 (see slides), since it can be more easily checked; reduces redundant definitions of the patterns. - Andy Bierman: what is the pattern for accepting mixed case DNS names when canonical is all lower-case? - Answer: both would have to be specified (J=FCrgen Sch=F6nw=E4lder: 'complicated') - Wes Hardaker: we should limit what we want to allow to what is known to work, however if we want operators to be able to edit the XML you have to allow multiple patterns. - Phil Shafer: suggest adding 'canonical =3D true' under one pattern, rather than repeating the pattern (addresses Bernd's concern above) - - this would impact previous decision that patterns are 'ANDed' - J=FCrgen Sch=F6nw=E4lder: order of prefs: 1, 3, 2 - David Partain: leaning towards 1, since the text in the description clause is clearer; concern that errors will still occur anyway. - Bernd Linowski: concern that the canonical reference won't be clear Votes: Alternative 1: 2 Alternative 2: 4 Alternative 3: 7 (general preference) Alternative 4: 1 Alternative 5: (suggestion to add 'canonical' to the pattern; but validates the 'and'ing) Action (Martin): take it to the mailing list, suggesting a syntax leaning towards 3 2. Keyref vs. leafref - Phil Shafer: there was a problem yesterday about must expressions on config data, does this address this? - No - Bal=E1zs Lengyel: Question: can you require instance true on state data? - Yes, in a grouping - Andy Bierman: when are 'must' statements in non-config data evaluated (there is no commit performed) - Bal=E1zs Lengyel: Question: can we allow constraints on state data that would make the config invalidate? - No, the state data must point to instance data in the running datastore Hum result: in favour. Conclusion: moving forward with this idea. 3. Conformance statement - Bal=E1zs Lengyel: concern that YANG is adding too many levels of optionality (already have features, when, capabilities, ...); can we just use feature instead of conformance? Martin Bj=F6rklund agrees. - Andy Bierman: feels a complete view of conformance is needed, in one place; but that a solution can wait until later. - Sharon Chisholm: doesn't see value, only complexity - J=FCrgen Sch=F6nw=E4lder: feature can handle, this can wait (if needed later) Vote: Proceed: 0 Don't proceed: All votes Conclusion: will take recommendation to the mailing list to table this for now. 4. schema discovery (YANG monitoring usage definition) - Andy Bierman: doesn't think submodule is needed since it's contained in the parent module - Do need it, to advertise where the submodules are located. - Mark Scott: suggest adding 'location' to the YANG description for completeness (and to better explain why YANG needs to explicitly define this - as the means to locate/retrieve the schema files). - It is part of the monitoring data - Phil Shafer/Andy Bierman: do we want to explicitly identify module/submodule in the schema list entries - No, a parser will have to figure out dependencies itself anyway - Andy Bierman: YANG must specify how the capabilities will be advertised Vote: In favour: 9 More work: 0 Conclusion: Accepted as is. The YANG draft must say how and what to advertise in the hello message. 5. Inline in - Wes Hardaker: prefers option 2, easier to parse top level looking for error tags - Bal=E1zs Lengyel: ensure this applies to all RPCs, not just base RPCs - Phil Shafer: option 2 (see slides) preferred, simpler to write scripts since nodes in error will be missing in top level parsing - Chris Elliot: see some benefit in both, but prefer it to be taken to mailing list - Bal=E1zs Lengyel: will this impact NETCONF or is it purely YANG matter? This likely belongs in NETCONF spec. - It will be addressed in the RFC update. Currently is not clear. - Needs to be done in YANG (clarity for YANG), NETCONF and likely other DMs Vote: Option 1: 0 Option 2: 7 (consensus) Action (Martin): take it to ML for further discussion 6. assigned-by - Andy Bierman: what if there are complex conditions that cause system to decide to create or not? - you wouldn't use this, you would specify in the description clause - Phil Shafer: you wouldn't turn this on, even if an option that it will be assigned. SO what is this for? - for a leaf with 'assigned by system' what is the client behaviour expected? Client will know that the server will assign it, and is expected to re-fetch it (to determine the value) - Bal=E1zs Lengyel: you don't have to re-fetch it, you just need to know that the system will assign it - Bal=E1zs Lengyel: this should be applied to keys as well? - A: No, otherwise it complicates knowing which key was assigned - counter: there are systems which assign keys for clients, without client knowing (suggest discuss offline) - Andy Bierman: must be filled in, or may be filled in? - A: may - David Partain: concern that this is ambiguous? Does this get filled in on reported information? - A: (none) - Sharon Chisholm: thinks this aligns to the client side conformance ('must use' clause) to allow clients to know what must be specified and what does not need to be - A: mark the leaf as mandatory to achieve this; - Andy Bierman: this problem goes away when 'with-defaults' is added to NETCONF - comments in room that it does not go away - Sharon Chisholm: there are 2 types of defaults: sparing, system-defined - Bal=E1zs Lengyel: supports the feature, but thinks it requires more discussion Vote: In favour: 6 (consensus) Not in favour: 0 Action: Take it to the mailing list, suggesting text and rules for this. 7. create-only for leafs - Sharon Chisholm: suggested different way to do this; over-ride max-access as an alternative? - Phil Shafer: Is there a concrete example of why this is needed? - doesn't seem to be one - Bal=E1zs Lengyel: Supported this be added: ATM or SDH data where the termination point cannot be changed once created? - Cases where editing resulted in an implicit delete/recreate, which you wanted to prevent - Bernd Linowski: there are cases where delete and recreate must be performed, and would like to use this to indicate those cases - Phil Shafer: thinks this cannot work - David Harrington: concerned that we are adding little features that are maybe not needed; i.e., couldn't this be added in a description clause - David Partain: table this until we get concrete examples, then consider for a 1.1 No vote. Conclusion: Exclude from 1.0. Those who want it can table for 1.1 list. 8. Actions/RPC in list - David Harrington: clarified this doesn't 'simply access control' but it 'aligns with access control YANG has in mind' - Andy Bierman: this is too complicated and can wait until 1.1 - David Partain: this should be in 1.0 - Bal=E1zs Lengyel: needed for current models - David Harrington: concern that this would impact the system, and that is hasn't been discussed sufficiently - Wes Hardaker: likes the idea, but concerned it will take a while to get it right; thinks it can be deferred to 1.1 and can be solved with hierarchical definitions today - Mehmet: useful feature and makes it possible to map to XSD, and sees no problem with it; thinks it should be added - Andy Bierman: Q: can an action change the candidate, running or startup config? A: Yes, acts like a normal RPC - Wes Hardaker: concern it impacts readability - Bal=E1zs Lengyel: thinks the YANG is more readable and takes priority over the XML readability - J=FCrgen Sch=F6nw=E4lder: this needs a new NETCONF capability, should not be part of YANG, and should be deferred - Phil Shafer: this doesn't add value, it's just another way to do RPCs; concern it is less readable, args are repeated - David Partain: does increase readability but there are orgs who work this way right now; in interest of having them adopt YANG it should be included now - Bal=E1zs Lengyel: you can most (all?) of the things with RPCS, but want we want here is hierarchical representation; don't see the other concerns - Chris Newman: looks like a mix of controller and model; why not define as DM refs in the RPCs, rather than mix the control and data - Phil Shafer: this works for trivial cases. In cases where a operation affects multiple things this doesn't work? A: why not. the operation can impact other things without being explicitly defined for each - no? - suggest top-level RPCs be used in those cases - Andy Bierman: is action allowed to be nested within containers? etc., i.e. highlighting there are questions to be answered. Vote: In favour: 4 Not in favour: 7 Conclusion: No consensus for feature, not considered for 1.0. 9. Remove some CLRs = - This needs to be taken to the mailing list. 10. typed extensions - J=FCrgen Sch=F6nw=E4lder: Not needed in 1.0 - Martin Bj=F6rklund: this is needed and not a significant item to develop - Phil Shafer: doesn't think this is needed; Q: if you don't understand the extension do you care about it being defined? - A: saves documentation associated with each extension type - Phil Shafer: argues it's the semantics more than the syntax that matters - Andy Bierman: Q: what about extensions that are containers and expect other extensions as leafs? - A: answered in another set of slides - Phil Shafer: Q: who is helped by this? those who implement the extension, or those that do not? - A: those who implement since it explicitly defines the args - Andy Bierman/J=FCrgen Sch=F6nw=E4lder: extension args as strings are OK Vote: In favour for 1.0: 5.5 Not in favour for 1.0: 4 - David Partain: concern that the second slide (and additional content) is too much (use-in, substatement, occurrence) - Mehmet Ersue: proposal is to have minimal content (first slide) in 1.0; rest can wait - Ladislav Lhotka: this should not be in YANG, but should be in the meta language Vote: In favour for 1.0: 3 Not in favour for 1.0: 7 Consensus - not in 1.0 Open issues and questions for DSDL (30 min) slides: http://www.ietf.org/proceedings/08nov/slides/netmod-2.pdf "Super-model" versus individual mapping = - Ladislav Lhotka: Modularity of YANG can be emulated. It is complex, probably 1 YANG model goes to many dsdl. It will be complicated. - Martin Bj=F6rklund: It will not be so complicated. - Sharon Chisholm: based on how we expect these to be used, the super-model/super-schema might not be used Action: Lada will discuss his thoughts on the mailing list. - Phil Shafer: text has already been added to the arch draft for validation (raised at interim) - Andy Bierman/J=FCrgen Sch=F6nw=E4lder: the agent validates, not the manager (that's implementation detail) - Phil: disagree, manager must also validate - J=FCrgen Sch=F6nw=E4lder: Q: how does DSDL help with a non-yet-present interface? - A: it doesn't. (though please clarify question) Compact versus XML syntax: XML syntax accepted - Sharon Chisholm: XML syntax is preferred, and better suited to more informative error messages Copy all meta data into DSDL schema agreed (as documented in first session notes). _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 06:59:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB8A28C0F7; Fri, 19 Dec 2008 06:59:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FD928C0F8 for ; Fri, 19 Dec 2008 06:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 fWwktUECTlOI for ; Fri, 19 Dec 2008 06:59:25 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 9DF7128C0F7 for ; Fri, 19 Dec 2008 06:59:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSUu2xJaEBcN6PR8XYpgGf7U23UG6hya0@postini.com; Fri, 19 Dec 2008 06:59:18 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 19 Dec 2008 06:56:43 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 06:56:42 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 06:56:42 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 06:56:42 -0800 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 mBJEufM96784; Fri, 19 Dec 2008 06:56:42 -0800 (PST) (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 mBJEpCUw094012; Fri, 19 Dec 2008 14:51:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812191451.mBJEpCUw094012@idle.juniper.net> To: Andy Bierman In-Reply-To: <494AF921.9010203@netconfcentral.com> Date: Fri, 19 Dec 2008 09:51:11 -0500 From: Phil Shafer X-OriginalArrivalTime: 19 Dec 2008 14:56:42.0453 (UTC) FILETIME=[010B5050:01C961EA] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] another XPath tip X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >XPath expressions do not have negative numbers, >only the unary operator '-' (see rule [30]). Viewed the other way, XPath expressions have negative numbers built by using the unary operator and a set of digits. >For example: > child::para[position()=last()-1] >Make sure you don't parse a '-1' instead of the correct '-' '1'. Normal grammar rules should handle this. The unary "-" is not a valid token after an Expr, so the "-" in "-1" should trigger rule 25 instead. The "gotcha" is probably that "-" is not a token if the next character is a path-element. So some look-ahead is required. Consider the difference between "last()-position()", "last-position()", "last()-position", and "last-position". Worse, consider "last()-1" and "last-1". Lots of fun. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 07:04:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4163E3A6968; Fri, 19 Dec 2008 07:04:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B383A6A05 for ; Fri, 19 Dec 2008 07:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bK0FSkmsxgfr for ; Fri, 19 Dec 2008 07:04:04 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id D2DE63A6911 for ; Fri, 19 Dec 2008 07:04:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSUu32b6kilbbFVNQHQAK7WPAkM7M2kuS@postini.com; Fri, 19 Dec 2008 07:03:56 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 19 Dec 2008 07:00:58 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 07:00:58 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 07:00:58 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 07:00:57 -0800 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 mBJF0uM98699; Fri, 19 Dec 2008 07:00:57 -0800 (PST) (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 mBJEtQfo094060; Fri, 19 Dec 2008 14:55:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812191455.mBJEtQfo094060@idle.juniper.net> To: Andy Bierman In-Reply-To: <494A41E5.2070309@netconfcentral.com> Date: Fri, 19 Dec 2008 09:55:26 -0500 From: Phil Shafer X-OriginalArrivalTime: 19 Dec 2008 15:00:57.0732 (UTC) FILETIME=[9933CC40:01C961EA] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I strongly object to the mandatory ?deviations=blah >change to the capability exchange defined in 4741. >I do not think YANG has the right to change it. >This should be done in 4741-bis, if at all. This is nonsense, since 4741 says capability strings are URIs and even contains an example for using the query mechanism in URIs. This is not a change to 4741. We are following both the intent and the example of the NETCONF spec. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 07:13:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031933A6A35; Fri, 19 Dec 2008 07:13:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780D33A63CB for ; Fri, 19 Dec 2008 07:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qBvhp3q8-bbB for ; Fri, 19 Dec 2008 07:13:00 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id C5B0B3A69F9 for ; Fri, 19 Dec 2008 07:12:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSUu58JuT1v2QcxfhIpEnMCD+Mw2P3jwj@postini.com; Fri, 19 Dec 2008 07:12:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 19 Dec 2008 07:09:53 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 07:09:52 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 07:09:52 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 07:09:52 -0800 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 mBJF9pM01103; Fri, 19 Dec 2008 07:09:52 -0800 (PST) (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 mBJF4LWf094126; Fri, 19 Dec 2008 15:04:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812191504.mBJF4LWf094126@idle.juniper.net> To: Andy Bierman In-Reply-To: <4949825E.3000001@netconfcentral.com> Date: Fri, 19 Dec 2008 10:04:21 -0500 From: Phil Shafer X-OriginalArrivalTime: 19 Dec 2008 15:09:52.0510 (UTC) FILETIME=[D7F471E0:01C961EB] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >A list of deviation module names (maybe the same one) >attached to potentially many capability URIs is complicated. >There is no way to get some of the capabilities but not >all of them. There seems to be no reason to optimize >for something not even supported by NETCONF anyway. >Since the message is the only opportunity >for the manager to process agent capabilities, >I suggest not ignoring some of them. IMHO these arguments against the deviation parameter don't hold water. Working backwards: - Clients are free to ignore any or all capabilities about which they do not care. This is goodness. - NETCONF supports this. - We optimize for real world scenarios, and I consider deviations a part of the real world. - A client can "get" any subset of capabilities that it care about. It can completely ignore the entire message as opaque data, if it knows it doesn't care about any of the capabilities expressed by the device (e.g. an config backup program). - Tying the deviations to the affected module allows the client to _avoid_ downloading every module in order to learn which ones affect the capability they _do_ care about. If I care about IPFIX and no deviations are reported, I know I'm golden without running down the other 150 modules the device supports. - This isn't complicated. It serves to localize the complexity, making only those who care about the deviations bear their expense. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 07:26:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7C63A63CB; Fri, 19 Dec 2008 07:26:38 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41D33A6A41 for ; Fri, 19 Dec 2008 07:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092, 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 UwZIOUvsCtKr for ; Fri, 19 Dec 2008 07:26:36 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 326193A684A for ; Fri, 19 Dec 2008 07:26:36 -0800 (PST) Received: (qmail 93977 invoked from network); 19 Dec 2008 15:26:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 19 Dec 2008 15:26:26 -0000 X-YMail-OSG: 5Ae9DPcVM1lygcwKH0Hff9nWBU3uNiL1PxgagZ8ZYQT1chjxOSjZVfIsv8gAZucp6hlaMT0W_XNeCv6iopLrMp5XvFiKWa3quyHfy8BHIrThSoxcsrw8RbhJYwGbKEijqOb8V9K_wajDjlv0cgH8yNID X-Yahoo-Newman-Property: ymail-3 Message-ID: <494BBD20.4040405@netconfcentral.com> Date: Fri, 19 Dec 2008 07:26:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812191504.mBJF4LWf094126@idle.juniper.net> In-Reply-To: <200812191504.mBJF4LWf094126@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> A list of deviation module names (maybe the same one) >> attached to potentially many capability URIs is complicated. >> There is no way to get some of the capabilities but not >> all of them. There seems to be no reason to optimize >> for something not even supported by NETCONF anyway. >> Since the message is the only opportunity >> for the manager to process agent capabilities, >> I suggest not ignoring some of them. > > IMHO these arguments against the deviation parameter don't hold > water. Working backwards: > > - Clients are free to ignore any or all capabilities about which > they do not care. This is goodness. > - NETCONF supports this. > - We optimize for real world scenarios, and I consider deviations > a part of the real world. > - A client can "get" any subset of capabilities that it care about. > It can completely ignore the entire message as opaque > data, if it knows it doesn't care about any of the capabilities > expressed by the device (e.g. an config backup program). > - Tying the deviations to the affected module allows the client > to _avoid_ downloading every module in order to learn which ones > affect the capability they _do_ care about. If I care about IPFIX > and no deviations are reported, I know I'm golden without running > down the other 150 modules the device supports. > - This isn't complicated. It serves to localize the complexity, making > only those who care about the deviations bear their expense. > I think this use case is nonsense. I seriously doubt any application developer would write code to handle just one capability URI. Since Martin is suggesting that all modules (even deviation-only) get advertised along with the 'plain' modules, the manager clearly has the code to parse a module capability URI. There is no text in 4741 about "free to ignore" the capabilities. On the contrary, all the text related to capabilities suggests that an application which ignores them will not work too well. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 07:48:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8F828C129; Fri, 19 Dec 2008 07:48:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64E928C129 for ; Fri, 19 Dec 2008 07:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.089, 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 JvtnSXuC1CD1 for ; Fri, 19 Dec 2008 07:48:21 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 5A6CC28C0F7 for ; Fri, 19 Dec 2008 07:48:20 -0800 (PST) Received: (qmail 13285 invoked from network); 19 Dec 2008 15:48:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.154 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 19 Dec 2008 15:48:11 -0000 X-YMail-OSG: 0mvZ2LoVM1kskqPcnUnObXoERTN_fvlwY0XJDPnEMAjPuTShgCm9gU5j1Buge5FQNSuFAjUhpeEmlmOXNhVDUP0rM.6_hbB8tQ_HjY4cj6MpTMjx.xUgFmJDMNFMf8LuBHhEFFi7RGDnKN.p_xdYrosF X-Yahoo-Newman-Property: ymail-3 Message-ID: <494BC239.3000601@netconfcentral.com> Date: Fri, 19 Dec 2008 07:48:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812191451.mBJEpCUw094012@idle.juniper.net> In-Reply-To: <200812191451.mBJEpCUw094012@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] another XPath tip X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> XPath expressions do not have negative numbers, >> only the unary operator '-' (see rule [30]). > > Viewed the other way, XPath expressions have negative numbers > built by using the unary operator and a set of digits. > Why doesn't YANG do it this way? Does it matter? >> For example: >> child::para[position()=last()-1] >> Make sure you don't parse a '-1' instead of the correct '-' '1'. > > Normal grammar rules should handle this. The unary "-" is not a > valid token after an Expr, so the "-" in "-1" should trigger rule > 25 instead. > > The "gotcha" is probably that "-" is not a token if the next character > is a path-element. So some look-ahead is required. Consider the > difference between "last()-position()", "last-position()", > "last()-position", and "last-position". Worse, consider "last()-1" > and "last-1". Lots of fun. sometimes 2-token lookahead is required. very fun. (follow the EBNF and the precedence falls out for free) > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 08:00:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8C63A6875; Fri, 19 Dec 2008 08:00:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B313A6875 for ; Fri, 19 Dec 2008 08:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 tDJn0xtjqce0 for ; Fri, 19 Dec 2008 07:59:59 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id A8A3328B23E for ; Fri, 19 Dec 2008 07:59:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSUvE8mdZUVKsjZXreM5N0Ay1iX/5ZNcz@postini.com; Fri, 19 Dec 2008 07:59:52 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Fri, 19 Dec 2008 07:56:01 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 07:56:01 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 07:56:00 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 07:56:00 -0800 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 mBJFtxM14914; Fri, 19 Dec 2008 07:55:59 -0800 (PST) (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 mBJFoTkF094367; Fri, 19 Dec 2008 15:50:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812191550.mBJFoTkF094367@idle.juniper.net> To: Andy Bierman In-Reply-To: <494BBD20.4040405@netconfcentral.com> Date: Fri, 19 Dec 2008 10:50:28 -0500 From: Phil Shafer X-OriginalArrivalTime: 19 Dec 2008 15:56:00.0227 (UTC) FILETIME=[49A48B30:01C961F2] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I seriously doubt any application developer >would write code to handle just one capability URI. An IPFIX config app that uses only the standard IPFIX module is free to ignore non-IPFIX modules. >There is no text in 4741 about "free to ignore" >the capabilities. On the contrary, all the text >related to capabilities suggests that an application >which ignores them will not work too well. There is no text in 4741 mandating what a client need do with the contents of the hello message, beyond some error handling with the session-id element. You are free to ignore the capabilities completely. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 08:49:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8993A6A4D; Fri, 19 Dec 2008 08:49:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE403A6A55 for ; Fri, 19 Dec 2008 08:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.087, 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 rlmKUcYncJUU for ; Fri, 19 Dec 2008 08:49:14 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 35EC73A6A4D for ; Fri, 19 Dec 2008 08:49:13 -0800 (PST) Received: (qmail 24855 invoked from network); 19 Dec 2008 16:49:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 19 Dec 2008 16:49:03 -0000 X-YMail-OSG: EWjJ8wkVM1keBIN7eehXIkA7xLaQ3zA6AjolxdjdcA7.AnhmAeqyVfjjbcCn2sLW8YvlwZmbi3nIDiZEg4QdoPq.q2KOS177MzoOdKaSyCctQm46afMNiWnCjAx.RhfxbVgzjU6CyK5_vHGCvWrAebaz X-Yahoo-Newman-Property: ymail-3 Message-ID: <494BD07E.4030207@netconfcentral.com> Date: Fri, 19 Dec 2008 08:49:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812191550.mBJFoTkF094367@idle.juniper.net> In-Reply-To: <200812191550.mBJFoTkF094367@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] deviation-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I seriously doubt any application developer >> would write code to handle just one capability URI. > > An IPFIX config app that uses only the standard IPFIX > module is free to ignore non-IPFIX modules. > >> There is no text in 4741 about "free to ignore" >> the capabilities. On the contrary, all the text >> related to capabilities suggests that an application >> which ignores them will not work too well. > > There is no text in 4741 mandating what a client need do with the > contents of the hello message, beyond some error handling with the > session-id element. You are free to ignore the capabilities > completely. > OK -- this is too minor a feature (or cruft depending on POV). Only 3 people care about it, and 2 of them think ignoring the agent capabilities is a good idea. (except :candidate, :writable-running, and :startup I hope; good luck ignoring those capabilities). > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Dec 19 13:12:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8F128C0E8; Fri, 19 Dec 2008 13:12:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E7828C103 for ; Fri, 19 Dec 2008 13:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 H4IlUJ+CqsOz for ; Fri, 19 Dec 2008 13:12:28 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C0E2F28C0E8 for ; Fri, 19 Dec 2008 13:12:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B27482158A for ; Fri, 19 Dec 2008 22:12:19 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-cb-494c0e33fa5b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 98E1721388 for ; Fri, 19 Dec 2008 22:12:19 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 22:12:19 +0100 Received: from [153.88.52.38] ([153.88.52.38]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 22:12:14 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 19 Dec 2008 22:12:14 +0100 User-Agent: KMail/1.9.10 References: <200812191452.52768.david.partain@ericsson.com> In-Reply-To: <200812191452.52768.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812192212.14874.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Dec 2008 21:12:19.0299 (UTC) FILETIME=[7A0D1B30:01C9621E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Preliminary IETF73 meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Friday 19 December 2008 14.52.52 David Partain wrote: > Hi, > > I realize these are late (and they have to be submitted today ...) but here > are the minutes. I will give the list a few hours to look through them > before submitting them to the Secretariat. Hi, I've now submitted these. Thanks to all of the notetakers! Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 20 04:32:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5D93A68B7; Sat, 20 Dec 2008 04:32:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DE43A6986 for ; Sat, 20 Dec 2008 04:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 QftYf+jOXkmd for ; Sat, 20 Dec 2008 04:32:17 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA7B3A68B7 for ; Sat, 20 Dec 2008 04:32:17 -0800 (PST) X-Trace: 118623047/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.245/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.245 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAAd1TEk+vGT1/2dsb2JhbACDQ4lyrl5YkHEGgn4 X-IronPort-AV: E=Sophos;i="4.36,254,1228089600"; d="scan'208";a="118623047" X-IP-Direction: IN Received: from 1cust245.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.245]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Dec 2008 12:32:07 +0000 Message-ID: <006e01c96296$9db0dcc0$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> Date: Sat, 20 Dec 2008 12:04:54 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ---- Original Message ----- From: "Randy Presuhn" To: Sent: Friday, December 19, 2008 12:05 AM Subject: Re: [netmod] octal numbers > > From: "Andy Bierman" > > To: "tom.petch" > > Cc: "Randy Presuhn" ; > > Sent: Thursday, December 18, 2008 2:21 PM > > Subject: Re: [netmod] octal numbers > ... > > Juergen pointed out the compelling factor in this area, > > which is whether widely and freely available software > > libraries exist or not. If glibc FP functions don't > > do the right thing, I am not writing my own, > > so that better be good enough. Nobody is going to > > write custom FP code for YANG. Get real (sic). > ... > > I heartily agree that requiring custom floating point code is > a non-starter. The problem is that requiring comparisons > to be done in floating point may not give the results that > most humans would expect. Your epsilon may vary. :-) > > Randy > And I would at least like to understand what IEEE 754-1885 has to say about the conversion, to understand what comparisons may produce, especially since we may be losing precision in the decimal to FP conversion. There may be no need to write code but I think that the lack of ready availability of this document is an issue. Perhaps we should make glibc a normative reference:-) Tom Petch _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 20 11:00:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2543A677D; Sat, 20 Dec 2008 11:00:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7A03A684C for ; Sat, 20 Dec 2008 11:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uTq03Ja1mGxQ for ; Sat, 20 Dec 2008 11:00:14 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id A0EAD3A677D for ; Sat, 20 Dec 2008 11:00:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bB8sX4NfDS1dCE12y57pSdj2bNX/7ootUhfJfbiBHPSzxetlqrMfMZMeh6Cqmw5M; 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 [68.165.5.199] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LE73W-0002BG-Av for netmod@ietf.org; Sat, 20 Dec 2008 14:00:06 -0500 Message-ID: <001c01c962d5$74a81b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> <006e01c96296$9db0dcc0$0601a8c0@allison> Date: Sat, 20 Dec 2008 11:02:07 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e483ca352ae77543da68c243d02d9ebc34350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.199 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "tom.petch" > To: "Randy Presuhn" ; > Sent: Saturday, December 20, 2008 3:04 AM > Subject: Re: [netmod] octal numbers ... > And I would at least like to understand what IEEE 754-1885 has to say about the > conversion, to understand what comparisons may produce, especially since we may > be losing precision in the decimal to FP conversion. There may be no need to > write code but I think that the lack of ready availability of this document is > an issue. ... http://en.wikipedia.org/wiki/IEEE_754-1985 provides the important information. It's fairly easy to describe some cases where information will *inherently* be lost be the conversion, simply due to the limitations of the format, regardless of the specific algorithm used to perform the conversion. For example, for positive integers, whenever there are more than 50 bits between the highest- and lowest-order "1" bits, information will be lost in the conversion to floating point. So, in that universe, 2**52 == (2**52) + 1; 2**53 == (2**53) + 1 == (2**53) + 2 == (2**53) + 3; 2**54 == (2**54) + 1 == (2**54) + 2 == (2**54) + 3 == (2**54) + 4 == (2**54) + 5 == (2**54) + 6 == (2**54) + 7; You see where this leads. Of course, if you don't need to compare large numbers precisely or manipulate thresholds for 64-bit counters using this format, it'll be a non-issue. Describing *all* the cases where information is lost is a bit trickier, since that requires thinking about the specifics of the conversion algorithm and whether normalization is enforced. If you go beyond just talking about integer conversions, and look at the general problem of decimal conversions / comparisons, then life gets really interesting. Recall that some useful numbers like decimal 0.1 cannot be represented *exactly* in this format. Your epsilon may vary. :-) Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 20 11:42:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1275D3A677D; Sat, 20 Dec 2008 11:42:17 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB873A6909 for ; Sat, 20 Dec 2008 11:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, GB_I_LETTER=-2, 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 B2prcLXXhKoc for ; Sat, 20 Dec 2008 11:42:11 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 24C853A677D for ; Sat, 20 Dec 2008 11:42:11 -0800 (PST) Received: (qmail 59711 invoked from network); 20 Dec 2008 19:42:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 20 Dec 2008 19:42:01 -0000 X-YMail-OSG: yNJJVg0VM1lzog5frXkgy.jc1pbhI6DP06DaBG3agERjJ6HzRK6zRLhwsT16G6A86.OKO8uLqqGIUe5_irJSgq4SgTWBRqEwTrAJ9OPYYSdA7v.Mi9l7qMZgAWjGVl2b84WBvFi2xR1p0IlPToxkplP7o1l5XQOuisrHmDWKPwWRb2gdtgcnrvkf X-Yahoo-Newman-Property: ymail-3 Message-ID: <494D4A88.30601@netconfcentral.com> Date: Sat, 20 Dec 2008 11:42:00 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Randy Presuhn References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> <006e01c96296$9db0dcc0$0601a8c0@allison> <001c01c962d5$74a81b60$6801a8c0@oemcomputer> In-Reply-To: <001c01c962d5$74a81b60$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "tom.petch" >> To: "Randy Presuhn" ; >> Sent: Saturday, December 20, 2008 3:04 AM >> Subject: Re: [netmod] octal numbers > ... >> And I would at least like to understand what IEEE 754-1885 has to say about the >> conversion, to understand what comparisons may produce, especially since we may >> be losing precision in the decimal to FP conversion. There may be no need to >> write code but I think that the lack of ready availability of this document is >> an issue. > ... > > http://en.wikipedia.org/wiki/IEEE_754-1985 provides the important information. > It's fairly easy to describe some cases where information will *inherently* be > lost be the conversion, simply due to the limitations of the format, regardless > of the specific algorithm used to perform the conversion. For example, for > positive integers, whenever there are more than 50 bits between the highest- > and lowest-order "1" bits, information will be lost in the conversion to floating point. > > So, in that universe, > 2**52 == (2**52) + 1; > 2**53 == (2**53) + 1 == (2**53) + 2 == (2**53) + 3; > 2**54 == (2**54) + 1 == (2**54) + 2 == (2**54) + 3 == (2**54) + 4 > == (2**54) + 5 == (2**54) + 6 == (2**54) + 7; > > You see where this leads. Of course, if you don't need to compare large > numbers precisely or manipulate thresholds for 64-bit counters using > this format, it'll be a non-issue. > > Describing *all* the cases where information is lost is a bit trickier, since that > requires thinking about the specifics of the conversion algorithm and whether > normalization is enforced. If you go beyond just talking about integer conversions, > and look at the general problem of decimal conversions / comparisons, then > life gets really interesting. Recall that some useful numbers like decimal > 0.1 cannot be represented *exactly* in this format. Your epsilon may vary. :-) > This is where the Product Manager would send all the engineers off for psychiatric testing. ;-) We're building a CM system. In all my years of MIB Doctoring, I have never even gotten 1 request for a floating point MIB object. I heard of one in the IETF once, to represent probabilities from 0 to 1. I do not think vendors will go out of their way to follow XPath 1.0 to the letter, just for YANG. I can envision some router vendors who think their embedded systems do not have enough code room to add a lot of FP library support -- for must/when XPath evaluation that rarely gets used at all, let alone used with numbers like 2**52, or 1.003501, or real floating point math like (7.0303 * (1 div 9)). If we want to make it really difficult for vendors to adopt NETCONF and NETMOD then we should make a big deal out of this. We could just say "follow XPath 1.0" and no more. I would not want vendors to think: "We cannot possibly conform to IEEE 754, so we cannot conform to NETMOD/NETCONF. Since the main reason we are doing this work is to be standards-based, there is no point in choosing NETMOD/NETCONF. Let's go a different direction with XML." > Randy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 20 12:18:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A9C3A677D; Sat, 20 Dec 2008 12:18:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3DB3A6866 for ; Sat, 20 Dec 2008 12:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, GB_I_LETTER=-2] 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 MzsW9WTyAATr for ; Sat, 20 Dec 2008 12:18:30 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D9F4E3A677D for ; Sat, 20 Dec 2008 12:18:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FTR+IwhZQO0UMS+wvzxr/FcxwqTSBvW2bTVCUFjGbG05lKr8d4t45/alHz27+qbf; 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 [68.165.5.199] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LE8HF-00079z-Bj for netmod@ietf.org; Sat, 20 Dec 2008 15:18:21 -0500 Message-ID: <000401c962e0$62ec00c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> <006e01c96296$9db0dcc0$0601a8c0@allison> <001c01c962d5$74a81b60$6801a8c0@oemcomputer> <494D4A88.30601@netconfcentral.com> Date: Sat, 20 Dec 2008 12:20:18 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e407cce866ca068f23689fa089eed3ee78350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.199 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Saturday, December 20, 2008 11:42 AM > Subject: Re: [netmod] octal numbers ... > This is where the Product Manager would send all the engineers > off for psychiatric testing. ;-) We're building a CM system. > In all my years of MIB Doctoring, I have never even gotten > 1 request for a floating point MIB object. I heard of one in > the IETF once, to represent probabilities from 0 to 1. Yup. Though there *are* cases where floating (or, more likely, fixed) point numbers might be useful, to treat them as the basis for comparison and other operations on things that are really integers does not make sense. Like it or not, computers operate in the world of discrete mathemetics, and floats are just a (very very useful and valuable) hack, not some magical way of connecting to the world of continuous mathematics. > I do not think vendors will go out of their way to > follow XPath 1.0 to the letter, just for YANG. Yup. A sanity check may be in order. > I can envision some router vendors who think their embedded > systems do not have enough code room to add a lot of FP library > support -- for must/when XPath evaluation that rarely gets > used at all, let alone used with numbers like 2**52, or 1.003501, > or real floating point math like (7.0303 * (1 div 9)). 2**52 isn't so far-fetched if someone needs to be able to specify thresholds on zero-based 64-bit counters. But I don't know how big an "if" that would be in the netconf/netmod world. > If we want to make it really difficult for vendors to > adopt NETCONF and NETMOD then we should make a big deal > out of this. We could just say "follow XPath 1.0" > and no more. I would not want vendors to think: > "We cannot possibly conform to IEEE 754, so we cannot > conform to NETMOD/NETCONF. Since the main reason > we are doing this work is to be standards-based, > there is no point in choosing NETMOD/NETCONF. Let's > go a different direction with XML." I agree this may be a teapot tempest. There are several possibilities to consider: - the cases where IEEE 754 comparisons will produce "surprising" answers don't matter because these sorts of values will never be used in models or data stores in places where XPath comparison with those values will happen - though the answers might be "surprising" to the naive, they're really not a problem - users of netmod applications *do* understand the implications of IEEE 754, and will design their models and XPath expressions accordingly - implementations don't really follow IEEE 754 rules when doing comparisons of things that are known to really be integers I'm sure there are others, but someone needs to sort this out, to avoid allowing it to turn into FUD. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 20 12:49:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3F63A6814; Sat, 20 Dec 2008 12:49:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224913A684C for ; Sat, 20 Dec 2008 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, GB_I_LETTER=-2, 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 Q3qIwTXr40q1 for ; Sat, 20 Dec 2008 12:49:10 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 921E53A6814 for ; Sat, 20 Dec 2008 12:49:10 -0800 (PST) Received: (qmail 82792 invoked from network); 20 Dec 2008 20:49:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Dec 2008 20:49:01 -0000 X-YMail-OSG: nUqBq0MVM1lhNJQEUCDpekW3_uud_Rmwzo_lBdMKQ.6PhIzKOxthK_WwUXbyJIgP1ZfmRcjmbJWbwiiAK7keyZakaGQchnBMzrD2ErvvuKSRQ3aHJeTrrejRrksIHDCB9xhprMG24KcY_q9DwEOJVuoytsKnGZcgg9RSFagDom08vv1KswiQWOms X-Yahoo-Newman-Property: ymail-3 Message-ID: <494D5A3B.5000004@netconfcentral.com> Date: Sat, 20 Dec 2008 12:48:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Randy Presuhn References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> <006e01c96296$9db0dcc0$0601a8c0@allison> <001c01c962d5$74a81b60$6801a8c0@oemcomputer> <494D4A88.30601@netconfcentral.com> <000401c962e0$62ec00c0$6801a8c0@oemcomputer> In-Reply-To: <000401c962e0$62ec00c0$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: >> Sent: Saturday, December 20, 2008 11:42 AM >> Subject: Re: [netmod] octal numbers > ... >> This is where the Product Manager would send all the engineers >> off for psychiatric testing. ;-) We're building a CM system. >> In all my years of MIB Doctoring, I have never even gotten >> 1 request for a floating point MIB object. I heard of one in >> the IETF once, to represent probabilities from 0 to 1. > > Yup. Though there *are* cases where floating (or, more likely, > fixed) point numbers might be useful, to treat them as the > basis for comparison and other operations on things that > are really integers does not make sense. Like it or not, > computers operate in the world of discrete mathemetics, > and floats are just a (very very useful and valuable) hack, > not some magical way of connecting to the world of > continuous mathematics. > >> I do not think vendors will go out of their way to >> follow XPath 1.0 to the letter, just for YANG. > > Yup. A sanity check may be in order. > >> I can envision some router vendors who think their embedded >> systems do not have enough code room to add a lot of FP library >> support -- for must/when XPath evaluation that rarely gets >> used at all, let alone used with numbers like 2**52, or 1.003501, >> or real floating point math like (7.0303 * (1 div 9)). > > 2**52 isn't so far-fetched if someone needs to be able to > specify thresholds on zero-based 64-bit counters. But > I don't know how big an "if" that would be in the netconf/netmod world. > >> If we want to make it really difficult for vendors to >> adopt NETCONF and NETMOD then we should make a big deal >> out of this. We could just say "follow XPath 1.0" >> and no more. I would not want vendors to think: >> "We cannot possibly conform to IEEE 754, so we cannot >> conform to NETMOD/NETCONF. Since the main reason >> we are doing this work is to be standards-based, >> there is no point in choosing NETMOD/NETCONF. Let's >> go a different direction with XML." > > I agree this may be a teapot tempest. > There are several possibilities to consider: > > - the cases where IEEE 754 comparisons will produce > "surprising" answers don't matter because these sorts > of values will never be used in models or data stores > in places where XPath comparison with those values > will happen > > - though the answers might be "surprising" to the naive, > they're really not a problem > > - users of netmod applications *do* understand the implications > of IEEE 754, and will design their models and XPath > expressions accordingly > > - implementations don't really follow IEEE 754 rules when doing > comparisons of things that are known to really be integers > > I'm sure there are others, but someone needs to sort this out, to > avoid allowing it to turn into FUD. > Experience shows that the IESG would be obliged to assist us, if we wanted to make a big deal out of this. > Randy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 20 15:37:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2213A6407; Sat, 20 Dec 2008 15:37:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1DD3A677D for ; Sat, 20 Dec 2008 15:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, GB_I_LETTER=-2, 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 g5t-mfaA7dYZ for ; Sat, 20 Dec 2008 15:36:59 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 7BBAE3A6407 for ; Sat, 20 Dec 2008 15:36:59 -0800 (PST) Received: (qmail 48118 invoked from network); 20 Dec 2008 23:36:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 20 Dec 2008 23:36:49 -0000 X-YMail-OSG: bbkzA4IVM1mKaDd0kpycqCwB9uvspnGBFjHd4MloBTOoQ2NSSl18y6caLRraSy3NMyrkd_5_wnMwIj7gr3HPaMucvQ4BENzb2Zl1jscdlS1lLcrqi4uWUIzJeCLI9BMRqQz7fRRkpsY5botBoaYgBsQ5zlCLamcH3ieVZPtwhgMYep5Kx0kdCdoU X-Yahoo-Newman-Property: ymail-3 Message-ID: <494D818F.8040908@netconfcentral.com> Date: Sat, 20 Dec 2008 15:36:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Randy Presuhn References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> <006e01c96296$9db0dcc0$0601a8c0@allison> <001c01c962d5$74a81b60$6801a8c0@oemcomputer> <494D4A88.30601@netconfcentral.com> <000401c962e0$62ec00c0$6801a8c0@oemcomputer> In-Reply-To: <000401c962e0$62ec00c0$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: [netmod] floating point in agents (was Re: octal numbers) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: >> Sent: Saturday, December 20, 2008 11:42 AM >> Subject: Re: [netmod] octal numbers > ... >> This is where the Product Manager would send all the engineers >> off for psychiatric testing. ;-) We're building a CM system. >> In all my years of MIB Doctoring, I have never even gotten >> 1 request for a floating point MIB object. I heard of one in >> the IETF once, to represent probabilities from 0 to 1. > > Yup. Though there *are* cases where floating (or, more likely, > fixed) point numbers might be useful, to treat them as the > basis for comparison and other operations on things that > are really integers does not make sense. Like it or not, > computers operate in the world of discrete mathemetics, > and floats are just a (very very useful and valuable) hack, > not some magical way of connecting to the world of > continuous mathematics. > >> I do not think vendors will go out of their way to >> follow XPath 1.0 to the letter, just for YANG. > > Yup. A sanity check may be in order. > >> I can envision some router vendors who think their embedded >> systems do not have enough code room to add a lot of FP library >> support -- for must/when XPath evaluation that rarely gets >> used at all, let alone used with numbers like 2**52, or 1.003501, >> or real floating point math like (7.0303 * (1 div 9)). > > 2**52 isn't so far-fetched if someone needs to be able to > specify thresholds on zero-based 64-bit counters. But > I don't know how big an "if" that would be in the netconf/netmod world. > >> If we want to make it really difficult for vendors to >> adopt NETCONF and NETMOD then we should make a big deal >> out of this. We could just say "follow XPath 1.0" >> and no more. I would not want vendors to think: >> "We cannot possibly conform to IEEE 754, so we cannot >> conform to NETMOD/NETCONF. Since the main reason >> we are doing this work is to be standards-based, >> there is no point in choosing NETMOD/NETCONF. Let's >> go a different direction with XML." > > I agree this may be a teapot tempest. It needs some attention. XPath 1.0 clearly requires floating point math support. If NETCONF agents which support :xpath capability actually do the FP math, then NETMOD has no issue. I wonder if that is the case. The YANG draft claims that an agent vendor could choose to implement a must or when expression with some 'hard-wired' internal code which emulates XPath in every way. I suppose the draft already covers this problem with that text. Given that this feature will rarely get used, it is even reasonable. (Can we choose as many answers as we want from the menu below? :-) > There are several possibilities to consider: > > - the cases where IEEE 754 comparisons will produce > "surprising" answers don't matter because these sorts > of values will never be used in models or data stores > in places where XPath comparison with those values > will happen > > - though the answers might be "surprising" to the naive, > they're really not a problem > > - users of netmod applications *do* understand the implications > of IEEE 754, and will design their models and XPath > expressions accordingly > > - implementations don't really follow IEEE 754 rules when doing > comparisons of things that are known to really be integers > > I'm sure there are others, but someone needs to sort this out, to > avoid allowing it to turn into FUD. > > Randy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 21 03:51:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465233A67C0; Sun, 21 Dec 2008 03:51:25 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4613A67C0 for ; Sun, 21 Dec 2008 03:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 yEOA25m5ofMb for ; Sun, 21 Dec 2008 03:51:23 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id F30763A680D for ; Sun, 21 Dec 2008 03:51:22 -0800 (PST) X-Trace: 63227374/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.95/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.95 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADa8TUk+vGlf/2dsb2JhbACDQykUA4k0rjhYj3IGhj0 X-IronPort-AV: E=Sophos;i="4.36,259,1228089600"; d="scan'208";a="63227374" X-IP-Direction: IN Received: from 1cust95.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.95]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Dec 2008 11:51:11 +0000 Message-ID: <000701c9635a$0fd39220$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <1229419168.6694.25.camel@missotis><20081217.131609.55656045.mbj@tail-f.com><1229518691.6175.24.camel@missotis> <20081217.140620.125651739.mbj@tail-f.com> Date: Sun, 21 Dec 2008 10:53:03 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Wednesday, December 17, 2008 2:06 PM Subject: Re: [netmod] canonical form > Ladislav Lhotka wrote: > > > 2. XPath 1.0 comparison in filtering and must/when expressions. > > > This is by definition done on the string representation of the > > > value (possibly interpreted as a number by XPath). > > > > > > By always using the canonical lexical form, we ensure that > > > comparisons can be done consistently. (*) > > > > This is however another deviation from XPath spec and practice. XPath > > has non-string types, supports numeric operations etc. > > I do not try to introduce anything new here, just documenting what > XPath does. Did I get it wrong? XPath has strings, numbers (64 bit > float) and boolean. > That is much as I see it. XPath 1.0 has strings, numbers and boolean (pace Node Sets). The lexical form for numbers is [30] Number ::= Digits ('.' Digits?)? | '.' Digits [31] Digits ::= [0-9]+ ie no octal, hexadecimal or 'float'. But the character string 'represents a floating-point number' and must be converted according to IEEE 754-1985 before being used with function or operator. (XPath 2.0 is different, perhaps the result of 10 years experience:-) Tom Petch > > > 3. Subtree filtering content match comparisons. Same as (2) above, > > > except that it defines its own whitespace trimming rules > > > (leading and trailing whitespaces are removed). > > > > But what if xpath capability is used? It will be very confusing if the > > comparison/matching semantics is different. > > I agree. I don't like the whitespace trimming rule, but it is there > in rfc4741. (it is also incompatible with the three whitespace rules > XSD defines...) > > > > (*) This works well as long as all types have a canonical lexical > > > form. Unfortunately, we have two types that don't, > > > 'instance-identifier' and 'identityref'. The lexical representation > > > of values of these types depend on the XML context in which they > > > occur. Specifically they both use namespace prefixes defined in > > > surrounding XML elements. For (1) above, where comparisons are done > > > in the value space, this is not a problem. But for (2) and (3) these > > > types cannot be correctly compared (unless the client uses the same > > > prefixes as the server, which we cannot assume.) > > > > > > I think we need to introduce the term "value space" in the spec, to > > > cover (1) above. (if all types could have a canonical lexical form we > > > wouldn't need this). > > > > On the other hand, if all comparisons were based on value space, we > > wouldn't need the canonical lexical form. > > Are you (!) suggesting that we change our usage of XPath to do > comparisons based on the value-space value? > > /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 21 03:56:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637293A67C0; Sun, 21 Dec 2008 03:56:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFF03A68DE for ; Sun, 21 Dec 2008 03:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 PkwgP1Clz07s for ; Sun, 21 Dec 2008 03:56:25 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 36B8A3A67C0 for ; Sun, 21 Dec 2008 03:56:25 -0800 (PST) X-Trace: 206928671/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.95/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.95 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAO29TUk+vGlf/2dsb2JhbACDQ0CJNK4rWI9yBoY9 X-IronPort-AV: E=Sophos;i="4.36,259,1228089600"; d="scan'208";a="206928671" X-IP-Direction: IN Received: from 1cust95.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.95]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Dec 2008 11:56:12 +0000 Message-ID: <002401c9635a$c3104680$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , References: <010a01c9600e$d4e732a0$6801a8c0@oemcomputer> Date: Sun, 21 Dec 2008 11:51:45 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Randy Presuhn" Sent: Wednesday, December 17, 2008 7:15 AM > I admit to being rather confused here. If XPath uses IEE 754, then > there are plenty of 64-bit integers that cannot be represented, or, > worse still, will be treated as being equal to other 64-bit integers > that have different bit patterns. This would seem to be a potential > trap for the unwary. Limiting the use of integer values to only those > values that will survive the IEEE 754 <-> integer round trip unscathed > seems a scary prospect. > Randy Not sure if you are now clear on this but my reading is .. Within expressions, XPath 1.0 allows integer and decimal [30] Number ::= Digits ('.' Digits?)? | '.' Digits [31] Digits ::= [0-9]+ but insists that everything is converted to double within function or operation so comparing two 100 digit numbers will first convert to double according to IEEE 754-1985 (sigh) rules. XPath 2.0 allows integer, decimal and double but only requires conversion if it is required, so two 100 digit decimal numbers are compared as decimal numbers, no conversion. Neither version allows octal or hexadecimal. Tom Petch > Randy > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 21 09:15:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780763A6768; Sun, 21 Dec 2008 09:15:57 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7763A6816 for ; Sun, 21 Dec 2008 09:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.057, 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 ZGlkmV9oQgCR for ; Sun, 21 Dec 2008 09:15:55 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id A9B353A6768 for ; Sun, 21 Dec 2008 09:15:55 -0800 (PST) Received: (qmail 34956 invoked from network); 21 Dec 2008 17:15:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 21 Dec 2008 17:15:45 -0000 X-YMail-OSG: k7p4OewVM1leRo44fdPv5CKg4nwvOgcGHX7jK.ICyYXIpSSOBHvAQ8HmXMyFj.WnQApxtg7PVFEW9SmEXPgsrnXSOryt0Tdgi9q01nvykMEevmLlOnGYUXW3Cdkgp4EsPuOpi_RQKurv8G4qoymyikWkKCVypm6eGbKrojqsCHaY3tOTjL6b7x03Qx4cQjOt X-Yahoo-Newman-Property: ymail-3 Message-ID: <494E79BF.9080204@netconfcentral.com> Date: Sun, 21 Dec 2008 09:15:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "tom.petch" References: <010a01c9600e$d4e732a0$6801a8c0@oemcomputer> <002401c9635a$c3104680$0601a8c0@allison> In-Reply-To: <002401c9635a$c3104680$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org tom.petch wrote: > ----- Original Message ----- > From: "Randy Presuhn" > Sent: Wednesday, December 17, 2008 7:15 AM > >> I admit to being rather confused here. If XPath uses IEE 754, then >> there are plenty of 64-bit integers that cannot be represented, or, >> worse still, will be treated as being equal to other 64-bit integers >> that have different bit patterns. This would seem to be a potential >> trap for the unwary. Limiting the use of integer values to only those >> values that will survive the IEEE 754 <-> integer round trip unscathed >> seems a scary prospect. >> > Randy > > Not sure if you are now clear on this but my reading is .. > > Within expressions, XPath 1.0 allows integer and decimal > > [30] Number ::= Digits ('.' Digits?)? | '.' Digits > [31] Digits ::= [0-9]+ > > but insists that everything is converted to double within function or operation > so comparing two 100 digit numbers will first convert to double according to > IEEE 754-1985 (sigh) rules. > > XPath 2.0 allows integer, decimal and double but only requires conversion if it > is required, so two 100 digit decimal numbers are compared as decimal numbers, > no conversion. > As Phil noted, XPath 2.0 is twice is big and at least twice as complicated as XPath 1.0. IMO, a non-starter for YANG. Our #1 priority is building a workable solution, which can be used by vendors and their customers to migrate from an ad-hoc proprietary CLI CM system to a significantly automated standard XML CM system. Let's try not to forget that as we work on Step Three out of twenty. If we get this part wrong, there probably won't be any more steps. I think the co-Chairs should figure out what to do from here, because we have run the course on this thread. > Neither version allows octal or hexadecimal. > > Tom Petch > >> Randy >> Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 21 11:36:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D5E3A6933; Sun, 21 Dec 2008 11:36:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A7C3A6938 for ; Sun, 21 Dec 2008 11:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.056, 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 64ICGll5bFaS for ; Sun, 21 Dec 2008 11:36:21 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id E7AA43A6933 for ; Sun, 21 Dec 2008 11:36:20 -0800 (PST) Received: (qmail 5657 invoked from network); 21 Dec 2008 19:36:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 21 Dec 2008 19:36:10 -0000 X-YMail-OSG: KJD8JRwVM1k4o7w4n0Zy9L82SrEaETWUzlO1B8XQSX1d2uiUJPCCe9lCPpmwdBh6OS69M1p6bL7SPvvIwAVZHXgVlIrErPRydIHpK_K8x8keMtt8wQAUGFnmTY7XeQgCHl8Ac6dcevZcwsYTW3dJkozL X-Yahoo-Newman-Property: ymail-3 Message-ID: <494E9AA8.3080008@netconfcentral.com> Date: Sun, 21 Dec 2008 11:36:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] anyxml syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The anyxml-stmt is not allowed to have any must-stmts. This seems odd because the XPath is allowed to point off somewhere else -- it cannot point inside the anyxml node, but other than that, it is pretty much the same as a leaf. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Dec 21 13:51:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7D23A68BB; Sun, 21 Dec 2008 13:51:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F563A69EE for ; Sun, 21 Dec 2008 13:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FF_IHOPE_YOU_SINK=2.166, GB_I_LETTER=-2] 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 1Vf6Mmf7vmtT for ; Sun, 21 Dec 2008 13:51:47 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id D28F83A68BB for ; Sun, 21 Dec 2008 13:51:46 -0800 (PST) X-Trace: 118869105/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.93/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.93 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAF5ITkk+vGRd/2dsb2JhbABFgn5AiTSuBViPEQaGPQ X-IronPort-AV: E=Sophos;i="4.36,260,1228089600"; d="scan'208";a="118869105" X-IP-Direction: IN Received: from 1cust93.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.93]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Dec 2008 21:51:36 +0000 Message-ID: <001001c963ad$f01e9d40$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , References: <000401c95fcb$bff9f8c0$6801a8c0@oemcomputer> <20081216.232014.150699396.mbj@tail-f.com> <000801c95fce$2a1b3e60$6801a8c0@oemcomputer><20081216.233927.158917585.mbj@tail-f.com><49485FEA.8070809@netconfcentral.com> <010a01c9600e$d4e732a0$6801a8c0@oemcomputer><003f01c96151$dcac62a0$0601a8c0@allison><494ACCF0.9030309@netconfcentral.com> <004001c96165$117bffa0$6801a8c0@oemcomputer> <006e01c96296$9db0dcc0$0601a8c0@allison><001c01c962d5$74a81b60$6801a8c0@oemcomputer><494D4A88.30601@netconfcentral.com> <000401c962e0$62ec00c0$6801a8c0@oemcomputer> Date: Sun, 21 Dec 2008 12:12:45 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] octal numbers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Ships in the night. The other option I would add is to declare a deviation, now that we have invented them, that comparisons should follow the rules of XPath 2.0 and not XPath 1.0 (which remains the standard for all other aspects of XPath). After all, XPath 2.0 might represent what XPath 1.0 would have been with ten more years experience. Tom Petch. ----- Original Message ----- From: "Randy Presuhn" To: Sent: Saturday, December 20, 2008 9:20 PM Subject: Re: [netmod] octal numbers > Hi - > > > From: "Andy Bierman" > > To: "Randy Presuhn" > > Cc: > > Sent: Saturday, December 20, 2008 11:42 AM > > Subject: Re: [netmod] octal numbers > ... > > This is where the Product Manager would send all the engineers > > off for psychiatric testing. ;-) We're building a CM system. > > In all my years of MIB Doctoring, I have never even gotten > > 1 request for a floating point MIB object. I heard of one in > > the IETF once, to represent probabilities from 0 to 1. > > Yup. Though there *are* cases where floating (or, more likely, > fixed) point numbers might be useful, to treat them as the > basis for comparison and other operations on things that > are really integers does not make sense. Like it or not, > computers operate in the world of discrete mathemetics, > and floats are just a (very very useful and valuable) hack, > not some magical way of connecting to the world of > continuous mathematics. > > > I do not think vendors will go out of their way to > > follow XPath 1.0 to the letter, just for YANG. > > Yup. A sanity check may be in order. > > > I can envision some router vendors who think their embedded > > systems do not have enough code room to add a lot of FP library > > support -- for must/when XPath evaluation that rarely gets > > used at all, let alone used with numbers like 2**52, or 1.003501, > > or real floating point math like (7.0303 * (1 div 9)). > > 2**52 isn't so far-fetched if someone needs to be able to > specify thresholds on zero-based 64-bit counters. But > I don't know how big an "if" that would be in the netconf/netmod world. > > > If we want to make it really difficult for vendors to > > adopt NETCONF and NETMOD then we should make a big deal > > out of this. We could just say "follow XPath 1.0" > > and no more. I would not want vendors to think: > > "We cannot possibly conform to IEEE 754, so we cannot > > conform to NETMOD/NETCONF. Since the main reason > > we are doing this work is to be standards-based, > > there is no point in choosing NETMOD/NETCONF. Let's > > go a different direction with XML." > > I agree this may be a teapot tempest. > There are several possibilities to consider: > > - the cases where IEEE 754 comparisons will produce > "surprising" answers don't matter because these sorts > of values will never be used in models or data stores > in places where XPath comparison with those values > will happen > > - though the answers might be "surprising" to the naive, > they're really not a problem > > - users of netmod applications *do* understand the implications > of IEEE 754, and will design their models and XPath > expressions accordingly > > - implementations don't really follow IEEE 754 rules when doing > comparisons of things that are known to really be integers > > I'm sure there are others, but someone needs to sort this out, to > avoid allowing it to turn into FUD. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 00:02:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64B53A6774; Mon, 22 Dec 2008 00:02:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC053A685E for ; Mon, 22 Dec 2008 00:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 yl++pn-vmlpa for ; Mon, 22 Dec 2008 00:02:40 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 926F63A6774 for ; Mon, 22 Dec 2008 00:02:40 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7DC5476C540; Mon, 22 Dec 2008 09:02:30 +0100 (CET) Date: Mon, 22 Dec 2008 09:02:28 +0100 (CET) Message-Id: <20081222.090228.90108427.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <494E9AA8.3080008@netconfcentral.com> References: <494E9AA8.3080008@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] anyxml syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > The anyxml-stmt is not allowed to have any must-stmts. > This seems odd because the XPath is allowed to point > off somewhere else -- it cannot point inside the anyxml > node, but other than that, it is pretty much the same as a leaf. You're right. I will add this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 06:12:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677E63A6808; Mon, 22 Dec 2008 06:12:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8283A694C for ; Mon, 22 Dec 2008 06:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.054, 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 slYOfLgJHI2P for ; Mon, 22 Dec 2008 06:12:34 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id D10423A6808 for ; Mon, 22 Dec 2008 06:12:34 -0800 (PST) Received: (qmail 3451 invoked from network); 22 Dec 2008 14:12:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 22 Dec 2008 14:12:23 -0000 X-YMail-OSG: GQDIUdwVM1nognHfUvZdH6PQ8X1KeJaJTgPTEfncWoR6Yy8zv1g5vN2B9p8akmAh.MlGY2rg0hsMG04laIUcZtAJlFuCqdqI87JZdlW.Upv2PIU3b98QdYKKZtj7Idi7KeSjhg.OY0G97vTK1dEsX4AR X-Yahoo-Newman-Property: ymail-3 Message-ID: <494FA046.1080309@netconfcentral.com> Date: Mon, 22 Dec 2008 06:12:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] why does deviation-stmt have restrictions? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, It seems odd that we are placing lots of restrictions on what a deviation is allowed to change. I even suggested that the builtin type MUST NOT change. I think we have the completely wrong perception of deviation-stmt. All these restrictions make is seem like deviations are an acceptable part of the data model. You don't like a clause? -- then just replace it or remove it with a deviation-stmt. It's OK in YANG. There is a strong chance your competitor in the market will not spin your deviations the same way. Deviations are mostly documenting the manner in which the agent does the WRONG, INCORRECT, NOT COMPLIANT, NON-STANDARD thing. In that respect, any valid YANG construct should be OK for a deviation (e.g., you cannot add a units-clause to a container, but you should replace the units clause on a leaf if you implemented the units wrong). Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 07:51:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB5D3A6829; Mon, 22 Dec 2008 07:51:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5473A3A6911 for ; Mon, 22 Dec 2008 07:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 A-ImI1kueurm for ; Mon, 22 Dec 2008 07:51:48 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 5BBBC3A6829 for ; Mon, 22 Dec 2008 07:51:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSU+3e4QB8cTDEQd69DqE/fPEduiHaV2P@postini.com; Mon, 22 Dec 2008 07:51:40 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 22 Dec 2008 07:48:09 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 07:48:09 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 07:48:08 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Dec 2008 07:48:08 -0800 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 mBMFm7M98277; Mon, 22 Dec 2008 07:48:07 -0800 (PST) (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 mBMFgYP1016206; Mon, 22 Dec 2008 15:42:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812221542.mBMFgYP1016206@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081222.090228.90108427.mbj@tail-f.com> Date: Mon, 22 Dec 2008 10:42:34 -0500 From: Phil Shafer X-OriginalArrivalTime: 22 Dec 2008 15:48:08.0326 (UTC) FILETIME=[AF9B6A60:01C9644C] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] anyxml syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Andy Bierman wrote: >> Hi, >> >> The anyxml-stmt is not allowed to have any must-stmts. >> This seems odd because the XPath is allowed to point >> off somewhere else -- it cannot point inside the anyxml >> node, but other than that, it is pretty much the same as a leaf. > >You're right. I will add this. If we undo this, it means that the server _must_ do xpath, since it has to apply an expression to unknown xml. I am strongly against this. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 07:56:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED8E3A6829; Mon, 22 Dec 2008 07:56:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94DE3A6968 for ; Mon, 22 Dec 2008 07:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 nFR2tIyI47FT for ; Mon, 22 Dec 2008 07:56:32 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id E9E613A6829 for ; Mon, 22 Dec 2008 07:56:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSU+4pvuvNlYX6InYhOyvjb5QD7Vv4882@postini.com; Mon, 22 Dec 2008 07:56:23 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 22 Dec 2008 07:53:29 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 07:53:29 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 07:53:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 07:53:28 -0800 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 mBMFrSM00956; Mon, 22 Dec 2008 07:53:28 -0800 (PST) (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 mBMFltvd016251; Mon, 22 Dec 2008 15:47:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812221547.mBMFltvd016251@idle.juniper.net> To: Andy Bierman In-Reply-To: <494FA046.1080309@netconfcentral.com> Date: Mon, 22 Dec 2008 10:47:55 -0500 From: Phil Shafer X-OriginalArrivalTime: 22 Dec 2008 15:53:28.0617 (UTC) FILETIME=[6E83F190:01C9644D] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] why does deviation-stmt have restrictions? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >There is a strong chance your competitor in the market >will not spin your deviations the same way. Deviations >are mostly documenting the manner in which the agent does the >WRONG, INCORRECT, NOT COMPLIANT, NON-STANDARD thing. Completely agree. Deviations are a means of documenting how and where the server violates the standard. They are not meant to imply that such violations are perfectly alright, but they are an admission that in the real world, bad things happen and we are better off knowing about them that pretending otherwise. >In that respect, any valid YANG construct should >be OK for a deviation (e.g., you cannot add a units-clause >to a container, but you should replace the units >clause on a leaf if you implemented the units wrong). Every deviation should be viewed as a impediment to allowing a box to be managed by a client application. The more severe the deviation, the worse things get. Changing ranges is bad, changing units is worse, changing the meaning is probably fatal. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 08:02:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F88A3A6829; Mon, 22 Dec 2008 08:02:22 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39FA3A69F9 for ; Mon, 22 Dec 2008 08:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.053, 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 VL0kkIPXLKRI for ; Mon, 22 Dec 2008 08:02:20 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 56A483A6829 for ; Mon, 22 Dec 2008 08:02:20 -0800 (PST) Received: (qmail 2946 invoked from network); 22 Dec 2008 16:02:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 22 Dec 2008 16:02:08 -0000 X-YMail-OSG: zNVXtpoVM1kS6nAKICGttvrOrD_nH9y.SYNWdcV9b1W4ZMV4Fqsd_1eY_WTsWBe66POxrC432bVpE9HrIci1oR.6k5Fi73M1tnY47SJLPGMjZa.kmsPRC0RTeyMFpuRHltGy92CgjFND27wuoGDv.d2h.M.wI7SoHyDJffSBQGa02yblUP0XWAGmkMlT4B0sHNCJWeXDWaxnWxaozV2pDw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <494FB9FE.5050906@netconfcentral.com> Date: Mon, 22 Dec 2008 08:02:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812221542.mBMFgYP1016206@idle.juniper.net> In-Reply-To: <200812221542.mBMFgYP1016206@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] anyxml syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> Andy Bierman wrote: >>> Hi, >>> >>> The anyxml-stmt is not allowed to have any must-stmts. >>> This seems odd because the XPath is allowed to point >>> off somewhere else -- it cannot point inside the anyxml >>> node, but other than that, it is pretty much the same as a leaf. >> You're right. I will add this. > > If we undo this, it means that the server _must_ do xpath, > since it has to apply an expression to unknown xml. I > am strongly against this. > That is not allowed. The agent cannot reference inside an anyxml node from a must/when expression. It makes no difference where the must-stmt is located. Disallowing must-stmt within anyxml has no impact whatsoever on this issue. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 08:12:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654643A6875; Mon, 22 Dec 2008 08:12:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07683A6985 for ; Mon, 22 Dec 2008 08:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.052, 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 63JtpSqZKXLi for ; Mon, 22 Dec 2008 08:12:04 -0800 (PST) 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 01F053A6875 for ; Mon, 22 Dec 2008 08:12:04 -0800 (PST) Received: (qmail 58567 invoked from network); 22 Dec 2008 16:11:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 22 Dec 2008 16:11:54 -0000 X-YMail-OSG: q9baE7sVM1nQqrC28XnT65Z0bpqfQzFJ1fcveCNxIYEL09.a.2ARsY5DrDJLmTyb8lK5qBuLINhwlyBlCMgmH56x0nzZItcyAxxZC38E2pk3Vr9lV4d_4zYq6488LreF0AaFfyyFD7I9RtwJYv.1NQcV X-Yahoo-Newman-Property: ymail-3 Message-ID: <494FBC48.3070009@netconfcentral.com> Date: Mon, 22 Dec 2008 08:11:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200812221547.mBMFltvd016251@idle.juniper.net> In-Reply-To: <200812221547.mBMFltvd016251@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] why does deviation-stmt have restrictions? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> There is a strong chance your competitor in the market >> will not spin your deviations the same way. Deviations >> are mostly documenting the manner in which the agent does the >> WRONG, INCORRECT, NOT COMPLIANT, NON-STANDARD thing. > > Completely agree. Deviations are a means of documenting > how and where the server violates the standard. They > are not meant to imply that such violations are perfectly > alright, but they are an admission that in the real world, > bad things happen and we are better off knowing about > them that pretending otherwise. > >> In that respect, any valid YANG construct should >> be OK for a deviation (e.g., you cannot add a units-clause >> to a container, but you should replace the units >> clause on a leaf if you implemented the units wrong). > > Every deviation should be viewed as a impediment to > allowing a box to be managed by a client application. > The more severe the deviation, the worse things get. > Changing ranges is bad, changing units is worse, changing > the meaning is probably fatal. > The NETMOD WG does not have to classify the manner or perceived severity of every possible deviation. I was wrong to think this would somehow 'guide' implementors to do the right thing. Of course implementing a float32 when the object calls for a boolean would be really bad. But this is just a documentation mechanism and if s/boolean/float32 is what the agent did, then that's what should be reported. In my SNMP experience, the deviations were rarely as clean as this YANG mechanism would suggest. BITS were routinely implemented wrong, and the NMS just had to hardwire the 'flip-the-bits' patch or 'bit4-is-really-bit9' patch. Most deviations can only be specified in a description clause, such as "will not take effect until next reboot", or "ARP cache does not get flushed as required by this object." There are still extremely valuable to the NMS developer, even though they cannot be automated patches. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 22 10:11:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A3D3A67AC; Mon, 22 Dec 2008 10:11:47 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECBC3A6829 for ; Mon, 22 Dec 2008 10:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 7Ms37NHDlVBV for ; Mon, 22 Dec 2008 10:11:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7BA663A67AC for ; Mon, 22 Dec 2008 10:11:44 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8DFD976C51A; Mon, 22 Dec 2008 19:11:34 +0100 (CET) Date: Mon, 22 Dec 2008 19:11:34 +0100 (CET) Message-Id: <20081222.191134.219345257.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200812221542.mBMFgYP1016206@idle.juniper.net> References: <20081222.090228.90108427.mbj@tail-f.com> <200812221542.mBMFgYP1016206@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] anyxml syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > >Andy Bierman wrote: > >> Hi, > >> > >> The anyxml-stmt is not allowed to have any must-stmts. > >> This seems odd because the XPath is allowed to point > >> off somewhere else -- it cannot point inside the anyxml > >> node, but other than that, it is pretty much the same as a leaf. > > > >You're right. I will add this. > > If we undo this, it means that the server _must_ do xpath, > since it has to apply an expression to unknown xml. I > am strongly against this. No, the change is merely to allow 'must' on an anxml node. The must expression itself cannot point inside the unknown chunk of data, just as today. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 23 11:12:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0307F28C157; Tue, 23 Dec 2008 11:12:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905B83A67DA for ; Tue, 23 Dec 2008 11:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 kBYZ48uZRuJ2 for ; Tue, 23 Dec 2008 11:12:18 -0800 (PST) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id 586443A6856 for ; Tue, 23 Dec 2008 11:12:16 -0800 (PST) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id mBNJC46q001624; Tue, 23 Dec 2008 20:12:04 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id mBNJC4Vl001623; Tue, 23 Dec 2008 20:12:04 +0100 (CET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: netmod@ietf.org In-Reply-To: <20081218161352.GC6703@elstar.local> (Juergen Schoenwaelder's message of "Thu, 18 Dec 2008 17:13:52 +0100") References: <20081218161352.GC6703@elstar.local> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Tue, 23 Dec 2008 20:12:04 +0100 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.3 (usg-unix-v) MIME-Version: 1.0 Subject: Re: [netmod] =?utf-8?q?ipv6_address_normalization_=C2=B6?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: > * Allow multiple formats and representations > * Make the shortened format the canonical format > * The :: substitution must be applied to the longest sequence of > zeros in an IPv6 address (if there is a tie, the first sequence > of zeros is replaced by ::) "Sequence of zeros"... I would prefer "sequence of all-zero 16-bit chunks", as that is clearer (if more verbose). I.e. you cannot compress 2000:1:2:3:4:5:6:7 => 2::1:2:3:4:5:6:7 I would also add that the :: subsitution should only be applied to sequences of two or more all-zero chunks, i.e. you shouldn't compress 2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7 This is a matter of taste and convention. The existing inet_ntop() code that I checked doesn't compress a single zero. -- Simon. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 23 16:37:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609A028C18E; Tue, 23 Dec 2008 16:37:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7527728C18E for ; Tue, 23 Dec 2008 16:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.054, 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 8rn9+zzkpRMf for ; Tue, 23 Dec 2008 16:37:24 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id D09A128C179 for ; Tue, 23 Dec 2008 16:37:24 -0800 (PST) Received: (qmail 67456 invoked from network); 24 Dec 2008 00:20:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.84.108 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 24 Dec 2008 00:20:16 -0000 X-YMail-OSG: 1_cALfAVM1kaiTOLOhhhsFnDeecr4n4tN9yeVX.kATNzDTxWOCYxtLN8zz866YaVRhPVOSocJRvQK3.F3HNuNnyCEQhayl.36Mc8U_tnDRiIy8SJdyrFiOOlshP_KW8c3KOUQfjwmjkDYhTqz45yEleG X-Yahoo-Newman-Property: ymail-3 Message-ID: <4951803E.8030009@netconfcentral.com> Date: Tue, 23 Dec 2008 16:20:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] container netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I was just looking at netconf-state.yang and then I looked at notifications.yang. They both define a top-level container. One of them defines it 'config true' and the other one defines it 'config false'. I know it is early for real data models and all, but notifications is a standards track RFC, so it must be right ;-) Every NETCONF model (rooted under /netconf) is going to have to augment the notifications data model. That doesn't seem very clean, but multiple /netconf containers in different XML namespaces is even worse. Suggestions to clean this mess up before it starts? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Dec 27 07:20:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0E83A68DA; Sat, 27 Dec 2008 07:20:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDB33A6A92 for ; Sat, 27 Dec 2008 07:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_05=-1.11, 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 KgLXYnsR7Kor for ; Sat, 27 Dec 2008 07:20:17 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id DF2143A6A8E for ; Sat, 27 Dec 2008 07:20:17 -0800 (PST) Received: (qmail 27039 invoked from network); 27 Dec 2008 15:20:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 27 Dec 2008 15:20:05 -0000 X-YMail-OSG: 9cBlovAVM1kq2NCXhzsGCOM_R1b.HjfvlZGOSE7h9TMQBQ5SIXz_2PA8gotafE0OV5ERvE.POQYL24szsU3iuc8HqT7EMlm_Z1lgqGf8OKdxg2BIYvZxp2Kq1DNuhDfbKFWQd.uTBR_Xc9NONa5Wcd5R X-Yahoo-Newman-Property: ymail-3 Message-ID: <495647A4.2050604@netconfcentral.com> Date: Sat, 27 Dec 2008 07:20:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The meaning of the docroot '/' within an AbsoluteLocationPath [rule 1] is not specified in the YANG draft. It changes depending on the context node. Not sure how to specify this, but here is a first draft... For a node within a NETCONF database, the document root is associated with the node,. E.g., a reference such as /if:interfaces/if:interface is aligned with or operations, such that is a child node of . For a node within an RPC method, the document root is associated with the parent of the element. E.g., a reference such as /nc:rpc/nc:get-config/nc:filter contains all the elements in the PDU. (Note the conceptual 'input' node is not present in the XPath for must/when/instance-id, but it is present for keyref.) For a node within a notification, the document root is associated with the parent of the element. E.g., a reference such as /ncn:notification/not:replayComplete contains all the elements in the PDU. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 00:57:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE493A679C; Mon, 29 Dec 2008 00:57:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8C63A68ED for ; Mon, 29 Dec 2008 00:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 XbOeGdl0WPJu for ; Mon, 29 Dec 2008 00:57:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6EB053A6847 for ; Mon, 29 Dec 2008 00:57:27 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A891676C52B; Mon, 29 Dec 2008 09:57:15 +0100 (CET) Date: Mon, 29 Dec 2008 09:57:15 +0100 (CET) Message-Id: <20081229.095715.28694997.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4951803E.8030009@netconfcentral.com> References: <4951803E.8030009@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] container netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > I was just looking at netconf-state.yang > and then I looked at notifications.yang. > > They both define a top-level container. > One of them defines it 'config true' and the other one > defines it 'config false'. > > I know it is early for real data models and all, > but notifications is a standards track RFC, > so it must be right ;-) > > Every NETCONF model (rooted under /netconf) is going > to have to augment the notifications data model. > That doesn't seem very clean, but multiple /netconf containers > in different XML namespaces is even worse. > > Suggestions to clean this mess up before it starts? That would be nice, and I believe that Sharon's intention has always been to have a single 'netconf' container. However, we're sort of stuck with the limitations of XSD. YANG is designed to handle this situation, but the YANG models are non-normative. Assuming we cannot change the structure of the data model in the notification RFC, and that we want one single 'netconf' container, it would have to be called: {urn:ietf:params:xml:ns:netmod:notification}netconf which is not optimal... Anyway, here are a few alternatives: 1) Add a substitionGroup to the 'netconf' element, as an errata to rfc 5277. The monitoring schema would then use this substitionGroup. 2) As an errata to 5277, add text that explains that the XSD is supposed to be completely open ( in XSD 1.1) The monitoring schema would then have text that explains that the contents would go under the {urn:ietf:params:xml:ns:netmod:notification}netconf element. 3) Live with it, and do better next time. Maybe as soon as in the monitoring spec - it could define a simple schema / YANG module with a single 'netconf' container in a generic namespace, and then augment this container with the monitoring stuff. When we do the third data model for netconf, we will then have this 'netconf' container element in place. But there are still a couple of unanswered questions - should we have one 'netconf' container for config and one for operational data? If we have one single container for both kinds, should we have two distinct subtrees underneath that one? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 02:11:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE6A3A677C; Mon, 29 Dec 2008 02:11:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2825B3A6866 for ; Mon, 29 Dec 2008 02:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 RmTw2JOykiss for ; Mon, 29 Dec 2008 02:11:40 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 066393A677C for ; Mon, 29 Dec 2008 02:11:40 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C5F1C76C52B; Mon, 29 Dec 2008 11:11:28 +0100 (CET) Date: Mon, 29 Dec 2008 11:11:28 +0100 (CET) Message-Id: <20081229.111128.155455032.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <495647A4.2050604@netconfcentral.com> References: <495647A4.2050604@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > The meaning of the docroot '/' within an AbsoluteLocationPath [rule 1] > is not specified in the YANG draft. It changes depending on > the context node. > > Not sure how to specify this, but here is a first draft... > > For a node within a NETCONF database, the document root is > associated with the node,. E.g., a reference > such as /if:interfaces/if:interface is aligned with > or operations, such that > is a child node of . I agree with this principle. > For a node within an RPC method, the document root is > associated with the parent of the element. > E.g., a reference such as /nc:rpc/nc:get-config/nc:filter > contains all the elements in the PDU. (Note the conceptual > 'input' node is not present in the XPath for must/when/instance-id, > but it is present for keyref.) > > For a node within a notification, the document root is > associated with the parent of the element. > E.g., a reference such as /ncn:notification/not:replayComplete > contains all the elements in the PDU. These XPath expressions are used in 'must', 'when' and 'path' (keyref/leafref). For example: rpc foo { input { leaf a { ... } leaf b { must "../a > ."; ... } } } So for 'must' and 'when', the tree to operate on should be the rpc/notification itself. But I don't quite see why the root would be the 'rpc' element; I think it should be the rpc/notification being defined. In the example above it would be 'foo'. But for 'path' expressions, this does not make much sense. As an example, consider this: notification link-down { leaf if-name { type keyref { path "/if:interface/if:name"; } } } Here, the intention is that the docroot of the path expression is the conceptual root of the running data store. In fact, it should be running + operational. This would mean that there is no way to address rpc/notification-local instances with keyref, unless we allow them to be addressed with relative xpath expressions: rpc foo { input { list a { ... } leaf b { type keyref { path "../a/name"; } } } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 07:34:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CD03A69BD; Mon, 29 Dec 2008 07:34:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4593A69BD for ; Mon, 29 Dec 2008 07:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.067, 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 NSUFkMOCzgzI for ; Mon, 29 Dec 2008 07:34:16 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 8CAF73A6C37 for ; Mon, 29 Dec 2008 07:34:16 -0800 (PST) Received: (qmail 19511 invoked from network); 29 Dec 2008 15:34:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Dec 2008 15:34:04 -0000 X-YMail-OSG: SfQGcDYVM1nWU6s3Dal0rYaeAvcX0DFmSdAJTOZRLRMDQTQR7__0jWypylhG7Fgnz1wy0LASE2tKnviGWrRKtWZdJrHHr4HcMbqg6YEeSVxPco1b79NipwtfLrIOBGOlG.ITG628QsMyFPLuNY7nlK5p4RaOq270laB.DzhMF6oPTEhulmWosorcGQaD3OEb8xMNscKQji2ZRmoS.5a0iw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4958EDEA.7010709@netconfcentral.com> Date: Mon, 29 Dec 2008 07:34:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <495647A4.2050604@netconfcentral.com> <20081229.111128.155455032.mbj@tail-f.com> In-Reply-To: <20081229.111128.155455032.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The meaning of the docroot '/' within an AbsoluteLocationPath [rule 1] >> is not specified in the YANG draft. It changes depending on >> the context node. >> >> Not sure how to specify this, but here is a first draft... >> >> For a node within a NETCONF database, the document root is >> associated with the node,. E.g., a reference >> such as /if:interfaces/if:interface is aligned with >> or operations, such that >> is a child node of . > > I agree with this principle. > >> For a node within an RPC method, the document root is >> associated with the parent of the element. >> E.g., a reference such as /nc:rpc/nc:get-config/nc:filter >> contains all the elements in the PDU. (Note the conceptual >> 'input' node is not present in the XPath for must/when/instance-id, >> but it is present for keyref.) >> >> For a node within a notification, the document root is >> associated with the parent of the element. >> E.g., a reference such as /ncn:notification/not:replayComplete >> contains all the elements in the PDU. > > These XPath expressions are used in 'must', 'when' and 'path' > (keyref/leafref). For example: > > rpc foo { > input { > leaf a { ... } > leaf b { > must "../a > ."; > ... > } > } > } > > So for 'must' and 'when', the tree to operate on should be the > rpc/notification itself. But I don't quite see why the root would be > the 'rpc' element; I think it should be the rpc/notification being > defined. In the example above it would be 'foo'. > The element is the start of the XML instance document. What is allowed for absolute path expressions? Is must "/nc:rpc/nc:edit-config/nc:test-option = 'set'"; permitted as a legal statement? Or maybe must "../../test-option"; Either way (starting at root, or using the parent node ..) you have to know which element is the document root. Andy > But for 'path' expressions, this does not make much sense. As an > example, consider this: > > notification link-down { > leaf if-name { > type keyref { > path "/if:interface/if:name"; > } > } > } > > Here, the intention is that the docroot of the path expression is the > conceptual root of the running data store. In fact, it should be > running + operational. > > This would mean that there is no way to address rpc/notification-local > instances with keyref, unless we allow them to be addressed with > relative xpath expressions: > > rpc foo { > input { > list a { ... } > leaf b { > type keyref { > path "../a/name"; > } > } > } > } > > > > /martin > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 08:19:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A856128C280; Mon, 29 Dec 2008 08:19:25 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DBB928C26A for ; Mon, 29 Dec 2008 08:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, 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 48MoIO3Hzzwh for ; Mon, 29 Dec 2008 08:19:23 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 6FA0F28C27F for ; Mon, 29 Dec 2008 08:19:23 -0800 (PST) Received: (qmail 94200 invoked from network); 29 Dec 2008 16:19:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 29 Dec 2008 16:19:11 -0000 X-YMail-OSG: wscbhPIVM1lnAQV0dLWm8OZpOlaiZrBw4pBAUfuBfk8wdcfkaWKQ2BglOwzFDY1bs5s3vAzihJmK3wJoAXHEdpvMGzq7vqK4gLq5llfTWEO9sCzYGMIIIGU54tfRdO2U_x0y2ryMFllBP.x9H0nZudmVJkxbPENiK_eZHH.kvPwG4Mvp36r5XmdM2nF4kSF65_nvwITohNqNtU1nIAKttQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4958F87E.2040500@netconfcentral.com> Date: Mon, 29 Dec 2008 08:19:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <495647A4.2050604@netconfcentral.com> <20081229.111128.155455032.mbj@tail-f.com> In-Reply-To: <20081229.111128.155455032.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The meaning of the docroot '/' within an AbsoluteLocationPath [rule 1] >> is not specified in the YANG draft. It changes depending on >> the context node. >> >> Not sure how to specify this, but here is a first draft... >> >> For a node within a NETCONF database, the document root is >> associated with the node,. E.g., a reference >> such as /if:interfaces/if:interface is aligned with >> or operations, such that >> is a child node of . > > I agree with this principle. > >> For a node within an RPC method, the document root is >> associated with the parent of the element. >> E.g., a reference such as /nc:rpc/nc:get-config/nc:filter >> contains all the elements in the PDU. (Note the conceptual >> 'input' node is not present in the XPath for must/when/instance-id, >> but it is present for keyref.) >> >> For a node within a notification, the document root is >> associated with the parent of the element. >> E.g., a reference such as /ncn:notification/not:replayComplete >> contains all the elements in the PDU. > > These XPath expressions are used in 'must', 'when' and 'path' > (keyref/leafref). For example: > > rpc foo { > input { > leaf a { ... } > leaf b { > must "../a > ."; > ... > } > } > } > > So for 'must' and 'when', the tree to operate on should be the > rpc/notification itself. But I don't quite see why the root would be > the 'rpc' element; I think it should be the rpc/notification being > defined. In the example above it would be 'foo'. > Here is a better example showing 2 XPath issues (augment targets are different than XPath paths: augment "/nc:rpc/nc:edit-config/nc:input" { when "/nc:rpc/nc:edit-config/nc:test-option = 'test-then-set'"; leaf my-test-option { ... } } Also, there is a 4th root, , when rpc output nodes are being referenced. Unless the entire PDU is available to the DM designer, there is no point is having all the user XML attributes in the element (mirrored in ) augment /a/b/c { when "/nc:rpc[@my-attr = '42']"; leaf forty-two-addons { ... } } Also, how is the expression "//foo" evaluated? Where is the 'top' for the expression evaluation code to start looking for 'foo' nodes? Obviously, processing for the ancestor and ancestor-or-self axis needs this clarification as well. > But for 'path' expressions, this does not make much sense. As an > example, consider this: > > notification link-down { > leaf if-name { > type keyref { > path "/if:interface/if:name"; > } > } > } > > Here, the intention is that the docroot of the path expression is the > conceptual root of the running data store. In fact, it should be > running + operational. > > This would mean that there is no way to address rpc/notification-local > instances with keyref, unless we allow them to be addressed with > relative xpath expressions: > > rpc foo { > input { > list a { ... } > leaf b { > type keyref { > path "../a/name"; > } > } > } > } > > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 12:02:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF423A6C0F; Mon, 29 Dec 2008 12:02:03 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFC03A6C0F for ; Mon, 29 Dec 2008 12:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 lR8NwO4z-mW7 for ; Mon, 29 Dec 2008 12:02:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 38CE03A681F for ; Mon, 29 Dec 2008 12:02:01 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 29C9676C51A; Mon, 29 Dec 2008 21:01:50 +0100 (CET) Date: Mon, 29 Dec 2008 21:01:46 +0100 (CET) Message-Id: <20081229.210146.54343388.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4958F87E.2040500@netconfcentral.com> References: <495647A4.2050604@netconfcentral.com> <20081229.111128.155455032.mbj@tail-f.com> <4958F87E.2040500@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Here is a better example showing 2 XPath issues (augment targets > are different than XPath paths: > > > augment "/nc:rpc/nc:edit-config/nc:input" { > > when "/nc:rpc/nc:edit-config/nc:test-option = 'test-then-set'"; > > leaf my-test-option { ... } > > } The augment expression should be: augment "/nc:edit-config/nc:input" { ... } There is no schema node 'rpc' in the NETCONF yang module (I had a look at your version, and you have one, defined as config data...) > Also, there is a 4th root, , when rpc output nodes are > being referenced. > > Unless the entire PDU is available to the DM designer, > there is no point is having all the user XML attributes > in the element (mirrored in ) I never understood why this attribute mirroring is important (we should ask Phil again, and write it down), but I'm quite sure the intention was not for DM designers to get access to the attributes. > augment /a/b/c { > when "/nc:rpc[@my-attr = '42']"; > > leaf forty-two-addons { ... } > } > > > Also, how is the expression "//foo" evaluated? > Where is the 'top' for the expression evaluation code > to start looking for 'foo' nodes? For an rpc definition of 'my-op', I think the tree should be: ... ... Hmm... another issue is if this is legal, and what it means: rpc my-op { input { leaf foo { when "/my-op/output/x"; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 12:32:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85743A69B9; Mon, 29 Dec 2008 12:32:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA003A69E8 for ; Mon, 29 Dec 2008 12:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, 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 iCfqCnVL7Vlx for ; Mon, 29 Dec 2008 12:32:22 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 3446B3A69B9 for ; Mon, 29 Dec 2008 12:32:22 -0800 (PST) Received: (qmail 44267 invoked from network); 29 Dec 2008 20:32:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 29 Dec 2008 20:32:07 -0000 X-YMail-OSG: daTbWcgVM1ksa1_2WGhEylePrVBk8JtAA_cfLtH6VFKQuOCxzYtwNZ7UIMl.WNuj_9c.cB4zv76cyOe1eIKM4g1d79tRHnOIti3YTSUvL.6nnLzXOgYVqfveURROHMXXqElYGcBP980NAPYLFqGiQN49KDdsGjU7CwALZN.jH.Qh373ZKFYKC8OhTzP1KB44aFkWC1.quJy2Iyq154nOHA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <495933C5.6020602@netconfcentral.com> Date: Mon, 29 Dec 2008 12:32:05 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <495647A4.2050604@netconfcentral.com> <20081229.111128.155455032.mbj@tail-f.com> <4958F87E.2040500@netconfcentral.com> <20081229.210146.54343388.mbj@tail-f.com> In-Reply-To: <20081229.210146.54343388.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Here is a better example showing 2 XPath issues (augment targets >> are different than XPath paths: >> >> >> augment "/nc:rpc/nc:edit-config/nc:input" { >> >> when "/nc:rpc/nc:edit-config/nc:test-option = 'test-then-set'"; >> >> leaf my-test-option { ... } >> >> } > > The augment expression should be: > > augment "/nc:edit-config/nc:input" { ... } > OK -- this is simpler and good enough > There is no schema node 'rpc' in the NETCONF yang module (I had a look > at your version, and you have one, defined as config data...) > >> Also, there is a 4th root, , when rpc output nodes are >> being referenced. >> >> Unless the entire PDU is available to the DM designer, >> there is no point is having all the user XML attributes >> in the element (mirrored in ) > > I never understood why this attribute mirroring is important (we > should ask Phil again, and write it down), but I'm quite sure the > intention was not for DM designers to get access to the attributes. > It was left up to the DM designers. The use-case was different applications for the than the one that generated the request. It is an app-to-app messaging mechanism, passed through the agent. We could leave /rpc and /notification out of YANG. IMO, it is no more or less stupid than: when "../ifInOctets mod 2"; which is perfectly legal YANG. But let's make the root for RPCs the method name node, and for notifications, the notification content node. That's fine. >> augment /a/b/c { >> when "/nc:rpc[@my-attr = '42']"; >> >> leaf forty-two-addons { ... } >> } >> >> >> Also, how is the expression "//foo" evaluated? >> Where is the 'top' for the expression evaluation code >> to start looking for 'foo' nodes? > > For an rpc definition of 'my-op', I think the tree should be: > > > > ... > > > ... > > > > Hmm... another issue is if this is legal, and what it means: > > rpc my-op { > input { > leaf foo { > when "/my-op/output/x"; > } > } > > This is legal but not going to work. The 'foo' when-stmt is evaluated at the time the PDU is received. At that time, there is no yet. Therefore, all references to such nodes will produce a 'false' result. IMO, the docroot for RPC input/output should be the and nodes, which will completely remove the possibility of referencing outside the scope of the 'current document'. rpc foo { input { leaf x { must '../y != 10'; type string; } leaf y { mandatory true; type string; } } } That looks better and matches the intent of the feature. XPath is designed to work against a single XML instance document. Let's keep it that way. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Dec 29 14:23:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE7B3A6452; Mon, 29 Dec 2008 14:23:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B353A67D0 for ; Mon, 29 Dec 2008 14:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 P+phEfJkbvAD for ; Mon, 29 Dec 2008 14:23:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EFDB83A6452 for ; Mon, 29 Dec 2008 14:23:27 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BA1E276C51A; Mon, 29 Dec 2008 23:23:15 +0100 (CET) Date: Mon, 29 Dec 2008 23:23:15 +0100 (CET) Message-Id: <20081229.232315.257844469.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <495933C5.6020602@netconfcentral.com> References: <4958F87E.2040500@netconfcentral.com> <20081229.210146.54343388.mbj@tail-f.com> <495933C5.6020602@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath document root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > IMO, the docroot for RPC input/output should be > the and nodes, which will completely > remove the possibility of referencing outside the > scope of the 'current document'. > > rpc foo { > input { > leaf x { must '../y != 10'; type string; } > leaf y { mandatory true; type string; } > } > } > > That looks better and matches the intent of the feature. Yes, you're right. I will try to specify this in -03. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 30 05:39:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142903A657C; Tue, 30 Dec 2008 05:39:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C5F3A690F for ; Tue, 30 Dec 2008 05:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 gQlYrVeBm73j for ; Tue, 30 Dec 2008 05:39:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 841513A657C for ; Tue, 30 Dec 2008 05:39:18 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BF56076C342 for ; Tue, 30 Dec 2008 14:39:06 +0100 (CET) Date: Tue, 30 Dec 2008 14:39:06 +0100 (CET) Message-Id: <20081230.143906.130384865.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, There's an open issue in -02 about the canonical form of floats. My preference has been to follow what XSD does, but when I looked at what they do, it turns out that it's not compatible with the normal C fprintf() function. When I then looked at how libxml2 handles this, it turns out that their function xmlSchemaGetCanonValue() doesn't generate conformant strings - it uses snprintf(). Since we state that servers MUST send data in the canonical form, this has some impact on implementations. An alternative could be to try to standardize what printf() does. Comments? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 30 08:41:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F97F3A67C0; Tue, 30 Dec 2008 08:41:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6A83A682D for ; Tue, 30 Dec 2008 08:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] 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 FJzhMIqCoEP8 for ; Tue, 30 Dec 2008 08:41:50 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 73FC33A67C0 for ; Tue, 30 Dec 2008 08:41:50 -0800 (PST) Received: (qmail 65478 invoked from network); 30 Dec 2008 16:41:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 30 Dec 2008 16:41:37 -0000 X-YMail-OSG: egIBhJwVM1mY5llxSJPvisCGiRXhicDikhoASNLQ1WSQZbw.cupD.UUeSSQRkYpgRioWJgE4hkuUWINN7JoH0bZoZIirnyCahtllr52RAfA.eG9Xwn7DSjYf59NWwHLscWeWOhq5euUda6vUP8efQ.g2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <495A4F3F.1060703@netconfcentral.com> Date: Tue, 30 Dec 2008 08:41:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081230.143906.130384865.mbj@tail-f.com> In-Reply-To: <20081230.143906.130384865.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > There's an open issue in -02 about the canonical form of floats. > > My preference has been to follow what XSD does, but when I looked at > what they do, it turns out that it's not compatible with the normal C > fprintf() function. When I then looked at how libxml2 handles this, > it turns out that their function xmlSchemaGetCanonValue() doesn't > generate conformant strings - it uses snprintf(). > > Since we state that servers MUST send data in the canonical form, this > has some impact on implementations. > > An alternative could be to try to standardize what printf() does. > > Comments? > float32: sprintf(buff, "%f", num.f); float64: sprintf(buff, "%lf", num.d); That's from my code. If sprintf does the wrong thing, the chance I will re-write sprintf myself just to comply with YANG are about 1 in a billion. Your odds may vary. I have an open bug to figure out why sprintf is generating extra trailing zeros, like 1.3 --> 1.300000 for float and double. All FP numbers seem to be printed with at least 6 digits of precision. Is this expected behavior or not? Standardizing what printf does is fine, but it does different things depending on how it is called. Let's pick some standard psuedo-code instead of mandating custom software nobody will write. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 30 09:28:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29053A6A13; Tue, 30 Dec 2008 09:28:22 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A403A6A3B for ; Tue, 30 Dec 2008 09:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 2t9RxahmEVOu for ; Tue, 30 Dec 2008 09:28:20 -0800 (PST) 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 EB2883A6A13 for ; Tue, 30 Dec 2008 09:28:20 -0800 (PST) Received: (qmail 59878 invoked from network); 30 Dec 2008 17:28:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 30 Dec 2008 17:28:09 -0000 X-YMail-OSG: lp1FhYAVM1nuLcxHtC4gjdSMSTkox.OKeEvmNURkVFHc.LBYAKOyrY8qu6_rGY_.TZ3cQniejE8zGpDL5Jd1ZUnS4Q202pEqHHCNXn2Fw6IuxxpDHF2CUl.9QVhfgU4D_vlhlGiDuECYmYZE144.jRJsZsbsrJkDa21Ic_CoVfjAzLozGEECPk8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <495A5A27.4010100@netconfcentral.com> Date: Tue, 30 Dec 2008 09:28:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081230.143906.130384865.mbj@tail-f.com> In-Reply-To: <20081230.143906.130384865.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > There's an open issue in -02 about the canonical form of floats. > > My preference has been to follow what XSD does, but when I looked at > what they do, it turns out that it's not compatible with the normal C > fprintf() function. When I then looked at how libxml2 handles this, > it turns out that their function xmlSchemaGetCanonValue() doesn't > generate conformant strings - it uses snprintf(). > > Since we state that servers MUST send data in the canonical form, this > has some impact on implementations. > > An alternative could be to try to standardize what printf() does. > > Comments? > See section 12.12.5, para 4 of the glibc manual: http://www.gnu.org/software/libc/manual/html_node/Floating_002dPoint-Conversions.html#Floating_002dPoint-Conversions It seems I should be using the '%a' or '%A' conversion, not the '%f' conversion, which is fixed point. The '%a' format is complicated, but here is the key sentence: The `%a' and `%A' conversions are meant for representing floating-point numbers exactly in textual form so that they can be exchanged as texts between different programs and/or machines. Great! But the very next sentence: The numbers are represented is the form [-]0xh.hhhp[+|-]dd. That is not IEEE754 format of course. XPath parsers will not accept the "+/- exponent" part, and will (incorrectly) accept an AdditiveExpr [rule 25] instead. Since that won't work, even though it exactly meets the real needs of the NETCONF community, setting the precision manually for the %f option seems the obvious next choice. The values to set manually are not so obvious. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 30 09:35:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D2E3A67C0; Tue, 30 Dec 2008 09:35:09 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07463A690F for ; Tue, 30 Dec 2008 09:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[AWL=-2.228, BAYES_20=-0.74, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, J_CHICKENPOX_74=0.6] 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 8v4o-VezbSOj for ; Tue, 30 Dec 2008 09:35:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 176C43A67C0 for ; Tue, 30 Dec 2008 09:35:08 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34221C0014; Tue, 30 Dec 2008 18:34:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zTSNg4YVBa3b; Tue, 30 Dec 2008 18:34:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 122FBC000C; Tue, 30 Dec 2008 18:34:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DEEB08D2118; Tue, 30 Dec 2008 18:34:49 +0100 (CET) Date: Tue, 30 Dec 2008 18:34:49 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081230173449.GA793@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20081230.143906.130384865.mbj@tail-f.com> <495A4F3F.1060703@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <495A4F3F.1060703@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Dec 30, 2008 at 08:41:35AM -0800, Andy Bierman wrote: > float32: sprintf(buff, "%f", num.f); > > float64: sprintf(buff, "%lf", num.d); [...] > I have an open bug to figure out why sprintf is > generating extra trailing zeros, like 1.3 --> 1.300000 > for float and double. All FP numbers seem > to be printed with at least 6 digits of precision. > Is this expected behavior or not? This is consistent with my manual page: f The argument is printed in the style [-]ddd.ddd where the number of d's after the decimal point is equal to the preci- sion specification for the argument. If the precision is missing, 6 digits are given; if the precision is explicitly 0, no digits and no decimal point are printed. And this is consistent with C99 says, which should be the definitive reference for this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Dec 30 16:01:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8884C3A6955; Tue, 30 Dec 2008 16:01:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AAA3A696A for ; Tue, 30 Dec 2008 16:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 oKUQew1XzRxI for ; Tue, 30 Dec 2008 16:01:48 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 32B2B3A6955 for ; Tue, 30 Dec 2008 16:01:47 -0800 (PST) Received: (qmail 22098 invoked from network); 31 Dec 2008 00:01:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.180 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 31 Dec 2008 00:01:35 -0000 X-YMail-OSG: KSBWtNAVM1kK9b2hXMluWV8vhB.uhdGLUco4uGI2uVtTaBsK3fks7EJCVKBDiU4VHrWt5q1GgNX.ayMEr74ZDMY8mjhbsbcMKZzyou.2bE0qXHgF6r6J7w0JRpi9PssBBChQJf7NZPDVVWuN755tPoVE X-Yahoo-Newman-Property: ymail-3 Message-ID: <495AB65D.5030808@andybierman.com> Date: Tue, 30 Dec 2008 16:01:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] yang-02, 7.5.2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Are all these discussions about must-stmt inside rpc or notification academic? From 7.5.2, para 4: The "must" statement is ignored if the data does not represent configuration. Para 7: If the node with the must statement represents configuration data, any node referenced in the XPath expression MUST also represent configuration. These statements seem to conflict. It's fine with me if we leave must-stmt processing out of RPC and notification completely. It will make the document easier to read and write (and get done). BTW, para 7 is not quite complete -- 'any node referenced' could be via 1 of the wildcard mechanisms, and not just an explicit path statement like the examples we often use. Each path statement result is a node-set, not just 1 node. Ditto for each path step. So we need a sentence that says that non-config nodes matched by [fill in the wildcard mechanisms], instead of by direct reference, are ignored during must-stmt validation and evaluation. Or are wildcard matches considered an error also? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Dec 31 03:45:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6E93A67F3; Wed, 31 Dec 2008 03:45:17 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BB63A6821 for ; Wed, 31 Dec 2008 03:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 wjBbP50B2R2b for ; Wed, 31 Dec 2008 03:45:16 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 1384E3A67F3 for ; Wed, 31 Dec 2008 03:45:15 -0800 (PST) X-Trace: 120361012/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.53/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.53 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAAvqWkk+vGQ1/2dsb2JhbACDQ0CJO78TBoY+ X-IronPort-AV: E=Sophos;i="4.36,307,1228089600"; d="scan'208";a="120361012" X-IP-Direction: IN Received: from 1cust53.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.53]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2008 11:45:01 +0000 Message-ID: <004d01c96b34$d3473360$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Martin Bjorklund" References: <20081230.143906.130384865.mbj@tail-f.com> <495A5A27.4010100@netconfcentral.com> Date: Wed, 31 Dec 2008 11:43:44 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Tuesday, December 30, 2008 6:28 PM Subject: Re: [netmod] canonical form of floats > Martin Bjorklund wrote: > > Hi, > > > > There's an open issue in -02 about the canonical form of floats. > > > > My preference has been to follow what XSD does, but when I looked at > > what they do, it turns out that it's not compatible with the normal C > > fprintf() function. When I then looked at how libxml2 handles this, > > it turns out that their function xmlSchemaGetCanonValue() doesn't > > generate conformant strings - it uses snprintf(). > > > > Since we state that servers MUST send data in the canonical form, this > > has some impact on implementations. > > > > An alternative could be to try to standardize what printf() does. > > > > Comments? > > > > See section 12.12.5, para 4 of the glibc manual: > > http://www.gnu.org/software/libc/manual/html_node/Floating_002dPoint-Conversions .html#Floating_002dPoint-Conversions > > It seems I should be using the '%a' or '%A' conversion, > not the '%f' conversion, which is fixed point. > > The '%a' format is complicated, but here is the key sentence: > > The `%a' and `%A' conversions are meant for representing floating-point > numbers exactly in textual form so that they can be exchanged as texts > between different programs and/or machines. > > Great! But the very next sentence: > > The numbers are represented is the form [-]0xh.hhhp[+|-]dd. > > That is not IEEE754 format of course. > XPath parsers will not accept the "+/- exponent" part, > and will (incorrectly) accept an AdditiveExpr [rule 25] instead. XPath 1.0 only allows integer and decimal, no float (nor octal, nor hexadecimal:-) Tom Petch > > Since that won't work, even though it exactly meets > the real needs of the NETCONF community, setting > the precision manually for the %f option seems > the obvious next choice. The values to set manually > are not so obvious. > > > > > > > /martin > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod