From mbj@tail-f.com Wed Jul 1 00:02:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F8128C4DD for ; Wed, 1 Jul 2009 00:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.090, 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 bffTJPBl5kG5 for ; Wed, 1 Jul 2009 00:02:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 28AF03A685E for ; Wed, 1 Jul 2009 00:02:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 993F776C52D; Wed, 1 Jul 2009 09:02:24 +0200 (CEST) Date: Wed, 01 Jul 2009 09:02:24 +0200 (CEST) Message-Id: <20090701.090224.50024147.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246428199.6491.18.camel@missotis> References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 07:02:05 -0000 Ladislav Lhotka wrote: > Example: > > module xxx { > prefix x; > namespace "http://example.com/xxx"; > grouping foo { > leaf a { > type uint8; > } > } > } > > module yyy { > prefix y; > namespace "http://example.com/yyy"; > import xxx { prefix x; } > grouping bar { > container c { > must "x:a < y:b"; This is not correct - the uses statement below adds the nodes from the grouping foo to 'yyy', so it should be: must "y:a < y:b"; > uses x:foo; > leaf b { > type uint8; > } > } > } > } > > module zzz { > prefix z; > namespace "http://example.com/zzz"; > import yyy { prefix y; } > uses bar; > } > > So, if I interpret your statement correctly, the following instance is > valid according to module zzz: > > > 1 > 2 > > > I think such juggling with namespaces is hardly acceptable. Also, it > contradicts what Andy said earlier: > "All prefixes need to be resolved in the module where they are appear." Can you describe how you would like it to work? /martin From lhotka@cesnet.cz Wed Jul 1 00:45:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DBF83A67F9 for ; Wed, 1 Jul 2009 00:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=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 vIVqeidO6jnd for ; Wed, 1 Jul 2009 00:45:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 139F43A67CC for ; Wed, 1 Jul 2009 00:45:31 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 75E17D800C8; Wed, 1 Jul 2009 09:45:52 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090701.090224.50024147.mbj@tail-f.com> References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 01 Jul 2009 09:45:52 +0200 Message-Id: <1246434352.6491.49.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 07:45:32 -0000 Martin Bjorklund píše v St 01. 07. 2009 v 09:02 +0200: > Ladislav Lhotka wrote: > > Example: > > > > module xxx { > > prefix x; > > namespace "http://example.com/xxx"; > > grouping foo { > > leaf a { > > type uint8; > > } > > } > > } > > > > module yyy { > > prefix y; > > namespace "http://example.com/yyy"; > > import xxx { prefix x; } > > grouping bar { > > container c { > > must "x:a < y:b"; > > This is not correct - the uses statement below adds the nodes from the > grouping foo to 'yyy', so it should be: > > must "y:a < y:b"; Right, this was my mistake, but still, the prefix "y" is explicit, so it should be resolved here to NS URI "http://example.com/yyy" and never change later. > > > uses x:foo; > > leaf b { > > type uint8; > > } > > } > > } > > } > > > > module zzz { > > prefix z; > > namespace "http://example.com/zzz"; > > import yyy { prefix y; } > > uses bar; Another typo, this should have been "uses y:bar;". > > } > > > > So, if I interpret your statement correctly, the following instance is > > valid according to module zzz: > > > > > > 1 > > 2 > > > > > > I think such juggling with namespaces is hardly acceptable. Also, it > > contradicts what Andy said earlier: > > "All prefixes need to be resolved in the module where they are appear." > > Can you describe how you would like it to work? 1. All names with explicit NS prefixes are resolved to QNames in the module where they appear, independently of whether they are in a grouping or not. 2. Inside groupings, unprefixed names are left "namespace-less" and their namespace is set later when the grouping is used in a schema tree. 3. If a grouping is used inside another grouping, the unprefixed names continue to be namespace-less. So, module yyy from my example should look like this: module yyy { prefix y; namespace "http://example.com/yyy"; import xxx { prefix x; } grouping bar { container c { must "a < b"; uses x:foo; leaf b { type uint8; } } } } Here, both "a" and "b" still have no namespace. module zzz { prefix z; namespace "http://example.com/zzz"; import yyy { prefix y; } uses y:bar; } Here, y:bar is used (instantiated) in the schema tree of module zzz, which becomes equivalent to: module zzz { prefix z; namespace "http://example.com/zzz"; import yyy { prefix y; } container c { must "z:a < z:b"; leaf a { type uint8; } leaf b { type uint8; } } } Now, "a" and "b" have the NS URI "http://example.com/zzz" and 1 2 is valid wrt zzz. If the must statement in module yyy was must "y:a < y:b"; it could be satisfied only if grouping bar is used in module yyy, so the above document wouldn't be valid. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Jul 1 01:33:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EBE3A6EC9 for ; Wed, 1 Jul 2009 01:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=0.392, 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 leaKGBhmLTCh for ; Wed, 1 Jul 2009 01:33:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A3DCF3A6E76 for ; Wed, 1 Jul 2009 01:33:01 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DE51DD800C1 for ; Wed, 1 Jul 2009 10:33:08 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20090630.223123.09049480.mbj@tail-f.com> References: <20090630.223123.09049480.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 01 Jul 2009 10:33:08 +0200 Message-Id: <1246437188.6491.52.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] xpath in augment 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: , X-List-Received-Date: Wed, 01 Jul 2009 08:33:02 -0000 +1 Lada Martin Bjorklund píše v Út 30. 06. 2009 v 22:31 +0200: > Hi, > > I realized that we are using the augment-style XPath in other > statements: deviation has an absolute expression just like top-level > augment, and unique and refine has a descendant expression just like > uses-augment. > > [BTW, There's a bug in the grammar for 'augment-arg', it should be: > augment-arg = absolute-schema-nodeid] > > So I'm thinking it might be easiest to explain this NOT in terms of > XPath, but simply define the rules for a schema node identifier. Then > all XPath evaluations in YANG work on the data tree only, which makes > things simpler. > > Something like this: > > > * Schema node identifier > > A schema node identifier is a string that identifies a node in the > schema tree. It has two forms, "absolute" and "descendant", defined > by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid" > in ^grammar^, respectively. A schema node identifier consists of a > path of identifiers, separated by slashes ("/"). In an absolute > schema node identifier, the first identifier after the leading slash > is any top-level schema node in local module or all imported modules. > > References to identifiers defined in external modules MUST be > qualified with appropriate prefixes, and references to identifiers > defined in the current module and its submodules MAY use a prefix. > > For example, to identify the child node "b" of top-level node "a", the > string "/a/b" can be used. > > > > > And then we just refer to this section for the statements above, and > get rid of the XPath issues for augment. > > Comments? > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From Washam.Fan@huaweisymantec.com Wed Jul 1 02:38:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55E228C490 for ; Wed, 1 Jul 2009 02:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buJ5vpJbSeUw for ; Wed, 1 Jul 2009 02:38:24 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id E51E528C477 for ; Wed, 1 Jul 2009 02:38:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KM300IUIK4B0J10@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 01 Jul 2009 17:38:35 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KM300JV9K4ADO10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 01 Jul 2009 17:38:35 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 01 Jul 2009 17:38:34 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Wed, 01 Jul 2009 17:38:34 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <1246434352.6491.49.camel@missotis> References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> <1246434352.6491.49.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 09:38:24 -0000 Hi, > > Can you describe how you would like it to work? > > 1. All names with explicit NS prefixes are resolved to QNames in the > > module where they appear, independently of whether they are in a > grouping or not. I would agree with what Martin said before. If the name refers to a node in the grouping regardless of the NS prefix, it should always refer to the node in the grouping. washam > > 2. Inside groupings, unprefixed names are left "namespace-less" and > their namespace is set later when the grouping is used in a schema > > tree. > > 3. If a grouping is used inside another grouping, the unprefixed > names > continue to be namespace-less. From lhotka@cesnet.cz Wed Jul 1 02:59:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5D328C3E3 for ; Wed, 1 Jul 2009 02:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.378, 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 BaabCMyoH21X for ; Wed, 1 Jul 2009 02:59:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 220DE28C0E9 for ; Wed, 1 Jul 2009 02:59:52 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E1197D800F0; Wed, 1 Jul 2009 12:00:11 +0200 (CEST) From: Ladislav Lhotka To: WashamFan In-Reply-To: References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> <1246434352.6491.49.camel@missotis> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 01 Jul 2009 12:00:11 +0200 Message-Id: <1246442411.6491.94.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 09:59:53 -0000 WashamFan píše v St 01. 07. 2009 v 17:38 +0800: > Hi, > > > > Can you describe how you would like it to work? > > > > 1. All names with explicit NS prefixes are resolved to QNames in the > > > > module where they appear, independently of whether they are in a > > grouping or not. > > I would agree with what Martin said before. If the name refers to a node > in the grouping regardless of the NS prefix, it should always refer to the node > in the grouping. It may not be always easy to determine which nodes are in the grouping, because groupings can be nested. Also, in a grouping like this ... prefix x; grouping foo { container c { must "x:a < ../x:above"; leaf a { ... } } } it would be pretty confusing if the resolution of the same prefix "x" was fixed for 'x:above' and postponed for 'x:a'. Lada > > washam > > > > 2. Inside groupings, unprefixed names are left "namespace-less" and > > their namespace is set later when the grouping is used in a schema > > > > tree. > > > > 3. If a grouping is used inside another grouping, the unprefixed > > names > > continue to be namespace-less. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From Washam.Fan@huaweisymantec.com Wed Jul 1 03:10:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D56E3A6E4D for ; Wed, 1 Jul 2009 03:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA0xOnprfR2I for ; Wed, 1 Jul 2009 03:10:43 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id AE20B3A6934 for ; Wed, 1 Jul 2009 03:10:43 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=iso-8859-15 Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KM300ICBLM60J20@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 01 Jul 2009 18:10:55 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KM300IZ0LM69H10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 01 Jul 2009 18:10:54 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 01 Jul 2009 18:10:54 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Wed, 01 Jul 2009 18:10:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <1246442411.6491.94.camel@missotis> References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> Content-transfer-encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 10:10:44 -0000 Hi=2C ----- Original Message ----- From=3A Ladislav Lhotka =3Clhotka=40cesnet=2Ecz=3E Date=3A Wednesday=2C July 1=2C 2009 6=3A00 pm Subject=3A Re=3A =5Bnetmod=5D prefixes in groupings To=3A WashamFan =3CWasham=2EFan=40huaweisymantec=2Ecom=3E Cc=3A Martin Bjorklund =3Cmbj=40tail-f=2Ecom=3E=2C netmod=40ietf=2Eorg =3E WashamFan p=ED=A8e v St 01=2E 07=2E 2009 v 17=3A38 +0800=3A =3E =3E Hi=2C =3E =3E = =3E =3E =3E =3E Can you describe how you would like it to work=3F =3E =3E =3E = =3E =3E =3E 1=2E All names with explicit NS prefixes are resolved to Q= Names in = =3E the = =3E =3E =3E = =3E =3E =3E module where they appear=2C independently of whether th= ey are = =3E in a = =3E =3E =3E grouping or not=2E =3E =3E = =3E =3E I would agree with what Martin said before=2E If the name refer= s to a = =3E node =3E =3E in the grouping regardless of the NS prefix=2C it should always= refer = =3E to the node =3E =3E in the grouping=2E =3E = =3E It may not be always easy to determine which nodes are in the group= ing=2C =3E because groupings can be nested=2E Also=2C in a grouping like this =3E = =3E =2E=2E=2E =3E prefix x=3B =3E = =3E grouping foo =7B =3E container c =7B =3E must =22x=3Aa =3C =2E=2E/x=3Aabove=22=3B =3E leaf a =7B =2E=2E=2E =7D =3E =7D =3E =7D =3E = =3E it would be pretty confusing if the resolution of the same prefix =22= x=22 =3E was fixed for =27x=3Aabove=27 and postponed for =27x=3Aa=27=2E I am not sure I follow=2E In the example=2C x=3Aa refers to a node in th= e grouping whereas x=3Aabout refers to some one outside of the grouping=2E Why conf= using=3F washam = From lhotka@cesnet.cz Wed Jul 1 03:59:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED22F28C4ED for ; Wed, 1 Jul 2009 03:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=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 14FE+LwUpD-R for ; Wed, 1 Jul 2009 03:59:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BBF5728C48E for ; Wed, 1 Jul 2009 03:59:36 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C0890D800CC; Wed, 1 Jul 2009 12:59:57 +0200 (CEST) From: Ladislav Lhotka To: WashamFan In-Reply-To: References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 01 Jul 2009 12:59:56 +0200 Message-Id: <1246445996.6491.102.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 10:59:40 -0000 WashamFan píše v St 01. 07. 2009 v 18:10 +0800: > > > > ... > > prefix x; > > > > grouping foo { > > container c { > > must "x:a < ../x:above"; > > leaf a { ... } > > } > > } > > > > it would be pretty confusing if the resolution of the same prefix "x" > > was fixed for 'x:above' and postponed for 'x:a'. > > I am not sure I follow. In the example, x:a refers to a node in the grouping > whereas x:about refers to some one outside of the grouping. Why confusing? Because the resolution of the same prefix in the same expression depends on non-trivial context, which is also complicated by the possibility of augmenting the grouping when it is used. Lada > > washam > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Jul 1 07:51:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0D93A69B7 for ; Wed, 1 Jul 2009 07:51:58 -0700 (PDT) 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.168, BAYES_00=-2.599, J_CHICKENPOX_13=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 3aS0nIhAOcwF for ; Wed, 1 Jul 2009 07:51:58 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id F0B1C3A6858 for ; Wed, 1 Jul 2009 07:51:57 -0700 (PDT) Received: (qmail 40525 invoked from network); 1 Jul 2009 14:49:32 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 1 Jul 2009 14:49:31 -0000 X-YMail-OSG: 3BrZYhEVM1kWJGVxKP.tEQon2pEv6Sp9JMoOHq3GSmzRVWtMYoIOdcTwWoibQ4PSz7pT3bqLxZhJYJYYkq2QpBWZPPG.Hz4IMIcuPVKO4LL8hvu0.WlnycUzECu4pAuSKx6umiHlXTb3j_atptYTtwIZ2Q8iv5UrS3X38ov1rT.K_aR8g2jyYVdKx09t5jry92Dtl1hTUNe8MvJOC3ncSxFtBYGP3FM5g4IPHOUBSZNCZm4egwMAxeJ0e0f3grLeGf6bnyDz6txPKW0q_Mi6S09RK39hwR4rYA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4B7768.3090708@netconfcentral.com> Date: Wed, 01 Jul 2009 07:49:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> <1246434352.6491.49.camel@missotis> In-Reply-To: <1246434352.6491.49.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 01 Jul 2009 14:51:59 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v St 01. 07. 2009 v 09:02 +0200: >> Ladislav Lhotka wrote: >>> Example: >>> >>> module xxx { >>> prefix x; >>> namespace "http://example.com/xxx"; >>> grouping foo { >>> leaf a { >>> type uint8; >>> } >>> } >>> } >>> >>> module yyy { >>> prefix y; >>> namespace "http://example.com/yyy"; >>> import xxx { prefix x; } >>> grouping bar { >>> container c { >>> must "x:a < y:b"; >> This is not correct - the uses statement below adds the nodes from the >> grouping foo to 'yyy', so it should be: >> >> must "y:a < y:b"; > > Right, this was my mistake, but still, the prefix "y" is explicit, so it > should be resolved here to NS URI "http://example.com/yyy" and never > change later. > >>> uses x:foo; >>> leaf b { >>> type uint8; >>> } >>> } >>> } >>> } >>> >>> module zzz { >>> prefix z; >>> namespace "http://example.com/zzz"; >>> import yyy { prefix y; } >>> uses bar; > > Another typo, this should have been "uses y:bar;". > >>> } >>> >>> So, if I interpret your statement correctly, the following instance is >>> valid according to module zzz: >>> >>> >>> 1 >>> 2 >>> >>> >>> I think such juggling with namespaces is hardly acceptable. Also, it >>> contradicts what Andy said earlier: >>> "All prefixes need to be resolved in the module where they are appear." >> Can you describe how you would like it to work? > > 1. All names with explicit NS prefixes are resolved to QNames in the > module where they appear, independently of whether they are in a > grouping or not. > > 2. Inside groupings, unprefixed names are left "namespace-less" and > their namespace is set later when the grouping is used in a schema > tree. > > 3. If a grouping is used inside another grouping, the unprefixed names > continue to be namespace-less. > This is worse than what we have now. Although it is possible to construct corner-cases that are confusing to the naked eye, they are not confusing to the software that is processing groupings. The rule for prefixes is rather simple now, and it should stay that way. It is critical that groupings remain transparent to the protocol. It would be a disaster to have a must-stmt or a default for an identityref work one way in plain YANG, but another way if the DM writer cut-and-paste those objects into a grouping, and replaced them with a uses-stmt for that grouping. E.g., leaf X { type string; } must always be equivalent to grouping A { leaf X { type string; } } uses A; for any grouping with any contents. > So, module yyy from my example should look like this: > > module yyy { > prefix y; > namespace "http://example.com/yyy"; > import xxx { prefix x; } > grouping bar { > container c { > must "a < b"; > uses x:foo; > leaf b { > type uint8; > } > } > } > } > > Here, both "a" and "b" still have no namespace. > > module zzz { > prefix z; > namespace "http://example.com/zzz"; > import yyy { prefix y; } > uses y:bar; > } > > Here, y:bar is used (instantiated) in the schema tree of module zzz, > which becomes equivalent to: > > module zzz { > prefix z; > namespace "http://example.com/zzz"; > import yyy { prefix y; } > container c { > must "z:a < z:b"; > leaf a { > type uint8; > } > leaf b { > type uint8; > } > } > } > > Now, "a" and "b" have the NS URI "http://example.com/zzz" and > > > 1 > 2 > > > is valid wrt zzz. > > If the must statement in module yyy was > > must "y:a < y:b"; > > it could be satisfied only if grouping bar is used in module yyy, so the > above document wouldn't be valid. > > Lada > Andy From muenz@net.in.tum.de Wed Jul 1 09:29:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16373A68F4 for ; Wed, 1 Jul 2009 09:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 N4SxVG1+P4xd for ; Wed, 1 Jul 2009 09:29:38 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id DAEA228C54B for ; Wed, 1 Jul 2009 09:29:21 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 17EC547CF3 for ; Wed, 1 Jul 2009 18:28:49 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0514A50B1 for ; Wed, 1 Jul 2009 18:28:49 +0200 (CEST) Message-ID: <4A4B8F24.2040602@net.in.tum.de> Date: Wed, 01 Jul 2009 18:30:28 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040302070607040004090706" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [netmod] Condition in must statement 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: , X-List-Received-Date: Wed, 01 Jul 2009 16:29:39 -0000 This is a cryptographically signed message in MIME format. --------------ms040302070607040004090706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I try to specify some restrictions regarding leafref values with a must statement in the IPFIX configuration model. Here's the part of the YANG spec: list observationPoint { key name; leaf name { type string; } leaf observationDomainId { type uint32; mandatory true; } ... leaf-list selectionProcess { type leafref { path "/ipfix/selectionProcess/name"; } } } list selectionProcess { must "/observationPoint[selectionProcess=current().name] .observationDomainId.floor() = /observationPoint[selectionProcess=current().name] .observationDomainId.ceil()" { description "If the input of this Selection Process is an Observed Packet Stream originating from different Observation Points, the must statement ensures that all Observation Points belong to the same Observation Domain."; } key name; leaf name { type string; } ... } The goal is that all elements of the observationPoint list referring to one specific element of the selectionProcess list must have the same observationDomainId value. I tried to restrict this by enforcing observationDomainId.ceil() = observationDomainId.floor() for the corresponding observationPoint elements. I'm not sure if the XPath expression is correct. Also, I would like to know which result the must statement returns if there are no observationPoint elements at all, or if no observationPoint is referring to the given selectionProcess element. Is it possible to have nested "[]" in the XPath? Because I have also something more weired in the cache list: list cache { if-feature meter; must "/observationPoint[ selectionProcess=/selectionProcess[cache=current().name].name ].observationDomainId.floor() = /observationPoint[ selectionProcess=/selectionProcess[cache=current().name].name ].observationDomainId.ceil()" { description "For configurations where there are no cascaded Selection Processes between Observation Points and this Cache, the must statement ensures that all Observation Points belong to the same Observation Domain."; } key name; description "Parameters of a Cache."; leaf name { type string; } ... } Maybe you can help me. Thanks, Gerhard --------------ms040302070607040004090706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzAxMTYzMDI4WjAjBgkqhkiG9w0BCQQxFgQU 43LpxxJYffhpCNHV4nIabOa1C6MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAFgeIG96ptLd/hx2DKR4wARZP/SOAKoWxng2gXtN0jWPQVvF XUbiXgjNy+A4AX56rgLfUfeHyoKctT+eGjXVeY3Wf93e2WgtSZOlFDXydiraTpwtq6CUh9eV M2Vr8yU5AiNd1dy68IWPo9s7yeT5V7qk5wX7iVO2NH6JgR9gfFhQx0MzPcTeCy1lohtPbO7f 0oAPdncz3Df41BN3QZhAFdBo9rYDvkZ1Qc4LOD1tpzyRv9bk7/C8lgh044fE9RYJKZcYxGPl xg45GSRI7b3OmE0fbnJ1Zc7t8k/i//F7AYbjLslXGA3TGr4zaNeN65gCIAOocVsJU0GPbly1 aXo/yXcAAAAAAAA= --------------ms040302070607040004090706-- From andy@netconfcentral.com Wed Jul 1 12:12:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A718D3A67E4 for ; Wed, 1 Jul 2009 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 sTbUo0dawctA for ; Wed, 1 Jul 2009 12:12:19 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 7F8B528C4FC for ; Wed, 1 Jul 2009 12:09:01 -0700 (PDT) Received: from [68.142.194.244] by n10.bullet.mail.mud.yahoo.com with NNFMP; 01 Jul 2009 19:09:02 -0000 Received: from [68.142.201.73] by t2.bullet.mud.yahoo.com with NNFMP; 01 Jul 2009 19:09:02 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 01 Jul 2009 19:09:02 -0000 X-Yahoo-Newman-Id: 146775.20191.bm@omp425.mail.mud.yahoo.com Received: (qmail 63875 invoked from network); 1 Jul 2009 19:09:01 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 1 Jul 2009 19:09:01 -0000 X-YMail-OSG: eHnKVp8VM1kxuOnwYKb_bC_kqOIjfMvWjn9eA87WvgbG3UuLehDvYOGa9nzsz8.0BEc9blH1fHdYEp0LWXTG_Sjz8nSQagXdX9WKj3jDaE3MCRVwYXkuD2OZTFRQH0d9ZYmRcyKlzMxMi6c5FBk3nIHk6mlETfSnDI69k_hiaZnHqlSHFkWH_BW6gLh0K0TyaNkZwBuBGJrerROYNxwUSMcgZXpAb0yIHibuP59NSyhHXRrZRNXDzO7tdKIbX6Qbq1CyMJCK9fq1_f4SuFv4n6naIdmHXh2kLb2rnbt9GauDR7EiN_34 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4BB3BF.50004@netconfcentral.com> Date: Wed, 01 Jul 2009 12:06:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Gerhard Muenz References: <4A4B8F24.2040602@net.in.tum.de> In-Reply-To: <4A4B8F24.2040602@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Wed, 01 Jul 2009 19:12:20 -0000 Gerhard Muenz wrote: > Hi, > > I try to specify some restrictions regarding leafref values with a must > statement in the IPFIX configuration model. > > Here's the part of the YANG spec: > > list observationPoint { > key name; > leaf name { type string; } > leaf observationDomainId { > type uint32; > mandatory true; > } > ... > leaf-list selectionProcess { > type leafref { path "/ipfix/selectionProcess/name"; } > } > } > > list selectionProcess { > must "/observationPoint[selectionProcess=current().name] > .observationDomainId.floor() = > /observationPoint[selectionProcess=current().name] > .observationDomainId.ceil()" { > description "If the input of this Selection Process is an > Observed Packet Stream originating from different > Observation Points, the must statement ensures that all > Observation Points belong to the same Observation Domain."; > } > key name; > leaf name { type string; } > ... > } > > The goal is that all elements of the observationPoint list referring to > one specific element of the selectionProcess list must have the same > observationDomainId value. I tried to restrict this by enforcing > observationDomainId.ceil() = observationDomainId.floor() for the > corresponding observationPoint elements. > > I'm not sure if the XPath expression is correct. > > Also, I would like to know which result the must statement returns if > there are no observationPoint elements at all, or if no observationPoint > is referring to the given selectionProcess element. > > Is it possible to have nested "[]" in the XPath? > > Because I have also something more weired in the cache list: > > list cache { > if-feature meter; > must "/observationPoint[ > selectionProcess=/selectionProcess[cache=current().name].name > ].observationDomainId.floor() = /observationPoint[ > selectionProcess=/selectionProcess[cache=current().name].name > ].observationDomainId.ceil()" { > description "For configurations where there are no cascaded > Selection Processes between Observation Points and this Cache, > the must statement ensures that all Observation Points belong > to the same Observation Domain."; > } > key name; > description "Parameters of a Cache."; > leaf name { type string; } > ... > } > > > Maybe you can help me. > Aren't both of these lists under /ipfix? These XPath expressions assume that is the case. Not sure if this is correct, but maybe this is what you had in mind: list observationPoint { key name; leaf name { type string; } leaf observationDomainId { type uint32; mandatory true; } ... leaf-list selectionProcess { type leafref { path "/ipfix/selectionProcess/name"; } } } list selectionProcess { must "floor(/ipfix/observationPoint[name=current()/name]/observationDomainId) = ceil(/ipfix/observationPoint[name=current()/name]/observationDomainId)" { description "If the input of this Selection Process is an Observed Packet Stream originating from different Observation Points, the must statement ensures that all Observation Points belong to the same Observation Domain."; } key name; leaf name { type string; } ... } list cache { if-feature meter; must "floor(/ipfix/observationPoint[selectionProcess[. = current()/name]]/observationDomainId) = ceil(/ipfix/observationPoint[selectionProcess[. = current()/name]]/observationDomainId)" { description "For configurations where there are no cascaded Selection Processes between Observation Points and this Cache, the must statement ensures that all Observation Points belong to the same Observation Domain."; } key name; description "Parameters of a Cache."; leaf name { type string; } ... } > Thanks, > Gerhard > Andy From mbj@tail-f.com Wed Jul 1 13:52:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E693A6AD6 for ; Wed, 1 Jul 2009 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.078, 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 opMgWCTa78R9 for ; Wed, 1 Jul 2009 13:52:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E53683A6A28 for ; Wed, 1 Jul 2009 13:52:41 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AEB2B76C49C; Wed, 1 Jul 2009 22:50:47 +0200 (CEST) Date: Wed, 01 Jul 2009 22:50:47 +0200 (CEST) Message-Id: <20090701.225047.168401569.mbj@tail-f.com> To: muenz@net.in.tum.de From: Martin Bjorklund In-Reply-To: <4A4B8F24.2040602@net.in.tum.de> References: <4A4B8F24.2040602@net.in.tum.de> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Wed, 01 Jul 2009 20:52:42 -0000 Gerhard Muenz wrote: > list selectionProcess { > must "/observationPoint[selectionProcess=current().name] > .observationDomainId.floor() = > /observationPoint[selectionProcess=current().name] > .observationDomainId.ceil()" { > description "If the input of this Selection Process is an > Observed Packet Stream originating from different > Observation Points, the must statement ensures that all > Observation Points belong to the same Observation Domain."; > } > key name; > leaf name { type string; } > ... > } > > The goal is that all elements of the observationPoint list referring to > one specific element of the selectionProcess list must have the same > observationDomainId value. I don't think this will be possible with XPath 1.0 in the data model you have. This is currently best described in text in the description clause. > I tried to restrict this by enforcing > observationDomainId.ceil() = observationDomainId.floor() for the > corresponding observationPoint elements. But observationDomainId is an integer, so ceiling() and floor() of an integer returns the same integer. > I'm not sure if the XPath expression is correct. Andy showed the correct syntax. > Also, I would like to know which result the must statement returns if > there are no observationPoint elements at all, or if no observationPoint > is referring to the given selectionProcess element. It returns false. > Is it possible to have nested "[]" in the XPath? Yes. /martin From jmh@joelhalpern.com Wed Jul 1 14:12:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD463A6EC7 for ; Wed, 1 Jul 2009 14:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtvcvhkT7DiZ for ; Wed, 1 Jul 2009 14:12:04 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5D3253A6EA1 for ; Wed, 1 Jul 2009 14:12:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BC7E443055D; Wed, 1 Jul 2009 14:12:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0A9A143051C; Wed, 1 Jul 2009 14:12:17 -0700 (PDT) Message-ID: <4A4BD12E.6000203@joelhalpern.com> Date: Wed, 01 Jul 2009 17:12:14 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Martin Bjorklund References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> In-Reply-To: <20090701.225047.168401569.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Wed, 01 Jul 2009 21:12:05 -0000 The interesting thing in Gerhard's example is that the MUST is really about a set of values, not about a single value. He is trying to use ceiling() and floor() to reduce the set of ids to a single id. If the largest and smallest id are the same, then only 1 id occurs in the list. However, this assumes that NETMOD XPATH can produce a list of nodes (values) to be passed to the function. I can't tell if this works, or not. These examples are a very different (but quite reasonable) use of MUST. They represent a constraint on a set, rather than a constraint on a single value. I wonder if one could write the constraint on the main list be writing a MUST that says either there is no other node in the list with the same selection function, or any other node in the list with the same selection has the same domainId. That would put the constraint where I suspect it belongs. Yours, Joel Martin Bjorklund wrote: > Gerhard Muenz wrote: ... >> I tried to restrict this by enforcing >> observationDomainId.ceil() = observationDomainId.floor() for the >> corresponding observationPoint elements. > > But observationDomainId is an integer, so ceiling() and floor() of an > integer returns the same integer. From andy@netconfcentral.com Wed Jul 1 14:20:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B063A6BD2 for ; Wed, 1 Jul 2009 14:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 G2C7hlUrD-yG for ; Wed, 1 Jul 2009 14:20:37 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id F0ECD3A6AF5 for ; Wed, 1 Jul 2009 14:20:36 -0700 (PDT) Received: from [68.142.194.244] by n18.bullet.mail.mud.yahoo.com with NNFMP; 01 Jul 2009 21:20:55 -0000 Received: from [68.142.201.252] by t2.bullet.mud.yahoo.com with NNFMP; 01 Jul 2009 21:20:55 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 01 Jul 2009 21:20:55 -0000 X-Yahoo-Newman-Id: 584019.83740.bm@omp413.mail.mud.yahoo.com Received: (qmail 18579 invoked from network); 1 Jul 2009 21:20:55 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 1 Jul 2009 21:20:54 -0000 X-YMail-OSG: hR1uhiwVM1mfVsLOpfxOYuLrbRZR3HUGyt0cGD9IZkHvSj5Gvvacu60UBnMLljOwal9HqY4s4li_jLtdVWbyNlMrE7hLpdDVkWGRKZ83JJFSdkU4BzyyvJAd1877eS0FBv8DZwl2XOFEcCTFjYpXB4rQDIPC5nmEe7uxM7oaO1dlcr8SJUOAWsU591hVY0uz_pFE_SdLWauJ2QQul8MRwrclj9WUDyOBg0WDaTOns0MUlX1Y2DPzAIyS0XS7qCdvTilmrVFiOiXv4.an9NaGABlqSzwvyRWFHuen0_5lw.uIUDrP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4BD322.4070902@netconfcentral.com> Date: Wed, 01 Jul 2009 14:20:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> In-Reply-To: <20090701.225047.168401569.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Wed, 01 Jul 2009 21:20:38 -0000 Martin Bjorklund wrote: > Gerhard Muenz wrote: >> list selectionProcess { >> must "/observationPoint[selectionProcess=current().name] >> .observationDomainId.floor() = >> /observationPoint[selectionProcess=current().name] >> .observationDomainId.ceil()" { >> description "If the input of this Selection Process is an >> Observed Packet Stream originating from different >> Observation Points, the must statement ensures that all >> Observation Points belong to the same Observation Domain."; >> } >> key name; >> leaf name { type string; } >> ... >> } >> >> The goal is that all elements of the observationPoint list referring to >> one specific element of the selectionProcess list must have the same >> observationDomainId value. > > I don't think this will be possible with XPath 1.0 in the data model > you have. This is currently best described in text in the description > clause. > >> I tried to restrict this by enforcing >> observationDomainId.ceil() = observationDomainId.floor() for the >> corresponding observationPoint elements. > > But observationDomainId is an integer, so ceiling() and floor() of an > integer returns the same integer. > yes -- I noticed that after I sent my email, so I wondered if it was a float by any chance, otherwise the floor() and ceil() functions were not what he wanted. The following will not work because it just checks if there is at least one entry (among all the entries with the same name) that hast the same observationDomainId as the first entry. (According to my understanding of XPath sec. 3.4) list selectionProcess { must "/ipfix/observationPoint[name=current()/name]/observationDomainId = /ipfix/observationPoint[1]/observationDomainId" { description "If the input of this Selection Process is an Observed Packet Stream originating from different Observation Points, the must statement ensures that all Observation Points belong to the same Observation Domain."; } key name; leaf name { type string; } ... } list cache { if-feature meter; must "/ipfix/observationPoint[selectionProcess[. = current()/name]]/observationDomainId = /ipfix/observationPoint[selectionProcess[1]]/observationDomainId" { description "For configurations where there are no cascaded Selection Processes between Observation Points and this Cache, the must statement ensures that all Observation Points belong to the same Observation Domain."; } key name; description "Parameters of a Cache."; leaf name { type string; } ... } Andy >> I'm not sure if the XPath expression is correct. > > Andy showed the correct syntax. > >> Also, I would like to know which result the must statement returns if >> there are no observationPoint elements at all, or if no observationPoint >> is referring to the given selectionProcess element. > > It returns false. > >> Is it possible to have nested "[]" in the XPath? > > Yes. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Wed Jul 1 15:25:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9243A6B0D for ; Wed, 1 Jul 2009 15:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.074, 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 IfG4meSZpDYm for ; Wed, 1 Jul 2009 15:25:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0826A3A6D73 for ; Wed, 1 Jul 2009 15:25:30 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 62AE176C49C; Thu, 2 Jul 2009 00:25:51 +0200 (CEST) Date: Thu, 02 Jul 2009 00:25:51 +0200 (CEST) Message-Id: <20090702.002551.216817369.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A4BD12E.6000203@joelhalpern.com> References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> <4A4BD12E.6000203@joelhalpern.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Wed, 01 Jul 2009 22:25:32 -0000 "Joel M. Halpern" wrote: > The interesting thing in Gerhard's example is that the MUST is really about a > set of values, not about a single value. He is trying to use ceiling() and > floor() to reduce the set of ids to a single id. If the largest and smallest > id are the same, then only 1 id occurs in the list. But that's not how these functions work. The in-parameter is a number, and in this example it is a nodeset. So the nodeset gets converted to a string (i.e. the first node's string value is used), which is then converted to a number. > However, this assumes that NETMOD XPATH can produce a list of nodes (values) to > be passed to the function. I can't tell if this works, or not. NETMOD uses normal XPath 1.0. > These examples are a very different (but quite reasonable) use of MUST. They > represent a constraint on a set, rather than a constraint on a single value. I > wonder if one could write the constraint on the main list be writing a MUST > that says either there is no other node in the list with the same selection > function, or any other node in the list with the same selection has the same > domainId. That would put the constraint where I suspect it belongs. I think that this expression will work: list selectionProcess { must "count(/ipfix/observationPoint[selectionProcess=current()/name]) = count(/ipfix/observationPoint [selectionProcess=current()/name] [observationDomainId=/ipfix/observationPoint [selectionProcess=current()/name][1]/ observationDomainId])"; It's pretty difficult to indent and read, but it says that: the number of observationPoint entries with a reference to this selectionProcess MUST equal the number of observationPoint entries with a reference to this selectionProcess, which has the same observationDomainId as the first of them /martin From Washam.Fan@huaweisymantec.com Wed Jul 1 19:11:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B623A6A46 for ; Wed, 1 Jul 2009 19:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.814, 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 uHaTHDrGVNtc for ; Wed, 1 Jul 2009 19:11:53 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 027A53A68D9 for ; Wed, 1 Jul 2009 19:09:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KM400ITKU030J90@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 02 Jul 2009 10:09:39 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KM400ETBU03FR00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 02 Jul 2009 10:09:39 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 02 Jul 2009 10:09:39 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 02 Jul 2009 10:09:39 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090702.002551.216817369.mbj@tail-f.com> References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 02:11:55 -0000 Hi, > I think that this expression will work: > > list selectionProcess { > must > > "count(/ipfix/observationPoint[selectionProcess=current()/name]) = > count(/ipfix/observationPoint > [selectionProcess=current()/name] > [observationDomainId=/ipfix/observationPoint > [selectionProcess=current()/name][1]/ > observationDomainId])"; I think there might be an alternative which looks more straight: list selectionProcess { must "max( /ipfix/observationPoint[selectionProcess=current()/name]/observationDomainId )= min( /ipfix/observationPoint[selectionProcess=current()/name]/observationDomainId ) " washam > It's pretty difficult to indent and read, but it says that: > > the number of observationPoint entries with a reference to this > selectionProcess > MUST equal > the number of observationPoint entries with a reference to this > selectionProcess, which has the same observationDomainId as the > first of them > > > /martin From mbj@tail-f.com Wed Jul 1 23:19:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D143A6A26 for ; Wed, 1 Jul 2009 23:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.082, 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 ZrNvtRScz7Ir for ; Wed, 1 Jul 2009 23:19:40 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CAD903A6CDA for ; Wed, 1 Jul 2009 23:19:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E2ABD76C52D; Thu, 2 Jul 2009 08:20:00 +0200 (CEST) Date: Thu, 02 Jul 2009 08:20:00 +0200 (CEST) Message-Id: <20090702.082000.190027935.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 06:19:40 -0000 Hi, WashamFan wrote: > I think there might be an alternative which looks more straight: > > list selectionProcess { > must > "max( > /ipfix/observationPoint[selectionProcess=current()/name]/observationDomainId > )= min( > /ipfix/observationPoint[selectionProcess=current()/name]/observationDomainId > ) > " This doesn't work, because there are no 'max' and 'min' functions in the XPath 1.0 Core Function Library. /martin From lhotka@cesnet.cz Thu Jul 2 00:58:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BD13A67B2 for ; Thu, 2 Jul 2009 00:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=0.363, 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 COBZ-KFtsWlM for ; Thu, 2 Jul 2009 00:58:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 32A373A6B33 for ; Thu, 2 Jul 2009 00:58:38 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 325A5D800C5; Thu, 2 Jul 2009 09:58:59 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A4B7768.3090708@netconfcentral.com> References: <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> <1246428199.6491.18.camel@missotis> <20090701.090224.50024147.mbj@tail-f.com> <1246434352.6491.49.camel@missotis> <4A4B7768.3090708@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 02 Jul 2009 09:58:58 +0200 Message-Id: <1246521538.6561.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Thu, 02 Jul 2009 07:58:40 -0000 Andy Bierman píše v St 01. 07. 2009 v 07:49 -0700: > This is worse than what we have now. > Although it is possible to construct corner-cases > that are confusing to the naked eye, they are not > confusing to the software that is processing groupings. > > The rule for prefixes is rather simple now, > and it should stay that way. So what is this simple rule? > > It is critical that groupings remain transparent to > the protocol. It would be a disaster to have > a must-stmt or a default for an identityref work > one way in plain YANG, but another way if the > DM writer cut-and-paste those objects into a > grouping, and replaced them with a uses-stmt > for that grouping. > > E.g., > > leaf X { type string; } > > must always be equivalent to > > grouping A { > leaf X { type string; } > } > > uses A; > > for any grouping with any contents. > My rules would not break this. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From muenz@net.in.tum.de Thu Jul 2 05:58:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB093A6D47 for ; Thu, 2 Jul 2009 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=-0.253, 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 pyROWdXZKduO for ; Thu, 2 Jul 2009 05:58:09 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 3D3B43A6D53 for ; Thu, 2 Jul 2009 05:58:09 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 342D848449; Thu, 2 Jul 2009 14:58:22 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 223CB509D; Thu, 2 Jul 2009 14:58:22 +0200 (CEST) Message-ID: <4A4CAF51.5070201@net.in.tum.de> Date: Thu, 02 Jul 2009 15:00:01 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Martin Bjorklund References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> In-Reply-To: <20090702.002551.216817369.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 12:58:10 -0000 Dear all, Thank you very much for your feedback. Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> The interesting thing in Gerhard's example is that the MUST is really about a >> set of values, not about a single value. He is trying to use ceiling() and >> floor() to reduce the set of ids to a single id. If the largest and smallest >> id are the same, then only 1 id occurs in the list. > > But that's not how these functions work. The in-parameter is a > number, and in this example it is a nodeset. So the nodeset gets > converted to a string (i.e. the first node's string value is used), > which is then converted to a number. Yes, I misunderstood the ceil() and floor() functions. >> However, this assumes that NETMOD XPATH can produce a list of nodes (values) to >> be passed to the function. I can't tell if this works, or not. > > NETMOD uses normal XPath 1.0. > >> These examples are a very different (but quite reasonable) use of MUST. They >> represent a constraint on a set, rather than a constraint on a single value. I >> wonder if one could write the constraint on the main list be writing a MUST >> that says either there is no other node in the list with the same selection >> function, or any other node in the list with the same selection has the same >> domainId. That would put the constraint where I suspect it belongs. > > I think that this expression will work: > > list selectionProcess { > must > "count(/ipfix/observationPoint[selectionProcess=current()/name]) = > count(/ipfix/observationPoint > [selectionProcess=current()/name] > [observationDomainId=/ipfix/observationPoint > [selectionProcess=current()/name][1]/ > observationDomainId])"; > > It's pretty difficult to indent and read, but it says that: > > the number of observationPoint entries with a reference to this > selectionProcess > MUST equal > the number of observationPoint entries with a reference to this > selectionProcess, which has the same observationDomainId as the > first of them Great, thanks a lot. That should work. And it seems to be robust against non-existing observationPoints, right? Then, both count() should return zero. I'll try to adopt this scheme for the second must condition as well. Are there tools that are able to validate an XML document against these must rules? Regards, Gerhard From mbj@tail-f.com Thu Jul 2 06:38:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604E93A6A4A for ; Thu, 2 Jul 2009 06:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, 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 FTacXzFmQ1yJ for ; Thu, 2 Jul 2009 06:38:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9E3D13A6906 for ; Thu, 2 Jul 2009 06:38:29 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A6BC76C52D; Thu, 2 Jul 2009 15:38:50 +0200 (CEST) Date: Thu, 02 Jul 2009 15:38:50 +0200 (CEST) Message-Id: <20090702.153850.26942210.mbj@tail-f.com> To: muenz@net.in.tum.de From: Martin Bjorklund In-Reply-To: <4A4CAF51.5070201@net.in.tum.de> References: <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> <4A4CAF51.5070201@net.in.tum.de> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 13:38:30 -0000 Gerhard Muenz wrote: > And it seems to be robust against non-existing observationPoints, right? > Then, both count() should return zero. Yes. > I'll try to adopt this scheme for the second must condition as well. > > Are there tools that are able to validate an XML document against these > must rules? Ladislav works on the DSDL mapping in pyang. You can use pyang to generate schemas which then can be used to validate instance documents. I'm not sure if it handles must expressions yet. /martin From andy@netconfcentral.com Thu Jul 2 07:27:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1715B28C139 for ; Thu, 2 Jul 2009 07:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 iG4IjJm8aQoS for ; Thu, 2 Jul 2009 07:27:05 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 94F0228C232 for ; Thu, 2 Jul 2009 07:26:37 -0700 (PDT) Received: (qmail 69945 invoked from network); 2 Jul 2009 14:26:56 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 2 Jul 2009 14:26:56 -0000 X-YMail-OSG: 42eN.9cVM1lFwV39IQV8EMq46gX8Q4EHdfvM.dHsZq0QlIqwwuXQyISt0hrlPSwWgcpiCn1OxVLtIMQOpKfcQpIOaXbj7UXr7WV7pF1MPD07fJ_VFdt7tMxL6HEerJHiTrswy1K9fS8fr2FStpnm2x4hHxEpPb_jJQfr3EtVIhdqSUUxUjWSX5a2RZSWVKmSuESN9VjFueRRnKoJjII2Od.DxcG5DkmEBqI8HtFmlP67aycuohvevO_YWmNxXyNDd3kx8rviTnxe3JuGVGuUyFHb5R7eX8NFvT.twTczwh.1gKZQJ2eQUwWGnJf6vQM8A77DvS19bjZAfSTb4MsFHyeJyMbltrASUuUfAGuvx9WU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4CC398.9040900@netconfcentral.com> Date: Thu, 02 Jul 2009 07:26:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Gerhard Muenz References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> <4A4CAF51.5070201@net.in.tum.de> In-Reply-To: <4A4CAF51.5070201@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 14:27:06 -0000 Gerhard Muenz wrote: > Dear all, > > Thank you very much for your feedback. > > Martin Bjorklund wrote: >> "Joel M. Halpern" wrote: >>> The interesting thing in Gerhard's example is that the MUST is really about a >>> set of values, not about a single value. He is trying to use ceiling() and >>> floor() to reduce the set of ids to a single id. If the largest and smallest >>> id are the same, then only 1 id occurs in the list. >> But that's not how these functions work. The in-parameter is a >> number, and in this example it is a nodeset. So the nodeset gets >> converted to a string (i.e. the first node's string value is used), >> which is then converted to a number. > > Yes, I misunderstood the ceil() and floor() functions. > >>> However, this assumes that NETMOD XPATH can produce a list of nodes (values) to >>> be passed to the function. I can't tell if this works, or not. >> NETMOD uses normal XPath 1.0. >> >>> These examples are a very different (but quite reasonable) use of MUST. They >>> represent a constraint on a set, rather than a constraint on a single value. I >>> wonder if one could write the constraint on the main list be writing a MUST >>> that says either there is no other node in the list with the same selection >>> function, or any other node in the list with the same selection has the same >>> domainId. That would put the constraint where I suspect it belongs. >> I think that this expression will work: >> >> list selectionProcess { >> must >> "count(/ipfix/observationPoint[selectionProcess=current()/name]) = >> count(/ipfix/observationPoint >> [selectionProcess=current()/name] >> [observationDomainId=/ipfix/observationPoint >> [selectionProcess=current()/name][1]/ >> observationDomainId])"; >> >> It's pretty difficult to indent and read, but it says that: >> >> the number of observationPoint entries with a reference to this >> selectionProcess >> MUST equal >> the number of observationPoint entries with a reference to this >> selectionProcess, which has the same observationDomainId as the >> first of them > > Great, thanks a lot. That should work. > > And it seems to be robust against non-existing observationPoints, right? > Then, both count() should return zero. > > I'll try to adopt this scheme for the second must condition as well. > > Are there tools that are able to validate an XML document against these > must rules? > if, by XML document, you mean NETCONF PDU, then yes, although beta-level. I think you could run xsltproc against dummy config files, using a simple transform to see if the expression matched anything. I have some test scripts somewhere for checking 'select' strings against an instance document, if you need examples. > Regards, > Gerhard Andy From andy@netconfcentral.com Thu Jul 2 09:11:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2899828C157 for ; Thu, 2 Jul 2009 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 z-aLyB6cFwor for ; Thu, 2 Jul 2009 09:11:51 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 836CD28C0E9 for ; Thu, 2 Jul 2009 09:11:29 -0700 (PDT) Received: (qmail 95061 invoked from network); 2 Jul 2009 16:11:49 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 2 Jul 2009 16:11:49 -0000 X-YMail-OSG: dILNC3gVM1lAi.98p4e__pgF0zt14ItmUZPfLruEPCnUvSXgx4O8UkV8ODTSyepqqiTviJbSyh0Ft5bjX8n8FkZsaXrAoEoPGgolFS0eIKmRkdanCGCkg4J_aCfyIom0AWJmlxlFvaXWyE9Iq4ZllwPLAZasXgPhVNNB62tOVl8wWv4Apsb6rhzk.cb5t_jsAJoHc5uIrUOWiA70uEjJfKAXBLVBOl7SEjtV33vZHhLBQ3fJOnq0xJu414goRIe8AUZj636U_lr5MXbO X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4CDC44.1020205@netconfcentral.com> Date: Thu, 02 Jul 2009 09:11:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-06; 9.7.3 (bits ordering) 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: , X-List-Received-Date: Thu, 02 Jul 2009 16:11:52 -0000 Hi, I do not like the canonical ordering for the bits data type. It is based on the order the bit statements appear in the YANG file. It should be based on the 'position' number given explicitly or automatically in the bit-stmt. Otherwise, what is the point of the position sub-stmt? It is just another special description clause? It seems non-intuitive to the YANG writer as well. It seems from reading a YANG module (not 1 sentence buried on page 120 of a 173 page draft), that by setting the position, you are setting the canonical order. One would not guess that the position-stmt is merely ornamentation. Andy From muenz@net.in.tum.de Thu Jul 2 09:51:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2954C3A6B7C for ; Thu, 2 Jul 2009 09:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 BZtpriduUmyJ for ; Thu, 2 Jul 2009 09:51:51 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 6035C3A691B for ; Thu, 2 Jul 2009 09:51:50 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id CA3F448449; Thu, 2 Jul 2009 18:51:47 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B231F50B1; Thu, 2 Jul 2009 18:51:47 +0200 (CEST) Message-ID: <4A4CE607.1080409@net.in.tum.de> Date: Thu, 02 Jul 2009 18:53:27 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Andy Bierman References: <4A4B8F24.2040602@net.in.tum.de> <20090701.225047.168401569.mbj@tail-f.com> <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> <4A4CAF51.5070201@net.in.tum.de> <4A4CC398.9040900@netconfcentral.com> In-Reply-To: <4A4CC398.9040900@netconfcentral.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010908060205000501030202" X-Virus-Scanned: ClamAV using ClamSMTP Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 16:51:52 -0000 This is a cryptographically signed message in MIME format. --------------ms010908060205000501030202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Andy, Andy Bierman wrote: >> Are there tools that are able to validate an XML document against these >> must rules? >> > > if, by XML document, you mean NETCONF PDU, then yes, > although beta-level. > > I think you could run xsltproc against dummy config files, > using a simple transform to see if the expression matched anything. > I have some test scripts somewhere for checking 'select' strings > against an instance document, if you need examples. At the moment, I use pyang to generate an xsd which I use to validate my NETCONF PDU examples. must statements do not seem to be validated with this method. If you had a better tool or an XSLT file for xsltproc in order to do a more thorough validation of my configuration examples, I would appreciate if you could pass them to me. Thanks, Gerhard --------------ms010908060205000501030202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzAyMTY1MzI3WjAjBgkqhkiG9w0BCQQxFgQU nXeUpX9x9dbt45TVeGdtCQb/1TEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIfEWEl/dkeP20NIB9fFCPDNfPmUm+sxGTrOMuLG8opgkUxU 3IJKyU7yKZLkJR7lQyulXmKKkQj5wdVJe5pqmTmE41ojwjhdRDtw8l1D4g6WfmKZ+zNk8BHA zzAYa9sBJtz3SC+LyBciKSZWukbryWzhgbuE6Scmt0XByqejXlW0HKA9VFA8a032egayumCj j+U5hb3WVZ8UKbSoSP1okREzNibstEt0aYPpNxgGmvJ9BMtkuQYq40Q1WiHGWl09Y8UNJOX+ za7TDsNXUPrKvnIcK5C5dWeR4DzHDovLXjxW+xqO4tyg+0DXSO/eP5FYb4gaJ3U7KLPfWNQC i27V5rMAAAAAAAA= --------------ms010908060205000501030202-- From mbj@tail-f.com Thu Jul 2 09:51:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE353A6B2F for ; Thu, 2 Jul 2009 09:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.070, 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 noj8z0zI5H6g for ; Thu, 2 Jul 2009 09:51:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C5AE83A69BA for ; Thu, 2 Jul 2009 09:51:55 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D33E76C52D; Thu, 2 Jul 2009 18:52:01 +0200 (CEST) Date: Thu, 02 Jul 2009 18:52:01 +0200 (CEST) Message-Id: <20090702.185201.02713184.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A4CDC44.1020205@netconfcentral.com> References: <4A4CDC44.1020205@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-06; 9.7.3 (bits ordering) 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: , X-List-Received-Date: Thu, 02 Jul 2009 16:51:56 -0000 Andy Bierman wrote: > Hi, > > I do not like the canonical ordering for the bits data type. > It is based on the order the bit statements appear in the > YANG file. It should be based on the 'position' number > given explicitly or automatically in the bit-stmt. I agree. /martin From lhotka@cesnet.cz Thu Jul 2 10:27:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FAB3A6CF4 for ; Thu, 2 Jul 2009 10:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=0.351, 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 xZ655TljGB4i for ; Thu, 2 Jul 2009 10:27:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3502C3A6CE3 for ; Thu, 2 Jul 2009 10:27:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 87C2BD800C5; Thu, 2 Jul 2009 19:27:13 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090702.082000.190027935.mbj@tail-f.com> References: <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> <20090702.082000.190027935.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 02 Jul 2009 19:27:12 +0200 Message-Id: <1246555632.6805.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 17:27:13 -0000 Hi, the following should work: must "not(/ipfix/observationPoint[selectionProcess=current()/name] /observationDomainId[1] != /ipfix/observationPoint[selectionProcess=current()/name] /observationDomainId)" (none of the selected nodes may differ from the first one) Lada Martin Bjorklund píše v Čt 02. 07. 2009 v 08:20 +0200: > Hi, > > WashamFan wrote: > > I think there might be an alternative which looks more straight: > > > > list selectionProcess { > > must > > "max( > > /ipfix/observationPoint[selectionProcess=current()/name]/observationDomainId > > )= min( > > /ipfix/observationPoint[selectionProcess=current()/name]/observationDomainId > > ) > > " > > This doesn't work, because there are no 'max' and 'min' functions in > the XPath 1.0 Core Function Library. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Jul 2 10:40:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6517B28C270 for ; Thu, 2 Jul 2009 10:40:03 -0700 (PDT) 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 OeITUiJiclVG for ; Thu, 2 Jul 2009 10:40:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5EB7128C25F for ; Thu, 2 Jul 2009 10:38:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 13A4CD800C8; Thu, 2 Jul 2009 19:38:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090702.153850.26942210.mbj@tail-f.com> References: <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> <4A4CAF51.5070201@net.in.tum.de> <20090702.153850.26942210.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 02 Jul 2009 19:38:55 +0200 Message-Id: <1246556335.6805.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, muenz@net.in.tum.de Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 17:40:03 -0000 Martin Bjorklund píše v Čt 02. 07. 2009 v 15:38 +0200: > Gerhard Muenz wrote: > > And it seems to be robust against non-existing observationPoints, right? > > Then, both count() should return zero. > > Yes. > > > I'll try to adopt this scheme for the second must condition as well. > > > > Are there tools that are able to validate an XML document against these > > must rules? > > Ladislav works on the DSDL mapping in pyang. You can use pyang to > generate schemas which then can be used to validate instance > documents. I'm not sure if it handles must expressions yet. Yes, it does, it maps must expressions to Schematron asserts, except that the missing default namespace prefixes have to be added manually (sigh). By coincidence, just today I wrote a function which adds the necessary prefixes, so must expressions should be fully supported soon. The only remaining problem is the mapping of constraints imposed by instance-identifier type. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From muenz@net.in.tum.de Thu Jul 2 11:32:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C6128C164 for ; Thu, 2 Jul 2009 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 bq+oD3WG4d0C for ; Thu, 2 Jul 2009 11:32:03 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 5DD5D28C295 for ; Thu, 2 Jul 2009 11:31:46 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 0BC5847F33; Thu, 2 Jul 2009 20:32:02 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id E64CA509D; Thu, 2 Jul 2009 20:32:01 +0200 (CEST) Message-ID: <4A4CFD85.2010707@net.in.tum.de> Date: Thu, 02 Jul 2009 20:33:41 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A4BD12E.6000203@joelhalpern.com> <20090702.002551.216817369.mbj@tail-f.com> <20090702.082000.190027935.mbj@tail-f.com> <1246555632.6805.5.camel@missotis> In-Reply-To: <1246555632.6805.5.camel@missotis> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060407080402030001030905" X-Virus-Scanned: ClamAV using ClamSMTP Cc: netmod@ietf.org Subject: Re: [netmod] Condition in must statement 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: , X-List-Received-Date: Thu, 02 Jul 2009 18:32:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060407080402030001030905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lada, Thanks, this is even more simple. Gerhard Ladislav Lhotka wrote: > Hi, >=20 > the following should work: >=20 > must > "not(/ipfix/observationPoint[selectionProcess=3Dcurrent()/name] > /observationDomainId[1] !=3D > /ipfix/observationPoint[selectionProcess=3Dcurrent()/name] > /observationDomainId)" >=20 > (none of the selected nodes may differ from the first one) >=20 > Lada >=20 > Martin Bjorklund p=ED=9Ae v C(t 02. 07. 2009 v 08:20 +0200: >> Hi, >> >> WashamFan wrote: >>> I think there might be an alternative which looks more straight: >>> >>> list selectionProcess { >>> must >>> "max( >>> /ipfix/observationPoint[selectionProcess=3Dcurrent()/name]/observatio= nDomainId >>> )=3D min( >>> /ipfix/observationPoint[selectionProcess=3Dcurrent()/name]/observatio= nDomainId >>> ) >>> " >> This doesn't work, because there are no 'max' and 'min' functions in >> the XPath 1.0 Core Function Library. >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms060407080402030001030905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzAyMTgzMzQxWjAjBgkqhkiG9w0BCQQxFgQU mQ7dZJ/lQK1u1s1Qyp3vtm31tR0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBADlaubXBG2gTCuRjoUcG2QtJxoa6sY1wer4jJYwtF6QT2oKU hhZR501OSxglQcYRT/9UegvYipQywxaueTRfFpiM3hPcyVkvJs0ExGkY4FPKocImYvHAPESF mXIpO39fLZ5O1lefRNWSiQd7uyNsaWNXSia5x220aqhAZFjsTY04+L225If8BEVRMweazcL/ X5miZvWWXjq6bpABoVRomD0ZZncXgEB5mrhGzpOu0f1YovIdbK8Jo6iHIk7Sv+jstuXT4ISG miRkEDOJbMA1xACYTOnIZOpyDD6lTDhC43IR4238/8Ir3ej41wJXM8MOoGAMTLQ9OSpn44nO I5Ze+/UAAAAAAAA= --------------ms060407080402030001030905-- From muenz@net.in.tum.de Thu Jul 2 12:02:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768343A6D2A for ; Thu, 2 Jul 2009 12:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 oZIW0s5ilh5t for ; Thu, 2 Jul 2009 12:02:52 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id A85513A6A36 for ; Thu, 2 Jul 2009 12:02:52 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B4C3D48449 for ; Thu, 2 Jul 2009 21:02:06 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9DB24509D for ; Thu, 2 Jul 2009 21:02:06 +0200 (CEST) Message-ID: <4A4D0492.2020107@net.in.tum.de> Date: Thu, 02 Jul 2009 21:03:46 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [netmod] default value depending one some other parameter? 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: , X-List-Received-Date: Thu, 02 Jul 2009 19:03:20 -0000 Hi, I assume that it is not possible to specify a default value for a leaf which depends on the value or existence of another leaf/container? My use-case: The usual default port for IPFIX is 4739, however it's 4740 if DTLS or TLS is used. At the moment, I specify a default value of 4739, yet this is not what the user expects if he configures transport layer security. Regard, Gerhard From andy@netconfcentral.com Thu Jul 2 13:35:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90B83A6B38 for ; Thu, 2 Jul 2009 13:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 IJSmTZjAkjS7 for ; Thu, 2 Jul 2009 13:35:44 -0700 (PDT) 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 3AA7228C146 for ; Thu, 2 Jul 2009 13:35:20 -0700 (PDT) Received: (qmail 6707 invoked from network); 2 Jul 2009 20:35:31 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Jul 2009 20:35:31 -0000 X-YMail-OSG: nSnUPOEVM1lIWZyeeTwu05b23OyA_YKFY7WqHermSa7rXmYXgj3DTK2tJKNp.6aHCAhWcgnEALrFwVoblI8MUSMU341z_Val4.HuvDK7J7fChL0tZBhXX2XuqdxobPMAwbQovrMP03DZYfdxcp.bYhkgQQxhzgb8QknkkmQnNsciWCB71HBeD18VCkohG5uX.4QEaq3BbPtmkrih8.1rODYzS3__Ktm7PjsJCCmbiridXbMUy3R6ohS4rF38Gdn9nnLLbDtpzBnvvkErGj8qesu2hSQT.VF8yO4AnOagpjL72h7y7sry X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4D1A14.8010903@netconfcentral.com> Date: Thu, 02 Jul 2009 13:35:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Gerhard Muenz References: <4A4D0492.2020107@net.in.tum.de> In-Reply-To: <4A4D0492.2020107@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] default value depending one some other parameter? 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: , X-List-Received-Date: Thu, 02 Jul 2009 20:35:44 -0000 Gerhard Muenz wrote: > Hi, > > I assume that it is not possible to specify a default value for a leaf > which depends on the value or existence of another leaf/container? > > My use-case: The usual default port for IPFIX is 4739, however it's 4740 > if DTLS or TLS is used. > > At the moment, I specify a default value of 4739, yet this is not what > the user expects if he configures transport layer security. > no -- you cannot use the default-stmt. You need to put the details in the description-stmt. The NETCONF has different defaults depending on the capabilities supported. This sort of conditional default is too complicated for YANG 1.0. > Regard, > Gerhard Andy From mbj@tail-f.com Thu Jul 2 13:36:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5019628C146 for ; Thu, 2 Jul 2009 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.061, 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 ZSM3V6a6K0uB for ; Thu, 2 Jul 2009 13:36:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 92CAF28C12D for ; Thu, 2 Jul 2009 13:36:51 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 332DE76C52D; Thu, 2 Jul 2009 22:36:48 +0200 (CEST) Date: Thu, 02 Jul 2009 22:36:47 +0200 (CEST) Message-Id: <20090702.223647.12999120.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246442411.6491.94.camel@missotis> References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Thu, 02 Jul 2009 20:36:52 -0000 Ladislav Lhotka wrote: > prefix x; > > grouping foo { > container c { > must "x:a < ../x:above"; > leaf a { ... } > } > } > > it would be pretty confusing if the resolution of the same prefix "x" > was fixed for 'x:above' and postponed for 'x:a'. The point is that you cannot expect to do a simple text substitution when you implement 'uses'. For example, my module might import your module and some other module: import foo-module { prefix f; } import other-module { prefix x; } uses foo; The prefix "x" in the grouping must not be resolved in this context! This is no different for must expressions than for references to types or whatever. For example: grouping foo { typedef my-type { type int32; } container c { must "x:a < ../x:above"; leaf a { type x:my-type } // legal } } So I agree with Andy that the current rules work fine. /martin From lhotka@cesnet.cz Fri Jul 3 01:32:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849F73A6BAB for ; Fri, 3 Jul 2009 01:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=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 N3BEzeAYgDNz for ; Fri, 3 Jul 2009 01:32:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9A8FA3A6B30 for ; Fri, 3 Jul 2009 01:32:34 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2AA2DD800C5; Fri, 3 Jul 2009 10:32:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090702.223647.12999120.mbj@tail-f.com> References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 03 Jul 2009 10:32:56 +0200 Message-Id: <1246609976.6530.17.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 03 Jul 2009 08:32:35 -0000 Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: > Ladislav Lhotka wrote: > > prefix x; > > > > grouping foo { > > container c { > > must "x:a < ../x:above"; > > leaf a { ... } > > } > > } > > > > it would be pretty confusing if the resolution of the same prefix "x" > > was fixed for 'x:above' and postponed for 'x:a'. > > The point is that you cannot expect to do a simple text substitution > when you implement 'uses'. For example, my module might import your > module and some other module: > > import foo-module { > prefix f; > } > import other-module { > prefix x; > } > > uses foo; > > The prefix "x" in the grouping must not be resolved in this context! > This is no different for must expressions than for references to types > or whatever. For example: > > grouping foo { > typedef my-type { type int32; } > container c { > must "x:a < ../x:above"; > leaf a { type x:my-type } // legal > } > } This is all fine, the problem would arise when this grouping 'foo' is defined in 'other-module' and used in the local module via 'uses x:foo'. In the schema tree of the local module, 'a' now has the namespace URI of the local module, so if the prefix 'x' still corresponds to the NS URI of 'other-module' the 'x:a' name in the must statement cannot match leaf 'a', although with the rules that you stated earlier 'x:a' would match 'a' in 'other-module' where grouping 'foo' is defined. Lada > > > So I agree with Andy that the current rules work fine. > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Jul 9 21:26:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA223A6CBB for ; Thu, 9 Jul 2009 21:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYv2+wos-FEP for ; Thu, 9 Jul 2009 21:26:12 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id A06B33A6CB4 for ; Thu, 9 Jul 2009 21:26:11 -0700 (PDT) Received: from [68.142.200.226] by n20.bullet.mail.mud.yahoo.com with NNFMP; 10 Jul 2009 04:26:37 -0000 Received: from [68.142.201.243] by t7.bullet.mud.yahoo.com with NNFMP; 10 Jul 2009 04:26:37 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 10 Jul 2009 04:26:37 -0000 X-Yahoo-Newman-Id: 700034.10550.bm@omp404.mail.mud.yahoo.com Received: (qmail 11870 invoked from network); 10 Jul 2009 04:26:37 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 10 Jul 2009 04:26:37 -0000 X-YMail-OSG: VAofOaYVM1kWtMb6zCR5rEPjcRmBDZyVoJSuAHtPSHLDI2DnsElXQiJ_eU10GFlOv6QRoiy3FXBqnUSrB02a7cH6F1E9hSN1kjm6YEQFUUPsIZWPSjHWrZy5lZteWyCuqtVqR0C4LrB27OTeYCyskUbRIeeOEJ6LXyJ6iRHORR9RRhEZHjZHVZJAZnvyPAJ6RMYSyOAjtaTawObUsM8ui.1nhwZ7pYuU6NuYBLGZh2Mh8bxcO1EWXU3ogDWA14cP4VnwrzAfgDUHbGbu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A56C32F.7090400@netconfcentral.com> Date: Thu, 09 Jul 2009 21:27:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] choice-within-a-case 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: , X-List-Received-Date: Fri, 10 Jul 2009 04:26:14 -0000 Hi, I was re-reading the ABNF in yang-06 and I noticed that a choice-stmt is not allowed within a case-stmt. I thought I was using that and yangdump missed it, but no, I was using a choice from a grouping: grouping HelpMode { choice help-mode { default normal; leaf brief { type empty; } leaf normal { type empty; } leaf full { type empty; } } } rpc eventlog { input { choice event-action { case show-case { leaf show { type uint32; } leaf start { type uint32; } uses HelpMode; } leaf clear { type uint32; } } } } All my tools support this just fine. According to the yang-06 ABNF, all tools should. So why is there a CLR preventing choice-stmt from being used directly, but it is OK to use it from a grouping? Andy From mbj@tail-f.com Fri Jul 10 13:51:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660FF28C29D for ; Fri, 10 Jul 2009 13:51:51 -0700 (PDT) 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 Y42nWFpit+L3 for ; Fri, 10 Jul 2009 13:51:50 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9972A3A6E8A for ; Fri, 10 Jul 2009 13:51:50 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E32A76C545; Fri, 10 Jul 2009 22:52:17 +0200 (CEST) Date: Fri, 10 Jul 2009 22:52:17 +0200 (CEST) Message-Id: <20090710.225217.259050038.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A56C32F.7090400@netconfcentral.com> References: <4A56C32F.7090400@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice-within-a-case 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: , X-List-Received-Date: Fri, 10 Jul 2009 20:51:51 -0000 Hi, Andy Bierman wrote: > So why is there a CLR preventing choice-stmt from > being used directly, but it is OK to use it > from a grouping? The intention was not to allow it through a grouping either. But this cannot be expressed in the ABNF grammar, it has to go into the text. /martin From andy@netconfcentral.com Fri Jul 10 14:26:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904333A6834 for ; Fri, 10 Jul 2009 14:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 hRgxGrufKRrd for ; Fri, 10 Jul 2009 14:26:30 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 781F33A6804 for ; Fri, 10 Jul 2009 14:26:30 -0700 (PDT) Received: from [68.142.200.221] by n19.bullet.mail.mud.yahoo.com with NNFMP; 10 Jul 2009 21:26:55 -0000 Received: from [68.142.201.66] by t9.bullet.mud.yahoo.com with NNFMP; 10 Jul 2009 21:26:55 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 10 Jul 2009 21:26:55 -0000 X-Yahoo-Newman-Id: 881990.88603.bm@omp418.mail.mud.yahoo.com Received: (qmail 6413 invoked from network); 10 Jul 2009 21:26:55 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 10 Jul 2009 21:26:55 -0000 X-YMail-OSG: ysfXnLUVM1l_FctFcrvgs6pVbsrlWLw2GBy28P1MylswpVaeVQFaO0T84abslPRF85Z8.3Xlo83EBXstPv1AoFJaEdSOSKXEF5V4Nm28u9c8c70odO1QFKpuZh6q3_KXsOQrqfZYcshQJrSBA4tQdk4t7HyKILQqUe2Xw0Wcd8j9orUsiVogHclrPTUrGlKtENOysX9QGVQbi4Tv4fq9nYjZSNbr04oqZzux3wcvyzvmlfIcafJy_ttOpouR43P8OE0LplB2rLutqf3oX5KOxLg2OgJtzV2IWy6m9sf_hqe3SnmpokdyWWAn_WSYejDDKq7uzeN2Gdb.FQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A57B255.8020001@netconfcentral.com> Date: Fri, 10 Jul 2009 14:27:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A56C32F.7090400@netconfcentral.com> <20090710.225217.259050038.mbj@tail-f.com> In-Reply-To: <20090710.225217.259050038.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice-within-a-case 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: , X-List-Received-Date: Fri, 10 Jul 2009 21:26:31 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> So why is there a CLR preventing choice-stmt from >> being used directly, but it is OK to use it >> from a grouping? > > The intention was not to allow it through a grouping either. But this > cannot be expressed in the ABNF grammar, it has to go into the text. > I think it is a dumb CLR. I have already found more than one use case for allowing choice within a case. Why is the CLR needed? Should I just write in the YANG Usage Guidelines "You can't do this because the NETMOD WG says so, but they don't know why." Usually a CLR has some reason attached to it, that can be expressed in text, if not ABNF. > > /martin > Andy From bernd.linowski.ext@nsn.com Mon Jul 13 04:37:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A3728C401 for ; Mon, 13 Jul 2009 04:37:52 -0700 (PDT) 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 uDyK-Nc3u6kX for ; Mon, 13 Jul 2009 04:37:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4206028C40D for ; Mon, 13 Jul 2009 04:37:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6DBbbvZ028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Jul 2009 13:37:37 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6DBbbCq008506 for ; Mon, 13 Jul 2009 13:37:37 +0200 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 13:37:36 +0200 Received: from FIESEXC030.nsn-intra.net ([10.135.48.16]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 14:37:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA03AE.5188DB81" Date: Mon, 13 Jul 2009 14:37:34 +0300 Message-ID: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: Acn+btoWS1eL+Z4VR1OxW2XlWfkt7wFNG+mQAAK2uJA= From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: X-OriginalArrivalTime: 13 Jul 2009 11:37:36.0090 (UTC) FILETIME=[518D7BA0:01CA03AE] Subject: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Mon, 13 Jul 2009 11:37:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA03AE.5188DB81 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, please find below the -00 draft we submitted on "Extending YANG with Language Abstractions". This is an early draft and needs some discussion for further development. Please give us your comments. Regards, Bernd -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: Monday, July 06, 2009 9:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extending YANG with Language Abstractions Author(s) : B. Linowski, M. Ersue Filename : draft-linowski-netmod-yang-abstract-00.txt Pages : 42 Date : 2009-07-06 YANG - the NETCONF Data Modeling Language - supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests to enhance YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CA03AE.5188DB81 Content-Type: application/octet-stream; name="draft-linowski-netmod-yang-abstract-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-linowski-netmod-yang-abstract-00.URL Content-Disposition: attachment; filename="draft-linowski-netmod-yang-abstract-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saW5vd3NraS1uZXRtb2QteWFuZy1hYnN0cmFjdC0wMC50eHQNCg== ------_=_NextPart_001_01CA03AE.5188DB81 Content-Type: text/plain; name="ATT1065579.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1065579.txt Content-Disposition: attachment; filename="ATT1065579.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA03AE.5188DB81-- From root@core3.amsl.com Mon Jul 13 07:30:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B4D193A6A8A; Mon, 13 Jul 2009 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713143001.B4D193A6A8A@core3.amsl.com> Date: Mon, 13 Jul 2009 07:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-03.txt 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: , X-List-Received-Date: Mon, 13 Jul 2009 14:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-03.txt Pages : 106 Date : 2009-07-13 This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO 19757. The following DSDL schema languages are used by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF PDU etc. Procedures for schema- based validation of such documents are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-dsdl-map-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13071917.I-D@ietf.org> --NextPart-- From lhotka@cesnet.cz Mon Jul 13 07:37:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C265C28C318 for ; Mon, 13 Jul 2009 07:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=0.319, 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 L-Bns7s-hjXX for ; Mon, 13 Jul 2009 07:37:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7D60E28C198 for ; Mon, 13 Jul 2009 07:37:02 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0C0ABD800C5 for ; Mon, 13 Jul 2009 16:37:25 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090713143001.B4D193A6A8A@core3.amsl.com> References: <20090713143001.B4D193A6A8A@core3.amsl.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 13 Jul 2009 16:37:24 +0200 Message-Id: <1247495844.7578.3.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-03.txt 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: , X-List-Received-Date: Mon, 13 Jul 2009 14:37:04 -0000 Hi, this version of DSDL mapping draft corresponds to yang-06 (sometimes even -07 :-). Significant changes compared to -02 are mainly in DSRL-related stuff (mapping of default values). Lada Internet-Drafts@ietf.org píše v Po 13. 07. 2009 v 07:30 -0700: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > > Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content > Author(s) : L. Lhotka, et al. > Filename : draft-ietf-netmod-dsdl-map-03.txt > Pages : 106 > Date : 2009-07-13 > > This draft specifies the mapping rules for translating YANG data > models into Document Schema Definition Languages (DSDL), a > coordinated set of XML schema languages standardized as ISO 19757. > The following DSDL schema languages are used by the mapping: RELAX > NG, Schematron and DSRL. The mapping takes one or more YANG modules > and produces a set of DSDL schemas for a selected target document > type - datastore content, NETCONF PDU etc. Procedures for schema- > based validation of such documents are also discussed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Mon Jul 13 13:00:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 43E1F3A69FC; Mon, 13 Jul 2009 13:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713200001.43E1F3A69FC@core3.amsl.com> Date: Mon, 13 Jul 2009 13:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Mon, 13 Jul 2009 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-07.txt Pages : 175 Date : 2009-07-13 YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13124848.I-D@ietf.org> --NextPart-- From david.partain@ericsson.com Tue Jul 14 07:32:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736D33A6EF8 for ; Tue, 14 Jul 2009 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 qwSuTvGOWO2K for ; Tue, 14 Jul 2009 07:32:00 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 44F333A6EF4 for ; Tue, 14 Jul 2009 07:32:00 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-cc-4a5c96d29c38 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 72.63.02747.2D69C5A4; Tue, 14 Jul 2009 16:31:46 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jul 2009 14:15:00 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jul 2009 14:14:55 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 14 Jul 2009 14:14:55 +0200 User-Agent: KMail/1.9.10 References: <4A1DA01A.2090809@netconfcentral.com> <20090604104412.GC21823@elstar.local> <20090604.124937.28006847.mbj@tail-f.com> In-Reply-To: <20090604.124937.28006847.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907141414.55244.david.partain@ericsson.com> X-OriginalArrivalTime: 14 Jul 2009 12:14:55.0738 (UTC) FILETIME=[B2E665A0:01CA047C] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] varbinds instead of leafrefs in notifications 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: , X-List-Received-Date: Tue, 14 Jul 2009 14:32:01 -0000 On Thursday 04 June 2009 12.49.37 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jun 04, 2009 at 10:09:37AM +0200, Balazs Lengyel wrote: > > > I really liked Andy's varbind idea. Can we have this for > > > notifications? It is simple, elegant and solves a real use-case. It > > > will result in much less confusion then understanding leafrefs in > > > notifications, it is also much more compact especially for lists > > > with multiple keys or lists within lists. > > > > There are many questions that need to be asked about this new feature > > (and let us be clear that this is a new feature), such as: > > Yes, and as we think more and try to document it (and implement it!) > we will find new questions. I strongly prefer to postpone this new > feature. If we keep the current leafref and later find a beautiful > way to handle notifications, well the worst thing that happened is > that we get a deprecated use case for leafrefs. Hi all, No new features at this point... Much too close to "the end" of our first round of YANG fun. cheers, David From andy@netconfcentral.com Tue Jul 14 08:04:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16403A6982 for ; Tue, 14 Jul 2009 08:04:35 -0700 (PDT) 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 Kxsu00nTyMGo for ; Tue, 14 Jul 2009 08:04:35 -0700 (PDT) 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 B240A28C22E for ; Tue, 14 Jul 2009 08:04:31 -0700 (PDT) Received: (qmail 13669 invoked from network); 14 Jul 2009 15:04:21 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 14 Jul 2009 15:04:21 -0000 X-YMail-OSG: G7VMSfsVM1lpk1jweVh6.mBaM9V6a3xVcQKL0jcSNWD1D6okFHt0.TaveVPURF6_CnZCvLAul56TdAtFcYSbFOw7FkbGRezLBa5QQ5L8F8AVM1Kozxq15.4JMkR1KjSxkwoFFw_LMU6T0QZRzmVAbwiEPqfvrRAh0XDZ4go6Nqb2nKdbAs7UfPs0L_qvLIQeoIeMqjXpBiSJfjkVDVG2_OC9dHPou4JdInojZvl7HyR8qnH_W6RVSDyg4HBdBTd8Myv9rvdCM3elpouJvkADRRZs5tgioPUs81bw1owr_xrfTRFvsHAk1Tid6w4Ygfxrp2cXgevdmyzGBpnItUinpD6OYXwlnms- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5C9E74.7090609@netconfcentral.com> Date: Tue, 14 Jul 2009 08:04:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: David Partain References: <4A1DA01A.2090809@netconfcentral.com> <20090604104412.GC21823@elstar.local> <20090604.124937.28006847.mbj@tail-f.com> <200907141414.55244.david.partain@ericsson.com> In-Reply-To: <200907141414.55244.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] varbinds instead of leafrefs in notifications 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: , X-List-Received-Date: Tue, 14 Jul 2009 15:04:36 -0000 David Partain wrote: > On Thursday 04 June 2009 12.49.37 Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Jun 04, 2009 at 10:09:37AM +0200, Balazs Lengyel wrote: >>>> I really liked Andy's varbind idea. Can we have this for >>>> notifications? It is simple, elegant and solves a real use-case. It >>>> will result in much less confusion then understanding leafrefs in >>>> notifications, it is also much more compact especially for lists >>>> with multiple keys or lists within lists. >>> There are many questions that need to be asked about this new feature >>> (and let us be clear that this is a new feature), such as: >> Yes, and as we think more and try to document it (and implement it!) >> we will find new questions. I strongly prefer to postpone this new >> feature. If we keep the current leafref and later find a beautiful >> way to handle notifications, well the worst thing that happened is >> that we get a deprecated use case for leafrefs. > > Hi all, > > No new features at this point... Much too close to "the end" of our first > round of YANG fun. > Agreed. Next time around there will probably be some vendor extensions to choose from, when looking at new features to standardize. It has come to my attention that not everybody thinks the XPath filtering should return a full-blown XML tree. Some people would prefer the option of getting back a varbind list representing the XPath node-set result, instead of XML subtrees. (So, it's not just notifications that need varbinds.) > cheers, > > David Andy From david.partain@ericsson.com Wed Jul 15 05:44:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DA93A6AED for ; Wed, 15 Jul 2009 05:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_SE=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 Clm9+mtJfsSk for ; Wed, 15 Jul 2009 05:44:17 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0FC783A67B3 for ; Wed, 15 Jul 2009 05:43:43 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-f5-4a5dcee1eb3d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C1.9A.18827.1EECD5A4; Wed, 15 Jul 2009 14:43:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 14:42:04 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 14:42:04 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 15 Jul 2009 14:42:03 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907151442.03550.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Jul 2009 12:42:04.0090 (UTC) FILETIME=[A7E2F1A0:01CA0549] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] IETF 75 Agenda 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: , X-List-Received-Date: Wed, 15 Jul 2009 12:44:18 -0000 Hi, At http://www.ietf.org/proceedings/09jul/agenda/netmod.txt you will find the agenda for the NETMOD meetings at IETF75 in Stockholm. If you have comments, requests, corrections, flames, please let me know. I'll update the above link as needed. Cheers, David From david.partain@ericsson.com Wed Jul 15 12:05:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B419B3A6EA3 for ; Wed, 15 Jul 2009 12:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUsIeER8NYOv for ; Wed, 15 Jul 2009 12:05:03 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4938A3A69CD for ; Wed, 15 Jul 2009 12:05:01 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-d0-4a5df1ecfb00 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 7C.F8.18827.CE1FD5A4; Wed, 15 Jul 2009 17:12:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 17:11:15 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 17:11:15 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 15 Jul 2009 17:11:14 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907151711.14858.david.partain@ericsson.com> X-OriginalArrivalTime: 15 Jul 2009 15:11:15.0237 (UTC) FILETIME=[7F2F9550:01CA055E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Issues to be discussed in Stockholm 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: , X-List-Received-Date: Wed, 15 Jul 2009 19:05:03 -0000 Hi all, The agenda has all of the relevant documents to read for Stockholm. If you have issues that need to be discussed about a particular document, PLEASE bring them up on the mailing list _before_ Stockholm if at all possible. The architecture document is currently on the agenda, but that item will be very short unless someone brings up issues here (or at the microphone or on jabber). The same is true for the types document. Unless something strange happens in Stockholm, there will be a WG last call on the architecture document (http://tools.ietf.org/id/draft-ietf-netmod-arch-02.txt) directly after the IETF. Cheers, David From andy@netconfcentral.com Thu Jul 16 09:36:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66353A6891 for ; Thu, 16 Jul 2009 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.109, 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 EwFTdL1V5U97 for ; Thu, 16 Jul 2009 09:36:20 -0700 (PDT) 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 094813A6D60 for ; Thu, 16 Jul 2009 09:36:20 -0700 (PDT) Received: (qmail 50592 invoked from network); 16 Jul 2009 16:35:34 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 16 Jul 2009 16:35:34 -0000 X-YMail-OSG: PYrJkZgVM1mIFi5DN8NEHAKxY8C2NYAgvI_3cMA3g_tMCGjWB8MOW4mAvRIgPqz153y6OLmGgWkgYKQOV7_VFA2mAyAQCJH1Q.0OGZm7R1UPy2OIOtV2NLu81kHg.R1rtOWXnssCyn5HW8WvbP_LgNL9Jh0o1WKgONBXBxUXmFoGA44Zgfuw9BWAMrE2o_jFEY7wOLB_ur6sxV5O.H3aW84COxNZT_qThMpOJCulp4I18tHFNlg_D2tUirl87XJKhMfYv5OOV2h4GuAB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5F56D7.3090401@netconfcentral.com> Date: Thu, 16 Jul 2009 09:35:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-types-03: new 'date' type 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: , X-List-Received-Date: Thu, 16 Jul 2009 16:36:20 -0000 Hi, Since the revision-date is so important in YANG, I think ietf-yang-types.yang should have a 'date' typedef, not just 'date-and-time': typedef date { type string { pattern '\d{4}-\d{2}-\d{2}'; } description 'The date type is a profile of the ISO 8601 standard for representation of dates using the Gregorian calendar. The format is most easily described using the following ABFN (see RFC 3339): date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 full-date = date-fullyear "-" date-month "-" date-mday The date type is consistent with the semantics defined in RFC 3339. The date type is compatible with the dateTime XML schema type with the following notable exception: // *** [ed: Note that the preceding paragraph, and // *** 2 bullets (a) and (b) have typos in the // *** date-and-time version: // *** s/data-and-time/date-and-time/ ] (a) The date type does not allow negative years. '; reference "RFC 3339: Date and Time on the Internet: Timestamps RFC 2579: Textual Conventions for SMIv2 W3C REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes Second Edition"; } Andy From andy@netconfcentral.com Fri Jul 17 09:24:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1AD83A6896 for ; Fri, 17 Jul 2009 09:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI9Be39NOqC4 for ; Fri, 17 Jul 2009 09:24:45 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id AE62F3A68DE for ; Fri, 17 Jul 2009 09:24:15 -0700 (PDT) Received: (qmail 29478 invoked from network); 17 Jul 2009 16:24:46 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 17 Jul 2009 16:24:46 -0000 X-YMail-OSG: u8GsNc0VM1lcWxPblwpVN7f3r488aK_rp4Ssp3CRpwE7D5hUU.1QEcskRaxPMfI3s_dwq43VEDR7UQO4U78XLnGfiN_0RNVpg0py.q0GI5fk7ZxUgRr.FDGXd5AV1.CaT_30qj9YoTPPoiht0A98k68n.ZujFWD.434ThOYiPLOfFnU_Wy1nWxYBSMlncwRWtulYxx8tJy3so53TRiyOZ1dGidWPL0a2TObZjpfd4BtJfE2b3i1GeewlNs6WiQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A60A5D1.6050505@netconfcentral.com> Date: Fri, 17 Jul 2009 09:24:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Fri, 17 Jul 2009 16:24:46 -0000 Hi, Not sure if this is also a 4741bis issue... Let's say the agent loads a module at boot-time or run-time, and it immediately invalidates the config? (e.g., missing mandatory top-level node). Or the NV-startup contents are not valid for the set of loaded modules at boot-time? (e.g., missing or unknown data) It means that the operation on the config can fail, because agent implementations are likely to keep going, and let an operator fix things (may be partially disabled until this done). Crash-and-reboot-loop is a bad option, but I guess it is a valid implementation choice. The agent will not allow any to the to succeed unless the validate tests pass (SOP for ). It also means that the starts out invalid and the agent will not let any succeed until the problems with the validation have been fixed. Not sure what text (if any) needs to be written in the YANG draft. Andy From andy@netconfcentral.com Mon Jul 20 02:20:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D033A6A11 for ; Mon, 20 Jul 2009 02:20:55 -0700 (PDT) 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 kln4h3HRJosL for ; Mon, 20 Jul 2009 02:20:48 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id C86723A6C20 for ; Mon, 20 Jul 2009 02:20:48 -0700 (PDT) Received: (qmail 5694 invoked from network); 20 Jul 2009 09:20:01 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.84.111 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2009 09:20:01 -0000 X-YMail-OSG: V956JrMVM1mlnQLRh7R2eooQJQv_5s1WSadnQTWhbHs7rsDloJa6qOwO1Up21agnBkc8YldjIVsnwX1E7j.Ui7Wf4U.F4NkFih3yAzbkpGgYXRqzQkJYq8bRXcZvE7AgtirEGR2rgIBmUHpVEiPwhzeNpuwcUsy2IfPnGvY7iAbUEXoB4yS4l6ivaFt81t.gxTWDEaGBYFhNlhBoK_yhevnCeGrPsfVzWBfPTcKlSSyIwqj25Eiy_pMPsS9nJR7HQ3SpwCT3im.xJfhwUNOvw_xBN1_3W3IzsV3QEX.9uGmsyxkSR3D9aSUWCDvgzwxzSj8spfBVFPTi603B6l8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6436CA.6060109@netconfcentral.com> Date: Mon, 20 Jul 2009 02:20:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> In-Reply-To: <4A642DB9.5030301@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Mon, 20 Jul 2009 09:20:55 -0000 Balazs Lengyel wrote: > Hello, > We sad earlier that running must be always valid. Is that a YANG or a > NETCONF requirement on the server? So are we saying that if the has even 1 missing leaf in it, the NETCONF agent must shutdown and refuse to run? Since there is no access control on , this means if a hacker can somehow cause the to be invalid (by 1 leaf), and then cause the box to reboot, then the NETCONF standard mandates that the device is FUBAR until the operator replaces the somehow? What about loading modules are run-time? Add 1 mandatory leaf, and the box rolls over and dies? Without any chance for the operator to create the new leaf? > Balazs > Andy > Andy Bierman wrote: >> Hi, >> >> Not sure if this is also a 4741bis issue... >> >> Let's say the agent loads a module at boot-time or run-time, >> and it immediately invalidates the config? >> (e.g., missing mandatory top-level node). >> >> Or the NV-startup contents are not valid for the set >> of loaded modules at boot-time? (e.g., missing or unknown data) >> >> It means that the operation on the config >> can fail, because agent implementations are likely to keep >> going, and let an operator fix things (may be partially disabled >> until this done). Crash-and-reboot-loop is a bad option, >> but I guess it is a valid implementation choice. >> >> The agent will not allow any to the >> to succeed unless the validate tests pass (SOP for ). >> >> It also means that the starts out invalid and the >> agent will not let any succeed until the problems >> with the validation have been fixed. >> >> Not sure what text (if any) needs to be written in the YANG draft. >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From balazs.lengyel@ericsson.com Mon Jul 20 05:38:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706FC3A6D5B for ; Mon, 20 Jul 2009 05:38:24 -0700 (PDT) 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 CHBixDvFnvev for ; Mon, 20 Jul 2009 05:38:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4DA553A6C08 for ; Mon, 20 Jul 2009 05:38:18 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-03-4a642dbcf79e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CD.A7.00514.CBD246A4; Mon, 20 Jul 2009 10:41:32 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:40:11 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:40:10 +0200 Message-ID: <4A642D6A.1030303@ericsson.com> Date: Mon, 20 Jul 2009 10:40:10 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A60A5D1.6050505@netconfcentral.com> In-Reply-To: <4A60A5D1.6050505@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 08:40:10.0963 (UTC) FILETIME=[B1744230:01CA0915] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Mon, 20 Jul 2009 12:38:24 -0000 Hello, During NETMOD the discussions it was stated nomerous times, that the running configuration MUST be valid at all times; e.g. this is the reason we can't refer to state data in must expressions. While I am not totally happy with this, this was the latest news about running. Are we saying now that in some cases running might not be valid? Also I very strongly think, that if running is valid at all times this MUST be stated in YANG and/or in the architecture document. Actually it is a strong requirement on the NETCONF server by YANG, that it should keep running valid. Balazs Andy Bierman wrote: > Hi, > > Not sure if this is also a 4741bis issue... > > Let's say the agent loads a module at boot-time or run-time, > and it immediately invalidates the config? > (e.g., missing mandatory top-level node). > > Or the NV-startup contents are not valid for the set > of loaded modules at boot-time? (e.g., missing or unknown data) > > It means that the operation on the config > can fail, because agent implementations are likely to keep > going, and let an operator fix things (may be partially disabled > until this done). Crash-and-reboot-loop is a bad option, > but I guess it is a valid implementation choice. > > The agent will not allow any to the > to succeed unless the validate tests pass (SOP for ). > > It also means that the starts out invalid and the > agent will not let any succeed until the problems > with the validation have been fixed. > > Not sure what text (if any) needs to be written in the YANG draft. > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Mon Jul 20 05:38:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798873A6C08 for ; Mon, 20 Jul 2009 05:38:24 -0700 (PDT) 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 8D1d2oC4Ch8w for ; Mon, 20 Jul 2009 05:38:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6DB083A6D42 for ; Mon, 20 Jul 2009 05:38:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-fb-4a642dbb5bd1 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 5B.A7.00514.BBD246A4; Mon, 20 Jul 2009 10:41:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:41:30 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:41:29 +0200 Message-ID: <4A642DB9.5030301@ericsson.com> Date: Mon, 20 Jul 2009 10:41:29 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A60A5D1.6050505@netconfcentral.com> In-Reply-To: <4A60A5D1.6050505@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 08:41:29.0758 (UTC) FILETIME=[E06B6BE0:01CA0915] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Mon, 20 Jul 2009 12:38:24 -0000 Hello, We sad earlier that running must be always valid. Is that a YANG or a NETCONF requirement on the server? Balazs Andy Bierman wrote: > Hi, > > Not sure if this is also a 4741bis issue... > > Let's say the agent loads a module at boot-time or run-time, > and it immediately invalidates the config? > (e.g., missing mandatory top-level node). > > Or the NV-startup contents are not valid for the set > of loaded modules at boot-time? (e.g., missing or unknown data) > > It means that the operation on the config > can fail, because agent implementations are likely to keep > going, and let an operator fix things (may be partially disabled > until this done). Crash-and-reboot-loop is a bad option, > but I guess it is a valid implementation choice. > > The agent will not allow any to the > to succeed unless the validate tests pass (SOP for ). > > It also means that the starts out invalid and the > agent will not let any succeed until the problems > with the validation have been fixed. > > Not sure what text (if any) needs to be written in the YANG draft. > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Mon Jul 20 08:43:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E0C3A6AC3 for ; Mon, 20 Jul 2009 08:43:59 -0700 (PDT) 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 CUQDC1MgGNV1 for ; Mon, 20 Jul 2009 08:43:52 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 0958D3A65A6 for ; Mon, 20 Jul 2009 08:43:43 -0700 (PDT) Received: (qmail 81685 invoked from network); 20 Jul 2009 15:43:41 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.84.111 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2009 15:43:41 -0000 X-YMail-OSG: G0v09rIVM1mRpWH.0UU75A0J3gsP4IXBcwp6rE9V0VFXdwq_BWKBZpUjm0JkT06U_AV1tOO0YpkJ3uhlqNc4pzPqGH49ep.g7FvR.tIX6UTOc75ppvxwXPHdHqC6eSvGpsMIdDyV6Pg8jVTTHgQJOSNJ9ttyTTpIEycVLlLmJshrH.Kw2kR4Yncna1RCYAPcv6fkZdHCeA74MyttMlppcPz9egYiG_MhbnQRVEeHdfxk9ZInZY2JxDeCQqeMEpALZ2qdqTrLRb_XOyd1mhIYe_I.ukY_1OORYntSFta_1h0sO8w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A649038.70303@netconfcentral.com> Date: Mon, 20 Jul 2009 08:41:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> In-Reply-To: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Mon, 20 Jul 2009 15:43:59 -0000 Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > Hi All, > > please find below the -00 draft we submitted on "Extending YANG with > Language Abstractions". > This is an early draft and needs some discussion for further > development. > Please give us your comments. > The new constructs that are proposed seem to overlap the YANG grouping and uses statements a great deal. Before YANG, I implemented something called NCX which had complex types, and every node had a type. Every node also formed a containment layer, even choices, because the type was a complete abstraction, and what if it changed from a list to a choice? I found that the complexity level in the agent callback structure went up a lot because of this abstraction. At first I did not like YANG groupings, because they are so much more fragile and 'hands-on' than complex types. You must control the containment layering and refinements. It is not handled automatically like with complex types. But now I think that groupings are more appropriate for embedded systems, and align better with traditional agent callback design. > Regards, > Bernd > Andy > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Monday, July 06, 2009 9:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Extending YANG with Language Abstractions > Author(s) : B. Linowski, M. Ersue > Filename : draft-linowski-netmod-yang-abstract-00.txt > Pages : 42 > Date : 2009-07-06 > > YANG - the NETCONF Data Modeling Language - supports modeling of a > tree of data elements that represent the configuration and runtime > status of a particular network element managed via NETCONF. This > memo suggests to enhance YANG with supplementary modeling features > and language abstractions with the aim to improve the model > extensibility and reuse. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- > 00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Mon Jul 20 14:39:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4923A6DD6 for ; Mon, 20 Jul 2009 14:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 N7N7B82l+7Su for ; Mon, 20 Jul 2009 14:39:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A9EB33A6DE4 for ; Mon, 20 Jul 2009 14:38:59 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F63F616017; Mon, 20 Jul 2009 23:38:30 +0200 (CEST) Date: Mon, 20 Jul 2009 23:38:29 +0200 (CEST) Message-Id: <20090720.233829.201993099.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6436CA.6060109@netconfcentral.com> References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Mon, 20 Jul 2009 21:39:02 -0000 Hi, Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello, > > We sad earlier that running must be always valid. Is that a YANG or a > > NETCONF requirement on the server? > > > So are we saying that if the > has even 1 missing leaf in it, the NETCONF > agent must shutdown and refuse to run? Short answer: Yes. I can't see how an agent can start with an invalid config in the general case. In your simple example, somewhere in the code someone expects this mandatory leaf to exist, and behave accordingly. If the code can start without this leaf, it wasn't mandatory - the code obviously took some default action. This should be reflected in the data model. > Since there is no access control on , What? Where is this specified? > this means if a hacker can somehow cause the > to be invalid (by 1 leaf), and > then cause the box to reboot, then the NETCONF > standard mandates that the device is FUBAR > until the operator replaces the somehow? If there is no access control on startup, a hacker can do much more damage than this... > What about loading modules are run-time? > Add 1 mandatory leaf, and the box rolls over and dies? > Without any chance for the operator to create the new leaf? If we say that running MAY be invalid, i.e. that the box is supposed to run with any invalid config, what is the purpose of the validation anyway? /martin From balazs.lengyel@ericsson.com Tue Jul 21 02:00:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701403A6BFB for ; Tue, 21 Jul 2009 02:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.684 X-Spam-Level: X-Spam-Status: No, score=-3.684 tagged_above=-999 required=5 tests=[AWL=-2.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=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 cXyIDC2nZp6i for ; Tue, 21 Jul 2009 02:00:28 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 757A93A684A for ; Tue, 21 Jul 2009 02:00:28 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-13-4a6583a2bab0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 5F.61.18827.2A3856A4; Tue, 21 Jul 2009 11:00:18 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 10:59:03 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 10:59:02 +0200 Message-ID: <4A658356.2040208@ericsson.com> Date: Tue, 21 Jul 2009 10:59:02 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 08:59:03.0044 (UTC) FILETIME=[7EA3DC40:01CA09E1] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] How to make something optional? 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: , X-List-Received-Date: Tue, 21 Jul 2009 09:00:29 -0000 Hello, We have at least three ways to make standard functions optional. Some guidance would be needed when to use capabilities (like the notification rfc), when to use optional modules (like the monitoring draft) and when to use YANG features. IMO should go into the usage guidelines doc. Balazs From andy@netconfcentral.com Tue Jul 21 05:02:33 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE8B3A6859 for ; Tue, 21 Jul 2009 05:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=1.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 zd6HX9lnQ3Kh for ; Tue, 21 Jul 2009 05:02:27 -0700 (PDT) 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 371973A67D9 for ; Tue, 21 Jul 2009 05:02:27 -0700 (PDT) Received: (qmail 8605 invoked from network); 21 Jul 2009 12:01:05 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.142.220 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 21 Jul 2009 12:01:04 -0000 X-YMail-OSG: 5w2DZesVM1nmh4adLh4L3iI2Q1M0ytpmQUa8w9FO4LkUnKKwCyGyCW_VE3ulWwYXHj4D0xeXzKAzrAcPQkkODKn3cPK0dw33Twf4mswkpW.Wa_qUKTiF_h_DzdXdjKZNdSsjArGnFwfc_vc476mQiapzg_biSbZiZXsBsgfUmgnsaQlSxIFER.fejTAqJ8EYeDQzaCvhvcfJ.a1Fesu5c3LoS7y4P0nvZJEuX9YP3xXLSXvUXmVHXTy_GAI6Rjd_DTofGmaD.ir.KiddXtJA1eiOSAMtDSnZ2d_9vwO2IQo9oKcszYhHz6a3SqrHatr.yqBerUN_vdq1eQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A65AD95.4090404@netconfcentral.com> Date: Tue, 21 Jul 2009 04:59:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> In-Reply-To: <20090720.233829.201993099.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 12:02:33 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> We sad earlier that running must be always valid. Is that a YANG or a >>> NETCONF requirement on the server? >> >> So are we saying that if the >> has even 1 missing leaf in it, the NETCONF >> agent must shutdown and refuse to run? > > Short answer: Yes. > > I can't see how an agent can start with an invalid config in the > general case. In your simple example, somewhere in the code someone > expects this mandatory leaf to exist, and behave accordingly. If the > code can start without this leaf, it wasn't mandatory - the code > obviously took some default action. This should be reflected in the > data model. > How come CLI-based routers don't won't this way? Could it be because this is way too fragile? I can't see how a YANG module with a mandatory top-level node in it can ever be deployed in a real system. By definition, it means the manager MUST set the node. The agent is NOT ALLOWED to set it. So once the module is loaded into the system, the agent is dead. I don't see how config and new modules are kept in perfect alignment, within a single protocol operation. Andy >> Since there is no access control on , > > What? Where is this specified? > >> this means if a hacker can somehow cause the >> to be invalid (by 1 leaf), and >> then cause the box to reboot, then the NETCONF >> standard mandates that the device is FUBAR >> until the operator replaces the somehow? > > If there is no access control on startup, a hacker can do much more > damage than this... > >> What about loading modules are run-time? >> Add 1 mandatory leaf, and the box rolls over and dies? >> Without any chance for the operator to create the new leaf? > > If we say that running MAY be invalid, i.e. that the box is supposed > to run with any invalid config, what is the purpose of the validation > anyway? > > > /martin > From andy@netconfcentral.com Tue Jul 21 05:43:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9107F28C226 for ; Tue, 21 Jul 2009 05:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 NCjli8TYjbCI for ; Tue, 21 Jul 2009 05:43:16 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id D6A8D28C0EC for ; Tue, 21 Jul 2009 05:43:16 -0700 (PDT) Received: (qmail 60404 invoked from network); 21 Jul 2009 12:36:17 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.142.220 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 21 Jul 2009 12:36:16 -0000 X-YMail-OSG: _GXSznQVM1ndXS8ES0suzlJejPBXUslOCRlY3FU2PuTy249F.bzvs9pMW4PyKSJnhilIzRdR_SoGc1LO4nO.MLxq3Pd5ZqiDdrpbqGAb5QQTIAreA0nNhn1pbUN4Y1F4_Xb5roc27.3YO6bLK8.P2p_9QvMi1WZNarbvvZYTEr7dIsgT68FabF0VQDSEMQxolcr8LMNWUpzMBSFfvcO6NBd3A9x1GSHHu48DPwaw9Jfpsh.gyq6Mw3N2boN7wPQvSNetvdvTo9jppnwaXlSOKp6F.Dn9sC6qEeLSWmWgBUWWNJVxdQUhwaPh5UbW7tyJvRE7T_z.0Xdw60B.ZpIvjt1ILKkdRc1ZB79UxVo6Hp6MUd8EeA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A65B5D4.6070904@netconfcentral.com> Date: Tue, 21 Jul 2009 05:34:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> <20090721.141026.165403245.mbj@tail-f.com> In-Reply-To: <20090721.141026.165403245.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 12:43:17 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> >>> Andy Bierman wrote: >>>> Balazs Lengyel wrote: >>>>> Hello, >>>>> We sad earlier that running must be always valid. Is that a YANG or a >>>>> NETCONF requirement on the server? >>>> So are we saying that if the >>>> has even 1 missing leaf in it, the NETCONF >>>> agent must shutdown and refuse to run? >>> Short answer: Yes. >>> >>> I can't see how an agent can start with an invalid config in the >>> general case. In your simple example, somewhere in the code someone >>> expects this mandatory leaf to exist, and behave accordingly. If the >>> code can start without this leaf, it wasn't mandatory - the code >>> obviously took some default action. This should be reflected in the >>> data model. >>> >> How come CLI-based routers don't won't this way? >> Could it be because this is way too fragile? >> >> I can't see how a YANG module with a mandatory >> top-level node in it can ever be deployed in >> a real system. > > Agreed. So do we agree on the above that startup must be valid? > In my code, startup is just a file that is input into , using an extreme 'continue-on-error' algorithm. Any bad config is tossed, and and good config is used. The operator may be able to fix a broken config, but certainly not if the box shuts down and refuses to accept any NETCONF sessions. >> I don't see how config and new modules >> are kept in perfect alignment, within a single >> protocol operation. > > As you said - if there are no top-level mandatory nodes (or within > NP-containers...) then it will work. Maybe add something about this > in the guidelines document? > I don't like the idea that YANG has perfectly valid constructs that are like poison pills -- just loading a valid YANG module into an agent should not force the box to shutdown. We need NETCONF agents to work with any valid YANG module that could ever be written. IMO, either we make this work in the NETCONF protocol, or change YANG so top-level mandatory nodes are not allowed. > > /martin > Andy From mbj@tail-f.com Tue Jul 21 05:44:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05D83A6B2A for ; Tue, 21 Jul 2009 05:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 r7iPj4Wd4h0s for ; Tue, 21 Jul 2009 05:44:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EB82A3A6B28 for ; Tue, 21 Jul 2009 05:44:13 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A38B376C540; Tue, 21 Jul 2009 14:16:24 +0200 (CEST) Date: Tue, 21 Jul 2009 14:16:24 +0200 (CEST) Message-Id: <20090721.141624.55725815.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A658356.2040208@ericsson.com> References: <4A658356.2040208@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] How to make something optional? 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: , X-List-Received-Date: Tue, 21 Jul 2009 12:44:14 -0000 Hi, Balazs Lengyel wrote: > Hello, > We have at least three ways to make standard functions optional. Some guidance > would be needed > when to use capabilities (like the notification rfc), when to use optional > modules (like the monitoring draft) and when to use YANG features. > IMO should go into the usage guidelines doc. I think the old way with just describing new capabilities in text can be replaced with a YANG module (and text of course). /martin From mbj@tail-f.com Tue Jul 21 06:09:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83C43A6A7C for ; Tue, 21 Jul 2009 06:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 mUY6Q4vudqMY for ; Tue, 21 Jul 2009 06:09:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D47963A68E8 for ; Tue, 21 Jul 2009 06:09:57 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 640F376C4E4; Tue, 21 Jul 2009 14:10:27 +0200 (CEST) Date: Tue, 21 Jul 2009 14:10:26 +0200 (CEST) Message-Id: <20090721.141026.165403245.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A65AD95.4090404@netconfcentral.com> References: <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 13:09:58 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > >> Balazs Lengyel wrote: > >>> Hello, > >>> We sad earlier that running must be always valid. Is that a YANG or a > >>> NETCONF requirement on the server? > >> > >> So are we saying that if the > >> has even 1 missing leaf in it, the NETCONF > >> agent must shutdown and refuse to run? > > > > Short answer: Yes. > > > > I can't see how an agent can start with an invalid config in the > > general case. In your simple example, somewhere in the code someone > > expects this mandatory leaf to exist, and behave accordingly. If the > > code can start without this leaf, it wasn't mandatory - the code > > obviously took some default action. This should be reflected in the > > data model. > > > > How come CLI-based routers don't won't this way? > Could it be because this is way too fragile? > > I can't see how a YANG module with a mandatory > top-level node in it can ever be deployed in > a real system. Agreed. So do we agree on the above that startup must be valid? > I don't see how config and new modules > are kept in perfect alignment, within a single > protocol operation. As you said - if there are no top-level mandatory nodes (or within NP-containers...) then it will work. Maybe add something about this in the guidelines document? /martin From balazs.lengyel@ericsson.com Tue Jul 21 07:11:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAF028C18B for ; Tue, 21 Jul 2009 07:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.058 X-Spam-Level: X-Spam-Status: No, score=-5.058 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 sNw17XTYjlEJ for ; Tue, 21 Jul 2009 07:11:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BF0BA3A68DD for ; Tue, 21 Jul 2009 07:11:54 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-81-4a65cca603e1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 52.03.00514.6ACC56A4; Tue, 21 Jul 2009 16:11:50 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:10:21 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:10:21 +0200 Message-ID: <4A65CC4C.2010808@ericsson.com> Date: Tue, 21 Jul 2009 16:10:20 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> In-Reply-To: <4A65AD95.4090404@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 14:10:21.0237 (UTC) FILETIME=[FBB5EE50:01CA0A0C] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 14:11:56 -0000 Andy Bierman wrote: > > I can't see how a YANG module with a mandatory > top-level node in it can ever be deployed in > a real system. > > By definition, it means the manager MUST set the node. > The agent is NOT ALLOWED to set it. So once the module > is loaded into the system, the agent is dead. > In Ericsson such top level nodes are typically created by the network element itself. It is always already there immediately, once you loaded/installed the module, and can not be deleted. Balazs From balazs.lengyel@ericsson.com Tue Jul 21 07:19:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27BE28C2A6 for ; Tue, 21 Jul 2009 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-1.949, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=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 LzAdenESs1Ju for ; Tue, 21 Jul 2009 07:19:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9E6083A6967 for ; Tue, 21 Jul 2009 07:19:47 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-d9-4a65ce69299b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id F6.F8.18827.96EC56A4; Tue, 21 Jul 2009 16:19:21 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:19:10 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:19:09 +0200 Message-ID: <4A65CE5D.9040706@ericsson.com> Date: Tue, 21 Jul 2009 16:19:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> In-Reply-To: <4A65AD95.4090404@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 14:19:09.0892 (UTC) FILETIME=[36D04840:01CA0A0E] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 14:19:49 -0000 Hello, This all leads me to a nice idea: - delete-config is mandatory to support on startup (if you have startup). - you can get a reboot immediately after delete-config of startup - this means that a) Every box that supports startup must be able to run with an empty configuration or b) Every box that supports startup must itself create a minimum config after delete-config/startup, that will allow it to run or c) I am wrong somewhere Balazs Andy Bierman wrote: > Martin Bjorklund wrote: >> Hi, >> >> Andy Bierman wrote: >>> Balazs Lengyel wrote: >>>> Hello, >>>> We sad earlier that running must be always valid. Is that a YANG or a >>>> NETCONF requirement on the server? >>> So are we saying that if the >>> has even 1 missing leaf in it, the NETCONF >>> agent must shutdown and refuse to run? >> Short answer: Yes. >> >> I can't see how an agent can start with an invalid config in the >> general case. In your simple example, somewhere in the code someone >> expects this mandatory leaf to exist, and behave accordingly. If the >> code can start without this leaf, it wasn't mandatory - the code >> obviously took some default action. This should be reflected in the >> data model. >> > > How come CLI-based routers don't won't this way? > Could it be because this is way too fragile? > > I can't see how a YANG module with a mandatory > top-level node in it can ever be deployed in > a real system. > > By definition, it means the manager MUST set the node. > The agent is NOT ALLOWED to set it. So once the module > is loaded into the system, the agent is dead. > > I don't see how config and new modules > are kept in perfect alignment, within a single > protocol operation. > > > Andy > >>> Since there is no access control on , >> What? Where is this specified? >> >>> this means if a hacker can somehow cause the >>> to be invalid (by 1 leaf), and >>> then cause the box to reboot, then the NETCONF >>> standard mandates that the device is FUBAR >>> until the operator replaces the somehow? >> If there is no access control on startup, a hacker can do much more >> damage than this... >> >>> What about loading modules are run-time? >>> Add 1 mandatory leaf, and the box rolls over and dies? >>> Without any chance for the operator to create the new leaf? >> If we say that running MAY be invalid, i.e. that the box is supposed >> to run with any invalid config, what is the purpose of the validation >> anyway? >> >> >> /martin >> > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Tue Jul 21 08:03:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B463A6E79 for ; Tue, 21 Jul 2009 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6OdrlmioYeR for ; Tue, 21 Jul 2009 08:03:07 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id D03943A6848 for ; Tue, 21 Jul 2009 08:03:06 -0700 (PDT) Received: (qmail 62564 invoked from network); 21 Jul 2009 15:02:28 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.142.220 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2009 15:02:27 -0000 X-YMail-OSG: uvIaLVMVM1lTGGnC4ERMSPmSVfCsr6vTbhn6j_D5GDSzIBgKwsweiUX9mLHIea.hRg9SbW6B20kWmFO_qzg80Dg9vEtXoWzvR8cw9aAE9IQO8l7JzwxF0uxxuQUhiqYBw1a6FRuNzUp1IhZQ4mKRf8q85YcfLa.LgmLm0w9tN4KCV3NShBLK3K8q3DW_s8IJinWiuAglrIgcuaRMHrvet9a1PgbpUdWU_S344fizRdJoX3_BZeJEhX_AHzEgXxyZuVk4xA4Q6uPQkGhx X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A65D88F.3030909@netconfcentral.com> Date: Tue, 21 Jul 2009 08:02:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> <4A65CC4C.2010808@ericsson.com> In-Reply-To: <4A65CC4C.2010808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 15:03:07 -0000 Balazs Lengyel wrote: > > > Andy Bierman wrote: >> >> I can't see how a YANG module with a mandatory >> top-level node in it can ever be deployed in >> a real system. >> >> By definition, it means the manager MUST set the node. >> The agent is NOT ALLOWED to set it. So once the module >> is loaded into the system, the agent is dead. >> > In Ericsson such top level nodes are typically created by the network > element itself. It is always already there immediately, once you > loaded/installed the module, and can not be deleted. > by definition, that is not a mandatory node, and not part of the problem. > Balazs > Andy From andy@netconfcentral.com Tue Jul 21 08:19:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF763A67F7 for ; Tue, 21 Jul 2009 08:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3NPRG7vMJN4 for ; Tue, 21 Jul 2009 08:19:52 -0700 (PDT) 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 7E5A428C2F9 for ; Tue, 21 Jul 2009 08:19:52 -0700 (PDT) Received: (qmail 95314 invoked from network); 21 Jul 2009 15:19:49 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.80.235 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2009 15:19:49 -0000 X-YMail-OSG: D.92fkoVM1lGFqXs0s92UX3YItdzFV.S4eXINRJTCeBZ12aCAil1fxSFdfL0odcJ22pwPLcmS6uRDl6AkFZSqqhDiYZPsbLzB3K033uZzNUUmhR3MRLjQl7dXA9dDCKgNqxYDx5Ro4QWYWmSFU3I6GvtiNH08E1EG1aMnGGKHnC2d36T1WjSZIlKawo_cUOSBkvu1YhNv..t3d_BsNOjdGmFiTs8GAxzs1cZJ6OupGiS9uh1zqj5qogG1DwFLAb.MW.SolEVCtyXruPEo8n.ckNbxkpcWma9NT1NjSB5unLYrCmwvDQJfE.gWf231nsuB.Lr58Bpqps8qcDTP5_eJrmVtUD0d0OAd6YCizX4ww8ZF5RR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A65DC24.8070901@netconfcentral.com> Date: Tue, 21 Jul 2009 08:17:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> <4A65CE5D.9040706@ericsson.com> In-Reply-To: <4A65CE5D.9040706@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 15:19:53 -0000 Balazs Lengyel wrote: > Hello, > This all leads me to a nice idea: > - delete-config is mandatory to support on startup (if you have startup). yes, but there may be access control in your way. I choose to tag the operation as 'secure', meaning by default only the 'super user' can invoke it. (oops - I forgot we have no official users, groups, or anything else ACM-wise, but IMO the concept of a super-user account that bypasses all access control is fairly important.) > - you can get a reboot immediately after delete-config of startup > - this means that > a) Every box that supports startup must be able to run with an empty > configuration including all the access control config wiped out -- yes. that is why it is dangerous to allow anybody to do this. > or > b) Every box that supports startup must itself create a minimum config > after delete-config/startup, that will allow it to run > or same as (a). The agent will always create any nodes it must have, if they are missing. Partial or empty startup makes no difference here. > c) I am wrong somewhere > > Balazs Andy > > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> >>> Andy Bierman wrote: >>>> Balazs Lengyel wrote: >>>>> Hello, >>>>> We sad earlier that running must be always valid. Is that a YANG or a >>>>> NETCONF requirement on the server? >>>> So are we saying that if the >>>> has even 1 missing leaf in it, the NETCONF >>>> agent must shutdown and refuse to run? >>> Short answer: Yes. >>> >>> I can't see how an agent can start with an invalid config in the >>> general case. In your simple example, somewhere in the code someone >>> expects this mandatory leaf to exist, and behave accordingly. If the >>> code can start without this leaf, it wasn't mandatory - the code >>> obviously took some default action. This should be reflected in the >>> data model. >>> >> >> How come CLI-based routers don't won't this way? >> Could it be because this is way too fragile? >> >> I can't see how a YANG module with a mandatory >> top-level node in it can ever be deployed in >> a real system. >> >> By definition, it means the manager MUST set the node. >> The agent is NOT ALLOWED to set it. So once the module >> is loaded into the system, the agent is dead. >> >> I don't see how config and new modules >> are kept in perfect alignment, within a single >> protocol operation. >> >> >> Andy >> >>>> Since there is no access control on , >>> What? Where is this specified? >>> >>>> this means if a hacker can somehow cause the >>>> to be invalid (by 1 leaf), and >>>> then cause the box to reboot, then the NETCONF >>>> standard mandates that the device is FUBAR >>>> until the operator replaces the somehow? >>> If there is no access control on startup, a hacker can do much more >>> damage than this... >>> >>>> What about loading modules are run-time? >>>> Add 1 mandatory leaf, and the box rolls over and dies? >>>> Without any chance for the operator to create the new leaf? >>> If we say that running MAY be invalid, i.e. that the box is supposed >>> to run with any invalid config, what is the purpose of the validation >>> anyway? >>> >>> >>> /martin >>> >> >> > From balazs.lengyel@ericsson.com Tue Jul 21 08:20:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023883A6A10 for ; Tue, 21 Jul 2009 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.79 X-Spam-Level: X-Spam-Status: No, score=-4.79 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 4OvDJsQHK5D0 for ; Tue, 21 Jul 2009 08:20:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 01DC53A69CB for ; Tue, 21 Jul 2009 08:20:48 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-01-4a65dccc4eca Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 73.17.00514.CCCD56A4; Tue, 21 Jul 2009 17:20:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 17:19:36 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 17:19:36 +0200 Message-ID: <4A65DC84.3040104@ericsson.com> Date: Tue, 21 Jul 2009 17:19:32 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> <4A65CC4C.2010808@ericsson.com> <4A65D88F.3030909@netconfcentral.com> In-Reply-To: <4A65D88F.3030909@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 15:19:36.0060 (UTC) FILETIME=[A82D9BC0:01CA0A16] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 15:20:50 -0000 Andy Bierman wrote: > Balazs Lengyel wrote: >> >> Andy Bierman wrote: >>> I can't see how a YANG module with a mandatory >>> top-level node in it can ever be deployed in >>> a real system. >>> >>> By definition, it means the manager MUST set the node. >>> The agent is NOT ALLOWED to set it. So once the module >>> is loaded into the system, the agent is dead. >>> >> In Ericsson such top level nodes are typically created by the network >> element itself. It is always already there immediately, once you >> loaded/installed the module, and can not be deleted. >> > > by definition, that is not a mandatory node, and not > part of the problem. > > If a list has min-elements 1; it is a mandatory element as defined in YANG chapter 3.1. It can be a top level node in a YAM. AFAIK it is not forbidden for the element itself to create the above element. Balazs From balazs.lengyel@ericsson.com Tue Jul 21 08:21:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A7B28C2B3 for ; Tue, 21 Jul 2009 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-1.712, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=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 0vuDVg0AsY58 for ; Tue, 21 Jul 2009 08:21:21 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 679983A6C6C for ; Tue, 21 Jul 2009 08:21:21 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-63-4a65dcf0dd84 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 1A.3C.18827.0FCD56A4; Tue, 21 Jul 2009 17:21:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 17:21:19 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 17:21:19 +0200 Message-ID: <4A65DCEE.6010403@ericsson.com> Date: Tue, 21 Jul 2009 17:21:18 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <20090713200001.43E1F3A69FC@core3.amsl.com> In-Reply-To: <20090713200001.43E1F3A69FC@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 15:21:19.0261 (UTC) FILETIME=[E5B0D4D0:01CA0A16] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Comments draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Tue, 21 Jul 2009 15:21:22 -0000 Hello, Where will the "Mapping to the NETCONF Schema Discovery Mechanism" be described? Balazs From andy@netconfcentral.com Tue Jul 21 08:35:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183DC3A6B95 for ; Tue, 21 Jul 2009 08:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 EH-FV7RWta-U for ; Tue, 21 Jul 2009 08:35:16 -0700 (PDT) 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 6DD143A6967 for ; Tue, 21 Jul 2009 08:35:16 -0700 (PDT) Received: (qmail 50342 invoked from network); 21 Jul 2009 15:34:52 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.80.235 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 21 Jul 2009 15:34:52 -0000 X-YMail-OSG: CbGX5jMVM1mIXFXzF9fG3lTstHF1dEFASZxmTmCAEI1EYlWNK8vOyRpVQ_C3Yx43_ZdU_U5i3mQVSAhkaoy3U8ziPyZPcDuvIa_gq7mbKCt9.xLBWvmdGyNKpASeio2TAUqIqjIw21kHUoI..vx8g.hBBl2i8eofMOdiO0s8tGOTBiv3xIjWjYRvH8l5X1g.V.DmzsAC_Ki.Jd00u1yrgagtHuyQv9kirWiUpWkTtYdn3MhYwFwxJNhZA_OvIK6Kn6hYWvKmxkmsOBI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A65E028.5050505@netconfcentral.com> Date: Tue, 21 Jul 2009 08:35:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <4A60A5D1.6050505@netconfcentral.com> <4A642DB9.5030301@ericsson.com> <4A6436CA.6060109@netconfcentral.com> <20090720.233829.201993099.mbj@tail-f.com> <4A65AD95.4090404@netconfcentral.com> <4A65CC4C.2010808@ericsson.com> <4A65D88F.3030909@netconfcentral.com> <4A65DC84.3040104@ericsson.com> In-Reply-To: <4A65DC84.3040104@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 15:35:17 -0000 Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> >>> Andy Bierman wrote: >>>> I can't see how a YANG module with a mandatory >>>> top-level node in it can ever be deployed in >>>> a real system. >>>> >>>> By definition, it means the manager MUST set the node. >>>> The agent is NOT ALLOWED to set it. So once the module >>>> is loaded into the system, the agent is dead. >>>> >>> In Ericsson such top level nodes are typically created by the network >>> element itself. It is always already there immediately, once you >>> loaded/installed the module, and can not be deleted. >>> >> >> by definition, that is not a mandatory node, and not >> part of the problem. >> >> > If a list has min-elements 1; it is a mandatory element as defined in > YANG chapter 3.1. > It can be a top level node in a YAM. > yes. I think there are 3 problems, or features, depending on how you look at it. By 'top-level', we of course mean a top-level exposed data node (could be within a choice or nested NP containers). - top-level mandatory=true - top-level min-elements > 0 - anywhere a must-stmt fails > AFAIK it is not forbidden for the element itself to create the above > element. correct -- I think the subtree in the notification RFC mandates that the agent create 1 entry for the NETCONF stream. This could be min-elements 1; (IMO). Only the mandatory-stmt is picky about how the entry got there. > Balazs > Andy From balazs.lengyel@ericsson.com Tue Jul 21 09:28:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE363A6B01 for ; Tue, 21 Jul 2009 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 IYTBhofOx4Iw for ; Tue, 21 Jul 2009 09:28:00 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 891CD3A6857 for ; Tue, 21 Jul 2009 09:28:00 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-84-4a65ec897434 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A0.DC.14528.98CE56A4; Tue, 21 Jul 2009 18:27:53 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:27:38 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:27:38 +0200 Message-ID: <4A65EC7A.1060008@ericsson.com> Date: Tue, 21 Jul 2009 18:27:38 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <20090713200001.43E1F3A69FC@core3.amsl.com> In-Reply-To: <20090713200001.43E1F3A69FC@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 16:27:38.0670 (UTC) FILETIME=[299A74E0:01CA0A20] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Tue, 21 Jul 2009 16:28:01 -0000 Hello, Ch 9.9.2 page 124) Change: If the leaf with the instance-identifier type represents to If the leaf with the leafref type represents Ch 9.13 page 132 The accessible tree in the first bullet about trees is restricted to config data. On the previous page it is allowed to point with a config leafref to state data if require instance is false. Please synchronize the two statements. IMHO the tree should include state data as well. Both for instance identifiers and leafrefs it should be stated, that the accessible tree is from the SAME datastore where the leaf exists. For leafs in the candidate it is the candidate and so on. The terminology "data in one of the NETCONF datastores" does not specify which datastore. Balazs From balazs.lengyel@ericsson.com Tue Jul 21 09:52:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00A23A684C for ; Tue, 21 Jul 2009 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 4JsQ2mM-2j9M for ; Tue, 21 Jul 2009 09:52:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0F3433A6813 for ; Tue, 21 Jul 2009 09:52:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-cd-4a65f25086a9 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 44.FA.00514.052F56A4; Tue, 21 Jul 2009 18:52:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:52:31 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:52:31 +0200 Message-ID: <4A65F24E.2020700@ericsson.com> Date: Tue, 21 Jul 2009 18:52:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <20090713200001.43E1F3A69FC@core3.amsl.com> In-Reply-To: <20090713200001.43E1F3A69FC@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 16:52:31.0145 (UTC) FILETIME=[A3301190:01CA0A23] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Tue, 21 Jul 2009 16:52:35 -0000 Hello, Ch 9.13.2 The last paragraph looks like a copy paste error from leafref. Please remove it. Balazs From mbj@tail-f.com Tue Jul 21 13:25:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5543A67A3 for ; Tue, 21 Jul 2009 13:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 4VgCxQbFLl6P for ; Tue, 21 Jul 2009 13:25:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6E33C3A683A for ; Tue, 21 Jul 2009 13:25:41 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D0F976C540; Tue, 21 Jul 2009 22:25:40 +0200 (CEST) Date: Tue, 21 Jul 2009 22:25:40 +0200 (CEST) Message-Id: <20090721.222540.86226812.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A65B5D4.6070904@netconfcentral.com> References: <4A65AD95.4090404@netconfcentral.com> <20090721.141026.165403245.mbj@tail-f.com> <4A65B5D4.6070904@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 20:25:42 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Andy Bierman wrote: > >>>> Balazs Lengyel wrote: > >>>>> Hello, > >>>>> We sad earlier that running must be always valid. Is that a YANG or a > >>>>> NETCONF requirement on the server? > >>>> So are we saying that if the > >>>> has even 1 missing leaf in it, the NETCONF > >>>> agent must shutdown and refuse to run? > >>> Short answer: Yes. > >>> > >>> I can't see how an agent can start with an invalid config in the > >>> general case. In your simple example, somewhere in the code someone > >>> expects this mandatory leaf to exist, and behave accordingly. If the > >>> code can start without this leaf, it wasn't mandatory - the code > >>> obviously took some default action. This should be reflected in the > >>> data model. > >>> > >> How come CLI-based routers don't won't this way? > >> Could it be because this is way too fragile? > >> > >> I can't see how a YANG module with a mandatory > >> top-level node in it can ever be deployed in > >> a real system. > > > > Agreed. So do we agree on the above that startup must be valid? > > > > In my code, startup is just a file that is input into , > using an extreme 'continue-on-error' algorithm. Any bad config > is tossed, and and good config is used. So what happens if there is a must expression that says that a > b, and it is not. Do you delete a or b? What if both are mandatory? What if a list has a max-elements constraint and there are more - do you randomly delete one entry? What if a must expression in general returns false, how do you know which node to delete? I don't think this idea works. Also, it implies that someone somehow was able to write invalid data into startup. If the server ensures that startup is valid, then this is not a problem. > The operator may be able to fix a broken config, > but certainly not if the box shuts down and > refuses to accept any NETCONF sessions. The point is that if startup (and running) are always valid, this situation does not occur. I am not sure what you argue for - is it: 1) startup is allowed to be invalid 2) running is allowed to be invalid > >> I don't see how config and new modules > >> are kept in perfect alignment, within a single > >> protocol operation. > > > > As you said - if there are no top-level mandatory nodes (or within > > NP-containers...) then it will work. Maybe add something about this > > in the guidelines document? > > > > I don't like the idea that YANG has perfectly valid > constructs that are like poison pills -- just > loading a valid YANG module into an agent should > not force the box to shutdown. We need NETCONF agents > to work with any valid YANG module that could ever be written. Of course. Continuing your example, if the new module has a mandatory top-level node, when it is loaded into the server (implementation dependant btw), the server must make sure that a value for the mandatory node is provided. /martin From mbj@tail-f.com Tue Jul 21 13:28:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5596F3A689A for ; Tue, 21 Jul 2009 13:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.029 X-Spam-Level: X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 fl3l2NTJxpnd for ; Tue, 21 Jul 2009 13:28:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8C3D93A683A for ; Tue, 21 Jul 2009 13:28:06 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5809176C4E4; Tue, 21 Jul 2009 22:28:06 +0200 (CEST) Date: Tue, 21 Jul 2009 22:28:05 +0200 (CEST) Message-Id: <20090721.222805.161644393.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A65D88F.3030909@netconfcentral.com> References: <4A65AD95.4090404@netconfcentral.com> <4A65CC4C.2010808@ericsson.com> <4A65D88F.3030909@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 20:28:07 -0000 Andy Bierman wrote: > Balazs Lengyel wrote: > > > > > > Andy Bierman wrote: > >> > >> I can't see how a YANG module with a mandatory > >> top-level node in it can ever be deployed in > >> a real system. > >> > >> By definition, it means the manager MUST set the node. > >> The agent is NOT ALLOWED to set it. So once the module > >> is loaded into the system, the agent is dead. > >> > > In Ericsson such top level nodes are typically created by the network > > element itself. It is always already there immediately, once you > > loaded/installed the module, and can not be deleted. > > > > by definition, that is not a mandatory node, and not > part of the problem. I think Balazs means that they use models with mandatory top-level nodes, and in order to handle it, a "factory default" value is provided. The node is still mandatory in the data model, even though the box provides an initial value. /martin From mbj@tail-f.com Tue Jul 21 13:32:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C5F28C36F for ; Tue, 21 Jul 2009 13:32:10 -0700 (PDT) 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.094, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 ZE-1BD0nyDPo for ; Tue, 21 Jul 2009 13:32:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1448528C364 for ; Tue, 21 Jul 2009 13:32:09 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CEF0976C4E4; Tue, 21 Jul 2009 22:32:09 +0200 (CEST) Date: Tue, 21 Jul 2009 22:32:09 +0200 (CEST) Message-Id: <20090721.223209.31919947.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A65DC24.8070901@netconfcentral.com> References: <4A65AD95.4090404@netconfcentral.com> <4A65CE5D.9040706@ericsson.com> <4A65DC24.8070901@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 20:32:10 -0000 Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello, > > This all leads me to a nice idea: > > - delete-config is mandatory to support on startup (if you have startup). [...] > > - you can get a reboot immediately after delete-config of startup > > - this means that > > a) Every box that supports startup must be able to run with an empty > > configuration [...] > > or > > b) Every box that supports startup must itself create a minimum config > > after delete-config/startup, that will allow it to run > > or > > same as (a). > The agent will always create any nodes it must have, > if they are missing. Partial or empty startup makes > no difference here. Agreed. I think delete-config on startup can be viewed as a reset to factory defaults, which might be empty. /martin From andy@netconfcentral.com Tue Jul 21 14:10:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8416F3A6E90 for ; Tue, 21 Jul 2009 14:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 dmLbiJCIVJmt for ; Tue, 21 Jul 2009 14:10:30 -0700 (PDT) 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 B84B73A6E80 for ; Tue, 21 Jul 2009 14:10:30 -0700 (PDT) Received: (qmail 17057 invoked from network); 21 Jul 2009 21:09:50 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.80.235 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 21 Jul 2009 21:09:50 -0000 X-YMail-OSG: Kz5rSzUVM1lfcs7HXSpoocisIgBHqlFpokF6vgnd2uBD3Ia3dj8By0SVot.GJBKPOdDxYa7zEtIBgJKPhLH3lxQqDUqNqUMrzhLfmI5acwHte5CiLAPxrTT3Sy9DU9OoW93eMm3vtI8jZ9p3ibQly9_RvfaGhXfFV1n2tmp1uiIhaof7oYR_YC8y2ENHSUyy1m16JFE012RyzhHX7gg1KNIMsUF5Y8P2yDUFtIvbn8611wy098EbPNeGAdd.fL4rYikhWah1qPXRCaO10hUTjNHbV4MzAz4j5IO9ioi2rAdjnZjxCqdHtjS6svInAXrmmwphM3OJo9aY X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A662E33.5080800@netconfcentral.com> Date: Tue, 21 Jul 2009 14:08:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A65AD95.4090404@netconfcentral.com> <20090721.141026.165403245.mbj@tail-f.com> <4A65B5D4.6070904@netconfcentral.com> <20090721.222540.86226812.mbj@tail-f.com> In-Reply-To: <20090721.222540.86226812.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 21:10:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: .... >> In my code, startup is just a file that is input into , >> using an extreme 'continue-on-error' algorithm. Any bad config >> is tossed, and and good config is used. > > So what happens if there is a must expression that says that a > b, > and it is not. Do you delete a or b? What if both are mandatory? neither. the node with the must-stmt would get flagged with the error, so it would be deleted. that error will ripple up until a 'detachable' point is reached, or maybe all the way to the top-level node. All the tainted nodes would get deleted. > What if a list has a max-elements constraint and there are more - do > you randomly delete one entry? What if a must expression in general > returns false, how do you know which node to delete? > I think all the entries would get deleted, because I would tag the parent with the error. So bye-bye all child nodes, not just the max-elements-exceeded node. > I don't think this idea works. Also, it implies that someone somehow > was able to write invalid data into startup. If the server ensures > that startup is valid, then this is not a problem. > What about a SW image upgrade, or just a reload with new modules that have some mandatory (or just desired) config? 1) lock target=startup 2) delete-config target=startup 3) copy-config source=@my-new-config target=startup 4) (offline change CLI parameters for agent to reflect new settings and modules expected) 5) restart The agent MUST NOT validate the contents of against the current settings/modules for this to work. I suppose a special operation for would be cleaner, but the WG is busy with other things now. > >> The operator may be able to fix a broken config, >> but certainly not if the box shuts down and >> refuses to accept any NETCONF sessions. > > The point is that if startup (and running) are always valid, this > situation does not occur. > > I am not sure what you argue for - is it: > > 1) startup is allowed to be invalid > 2) running is allowed to be invalid > >>>> I don't see how config and new modules >>>> are kept in perfect alignment, within a single >>>> protocol operation. >>> As you said - if there are no top-level mandatory nodes (or within >>> NP-containers...) then it will work. Maybe add something about this >>> in the guidelines document? >>> >> I don't like the idea that YANG has perfectly valid >> constructs that are like poison pills -- just >> loading a valid YANG module into an agent should >> not force the box to shutdown. We need NETCONF agents >> to work with any valid YANG module that could ever be written. > > Of course. Continuing your example, if the new module has a mandatory > top-level node, when it is loaded into the server (implementation > dependant btw), the server must make sure that a value for the > mandatory node is provided. > > > /martin > Andy From phil@juniper.net Tue Jul 21 14:24:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2419528C11D for ; Tue, 21 Jul 2009 14:24:12 -0700 (PDT) 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 2oszrj1vP2Sq for ; Tue, 21 Jul 2009 14:24:11 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 546953A68B4 for ; Tue, 21 Jul 2009 14:24:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSmYx+Mf47fqikAakVpk24vkgihK4AN64@postini.com; Tue, 21 Jul 2009 14:24:12 PDT 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.375.2; Tue, 21 Jul 2009 14:19:54 -0700 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, 21 Jul 2009 14:19:54 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 14:19:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 14:19:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6LLJrd94228; Tue, 21 Jul 2009 14:19:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6LL8Vh7051806; Tue, 21 Jul 2009 21:08:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907212108.n6LL8Vh7051806@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090721.222540.86226812.mbj@tail-f.com> Date: Tue, 21 Jul 2009 17:08:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Jul 2009 21:19:53.0578 (UTC) FILETIME=[FD3914A0:01CA0A48] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 21:24:12 -0000 Martin Bjorklund writes: >The point is that if startup (and running) are always valid, this >situation does not occur. My take on this discussion is that invalid startup configs are an ugly fact of life, and while it would be nice to say "don't do that", they will inevitably occur. Do we need to say what devices should do, or do we leave implementors to do their best? Scenario one: sw install changes the rules for config but doesn't update the startup. Scenario two: startup is on removal media and the user inserts media with an invalid startup config. This isn't an easy decision on the device side, since discarding invalid config may lead to evil acts (no firewall rules) that will not be noticed until evil things happen, and stopping dead means your device becomes an inefficient space heater. FWIW, I went with option two, since (a) a dead device gets noticed and fixed, (b) open firewalls are bad news, and (c) space heaters are pretty cool. If we heat all of space, we won't need spacesuits. Thanks, Phil From mbj@tail-f.com Tue Jul 21 14:39:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C62028C36D for ; Tue, 21 Jul 2009 14:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=0.484, 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 zJPNuDGzYovK for ; Tue, 21 Jul 2009 14:39:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 557CE28C2BD for ; Tue, 21 Jul 2009 14:39:38 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E86DA76C4E4; Tue, 21 Jul 2009 23:39:36 +0200 (CEST) Date: Tue, 21 Jul 2009 23:39:36 +0200 (CEST) Message-Id: <20090721.233936.18401704.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907212108.n6LL8Vh7051806@idle.juniper.net> References: <20090721.222540.86226812.mbj@tail-f.com> <200907212108.n6LL8Vh7051806@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 21:39:39 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >The point is that if startup (and running) are always valid, this > >situation does not occur. > > My take on this discussion is that invalid startup configs are an > ugly fact of life, and while it would be nice to say "don't do > that", they will inevitably occur. [back pedaling a bit] Yes, you are right. I have a problem with Andy's original email, and also the title of this thread -- I don't think running can ever be invalid. I will make sure that my startup is valid at the time it is written, but as you say, I can not guarantee that the startup file is valid with the sw when the device boots. (I can guarantee that running is valid though). > Do we need to say what devices > should do, or do we leave implementors to do their best? I would prefer the latter. Then Andy can do his delete and you and I can make our space heaters. /martin From andy@netconfcentral.com Tue Jul 21 14:41:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDD228C3A4 for ; Tue, 21 Jul 2009 14:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 lf39kWvpYkfd for ; Tue, 21 Jul 2009 14:41:42 -0700 (PDT) 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 2ADD628C397 for ; Tue, 21 Jul 2009 14:41:42 -0700 (PDT) Received: (qmail 70296 invoked from network); 21 Jul 2009 21:41:39 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.80.235 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 21 Jul 2009 21:41:39 -0000 X-YMail-OSG: 191scbwVM1kLYPEo3F.0G.ZI3fvWRcXMiLhid_qWgQHqqj3X8I5OeICfmn4GGol_0GFE3zZPE5VTh8GGttAvJ3mnP0FKvyafB2Q2C7Ou1tzPXnEGBpsvxi8dBF2d.aiO47uuemJiJPgUGNU_MMZdIxjdsEHtHnKZsTg65Yt3QAyKLyo7yOTPGRqoVx5Yo8Zi_kqpdoXV_v4sBM1sIMhs0hQaqfJlOarknq0yq6P77L69o_ZyeWl8ExMJp8LH1BIrhj.pf8JjLhxpS64- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6635A8.80107@netconfcentral.com> Date: Tue, 21 Jul 2009 14:39:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907212108.n6LL8Vh7051806@idle.juniper.net> In-Reply-To: <200907212108.n6LL8Vh7051806@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 21:41:43 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> The point is that if startup (and running) are always valid, this >> situation does not occur. > > My take on this discussion is that invalid startup configs are an > ugly fact of life, and while it would be nice to say "don't do > that", they will inevitably occur. Do we need to say what devices > should do, or do we leave implementors to do their best? > > Scenario one: sw install changes the rules for config but doesn't > update the startup. > > Scenario two: startup is on removal media and the user inserts media > with an invalid startup config. > > This isn't an easy decision on the device side, since discarding > invalid config may lead to evil acts (no firewall rules) that will > not be noticed until evil things happen, and stopping dead means > your device becomes an inefficient space heater. > > FWIW, I went with option two, since (a) a dead device gets noticed > and fixed, (b) open firewalls are bad news, and (c) space heaters > are pretty cool. If we heat all of space, we won't need spacesuits. > really? is that what the CLI does too? Just 1 bad CLI command and the router refuses to do anything at all? What about plug-in modules that aren't there, but the config for them is there? What if the YANG file for that module isn't even available, not just the instrumentation? What about 1 module that was updated, but the config was not, and the YANG update rules are not followed to the letter, so the startup has invalid config for 1 module? Tossing the valid config for all the rest of the modules seems harsh. The agent can always hard-wire a check-list of must-have-modules if it wants, and act like a brick when the need arises. I think I am agreeing with you that it is an implementation specific matter how the agent will handle certain errors in the config. > Thanks, > Phil > Andy From phil@juniper.net Tue Jul 21 14:45:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4D83A6E8C for ; Tue, 21 Jul 2009 14:45:48 -0700 (PDT) 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 JAYS8TjbXoYD for ; Tue, 21 Jul 2009 14:45:48 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 73EB93A683A for ; Tue, 21 Jul 2009 14:45:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSmY3CbitHhGaIDVh1qmWwx0l4q1hYpMP@postini.com; Tue, 21 Jul 2009 14:45:48 PDT 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.375.2; Tue, 21 Jul 2009 14:42:56 -0700 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, 21 Jul 2009 14:42:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 14:42:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 14:42:55 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6LLgsd06289; Tue, 21 Jul 2009 14:42:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6LLVX8I052135; Tue, 21 Jul 2009 21:31:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907212131.n6LLVX8I052135@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090721.233936.18401704.mbj@tail-f.com> Date: Tue, 21 Jul 2009 17:31:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Jul 2009 21:42:55.0246 (UTC) FILETIME=[34C2E2E0:01CA0A4C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 21:45:49 -0000 Martin Bjorklund writes: >I would prefer the latter. Then Andy can do his delete and you and I >can make our space heaters. Sounds good. I agree that running should never be invalid. If a box doesn't enforce a rule on running, that it's not a rule. (Or it's a deviation from the rule). Thanks, Phil From phil@juniper.net Tue Jul 21 14:49:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5823F28C3B1 for ; Tue, 21 Jul 2009 14:49:45 -0700 (PDT) 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 DLmuoh74X7iQ for ; Tue, 21 Jul 2009 14:49:44 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 6F0303A683A for ; Tue, 21 Jul 2009 14:49:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSmY39HqNhRndZ0smVseluxxx5DrQra30@postini.com; Tue, 21 Jul 2009 14:49:45 PDT 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.375.2; Tue, 21 Jul 2009 14:46:44 -0700 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, 21 Jul 2009 14:46:44 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 14:46:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 14:46:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6LLkgd07843; Tue, 21 Jul 2009 14:46:42 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6LLZLDe052187; Tue, 21 Jul 2009 21:35:21 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907212135.n6LLZLDe052187@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6635A8.80107@netconfcentral.com> Date: Tue, 21 Jul 2009 17:35:21 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Jul 2009 21:46:43.0209 (UTC) FILETIME=[BCA34790:01CA0A4C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Tue, 21 Jul 2009 21:49:45 -0000 Andy Bierman writes: >really? Honest. >is that what the CLI does too? Nope. >Just 1 bad CLI command and the router refuses to >do anything at all? Of course not. A user at the CLI gets an error and the command is ignored. But at boot time (startup), there's no user to give an error to. >I think I am agreeing with you that it is an implementation >specific matter how the agent will handle certain errors >in the config. Cool. So what do we need to say in the spec? Just mention that care should be taken that startup be valid, but the real world might interfer and the behavior of the device in the face of an invalid startup config is left to the device implementor? Thanks, Phil From mbj@tail-f.com Tue Jul 21 15:01:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BF13A6EA5 for ; Tue, 21 Jul 2009 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.377, 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 XK392XyrA7r2 for ; Tue, 21 Jul 2009 15:01:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6F95628C385 for ; Tue, 21 Jul 2009 15:01:12 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 51C7776C4E4; Wed, 22 Jul 2009 00:01:12 +0200 (CEST) Date: Wed, 22 Jul 2009 00:01:11 +0200 (CEST) Message-Id: <20090722.000111.41126511.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A65DCEE.6010403@ericsson.com> References: <20090713200001.43E1F3A69FC@core3.amsl.com> <4A65DCEE.6010403@ericsson.com> lX-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Comments draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Tue, 21 Jul 2009 22:01:13 -0000 Balazs Lengyel wrote: > Hello, > Where will the "Mapping to the NETCONF Schema Discovery Mechanism" be > described? The text we had was included in the monitoring spec instead. /martin From mbj@tail-f.com Tue Jul 21 15:09:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F583A6B7B for ; Tue, 21 Jul 2009 15:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=0.339, 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 cTkh91c0oaYU for ; Tue, 21 Jul 2009 15:09:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6D04D3A6AC0 for ; Tue, 21 Jul 2009 15:09:49 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3454A76C540; Wed, 22 Jul 2009 00:09:49 +0200 (CEST) Date: Wed, 22 Jul 2009 00:09:48 +0200 (CEST) Message-Id: <20090722.000948.206458951.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A65EC7A.1060008@ericsson.com> References: <20090713200001.43E1F3A69FC@core3.amsl.com> <4A65EC7A.1060008@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Tue, 21 Jul 2009 22:09:50 -0000 Balazs Lengyel wrote: > Hello, > Ch 9.9.2 page 124) > Change: > If the leaf with the instance-identifier type represents > to > If the leaf with the leafref type represents Fixed. > Ch 9.13 page 132 > The accessible tree in the first bullet about trees is restricted to config > data. > On the previous page it is allowed to point with a config leafref to state data > if require instance is false. > > Please synchronize the two statements. IMHO the tree should include state data > as well. I will get back to you on this one. /martin From mbj@tail-f.com Tue Jul 21 15:10:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8973A6EA9 for ; Tue, 21 Jul 2009 15:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.308, 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 oLaCjgSXRtvM for ; Tue, 21 Jul 2009 15:10:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7EF7F28C3B7 for ; Tue, 21 Jul 2009 15:10:12 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 696EE76C4E4; Wed, 22 Jul 2009 00:10:12 +0200 (CEST) Date: Wed, 22 Jul 2009 00:10:12 +0200 (CEST) Message-Id: <20090722.001012.70824812.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A65F24E.2020700@ericsson.com> References: <20090713200001.43E1F3A69FC@core3.amsl.com> <4A65F24E.2020700@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Tue, 21 Jul 2009 22:10:13 -0000 Balazs Lengyel wrote: > Hello, > Ch 9.13.2 > The last paragraph looks like a copy paste error from leafref. Please remove > it. Fixed. /martin From lhotka@cesnet.cz Tue Jul 21 23:15:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6F43A6B26 for ; Tue, 21 Jul 2009 23:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 Atp+vURNrdkP for ; Tue, 21 Jul 2009 23:15:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A6EC83A685B for ; Tue, 21 Jul 2009 23:15:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 06EFED80095 for ; Wed, 22 Jul 2009 08:12:48 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090721.222805.161644393.mbj@tail-f.com> References: <4A65AD95.4090404@netconfcentral.com> <4A65CC4C.2010808@ericsson.com> <4A65D88F.3030909@netconfcentral.com> <20090721.222805.161644393.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 22 Jul 2009 08:12:45 +0200 Message-Id: <1248243165.7960.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Wed, 22 Jul 2009 06:15:11 -0000 Martin Bjorklund píše v Út 21. 07. 2009 v 22:28 +0200: > I think Balazs means that they use models with mandatory top-level > nodes, and in order to handle it, a "factory default" value is > provided. The node is still mandatory in the data model, even though > the box provides an initial value. So these "factory defaults" are not (necessarily) part of the data model, and these mandatory nodes are not set by the manager. It looks like we are going to repeat the same discussion we had about two years ago ... Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Jul 22 01:05:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644A13A689C for ; Wed, 22 Jul 2009 01:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.261, 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 5KGEv1AEy9h0 for ; Wed, 22 Jul 2009 01:05:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9ACE43A6851 for ; Wed, 22 Jul 2009 01:05:54 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B3EB76C4CA; Wed, 22 Jul 2009 10:05:00 +0200 (CEST) Date: Wed, 22 Jul 2009 10:04:59 +0200 (CEST) Message-Id: <20090722.100459.173111741.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1248243165.7960.6.camel@missotis> References: <4A65D88F.3030909@netconfcentral.com> <20090721.222805.161644393.mbj@tail-f.com> <1248243165.7960.6.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Wed, 22 Jul 2009 08:05:55 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMjEuIDA3LiAyMDA5IHYgMjI6MjggKzAyMDA6DQo+IA0KPiA+IEkg dGhpbmsgQmFsYXpzIG1lYW5zIHRoYXQgdGhleSB1c2UgbW9kZWxzIHdpdGggbWFuZGF0b3J5IHRv cC1sZXZlbA0KPiA+IG5vZGVzLCBhbmQgaW4gb3JkZXIgdG8gaGFuZGxlIGl0LCBhICJmYWN0b3J5 IGRlZmF1bHQiIHZhbHVlIGlzDQo+ID4gcHJvdmlkZWQuICBUaGUgbm9kZSBpcyBzdGlsbCBtYW5k YXRvcnkgaW4gdGhlIGRhdGEgbW9kZWwsIGV2ZW4gdGhvdWdoDQo+ID4gdGhlIGJveCBwcm92aWRl cyBhbiBpbml0aWFsIHZhbHVlLg0KPiANCj4gU28gdGhlc2UgImZhY3RvcnkgZGVmYXVsdHMiIGFy ZSBub3QgKG5lY2Vzc2FyaWx5KSBwYXJ0IG9mIHRoZSBkYXRhDQo+IG1vZGVsLCBhbmQgdGhlc2Ug bWFuZGF0b3J5IG5vZGVzIGFyZSBub3Qgc2V0IGJ5IHRoZSBtYW5hZ2VyLiBJdCBsb29rcw0KPiBs aWtlIHdlIGFyZSBnb2luZyB0byByZXBlYXQgdGhlIHNhbWUgZGlzY3Vzc2lvbiB3ZSBoYWQgYWJv dXQgdHdvIHllYXJzDQo+IGFnbyAuLi4NCg0KTm8sIEkgaG9wZSBub3QuICAiZmFjdG9yeSBkZWZh dWx0cyIgc2hvdWxkIG1heWJlIGJlICJmYWN0b3J5IGluaXRpYWwNCmRhdGEiIC0gaXQgaXMgc2lt cGx5IHRoZSBpbml0aWFsIHNldCBvZiBkYXRhLCBpZiBhbnksIGluIHRoZSBkYXRhDQpzdG9yZS4N Cg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Wed Jul 22 01:48:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607653A6B93 for ; Wed, 22 Jul 2009 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 Um6S5fcRZ4Jr for ; Wed, 22 Jul 2009 01:48:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4F62E3A68C7 for ; Wed, 22 Jul 2009 01:48:37 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 84324D80095; Wed, 22 Jul 2009 10:19:52 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090722.100459.173111741.mbj@tail-f.com> References: <4A65D88F.3030909@netconfcentral.com> <20090721.222805.161644393.mbj@tail-f.com> <1248243165.7960.6.camel@missotis> <20090722.100459.173111741.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 22 Jul 2009 10:19:51 +0200 Message-Id: <1248250791.7960.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Wed, 22 Jul 2009 08:48:58 -0000 Martin Bjorklund píše v St 22. 07. 2009 v 10:04 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 21. 07. 2009 v 22:28 +0200: > > > > > I think Balazs means that they use models with mandatory top-level > > > nodes, and in order to handle it, a "factory default" value is > > > provided. The node is still mandatory in the data model, even though > > > the box provides an initial value. > > > > So these "factory defaults" are not (necessarily) part of the data > > model, and these mandatory nodes are not set by the manager. It looks > > like we are going to repeat the same discussion we had about two years > > ago ... > > No, I hope not. "factory defaults" should maybe be "factory initial > data" - it is simply the initial set of data, if any, in the data > store. Well, they are set "by default", without any manager being involved. My personal conclusion from that old discussion was: 1. The only sensible definition of "mandatory" that doesn't depend on a particular device behaviour is this: A configuration parameter is mandatory if it is required for a (sub)system or protocol to operate properly. 2. The notion of default values is broader than what can be possibly specified in a data model. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Wed Jul 22 03:50:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8A128C3B9 for ; Wed, 22 Jul 2009 03:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, HELO_EQ_SE=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 vLymU8zgf1Lt for ; Wed, 22 Jul 2009 03:50:37 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9F6B528C39C for ; Wed, 22 Jul 2009 03:50:37 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-b6-4a66eb42ff29 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 99.26.18827.24BE66A4; Wed, 22 Jul 2009 12:34:42 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 12:33:48 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 12:33:47 +0200 Message-ID: <4A66EB0B.6060109@ericsson.com> Date: Wed, 22 Jul 2009 12:33:47 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4A65AD95.4090404@netconfcentral.com> <4A65CE5D.9040706@ericsson.com> <4A65DC24.8070901@netconfcentral.com> <20090721.223209.31919947.mbj@tail-f.com> In-Reply-To: <20090721.223209.31919947.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 10:33:47.0907 (UTC) FILETIME=[E57EDD30:01CA0AB7] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Wed, 22 Jul 2009 10:50:38 -0000 Hello Martin, You should out this into 4741bis! Maybe add it to TRAC as a start? Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> This all leads me to a nice idea: >>> - delete-config is mandatory to support on startup (if you have startup). > > [...] > >>> - you can get a reboot immediately after delete-config of startup >>> - this means that >>> a) Every box that supports startup must be able to run with an empty >>> configuration > > [...] > >>> or >>> b) Every box that supports startup must itself create a minimum config >>> after delete-config/startup, that will allow it to run >>> or >> same as (a). >> The agent will always create any nodes it must have, >> if they are missing. Partial or empty startup makes >> no difference here. > > Agreed. I think delete-config on startup can be viewed as a reset to > factory defaults, which might be empty. > > > /martin > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Wed Jul 22 04:08:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8584F28C3C7 for ; Wed, 22 Jul 2009 04:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=1.007, 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 fJX5AUhO4Bzj for ; Wed, 22 Jul 2009 04:08:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0DA3C3A697E for ; Wed, 22 Jul 2009 04:08:19 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-3e-4a66f2bd3b2f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D0.8B.14528.DB2F66A4; Wed, 22 Jul 2009 13:06:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:04:58 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:04:58 +0200 Message-ID: <4A66F259.7090002@ericsson.com> Date: Wed, 22 Jul 2009 13:04:57 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> In-Reply-To: <4A649038.70303@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 11:04:58.0199 (UTC) FILETIME=[4046C670:01CA0ABC] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Wed, 22 Jul 2009 11:08:21 -0000 Hello Andy, So you are saying, using complex types is more complicated. You wanted to use complex types, but later abandoned it due to implementation complexity. A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the human user it is easier to think in terms of Managed objects with complex types then in terms of groupings. Also we stated somewhere that readers are the most important community. I think we should not block this effort. Balazs Andy Bierman wrote: > Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: >> Hi All, >> >> please find below the -00 draft we submitted on "Extending YANG with >> Language Abstractions". >> This is an early draft and needs some discussion for further >> development. >> Please give us your comments. >> > > The new constructs that are proposed seem to overlap the > YANG grouping and uses statements a great deal. > > Before YANG, I implemented something called NCX > which had complex types, and every node > had a type. Every node also formed a containment > layer, even choices, because the type was a complete > abstraction, and what if it changed from a list to a choice? > > I found that the complexity level in the agent callback > structure went up a lot because of this abstraction. > > At first I did not like YANG groupings, because they are so > much more fragile and 'hands-on' than complex types. > You must control the containment layering and refinements. > It is not handled automatically like with complex types. > > But now I think that groupings are more appropriate for > embedded systems, and align better with traditional > agent callback design. > >> Regards, >> Bernd >> > > > Andy > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext >> Internet-Drafts@ietf.org >> Sent: Monday, July 06, 2009 9:00 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Extending YANG with Language Abstractions >> Author(s) : B. Linowski, M. Ersue >> Filename : draft-linowski-netmod-yang-abstract-00.txt >> Pages : 42 >> Date : 2009-07-06 >> >> YANG - the NETCONF Data Modeling Language - supports modeling of a >> tree of data elements that represent the configuration and runtime >> status of a particular network element managed via NETCONF. This >> memo suggests to enhance YANG with supplementary modeling features >> and language abstractions with the aim to improve the model >> extensibility and reuse. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- >> 00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Wed Jul 22 07:29:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448683A68E1 for ; Wed, 22 Jul 2009 07:29:50 -0700 (PDT) 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 kytHFmLiYIYp for ; Wed, 22 Jul 2009 07:29:49 -0700 (PDT) Received: from n16a.bullet.mail.mud.yahoo.com (n16a.bullet.mail.mud.yahoo.com [68.142.207.126]) by core3.amsl.com (Postfix) with SMTP id E31BD3A69C6 for ; Wed, 22 Jul 2009 07:28:58 -0700 (PDT) Received: from [68.142.200.224] by n16.bullet.mail.mud.yahoo.com with NNFMP; 22 Jul 2009 14:23:18 -0000 Received: from [68.142.201.251] by t5.bullet.mud.yahoo.com with NNFMP; 22 Jul 2009 14:23:18 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 22 Jul 2009 14:23:18 -0000 X-Yahoo-Newman-Id: 388095.76096.bm@omp412.mail.mud.yahoo.com Received: (qmail 82640 invoked from network); 22 Jul 2009 14:23:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 22 Jul 2009 14:23:17 -0000 X-YMail-OSG: FssMPogVM1nExKUC_sV9HyUv6yQBmJCuENHq_wczBTmD13QVH3w6HMQM9NeK.cKXdFGe8hEwWKwXZ923bYk6pgV_LInfUoaYWxV9jGW4ETPF07_D7VeLCfNRBqSGz80liQuUo34KN1HSjyLLuHOc0UgVM0bXn6O1jVlDRLBBW.FVAMdFNX34HoM.fDh_BCQfb2OONSuHrq6Lf9YfrkDSC7K2NlagBRA1JAcHGLAvDNTahWTzorR0KXtug2.lw7trdV5HwMSE5CFgSPRCYLpU30ves_DRM2tlNvOxKWOJ8uptnW1oKDwWfbxM1SpBws2T.NCmruhdn1pi1DjBgaJm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6720DB.5090002@netconfcentral.com> Date: Wed, 22 Jul 2009 07:23:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> In-Reply-To: <4A66F259.7090002@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Wed, 22 Jul 2009 14:29:50 -0000 Balazs Lengyel wrote: > Hello Andy, > So you are saying, using complex types is more complicated. You wanted > to use complex types, but later abandoned it due to implementation > complexity. > > A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard > organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the > human user it is easier to think in terms of Managed objects with > complex types then in terms of groupings. > > Also we stated somewhere that readers are the most important community. > I think we should not block this effort. I am not in favor or turning YANG into XSD, with elements and element lists mixed in with the containers and lists. I think YANG mechanisms are sufficient, and the proposed mechanisms do not add any important new functionality. Instead, they add more ways to do the same things already supported by YANG. I think we should finish YANG 1.0 and start using it. I don't see a need to delay YANG further, or to start working on a replacement for it. I did not find that the 'complex-type' and 'element' constructs made the IPFIX data model even slightly easier to understand. > Balazs Andy > > Andy Bierman wrote: >> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: >>> Hi All, >>> >>> please find below the -00 draft we submitted on "Extending YANG with >>> Language Abstractions". >>> This is an early draft and needs some discussion for further >>> development. >>> Please give us your comments. >>> >> >> The new constructs that are proposed seem to overlap the >> YANG grouping and uses statements a great deal. >> >> Before YANG, I implemented something called NCX >> which had complex types, and every node >> had a type. Every node also formed a containment >> layer, even choices, because the type was a complete >> abstraction, and what if it changed from a list to a choice? >> >> I found that the complexity level in the agent callback >> structure went up a lot because of this abstraction. >> >> At first I did not like YANG groupings, because they are so >> much more fragile and 'hands-on' than complex types. >> You must control the containment layering and refinements. >> It is not handled automatically like with complex types. >> >> But now I think that groupings are more appropriate for >> embedded systems, and align better with traditional >> agent callback design. >> >>> Regards, >>> Bernd >>> >> >> >> Andy >> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext >>> Internet-Drafts@ietf.org >>> Sent: Monday, July 06, 2009 9:00 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Extending YANG with Language Abstractions >>> Author(s) : B. Linowski, M. Ersue >>> Filename : draft-linowski-netmod-yang-abstract-00.txt >>> Pages : 42 >>> Date : 2009-07-06 >>> >>> YANG - the NETCONF Data Modeling Language - supports modeling of a >>> tree of data elements that represent the configuration and runtime >>> status of a particular network element managed via NETCONF. This >>> memo suggests to enhance YANG with supplementary modeling features >>> and language abstractions with the aim to improve the model >>> extensibility and reuse. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- >>> 00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 phil@juniper.net Wed Jul 22 09:35:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6D63A684D for ; Wed, 22 Jul 2009 09:35:29 -0700 (PDT) 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 lZwTHgSMhOOz for ; Wed, 22 Jul 2009 09:35:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id BB2213A6ABF for ; Wed, 22 Jul 2009 09:35:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSmc/brNkCRAVDeSdIbTD7CATEGorQWBM@postini.com; Wed, 22 Jul 2009 09:35:29 PDT 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.375.2; Wed, 22 Jul 2009 08:34:15 -0700 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, 22 Jul 2009 08:34:16 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 08:34:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 08:34:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6MFYDd47535; Wed, 22 Jul 2009 08:34:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6MFMp2d058153; Wed, 22 Jul 2009 15:22:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907221522.n6MFMp2d058153@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6720DB.5090002@netconfcentral.com> Date: Wed, 22 Jul 2009 11:22:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2009 15:34:14.0364 (UTC) FILETIME=[DE19E9C0:01CA0AE1] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Wed, 22 Jul 2009 16:35:29 -0000 >Balazs Lengyel wrote: >> A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard >> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the >> human user it is easier to think in terms of Managed objects with >> complex types then in terms of groupings. I've not finished the draft yet, but there were concerns (when OO constructs were earlier proposed as part of YANG) about how reuse and revision would work with these OO constructs. Are these solved in the draft? Thanks, Phil From david.partain@ericsson.com Wed Jul 22 10:40:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920AC3A6B4C for ; Wed, 22 Jul 2009 10:40:14 -0700 (PDT) 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 JfM8fKjlYrjP for ; Wed, 22 Jul 2009 10:40:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9572D3A6820 for ; Wed, 22 Jul 2009 10:40:13 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-b0-4a6743e90a62 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 33.51.00514.9E3476A4; Wed, 22 Jul 2009 18:52:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:52:16 +0200 Received: from [153.88.45.151] ([153.88.45.151]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:52:15 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 22 Jul 2009 18:52:30 +0200 User-Agent: KMail/1.9.10 References: <200907221522.n6MFMp2d058153@idle.juniper.net> In-Reply-To: <200907221522.n6MFMp2d058153@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221852.30430.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Jul 2009 16:52:16.0093 (UTC) FILETIME=[C4A110D0:01CA0AEC] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Regarding draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Wed, 22 Jul 2009 17:40:14 -0000 Hi, My co-chair is currently on vacation, but I think I'm speaking for both of us... This draft is NOT a working group item. It is on the agenda because we (1) have time and (2) there are people in the NETMOD working group who want to gauge interest and perhaps work more together after Stockholm. However, the fact that this is on the agenda should not be interpreted to mean "We're considering re-chartering to include this right now." While I don't get to decide such things alone, I will strenuously oppose any such action right now. We will finish our currently-chartered items before we consider re-chartering to include ANY new work. That includes this draft and the SMI draft by Juergen and any other NETMOD-related draft. We have a set of deadlines that I intend to do my utmost to see that we meet. Adding new work now would not be helpful in doing so. Cheers, David From David.French@S3Group.com Wed Jul 22 12:41:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F963A6AA4 for ; Wed, 22 Jul 2009 12:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzW1s1e5VA1L for ; Wed, 22 Jul 2009 12:41:00 -0700 (PDT) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id EA29F3A699A for ; Wed, 22 Jul 2009 12:40:58 -0700 (PDT) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id n6MFu2oo028493; Wed, 22 Jul 2009 17:56:02 +0200 Received: from [192.168.88.188] ([192.168.88.188]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jul 2009 17:56:02 +0200 Message-ID: <4A673764.7070804@s3group.com> Date: Wed, 22 Jul 2009 17:59:32 +0200 From: David French User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: netmod@ietf.org References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> In-Reply-To: <4A66F259.7090002@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 15:56:02.0297 (UTC) FILETIME=[E9B0A690:01CA0AE4] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 22 Jul 2009 17:56:04 +0200 (CEST) Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Wed, 22 Jul 2009 19:41:02 -0000 Hi, Just to add to Balazs mention, our (S3 / embeddedMIND) experience has also been that an emphasis on managed object hierarchy concepts when modelling rather than Yang-style groupings leads to a more straightforward mapping and lower integration costs with the applications on the device. Regards, David French www.embeddedmind.com Balazs Lengyel wrote: > Hello Andy, > So you are saying, using complex types is more complicated. You wanted > to use complex types, but later abandoned it due to implementation > complexity. > > A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard > organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the > human user it is easier to think in terms of Managed objects with > complex types then in terms of groupings. > > Also we stated somewhere that readers are the most important > community. I think we should not block this effort. > Balazs > > Andy Bierman wrote: >> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: >>> Hi All, >>> >>> please find below the -00 draft we submitted on "Extending YANG with >>> Language Abstractions". >>> This is an early draft and needs some discussion for further >>> development. >>> Please give us your comments. >>> >> >> The new constructs that are proposed seem to overlap the >> YANG grouping and uses statements a great deal. >> >> Before YANG, I implemented something called NCX >> which had complex types, and every node >> had a type. Every node also formed a containment >> layer, even choices, because the type was a complete >> abstraction, and what if it changed from a list to a choice? >> >> I found that the complexity level in the agent callback >> structure went up a lot because of this abstraction. >> >> At first I did not like YANG groupings, because they are so >> much more fragile and 'hands-on' than complex types. >> You must control the containment layering and refinements. >> It is not handled automatically like with complex types. >> >> But now I think that groupings are more appropriate for >> embedded systems, and align better with traditional >> agent callback design. >> >>> Regards, >>> Bernd >>> >> >> >> Andy >> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext >>> Internet-Drafts@ietf.org >>> Sent: Monday, July 06, 2009 9:00 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Extending YANG with Language Abstractions >>> Author(s) : B. Linowski, M. Ersue >>> Filename : draft-linowski-netmod-yang-abstract-00.txt >>> Pages : 42 >>> Date : 2009-07-06 >>> >>> YANG - the NETCONF Data Modeling Language - supports modeling of a >>> tree of data elements that represent the configuration and runtime >>> status of a particular network element managed via NETCONF. This >>> memo suggests to enhance YANG with supplementary modeling features >>> and language abstractions with the aim to improve the model >>> extensibility and reuse. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- >>> >>> 00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> 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 >> > -- ----------------------------------- David French, VP Product Management Management Infrastructure for Networked Devices www.embeddedmind.com +48 71 3348174 (use email not voicemail) http://www.s3group.com/legal/ From lhotka@cesnet.cz Thu Jul 23 00:17:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43403A6971 for ; Thu, 23 Jul 2009 00:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 SEAn16EES6WO for ; Thu, 23 Jul 2009 00:17:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 235853A698D for ; Thu, 23 Jul 2009 00:17:20 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0BB3ED80095 for ; Thu, 23 Jul 2009 08:44:58 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4A673764.7070804@s3group.com> References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 23 Jul 2009 08:44:56 +0200 Message-Id: <1248331496.4674.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 07:17:21 -0000 David French píše v St 22. 07. 2009 v 17:59 +0200: > Hi, > > Just to add to Balazs mention, our (S3 / embeddedMIND) > experience has also been that an emphasis on managed object > hierarchy concepts when modelling rather than > Yang-style groupings leads to a more straightforward mapping > and lower integration costs with the applications on the device. Why is YANG insufficient for modelling such object hierarchies? In fact, YANG allows for "multiple inheritance", which might be very useful - and safe, since we don't have to care about method lookup strategies. Perhaps the difference is just that YANG doesn't *enforce* object orientation. Lada > > Regards, > > David French > www.embeddedmind.com > > Balazs Lengyel wrote: > > Hello Andy, > > So you are saying, using complex types is more complicated. You wanted > > to use complex types, but later abandoned it due to implementation > > complexity. > > > > A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard > > organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the > > human user it is easier to think in terms of Managed objects with > > complex types then in terms of groupings. > > > > Also we stated somewhere that readers are the most important > > community. I think we should not block this effort. > > Balazs > > > > Andy Bierman wrote: > >> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > >>> Hi All, > >>> > >>> please find below the -00 draft we submitted on "Extending YANG with > >>> Language Abstractions". > >>> This is an early draft and needs some discussion for further > >>> development. > >>> Please give us your comments. > >>> > >> > >> The new constructs that are proposed seem to overlap the > >> YANG grouping and uses statements a great deal. > >> > >> Before YANG, I implemented something called NCX > >> which had complex types, and every node > >> had a type. Every node also formed a containment > >> layer, even choices, because the type was a complete > >> abstraction, and what if it changed from a list to a choice? > >> > >> I found that the complexity level in the agent callback > >> structure went up a lot because of this abstraction. > >> > >> At first I did not like YANG groupings, because they are so > >> much more fragile and 'hands-on' than complex types. > >> You must control the containment layering and refinements. > >> It is not handled automatically like with complex types. > >> > >> But now I think that groupings are more appropriate for > >> embedded systems, and align better with traditional > >> agent callback design. > >> > >>> Regards, > >>> Bernd > >>> > >> > >> > >> Andy > >> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org > >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > >>> Internet-Drafts@ietf.org > >>> Sent: Monday, July 06, 2009 9:00 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> Title : Extending YANG with Language Abstractions > >>> Author(s) : B. Linowski, M. Ersue > >>> Filename : draft-linowski-netmod-yang-abstract-00.txt > >>> Pages : 42 > >>> Date : 2009-07-06 > >>> > >>> YANG - the NETCONF Data Modeling Language - supports modeling of a > >>> tree of data elements that represent the configuration and runtime > >>> status of a particular network element managed via NETCONF. This > >>> memo suggests to enhance YANG with supplementary modeling features > >>> and language abstractions with the aim to improve the model > >>> extensibility and reuse. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- > >>> > >>> 00.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > -- > > ----------------------------------- > David French, VP Product Management > Management Infrastructure for Networked Devices > www.embeddedmind.com > +48 71 3348174 (use email not voicemail) > > http://www.s3group.com/legal/ > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Thu Jul 23 01:14:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9C33A69A8 for ; Thu, 23 Jul 2009 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=0.838, 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 ptlD8jn2y5ml for ; Thu, 23 Jul 2009 01:14:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 28CE628B56A for ; Thu, 23 Jul 2009 01:14:05 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-8c-4a6817dd061c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 06.BD.00514.DD7186A4; Thu, 23 Jul 2009 09:57:17 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:56:30 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:56:30 +0200 Message-ID: <4A6817AE.8000906@ericsson.com> Date: Thu, 23 Jul 2009 09:56:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com> <1248331496.4674.25.camel@missotis> In-Reply-To: <1248331496.4674.25.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Jul 2009 07:56:30.0722 (UTC) FILETIME=[16E87620:01CA0B6B] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 08:14:08 -0000 Hello, The two main points I am missing are - actions/rpcs in groupings/lists - type information on groupings/lists. Unless you do a deep analysis of the YAMs there is no way to find out that e.g. a leafref points at something derived from a grouping. I don't believe anyone wants to enforce object orientation in YANG. Balazs Ladislav Lhotka wrote: > David French píše v St 22. 07. 2009 v 17:59 +0200: >> Hi, >> >> Just to add to Balazs mention, our (S3 / embeddedMIND) >> experience has also been that an emphasis on managed object >> hierarchy concepts when modelling rather than >> Yang-style groupings leads to a more straightforward mapping >> and lower integration costs with the applications on the device. > > Why is YANG insufficient for modelling such object hierarchies? In fact, > YANG allows for "multiple inheritance", which might be very useful - and > safe, since we don't have to care about method lookup strategies. > > Perhaps the difference is just that YANG doesn't *enforce* object > orientation. > > Lada > >> Regards, >> >> David French >> www.embeddedmind.com >> >> Balazs Lengyel wrote: >>> Hello Andy, >>> So you are saying, using complex types is more complicated. You wanted >>> to use complex types, but later abandoned it due to implementation >>> complexity. >>> >>> A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard >>> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the >>> human user it is easier to think in terms of Managed objects with >>> complex types then in terms of groupings. >>> >>> Also we stated somewhere that readers are the most important >>> community. I think we should not block this effort. >>> Balazs >>> >>> Andy Bierman wrote: >>>> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: >>>>> Hi All, >>>>> >>>>> please find below the -00 draft we submitted on "Extending YANG with >>>>> Language Abstractions". >>>>> This is an early draft and needs some discussion for further >>>>> development. >>>>> Please give us your comments. >>>>> >>>> The new constructs that are proposed seem to overlap the >>>> YANG grouping and uses statements a great deal. >>>> >>>> Before YANG, I implemented something called NCX >>>> which had complex types, and every node >>>> had a type. Every node also formed a containment >>>> layer, even choices, because the type was a complete >>>> abstraction, and what if it changed from a list to a choice? >>>> >>>> I found that the complexity level in the agent callback >>>> structure went up a lot because of this abstraction. >>>> >>>> At first I did not like YANG groupings, because they are so >>>> much more fragile and 'hands-on' than complex types. >>>> You must control the containment layering and refinements. >>>> It is not handled automatically like with complex types. >>>> >>>> But now I think that groupings are more appropriate for >>>> embedded systems, and align better with traditional >>>> agent callback design. >>>> >>>>> Regards, >>>>> Bernd >>>>> >>>> >>>> Andy >>>> >>>>> -----Original Message----- >>>>> From: i-d-announce-bounces@ietf.org >>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext >>>>> Internet-Drafts@ietf.org >>>>> Sent: Monday, July 06, 2009 9:00 PM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : Extending YANG with Language Abstractions >>>>> Author(s) : B. Linowski, M. Ersue >>>>> Filename : draft-linowski-netmod-yang-abstract-00.txt >>>>> Pages : 42 >>>>> Date : 2009-07-06 >>>>> >>>>> YANG - the NETCONF Data Modeling Language - supports modeling of a >>>>> tree of data elements that represent the configuration and runtime >>>>> status of a particular network element managed via NETCONF. This >>>>> memo suggests to enhance YANG with supplementary modeling features >>>>> and language abstractions with the aim to improve the model >>>>> extensibility and reuse. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- >>>>> >>>>> 00.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >> -- >> >> ----------------------------------- >> David French, VP Product Management >> Management Infrastructure for Networked Devices >> www.embeddedmind.com >> +48 71 3348174 (use email not voicemail) >> >> http://www.s3group.com/legal/ >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From lhotka@cesnet.cz Thu Jul 23 03:32:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9A23A6887 for ; Thu, 23 Jul 2009 03:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 NLbA7xfcVlrA for ; Thu, 23 Jul 2009 03:32:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 535CE3A6817 for ; Thu, 23 Jul 2009 03:32:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9ABD1D800BD; Thu, 23 Jul 2009 12:30:38 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <4A6817AE.8000906@ericsson.com> References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com> <1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 23 Jul 2009 12:30:37 +0200 Message-Id: <1248345037.4674.64.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 10:32:31 -0000 Balazs Lengyel píše v Čt 23. 07. 2009 v 09:56 +0200: > Hello, > The two main points I am missing are > - actions/rpcs in groupings/lists Hmm, do you mean something like methods? Bernd & Mehmet's draft does not propose anything like this (yet) but IMO without support for late binding it is just unnecessary syntactic sugar. > - type information on groupings/lists. Unless you do a deep analysis of the YAMs there is no > way to find out that e.g. a leafref points at something derived from a grouping. Validation including type checking is performed on instance XML documents where this information is not available anyway. An instance-identifier points to a concrete data node whose presence can be directly checked for. Everything else is quite complicated - how would you specify an XPath expression pointing to a complex type that has no corresponding node in the data tree? YANG is much closer to an XML schema language than to a programming language and I think it should stay this way. Lada > > I don't believe anyone wants to enforce object orientation in YANG. > Balazs > > Ladislav Lhotka wrote: > > David French píše v St 22. 07. 2009 v 17:59 +0200: > >> Hi, > >> > >> Just to add to Balazs mention, our (S3 / embeddedMIND) > >> experience has also been that an emphasis on managed object > >> hierarchy concepts when modelling rather than > >> Yang-style groupings leads to a more straightforward mapping > >> and lower integration costs with the applications on the device. > > > > Why is YANG insufficient for modelling such object hierarchies? In fact, > > YANG allows for "multiple inheritance", which might be very useful - and > > safe, since we don't have to care about method lookup strategies. > > > > Perhaps the difference is just that YANG doesn't *enforce* object > > orientation. > > > > Lada > > > >> Regards, > >> > >> David French > >> www.embeddedmind.com > >> > >> Balazs Lengyel wrote: > >>> Hello Andy, > >>> So you are saying, using complex types is more complicated. You wanted > >>> to use complex types, but later abandoned it due to implementation > >>> complexity. > >>> > >>> A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard > >>> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the > >>> human user it is easier to think in terms of Managed objects with > >>> complex types then in terms of groupings. > >>> > >>> Also we stated somewhere that readers are the most important > >>> community. I think we should not block this effort. > >>> Balazs > >>> > >>> Andy Bierman wrote: > >>>> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > >>>>> Hi All, > >>>>> > >>>>> please find below the -00 draft we submitted on "Extending YANG with > >>>>> Language Abstractions". > >>>>> This is an early draft and needs some discussion for further > >>>>> development. > >>>>> Please give us your comments. > >>>>> > >>>> The new constructs that are proposed seem to overlap the > >>>> YANG grouping and uses statements a great deal. > >>>> > >>>> Before YANG, I implemented something called NCX > >>>> which had complex types, and every node > >>>> had a type. Every node also formed a containment > >>>> layer, even choices, because the type was a complete > >>>> abstraction, and what if it changed from a list to a choice? > >>>> > >>>> I found that the complexity level in the agent callback > >>>> structure went up a lot because of this abstraction. > >>>> > >>>> At first I did not like YANG groupings, because they are so > >>>> much more fragile and 'hands-on' than complex types. > >>>> You must control the containment layering and refinements. > >>>> It is not handled automatically like with complex types. > >>>> > >>>> But now I think that groupings are more appropriate for > >>>> embedded systems, and align better with traditional > >>>> agent callback design. > >>>> > >>>>> Regards, > >>>>> Bernd > >>>>> > >>>> > >>>> Andy > >>>> > >>>>> -----Original Message----- > >>>>> From: i-d-announce-bounces@ietf.org > >>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > >>>>> Internet-Drafts@ietf.org > >>>>> Sent: Monday, July 06, 2009 9:00 PM > >>>>> To: i-d-announce@ietf.org > >>>>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>>> directories. > >>>>> > >>>>> Title : Extending YANG with Language Abstractions > >>>>> Author(s) : B. Linowski, M. Ersue > >>>>> Filename : draft-linowski-netmod-yang-abstract-00.txt > >>>>> Pages : 42 > >>>>> Date : 2009-07-06 > >>>>> > >>>>> YANG - the NETCONF Data Modeling Language - supports modeling of a > >>>>> tree of data elements that represent the configuration and runtime > >>>>> status of a particular network element managed via NETCONF. This > >>>>> memo suggests to enhance YANG with supplementary modeling features > >>>>> and language abstractions with the aim to improve the model > >>>>> extensibility and reuse. > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>> http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- > >>>>> > >>>>> 00.txt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> Below is the data which will enable a MIME compliant mail reader > >>>>> implementation to automatically retrieve the ASCII version of the > >>>>> Internet-Draft. > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------ > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >> -- > >> > >> ----------------------------------- > >> David French, VP Product Management > >> Management Infrastructure for Networked Devices > >> www.embeddedmind.com > >> +48 71 3348174 (use email not voicemail) > >> > >> http://www.s3group.com/legal/ > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Jul 23 05:53:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629033A672F for ; Thu, 23 Jul 2009 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_16=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 VFPcMAvOUX0N for ; Thu, 23 Jul 2009 05:53:57 -0700 (PDT) Received: from n5a.bullet.mud.yahoo.com (n5a.bullet.mud.yahoo.com [209.191.126.232]) by core3.amsl.com (Postfix) with SMTP id CEA953A6912 for ; Thu, 23 Jul 2009 05:53:53 -0700 (PDT) Received: from [68.142.200.221] by n5.bullet.mud.yahoo.com with NNFMP; 23 Jul 2009 12:52:10 -0000 Received: from [68.142.201.244] by t9.bullet.mud.yahoo.com with NNFMP; 23 Jul 2009 12:52:10 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 23 Jul 2009 12:52:10 -0000 X-Yahoo-Newman-Id: 553653.68347.bm@omp405.mail.mud.yahoo.com Received: (qmail 56523 invoked from network); 23 Jul 2009 12:52:10 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 23 Jul 2009 12:52:09 -0000 X-YMail-OSG: cdpWvY0VM1kgw4GR.lX5dMTtD3zJY7iXqrc28ofd.ms8ERpekj0svQYEGkQul1pao.OEeyl.TpJdqF73fpClS0aOZGq2lFkIG3AOOxfnuPspT_Pe8HObRG7Me4YKMMWAlEe7nlDbTI4WwTOYYx_yzgcIRC2Z10yPmLkFUc0Mk_DRkCONFE4YsWchIZN6a2RnnTFrSlAKQGa4rEu2icBt08qLdTAYFB.4mNrCiWcnZ_XHO.VUK63Hp6yiwH4k45SL10YIBfPTq1eygMm6E214pvxK..gCg_1U7PhLhUzlkR6cEkQqvraq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A685D08.7060808@netconfcentral.com> Date: Thu, 23 Jul 2009 05:52:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com> <1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com> <1248345037.4674.64.camel@missotis> In-Reply-To: <1248345037.4674.64.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 12:53:58 -0000 Ladislav Lhotka wrote: > Balazs Lengyel píše v Čt 23. 07. 2009 v 09:56 +0200: >> Hello, >> The two main points I am missing are >> - actions/rpcs in groupings/lists > > Hmm, do you mean something like methods? Bernd & Mehmet's draft does not > propose anything like this (yet) but IMO without support for late > binding it is just unnecessary syntactic sugar. > >> - type information on groupings/lists. Unless you do a deep analysis of the YAMs there is no >> way to find out that e.g. a leafref points at something derived from a grouping. > > Validation including type checking is performed on instance XML > documents where this information is not available anyway. An > instance-identifier points to a concrete data node whose presence can be > directly checked for. Everything else is quite complicated - how would > you specify an XPath expression pointing to a complex type that has no > corresponding node in the data tree? > > YANG is much closer to an XML schema language than to a programming > language and I think it should stay this way. > Yes -- I know the IETF does not work on APIs, but this seems like a problem for the code generators to solve. It there was some sort of class hierarchy (from NETCONF session to content) myitf = session.interfaces.interface.get_config(name='eth0'); status = session.interfaces.interface.reset(name='eth0'); Extensions could be used to declare a method. Access control and normal processing give the illusion the rpc is coupled to the data. module interfaces { rpc reset { x:method /interfaces/interface; input { leaf name { ... } } } container interfaces { list interface { ... } } } then would this be good enough? Could something like this be standardized at all? (I know the callingPoint mechanism is similar, but not quite the same as this 'method' extension.) > Lada > Andy From phil@juniper.net Thu Jul 23 07:20:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2464C3A6B79 for ; Thu, 23 Jul 2009 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 CL9+GUat0+Ll for ; Thu, 23 Jul 2009 07:20:10 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 8FDF13A6B77 for ; Thu, 23 Jul 2009 07:20:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSmhxX19Cp6KEb+2faJliau2IteZYFinP@postini.com; Thu, 23 Jul 2009 07:20:11 PDT 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.375.2; Thu, 23 Jul 2009 07:12:39 -0700 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, 23 Jul 2009 07:12:39 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 07:12:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 07:12:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6NECcd06522; Thu, 23 Jul 2009 07:12:38 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6NE1F3A068382; Thu, 23 Jul 2009 14:01:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907231401.n6NE1F3A068382@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A685D08.7060808@netconfcentral.com> Date: Thu, 23 Jul 2009 10:01:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2009 14:12:38.0941 (UTC) FILETIME=[A29D64D0:01CA0B9F] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 14:20:11 -0000 Andy Bierman writes: >then would this be good enough? If you wanted this, you could do it by just tagging the input item: module interfaces { rpc reset { x:method-of name; input { leaf name { type leafref { path /interfaces/interface; } } } } container interfaces { list interface { ... } } } Your code generator sees "method-of name", looks up "name" in the input parameter list, finds the leafref to /interfaces/interface and adds it as a method of that class. And you'd still be able to invoke it as a normal netconf operation, with no changes to the netconf content. Only your local coders need to know that interfaces.interface has a method called reset. You could even: rpc reset-interface { x:method-of name { x:method-name reset; } } to distinquish the method name from the real RPC name. Anyhow the point is that you can add features for oo tool support without impacting other YANG users. Thanks, Phil From cfinss@dial.pipex.com Thu Jul 23 08:31:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF623A6941 for ; Thu, 23 Jul 2009 08:31:22 -0700 (PDT) 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 tO6b+7wuK-Vq for ; Thu, 23 Jul 2009 08:31:22 -0700 (PDT) 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 F39F03A6783 for ; Thu, 23 Jul 2009 08:31:21 -0700 (PDT) X-Trace: 269846876/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.82/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.82 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: 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: AhUFACMeaEo+vGlS/2dsb2JhbACDLFqMJsJzCYQEBQ X-IronPort-AV: E=Sophos;i="4.43,255,1246834800"; d="scan'208";a="269846876" X-IP-Direction: IN Received: from 1cust82.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.82]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Jul 2009 16:28:05 +0100 Message-ID: <006d01ca0ba1$bc1344a0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <20090713200001.43E1F3A69FC@core3.amsl.com><4A65EC7A.1060008@ericsson.com> <20090722.000948.206458951.mbj@tail-f.com> Date: Thu, 23 Jul 2009 16:23:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 15:31:23 -0000 Martin Some wordings that have bugged me for a while. 5.1 ..."by using the enterprise or organization name as a prefix." Do you really mean prefix? only I think of prefix as shorthand and while IBM, Cisco or HP might qualify, other organization names would not. 5.5 .."searches up the levels of hierarchy in the schema tree" levels of hierarchy has a suggestion of all the nodes at a level whereas I think that this means search the path to the root. 6 " YANG modules are written in the UTF-8 [RFC3629] character set." UTF-8 is not a character set in the lexicons I use; character encoding, transfer format, character syntax but not character set. 6.1.3 "up to at most the column of the double quote character." seems imprecise, leaving the option of everything up to or some way short of or whatever an implementation chooses " \\ a single backslash" so is a double backslash \\\ or \\\\ - worth an example 6.2.1 "All groupings defined within a parent node " well no, grouping names, otherwise it sounds like the identifiers defined within the grouping. 7.1.3 "with the exception of data node identifiers defined inside a grouping " well, only when they are 'uses'd in another module; needs adding IMO 9.9.2 "Predicates are used only for constraining the values for the key nodes for list entries" or leaflists? Tom Petch From phil@juniper.net Thu Jul 23 09:01:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D874C3A68A0 for ; Thu, 23 Jul 2009 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 FvUMzU+7PP48 for ; Thu, 23 Jul 2009 09:01:31 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 5837E3A69F8 for ; Thu, 23 Jul 2009 09:01:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSmiJHRXONGgcGr2sTlFQVF/8K4j9dMJu@postini.com; Thu, 23 Jul 2009 09:01:31 PDT 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.375.2; Thu, 23 Jul 2009 08:51:55 -0700 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, 23 Jul 2009 08:51:55 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 08:51:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 08:51:54 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6NFprd54417; Thu, 23 Jul 2009 08:51:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6NFeU6F069553; Thu, 23 Jul 2009 15:40:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907231540.n6NFeU6F069553@idle.juniper.net> To: "tom.petch" In-Reply-To: <006d01ca0ba1$bc1344a0$0601a8c0@allison> Date: Thu, 23 Jul 2009 11:40:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2009 15:51:54.0117 (UTC) FILETIME=[802D2350:01CA0BAD] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 16:01:32 -0000 "tom.petch" writes: >5.1 ..."by using the enterprise or organization name as a prefix." >Do you really mean prefix? only I think of prefix as shorthand and while IBM, >Cisco or HP might qualify, other organization names would not. We tried to use java-style reverse dns names, but it didn't fly. >6.1.3 "up to at most the column of the double quote character." >seems imprecise, leaving the option of everything up to or some way short of or >whatever an implementation chooses I think the intent is to make this trimming optional. Great comments! Thanks, Phil From mehmet.ersue@nsn.com Thu Jul 23 11:29:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D7D3A6A84 for ; Thu, 23 Jul 2009 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIdZpGko4XXR for ; Thu, 23 Jul 2009 11:29:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F0A4328C14F for ; Thu, 23 Jul 2009 11:28:49 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6NIS9GC025317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jul 2009 20:28:09 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6NIS9TE022999; Thu, 23 Jul 2009 20:28:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 20:28:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0BC3.53BB5A69" Date: Thu, 23 Jul 2009 20:28:08 +0200 Message-ID: In-Reply-To: <4A6720DB.5090002@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoK2OWPts3P+5TKRnKKGE5rh924WAA5+Cww References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net><4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> <4A6720DB.5090002@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Balazs Lengyel" X-OriginalArrivalTime: 23 Jul 2009 18:28:08.0821 (UTC) FILETIME=[53EF7250:01CA0BC3] Cc: netmod@ietf.org Subject: Re: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 18:29:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0BC3.53BB5A69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I like groupings and they are appropriate for many of our modeling=20 work.=20 But I also believe strongly that complex types are a useful option=20 for straightforward modeling when people have managed objects=20 with complex types in mind.=20 Well, I agree that some of us don't use them and think they are=20 not necessary. But I also know clearly that many of us use complex types and=20 type-safe modeling extensively. I would like to enable complex types also for YANG-based modeling=20 and NETCONF-based configuration. > I did not find that the 'complex-type' and 'element' constructs > made the IPFIX data model even slightly easier to understand. I think this a subjective impression which accept fully.=20 OTOH based on the feedback we got some of us seem to think that=20 the IPFIX model prepared with complex types is at least easier to=20 read and more straightforward to model. We summarized the benefits for the use of complex types in the draft. Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Wednesday, July 22, 2009 4:23 PM > To: Balazs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] FW:I-D=20 > Action:draft-linowski-netmod-yang-abstract-00.txt >=20 > Balazs Lengyel wrote: > > Hello Andy, > > So you are saying, using complex types is more complicated.=20 > You wanted > > to use complex types, but later abandoned it due to implementation > > complexity. > >=20 > > A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard > > organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find,=20 > that for the > > human user it is easier to think in terms of Managed objects with > > complex types then in terms of groupings. > >=20 > > Also we stated somewhere that readers are the most=20 > important community. > > I think we should not block this effort. >=20 > I am not in favor or turning YANG into XSD, > with elements and element lists mixed in > with the containers and lists. I think YANG mechanisms > are sufficient, and the proposed mechanisms do > not add any important new functionality. Instead, they add more > ways to do the same things already supported by YANG. >=20 > I think we should finish YANG 1.0 and start using it. > I don't see a need to delay YANG further, or > to start working on a replacement for it. >=20 > I did not find that the 'complex-type' and 'element' constructs > made the IPFIX data model even slightly easier to understand. >=20 > > Balazs >=20 > Andy >=20 > >=20 > > Andy Bierman wrote: > >> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > >>> Hi All, > >>> > >>> please find below the -00 draft we submitted on=20 > "Extending YANG with > >>> Language Abstractions". > >>> This is an early draft and needs some discussion for further > >>> development. > >>> Please give us your comments. > >>> > >> > >> The new constructs that are proposed seem to overlap the > >> YANG grouping and uses statements a great deal. > >> > >> Before YANG, I implemented something called NCX > >> which had complex types, and every node > >> had a type. Every node also formed a containment > >> layer, even choices, because the type was a complete > >> abstraction, and what if it changed from a list to a choice? > >> > >> I found that the complexity level in the agent callback > >> structure went up a lot because of this abstraction. > >> > >> At first I did not like YANG groupings, because they are so > >> much more fragile and 'hands-on' than complex types. > >> You must control the containment layering and refinements. > >> It is not handled automatically like with complex types. > >> > >> But now I think that groupings are more appropriate for > >> embedded systems, and align better with traditional > >> agent callback design. > >> > >>> Regards, > >>> Bernd > >>> > >> > >> > >> Andy > >> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org > >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > >>> Internet-Drafts@ietf.org > >>> Sent: Monday, July 06, 2009 9:00 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> Title : Extending YANG with Language Abstractions > >>> Author(s) : B. Linowski, M. Ersue > >>> Filename : draft-linowski-netmod-yang-abstract-00.txt > >>> Pages : 42 > >>> Date : 2009-07-06 > >>> > >>> YANG - the NETCONF Data Modeling Language - supports modeling of a > >>> tree of data elements that represent the configuration and runtime > >>> status of a particular network element managed via NETCONF. This > >>> memo suggests to enhance YANG with supplementary modeling features > >>> and language abstractions with the aim to improve the model > >>> extensibility and reuse. > >>> > >>> A URL for this Internet-Draft is: > >>>=20 > http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang > -abstract- > >>> 00.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> > >>> > >>>=20 > -------------------------------------------------------------- > ---------- > >>> > >>> _______________________________________________ > >>> 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 > >> > >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 ------_=_NextPart_001_01CA0BC3.53BB5A69 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [netmod] FW:I-D = Action:draft-linowski-netmod-yang-abstract-00.txt

Hi,

I like groupings = and they are appropriate for many of our modeling
work. =

But I also believe = strongly that complex types are a useful option
for = straightforward modeling when people have managed objects
with complex types = in mind.

Well, I agree that = some of us don't use them and think they are
not = necessary.
But I also know = clearly that many of us use complex types and
type-safe modeling = extensively.

I would like to = enable complex types also for YANG-based modeling
and NETCONF-based = configuration.

> I did not find = that the 'complex-type' and 'element' constructs
> made the = IPFIX data model even slightly easier to understand.

I think this a = subjective impression which accept fully.
OTOH based on the = feedback we got some of us seem to think that
the IPFIX model = prepared with complex types is at least easier to
read and more = straightforward to model.
We summarized the = benefits for the use of complex types in the draft.

Cheers,
Mehmet
 

> -----Original = Message-----
> From: = netmod-bounces@ietf.org
> = [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy = Bierman
> Sent: = Wednesday, July 22, 2009 4:23 PM
> To: Balazs = Lengyel
> Cc: = netmod@ietf.org
> Subject: Re: = [netmod] FW:I-D
> = Action:draft-linowski-netmod-yang-abstract-00.txt
>
> Balazs Lengyel = wrote:
> > Hello = Andy,
> > So you are = saying, using complex types is more complicated.
> You = wanted
> > to use = complex types, but later abandoned it due to = implementation
> > = complexity.
> > =
> > A lot of = people (Ericsson, NSN, S3 a Netconf vendor) and standard
> > = organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find,
> that for = the
> > human user = it is easier to think in terms of Managed objects with
> > complex = types then in terms of groupings.
> > =
> > Also we = stated somewhere that readers are the most
> important = community.
> > I think we = should not block this effort.
>
> I am not in = favor or turning YANG into XSD,
> with elements = and element lists mixed in
> with the = containers and lists.  I think YANG mechanisms
> are sufficient, = and the proposed mechanisms do
> not add any = important new functionality.   Instead, they add = more
> ways to do the = same things already supported by YANG.
>
> I think we = should finish YANG 1.0 and start using it.
> I don't see a = need to delay YANG further, or
> to start = working on a replacement for it.
>
> I did not find = that the 'complex-type' and 'element' constructs
> made the IPFIX = data model even slightly easier to understand.
>
> > = Balazs
>
> = Andy
>
> > =
> > Andy = Bierman wrote:
> >> = Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote:
> >>> Hi = All,
> = >>>
> >>> = please find below the -00 draft we submitted on
> "Extending = YANG with
> >>> = Language Abstractions".
> >>> = This is an early draft and needs some discussion for = further
> >>> = development.
> >>> = Please give us your comments.
> = >>>
> = >>
> >> The = new constructs that are proposed seem to overlap the
> >> YANG = grouping and uses statements a great deal.
> = >>
> >> Before = YANG, I implemented something called NCX
> >> which = had complex types, and every node
> >> had a = type.  Every node also formed a containment
> >> layer, = even choices, because the type was a complete
> >> = abstraction, and what if it changed from a list to a = choice?
> = >>
> >> I = found that the complexity level in the agent callback
> >> = structure went up a lot because of this abstraction.
> = >>
> >> At = first I did not like YANG groupings, because they are so
> >> much = more fragile and 'hands-on' than complex types.
> >> You = must control the containment layering and refinements.
> >> It is = not handled automatically like with complex types.
> = >>
> >> But = now I think that groupings are more appropriate for
> >> = embedded systems, and align better with traditional
> >> agent = callback design.
> = >>
> >>> = Regards,
> >>> = Bernd
> = >>>
> = >>
> = >>
> >> = Andy
> = >>
> >>> = -----Original Message-----
> >>> = From: i-d-announce-bounces@ietf.org
> >>> = [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of = ext
> >>> = Internet-Drafts@ietf.org
> >>> = Sent: Monday, July 06, 2009 9:00 PM
> >>> = To: i-d-announce@ietf.org
> >>> = Subject: I-D = Action:draft-linowski-netmod-yang-abstract-00.txt
> >>> A = New Internet-Draft is available from the on-line = Internet-Drafts
> >>> = directories.
> = >>>
> = >>>     = Title           : = Extending YANG with Language Abstractions
> = >>>     = Author(s)       : B. Linowski, M. = Ersue
> = >>>     = Filename        : = draft-linowski-netmod-yang-abstract-00.txt
> = >>>     = Pages           : = 42
> = >>>     = Date            : = 2009-07-06
> = >>>
> >>> = YANG - the NETCONF Data Modeling Language - supports modeling of = a
> >>> = tree of data elements that represent the configuration and = runtime
> >>> = status of a particular network element managed via NETCONF.  = This
> >>> = memo suggests to enhance YANG with supplementary modeling = features
> >>> = and language abstractions with the aim to improve the = model
> >>> = extensibility and reuse.
> = >>>
> >>> A = URL for this Internet-Draft is:
> >>> =
> = <= SPAN LANG=3D"de">http://www.ietf.org/internet-drafts/draft-linowski-netmod-= yang
> = -abstract-
> >>> = 00.txt
> = >>>
> >>> = Internet-Drafts are also available by anonymous FTP at:
> >>> = ftp://ftp.ietf.org/internet-drafts/<= SPAN LANG=3D"de">
> = >>>
> >>> = Below is the data which will enable a MIME compliant mail = reader
> >>> = implementation to automatically retrieve the ASCII version of = the
> >>> = Internet-Draft.
> = >>>
> = >>>
> >>> =
> = --------------------------------------------------------------
> = ----------
> = >>>
> >>> = _______________________________________________
> >>> = 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
>

------_=_NextPart_001_01CA0BC3.53BB5A69-- From mehmet.ersue@nsn.com Thu Jul 23 11:29:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961F53A63C9 for ; Thu, 23 Jul 2009 11:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnchsP1C5gYV for ; Thu, 23 Jul 2009 11:29:15 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 5479B28C15B for ; Thu, 23 Jul 2009 11:29:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6NIScED025912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jul 2009 20:28:38 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6NISccw032386; Thu, 23 Jul 2009 20:28:38 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 20:28:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0BC3.6519BEEF" Date: Thu, 23 Jul 2009 20:28:37 +0200 Message-ID: In-Reply-To: <4A6817AE.8000906@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoLbZyJItCuByVSS7Wm+n9nLTvYzAAVGEKA References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com><4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com><1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" , "Ladislav Lhotka" X-OriginalArrivalTime: 23 Jul 2009 18:28:38.0023 (UTC) FILETIME=[65575170:01CA0BC3] Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 18:29:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0BC3.6519BEEF Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Hi Balazs, thank you for pointing this out. We indeed have a lot to do and the -00 draft is for sure=20 not complete.=20 Actions/rpcs in groupings/lists and type information on=20 groupings are features we definitely need. We would be happy to have your suggestions and input.=20 Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Balazs Lengyel > Sent: Thursday, July 23, 2009 9:57 AM > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] FW:=20 > I-DAction:draft-linowski-netmod-yang-abstract-00.txt >=20 > Hello, > The two main points I am missing are > - actions/rpcs in groupings/lists > - type information on groupings/lists. Unless you do a deep=20 > analysis of the YAMs there is no=20 > way to find out that e.g. a leafref points at something=20 > derived from a grouping. >=20 > I don't believe anyone wants to enforce object orientation in YANG. > Balazs >=20 > Ladislav Lhotka wrote: > > David French p=ED=B9e v St 22. 07. 2009 v 17:59 +0200: > >> Hi, > >> > >> Just to add to Balazs mention, our (S3 / embeddedMIND) > >> experience has also been that an emphasis on managed object > >> hierarchy concepts when modelling rather than > >> Yang-style groupings leads to a more straightforward mapping > >> and lower integration costs with the applications on the device. > >=20 > > Why is YANG insufficient for modelling such object=20 > hierarchies? In fact, > > YANG allows for "multiple inheritance", which might be very=20 > useful - and > > safe, since we don't have to care about method lookup strategies. > >=20 > > Perhaps the difference is just that YANG doesn't *enforce* object > > orientation. > >=20 > > Lada > > =20 > >> Regards, > >> > >> David French > >> www.embeddedmind.com > >> > >> Balazs Lengyel wrote: > >>> Hello Andy, > >>> So you are saying, using complex types is more=20 > complicated. You wanted > >>> to use complex types, but later abandoned it due to implementation > >>> complexity. > >>> > >>> A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard > >>> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find,=20 > that for the > >>> human user it is easier to think in terms of Managed objects with > >>> complex types then in terms of groupings. > >>> > >>> Also we stated somewhere that readers are the most important > >>> community. I think we should not block this effort. > >>> Balazs > >>> > >>> Andy Bierman wrote: > >>>> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > >>>>> Hi All, > >>>>> > >>>>> please find below the -00 draft we submitted on=20 > "Extending YANG with > >>>>> Language Abstractions". > >>>>> This is an early draft and needs some discussion for further > >>>>> development. > >>>>> Please give us your comments. > >>>>> > >>>> The new constructs that are proposed seem to overlap the > >>>> YANG grouping and uses statements a great deal. > >>>> > >>>> Before YANG, I implemented something called NCX > >>>> which had complex types, and every node > >>>> had a type. Every node also formed a containment > >>>> layer, even choices, because the type was a complete > >>>> abstraction, and what if it changed from a list to a choice? > >>>> > >>>> I found that the complexity level in the agent callback > >>>> structure went up a lot because of this abstraction. > >>>> > >>>> At first I did not like YANG groupings, because they are so > >>>> much more fragile and 'hands-on' than complex types. > >>>> You must control the containment layering and refinements. > >>>> It is not handled automatically like with complex types. > >>>> > >>>> But now I think that groupings are more appropriate for > >>>> embedded systems, and align better with traditional > >>>> agent callback design. > >>>> > >>>>> Regards, > >>>>> Bernd > >>>>> > >>>> > >>>> Andy > >>>> > >>>>> -----Original Message----- > >>>>> From: i-d-announce-bounces@ietf.org > >>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > >>>>> Internet-Drafts@ietf.org > >>>>> Sent: Monday, July 06, 2009 9:00 PM > >>>>> To: i-d-announce@ietf.org > >>>>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > >>>>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts > >>>>> directories. > >>>>> > >>>>> Title : Extending YANG with Language Abstractions > >>>>> Author(s) : B. Linowski, M. Ersue > >>>>> Filename : draft-linowski-netmod-yang-abstract-00.txt > >>>>> Pages : 42 > >>>>> Date : 2009-07-06 > >>>>> > >>>>> YANG - the NETCONF Data Modeling Language - supports=20 > modeling of a > >>>>> tree of data elements that represent the configuration=20 > and runtime > >>>>> status of a particular network element managed via=20 > NETCONF. This > >>>>> memo suggests to enhance YANG with supplementary=20 > modeling features > >>>>> and language abstractions with the aim to improve the model > >>>>> extensibility and reuse. > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>>=20 > http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang > -abstract- > >>>>> > >>>>> 00.txt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> Below is the data which will enable a MIME compliant mail reader > >>>>> implementation to automatically retrieve the ASCII=20 > version of the > >>>>> Internet-Draft. > >>>>> > >>>>> > >>>>>=20 > -------------------------------------------------------------- > ---------- > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >> --=20 > >> > >> ----------------------------------- > >> David French, VP Product Management > >> Management Infrastructure for Networked Devices > >> www.embeddedmind.com > >> +48 71 3348174 (use email not voicemail) > >> > >> http://www.s3group.com/legal/ > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email:=20 > Balazs.Lengyel@ericsson.com > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 ------_=_NextPart_001_01CA0BC3.6519BEEF Content-Type: text/html; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable RE: [netmod] FW: = I-DAction:draft-linowski-netmod-yang-abstract-00.txt

Hi = Balazs,

thank you for = pointing this out.

We indeed have a = lot to do and the -00 draft is for sure
not complete. =

Actions/rpcs in = groupings/lists and type information on
groupings are = features we definitely need.
We would be happy = to have your suggestions and input.

Cheers,
Mehmet
 

> -----Original = Message-----
> From: = netmod-bounces@ietf.org
> = [mailto:netmod-bounces@ietf.org] On Behalf Of ext Balazs = Lengyel
> Sent: Thursday, = July 23, 2009 9:57 AM
> To: Ladislav = Lhotka
> Cc: = netmod@ietf.org
> Subject: Re: = [netmod] FW:
> = I-DAction:draft-linowski-netmod-yang-abstract-00.txt
>
> = Hello,
> The two main = points I am missing are
> - actions/rpcs = in groupings/lists
> - type = information on groupings/lists. Unless you do a deep
> analysis of the = YAMs there is no
> way to find out = that e.g. a leafref points at something
> derived from a = grouping.
>
> I don't believe = anyone wants to enforce object orientation in YANG.
> = Balazs
>
> Ladislav Lhotka = wrote:
> > David = French p=ED=B9e v St 22. 07. 2009 v 17:59 +0200:
> >> = Hi,
> = >>
> >> Just = to add to Balazs mention, our (S3 / embeddedMIND)
> >> = experience has also been that an emphasis on managed = object
> >> = hierarchy concepts when modelling rather than
> >> = Yang-style groupings leads to a more straightforward = mapping
> >> and = lower integration costs with the applications on the = device.
> > =
> > Why is = YANG insufficient for modelling such object
> hierarchies? In = fact,
> > YANG = allows for "multiple inheritance", which might be very =
> useful - = and
> > safe, = since we don't have to care about method lookup = strategies.
> > =
> > Perhaps = the difference is just that YANG doesn't *enforce* object
> > = orientation.
> > =
> > = Lada
> >  =
> >> = Regards,
> = >>
> >> David = French
> >> = www.embeddedmind.com
> = >>
> >> Balazs = Lengyel wrote:
> >>> = Hello Andy,
> >>> So = you are saying, using complex types is more
> complicated. = You wanted
> >>> to = use complex types, but later abandoned it due to = implementation
> >>> = complexity.
> = >>>
> >>> A = lot of people (Ericsson, NSN, S3 a Netconf vendor) and = standard
> >>> = organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find,
> that for = the
> >>> = human user it is easier to think in terms of Managed objects = with
> >>> = complex types then in terms of groupings.
> = >>>
> >>> = Also we stated somewhere that readers are the most = important
> >>> = community. I think we should not block this effort.
> >>> = Balazs
> = >>>
> >>> = Andy Bierman wrote:
> = >>>> Linowski, Bernd (EXT-Other - DE/Dusseldorf) = wrote:
> = >>>>> Hi All,
> = >>>>>
> = >>>>> please find below the -00 draft we submitted on =
> "Extending = YANG with
> = >>>>> Language Abstractions".
> = >>>>> This is an early draft and needs some discussion = for further
> = >>>>> development.
> = >>>>> Please give us your comments.
> = >>>>>
> = >>>> The new constructs that are proposed seem to overlap = the
> = >>>> YANG grouping and uses statements a great = deal.
> = >>>>
> = >>>> Before YANG, I implemented something called = NCX
> = >>>> which had complex types, and every node
> = >>>> had a type.  Every node also formed a = containment
> = >>>> layer, even choices, because the type was a = complete
> = >>>> abstraction, and what if it changed from a list to a = choice?
> = >>>>
> = >>>> I found that the complexity level in the agent = callback
> = >>>> structure went up a lot because of this = abstraction.
> = >>>>
> = >>>> At first I did not like YANG groupings, because they = are so
> = >>>> much more fragile and 'hands-on' than complex = types.
> = >>>> You must control the containment layering and = refinements.
> = >>>> It is not handled automatically like with complex = types.
> = >>>>
> = >>>> But now I think that groupings are more appropriate = for
> = >>>> embedded systems, and align better with = traditional
> = >>>> agent callback design.
> = >>>>
> = >>>>> Regards,
> = >>>>> Bernd
> = >>>>>
> = >>>>
> = >>>> Andy
> = >>>>
> = >>>>> -----Original Message-----
> = >>>>> From: i-d-announce-bounces@ietf.org
> = >>>>> [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of = ext
> = >>>>> Internet-Drafts@ietf.org
> = >>>>> Sent: Monday, July 06, 2009 9:00 PM
> = >>>>> To: i-d-announce@ietf.org
> = >>>>> Subject: I-D = Action:draft-linowski-netmod-yang-abstract-00.txt
> = >>>>> A New Internet-Draft is available from the on-line =
> = Internet-Drafts
> = >>>>> directories.
> = >>>>>
> = >>>>>     = Title           : = Extending YANG with Language Abstractions
> = >>>>>     = Author(s)       : B. Linowski, M. = Ersue
> = >>>>>     = Filename        : = draft-linowski-netmod-yang-abstract-00.txt
> = >>>>>     = Pages           : = 42
> = >>>>>     = Date            : = 2009-07-06
> = >>>>>
> = >>>>> YANG - the NETCONF Data Modeling Language - = supports
> modeling of = a
> = >>>>> tree of data elements that represent the = configuration
> and = runtime
> = >>>>> status of a particular network element managed via =
> NETCONF.  = This
> = >>>>> memo suggests to enhance YANG with supplementary =
> modeling = features
> = >>>>> and language abstractions with the aim to improve = the model
> = >>>>> extensibility and reuse.
> = >>>>>
> = >>>>> A URL for this Internet-Draft is:
> = >>>>>
> = <= SPAN LANG=3D"de">http://www.ietf.org/internet-drafts/draft-linowski-netmod-= yang
> = -abstract-
> = >>>>>
> = >>>>> 00.txt
> = >>>>>
> = >>>>> Internet-Drafts are also available by anonymous FTP = at:
> = >>>>> ftp://ftp.ietf.org/internet-drafts/<= SPAN LANG=3D"de">
> = >>>>>
> = >>>>> Below is the data which will enable a MIME = compliant mail reader
> = >>>>> implementation to automatically retrieve the ASCII =
> version of = the
> = >>>>> Internet-Draft.
> = >>>>>
> = >>>>>
> = >>>>>
> = --------------------------------------------------------------
> = ----------
> = >>>>>
> = >>>>>
> = >>>>> = _______________________________________________
> = >>>>> 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
> = >>>>
> >> -- =
> = >>
> >> = -----------------------------------
> >> David = French, VP Product Management
> >> = Management Infrastructure for Networked Devices
> >> = www.embeddedmind.com
> >> +48 71 = 3348174 (use email not voicemail)
> = >>
> >> = http://www.s3group.com/legal/
> >> = _______________________________________________
> >> netmod = mailing list
> >> = netmod@ietf.org
> >> = https://www.ietf.org/mailman/listinfo/netmod
>
> -- =
> Balazs = Lengyel           =             = Ericsson Hungary Ltd.
> System = Manager
> ECN: 831 = 7320           &nb= sp;            = 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
>

------_=_NextPart_001_01CA0BC3.6519BEEF-- From mehmet.ersue@nsn.com Thu Jul 23 11:54:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB233A6BD3 for ; Thu, 23 Jul 2009 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.41 X-Spam-Level: X-Spam-Status: No, score=-4.41 tagged_above=-999 required=5 tests=[AWL=2.189, 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 IgEfgL+UNb3I for ; Thu, 23 Jul 2009 11:54:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id F422F28C14F for ; Thu, 23 Jul 2009 11:54:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6NIPqhN029991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jul 2009 20:25:52 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6NIPqHU029255; Thu, 23 Jul 2009 20:25:52 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 20:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jul 2009 20:25:50 +0200 Message-ID: In-Reply-To: <200907221852.30430.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Regarding draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoK83oV0oTL8F50RdyaDrBNg9+JNAAycrvw References: <200907221522.n6MFMp2d058153@idle.juniper.net> <200907221852.30430.david.partain@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Partain" , X-OriginalArrivalTime: 23 Jul 2009 18:25:51.0656 (UTC) FILETIME=[022DBA80:01CA0BC3] Subject: Re: [netmod] Regarding draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 18:54:09 -0000 Hi All, sorry for not stating it more clearly on the NETMOD maillist=20 earlier.=20 As discussed with the chairs we don't want to disturb the=20 development of YANG 1.0. This is the reason why we waited=20 until WGLC of the chartered YANG specification work. It might be still a bit early but after having finalized the=20 YANG development mostly I think it is the right time to start the discussion on new YANG features, which are useful and=20 interesting to develop soon. Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext David Partain > Sent: Wednesday, July 22, 2009 6:53 PM > To: netmod@ietf.org > Subject: [netmod] Regarding draft-linowski-netmod-yang-abstract-00.txt >=20 > Hi, >=20 > My co-chair is currently on vacation, but I think I'm=20 > speaking for both of=20 > us... >=20 > This draft is NOT a working group item. It is on the agenda=20 > because we (1)=20 > have time and (2) there are people in the NETMOD working=20 > group who want to=20 > gauge interest and perhaps work more together after Stockholm. =20 >=20 > However, the fact that this is on the agenda should not be=20 > interpreted to=20 > mean "We're considering re-chartering to include this right=20 > now." While I=20 > don't get to decide such things alone, I will strenuously=20 > oppose any such=20 > action right now. >=20 > We will finish our currently-chartered items before we=20 > consider re-chartering=20 > to include ANY new work. That includes this draft and the=20 > SMI draft by=20 > Juergen and any other NETMOD-related draft. We have a set of=20 > deadlines that=20 > I intend to do my utmost to see that we meet. Adding new=20 > work now would not=20 > be helpful in doing so. >=20 > Cheers, >=20 > David >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From andy@netconfcentral.com Thu Jul 23 12:02:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043893A6B0A for ; Thu, 23 Jul 2009 12:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 6lFOfVJILifr for ; Thu, 23 Jul 2009 12:02:12 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 253623A6855 for ; Thu, 23 Jul 2009 12:02:12 -0700 (PDT) Received: (qmail 18148 invoked from network); 23 Jul 2009 19:00:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2009 19:00:25 -0000 X-YMail-OSG: 2nO1nYEVM1kOi180iwjZ3rU3sCiAv.jd4N8IM9zbasnvO3yxsWxV5bfWUEhuCh7EvjjxokgUdx_wxQb6VtP9eusvxEMlSf8Bgb9aUu3rsLxlC0XyHmYP7fHXwQnrqEyMY9qfK_Eor86KjGfcBrZvZaHTTKOFllLZte_Fe7kYhJgFr8wTycSb1IADii8kWnwWPgBg7Vv_ypz7iTZHcN3NWRoSt0H71o6Yn72K34EVlQvWPju_D4ACRRyH6w_sTROy5NyAhhZC1jSF5paw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A68B359.9040802@netconfcentral.com> Date: Thu, 23 Jul 2009 12:00:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com><4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com><1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 19:02:13 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Balazs, > > thank you for pointing this out. > > We indeed have a lot to do and the -00 draft is for sure > not complete. > > Actions/rpcs in groupings/lists and type information on > groupings are features we definitely need. > We would be happy to have your suggestions and input. > Hi, Didn't we do a requirements gathering phase of some sort, in order to get to the point where charter decisions were made, so that the NETMOD WG could proceed and finish in finite time? I believe the consensus at the time was that we did not want an OO data modeling language and we choose YANG over several other proposals, including the OO proposal from your co-author. It is rather subjective to start comparing comfort-levels with 1 variant of the IPFIX model or another. I doubt we could reach agreement in the IETF on a data modeling language that had enough OO programming language features to make a real difference. I prefer to get a stable YANG 1.0 deployed, and start defining some standard content. IMO, the DML used would not make much difference at all if I were deciding whether to implement the IPFIX model or not. > Cheers, > Mehmet > Andy From mbj@tail-f.com Thu Jul 23 14:31:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85203A6AFE for ; Thu, 23 Jul 2009 14:31:46 -0700 (PDT) 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 Cq52Wl9utNli for ; Thu, 23 Jul 2009 14:31:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2237B3A6A74 for ; Thu, 23 Jul 2009 14:31:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DAE6776C54E; Thu, 23 Jul 2009 23:31:44 +0200 (CEST) Date: Thu, 23 Jul 2009 23:31:44 +0200 (CEST) Message-Id: <20090723.233144.192180203.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: <4A66F259.7090002@ericsson.com> <4A6720DB.5090002@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Thu, 23 Jul 2009 21:31:47 -0000 Hi, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > I like groupings and they are appropriate for many of our modeling > work. > > But I also believe strongly that complex types are a useful option > for straightforward modeling when people have managed objects > with complex types in mind. > > Well, I agree that some of us don't use them and think they are > not necessary. It seems you are saying that using complex types is just a different way of doing what can already be done. Some people find models with complex types easier to read, and some people find them harder to read. I don't like the idea of introducing new alternative ways of doing what we already do. This just adds complexity to the language. Even if you think models with complex types are easier to read, the result will be that some models use complex types and others don't, so the net result will not be easier to understand. /martin From bernd.linowski.ext@nsn.com Fri Jul 24 01:30:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C723A680F for ; Fri, 24 Jul 2009 01:30:23 -0700 (PDT) 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 wzOloEUOx+am for ; Fri, 24 Jul 2009 01:30:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 292153A657C for ; Fri, 24 Jul 2009 01:30:20 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6O8Ejt5023389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2009 10:14:45 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6O8EiK4023035; Fri, 24 Jul 2009 10:14:45 +0200 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 10:13:49 +0200 Received: from FIESEXC030.nsn-intra.net ([10.135.48.16]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 11:13:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jul 2009 11:13:47 +0300 Message-ID: <2E23AE0E4AED07418C26486630C852A02D8ED0@FIESEXC030.nsn-intra.net> In-Reply-To: <1248345037.4674.64.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoLgOYzy1otTWubTOeP9ScdmCWRjAAslgbQ References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net><4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com><4A673764.7070804@s3group.com> <1248331496.4674.25.camel@missotis><4A6817AE.8000906@ericsson.com> <1248345037.4674.64.camel@missotis> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: "ext Ladislav Lhotka" , "Balazs Lengyel" , X-OriginalArrivalTime: 24 Jul 2009 08:13:48.0849 (UTC) FILETIME=[AC17D210:01CA0C36] Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Fri, 24 Jul 2009 08:30:23 -0000 =20 Hi, Ladislav Lhotka wrote: > Sent: Thursday, July 23, 2009 12:31 PM > To: Balazs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] FW: I-D=20 > Action:draft-linowski-netmod-yang-abstract-00.txt >=20 > Balazs Lengyel p=ED=B9e v =C8t 23. 07. 2009 v 09:56 +0200: > > Hello, > > The two main points I am missing are > > - actions/rpcs in groupings/lists >=20 > Hmm, do you mean something like methods? Bernd & Mehmet's=20 > draft does not > propose anything like this (yet) but IMO without support for late > binding it is just unnecessary syntactic sugar. >=20 We haven't covered actions/rpcs in complex-types simply because of lack time. Having an action defined in the scope of the target of that action would improves clarity in some cases imho (e.g. having a "witch-group" action as part of a "protection-group" = complex type would tell that this action may be applied only to protection groups) Balazs Lengyel p=ED=B9e wrote: > > - type information on groupings/lists. Unless you do a deep=20 > analysis of the YAMs there is no=20 > > way to find out that e.g. a leafref points at something=20 > derived from a grouping. >=20 I agree with Balazs here.=20 The typed instance identifier addresses this by explicitly including the = type of the target in the model. > Validation including type checking is performed on instance XML > documents where this information is not available anyway. An > instance-identifier points to a concrete data node whose=20 > presence can be > directly checked for. Everything else is quite complicated - how would > you specify an XPath expression pointing to a complex type that has no > corresponding node in the data tree? >=20 By including the type information in the model explicitly, what is done in the proposed typed instance identifier. > YANG is much closer to an XML schema language than to a programming > language and I think it should stay this way. Well, as soon as you describe behavior in a language - which YANG does already in form of rpc's and notifications - it is also an interface = description language. In that respect it goes already far beyond what XML schema does. - Bernd >=20 > Lada >=20 > >=20 > > I don't believe anyone wants to enforce object orientation in YANG. > > Balazs > >=20 > > Ladislav Lhotka wrote: > > > David French p=ED=B9e v St 22. 07. 2009 v 17:59 +0200: > > >> Hi, > > >> > > >> Just to add to Balazs mention, our (S3 / embeddedMIND) > > >> experience has also been that an emphasis on managed object > > >> hierarchy concepts when modelling rather than > > >> Yang-style groupings leads to a more straightforward mapping > > >> and lower integration costs with the applications on the device. > > >=20 > > > Why is YANG insufficient for modelling such object=20 > hierarchies? In fact, > > > YANG allows for "multiple inheritance", which might be=20 > very useful - and > > > safe, since we don't have to care about method lookup strategies. > > >=20 > > > Perhaps the difference is just that YANG doesn't *enforce* object > > > orientation. > > >=20 > > > Lada > > > =20 > > >> Regards, > > >> > > >> David French > > >> www.embeddedmind.com > > >> > > >> Balazs Lengyel wrote: > > >>> Hello Andy, > > >>> So you are saying, using complex types is more=20 > complicated. You wanted > > >>> to use complex types, but later abandoned it due to=20 > implementation > > >>> complexity. > > >>> > > >>> A lot of people (Ericsson, NSN, S3 a Netconf vendor)=20 > and standard > > >>> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM)=20 > find, that for the > > >>> human user it is easier to think in terms of Managed=20 > objects with > > >>> complex types then in terms of groupings. > > >>> > > >>> Also we stated somewhere that readers are the most important > > >>> community. I think we should not block this effort. > > >>> Balazs > > >>> > > >>> Andy Bierman wrote: > > >>>> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > > >>>>> Hi All, > > >>>>> > > >>>>> please find below the -00 draft we submitted on=20 > "Extending YANG with > > >>>>> Language Abstractions". > > >>>>> This is an early draft and needs some discussion for further > > >>>>> development. > > >>>>> Please give us your comments. > > >>>>> > > >>>> The new constructs that are proposed seem to overlap the > > >>>> YANG grouping and uses statements a great deal. > > >>>> > > >>>> Before YANG, I implemented something called NCX > > >>>> which had complex types, and every node > > >>>> had a type. Every node also formed a containment > > >>>> layer, even choices, because the type was a complete > > >>>> abstraction, and what if it changed from a list to a choice? > > >>>> > > >>>> I found that the complexity level in the agent callback > > >>>> structure went up a lot because of this abstraction. > > >>>> > > >>>> At first I did not like YANG groupings, because they are so > > >>>> much more fragile and 'hands-on' than complex types. > > >>>> You must control the containment layering and refinements. > > >>>> It is not handled automatically like with complex types. > > >>>> > > >>>> But now I think that groupings are more appropriate for > > >>>> embedded systems, and align better with traditional > > >>>> agent callback design. > > >>>> > > >>>>> Regards, > > >>>>> Bernd > > >>>>> > > >>>> > > >>>> Andy > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: i-d-announce-bounces@ietf.org > > >>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > > >>>>> Internet-Drafts@ietf.org > > >>>>> Sent: Monday, July 06, 2009 9:00 PM > > >>>>> To: i-d-announce@ietf.org > > >>>>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > > >>>>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts > > >>>>> directories. > > >>>>> > > >>>>> Title : Extending YANG with Language=20 > Abstractions > > >>>>> Author(s) : B. Linowski, M. Ersue > > >>>>> Filename :=20 > draft-linowski-netmod-yang-abstract-00.txt > > >>>>> Pages : 42 > > >>>>> Date : 2009-07-06 > > >>>>> > > >>>>> YANG - the NETCONF Data Modeling Language - supports=20 > modeling of a > > >>>>> tree of data elements that represent the=20 > configuration and runtime > > >>>>> status of a particular network element managed via=20 > NETCONF. This > > >>>>> memo suggests to enhance YANG with supplementary=20 > modeling features > > >>>>> and language abstractions with the aim to improve the model > > >>>>> extensibility and reuse. > > >>>>> > > >>>>> A URL for this Internet-Draft is: > > >>>>>=20 > http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang -abstract- > > >>>>> > > >>>>> 00.txt > > >>>>> > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>>> > > >>>>> Below is the data which will enable a MIME compliant=20 > mail reader > > >>>>> implementation to automatically retrieve the ASCII=20 > version of the > > >>>>> Internet-Draft. > > >>>>> > > >>>>> > > >>>>>=20 > -------------------------------------------------------------- > ---------- > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 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 > > >>>> > > >> --=20 > > >> > > >> ----------------------------------- > > >> David French, VP Product Management > > >> Management Infrastructure for Networked Devices > > >> www.embeddedmind.com > > >> +48 71 3348174 (use email not voicemail) > > >> > > >> http://www.s3group.com/legal/ > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > >=20 > --=20 > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mehmet.ersue@nsn.com Fri Jul 24 05:50:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E653A68D6 for ; Fri, 24 Jul 2009 05:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.313, 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 0WW97DI7JfA6 for ; Fri, 24 Jul 2009 05:50:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 601F13A6862 for ; Fri, 24 Jul 2009 05:50:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6OCnqqE000609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2009 14:49:53 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6OCnqhE032604; Fri, 24 Jul 2009 14:49:52 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 14:48:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jul 2009 14:48:52 +0200 Message-ID: In-Reply-To: <20090723.233144.192180203.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoL3PsCC64b3FWwTCaDtXWfv8uDyAAfDa7g References: <4A66F259.7090002@ericsson.com><4A6720DB.5090002@netconfcentral.com> <20090723.233144.192180203.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" X-OriginalArrivalTime: 24 Jul 2009 12:48:53.0160 (UTC) FILETIME=[196DD280:01CA0C5D] Cc: netmod@ietf.org Subject: Re: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Fri, 24 Jul 2009 12:50:03 -0000 Hi Martin, I think it is the feature richness which makes a modeling language successful. Different people will prepare their=20 YAM on different abstraction levels and will use different=20 language constructs based on their preferences. There might be models, where groupings are the most=20 appropriate construct to use, e.g. for the modeling=20 of structured data tables. Others will use complex=20 types _and_ groupings because they have a bigger amount=20 of modeling work to do. Their system and the huge amount=20 of data models makes it necessary to design in a top-down=20 manner and to do hierarchical modeling. I also can imagine that some of us will be interested to=20 use and derive their data models from industry standard information models. A language mapping at the interface=20 between the two models becomes important. I believe it will be useful to have YANG easier mappable=20 to other modeling languages. This will also enable easy adoption of IETF data models by other SDOs. I think it=20 is a good thing if TMF or 3GPP would be able to map YAMs=20 to their model easily or adopt and use YAMs as they are. Cheers, Mehmet =20 > -----Original Message----- > From: ext Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Thursday, July 23, 2009 11:32 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: andy@netconfcentral.com; balazs.lengyel@ericsson.com;=20 > netmod@ietf.org > Subject: Re: [netmod] FW:I-D=20 > Action:draft-linowski-netmod-yang-abstract-00.txt >=20 > Hi, >=20 > "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > I like groupings and they are appropriate for many of our modeling=20 > > work.=20 > >=20 > > But I also believe strongly that complex types are a useful option=20 > > for straightforward modeling when people have managed objects=20 > > with complex types in mind.=20 > >=20 > > Well, I agree that some of us don't use them and think they are=20 > > not necessary. >=20 > It seems you are saying that using complex types is just a different > way of doing what can already be done. Some people find models with > complex types easier to read, and some people find them harder to > read. =20 >=20 > I don't like the idea of introducing new alternative ways of doing > what we already do. This just adds complexity to the language. Even > if you think models with complex types are easier to read, the result > will be that some models use complex types and others don't, so the > net result will not be easier to understand. >=20 >=20 >=20 > /martin >=20 From mehmet.ersue@nsn.com Fri Jul 24 05:51:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6103F28C19F for ; Fri, 24 Jul 2009 05:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=-0.906, 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 ULP7KCxtxlwG for ; Fri, 24 Jul 2009 05:51:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2E2383A697D for ; Fri, 24 Jul 2009 05:51:22 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6OCoqsB000324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2009 14:50:52 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6OConuY020693; Fri, 24 Jul 2009 14:50:52 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 14:50:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jul 2009 14:50:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf][netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoLx9cJNsogs+qwRd2T5H3A+n5GvgAD/nAQACFaqZA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 24 Jul 2009 12:50:47.0067 (UTC) FILETIME=[5D52A6B0:01CA0C5D] Subject: [netmod] FW: [Netconf] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Fri, 24 Jul 2009 12:51:23 -0000 =20 Hi Andy, From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 > Ersue, Mehmet (NSN - DE/Munich) wrote: > >=20 > > Hi Balazs, > >=20 > > thank you for pointing this out. > >=20 > > We indeed have a lot to do and the -00 draft is for sure > > not complete. > >=20 > > Actions/rpcs in groupings/lists and type information on > > groupings are features we definitely need. > > We would be happy to have your suggestions and input. > >=20 >=20 >=20 > Hi, >=20 > Didn't we do a requirements gathering phase of some sort, > in order to get to the point where charter decisions > were made, so that the NETMOD WG could proceed and > finish in finite time? Yes, we had long discussions on this and decided to start the work based on the WG items listed in the NETMOD charter. At the same time, IIRC based on the request of not-negligible amount of persons we wrote following text into the charter: "Language abstractions that facilitate model extensibility=20 and reuse have been identified as a work area and will be=20 considered as a work item or may be integrated into the=20 YANG document based on WG consensus." This was the consensus we had after the requirements and=20 NETMOD charter discussion. BTW: We had similar discussions also later. E.g. we discussed in the interim meeting on "rpc statement in list". http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00221 The consensus was not to add it to YANG 1.0 with=20 the hope that it'll be considered later.=20 =20 > I believe the consensus at the time was that we did > not want an OO data modeling language and we choose YANG over several > other proposals, including the OO proposal from your co-author. Actually I don't like the term "OO". It does not explain what we would like to have. I also don't want YANG to be=20 an "object oriented programming language". But OTOH I want language abstractions and modeling language=20 features which support extensibility and top-down modeling. I don't think it is a contradiction to have both groupings and=20 complex types as YANG features. Both have their specialities and are worth to use for specific purposes. It is the feature richness which makes a language successful. Different people will model their YAM on different abstraction=20 levels. Some will use only groupings because they aim to model=20 structured data tables. Others will use complex types _and_ groupings because they have a bigger amount of modeling work=20 to do. Their system and the huge amount of data models ask=20 for top-down design and a hierarchical modeling. =20 > It is rather subjective to start comparing comfort-levels > with 1 variant of the IPFIX model or another. I doubt we > could reach agreement in the IETF on a data modeling language > that had enough OO programming language features to make a > real difference. I prefer to get a stable YANG 1.0 deployed, > and start defining some standard content. =20 As I wrote in another mail I fully support the targets of the WG developing YANG 1.0 with the decided set of features. What we are discussing is relevant for YANG 1.x. > IMO, the DML used > would not make much difference at all if I were deciding whether to > implement the IPFIX model or not. >=20 >=20 > > Cheers, > > Mehmet > > Cheers, Mehmet >=20 >=20 >=20 > Andy >=20 >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Fri Jul 24 07:16:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874CB3A67D3 for ; Fri, 24 Jul 2009 07:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.580, 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 qRqf6kyFGosg for ; Fri, 24 Jul 2009 07:16:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6C7593A68E8 for ; Fri, 24 Jul 2009 07:16:44 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 742C7C0067; Fri, 24 Jul 2009 16:08:47 +0200 (CEST) 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 aSXEhYpnsPqz; Fri, 24 Jul 2009 16:08:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4751CC001A; Fri, 24 Jul 2009 16:08:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA1B3B6AAAB; Fri, 24 Jul 2009 16:08:45 +0200 (CEST) Date: Fri, 24 Jul 2009 16:08:45 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090724140845.GA7057@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , "netmod@ietf.org" References: <4A66F259.7090002@ericsson.com> <4A6720DB.5090002@netconfcentral.com> <20090723.233144.192180203.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:16:45 -0000 On Fri, Jul 24, 2009 at 02:48:52PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: Disclaimer: I have not read the document yet in detail but I have some questions to understand the stated motivation. > I think it is the feature richness which makes a modeling > language successful. Different people will prepare their > YAM on different abstraction levels and will use different > language constructs based on their preferences. > > There might be models, where groupings are the most > appropriate construct to use, e.g. for the modeling > of structured data tables. Others will use complex > types _and_ groupings because they have a bigger amount > of modeling work to do. Their system and the huge amount > of data models makes it necessary to design in a top-down > manner and to do hierarchical modeling. Can you provide the necessary text for the guidelines document that tells people which construct to use when and why? > I also can imagine that some of us will be interested to > use and derive their data models from industry standard > information models. A language mapping at the interface > between the two models becomes important. Are you saying a mapping of those industry standard models (which ones?) to YANG 1.0 is not possible? Why is it not possible? > I believe it will be useful to have YANG easier mappable > to other modeling languages. This will also enable easy > adoption of IETF data models by other SDOs. I think it > is a good thing if TMF or 3GPP would be able to map YAMs > to their model easily or adopt and use YAMs as they are. Now you are talking of mapping YANG to other languages (which ones?). Why is that not possible with YANG 1.0? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Jul 24 07:55:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47A828C204 for ; Fri, 24 Jul 2009 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 Y3kzAT+820a5 for ; Fri, 24 Jul 2009 07:55:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A15E63A6BD7 for ; Fri, 24 Jul 2009 07:54:03 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D3DE7D80096 for ; Fri, 24 Jul 2009 16:54:01 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090723.233144.192180203.mbj@tail-f.com> References: <4A66F259.7090002@ericsson.com> <4A6720DB.5090002@netconfcentral.com> <20090723.233144.192180203.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 24 Jul 2009 16:54:00 +0200 Message-Id: <1248447240.30014.11.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Fri, 24 Jul 2009 14:55:08 -0000 Martin Bjorklund píše v Čt 23. 07. 2009 v 23:31 +0200: > Hi, > > "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > I like groupings and they are appropriate for many of our modeling > > work. > > > > But I also believe strongly that complex types are a useful option > > for straightforward modeling when people have managed objects > > with complex types in mind. > > > > Well, I agree that some of us don't use them and think they are > > not necessary. > > It seems you are saying that using complex types is just a different > way of doing what can already be done. Some people find models with > complex types easier to read, and some people find them harder to > read. I suspect the main problem of groupings is that they may be perceived as something like macros - which they aren't in reality. > > > I don't like the idea of introducing new alternative ways of doing > what we already do. This just adds complexity to the language. Even > if you think models with complex types are easier to read, the result > will be that some models use complex types and others don't, so the > net result will not be easier to understand. +1 Lada > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Jul 24 08:04:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A7E3A6AB1 for ; Fri, 24 Jul 2009 08:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 Xq2qIfb+Qrzr for ; Fri, 24 Jul 2009 08:04:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 88E713A6A69 for ; Fri, 24 Jul 2009 08:04:05 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 49A7BD80096; Fri, 24 Jul 2009 17:04:06 +0200 (CEST) From: Ladislav Lhotka To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" In-Reply-To: <2E23AE0E4AED07418C26486630C852A02D8ED0@FIESEXC030.nsn-intra.net> References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com> <4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com> <1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com> <1248345037.4674.64.camel@missotis> <2E23AE0E4AED07418C26486630C852A02D8ED0@FIESEXC030.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 24 Jul 2009 17:04:04 +0200 Message-Id: <1248447844.30014.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Fri, 24 Jul 2009 15:04:07 -0000 Linowski, Bernd (EXT-Other - DE/Dusseldorf) píše v Pá 24. 07. 2009 v 11:13 +0300: > We haven't covered actions/rpcs in complex-types simply because > of lack time. Yes, I understand, but without a reasonably detailed proposal it is difficult to discuss such features. > Having an action defined in the scope of the target > of that action would improves clarity in some cases imho > (e.g. having a "witch-group" action as part of a "protection-group" complex type > would tell that this action may be applied only to protection groups) This is again subjective, some implementors might prefer to have all the RPCs and notifications in one place. > > Balazs Lengyel píše wrote: > > > - type information on groupings/lists. Unless you do a deep > > analysis of the YAMs there is no > > > way to find out that e.g. a leafref points at something > > derived from a grouping. > > > > I agree with Balazs here. > > The typed instance identifier addresses this by explicitly including the type > of the target in the model. > > > Validation including type checking is performed on instance XML > > documents where this information is not available anyway. An > > instance-identifier points to a concrete data node whose > > presence can be > > directly checked for. Everything else is quite complicated - how would > > you specify an XPath expression pointing to a complex type that has no > > corresponding node in the data tree? > > > > By including the type information in the model explicitly, what is > done in the proposed typed instance identifier. Yes, but it doesn't answer my question. If no trace of the complex type remains in the instance document, what does the "instance identifier of a complex type" point to in the instance document (or datastore)? > > > YANG is much closer to an XML schema language than to a programming > > language and I think it should stay this way. > > Well, as soon as you describe behavior in a language - which YANG does > already in form of rpc's and notifications - it is also an interface description language. > In that respect it goes already far beyond what XML schema does. No, YANG specifies just the signatures of RPC methods, no behaviour at all. Lada > > - Bernd > > > > > Lada > > > > > > > > I don't believe anyone wants to enforce object orientation in YANG. > > > Balazs > > > > > > Ladislav Lhotka wrote: > > > > David French píše v St 22. 07. 2009 v 17:59 +0200: > > > >> Hi, > > > >> > > > >> Just to add to Balazs mention, our (S3 / embeddedMIND) > > > >> experience has also been that an emphasis on managed object > > > >> hierarchy concepts when modelling rather than > > > >> Yang-style groupings leads to a more straightforward mapping > > > >> and lower integration costs with the applications on the device. > > > > > > > > Why is YANG insufficient for modelling such object > > hierarchies? In fact, > > > > YANG allows for "multiple inheritance", which might be > > very useful - and > > > > safe, since we don't have to care about method lookup strategies. > > > > > > > > Perhaps the difference is just that YANG doesn't *enforce* object > > > > orientation. > > > > > > > > Lada > > > > > > > >> Regards, > > > >> > > > >> David French > > > >> www.embeddedmind.com > > > >> > > > >> Balazs Lengyel wrote: > > > >>> Hello Andy, > > > >>> So you are saying, using complex types is more > > complicated. You wanted > > > >>> to use complex types, but later abandoned it due to > > implementation > > > >>> complexity. > > > >>> > > > >>> A lot of people (Ericsson, NSN, S3 a Netconf vendor) > > and standard > > > >>> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) > > find, that for the > > > >>> human user it is easier to think in terms of Managed > > objects with > > > >>> complex types then in terms of groupings. > > > >>> > > > >>> Also we stated somewhere that readers are the most important > > > >>> community. I think we should not block this effort. > > > >>> Balazs > > > >>> > > > >>> Andy Bierman wrote: > > > >>>> Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > > > >>>>> Hi All, > > > >>>>> > > > >>>>> please find below the -00 draft we submitted on > > "Extending YANG with > > > >>>>> Language Abstractions". > > > >>>>> This is an early draft and needs some discussion for further > > > >>>>> development. > > > >>>>> Please give us your comments. > > > >>>>> > > > >>>> The new constructs that are proposed seem to overlap the > > > >>>> YANG grouping and uses statements a great deal. > > > >>>> > > > >>>> Before YANG, I implemented something called NCX > > > >>>> which had complex types, and every node > > > >>>> had a type. Every node also formed a containment > > > >>>> layer, even choices, because the type was a complete > > > >>>> abstraction, and what if it changed from a list to a choice? > > > >>>> > > > >>>> I found that the complexity level in the agent callback > > > >>>> structure went up a lot because of this abstraction. > > > >>>> > > > >>>> At first I did not like YANG groupings, because they are so > > > >>>> much more fragile and 'hands-on' than complex types. > > > >>>> You must control the containment layering and refinements. > > > >>>> It is not handled automatically like with complex types. > > > >>>> > > > >>>> But now I think that groupings are more appropriate for > > > >>>> embedded systems, and align better with traditional > > > >>>> agent callback design. > > > >>>> > > > >>>>> Regards, > > > >>>>> Bernd > > > >>>>> > > > >>>> > > > >>>> Andy > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: i-d-announce-bounces@ietf.org > > > >>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > > > >>>>> Internet-Drafts@ietf.org > > > >>>>> Sent: Monday, July 06, 2009 9:00 PM > > > >>>>> To: i-d-announce@ietf.org > > > >>>>> Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt > > > >>>>> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > >>>>> directories. > > > >>>>> > > > >>>>> Title : Extending YANG with Language > > Abstractions > > > >>>>> Author(s) : B. Linowski, M. Ersue > > > >>>>> Filename : > > draft-linowski-netmod-yang-abstract-00.txt > > > >>>>> Pages : 42 > > > >>>>> Date : 2009-07-06 > > > >>>>> > > > >>>>> YANG - the NETCONF Data Modeling Language - supports > > modeling of a > > > >>>>> tree of data elements that represent the > > configuration and runtime > > > >>>>> status of a particular network element managed via > > NETCONF. This > > > >>>>> memo suggests to enhance YANG with supplementary > > modeling features > > > >>>>> and language abstractions with the aim to improve the model > > > >>>>> extensibility and reuse. > > > >>>>> > > > >>>>> A URL for this Internet-Draft is: > > > >>>>> > > http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang > -abstract- > > > >>>>> > > > >>>>> 00.txt > > > >>>>> > > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > > >>>>> > > > >>>>> Below is the data which will enable a MIME compliant > > mail reader > > > >>>>> implementation to automatically retrieve the ASCII > > version of the > > > >>>>> Internet-Draft. > > > >>>>> > > > >>>>> > > > >>>>> > > -------------------------------------------------------------- > > ---------- > > > >>>>> > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> 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 > > > >>>> > > > >> -- > > > >> > > > >> ----------------------------------- > > > >> David French, VP Product Management > > > >> Management Infrastructure for Networked Devices > > > >> www.embeddedmind.com > > > >> +48 71 3348174 (use email not voicemail) > > > >> > > > >> http://www.s3group.com/legal/ > > > >> _______________________________________________ > > > >> netmod mailing list > > > >> netmod@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bernd.linowski.ext@nsn.com Fri Jul 24 09:45:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22FB3A6D13 for ; Fri, 24 Jul 2009 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 eKH3wnp2YJhn for ; Fri, 24 Jul 2009 09:45:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F2AFB3A6D09 for ; Fri, 24 Jul 2009 09:44:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6OGi2aU018932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2009 18:44:02 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6OGi2eD022433; Fri, 24 Jul 2009 18:44:02 +0200 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 18:39:54 +0200 Received: from FIESEXC030.nsn-intra.net ([10.135.48.16]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 19:39:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jul 2009 19:39:52 +0300 Message-ID: <2E23AE0E4AED07418C26486630C852A02D8F6A@FIESEXC030.nsn-intra.net> In-Reply-To: <20090724140845.GA7057@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod]FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoMaWL7s/nYuc5VSWCN37eg7DWVegADA8ow References: <4A66F259.7090002@ericsson.com><4A6720DB.5090002@netconfcentral.com><20090723.233144.192180203.mbj@tail-f.com> <20090724140845.GA7057@elstar.local> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: "Juergen Schoenwaelder" , "Ersue, Mehmet (NSN - DE/Munich)" X-OriginalArrivalTime: 24 Jul 2009 16:39:53.0599 (UTC) FILETIME=[5EE4F8F0:01CA0C7D] Cc: netmod@ietf.org Subject: Re: [netmod] FW:I-D Action:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Fri, 24 Jul 2009 16:45:04 -0000 Hi=20 Juergen Schoenwaelder wrote: > =20 > > I also can imagine that some of us will be interested to=20 > > use and derive their data models from industry standard > > information models. A language mapping at the interface=20 > > between the two models becomes important. >=20 > Are you saying a mapping of those industry standard models (which > ones?) to YANG 1.0 is not possible? Why is it not possible? >=20 For example, mapping of recursive structures is an area where things get difficult. In 3GPP a 3GSubNetwork might contain other 3GSubNetworks, in the SID a Hardware instance might contain other Hardware instances. Currently, you have to use a leafref-typed leafs to point the the parent (and/or the children) to emulate recursive containment. This also has the disadvantage that the hierarchy is not visible in the NETCONF payload. It also makes filtering based on a location in the (conceptual) containment tree formed by recursice structures difficult. BR, Bernd > > I believe it will be useful to have YANG easier mappable=20 > > to other modeling languages. This will also enable easy > > adoption of IETF data models by other SDOs. I think it=20 > > is a good thing if TMF or 3GPP would be able to map YAMs=20 > > to their model easily or adopt and use YAMs as they are. >=20 > Now you are talking of mapping YANG to other languages (which > ones?). Why is that not possible with YANG 1.0? >=20 > /js >=20 > --=20 > 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 >=20 From cfinss@dial.pipex.com Fri Jul 24 11:17:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B333A68EA for ; Fri, 24 Jul 2009 11:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 d-CE+o3vhGUk for ; Fri, 24 Jul 2009 11:17:03 -0700 (PDT) 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 2F2E63A6A8C for ; Fri, 24 Jul 2009 11:17:03 -0700 (PDT) X-Trace: 125578116/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.168/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.168 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: 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: AlAFAAOXaUo+vGmo/2dsb2JhbACDLDwejCvFCAmEBAWBQw X-IronPort-AV: E=Sophos;i="4.43,265,1246834800"; d="scan'208";a="125578116" X-IP-Direction: IN Received: from 1cust168.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.168]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Jul 2009 19:17:00 +0100 Message-ID: <000401ca0c82$7ef8d940$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <1246434352.6491.49.camel@missotis><1246442411.6491.94.camel@missotis><20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> Date: Fri, 24 Jul 2009 17:51:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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] prefixes in groupings 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: , X-List-Received-Date: Fri, 24 Jul 2009 18:17:04 -0000 Apologies for taking so long to fail to understand this - I was away at the time. But.... Martin in an earlier post in the thread said "If a must/when expression in a grouping refers to a node in the grouping - with or without prefix - at conceptual evaluation time they will always refer to the node within the grouping, i.e. with the namespace of the module where the grouping is used." Forget the must/when and XPath:-), I cannot reconcile "at conceptual evaluation time they will always refer to the node within the grouping" which suggests that a leaf in a grouping is in the namespace of the module where the grouping appears, which is what I also get from " Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used." from yang-07. But " with the namespace of the module where the grouping is used." tells me the opposite, that it is the namespace of the module in which the uses statement appears. or to quote Andy "The objects themselves will end up with the namespace of the final 'uses stmt'." I am not saying one or the other is preferrable, just that I cannot get a single meaning from words used in this thread and the I-D. By contrast, I am comfortable with the interpretation of prefixes; there all the text tells me the same thing. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Martin Bjorklund" Cc: Sent: Friday, July 03, 2009 10:32 AM Subject: Re: [netmod] prefixes in groupings > Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: > > Ladislav Lhotka wrote: > > > prefix x; > > > > > > grouping foo { > > > container c { > > > must "x:a < ../x:above"; > > > leaf a { ... } > > > } > > > } > > > > > > it would be pretty confusing if the resolution of the same prefix "x" > > > was fixed for 'x:above' and postponed for 'x:a'. > > > > The point is that you cannot expect to do a simple text substitution > > when you implement 'uses'. For example, my module might import your > > module and some other module: > > > > import foo-module { > > prefix f; > > } > > import other-module { > > prefix x; > > } > > > > uses foo; > > > > The prefix "x" in the grouping must not be resolved in this context! > > This is no different for must expressions than for references to types > > or whatever. For example: > > > > grouping foo { > > typedef my-type { type int32; } > > container c { > > must "x:a < ../x:above"; > > leaf a { type x:my-type } // legal > > } > > } > > This is all fine, the problem would arise when this grouping 'foo' is > defined in 'other-module' and used in the local module via 'uses x:foo'. > In the schema tree of the local module, 'a' now has the namespace URI of > the local module, so if the prefix 'x' still corresponds to the NS URI > of 'other-module' the 'x:a' name in the must statement cannot match leaf > 'a', although with the rules that you stated earlier 'x:a' would match > 'a' in 'other-module' where grouping 'foo' is defined. > > Lada > > > > > > > So I agree with Andy that the current rules work fine. > > > > > > > > /martin > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Fri Jul 24 12:37:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24A23A69EA for ; Fri, 24 Jul 2009 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=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 PHmFi81J7FYn for ; Fri, 24 Jul 2009 12:37:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7C6F33A69B4 for ; Fri, 24 Jul 2009 12:37:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 91D9BD80096; Fri, 24 Jul 2009 21:36:24 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <000401ca0c82$7ef8d940$0601a8c0@allison> References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 24 Jul 2009 21:36:23 +0200 Message-Id: <1248464183.30014.42.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 24 Jul 2009 19:37:34 -0000 Hi Tom, this ambiguity is due to the fact that the handling of prefixes in groupings is inconsistent. I tried to propose a remedy: http://www.ietf.org/mail-archive/web/netmod/current/msg03052.html In simple terms: - unprefixed name in a grouping => null namespace URI, this name will adopt the namespace of the module where the grouping is used - a prefixed name in a grouping always stays in the namespace the prefix is bound to in the module where the grouping is defined. Lada tom.petch píše v Pá 24. 07. 2009 v 17:51 +0200: > Apologies for taking so long to fail to understand this - I was away at the > time. > > But.... > > Martin in an earlier post in the thread said > "If a must/when expression in a grouping refers to a node in the > grouping - with or without prefix - at conceptual evaluation time they > will always refer to the node within the grouping, i.e. with the > namespace of the module where the grouping is used." > > Forget the must/when and XPath:-), I cannot reconcile > "at conceptual evaluation time they > will always refer to the node within the grouping" > which suggests that a leaf in a grouping is in the namespace of the module > where the grouping appears, which is what I also get from > " Identifiers appearing inside the > grouping are resolved relative to the scope in which the grouping is > defined, not where it is used." from yang-07. > > But > " with the namespace of the module where the grouping is used." > tells me the opposite, that it is the namespace of the module > in which the uses statement appears. > > or to quote Andy > "The objects themselves will end up with the namespace > of the final 'uses stmt'." > > I am not saying one or the other is preferrable, just that I cannot get > a single meaning from words used in this thread and the I-D. > > By contrast, I am comfortable with the interpretation of prefixes; there all the > text tells me the same thing. > > Tom Petch > > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Friday, July 03, 2009 10:32 AM > Subject: Re: [netmod] prefixes in groupings > > > > Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: > > > Ladislav Lhotka wrote: > > > > prefix x; > > > > > > > > grouping foo { > > > > container c { > > > > must "x:a < ../x:above"; > > > > leaf a { ... } > > > > } > > > > } > > > > > > > > it would be pretty confusing if the resolution of the same prefix "x" > > > > was fixed for 'x:above' and postponed for 'x:a'. > > > > > > The point is that you cannot expect to do a simple text substitution > > > when you implement 'uses'. For example, my module might import your > > > module and some other module: > > > > > > import foo-module { > > > prefix f; > > > } > > > import other-module { > > > prefix x; > > > } > > > > > > uses foo; > > > > > > The prefix "x" in the grouping must not be resolved in this context! > > > This is no different for must expressions than for references to types > > > or whatever. For example: > > > > > > grouping foo { > > > typedef my-type { type int32; } > > > container c { > > > must "x:a < ../x:above"; > > > leaf a { type x:my-type } // legal > > > } > > > } > > > > This is all fine, the problem would arise when this grouping 'foo' is > > defined in 'other-module' and used in the local module via 'uses x:foo'. > > In the schema tree of the local module, 'a' now has the namespace URI of > > the local module, so if the prefix 'x' still corresponds to the NS URI > > of 'other-module' the 'x:a' name in the must statement cannot match leaf > > 'a', although with the rules that you stated earlier 'x:a' would match > > 'a' in 'other-module' where grouping 'foo' is defined. > > > > Lada > > > > > > > > > > > So I agree with Andy that the current rules work fine. > > > > > > > > > > > > /martin > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Jul 24 12:56:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790F23A67FD for ; Fri, 24 Jul 2009 12:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 hmgQ2FWusXMP for ; Fri, 24 Jul 2009 12:56:17 -0700 (PDT) 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 851BC3A67E4 for ; Fri, 24 Jul 2009 12:56:17 -0700 (PDT) Received: (qmail 38915 invoked from network); 24 Jul 2009 19:52:31 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 24 Jul 2009 19:52:31 -0000 X-YMail-OSG: Mq6ncUQVM1mm2QRa0FrcoiIYnydMganezBUZAQkEr4kGzmBZILYCtionCm7qqPBVRPfPfxusJM8B9g3goOsq3_ao21jyF0yLurtjdY1fb_T8W3Qy_zFk9MYVk53TLk2LLaZeUjTiITUogcSNyqc1QKBQzWXpUw5aw.YvhGi6raoCYAjAM3gzze..tEctZRvo8Mr3Pu4IrloQ5aFSYJ3Gn0u.f8ie16mVhaypBzoOOXSlz8yLbDRgSOsnQlqu.vtT3TE0Pv84.hkV7wwLOCFD7hORnXUKvd_uq5KUCjzb33YJ9m58 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6A109E.8000403@netconfcentral.com> Date: Fri, 24 Jul 2009 12:50:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> <1248464183.30014.42.camel@missotis> In-Reply-To: <1248464183.30014.42.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 24 Jul 2009 19:56:18 -0000 Ladislav Lhotka wrote: > Hi Tom, > > this ambiguity is due to the fact that the handling of prefixes in > groupings is inconsistent. I tried to propose a remedy: > > http://www.ietf.org/mail-archive/web/netmod/current/msg03052.html > > In simple terms: > > - unprefixed name in a grouping => null namespace URI, this name will > adopt the namespace of the module where the grouping is used > - a prefixed name in a grouping always stays in the namespace the > prefix is bound to in the module where the grouping is defined. > Except this is fatally flawed because it breaks the "grouping transparency rule". For any set of sibling objects, it should not make any difference whether they are declared inline or via a uses statement. Prefixes are handled consistently now (IMO) because all the QNames appearing in the same YANG [sub]module, will be processed the same way. We have to resolve QNames as soon as possible, not as late as possible, when they are used within a definition. Assigning a namespace to the exported definition is not the same thing as resolving the dependencies within that definition. > Lada Andy > > tom.petch píše v Pá 24. 07. 2009 v 17:51 +0200: >> Apologies for taking so long to fail to understand this - I was away at the >> time. >> >> But.... >> >> Martin in an earlier post in the thread said >> "If a must/when expression in a grouping refers to a node in the >> grouping - with or without prefix - at conceptual evaluation time they >> will always refer to the node within the grouping, i.e. with the >> namespace of the module where the grouping is used." >> >> Forget the must/when and XPath:-), I cannot reconcile >> "at conceptual evaluation time they >> will always refer to the node within the grouping" >> which suggests that a leaf in a grouping is in the namespace of the module >> where the grouping appears, which is what I also get from >> " Identifiers appearing inside the >> grouping are resolved relative to the scope in which the grouping is >> defined, not where it is used." from yang-07. >> >> But >> " with the namespace of the module where the grouping is used." >> tells me the opposite, that it is the namespace of the module >> in which the uses statement appears. >> >> or to quote Andy >> "The objects themselves will end up with the namespace >> of the final 'uses stmt'." >> >> I am not saying one or the other is preferrable, just that I cannot get >> a single meaning from words used in this thread and the I-D. >> >> By contrast, I am comfortable with the interpretation of prefixes; there all the >> text tells me the same thing. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Ladislav Lhotka" >> To: "Martin Bjorklund" >> Cc: >> Sent: Friday, July 03, 2009 10:32 AM >> Subject: Re: [netmod] prefixes in groupings >> >> >>> Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: >>>> Ladislav Lhotka wrote: >>>>> prefix x; >>>>> >>>>> grouping foo { >>>>> container c { >>>>> must "x:a < ../x:above"; >>>>> leaf a { ... } >>>>> } >>>>> } >>>>> >>>>> it would be pretty confusing if the resolution of the same prefix "x" >>>>> was fixed for 'x:above' and postponed for 'x:a'. >>>> The point is that you cannot expect to do a simple text substitution >>>> when you implement 'uses'. For example, my module might import your >>>> module and some other module: >>>> >>>> import foo-module { >>>> prefix f; >>>> } >>>> import other-module { >>>> prefix x; >>>> } >>>> >>>> uses foo; >>>> >>>> The prefix "x" in the grouping must not be resolved in this context! >>>> This is no different for must expressions than for references to types >>>> or whatever. For example: >>>> >>>> grouping foo { >>>> typedef my-type { type int32; } >>>> container c { >>>> must "x:a < ../x:above"; >>>> leaf a { type x:my-type } // legal >>>> } >>>> } >>> This is all fine, the problem would arise when this grouping 'foo' is >>> defined in 'other-module' and used in the local module via 'uses x:foo'. >>> In the schema tree of the local module, 'a' now has the namespace URI of >>> the local module, so if the prefix 'x' still corresponds to the NS URI >>> of 'other-module' the 'x:a' name in the must statement cannot match leaf >>> 'a', although with the rules that you stated earlier 'x:a' would match >>> 'a' in 'other-module' where grouping 'foo' is defined. >>> >>> Lada >>> >>>> >>>> So I agree with Andy that the current rules work fine. >>>> >>>> >>>> >>>> /martin >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> From phil@juniper.net Fri Jul 24 13:24:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B0C3A6809 for ; Fri, 24 Jul 2009 13:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc02le52dJ5y for ; Fri, 24 Jul 2009 13:24:38 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 3A4F03A67E4 for ; Fri, 24 Jul 2009 13:24:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSmoYE3FnSitLfcO9ssy7Rnx0cqOnIfFV@postini.com; Fri, 24 Jul 2009 13:24:39 PDT 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.375.2; Fri, 24 Jul 2009 13:17:27 -0700 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, 24 Jul 2009 13:17:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 13:17:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 13:17:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6OKHPd77648; Fri, 24 Jul 2009 13:17:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6OK6101080741; Fri, 24 Jul 2009 20:06:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907242006.n6OK6101080741@idle.juniper.net> To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" Date: Fri, 24 Jul 2009 16:06:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jul 2009 20:17:26.0300 (UTC) FILETIME=[C2E915C0:01CA0C9B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: [netmod] Moving the discussion back toward new concepts 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: , X-List-Received-Date: Fri, 24 Jul 2009 20:24:39 -0000 "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" writes: >For example, mapping of recursive structures is an area where >things get difficult. > >In 3GPP a 3GSubNetwork might contain other 3GSubNetworks, in the SID >a Hardware instance might contain other Hardware instances. >Currently, you have to use a leafref-typed leafs to point the >the parent (and/or the children) to emulate recursive containment. >This also has the disadvantage that the hierarchy is not visible >in the NETCONF payload. It also makes filtering based on >a location in the (conceptual) containment tree formed by recursice >structures difficult. This is great stuff. IMHO you should redo your "motivation" section into three sections: (a) Things YANG can't do (b) Things YANG isn't good at (c) Things we don't now how to do in YANG Recursive content belongs in (a). Give an overview of the issue and then this example. Repeat this for all the topics in your motivation section. It will go a long way to helping turn your document from "an alternative means of doing what YANG can do" into "a means of extending YANG to do what it could not do before". For example, your "complex types" are a red herring. The difference between: complex-type ManagedHardware { abstract true; key object-id; leaf objectId { type string { max-length 32; } } leaf serialNumber { type string; config false; } leaf commonName { type string; } } complex-type Equipment { extends ManagedHardware; leaf installed {type boolean; config false; } leaf version { type string; } leaf redundancy {type uint16; } } element equipment { type Equipment; } and: grouping ManagedHardware { key object-id; leaf objectId { type string { max-length 32; } } leaf serialNumber { type string; config false; } leaf commonName { type string; } } grouping Equipment { uses ManagedHardware; leaf installed {type boolean; config false; } leaf version { type string; } leaf redundancy {type uint16; } } container equipment { type Equipment; } is near zero. By introducing equivalent syntax, you've moved the discussion from concepts you want to add into the realm of "two equivalent ways to do the same thing". This is a lose, but for your ideas and for the working group. Let's move the discussion back and inspect the real underlaying issues of things you don't think you can do in YANG, because it's really hard to see these clearly. My concern is that most of your issues are related to generating code and data from YANG modules, rather than real modeling issues. If you want "ManagedHardware" to be a Java class, say: grouping ManagedHardware { java:class ManagedHardware { java:abstract true; } key object-id; leaf objectId { type string { max-length 32; } } leaf serialNumber { type string; config false; } leaf commonName { type string; } } Nothing else in YANG needs to change to give you this ability to fine tune your code generation. I can see value in standardizing these code generation hooks, but don't see this justifying the "complex-type" and "element" statements. If you want polymorphism, adding that can be done with an "isa" statement (and/or extension function). If you want recursion, that change can be made. But there's no need to invent new mechanisms for expressing concepts that already exist. Making users understand the diferences, overlap, and how to choose between "element" and "container" is expensive. Also "element" is a poor choice for a statement, since "element" is already overloaded. All XML is encoded in elements, so container, list, leaf, etc all turn into elements. I meant to diff your ipfix against the real one, but my guess is that it's mostly s/grouping/complex-type/. If you'd used the existing YANG statements, such a diff might help show what is won by using your new concepts. Thanks, Phil From mbj@tail-f.com Fri Jul 24 14:20:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987B13A6AF6 for ; Fri, 24 Jul 2009 14:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=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 LeQ3hL4MinIN for ; Fri, 24 Jul 2009 14:20:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 46EF63A6AB0 for ; Fri, 24 Jul 2009 14:20:19 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D848F76C4E4; Fri, 24 Jul 2009 23:20:18 +0200 (CEST) Date: Fri, 24 Jul 2009 23:20:18 +0200 (CEST) Message-Id: <20090724.232018.193773390.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <000401ca0c82$7ef8d940$0601a8c0@allison> References: <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 24 Jul 2009 21:20:20 -0000 SGksDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBpc3N1ZXMgaGVyZS4gIFRoZSBmaXJzdCBpcyB3 aGljaCBuYW1lc3BhY2UNCm5vZGVzIGluIGEgZ3JvdXBpbmcgYmVsb25nIHRvLiAgVGhlIGFuc3dl ciBpcyB0aGF0IGl0IGlzIHRoZSBuYW1lc3BhY2UNCm9mIHRoZSBtb2R1bGUgdGhhdCBoYXMgdGhl IHVzZXMgc3RhdGVtZW50LiAgRm9yIGV4YW1wbGU6DQoNCiAgbW9kdWxlIGEgew0KICAgIG5hbWVz cGFjZSAiaHR0cDovL2V4YW1wbGUuY29tL2EiOw0KICAgIHByZWZpeCBhOw0KICANCiAgICBncm91 cGluZyBmb28gew0KICAgICAgbGVhZiB4IHsgdHlwZSBpbnQzMjsgfQ0KICAgIH0NCiAgfQ0KDQog IG1vZHVsZSBiIHsNCiAgICBuYW1lc3BhY2UgImh0dHA6Ly9leGFtcGxlLmNvbS9iIjsNCiAgICBw cmVmaXggYjsNCiAgDQogICAgaW1wb3J0IGEgeyBwcmVmaXggYTsgfQ0KDQogICAgdXNlcyBhOmZv bzsNCiAgfQ0KDQogIG1vZHVsZSBjIHsNCiAgICBuYW1lc3BhY2UgImh0dHA6Ly9leGFtcGxlLmNv bS9jIjsNCiAgICBwcmVmaXggYzsNCiAgDQogICAgaW1wb3J0IGEgeyBwcmVmaXggYTsgfQ0KDQog ICAgdXNlcyBhOmZvbzsNCiAgfQ0KDQpUaGUgbGVhZiB4IG5vdyBleGlzdHMgaW4gdHdvIFhNTCBu YW1lc3BhY2VzLCBlLmcuDQoNCiAgLi4uDQogIDxjb25maWc+DQogICAgPHggeG1sbnM9Imh0dHA6 Ly9leGFtcGxlLmNvbS9iIj40MjwveD4NCiAgICA8eCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29t L2MiPjQ3MTE8L3g+DQogIDwvY29uZmlnPg0KDQoNClRoZSBzZWNvbmQgaXNzdWUgaXMgaG93IHBy ZWZpeGVzIGFyZSByZXNvbHZlZCB3aXRoaW4gZ3JvdXBpbmdzLg0KSW4gdGhlIGV4YW1wbGUgYWJv dmUsIHN1cHBvc2UgdGhlIGZvbyBncm91cGluZyBpcyBkZWZpbmVkIGxpa2UgdGhpcw0KaW5zdGVh ZDoNCg0KICAgIGdyb3VwaW5nIGZvbyB7DQogICAgICBsZWFmIHggew0KICAgICAgICB0eXBlIGlu dDMyOw0KICAgICAgfQ0KICAgICAgbGVhZiB5IHsNCiAgICAgICAgdHlwZSBpbnQzMjsNCiAgICAg ICAgbXVzdCAiY3VycmVudCgpIDwgYTp4IjsNCiAgICAgIH0NCiAgICB9DQoNClRoZSBub3Rpb24g ImE6eCIgaXMgdXNlZCB0byByZWZlciB0byB0aGUgbm9kZSAieCIgd2l0aGluIHRoZQ0KZ3JvdXBp bmcuICBXaGVuIHRoZSBncm91cGluZyBpcyB1c2VkIGluIG1vZHVsZXMgYiBhbmQgYywgeW91IGNh bm5vdA0KanVzdCBkbyBhIHN5bnRhY3RpY2FsIHN1YnN0aXR1dGlvbiBvZiB0aGUgZ3JvdXBpbmcg Y29udGVudHMuICBZb3UgbXVzdA0Kc3Vic3RpdHVlIHRoZSAicmVzb2x2ZWQgc3RydWN0dXJlIiwg d2hlcmUgImE6eCIgaXMgYWxyZWFkeSByZXNvbHZlZC4NCg0KVGhpcyBpcyBjb25zaXN0ZW50IHdp dGggaG93IHR5cGUgbmFtZXMgYXJlIHJlc29sdmVkIGluIHRoaXMgZXhhbXBsZToNCg0KICAgIGdy b3VwaW5nIGZvbyB7DQogICAgICBsZWFmIHggew0KICAgICAgICB0eXBlIGludDMyOw0KICAgICAg fQ0KICAgICAgbGVhZiB5IHsNCiAgICAgICAgdHlwZSBhOm15LXR5cGU7DQogICAgICAgIG11c3Qg ImN1cnJlbnQoKSA8IGE6eCI7DQogICAgICB9DQogICAgICB0eXBlZGVmIG15LXR5cGUgew0KICAg ICAgICB0eXBlIGludDMyOw0KICAgICAgfQ0KICAgIH0NCg0KQWdhaW4sIHRoZSB0eXBlIG9mICd5 JyBtdXN0IGJlIHJlc29sdmVkIHByaW9yIHRvIHRoZSB1c2VzIGV4cGFuc2lvbi4NCg0KDQovbWFy dGluDQoNCg0KDQoidG9tLnBldGNoIiA8Y2ZpbnNzQGRpYWwucGlwZXguY29tPiB3cm90ZToNCj4g QXBvbG9naWVzIGZvciB0YWtpbmcgc28gbG9uZyB0byBmYWlsIHRvIHVuZGVyc3RhbmQgdGhpcyAt IEkgd2FzIGF3YXkgYXQgdGhlDQo+IHRpbWUuDQo+IA0KPiBCdXQuLi4uDQo+IA0KPiBNYXJ0aW4g aW4gYW4gZWFybGllciBwb3N0IGluIHRoZSB0aHJlYWQgc2FpZA0KPiAiSWYgYSBtdXN0L3doZW4g ZXhwcmVzc2lvbiBpbiBhIGdyb3VwaW5nIHJlZmVycyB0byBhIG5vZGUgaW4gdGhlDQo+IGdyb3Vw aW5nIC0gd2l0aCBvciB3aXRob3V0IHByZWZpeCAtIGF0IGNvbmNlcHR1YWwgZXZhbHVhdGlvbiB0 aW1lIHRoZXkNCj4gd2lsbCBhbHdheXMgcmVmZXIgdG8gdGhlIG5vZGUgd2l0aGluIHRoZSBncm91 cGluZywgaS5lLiB3aXRoIHRoZQ0KPiBuYW1lc3BhY2Ugb2YgdGhlIG1vZHVsZSB3aGVyZSB0aGUg Z3JvdXBpbmcgaXMgdXNlZC4iDQo+IA0KPiBGb3JnZXQgdGhlIG11c3Qvd2hlbiBhbmQgWFBhdGg6 LSksIEkgY2Fubm90IHJlY29uY2lsZQ0KPiAiYXQgY29uY2VwdHVhbCBldmFsdWF0aW9uIHRpbWUg dGhleQ0KPiB3aWxsIGFsd2F5cyByZWZlciB0byB0aGUgbm9kZSB3aXRoaW4gdGhlIGdyb3VwaW5n Ig0KPiB3aGljaCBzdWdnZXN0cyB0aGF0IGEgbGVhZiBpbiBhIGdyb3VwaW5nIGlzIGluIHRoZSBu YW1lc3BhY2Ugb2YgdGhlIG1vZHVsZQ0KPiB3aGVyZSB0aGUgZ3JvdXBpbmcgYXBwZWFycywgd2hp Y2ggaXMgd2hhdCBJIGFsc28gZ2V0IGZyb20NCj4gIiBJZGVudGlmaWVycyBhcHBlYXJpbmcgaW5z aWRlIHRoZQ0KPiAgICBncm91cGluZyBhcmUgcmVzb2x2ZWQgcmVsYXRpdmUgdG8gdGhlIHNjb3Bl IGluIHdoaWNoIHRoZSBncm91cGluZyBpcw0KPiAgICBkZWZpbmVkLCBub3Qgd2hlcmUgaXQgaXMg dXNlZC4iIGZyb20geWFuZy0wNy4NCj4gDQo+IEJ1dA0KPiAiIHdpdGggdGhlIG5hbWVzcGFjZSBv ZiB0aGUgbW9kdWxlIHdoZXJlIHRoZSBncm91cGluZyBpcyB1c2VkLiINCj4gdGVsbHMgbWUgdGhl IG9wcG9zaXRlLCB0aGF0IGl0IGlzIHRoZSBuYW1lc3BhY2Ugb2YgdGhlIG1vZHVsZQ0KPiBpbiB3 aGljaCB0aGUgdXNlcyBzdGF0ZW1lbnQgYXBwZWFycy4NCj4gDQo+IG9yIHRvIHF1b3RlIEFuZHkN Cj4gIlRoZSBvYmplY3RzIHRoZW1zZWx2ZXMgd2lsbCBlbmQgdXAgd2l0aCB0aGUgbmFtZXNwYWNl DQo+IG9mIHRoZSBmaW5hbCAndXNlcyBzdG10Jy4iDQo+IA0KPiBJIGFtIG5vdCBzYXlpbmcgb25l IG9yIHRoZSBvdGhlciBpcyBwcmVmZXJyYWJsZSwganVzdCB0aGF0IEkgY2Fubm90IGdldA0KPiBh IHNpbmdsZSBtZWFuaW5nIGZyb20gd29yZHMgdXNlZCBpbiB0aGlzIHRocmVhZCBhbmQgdGhlIEkt RC4NCj4gDQo+IEJ5IGNvbnRyYXN0LCBJIGFtIGNvbWZvcnRhYmxlIHdpdGggdGhlIGludGVycHJl dGF0aW9uIG9mIHByZWZpeGVzOyB0aGVyZSBhbGwNCj4gdGhlDQo+IHRleHQgdGVsbHMgbWUgdGhl IHNhbWUgdGhpbmcuDQo+IA0KPiBUb20gUGV0Y2gNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCj4gRnJvbTogIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBjZXNuZXQuY3o+DQo+ IFRvOiAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPg0KPiBDYzogPG5ldG1vZEBp ZXRmLm9yZz4NCj4gU2VudDogRnJpZGF5LCBKdWx5IDAzLCAyMDA5IDEwOjMyIEFNDQo+IFN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBwcmVmaXhlcyBpbiBncm91cGluZ3MNCj4gDQo+IA0KPiA+IE1hcnRp biBCam9ya2x1bmQgcMOtxaFlIHYgxIx0IDAyLiAwNy4gMjAwOSB2IDIyOjM2ICswMjAwOg0KPiA+ ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+ID4gcHJl Zml4IHg7DQo+ID4gPiA+DQo+ID4gPiA+IGdyb3VwaW5nIGZvbyB7DQo+ID4gPiA+ICAgIGNvbnRh aW5lciBjIHsNCj4gPiA+ID4gICAgICAgIG11c3QgIng6YSA8IC4uL3g6YWJvdmUiOw0KPiA+ID4g PiAgICAgICAgbGVhZiBhIHsgLi4uIH0NCj4gPiA+ID4gICAgfQ0KPiA+ID4gPiB9DQo+ID4gPiA+ DQo+ID4gPiA+IGl0IHdvdWxkIGJlIHByZXR0eSBjb25mdXNpbmcgaWYgdGhlIHJlc29sdXRpb24g b2YgdGhlIHNhbWUgcHJlZml4ICJ4Ig0KPiA+ID4gPiB3YXMgZml4ZWQgZm9yICd4OmFib3ZlJyBh bmQgcG9zdHBvbmVkIGZvciAneDphJy4NCj4gPiA+DQo+ID4gPiBUaGUgcG9pbnQgaXMgdGhhdCB5 b3UgY2Fubm90IGV4cGVjdCB0byBkbyBhIHNpbXBsZSB0ZXh0IHN1YnN0aXR1dGlvbg0KPiA+ID4g d2hlbiB5b3UgaW1wbGVtZW50ICd1c2VzJy4gIEZvciBleGFtcGxlLCBteSBtb2R1bGUgbWlnaHQg aW1wb3J0IHlvdXINCj4gPiA+IG1vZHVsZSBhbmQgc29tZSBvdGhlciBtb2R1bGU6DQo+ID4gPg0K PiA+ID4gICBpbXBvcnQgZm9vLW1vZHVsZSB7DQo+ID4gPiAgICAgICBwcmVmaXggZjsNCj4gPiA+ ICAgfQ0KPiA+ID4gICBpbXBvcnQgb3RoZXItbW9kdWxlIHsNCj4gPiA+ICAgICAgIHByZWZpeCB4 Ow0KPiA+ID4gICB9DQo+ID4gPg0KPiA+ID4gICB1c2VzIGZvbzsNCj4gPiA+DQo+ID4gPiBUaGUg cHJlZml4ICJ4IiBpbiB0aGUgZ3JvdXBpbmcgbXVzdCBub3QgYmUgcmVzb2x2ZWQgaW4gdGhpcyBj b250ZXh0IQ0KPiA+ID4gVGhpcyBpcyBubyBkaWZmZXJlbnQgZm9yIG11c3QgZXhwcmVzc2lvbnMg dGhhbiBmb3IgcmVmZXJlbmNlcyB0byB0eXBlcw0KPiA+ID4gb3Igd2hhdGV2ZXIuICBGb3IgZXhh bXBsZToNCj4gPiA+DQo+ID4gPiAgZ3JvdXBpbmcgZm9vIHsNCj4gPiA+ICAgICB0eXBlZGVmIG15 LXR5cGUgeyB0eXBlIGludDMyOyB9DQo+ID4gPiAgICAgY29udGFpbmVyIGMgew0KPiA+ID4gICAg ICAgICBtdXN0ICJ4OmEgPCAuLi94OmFib3ZlIjsNCj4gPiA+ICAgICAgICAgbGVhZiBhIHsgdHlw ZSB4Om15LXR5cGUgfSAgLy8gbGVnYWwNCj4gPiA+ICAgICB9DQo+ID4gPiAgfQ0KPiA+DQo+ID4g VGhpcyBpcyBhbGwgZmluZSwgdGhlIHByb2JsZW0gd291bGQgYXJpc2Ugd2hlbiB0aGlzIGdyb3Vw aW5nICdmb28nIGlzDQo+ID4gZGVmaW5lZCBpbiAnb3RoZXItbW9kdWxlJyBhbmQgdXNlZCBpbiB0 aGUgbG9jYWwgbW9kdWxlIHZpYSAndXNlcyB4OmZvbycuDQo+ID4gSW4gdGhlIHNjaGVtYSB0cmVl IG9mIHRoZSBsb2NhbCBtb2R1bGUsICdhJyBub3cgaGFzIHRoZSBuYW1lc3BhY2UgVVJJIG9mDQo+ ID4gdGhlIGxvY2FsIG1vZHVsZSwgc28gaWYgdGhlIHByZWZpeCAneCcgc3RpbGwgY29ycmVzcG9u ZHMgdG8gdGhlIE5TIFVSSQ0KPiA+IG9mICdvdGhlci1tb2R1bGUnIHRoZSAneDphJyBuYW1lIGlu IHRoZSBtdXN0IHN0YXRlbWVudCBjYW5ub3QgbWF0Y2ggbGVhZg0KPiA+ICdhJywgYWx0aG91Z2gg d2l0aCB0aGUgcnVsZXMgdGhhdCB5b3Ugc3RhdGVkIGVhcmxpZXIgJ3g6YScgd291bGQgbWF0Y2gN Cj4gPiAnYScgaW4gJ290aGVyLW1vZHVsZScgd2hlcmUgZ3JvdXBpbmcgJ2ZvbycgaXMgZGVmaW5l ZC4NCj4gPg0KPiA+IExhZGENCj4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBTbyBJIGFncmVlIHdp dGggQW5keSB0aGF0IHRoZSBjdXJyZW50IHJ1bGVzIHdvcmsgZmluZS4NCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+IC9tYXJ0aW4NCj4gPiAtLQ0KPiA+IExhZGlzbGF2IExob3RrYSwgQ0VTTkVU DQo+ID4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo+ID4NCj4gDQo= From andy@netconfcentral.com Fri Jul 24 14:21:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B193F3A6AB0 for ; Fri, 24 Jul 2009 14:21:09 -0700 (PDT) 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 1frC0ifFGnIo for ; Fri, 24 Jul 2009 14:21:09 -0700 (PDT) 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 299943A68BB for ; Fri, 24 Jul 2009 14:21:09 -0700 (PDT) Received: (qmail 52383 invoked from network); 24 Jul 2009 21:21:08 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 24 Jul 2009 21:21:08 -0000 X-YMail-OSG: g9PT0WgVM1nhCf90NrRicm7EpZyimFPL4cxaspby78k0wCFMk2UX2e55IltxNNYjjXeWD2SHCTGYaGkZn2aXHFoAb2dUT9FoWDWOo6u7sD1RLfMTvn2vqANPHUHNXwnHVZ_t3xFhHXlMldMm2xjgWhm3cuL9Hs5pbJ2XBW3R14hXB.d2VBGwgHDBLLdlgKFgJb8DKW6Xei2B4JpO3rAclukaHVYzWh_UcDryMMt6jlRPG0H.GPBITLdZnDz5khyDmGPP0bvav0PjiMpZ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6A2567.4040507@netconfcentral.com> Date: Fri, 24 Jul 2009 14:19:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907242006.n6OK6101080741@idle.juniper.net> In-Reply-To: <200907242006.n6OK6101080741@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Moving the discussion back toward new concepts 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: , X-List-Received-Date: Fri, 24 Jul 2009 21:21:09 -0000 Phil Shafer wrote: .... > Let's move the discussion back and inspect the real underlaying > issues of things you don't think you can do in YANG, because it's > really hard to see these clearly. > excellent point. The problem statement is not well specified, and (IMO) there is no evidence of any consensus on this critical prerequisite to meaningful discussion of solutions. Why don't we just standardize Python classes and not bother with a DML at all? (only kidding ;-) > Thanks, > Phil Andy From andy@netconfcentral.com Fri Jul 24 17:19:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F5E3A67EC for ; Fri, 24 Jul 2009 17:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 msAO6mVW26XW for ; Fri, 24 Jul 2009 17:19:58 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id DE3FC3A67BD for ; Fri, 24 Jul 2009 17:19:57 -0700 (PDT) Received: (qmail 36886 invoked from network); 25 Jul 2009 00:19:57 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2009 00:19:56 -0000 X-YMail-OSG: RDjNtccVM1mz7NctndvugdQPpFfwsJzRwRxZ9QZbOntNHjokf0lLi4h6nRqOHnHu7JM34nsg7fiBHALRuxQD4PofNfoUcyHgbLwT58PfgtbfmQMaDI.l5YlPPa2hcwQYJyYvDTpHOYgwT7lNE7BU_VbjI1v3lEw4PU_BZZ3vrezseZr6GE2fVL5da2nM00GQy_E.vM_x92nbqhm6Zw9_OfdfYyoGvwoPqQg.LFQASLFmAP_zzjooT6OjnOdgVyodMB0q4ViHjbAoxcb8fFS29xWsNF4Ls2.YwiCUh8ClFY_9Hdu1xdpAu26gbuKF9djX8Yu5f86w36RcwZ7TizbrmUbY X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6A4FC9.4090907@netconfcentral.com> Date: Fri, 24 Jul 2009 17:20:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090721.222540.86226812.mbj@tail-f.com> <200907212108.n6LL8Vh7051806@idle.juniper.net> <20090721.233936.18401704.mbj@tail-f.com> In-Reply-To: <20090721.233936.18401704.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] what if starts out invalid? 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: , X-List-Received-Date: Sat, 25 Jul 2009 00:19:58 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> The point is that if startup (and running) are always valid, this >>> situation does not occur. >> My take on this discussion is that invalid startup configs are an >> ugly fact of life, and while it would be nice to say "don't do >> that", they will inevitably occur. > > [back pedaling a bit] > > Yes, you are right. I have a problem with Andy's original email, and > also the title of this thread -- I don't think running can ever be > invalid. I will make sure that my startup is valid at the time it is > written, but as you say, I can not guarantee that the startup file is > valid with the sw when the device boots. (I can guarantee that > running is valid though). > I think you are right. We need to document all this correctly in yang/usage/4741bis. If we are saying that certain errors are OK to continue (invalid-value) but others are fatal errors (mandatory/min-elements), then it needs to be written down. It is OK for the agent to prune 'bad startup config' as it is loaded into . The operator should be able to choose "stop-on-error" or "continue-on-error" for processing the startup config. (e.g., a CLI parm). Even if "continue-on-error" is done by the agent, the config MUST be completely YANG-validated OK or the agent will not start. The problem is that we have no way to send out notifications to the operator that this problem is happening. But via polling, the device will disappear from radar, and get attention, as Phil noted. The "rollback-on-error" option also applies to . It could mean "try the current , and go back to the last if it does not validate". (But I digress... ;-) In summary: - , and can fail the operation - if fails the initial startup operation, the agent must not accept NETCONF sessions (cannot force a shutdown). So what happens if the device capabilities or sub-systems change during run-time? This goes back to the old question of pre-provisioning. What if 1 implementation keeps the 'dead' config, and another deletes it, causing an invalid config? I assume its OK to have subtrees in the config that may not have hardware or for whatever reason are not installed at the moment. But the manager cannot tell (other than adding 'enabled' flags to all the data structures), the difference between live config and pending config. It's possible that the agent implementation doesn't even know for sure. That support would need to be built-in. I think the standard should eventually deal with this somehow. >> Do we need to say what devices >> should do, or do we leave implementors to do their best? > > I would prefer the latter. Then Andy can do his delete and you and I > can make our space heaters. > > > /martin > Andy From lhotka@cesnet.cz Sat Jul 25 06:35:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A29D3A67FF for ; Sat, 25 Jul 2009 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, 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 wIuVVKwi9HEk for ; Sat, 25 Jul 2009 06:35:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2A9F63A6948 for ; Sat, 25 Jul 2009 06:35:26 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AF596D800C5; Sat, 25 Jul 2009 15:34:01 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A6A109E.8000403@netconfcentral.com> References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> <1248464183.30014.42.camel@missotis> <4A6A109E.8000403@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 25 Jul 2009 15:34:00 +0200 Message-Id: <1248528840.9384.48.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Sat, 25 Jul 2009 13:35:29 -0000 Andy Bierman píše v Pá 24. 07. 2009 v 12:50 -0700: > Ladislav Lhotka wrote: > > Hi Tom, > > > > this ambiguity is due to the fact that the handling of prefixes in > > groupings is inconsistent. I tried to propose a remedy: > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg03052.html > > > > In simple terms: > > > > - unprefixed name in a grouping => null namespace URI, this name will > > adopt the namespace of the module where the grouping is used > > - a prefixed name in a grouping always stays in the namespace the > > prefix is bound to in the module where the grouping is defined. > > > > Except this is fatally flawed because it breaks the > "grouping transparency rule". > > For any set of sibling objects, it should not make any > difference whether they are declared inline or via a > uses statement. It doesn't, if the module writer uses names without NS prefixes. > > Prefixes are handled consistently now (IMO) > because all the QNames appearing in the same YANG [sub]module, > will be processed the same way. > > We have to resolve QNames as soon as possible, > not as late as possible, when they are used within > a definition. Assigning a namespace to the exported > definition is not the same thing as resolving the > dependencies within that definition. OK, so consider the following module: module foo { namespace "http://example.net/foo"; prefix foo; grouping ggg { ... must "foo:bar < 42"; leaf bar { type uint8; } ... } ... } Now, resolving the QName as early as possible means that "foo:bar" is resolved to "{http://example.net/foo}bar". If module "foo" is imported and grouping "ggg" is then used in another module, this QName should no more mean the name of the adjacent leaf because the latter assumes the namespace of the importing module. Using my rules, this would be a consequence of using the prefixed name. However, if the must expression was must "bar < 42"; it would be guaranteed that "bar" always refers to the adjacent leaf. Lada > > > > Lada > > Andy > > > > > tom.petch píše v Pá 24. 07. 2009 v 17:51 +0200: > >> Apologies for taking so long to fail to understand this - I was away at the > >> time. > >> > >> But.... > >> > >> Martin in an earlier post in the thread said > >> "If a must/when expression in a grouping refers to a node in the > >> grouping - with or without prefix - at conceptual evaluation time they > >> will always refer to the node within the grouping, i.e. with the > >> namespace of the module where the grouping is used." > >> > >> Forget the must/when and XPath:-), I cannot reconcile > >> "at conceptual evaluation time they > >> will always refer to the node within the grouping" > >> which suggests that a leaf in a grouping is in the namespace of the module > >> where the grouping appears, which is what I also get from > >> " Identifiers appearing inside the > >> grouping are resolved relative to the scope in which the grouping is > >> defined, not where it is used." from yang-07. > >> > >> But > >> " with the namespace of the module where the grouping is used." > >> tells me the opposite, that it is the namespace of the module > >> in which the uses statement appears. > >> > >> or to quote Andy > >> "The objects themselves will end up with the namespace > >> of the final 'uses stmt'." > >> > >> I am not saying one or the other is preferrable, just that I cannot get > >> a single meaning from words used in this thread and the I-D. > >> > >> By contrast, I am comfortable with the interpretation of prefixes; there all the > >> text tells me the same thing. > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Ladislav Lhotka" > >> To: "Martin Bjorklund" > >> Cc: > >> Sent: Friday, July 03, 2009 10:32 AM > >> Subject: Re: [netmod] prefixes in groupings > >> > >> > >>> Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: > >>>> Ladislav Lhotka wrote: > >>>>> prefix x; > >>>>> > >>>>> grouping foo { > >>>>> container c { > >>>>> must "x:a < ../x:above"; > >>>>> leaf a { ... } > >>>>> } > >>>>> } > >>>>> > >>>>> it would be pretty confusing if the resolution of the same prefix "x" > >>>>> was fixed for 'x:above' and postponed for 'x:a'. > >>>> The point is that you cannot expect to do a simple text substitution > >>>> when you implement 'uses'. For example, my module might import your > >>>> module and some other module: > >>>> > >>>> import foo-module { > >>>> prefix f; > >>>> } > >>>> import other-module { > >>>> prefix x; > >>>> } > >>>> > >>>> uses foo; > >>>> > >>>> The prefix "x" in the grouping must not be resolved in this context! > >>>> This is no different for must expressions than for references to types > >>>> or whatever. For example: > >>>> > >>>> grouping foo { > >>>> typedef my-type { type int32; } > >>>> container c { > >>>> must "x:a < ../x:above"; > >>>> leaf a { type x:my-type } // legal > >>>> } > >>>> } > >>> This is all fine, the problem would arise when this grouping 'foo' is > >>> defined in 'other-module' and used in the local module via 'uses x:foo'. > >>> In the schema tree of the local module, 'a' now has the namespace URI of > >>> the local module, so if the prefix 'x' still corresponds to the NS URI > >>> of 'other-module' the 'x:a' name in the must statement cannot match leaf > >>> 'a', although with the rules that you stated earlier 'x:a' would match > >>> 'a' in 'other-module' where grouping 'foo' is defined. > >>> > >>> Lada > >>> > >>>> > >>>> So I agree with Andy that the current rules work fine. > >>>> > >>>> > >>>> > >>>> /martin > >>> -- > >>> Ladislav Lhotka, CESNET > >>> PGP Key ID: E74E8C0C > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Jul 25 07:21:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC88B3A69FE for ; Sat, 25 Jul 2009 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 FDl9Wt5VxnzS for ; Sat, 25 Jul 2009 07:21:25 -0700 (PDT) Received: from n16b.bullet.mail.mud.yahoo.com (n16b.bullet.mail.mud.yahoo.com [68.142.207.237]) by core3.amsl.com (Postfix) with SMTP id 861C73A6768 for ; Sat, 25 Jul 2009 07:21:25 -0700 (PDT) Received: from [68.142.200.224] by n16.bullet.mail.mud.yahoo.com with NNFMP; 25 Jul 2009 14:07:25 -0000 Received: from [68.142.201.242] by t5.bullet.mud.yahoo.com with NNFMP; 25 Jul 2009 14:07:25 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 25 Jul 2009 14:07:25 -0000 X-Yahoo-Newman-Id: 366224.65465.bm@omp403.mail.mud.yahoo.com Received: (qmail 21118 invoked from network); 25 Jul 2009 14:07:24 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 25 Jul 2009 14:07:24 -0000 X-YMail-OSG: YWmGssAVM1nbQr_T9vm7D6VujCHNA3IVw_nRdE_3.LXlT0hUr415iuMJkGX4E_txDPARAp9ThcLoYSgplKX1KaGD8qMjpRdHV0j6h9yFn.mMC4t2UNLNVoKFPVcE8M_EHe7p9LiGTCkxQdDKo0zG1eoIeEIJqPDZqzv8YbDxCPzPQ7YPl4yC4lgJLc0bZ5.CRfGNjUMk_EK4Bqu0e_g77F2L41q8AAh3jgAyC022zMdpzZ_kar_RUyILrcPOq_RZPsUsKgnZ_k4N3k8_FkIKAo8g0tq6g2TNsPk7YhLqUkMfGNkdpf22 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6B11BF.8000600@netconfcentral.com> Date: Sat, 25 Jul 2009 07:07:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> <1248464183.30014.42.camel@missotis> <4A6A109E.8000403@netconfcentral.com> <1248528840.9384.48.camel@nomad> In-Reply-To: <1248528840.9384.48.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Sat, 25 Jul 2009 14:21:27 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Pá 24. 07. 2009 v 12:50 -0700: >> Ladislav Lhotka wrote: >>> Hi Tom, >>> >>> this ambiguity is due to the fact that the handling of prefixes in >>> groupings is inconsistent. I tried to propose a remedy: >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg03052.html >>> >>> In simple terms: >>> >>> - unprefixed name in a grouping => null namespace URI, this name will >>> adopt the namespace of the module where the grouping is used >>> - a prefixed name in a grouping always stays in the namespace the >>> prefix is bound to in the module where the grouping is defined. >>> >> Except this is fatally flawed because it breaks the >> "grouping transparency rule". >> >> For any set of sibling objects, it should not make any >> difference whether they are declared inline or via a >> uses statement. > > It doesn't, if the module writer uses names without NS prefixes. > Prefixes are not a problem at all. Perhaps the terminology needs to be better aligned with XML. It is not the QName that gets carried forward when a uses-stmt is processed. It is the expanded-name that is remembered, not the QName. http://www.w3.org/TR/xpath#dt-expanded-name Andy >> Prefixes are handled consistently now (IMO) >> because all the QNames appearing in the same YANG [sub]module, >> will be processed the same way. >> >> We have to resolve QNames as soon as possible, >> not as late as possible, when they are used within >> a definition. Assigning a namespace to the exported >> definition is not the same thing as resolving the >> dependencies within that definition. > > OK, so consider the following module: > > module foo { > namespace "http://example.net/foo"; > prefix foo; > grouping ggg { > ... > must "foo:bar < 42"; > leaf bar { type uint8; } > ... > } > ... > } > > Now, resolving the QName as early as possible means that "foo:bar" is > resolved to "{http://example.net/foo}bar". If module "foo" is imported > and grouping "ggg" is then used in another module, this QName should no > more mean the name of the adjacent leaf because the latter assumes the > namespace of the importing module. Using my rules, this would be a > consequence of using the prefixed name. However, if the must expression > was > > must "bar < 42"; > > it would be guaranteed that "bar" always refers to the adjacent leaf. > > Lada > >> >>> Lada >> Andy >> >>> tom.petch píše v Pá 24. 07. 2009 v 17:51 +0200: >>>> Apologies for taking so long to fail to understand this - I was away at the >>>> time. >>>> >>>> But.... >>>> >>>> Martin in an earlier post in the thread said >>>> "If a must/when expression in a grouping refers to a node in the >>>> grouping - with or without prefix - at conceptual evaluation time they >>>> will always refer to the node within the grouping, i.e. with the >>>> namespace of the module where the grouping is used." >>>> >>>> Forget the must/when and XPath:-), I cannot reconcile >>>> "at conceptual evaluation time they >>>> will always refer to the node within the grouping" >>>> which suggests that a leaf in a grouping is in the namespace of the module >>>> where the grouping appears, which is what I also get from >>>> " Identifiers appearing inside the >>>> grouping are resolved relative to the scope in which the grouping is >>>> defined, not where it is used." from yang-07. >>>> >>>> But >>>> " with the namespace of the module where the grouping is used." >>>> tells me the opposite, that it is the namespace of the module >>>> in which the uses statement appears. >>>> >>>> or to quote Andy >>>> "The objects themselves will end up with the namespace >>>> of the final 'uses stmt'." >>>> >>>> I am not saying one or the other is preferrable, just that I cannot get >>>> a single meaning from words used in this thread and the I-D. >>>> >>>> By contrast, I am comfortable with the interpretation of prefixes; there all the >>>> text tells me the same thing. >>>> >>>> Tom Petch >>>> >>>> ----- Original Message ----- >>>> From: "Ladislav Lhotka" >>>> To: "Martin Bjorklund" >>>> Cc: >>>> Sent: Friday, July 03, 2009 10:32 AM >>>> Subject: Re: [netmod] prefixes in groupings >>>> >>>> >>>>> Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: >>>>>> Ladislav Lhotka wrote: >>>>>>> prefix x; >>>>>>> >>>>>>> grouping foo { >>>>>>> container c { >>>>>>> must "x:a < ../x:above"; >>>>>>> leaf a { ... } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> it would be pretty confusing if the resolution of the same prefix "x" >>>>>>> was fixed for 'x:above' and postponed for 'x:a'. >>>>>> The point is that you cannot expect to do a simple text substitution >>>>>> when you implement 'uses'. For example, my module might import your >>>>>> module and some other module: >>>>>> >>>>>> import foo-module { >>>>>> prefix f; >>>>>> } >>>>>> import other-module { >>>>>> prefix x; >>>>>> } >>>>>> >>>>>> uses foo; >>>>>> >>>>>> The prefix "x" in the grouping must not be resolved in this context! >>>>>> This is no different for must expressions than for references to types >>>>>> or whatever. For example: >>>>>> >>>>>> grouping foo { >>>>>> typedef my-type { type int32; } >>>>>> container c { >>>>>> must "x:a < ../x:above"; >>>>>> leaf a { type x:my-type } // legal >>>>>> } >>>>>> } >>>>> This is all fine, the problem would arise when this grouping 'foo' is >>>>> defined in 'other-module' and used in the local module via 'uses x:foo'. >>>>> In the schema tree of the local module, 'a' now has the namespace URI of >>>>> the local module, so if the prefix 'x' still corresponds to the NS URI >>>>> of 'other-module' the 'x:a' name in the must statement cannot match leaf >>>>> 'a', although with the rules that you stated earlier 'x:a' would match >>>>> 'a' in 'other-module' where grouping 'foo' is defined. >>>>> >>>>> Lada >>>>> >>>>>> So I agree with Andy that the current rules work fine. >>>>>> >>>>>> >>>>>> >>>>>> /martin >>>>> -- >>>>> Ladislav Lhotka, CESNET >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> From cfinss@dial.pipex.com Sun Jul 26 13:01:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFFD3A6B79 for ; Sun, 26 Jul 2009 13:01:48 -0700 (PDT) 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.225, BAYES_00=-2.599, J_CHICKENPOX_13=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 MDJSCTFGAfa8 for ; Sun, 26 Jul 2009 13:01:47 -0700 (PDT) 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 DB20D3A69D0 for ; Sun, 26 Jul 2009 13:01:46 -0700 (PDT) X-Trace: 270574538/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.146/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.146 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: 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: AkQFABZTbEo+vGSS/2dsb2JhbACDLFqMNLwQCYQEBYFI X-IronPort-AV: E=Sophos;i="4.43,272,1246834800"; d="scan'208";a="270574538" X-IP-Direction: IN Received: from 1cust146.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.146]) by smtp.pipex.tiscali.co.uk with SMTP; 26 Jul 2009 21:01:45 +0100 Message-ID: <002101ca0e23$73a94dc0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <20090702.223647.12999120.mbj@tail-f.com><1246609976.6530.17.camel@missotis><000401ca0c82$7ef8d940$0601a8c0@allison> <20090724.232018.193773390.mbj@tail-f.com> Date: Sun, 26 Jul 2009 21:00:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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] prefixes in groupings 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: , X-List-Received-Date: Sun, 26 Jul 2009 20:01:48 -0000 Martin Many thanks, that is crystal clear. But... what I cannot then understand is the sentence in netmod-yang-07, to whit, " Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used." "Identifiers .. resolved relative to the scope ... is defined" I see that as telling me when to add a namespace to an identifier, by prefix or by default, and telling me that that happens where the grouping is defined, not where it is used so I understand grouping foo { leaf x { type int32; } } places 'x' with no prefix as being in namespace "http://example.com/a"; How am I misreading that sentence? Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Friday, July 24, 2009 11:20 PM Subject: Re: [netmod] prefixes in groupings > Hi, > > I think there are two issues here. The first is which namespace > nodes in a grouping belong to. The answer is that it is the namespace > of the module that has the uses statement. For example: > > module a { > namespace "http://example.com/a"; > prefix a; > > grouping foo { > leaf x { type int32; } > } > } > > module b { > namespace "http://example.com/b"; > prefix b; > > import a { prefix a; } > > uses a:foo; > } > > module c { > namespace "http://example.com/c"; > prefix c; > > import a { prefix a; } > > uses a:foo; > } > > The leaf x now exists in two XML namespaces, e.g. > > ... > > 42 > 4711 > > > > The second issue is how prefixes are resolved within groupings. > In the example above, suppose the foo grouping is defined like this > instead: > > grouping foo { > leaf x { > type int32; > } > leaf y { > type int32; > must "current() < a:x"; > } > } > > The notion "a:x" is used to refer to the node "x" within the > grouping. When the grouping is used in modules b and c, you cannot > just do a syntactical substitution of the grouping contents. You must > substitue the "resolved structure", where "a:x" is already resolved. > > This is consistent with how type names are resolved in this example: > > grouping foo { > leaf x { > type int32; > } > leaf y { > type a:my-type; > must "current() < a:x"; > } > typedef my-type { > type int32; > } > } > > Again, the type of 'y' must be resolved prior to the uses expansion. > > > /martin > > > > "tom.petch" wrote: > > Apologies for taking so long to fail to understand this - I was away at the > > time. > > > > But.... > > > > Martin in an earlier post in the thread said > > "If a must/when expression in a grouping refers to a node in the > > grouping - with or without prefix - at conceptual evaluation time they > > will always refer to the node within the grouping, i.e. with the > > namespace of the module where the grouping is used." > > > > Forget the must/when and XPath:-), I cannot reconcile > > "at conceptual evaluation time they > > will always refer to the node within the grouping" > > which suggests that a leaf in a grouping is in the namespace of the module > > where the grouping appears, which is what I also get from > > " Identifiers appearing inside the > > grouping are resolved relative to the scope in which the grouping is > > defined, not where it is used." from yang-07. > > > > But > > " with the namespace of the module where the grouping is used." > > tells me the opposite, that it is the namespace of the module > > in which the uses statement appears. > > > > or to quote Andy > > "The objects themselves will end up with the namespace > > of the final 'uses stmt'." > > > > I am not saying one or the other is preferrable, just that I cannot get > > a single meaning from words used in this thread and the I-D. > > > > By contrast, I am comfortable with the interpretation of prefixes; there all > > the > > text tells me the same thing. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Ladislav Lhotka" > > To: "Martin Bjorklund" > > Cc: > > Sent: Friday, July 03, 2009 10:32 AM > > Subject: Re: [netmod] prefixes in groupings > > > > > > > Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: > > > > Ladislav Lhotka wrote: > > > > > prefix x; > > > > > > > > > > grouping foo { > > > > > container c { > > > > > must "x:a < ../x:above"; > > > > > leaf a { ... } > > > > > } > > > > > } > > > > > > > > > > it would be pretty confusing if the resolution of the same prefix "x" > > > > > was fixed for 'x:above' and postponed for 'x:a'. > > > > > > > > The point is that you cannot expect to do a simple text substitution > > > > when you implement 'uses'. For example, my module might import your > > > > module and some other module: > > > > > > > > import foo-module { > > > > prefix f; > > > > } > > > > import other-module { > > > > prefix x; > > > > } > > > > > > > > uses foo; > > > > > > > > The prefix "x" in the grouping must not be resolved in this context! > > > > This is no different for must expressions than for references to types > > > > or whatever. For example: > > > > > > > > grouping foo { > > > > typedef my-type { type int32; } > > > > container c { > > > > must "x:a < ../x:above"; > > > > leaf a { type x:my-type } // legal > > > > } > > > > } > > > > > > This is all fine, the problem would arise when this grouping 'foo' is > > > defined in 'other-module' and used in the local module via 'uses x:foo'. > > > In the schema tree of the local module, 'a' now has the namespace URI of > > > the local module, so if the prefix 'x' still corresponds to the NS URI > > > of 'other-module' the 'x:a' name in the must statement cannot match leaf > > > 'a', although with the rules that you stated earlier 'x:a' would match > > > 'a' in 'other-module' where grouping 'foo' is defined. > > > > > > Lada > > > > > > > > > > > > > > > So I agree with Andy that the current rules work fine. > > > > > > > > > > > > > > > > /martin > > > -- > > > Ladislav Lhotka, CESNET > > > PGP Key ID: E74E8C0C > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > From lhotka@cesnet.cz Mon Jul 27 01:01:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBEC28C151 for ; Mon, 27 Jul 2009 01:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, 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 9JyaeyLKUVAw for ; Mon, 27 Jul 2009 01:01:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B120B28C20F for ; Mon, 27 Jul 2009 01:01:04 -0700 (PDT) Received: from [130.129.18.69] (dhcp-1245.meeting.ietf.org [130.129.18.69]) by office2.cesnet.cz (Postfix) with ESMTP id E82B7D800C1; Mon, 27 Jul 2009 10:01:04 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A6B11BF.8000600@netconfcentral.com> References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> <1248464183.30014.42.camel@missotis> <4A6A109E.8000403@netconfcentral.com> <1248528840.9384.48.camel@nomad> <4A6B11BF.8000600@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 27 Jul 2009 10:00:59 +0200 Message-Id: <1248681659.4454.11.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Mon, 27 Jul 2009 08:01:07 -0000 Andy Bierman píše v So 25. 07. 2009 v 07:07 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Pá 24. 07. 2009 v 12:50 -0700: > >> Ladislav Lhotka wrote: > >>> Hi Tom, > >>> > >>> this ambiguity is due to the fact that the handling of prefixes in > >>> groupings is inconsistent. I tried to propose a remedy: > >>> > >>> http://www.ietf.org/mail-archive/web/netmod/current/msg03052.html > >>> > >>> In simple terms: > >>> > >>> - unprefixed name in a grouping => null namespace URI, this name will > >>> adopt the namespace of the module where the grouping is used > >>> - a prefixed name in a grouping always stays in the namespace the > >>> prefix is bound to in the module where the grouping is defined. > >>> > >> Except this is fatally flawed because it breaks the > >> "grouping transparency rule". > >> > >> For any set of sibling objects, it should not make any > >> difference whether they are declared inline or via a > >> uses statement. > > > > It doesn't, if the module writer uses names without NS prefixes. > > > > > Prefixes are not a problem at all. > Perhaps the terminology needs to be better aligned with XML. > It is not the QName that gets carried forward when a > uses-stmt is processed. It is the expanded-name > that is remembered, not the QName. > > http://www.w3.org/TR/xpath#dt-expanded-name > I fully agree, but somehow we still come to different conclusions. Back to my example: the QName "foo:bar" is resolved in the context of module "foo" to "{http://example.net/foo}bar", right? (I am using James Clark's notation for expanded names here.) Then, if the grouping "ggg" is used in another module, the must constraint will never match due to the mismatch in namespaces since leaf "bar" now has the namespace URI of the module in which the grouping was used. Do we agree on this? Lada > > Andy > > >> Prefixes are handled consistently now (IMO) > >> because all the QNames appearing in the same YANG [sub]module, > >> will be processed the same way. > >> > >> We have to resolve QNames as soon as possible, > >> not as late as possible, when they are used within > >> a definition. Assigning a namespace to the exported > >> definition is not the same thing as resolving the > >> dependencies within that definition. > > > > OK, so consider the following module: > > > > module foo { > > namespace "http://example.net/foo"; > > prefix foo; > > grouping ggg { > > ... > > must "foo:bar < 42"; > > leaf bar { type uint8; } > > ... > > } > > ... > > } > > > > Now, resolving the QName as early as possible means that "foo:bar" is > > resolved to "{http://example.net/foo}bar". If module "foo" is imported > > and grouping "ggg" is then used in another module, this QName should no > > more mean the name of the adjacent leaf because the latter assumes the > > namespace of the importing module. Using my rules, this would be a > > consequence of using the prefixed name. However, if the must expression > > was > > > > must "bar < 42"; > > > > it would be guaranteed that "bar" always refers to the adjacent leaf. > > > > Lada > > > >> > >>> Lada > >> Andy > >> > >>> tom.petch píše v Pá 24. 07. 2009 v 17:51 +0200: > >>>> Apologies for taking so long to fail to understand this - I was away at the > >>>> time. > >>>> > >>>> But.... > >>>> > >>>> Martin in an earlier post in the thread said > >>>> "If a must/when expression in a grouping refers to a node in the > >>>> grouping - with or without prefix - at conceptual evaluation time they > >>>> will always refer to the node within the grouping, i.e. with the > >>>> namespace of the module where the grouping is used." > >>>> > >>>> Forget the must/when and XPath:-), I cannot reconcile > >>>> "at conceptual evaluation time they > >>>> will always refer to the node within the grouping" > >>>> which suggests that a leaf in a grouping is in the namespace of the module > >>>> where the grouping appears, which is what I also get from > >>>> " Identifiers appearing inside the > >>>> grouping are resolved relative to the scope in which the grouping is > >>>> defined, not where it is used." from yang-07. > >>>> > >>>> But > >>>> " with the namespace of the module where the grouping is used." > >>>> tells me the opposite, that it is the namespace of the module > >>>> in which the uses statement appears. > >>>> > >>>> or to quote Andy > >>>> "The objects themselves will end up with the namespace > >>>> of the final 'uses stmt'." > >>>> > >>>> I am not saying one or the other is preferrable, just that I cannot get > >>>> a single meaning from words used in this thread and the I-D. > >>>> > >>>> By contrast, I am comfortable with the interpretation of prefixes; there all the > >>>> text tells me the same thing. > >>>> > >>>> Tom Petch > >>>> > >>>> ----- Original Message ----- > >>>> From: "Ladislav Lhotka" > >>>> To: "Martin Bjorklund" > >>>> Cc: > >>>> Sent: Friday, July 03, 2009 10:32 AM > >>>> Subject: Re: [netmod] prefixes in groupings > >>>> > >>>> > >>>>> Martin Bjorklund píše v Čt 02. 07. 2009 v 22:36 +0200: > >>>>>> Ladislav Lhotka wrote: > >>>>>>> prefix x; > >>>>>>> > >>>>>>> grouping foo { > >>>>>>> container c { > >>>>>>> must "x:a < ../x:above"; > >>>>>>> leaf a { ... } > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> it would be pretty confusing if the resolution of the same prefix "x" > >>>>>>> was fixed for 'x:above' and postponed for 'x:a'. > >>>>>> The point is that you cannot expect to do a simple text substitution > >>>>>> when you implement 'uses'. For example, my module might import your > >>>>>> module and some other module: > >>>>>> > >>>>>> import foo-module { > >>>>>> prefix f; > >>>>>> } > >>>>>> import other-module { > >>>>>> prefix x; > >>>>>> } > >>>>>> > >>>>>> uses foo; > >>>>>> > >>>>>> The prefix "x" in the grouping must not be resolved in this context! > >>>>>> This is no different for must expressions than for references to types > >>>>>> or whatever. For example: > >>>>>> > >>>>>> grouping foo { > >>>>>> typedef my-type { type int32; } > >>>>>> container c { > >>>>>> must "x:a < ../x:above"; > >>>>>> leaf a { type x:my-type } // legal > >>>>>> } > >>>>>> } > >>>>> This is all fine, the problem would arise when this grouping 'foo' is > >>>>> defined in 'other-module' and used in the local module via 'uses x:foo'. > >>>>> In the schema tree of the local module, 'a' now has the namespace URI of > >>>>> the local module, so if the prefix 'x' still corresponds to the NS URI > >>>>> of 'other-module' the 'x:a' name in the must statement cannot match leaf > >>>>> 'a', although with the rules that you stated earlier 'x:a' would match > >>>>> 'a' in 'other-module' where grouping 'foo' is defined. > >>>>> > >>>>> Lada > >>>>> > >>>>>> So I agree with Andy that the current rules work fine. > >>>>>> > >>>>>> > >>>>>> > >>>>>> /martin > >>>>> -- > >>>>> Ladislav Lhotka, CESNET > >>>>> PGP Key ID: E74E8C0C > >>>>> > >>>>> _______________________________________________ > >>>>> netmod mailing list > >>>>> netmod@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>> > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jul 27 01:55:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20A13A6886 for ; Mon, 27 Jul 2009 01:55:27 -0700 (PDT) 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 zzLL1zHtsT01 for ; Mon, 27 Jul 2009 01:55:26 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BE7EF3A6824 for ; Mon, 27 Jul 2009 01:55:26 -0700 (PDT) Received: from localhost (dhcp-1267.meeting.ietf.org [130.129.18.103]) by mail.tail-f.com (Postfix) with ESMTPSA id F1CB6616016; Mon, 27 Jul 2009 10:55:26 +0200 (CEST) Date: Mon, 27 Jul 2009 10:55:26 +0200 (CEST) Message-Id: <20090727.105526.38124005.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <002101ca0e23$73a94dc0$0601a8c0@allison> References: <000401ca0c82$7ef8d940$0601a8c0@allison> <20090724.232018.193773390.mbj@tail-f.com> <002101ca0e23$73a94dc0$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Mon, 27 Jul 2009 08:55:27 -0000 "tom.petch" wrote: > Martin > > Many thanks, that is crystal clear. > > But... > what I cannot then understand is the sentence in netmod-yang-07, to whit, > " Identifiers appearing inside the > grouping are resolved relative to the scope in which the grouping is > defined, not where it is used." > > "Identifiers .. resolved relative to the scope ... is defined" > > I see that as telling me when to add a namespace to an identifier, by > prefix or by default, and telling me that that happens where the grouping > is defined, not where it is used so I understand > grouping foo { > leaf x { type int32; } > } > places 'x' with no prefix as being in > namespace "http://example.com/a"; > > How am I misreading that sentence? Here's an expanded example where an identifier is resloved according to the rule above: module a { namespace "http://example.com/a"; prefix a; typedef t { ... } grouping foo { leaf x { type a:t; } } } Now, the identifier "a:t" is resolved in the scope where the grouping is definied, thus it means the type "t" in module "a". Note that this does *not* place 'x' in the XML namespace "http://example.com/a" - nodes are placed in the XML namespace of where the grouping is used. /martin From mbj@tail-f.com Mon Jul 27 02:44:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CC03A6C1C for ; Mon, 27 Jul 2009 02:44:45 -0700 (PDT) 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 y3Kd-Hy55UJL for ; Mon, 27 Jul 2009 02:44:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1D2CB3A69EF for ; Mon, 27 Jul 2009 02:44:45 -0700 (PDT) Received: from localhost (dhcp-1267.meeting.ietf.org [130.129.18.103]) by mail.tail-f.com (Postfix) with ESMTPSA id C2ECA616004; Mon, 27 Jul 2009 11:44:19 +0200 (CEST) Date: Mon, 27 Jul 2009 11:44:19 +0200 (CEST) Message-Id: <20090727.114419.32547097.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1248681659.4454.11.camel@nomad> References: <1248528840.9384.48.camel@nomad> <4A6B11BF.8000600@netconfcentral.com> <1248681659.4454.11.camel@nomad> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Mon, 27 Jul 2009 09:44:46 -0000 Ladislav Lhotka wrote: > I fully agree, but somehow we still come to different conclusions. > Back to my example: the QName "foo:bar" is resolved in the context of > module "foo" to "{http://example.net/foo}bar", right? (I am using James > Clark's notation for expanded names here.) Then, if the grouping "ggg" > is used in another module, the must constraint will never match due to > the mismatch in namespaces since leaf "bar" now has the namespace URI of > the module in which the grouping was used. Do we agree on this? Yes, you have convinced me that this is the correct way to handle this. In the grouping: grouping foo { leaf a { type int32; must ". < ../b"; // (*) } leaf b { type int32; } } leafs a and b are not bound to any namespace, so it makes sense to use no prefix in the must expression at (*). (I will bring this up as an open issue at the session today) /martin From brent@netomata.com Mon Jul 27 04:38:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148C428C1C0 for ; Mon, 27 Jul 2009 04:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdZrQX7NSyJb for ; Mon, 27 Jul 2009 04:38:11 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 1112828C20A for ; Mon, 27 Jul 2009 04:38:10 -0700 (PDT) Received: by bwz21 with SMTP id 21so159538bwz.37 for ; Mon, 27 Jul 2009 04:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.71.65 with SMTP id g1mr3064032bkj.27.1248694689080; Mon, 27 Jul 2009 04:38:09 -0700 (PDT) Date: Mon, 27 Jul 2009 13:38:09 +0200 Message-ID: From: Brent Chapman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=00504502ddc6602aaf046fae6363 Subject: [netmod] How to represent durations? 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: , X-List-Received-Date: Mon, 27 Jul 2009 11:38:12 -0000 --00504502ddc6602aaf046fae6363 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My apologies for coming late to the discussion, but how do you represent durations (i.e, "30 seconds", "60 minutes", "20 milli-seconds") in NETMOD? For instance, if I'm setting up an ARP cache expiration policy for a particular device, I might want to set it to "10 minutes". If I'm setting a VRRP failover policy, I might want to say "30 seconds". If I want to set a jitter limit parameter on a VOIP link, I might want to express it in milli-seconds. -Brent -- Brent Chapman Netomata, Inc. -- www.netomata.com Making networks more cost-effective, reliable, and flexible by automating network configuration --00504502ddc6602aaf046fae6363 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My apologies for coming late to the discussion, but how do you represent du= rations (i.e, "30 seconds", "60 minutes", "20 mill= i-seconds") in NETMOD?

For instance, if I= 9;m setting up an ARP cache expiration=A0policy=A0for=A0a=A0particular=A0de= vice,=A0I=A0might=A0want=A0to=A0set=A0it=A0to=A0"10=A0minutes".= =A0=A0If=A0I'm=A0setting=A0a=A0VRRP=A0failover=A0policy,=A0I=A0might=A0= want=A0to=A0say=A0"30=A0seconds".=A0=A0If=A0I=A0want=A0to=A0set= =A0a=A0jitter=A0limit=A0parameter=A0on=A0a=A0VOIP=A0link,=A0I=A0might=A0wan= t=A0to=A0express=A0it=A0in=A0milli-seconds.


-Brent
--
Brent Chapman <= brent@netomata.com>
Netomat= a, Inc. -- www.netomata.com
Maki= ng networks more cost-effective, reliable, and flexible by automating netwo= rk configuration

--00504502ddc6602aaf046fae6363-- From j.schoenwaelder@jacobs-university.de Mon Jul 27 05:05:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEEC3A69E8 for ; Mon, 27 Jul 2009 05:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.982 X-Spam-Level: X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, GB_I_LETTER=-2, 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 9RNCH9lrlLKE for ; Mon, 27 Jul 2009 05:05:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1B6603A6C5B for ; Mon, 27 Jul 2009 05:05:49 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF3C1C0041 for ; Mon, 27 Jul 2009 14:05:36 +0200 (CEST) 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 qqfcL3pUalA9; Mon, 27 Jul 2009 14:05:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20C56C0040; Mon, 27 Jul 2009 14:05:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A58BFB6D66E; Mon, 27 Jul 2009 14:05:35 +0200 (CEST) Date: Mon, 27 Jul 2009 14:05:35 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090727120535.GA10672@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 12:05:50 -0000 Hi, during the WG meeting, the date-and-time canonicalization rules came up and it was not clear whether the text forces all canonical date-and-time values to be in UTC. Here is the relevant text: The canonical format for date-and-time values mandates the UTC time format with the time-offset is indicated by the letter "Z". This is consistent with the canonical format used by the dateTime XML schema type. Since YANG requires to send data in canonical format (section 9.1 of the YANG document), this essentially means date-and-time values are pretty much always in UTC when you get them from a device. This is likely not what operationally is always wanted. If we allow non UTC time zones, then of course we allow for multiple different representations for the same value. According to section 9.1 of the YANG document, this is actually allowed. Should date-and-time make use of this special rule? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brent@netomata.com Mon Jul 27 05:59:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14A33A6A82 for ; Mon, 27 Jul 2009 05:59:43 -0700 (PDT) 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.380, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntjUDuN4-t-H for ; Mon, 27 Jul 2009 05:59:42 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 9183E3A67FC for ; Mon, 27 Jul 2009 05:59:42 -0700 (PDT) Received: by bwz21 with SMTP id 21so202662bwz.37 for ; Mon, 27 Jul 2009 05:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.65.16 with SMTP id g16mr3131601bki.37.1248699573764; Mon, 27 Jul 2009 05:59:33 -0700 (PDT) In-Reply-To: <20090727120535.GA10672@elstar.local> References: <20090727120535.GA10672@elstar.local> Date: Mon, 27 Jul 2009 14:59:33 +0200 Message-ID: From: Brent Chapman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=0016e6ddfff68684c9046faf86a9 Subject: Re: [netmod] data-and-time canonicalization 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: , X-List-Received-Date: Mon, 27 Jul 2009 12:59:43 -0000 --0016e6ddfff68684c9046faf86a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A related issue... How do I specify times that are in the local timezone, regardless of date? And how do I specify day-of-week? For example, some firewalls enable you to configure rules to block certain traffic during certain hours of the day, perhaps further limited to certain days of the week. For instance, a business might set a firewall rule of "block all HTTP traffic to www.facebook.com between 8am and 5pm local time, Monday through Friday", or parents (or someone offering an "Internet for families" service) might set two firewall rules of the form "block all HTTP traffic except to www.wikipedia.com by default" (so that the kids can use it to do their homework) and "allow all HTTP traffic between 6pm and 10pm weekdays and all day on weekends" (so that the kids can surf the Internet freely in the evenings and on weekends). How would the time-of-day and day-of-week aspects of those rules be expressed in YANG? Don't forget daylight savings time changes... -Brent -- Brent Chapman Netomata, Inc. -- www.netomata.com Making networks more cost-effective, reliable, and flexible by automating network configuration --0016e6ddfff68684c9046faf86a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A related issue... =A0How do I specify times that are in the local timezone= , regardless of date? =A0And how do I specify day-of-week?

For example, some firewalls enable you to configure rules to block certa= in traffic during certain hours of the day, perhaps further limited to cert= ain days of the week. =A0For instance, a business might set a firewall rule= of "block all HTTP traffic to www= .facebook.com between 8am and 5pm local time, Monday through Friday&quo= t;, or parents (or someone offering an "Internet for families" se= rvice) might set two firewall rules of the form "block all HTTP traffi= c except to www.wikipedia.com by d= efault" (so that the kids can use it to do their homework) and "a= llow all HTTP traffic between 6pm and 10pm weekdays and all day on weekends= " (so that the kids can surf the Internet freely in the evenings and o= n weekends). =A0

How would the time-of-day and day-of-week aspects of th= ose rules be expressed in YANG? =A0Don't forget daylight savings time c= hanges...

-Brent
--
Brent Chapman &l= t;brent@netomata.com>
Netomata, Inc. -- www.netomata.com<= br>Making networks more cost-effective, reliable, and flexible by automatin= g network configuration

--0016e6ddfff68684c9046faf86a9-- From andy@netconfcentral.com Mon Jul 27 06:47:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D41E3A6C98 for ; Mon, 27 Jul 2009 06:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 QoliDstGP7KO for ; Mon, 27 Jul 2009 06:47:23 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 965DC3A6C97 for ; Mon, 27 Jul 2009 06:47:23 -0700 (PDT) Received: (qmail 11543 invoked from network); 27 Jul 2009 13:47:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 27 Jul 2009 13:47:20 -0000 X-YMail-OSG: D4oi68sVM1kDnlYSalZJNZL4J1WbK0aNwT4d3PdPGZ64lTBQNM5tViK7OtrUHxlPphKdz20Vh3fpC_zJSuUNlvvL.pFz2fU37wGD6iuTwsn2mrmb1A0bT3TDK_dTg8YYKtqkzdfbM6I8Cd2.SoPYPTH0t7_ORzxxHYO20cCF2LULXrouO04YCZUSMHF8QcFZFdsNS_6peVp4UXguXqPf1.f9xOOVpOra1231NXSUGY7mZcx6fsI.rWnElEYbXxz0Ht9yoyVlwKGdGOrF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6DB01D.6060506@netconfcentral.com> Date: Mon, 27 Jul 2009 06:48:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 13:47:24 -0000 Hi, I am conflicted regarding Phil's proposal about 'dead nodes in an XPath expression are errors'. When coding this (yangdump has 4 or 5 warnings just on this 1 topic), I thought "gee this is stupid, but that's what XPath says to do, and YANG says I MUST support valid XPath". But these need to be warnings, not errors. First, when analyzing the object tree to generate warnings about what will happen at run-time, any expression with positional axes, or certain function calls or wildcard combos, can fool the compiler. preceding-sibling::*[3][some-child='fred'] Is there a 'some-child' node in the data tree? Maybe. (Do you have any idea how hard it would be for the XPath 'parse_predicate' code to get this right every time? And what about all the preceding siblings that don't have a 'some-child' leaf? They are intended as 'no-match', not an error at all.) There is also the 'some minus child' arithmetic expression that will trip up the compiler in this example. Then there is the problem of intended usage within YANG. must "NOT_YET"; // obviously a bug when "NOT_YET"; // not a bug Checking for expressions that always yield a constant result is tricky (true or false, doesn't matter, both are bugs). The easy ones are not likely to ever show up (must "3 > 4";) Summary: pay attention to warnings when you are debugging, or you deserve what you get. Andy From j.schoenwaelder@jacobs-university.de Mon Jul 27 07:15:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CC828C25A for ; Mon, 27 Jul 2009 07:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, 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 u1sExE384rV1 for ; Mon, 27 Jul 2009 07:15:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 07B043A69D5 for ; Mon, 27 Jul 2009 07:15:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00A91C0044; Mon, 27 Jul 2009 16:15:06 +0200 (CEST) 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 cjjow5epmjoq; Mon, 27 Jul 2009 16:15:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1DBBC0043; Mon, 27 Jul 2009 16:15:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 78D3BB6DA8E; Mon, 27 Jul 2009 16:15:04 +0200 (CEST) Date: Mon, 27 Jul 2009 16:15:04 +0200 From: Juergen Schoenwaelder To: Brent Chapman Message-ID: <20090727141504.GC10978@elstar.local> Mail-Followup-To: Brent Chapman , "netmod@ietf.org" References: <20090727120535.GA10672@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:15:13 -0000 On Mon, Jul 27, 2009 at 02:59:33PM +0200, Brent Chapman wrote: > A related issue... How do I specify times that are in the local > timezone, regardless of date? This is handled by following RFC 3339. In particular, the time-offset -00:00 indicates an unknown time zone. > And how do I specify day-of-week? Not with date-and-time. > For example, some firewalls enable you to configure rules to block > certain traffic during certain hours of the day, perhaps further > limited to certain days of the week. For instance, a business might > set a firewall rule of "block all HTTP traffic to > www.facebook.com between 8am and 5pm local > time, Monday through Friday", or parents (or someone offering an > "Internet for families" service) might set two firewall rules of the > form "block all HTTP traffic except to > www.wikipedia.com by default" (so that the > kids can use it to do their homework) and "allow all HTTP traffic > between 6pm and 10pm weekdays and all day on weekends" (so that the > kids can surf the Internet freely in the evenings and on weekends). > > How would the time-of-day and day-of-week aspects of those rules be > expressed in YANG? Don't forget daylight savings time changes... I agree that this will have to be sorted out sooner or later, but I am not sure it is critical to solve this to get YANG out of the door. The idea is to add types to the types document over time. In SNMP land, we have the DISMAN-SCHEDULE-MIB (RFC3231) and this document uses a collection of objects to do what I think you want. You want a data type with a single "atomic" representation, likely in a format that is similar to some cron formats. While surely interesting, I would not want to hold off the YANG work for this; I would be in favour adding it once we have a clear use case and a decent solution proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Jul 27 07:16:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D21C28C268 for ; Mon, 27 Jul 2009 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=0.600, 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 6U-j8O6RK2Tm for ; Mon, 27 Jul 2009 07:16:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 23BC028C25E for ; Mon, 27 Jul 2009 07:16:41 -0700 (PDT) Received: from [130.129.18.69] (dhcp-1245.meeting.ietf.org [130.129.18.69]) by office2.cesnet.cz (Postfix) with ESMTP id 3A463D800E8; Mon, 27 Jul 2009 16:16:39 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A6DB01D.6060506@netconfcentral.com> References: <4A6DB01D.6060506@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 27 Jul 2009 16:16:37 +0200 Message-Id: <1248704197.3795.62.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 14:16:42 -0000 Hi, I agree with Andy. In addition, from the viewpoint of XPath, (extended) names of nonexistent nodes are nothing illegal, they just select the empty set of nodes with all consequences on more complicated expressions, e.g. "count(foo:nonexistent)" returns zero. Lada Andy Bierman píše v Po 27. 07. 2009 v 06:48 -0700: > Hi, > > I am conflicted regarding Phil's proposal > about 'dead nodes in an XPath expression are errors'. > When coding this (yangdump has 4 or 5 warnings > just on this 1 topic), I thought "gee this is stupid, > but that's what XPath says to do, and YANG says I MUST > support valid XPath". > > But these need to be warnings, not errors. > > First, when analyzing the object tree to generate > warnings about what will happen at run-time, any expression > with positional axes, or certain function calls or wildcard combos, > can fool the compiler. > > preceding-sibling::*[3][some-child='fred'] > > Is there a 'some-child' node in the data tree? Maybe. > (Do you have any idea how hard it would be for the > XPath 'parse_predicate' code to get this right every time? > And what about all the preceding siblings that don't > have a 'some-child' leaf? They are intended as 'no-match', > not an error at all.) > > There is also the 'some minus child' arithmetic expression > that will trip up the compiler in this example. > > > Then there is the problem of intended usage within YANG. > > must "NOT_YET"; // obviously a bug > > when "NOT_YET"; // not a bug > > > Checking for expressions that always yield a constant result > is tricky (true or false, doesn't matter, both are bugs). > The easy ones are not likely to ever show up (must "3 > 4";) > > Summary: pay attention to warnings when you are debugging, > or you deserve what you get. > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Mon Jul 27 07:26:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E139428C1E4 for ; Mon, 27 Jul 2009 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=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 QX8fm7WWxQ2V for ; Mon, 27 Jul 2009 07:26:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 31C6428C242 for ; Mon, 27 Jul 2009 07:26:06 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6REQ0Lj020860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2009 16:26:01 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6REPwAH011192; Mon, 27 Jul 2009 16:26:00 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 16:25:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0EC6.28735BBD" Date: Mon, 27 Jul 2009 16:25:57 +0200 Message-ID: In-Reply-To: <4A685D08.7060808@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoLlKeNKTIlaUP7T/OOj69D0qRcdQDL4hiA References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com><4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com><1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com><1248345037.4674.64.camel@missotis> <4A685D08.7060808@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , X-OriginalArrivalTime: 27 Jul 2009 14:25:58.0454 (UTC) FILETIME=[28D06560:01CA0EC6] Subject: Re: [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt 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: , X-List-Received-Date: Mon, 27 Jul 2009 14:26:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0EC6.28735BBD Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Hi Andy, I think this wouldn't be sufficient as the example does not=20 address derived types and using a type in different places=20 in the node tree. We need to discuss this in detail in the session on Wednesday. BTW: We noted RPCs and invocations as open issue in the draft. Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Thursday, July 23, 2009 2:52 PM > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] FW:=20 > I-DAction:draft-linowski-netmod-yang-abstract-00.txt >=20 > Ladislav Lhotka wrote: > > Balazs Lengyel p=ED=B9e v =C8t 23. 07. 2009 v 09:56 +0200: > >> Hello, > >> The two main points I am missing are > >> - actions/rpcs in groupings/lists > >=20 > > Hmm, do you mean something like methods? Bernd & Mehmet's=20 > draft does not > > propose anything like this (yet) but IMO without support for late > > binding it is just unnecessary syntactic sugar. > >=20 > >> - type information on groupings/lists. Unless you do a=20 > deep analysis of the YAMs there is no=20 > >> way to find out that e.g. a leafref points at something=20 > derived from a grouping. > >=20 > > Validation including type checking is performed on instance XML > > documents where this information is not available anyway. An > > instance-identifier points to a concrete data node whose=20 > presence can be > > directly checked for. Everything else is quite complicated=20 > - how would > > you specify an XPath expression pointing to a complex type=20 > that has no > > corresponding node in the data tree? > >=20 > > YANG is much closer to an XML schema language than to a programming > > language and I think it should stay this way. > >=20 >=20 > Yes -- I know the IETF does not work on APIs, > but this seems like a problem for the code generators to solve. >=20 > It there was some sort of class hierarchy (from NETCONF=20 > session to content) >=20 > myitf =3D session.interfaces.interface.get_config(name=3D'eth0'); >=20 > status =3D session.interfaces.interface.reset(name=3D'eth0'); >=20 > Extensions could be used to declare a method. > Access control and normal processing > give the illusion the rpc is coupled to the data. >=20 >=20 > module interfaces { >=20 > rpc reset { > x:method /interfaces/interface; > input { > leaf name { ... } > } > } >=20 > container interfaces { > list interface { ... } > } >=20 > } >=20 > then would this be good enough? > Could something like this be standardized at all? >=20 > (I know the callingPoint mechanism is similar, > but not quite the same as this 'method' extension.) >=20 >=20 >=20 > > Lada > >=20 >=20 > Andy >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 ------_=_NextPart_001_01CA0EC6.28735BBD Content-Type: text/html; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable RE: [netmod] FW: = I-DAction:draft-linowski-netmod-yang-abstract-00.txt

Hi = Andy,

I think this = wouldn't be sufficient as the example does not
address derived = types and using a type in different places
in the node = tree.

We need to discuss = this in detail in the session on Wednesday.

BTW: We noted RPCs = and invocations as open issue in the
draft.

Cheers,
Mehmet
 

> -----Original = Message-----
> From: = netmod-bounces@ietf.org
> = [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy = Bierman
> Sent: Thursday, = July 23, 2009 2:52 PM
> To: Ladislav = Lhotka
> Cc: = netmod@ietf.org
> Subject: Re: = [netmod] FW:
> = I-DAction:draft-linowski-netmod-yang-abstract-00.txt
>
> Ladislav Lhotka = wrote:
> > Balazs = Lengyel p=ED=B9e v =C8t 23. 07. 2009 v 09:56 +0200:
> >> = Hello,
> >> The = two main points I am missing are
> >> - = actions/rpcs in groupings/lists
> > =
> > Hmm, do = you mean something like methods? Bernd & Mehmet's
> draft does = not
> > propose = anything like this (yet) but IMO without support for late
> > binding it = is just unnecessary syntactic sugar.
> > =
> >> - type = information on groupings/lists. Unless you do a
> deep analysis = of the YAMs there is no
> >> way to = find out that e.g. a leafref points at something
> derived from a = grouping.
> > =
> > Validation = including type checking is performed on instance XML
> > documents = where this information is not available anyway. An
> > = instance-identifier points to a concrete data node whose
> presence can = be
> > directly = checked for. Everything else is quite complicated
> - how = would
> > you = specify an XPath expression pointing to a complex type
> that has = no
> > = corresponding node in the data tree?
> > =
> > YANG is = much closer to an XML schema language than to a = programming
> > language = and I think it should stay this way.
> > =
>
> Yes -- I know = the IETF does not work on APIs,
> but this seems = like a problem for the code generators to solve.
>
> It there was = some sort of class hierarchy (from NETCONF
> session to = content)
>
>    myitf =3D = session.interfaces.interface.get_config(name=3D'eth0');
>
>    status =3D = session.interfaces.interface.reset(name=3D'eth0');
>
> Extensions = could be used to declare a method.
> Access control = and normal <rpc> processing
> give the = illusion the rpc is coupled to the data.
>
>
> module = interfaces {
>
>   rpc = reset {
>      x:method = /interfaces/interface;
>      input {
>         leaf = name { ... }
>      }
>   = }
>
>   = container interfaces {
>      list interface { ... = }
>   = }
>
> }
>
> then would this = be good enough?
> Could something = like this be standardized at all?
>
> (I know the = callingPoint mechanism is similar,
> but not quite = the same as this 'method' extension.)
>
>
>
> > = Lada
> > =
>
> = Andy
>
>
> = _______________________________________________
> netmod mailing = list
> = netmod@ietf.org
> = https://www.ietf.org/mailman/listinfo/netmod
>

------_=_NextPart_001_01CA0EC6.28735BBD-- From phil@juniper.net Mon Jul 27 09:45:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D5A28C1F6 for ; Mon, 27 Jul 2009 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 mhdcdlGZJSzT for ; Mon, 27 Jul 2009 09:45:32 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id A2C0E3A6AD5 for ; Mon, 27 Jul 2009 09:45:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSm3ZqxWey5C0onIsmfXQHPqOV3qGeN33@postini.com; Mon, 27 Jul 2009 09:45:33 PDT 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.375.2; Mon, 27 Jul 2009 09:41:32 -0700 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, 27 Jul 2009 09:41:32 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:41:32 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:41:31 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6RGfUd99054; Mon, 27 Jul 2009 09:41:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6RGU3Wb018772; Mon, 27 Jul 2009 16:30:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907271630.n6RGU3Wb018772@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6DB01D.6060506@netconfcentral.com> Date: Mon, 27 Jul 2009 12:30:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Jul 2009 16:41:31.0566 (UTC) FILETIME=[1886CCE0:01CA0ED9] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 16:45:32 -0000 Andy Bierman writes: >But these need to be warnings, not errors. Not true. We can say "XPath expressions should not refer to nodes that are not defined in the module". This makes "../foo" an error if "foo" is not defined. More complex expression may be tricky, but the tool can know that when it finds them, they are an error. Otherwise "../Interface" (instead of "interface") or "../../time-frame" instead of "TimeFrame" will not be a compile error, since it's perfectly valid. Many typos will be published in RFCs if they aren't detected. > must "NOT_YET"; // obviously a bug > when "NOT_YET"; // not a bug must 1 ; when 0; >Summary: pay attention to warnings when you are debugging, >or you deserve what you get. Um, I'm a -Werror addict, since I despise errors, but I think that's rare. The vast majority of programmers happily ignore warnings, allowing them to pile up until the warnings caused by new code changes are lost in the noise of the old warnings. Garbage in, garbage out. So why allow garbage? Thanks, Phil From andy@netconfcentral.com Mon Jul 27 10:29:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CA03A6CA9 for ; Mon, 27 Jul 2009 10:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 y-q2ZRlWdapj for ; Mon, 27 Jul 2009 10:29:48 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 21CF63A6B54 for ; Mon, 27 Jul 2009 10:29:48 -0700 (PDT) Received: from [68.142.194.243] by n18.bullet.mail.mud.yahoo.com with NNFMP; 27 Jul 2009 17:29:12 -0000 Received: from [68.142.201.249] by t1.bullet.mud.yahoo.com with NNFMP; 27 Jul 2009 17:29:12 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 27 Jul 2009 17:29:12 -0000 X-Yahoo-Newman-Id: 395757.66576.bm@omp410.mail.mud.yahoo.com Received: (qmail 93560 invoked from network); 27 Jul 2009 17:29:11 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 27 Jul 2009 17:29:11 -0000 X-YMail-OSG: xgG0LfUVM1l1Vxzjgr4mCZvIdS.2E9nyKe1p9j0P62Ehztcds1jS84TpxQ2oQzTgGAarF9MDcwg0r2PXP1BJEUdrojmrOIcO3svT6RXbM1pWino8bELXjxcsXsQva1poiosX.ZCEhJR8nuQTvsQ1_p09K1VPs2Ea0OaOwwF3l8sqRB4QKYnn3I8i7PRv8mBcMLNHizitPkfbllRawi6RrEyCyQ9h52AgtbEPNpITQTiLEQkl.d8h5r7IZt0nNGtCn7Y6qkR_sm0KIvPV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6DE41E.705@netconfcentral.com> Date: Mon, 27 Jul 2009 10:30:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907271630.n6RGU3Wb018772@idle.juniper.net> In-Reply-To: <200907271630.n6RGU3Wb018772@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 17:29:49 -0000 Phil Shafer wrote: > Andy Bierman writes: >> But these need to be warnings, not errors. > > Not true. We can say "XPath expressions should not refer to > nodes that are not defined in the module". This makes "../foo" > an error if "foo" is not defined. More complex expression may > be tricky, but the tool can know that when it finds them, they > are an error. Otherwise "../Interface" (instead of "interface") > or "../../time-frame" instead of "TimeFrame" will not be a > compile error, since it's perfectly valid. > > Many typos will be published in RFCs if they aren't detected. > This assumes that the WG members will not be able to review the YANG module and find the problems. If that is the case, then XPath is too hard to use and it needs to be tossed out of YANG completely. But I think it will be OK, because YANG authors who don't know XPath will avoid must/when statements completely. They will write description statements instead, just like in SMIv2. >> must "NOT_YET"; // obviously a bug >> when "NOT_YET"; // not a bug > > must 1 ; when 0; > both expressions evaluate to the same thing -- undefined element, but in a 'when' expression, this might be the intent. >> Summary: pay attention to warnings when you are debugging, >> or you deserve what you get. > > Um, I'm a -Werror addict, since I despise errors, but I think > that's rare. The vast majority of programmers happily ignore > warnings, allowing them to pile up until the warnings caused > by new code changes are lost in the noise of the old warnings. > > Garbage in, garbage out. So why allow garbage? > > Thanks, > Phil > Andy From phil@juniper.net Mon Jul 27 10:54:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C043A6AF9 for ; Mon, 27 Jul 2009 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 a2SRc1mT5o0l for ; Mon, 27 Jul 2009 10:54:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id E87053A67A7 for ; Mon, 27 Jul 2009 10:54:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSm3pfJxe9/SQ6KBz5YnehvascjTKKPOn@postini.com; Mon, 27 Jul 2009 10:54:31 PDT 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.375.2; Mon, 27 Jul 2009 10:48:00 -0700 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, 27 Jul 2009 10:48:00 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 10:48:00 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jul 2009 10:47:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6RHlwd35686; Mon, 27 Jul 2009 10:47:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6RHaVEH019666; Mon, 27 Jul 2009 17:36:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907271736.n6RHaVEH019666@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6DE41E.705@netconfcentral.com> Date: Mon, 27 Jul 2009 13:36:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Jul 2009 17:47:59.0448 (UTC) FILETIME=[617D4D80:01CA0EE2] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 17:54:30 -0000 Andy Bierman writes: >This assumes that the WG members will not be >able to review the YANG module and find the >problems. Are you assuming reviewers will catch every mistake? >> must 1 ; when 0; >both expressions evaluate to the same thing -- undefined element, >but in a 'when' expression, this might be the intent. 1 and 0 are numbers. Thanks, Phil From andy@netconfcentral.com Mon Jul 27 11:16:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EA23A6CE2 for ; Mon, 27 Jul 2009 11:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 L-XmSk4kld1r for ; Mon, 27 Jul 2009 11:16:00 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 70ED93A6CB8 for ; Mon, 27 Jul 2009 11:16:00 -0700 (PDT) Received: (qmail 10089 invoked from network); 27 Jul 2009 18:15:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 27 Jul 2009 18:15:04 -0000 X-YMail-OSG: uy1MUSgVM1kLQPQC9u75fVCoY6f5E0Ic32u3_DOhRwXhQCtKGXqBjTepFX4XG0Qm7s__PJNb3wZG7coHqkp4aMe0WjqiVq40tLFk3EjVp7qfjMiqIZe1nTWnXBznJvBPCO3e_V3tIbf1eryW64HWwDa2hLc8bto6EljD_LTcbpqITFqqkra9i5I_8RPVEE3GqFOmDbT9WQ8iH.vN7gAeWAgsS4isWdM7l8IQXSww3W5p8OQ5D2c28VmclBmYKcTNRGaTE9iXfaAf.YJp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6DEEDF.9040909@netconfcentral.com> Date: Mon, 27 Jul 2009 11:15:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907271736.n6RHaVEH019666@idle.juniper.net> In-Reply-To: <200907271736.n6RHaVEH019666@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 18:16:01 -0000 Phil Shafer wrote: > Andy Bierman writes: >> This assumes that the WG members will not be >> able to review the YANG module and find the >> problems. > > Are you assuming reviewers will catch every mistake? > No better or worse than any other IETF document >>> must 1 ; when 0; >> both expressions evaluate to the same thing -- undefined element, >> but in a 'when' expression, this might be the intent. > > 1 and 0 are numbers. > yes, but not sure what this has to do with the issue I raised about requiring the XPath parser to treat when and must expressions differently. > Thanks, > Phil > Andy From andy@netconfcentral.com Mon Jul 27 16:25:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE09E3A695A for ; Mon, 27 Jul 2009 16:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 fYoyWTJs2toU for ; Mon, 27 Jul 2009 16:25:51 -0700 (PDT) Received: from n16a.bullet.mail.mud.yahoo.com (n16a.bullet.mail.mud.yahoo.com [68.142.207.126]) by core3.amsl.com (Postfix) with SMTP id BC6073A6809 for ; Mon, 27 Jul 2009 16:25:51 -0700 (PDT) Received: from [68.142.200.226] by n16.bullet.mail.mud.yahoo.com with NNFMP; 27 Jul 2009 23:25:53 -0000 Received: from [68.142.201.245] by t7.bullet.mud.yahoo.com with NNFMP; 27 Jul 2009 23:25:53 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 27 Jul 2009 23:25:53 -0000 X-Yahoo-Newman-Id: 241383.42504.bm@omp406.mail.mud.yahoo.com Received: (qmail 65339 invoked from network); 27 Jul 2009 23:25:52 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 27 Jul 2009 23:25:52 -0000 X-YMail-OSG: JHMTixkVM1kbMZzEVZlbKkYErEWV_0gt8nNtyWLlyXoF6WCouztfVsiBJC8r5nHjvbK89.T5Rnm57oUfN51W0.GBqwl32UFZVmLkr9Enk7T9xtAgSZC.zTO32KL3WLTlO2vWToYNLV7zVQsLILkrj6kS2Y1U6.bxmx3ROwJW_UIHYGc18hkUzAw0FkoGRaKr28afvDOTmYo0Xp8yew8R7s7j6035ARUOq.AY2V5Lp11LZt4L7hlxPVOXSFsWSX5LuBINziStK1weLMZ7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6E373F.8030905@netconfcentral.com> Date: Mon, 27 Jul 2009 16:24:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907271736.n6RHaVEH019666@idle.juniper.net> In-Reply-To: <200907271736.n6RHaVEH019666@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Mon, 27 Jul 2009 23:25:55 -0000 Phil Shafer wrote: > Andy Bierman writes: >> This assumes that the WG members will not be >> able to review the YANG module and find the >> problems. > > Are you assuming reviewers will catch every mistake? I am not assuming a compiler can always tell that certain valid XPath is OK sometimes, and other times not. I think must and when statement usage will be problematic, but could also enable a lot of automatic code generation as well. Don't ignore compiler warnings, and use the power saw carefully. I think yangdump and pyang will support an "IETF review" mode, and garbage XPath will certainly be elevated to an error in this mode. But I do not want to put any rules in YANG about what is and is not garbage XPath. YANG compilers MUST report invalid XPath usage (e.g., "x and and y"). They SHOULD report warnings for expressions which may produce constant (or empty) results at run-time. > >>> must 1 ; when 0; >> both expressions evaluate to the same thing -- undefined element, >> but in a 'when' expression, this might be the intent. > > 1 and 0 are numbers. > > Thanks, > Phil > Andy From phil@juniper.net Tue Jul 28 01:12:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79E03A6D49 for ; Tue, 28 Jul 2009 01:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 K66GPn2Anak2 for ; Tue, 28 Jul 2009 01:12:51 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id F317D3A6D45 for ; Tue, 28 Jul 2009 01:12:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSm6zBOXHiXP8VDMUA/qh0wLprFv0/mR/@postini.com; Tue, 28 Jul 2009 01:12:53 PDT 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.375.2; Tue, 28 Jul 2009 01:06:58 -0700 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, 28 Jul 2009 01:06:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 01:06:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jul 2009 01:06:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6S86ud59652; Tue, 28 Jul 2009 01:06:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6S7tSOF024791; Tue, 28 Jul 2009 07:55:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907280755.n6S7tSOF024791@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6E373F.8030905@netconfcentral.com> Date: Tue, 28 Jul 2009 03:55:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Jul 2009 08:06:57.0191 (UTC) FILETIME=[6060CB70:01CA0F5A] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Tue, 28 Jul 2009 08:12:53 -0000 Andy Bierman writes: >Don't ignore compiler warnings, and use the power saw carefully. >I think yangdump and pyang will support an "IETF review" mode, >and garbage XPath will certainly be elevated to an error in this mode. I don't really understand this stance. You are saying that generic YANG should be fine with references to undefined elements, but that ietf mode will make this an error. If the goal is to make it an error, why not simply declare from the start that references to undefined elements are illegal. Consider: - the cost of allowing such simple, completely preventable errors - the benefit of detecting errors as early as possible - every YANG module author will not be a YANG expert - rfc reviewers don't catch errors (consider 4741 as proof ;^) I don't understand why this is a hangup. You are already saying that tools need to support detecting this (for your ietf mode), so there's no win in calling it legal YANG. It will just be a source of errors for our fledgling langauge. Thanks, Phil From j.schoenwaelder@jacobs-university.de Tue Jul 28 01:38:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDE93A6DD1 for ; Tue, 28 Jul 2009 01:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 jyf0rhxd-ydy for ; Tue, 28 Jul 2009 01:38:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5CBBF3A6DCF for ; Tue, 28 Jul 2009 01:38:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 348CFC0071; Tue, 28 Jul 2009 10:38:22 +0200 (CEST) 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 qwzntZgqJ23m; Tue, 28 Jul 2009 10:38:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32C6CC0070; Tue, 28 Jul 2009 10:38:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F6ECB6E7BC; Tue, 28 Jul 2009 10:38:21 +0200 (CEST) Date: Tue, 28 Jul 2009 10:38:21 +0200 From: Juergen Schoenwaelder To: Brent Chapman Message-ID: <20090728083821.GB11743@elstar.local> Mail-Followup-To: Brent Chapman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] How to represent durations? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:38:22 -0000 On Mon, Jul 27, 2009 at 01:38:09PM +0200, Brent Chapman wrote: > My apologies for coming late to the discussion, but how do you > represent durations (i.e, "30 seconds", "60 minutes", "20 > milli-seconds") in NETMOD? > For instance, if I'm setting up an ARP cache expiration policy for a > particular device, I might want to set it to "10 minutes". If I'm > setting a VRRP failover policy, I might want to say "30 seconds". > If I want to set a jitter limit parameter on a VOIP link, I might > want to express it in milli-seconds. XML schema supports a duration type that has been modelled after some ISO standard. I can express durations counted in years all the way down to seconds. This is how a generic type could look like (although the XSD type falls short on milli-second or micro-second resolutions). The way we have dealt with this in the past in most MIB modules is to have data model specific numbers where the data modeler at modeling time defines the resolution, e.g. defining a leaf with a protocol timeout expressed in milli-seconds. Speaking as a document editor, I do not know how a good duration type looks like (I believe the XSD type is not very useable for us) and so either someone makes a good concrete proposal now or we should leave out a generic duration type and leave this for a future revision of this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Jul 28 01:39:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EB93A6DC1 for ; Tue, 28 Jul 2009 01:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 DaBUgI4BS5gC for ; Tue, 28 Jul 2009 01:39:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 549673A6D76 for ; Tue, 28 Jul 2009 01:39:07 -0700 (PDT) Received: from [10.43.1.24] (unknown [77.241.97.148]) by office2.cesnet.cz (Postfix) with ESMTP id BD079D800C8; Tue, 28 Jul 2009 10:39:06 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A6E373F.8030905@netconfcentral.com> References: <200907271736.n6RHaVEH019666@idle.juniper.net> <4A6E373F.8030905@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 28 Jul 2009 10:39:02 +0200 Message-Id: <1248770342.5787.15.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Tue, 28 Jul 2009 08:39:26 -0000 Hi, the upcoming XSD Schema 1.1 introduces asserts which serve pretty much the same purpose as 'must' in YANG. They use XPath 2.0 but have the following limitations: - no access outside the subtree where the assert appears - they are not schema-aware (which is the topic of this thread) I don't know the reasons behind these limitations but at least they indicate something. Lada Andy Bierman píše v Po 27. 07. 2009 v 16:24 -0700: > Phil Shafer wrote: > > Andy Bierman writes: > >> This assumes that the WG members will not be > >> able to review the YANG module and find the > >> problems. > > > > Are you assuming reviewers will catch every mistake? > > I am not assuming a compiler can always tell that > certain valid XPath is OK sometimes, and other times not. > > I think must and when statement usage will be problematic, > but could also enable a lot of automatic code generation as well. > Don't ignore compiler warnings, and use the power saw carefully. > > I think yangdump and pyang will support an "IETF review" mode, > and garbage XPath will certainly be elevated to an error in this mode. > > But I do not want to put any rules in YANG about what is > and is not garbage XPath. YANG compilers MUST report invalid > XPath usage (e.g., "x and and y"). They SHOULD report warnings > for expressions which may produce constant (or empty) results at run-time. > > > > > >>> must 1 ; when 0; > >> both expressions evaluate to the same thing -- undefined element, > >> but in a 'when' expression, this might be the intent. > > > > 1 and 0 are numbers. > > > > Thanks, > > Phil > > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Jul 28 01:49:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794473A6AF4 for ; Tue, 28 Jul 2009 01:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, GB_I_LETTER=-2, 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 KIjb23moMz53 for ; Tue, 28 Jul 2009 01:49:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DA68B3A690D for ; Tue, 28 Jul 2009 01:48:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE81FC0054 for ; Tue, 28 Jul 2009 10:48:44 +0200 (CEST) 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 878UfFRG4fbu; Tue, 28 Jul 2009 10:48:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C88DDC004F; Tue, 28 Jul 2009 10:48:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C28A8B6E84B; Tue, 28 Jul 2009 10:48:43 +0200 (CEST) Date: Tue, 28 Jul 2009 10:48:43 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090728084843.GC11743@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20090727120535.GA10672@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090727120535.GA10672@elstar.local> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [netmod] data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:49:03 -0000 On Mon, Jul 27, 2009 at 02:05:35PM +0200, Juergen Schoenwaelder wrote: > Hi, > > during the WG meeting, the date-and-time canonicalization rules > came up and it was not clear whether the text forces all canonical > date-and-time values to be in UTC. Here is the relevant text: > > The canonical format for date-and-time values mandates the UTC > time format with the time-offset is indicated by the letter "Z". > This is consistent with the canonical format used by the > dateTime XML schema type. > > Since YANG requires to send data in canonical format (section 9.1 of > the YANG document), this essentially means date-and-time values are > pretty much always in UTC when you get them from a device. This is > likely not what operationally is always wanted. > > If we allow non UTC time zones, then of course we allow for multiple > different representations for the same value. According to section 9.1 > of the YANG document, this is actually allowed. Should date-and-time > make use of this special rule? Let me try to add an example. Currently, the specs say that it is fine to send 2009-07-28T10:40:46+02:00 to a NETCONF server but the server has to return the date as 2009-07-28T08:40:46Z and it might be that this behaviour is surprising to some NETCONF users. On the other hand, this canonicalization makes it easier to compare the textual representation of values since you do not have to do time zone delta calculations. If we change rules, then we might want to require that the server returns the data in exactly the format it was entered into the configuration. But this of course requires that implementations maintain information about the format that was used next to the value itself and a device may generate date-and-time values in different leafs that look different but are actualy the same. Since I am scheduled to discuss this again tomorrow, it would really help to have some discussion here on the list where the whole WG can easily participate. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jul 28 01:54:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308C13A6D37 for ; Tue, 28 Jul 2009 01:54:06 -0700 (PDT) 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.055, 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 nKW0q2Ddzipu for ; Tue, 28 Jul 2009 01:54:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B72763A6CE6 for ; Tue, 28 Jul 2009 01:53:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1AA5C0070 for ; Tue, 28 Jul 2009 10:53:51 +0200 (CEST) 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 V8b0XPwDeB0G; Tue, 28 Jul 2009 10:53:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3281C004F; Tue, 28 Jul 2009 10:53:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DDA21B6E8BD; Tue, 28 Jul 2009 10:53:50 +0200 (CEST) Date: Tue, 28 Jul 2009 10:53:50 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090728085350.GA11803@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] yang types wg discussion results X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:54:06 -0000 Hi, as far as I recall, the outcome of the yang types discussion in Stockholm is the following: - we add a data type (date-and-time without time) - we remove the XSD/RNG appendixes - we need to discuss the timezone normalization of date-and-time Am I missing something? Those who did not attend the meeting, please air any concerns now. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Jul 28 02:31:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496243A6D27 for ; Tue, 28 Jul 2009 02:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.300, 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 rNscGiHjp+nd for ; Tue, 28 Jul 2009 02:31:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2687A3A6E98 for ; Tue, 28 Jul 2009 02:31:10 -0700 (PDT) Received: from [130.129.20.168] (dhcp-14a8.meeting.ietf.org [130.129.20.168]) by office2.cesnet.cz (Postfix) with ESMTP id D1E97D800C8 for ; Tue, 28 Jul 2009 11:30:30 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Tue, 28 Jul 2009 11:30:25 +0200 Message-Id: <1248773425.7144.23.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] more XPath fun 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: , X-List-Received-Date: Tue, 28 Jul 2009 09:31:11 -0000 Hi, yang-usage draft says this: "..., the 'preceding', 'preceding-sibling', 'following', and 'following-sibling' axis SHOULD NOT be used. These constructs rely on XML document order within a NETCONF agent configuration database, which may not be supported consistently or produce reliable results across implementations." I don't agree with this, here are two examples where these axes are useful and maybe indispensable: 1. Global uniqueness: grouping id { leaf id { type string; must "not(.=preceding::id)"; } } This grouping can be used to place an id anywhere in the schema and the 'must' constraint guarantees their uniqueness. 2. Lists ordered-by user: 'must' statement may be used to specify some constraints on the order. For example, this guarantees that IPv4 clients appear before IPv6 ones: list client { must "not(preceding-sibling::client/version > version)"; leaf version { type inet:ip-version; } } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Jul 28 02:31:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB253A6E8B for ; Tue, 28 Jul 2009 02:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 6+0uDocvBaKZ for ; Tue, 28 Jul 2009 02:31:24 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 3A4CF3A6CEF for ; Tue, 28 Jul 2009 02:31:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSm7FMpf8rqxlOPnpVRUIJ4r3hU5Ttqha@postini.com; Tue, 28 Jul 2009 02:31:23 PDT 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.375.2; Tue, 28 Jul 2009 02:26:59 -0700 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, 28 Jul 2009 02:26:59 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 02:26:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jul 2009 02:26:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6S9Qvd93666; Tue, 28 Jul 2009 02:26:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6S9FTvN025817; Tue, 28 Jul 2009 09:15:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907280915.n6S9FTvN025817@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090728084843.GC11743@elstar.local> Date: Tue, 28 Jul 2009 05:15:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Jul 2009 09:26:57.0632 (UTC) FILETIME=[8DA9F600:01CA0F65] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] data-and-time canonicalization 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: , X-List-Received-Date: Tue, 28 Jul 2009 09:31:24 -0000 Juergen Schoenwaelder writes: >If we change rules, then we might want to require that the server >returns the data in exactly the format it was entered into the >configuration. I'm less concerned with maintaining the exact text than I am about losing timezone information. Should we keep the canonicalization, but require the timezone (if any) be kept in the +hh:mm suffix? (And what about timezones that don't allow +hh:mm (suntime)?) Thanks, Phil From j.schoenwaelder@jacobs-university.de Tue Jul 28 03:24:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88F53A6C1B for ; Tue, 28 Jul 2009 03:24:22 -0700 (PDT) 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.052, 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 Q3rsCjwIP54a for ; Tue, 28 Jul 2009 03:24:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B357A3A6C07 for ; Tue, 28 Jul 2009 03:24:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1B74C004F; Tue, 28 Jul 2009 12:24:22 +0200 (CEST) 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 axYFgBNVELIz; Tue, 28 Jul 2009 12:24:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7CE7C0003; Tue, 28 Jul 2009 12:24:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CA6AEB6EA90; Tue, 28 Jul 2009 12:24:21 +0200 (CEST) Date: Tue, 28 Jul 2009 12:24:21 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090728102421.GA11915@elstar.local> Mail-Followup-To: Phil Shafer , "netmod@ietf.org" References: <20090728084843.GC11743@elstar.local> <200907280915.n6S9FTvN025817@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907280915.n6S9FTvN025817@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:24:22 -0000 On Tue, Jul 28, 2009 at 11:15:29AM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >If we change rules, then we might want to require that the server > >returns the data in exactly the format it was entered into the > >configuration. > > I'm less concerned with maintaining the exact text than I am about > losing timezone information. Should we keep the canonicalization, > but require the timezone (if any) be kept in the +hh:mm suffix? This is one option. The question then is of course which offset date-and-time values use that are generated locally. So there probably needs to be text that says a server should use the local timezone offset and fall back to UTC if that is available or just unknown timezone offset if the server really has no clue about timezone information. > (And what about timezones that don't allow +hh:mm (suntime)?) I think this is not really an issue; boxes can change their time zone. If you have daylight saving time, you essentially change periodically your timezone offset - in value space that is in UTC time nothing really happens. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.partain@ericsson.com Tue Jul 28 08:06:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4D13A68A5 for ; Tue, 28 Jul 2009 08:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_SE=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 WGXLORYGUF6p for ; Tue, 28 Jul 2009 08:06:31 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 58D923A6C74 for ; Tue, 28 Jul 2009 08:06:31 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-93-4a6f13f7947c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 02.8C.18827.7F31F6A4; Tue, 28 Jul 2009 17:06:31 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:06:31 +0200 Received: from [153.88.51.215] ([153.88.51.215]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:06:31 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Jul 2009 16:51:29 +0200 User-Agent: KMail/1.9.10 References: <200907271736.n6RHaVEH019666@idle.juniper.net> <4A6E373F.8030905@netconfcentral.com> <1248770342.5787.15.camel@nomad> In-Reply-To: <1248770342.5787.15.camel@nomad> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907281651.30179.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Jul 2009 15:06:31.0445 (UTC) FILETIME=[FD671C50:01CA0F94] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Tue, 28 Jul 2009 15:06:32 -0000 Hi all, This issue has generated a fair bit of discussion here at the IETF. =20 Essentially, the discussion has demonstrated clearly that there are pretty= =20 set stances in the working group. I, as technical contributor, agree with Phil that this garbage should be=20 thrown back in the face of the person who handed it to the compiler. However, I also see in the mail and in discussions that have been happening= in=20 Stockholm that there are several others who think the YANG specification=20 should not start down this path. If it's valid XPath, it's a YANG warning= =20 and not an error. Rather, it will be up to YANG compilers to deal with=20 garbage in XPath expressions if they choose to do so. That means that, while nonsense, the following would be considered "valid"= =20 (but stupid) YANG: module a { namespace =E2=80=9Chttp://example.com/a=E2=80=9D; prefix a; container foo { leaf a { type int32; must =E2=80=9C. < ../c=E2=80=9D; } leaf b { =E2=80=A6 } } } We will try to put this issue to bed tomorrow in the working group meeting. Cheers, David From david.partain@ericsson.com Tue Jul 28 08:06:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200343A700B for ; Tue, 28 Jul 2009 08:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.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 mg8rDoKRHUzE for ; Tue, 28 Jul 2009 08:06:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2F5033A68A5 for ; Tue, 28 Jul 2009 08:06:47 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-50-4a6f14075bde Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 99.1E.00514.7041F6A4; Tue, 28 Jul 2009 17:06:47 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:06:32 +0200 Received: from [153.88.51.215] ([153.88.51.215]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:06:31 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Tue, 28 Jul 2009 16:52:35 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200907281652.35229.david.partain@ericsson.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:06:31.0570 (UTC) FILETIME=[FD7A2F20:01CA0F94] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Types document: inclusion of date type 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: , X-List-Received-Date: Tue, 28 Jul 2009 15:06:48 -0000 Hi, A number of people have expressed concerns about including this new type after the meeting on Monday (where the rough consensus in the room was to include it). Because of this input, it would be very helpful if proponents of adding this type can provide use cases where this type would be useful. We'll have a brief discussion about this tomorrow in the WG meeting. Cheers, David From david.partain@ericsson.com Tue Jul 28 08:06:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD103A68A5 for ; Tue, 28 Jul 2009 08:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, 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 Hfqxi3YIa7Bt for ; Tue, 28 Jul 2009 08:06:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D70B63A6C74 for ; Tue, 28 Jul 2009 08:06:47 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-51-4a6f1407bc50 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C9.1E.00514.7041F6A4; Tue, 28 Jul 2009 17:06:47 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:06:32 +0200 Received: from [153.88.51.215] ([153.88.51.215]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:06:31 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Jul 2009 17:00:12 +0200 User-Agent: KMail/1.9.10 References: <200907280915.n6S9FTvN025817@idle.juniper.net> In-Reply-To: <200907280915.n6S9FTvN025817@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907281700.12270.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Jul 2009 15:06:31.0648 (UTC) FILETIME=[FD861600:01CA0F94] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] data-and-time canonicalization 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: , X-List-Received-Date: Tue, 28 Jul 2009 15:06:48 -0000 Hi all, Again, this is an issue that needs to be concluded. We will conclude this discussion tomorrow in the WG meeting if at all possible. Given the following choices: 1. keep UTC as canonical, meaning the server will always return UTC 2. make the server return whatever it received I believe from my conversations with several people here this week that we'll find that there are more people who will fall on the side of keeping UTC as the canonical form. In the end, we have to choose. We'll discuss this tomorrow. Thanks. David From j.schoenwaelder@jacobs-university.de Tue Jul 28 08:24:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530BB3A67FF for ; Tue, 28 Jul 2009 08:24:17 -0700 (PDT) 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.048, 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 JD3RplOi1lgn for ; Tue, 28 Jul 2009 08:24:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 116EF3A6FC7 for ; Tue, 28 Jul 2009 08:24:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7CB2C007B; Tue, 28 Jul 2009 17:24:16 +0200 (CEST) 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 JKh6zXa3i-xg; Tue, 28 Jul 2009 17:24:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4222C0078; Tue, 28 Jul 2009 17:24:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B4A5B6F339; Tue, 28 Jul 2009 17:24:15 +0200 (CEST) Date: Tue, 28 Jul 2009 17:24:14 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20090728152414.GA12351@elstar.local> Mail-Followup-To: David Partain , NETMOD Working Group References: <200907281652.35229.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907281652.35229.david.partain@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] Types document: inclusion of date type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:24:17 -0000 On Tue, Jul 28, 2009 at 04:52:35PM +0200, David Partain wrote: > A number of people have expressed concerns about including this new > type after the meeting on Monday (where the rough consensus in the > room was to include it). Because of this input, it would be very > helpful if proponents of adding this type can provide use cases > where this type would be useful. We'll have a brief discussion > about this tomorrow in the WG meeting. To add some more background from the discussion today: The use case question came up after investigating XSD compatibility; the XSD date type allows for an optional time zone qualifier. A date value without a time zone qualifier actually indicates a time interval of 48 hours while a date value with a time zone qualifier indicates a 24 hour time interval. Whether the difference matters depends on the use case (and if there is a time zone, we must not normalize the time zone away because that changes the 24 hour time interval expressed with a date value). The yang types document editor is not sure how to get this seemingly simple date type right - what I do understand now is that the simple format YYYY-MM-DD indicates a 48 hours time interval unless we attach additional rules (e.g. a date value is always in UTC - but that might be bad for some potential use cases of such a data type since the 24 hour intervals you can represent are somewhat restricted). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Tue Jul 28 08:47:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BA23A70C6 for ; Tue, 28 Jul 2009 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 9hlviskfn4zt for ; Tue, 28 Jul 2009 08:47:00 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 9C05D3A70BD for ; Tue, 28 Jul 2009 08:47:00 -0700 (PDT) Received: (qmail 97391 invoked from network); 28 Jul 2009 15:46:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 28 Jul 2009 15:46:58 -0000 X-YMail-OSG: pJi6AccVM1kckDjAadZERIH7C9tPYlbwNER8YbCkubGyzlOvWBMa3bw6iBtgovhpETID9vVSuYFb_zskh9bNULZuJVeHx3tJzL2G4F7pvV6VKXll04LRLADPdHM0dzx688VCIvIFt1uHLWlKtefQ9VbYvg1feSGkrAV5uruXzGnGKS_KN4NSfIRCVGYBE80etYfRd7pxqjW7sT.860eVHthFMECCVrng5TehVuWXbUD.Cr4Zjtli59S.226JXDwhOLtxqN4aF9chfHad X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6F1D3A.3020307@netconfcentral.com> Date: Tue, 28 Jul 2009 08:46:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: David Partain , NETMOD Working Group References: <200907281652.35229.david.partain@ericsson.com> <20090728152414.GA12351@elstar.local> In-Reply-To: <20090728152414.GA12351@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Types document: inclusion of date type 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: , X-List-Received-Date: Tue, 28 Jul 2009 15:47:01 -0000 Juergen Schoenwaelder wrote: > On Tue, Jul 28, 2009 at 04:52:35PM +0200, David Partain wrote: > >> A number of people have expressed concerns about including this new >> type after the meeting on Monday (where the rough consensus in the >> room was to include it). Because of this input, it would be very >> helpful if proponents of adding this type can provide use cases >> where this type would be useful. We'll have a brief discussion >> about this tomorrow in the WG meeting. > > To add some more background from the discussion today: > > The use case question came up after investigating XSD compatibility; > the XSD date type allows for an optional time zone qualifier. A date > value without a time zone qualifier actually indicates a time interval > of 48 hours while a date value with a time zone qualifier indicates a > 24 hour time interval. Whether the difference matters depends on the > use case (and if there is a time zone, we must not normalize the time > zone away because that changes the 24 hour time interval expressed > with a date value). > > The yang types document editor is not sure how to get this seemingly > simple date type right - what I do understand now is that the simple > format YYYY-MM-DD indicates a 48 hours time interval unless we attach > additional rules (e.g. a date value is always in UTC - but that might > be bad for some potential use cases of such a data type since the 24 > hour intervals you can represent are somewhat restricted). > It's OK with me to leave out this data type and let it be defined as needed in vendor or standard data models. > /js > Andy From brent@netomata.com Tue Jul 28 08:49:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA813A6DEE for ; Tue, 28 Jul 2009 08:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbJhZmWCkWug for ; Tue, 28 Jul 2009 08:49:07 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 702303A70A1 for ; Tue, 28 Jul 2009 08:49:02 -0700 (PDT) Received: by bwz21 with SMTP id 21so123187bwz.37 for ; Tue, 28 Jul 2009 08:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.71.82 with SMTP id g18mr4042767bkj.120.1248796140342; Tue, 28 Jul 2009 08:49:00 -0700 (PDT) In-Reply-To: <200907281652.35229.david.partain@ericsson.com> References: <200907281652.35229.david.partain@ericsson.com> Date: Tue, 28 Jul 2009 17:49:00 +0200 Message-ID: From: Brent Chapman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=00504502daac578eef046fc602f5 Subject: Re: [netmod] Types document: inclusion of date type 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: , X-List-Received-Date: Tue, 28 Jul 2009 15:49:08 -0000 --00504502daac578eef046fc602f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jul 28, 2009 at 4:52 PM, David Partain wrote: > Hi, > > A number of people have expressed concerns about including this new type > after > the meeting on Monday (where the rough consensus in the room was to include > it). Because of this input, it would be very helpful if proponents of > adding > this type can provide use cases where this type would be useful. We'll > have > a brief discussion about this tomorrow in the WG meeting. > How about SSL certificate management for load balancers, VPN concentrators, and the like, where particular certificates are valid only before or only after certain dates? I suppose that there's a time (midnight?) implicit in those certificate dates, so perhaps this is a less-than-ideal use case. -Brent -- Brent Chapman Netomata, Inc. -- www.netomata.com Making networks more cost-effective, reliable, and flexible by automating network configuration --00504502daac578eef046fc602f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 28, 2009 at 4:52 PM, David Partain <david.partain@ericsson.com><= /span> wrote:
Hi,

A number of people have expressed concerns about including this new type af= ter
the meeting on Monday (where the rough consensus in the room was to include=
it). =A0Because of this input, it would be very helpful if proponents of ad= ding
this type can provide use cases where this type would be useful. =A0We'= ll have
a brief discussion about this tomorrow in the WG meeting.

How about SSL certificate management for load= balancers, VPN concentrators, and the like, where particular certificates = are valid only before or only after certain dates? =A0I suppose that there&= #39;s a time (midnight?) implicit in those certificate dates, so perhaps th= is is a less-than-ideal use case.

brent@netomata.com>
Netomata, Inc. -- www.netomata.com<= br>Making networks more cost-effective, reliable, and flexible by automatin= g network configuration

--00504502daac578eef046fc602f5-- From balazs.lengyel@ericsson.com Tue Jul 28 09:03:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBDB3A70A5 for ; Tue, 28 Jul 2009 09:03:08 -0700 (PDT) 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 ift9BZCof+Yt for ; Tue, 28 Jul 2009 09:03:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9CAEB3A707A for ; Tue, 28 Jul 2009 09:02:50 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-8d-4a6f211d5cef Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 53.21.20893.D112F6A4; Tue, 28 Jul 2009 18:02:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 18:02:20 +0200 Received: from [127.0.0.1] ([10.42.207.84]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 18:02:19 +0200 Message-ID: <4A6F210F.3020109@ericsson.com> Date: Tue, 28 Jul 2009 18:02:23 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 16:02:19.0942 (UTC) FILETIME=[C9433460:01CA0F9C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Unique prefixes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:03:08 -0000 Hello, Prefixes are used widely in YANG. It would be a lot easier to read YANG Modules if they would all use unique prefixes and if the prefixes used in import, would be the same as in the imported module. If the prefixes used to point out a specific modules change in every other module, understanding the text becomes much more difficult. It would be quite difficult to have unique prefixes for all standard and non-standard modules, but at least standard YAMs should have a unique prefix. Add to 14. IANA Considerations The registry shall record for each entry: ... - for modules, the prefix defined in the module's prefix statement ... Add to 7.1.4. The prefix Statement Prefixes in YANG modules SHOULD be unique. Prefixes of standard YANG modules MUST be unique, this is guaranteed by registering the prefix value in the new "YANG Module Names" registry. The prefix statement in any import statements SHOULD use the same value as the imported modules prefix statement. The above was discussed by Martin, David Partain, Dave Kessens, Lada, Phil, Bernd, Jurgen, Mehmet and Balazs. The above text indicates their rough consensus. Balazs From balazs.lengyel@ericsson.com Tue Jul 28 09:03:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6973A7080 for ; Tue, 28 Jul 2009 09:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_SE=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 cPb6CzbRheHg for ; Tue, 28 Jul 2009 09:03:23 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1A7723A707E for ; Tue, 28 Jul 2009 09:03:22 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-c3-4a6f214ba662 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id CE.41.18827.B412F6A4; Tue, 28 Jul 2009 18:03:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 18:03:23 +0200 Received: from [127.0.0.1] ([10.42.207.84]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 18:03:22 +0200 Message-ID: <4A6F214F.4040808@ericsson.com> Date: Tue, 28 Jul 2009 18:03:27 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 16:03:22.0801 (UTC) FILETIME=[EEBABA10:01CA0F9C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Dont reuse list and container names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:03:24 -0000 Hello, YANG data modules will often be mapped to Java and C++ code and to other modeling languages, that use complex types and managed objects like 3GPP, SAF. Often these mappings will create a manage object or a class for each container and list. If the list names and container names are not unique the mapping will fail. Having unique names will also make YAMs easier to read. I propose to add to the Yang-Usage guidelines: "The common set of names of containers and lists in a YANG module and its submodules SHOULD only contain unique names." Balazs, From j.schoenwaelder@jacobs-university.de Tue Jul 28 09:22:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588913A70E2 for ; Tue, 28 Jul 2009 09:22:45 -0700 (PDT) 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.046, 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 25Z1Eu9uubd5 for ; Tue, 28 Jul 2009 09:22:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C485C3A6919 for ; Tue, 28 Jul 2009 09:22:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0B35C0055; Tue, 28 Jul 2009 18:22:44 +0200 (CEST) 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 puTyMGg6Sg7L; Tue, 28 Jul 2009 18:22:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD3EDC0052; Tue, 28 Jul 2009 18:22:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ACACFB6F585; Tue, 28 Jul 2009 18:22:43 +0200 (CEST) Date: Tue, 28 Jul 2009 18:22:43 +0200 From: Juergen Schoenwaelder To: Brent Chapman Message-ID: <20090728162243.GA12671@elstar.local> Mail-Followup-To: Brent Chapman , "netmod@ietf.org" References: <200907281652.35229.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Types document: inclusion of date type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:22:45 -0000 On Tue, Jul 28, 2009 at 05:49:00PM +0200, Brent Chapman wrote: > On Tue, Jul 28, 2009 at 4:52 PM, David Partain > wrote: > Hi, > > A number of people have expressed concerns about including this new type after > the meeting on Monday (where the rough consensus in the room was to include > it). Because of this input, it would be very helpful if proponents of adding > this type can provide use cases where this type would be useful. We'll have > a brief discussion about this tomorrow in the WG meeting. > > How about SSL certificate management for load balancers, VPN > concentrators, and the like, where particular certificates are valid > only before or only after certain dates? I suppose that there's a > time (midnight?) implicit in those certificate dates, so perhaps > this is a less-than-ideal use case. Once again, our principle has been to not define types because they _might_ be useful but to only include types where we are sure they _are_ useful in a number of YANG modules and where we know how to get the definition right so that the type works in a reusable way without surprises. We can add types incrementally - once we understand the requirements of concrete use cases. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jul 28 09:25:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11F23A69B7 for ; Tue, 28 Jul 2009 09:25:15 -0700 (PDT) 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.044, 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 fR+auIFAA1mJ for ; Tue, 28 Jul 2009 09:25:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ED8D23A67F2 for ; Tue, 28 Jul 2009 09:25:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E963C0055; Tue, 28 Jul 2009 18:25:13 +0200 (CEST) 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 Db0siCn81pry; Tue, 28 Jul 2009 18:25:12 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38FE7C0052; Tue, 28 Jul 2009 18:25:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F1EF5B6F5CD; Tue, 28 Jul 2009 18:25:11 +0200 (CEST) Date: Tue, 28 Jul 2009 18:25:11 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090728162511.GB12671@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <4A6F214F.4040808@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6F214F.4040808@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Dont reuse list and container names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:25:16 -0000 On Tue, Jul 28, 2009 at 06:03:27PM +0200, Balazs Lengyel wrote: > YANG data modules will often be mapped to Java and C++ code and to > other modeling languages, that use complex types and managed objects > like 3GPP, SAF. Often these mappings will create a manage object or > a class for each container and list. If the list names and container > names are not unique the mapping will fail. Having unique names will > also make YAMs easier to read. I propose to add to the Yang-Usage > guidelines: > > "The common set of names of containers and lists in a YANG module > and its submodules SHOULD only contain unique names." I disagree. Either they MUST be unique (I do not agree to this change at this point in time) or tools must be able to make identifiers unique when they create code. And from the SMIv2 experience, I know that languages really differ in their understanding of what an identifier is. Do not open that box. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jul 28 09:29:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6096D3A7113 for ; Tue, 28 Jul 2009 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rMTNZoQm+SGQ for ; Tue, 28 Jul 2009 09:29:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 318343A7044 for ; Tue, 28 Jul 2009 09:29:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F66FC0056; Tue, 28 Jul 2009 18:29:02 +0200 (CEST) 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 QXkOCJmWiBY0; Tue, 28 Jul 2009 18:29:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCE76C0052; Tue, 28 Jul 2009 18:29:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE029B6F614; Tue, 28 Jul 2009 18:29:01 +0200 (CEST) Date: Tue, 28 Jul 2009 18:29:01 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090728162901.GC12671@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <4A6F210F.3020109@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6F210F.3020109@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Unique prefixes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:29:07 -0000 On Tue, Jul 28, 2009 at 06:02:23PM +0200, Balazs Lengyel wrote: > Prefixes are used widely in YANG. It would be a lot easier to read > YANG Modules if they would all use unique prefixes and if the > prefixes used in import, would be the same as in the imported > module. > > If the prefixes used to point out a specific modules change in every > other module, understanding the text becomes much more difficult. > > It would be quite difficult to have unique prefixes for all standard > and non-standard modules, but at least standard YAMs should have a > unique prefix. Clarification: I think we talked about RFC published YANG modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Tue Jul 28 10:30:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324AC3A6E9C for ; Tue, 28 Jul 2009 10:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.294, 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 qfcHhMUUm8W9 for ; Tue, 28 Jul 2009 10:30:54 -0700 (PDT) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by core3.amsl.com (Postfix) with SMTP id 47C1E3A6892 for ; Tue, 28 Jul 2009 10:30:54 -0700 (PDT) Received: from [68.142.200.225] by n23.bullet.mail.mud.yahoo.com with NNFMP; 28 Jul 2009 17:29:40 -0000 Received: from [68.142.201.70] by t6.bullet.mud.yahoo.com with NNFMP; 28 Jul 2009 17:29:40 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 28 Jul 2009 17:29:40 -0000 X-Yahoo-Newman-Id: 889495.68013.bm@omp422.mail.mud.yahoo.com Received: (qmail 9730 invoked from network); 28 Jul 2009 17:29:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 28 Jul 2009 17:29:40 -0000 X-YMail-OSG: KJihwUEVM1kLEGTz1xZYID.xsRu1pSqJDTosrug93D1s4cWeWtlkcxm7j7SiuHBZZYq6_Iu6eyc0qgYbTe9zicnIZlJ1yLcshbK3lolFt_aSHD4IujKG9ZuHSfjXPuFW87vsC9AFcazuXj2xmeCHJdbUx_QMkIXlqf9uEu6Z1XRlG3ehm86rtatrlBO.mO5mzmxQOF1ccvfnjaIb8iJA8oygMgiIXGIFMZyJToJI3UWS6gTNFaeghI5O5eruwxdA.PMbPWAYq7aI954vyekr4qfN8ElD_K_oWB22E1IgkwgAIQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6F3547.80607@netconfcentral.com> Date: Tue, 28 Jul 2009 10:28:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: balazs.lengyel@ericsson.com References: <4A6F210F.3020109@ericsson.com> In-Reply-To: <4A6F210F.3020109@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Unique prefixes 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: , X-List-Received-Date: Tue, 28 Jul 2009 17:30:55 -0000 Lengyel wrote: > Hello, > Prefixes are used widely in YANG. It would be a lot easier to read YANG > Modules if they > would all use unique prefixes and if the prefixes used in import, would > be the same as in > the imported module. > > If the prefixes used to point out a specific modules change in every > other module, > understanding the text becomes much more difficult. > > It would be quite difficult to have unique prefixes for all standard and > non-standard > modules, but at least standard YAMs should have a unique prefix. > > I do not think we need prefix uniqueness. Unless every prefix string really is unique, then it does the manager no good, since it needs code to use an alternative, when a prefix collision comes up. We already have unique module names and (hopefully) namespace URIs. Use the module name in code generation, etc. because that is the only thing you can count on as being unique. It is impractical to maintain uniqueness among 2 and 3 character identifiers. Andy > > > > Add to 14. IANA Considerations > > The registry shall record for each entry: > ... > - for modules, the prefix defined in the module's prefix statement > ... > > Add to 7.1.4. The prefix Statement > Prefixes in YANG modules SHOULD be unique. Prefixes of standard YANG > modules MUST be > unique, this is guaranteed by registering the prefix value in the new > "YANG Module Names" > registry. > The prefix statement in any import statements SHOULD use the same value > as the imported > modules prefix statement. > > > The above was discussed by Martin, David Partain, Dave Kessens, Lada, > Phil, Bernd, Jurgen, > Mehmet and Balazs. The above text indicates their rough consensus. > > Balazs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Tue Jul 28 10:34:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE253A6F2D for ; Tue, 28 Jul 2009 10:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 lr3C1gtP7wvD for ; Tue, 28 Jul 2009 10:34:28 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id D7ED13A6F97 for ; Tue, 28 Jul 2009 10:34:16 -0700 (PDT) Received: from [68.142.200.226] by n13.bullet.mail.mud.yahoo.com with NNFMP; 28 Jul 2009 17:33:49 -0000 Received: from [68.142.201.71] by t7.bullet.mud.yahoo.com with NNFMP; 28 Jul 2009 17:33:49 -0000 Received: from [127.0.0.1] by omp423.mail.mud.yahoo.com with NNFMP; 28 Jul 2009 17:33:49 -0000 X-Yahoo-Newman-Id: 681499.16515.bm@omp423.mail.mud.yahoo.com Received: (qmail 70938 invoked from network); 28 Jul 2009 17:33:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 28 Jul 2009 17:33:49 -0000 X-YMail-OSG: Z8Pf2RgVM1n2GIwAs0In7pqkCRIAJRf_CnX0Te8uOCB1CsSn4BuDX.r2DOLk5FfBWwDwfj7RgHU7hpYHvNJ..q8Z.SFvynbvjl.QT03.dTD_XiVL_eEMjN4f67VtSqG04Ope1PHWoWLfnSvjUDw_N31B8zex9gc69.N8yQXCQn1PUnYFkTjIiCVMUm.uoH.co5GNav7XSoDp5XgDwTl1ECbQCqI9Tu0.lXG0awyQrqJ8nZm6LuqPBVDcps6sjH7_AH3p_jhCuYiFWvCIP.3yh51H5ESEbeQnVf3EzLgQvZ5Ia.4qZA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6F36BE.4090207@netconfcentral.com> Date: Tue, 28 Jul 2009 10:34:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: balazs.lengyel@ericsson.com References: <4A6F214F.4040808@ericsson.com> In-Reply-To: <4A6F214F.4040808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Dont reuse list and container names 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: , X-List-Received-Date: Tue, 28 Jul 2009 17:34:29 -0000 Balazs Lengyel wrote: > Hello, > YANG data modules will often be mapped to Java and C++ code and to other > modeling > languages, that use complex types and managed objects like 3GPP, SAF. > Often these > mappings will create a manage object or a class for each container and > list. If the list > names and container names are not unique the mapping will fail. Having > unique names will > also make YAMs easier to read. I propose to add to the Yang-Usage > guidelines: > > "The common set of names of containers and lists in a YANG module and > its submodules > SHOULD only contain unique names." > I do not agree with this. By definition, objects from groupings will have the same name. XML does not place any requirement on nested name uniqueness, just sibling name uniqueness. I think code generators need to deal with: - objects from uses-stmt (duplicates will come up) - the dash and dot chars are not allowed in identifiers within code. - YANG identifiers can be infinite length So name mangling is already mandatory for tools to implement. > Balazs, > Andy From lhotka@cesnet.cz Tue Jul 28 13:36:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7B83A6AA4 for ; Tue, 28 Jul 2009 13:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 7Lj-U3ZecCUl for ; Tue, 28 Jul 2009 13:36:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 70AF93A6907 for ; Tue, 28 Jul 2009 13:36:15 -0700 (PDT) Received: from [10.43.1.3] (unknown [77.241.97.148]) by office2.cesnet.cz (Postfix) with ESMTP id 55243D800C5 for ; Tue, 28 Jul 2009 22:36:13 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4A6F214F.4040808@ericsson.com> References: <4A6F214F.4040808@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 28 Jul 2009 22:36:04 +0200 Message-Id: <1248813364.18883.4.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Dont reuse list and container names 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: , X-List-Received-Date: Tue, 28 Jul 2009 20:36:16 -0000 Balazs Lengyel píše v Út 28. 07. 2009 v 18:03 +0200: > Hello, > YANG data modules will often be mapped to Java and C++ code and to other modeling > languages, that use complex types and managed objects like 3GPP, SAF. Often these > mappings will create a manage object or a class for each container and list. If the list > names and container names are not unique the mapping will fail. Having unique names will Then these mappings can mangle names to make them unique. DSDL mapping does this with names of groupings and types. Lada > also make YAMs easier to read. I propose to add to the Yang-Usage guidelines: > > "The common set of names of containers and lists in a YANG module and its submodules > SHOULD only contain unique names." > > Balazs, > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Jul 28 17:04:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BCE73A6C91 for ; Tue, 28 Jul 2009 17:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 Snl6IsCftIfS for ; Tue, 28 Jul 2009 17:04:05 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 9E8093A6E06 for ; Tue, 28 Jul 2009 17:03:37 -0700 (PDT) Received: (qmail 1756 invoked from network); 29 Jul 2009 00:03:37 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2009 00:03:37 -0000 X-YMail-OSG: 7B1V4soVM1n5j1zHoznzk4.cGX5hOg5AQVzYI42L3Stiz2BeR2lqK7KtJlUrEpC2v4hMh4.6zXRXbNn_XLRe6Vegrhrf6d4l5bYKcR_dISQEU5NuagBz5RWFdK0AsuAFFc04Vc58Gt3kTfJyGuSTZIJCf3y.A5ZoGk1yTggE0CWBy_EYkBVPAu6v6eqmM30z9PSu_oZz8OgW6goEV49fM42ICz0xJq7pfsL.uiIgRhcArtjrrNfZfb7Rwjs1QgRufOsPFc6owPHkuzbBYNlNB9sB.E5Rl3cQJtJiJ9_Yhm9t2YArCuSitrk4itAubMNsE4Xqu6ITiqOhd12lvLL7KA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6F91A2.5080109@netconfcentral.com> Date: Tue, 28 Jul 2009 17:02:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: David Partain References: <200907271736.n6RHaVEH019666@idle.juniper.net> <4A6E373F.8030905@netconfcentral.com> <1248770342.5787.15.camel@nomad> <200907281651.30179.david.partain@ericsson.com> In-Reply-To: <200907281651.30179.david.partain@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Wed, 29 Jul 2009 00:04:06 -0000 David Partain wrote: > Hi all, > > This issue has generated a fair bit of discussion here at the IETF. > Essentially, the discussion has demonstrated clearly that there are pretty > set stances in the working group. > > I, as technical contributor, agree with Phil that this garbage should be > thrown back in the face of the person who handed it to the compiler. > > However, I also see in the mail and in discussions that have been happening in > Stockholm that there are several others who think the YANG specification > should not start down this path. If it's valid XPath, it's a YANG warning > and not an error. Rather, it will be up to YANG compilers to deal with > garbage in XPath expressions if they choose to do so. > > That means that, while nonsense, the following would be considered "valid" > (but stupid) YANG: > > module a { > namespace “http://example.com/a”; > prefix a; > container foo { > leaf a { > type int32; > must “. < ../c”; > } > leaf b { … } > } > } > > We will try to put this issue to bed tomorrow in the working group meeting. > I changed my mind on this one. The issue is the usage of a complete QName within an absolute or relative path expression, without any wildcards or references to relative position of instances in the data tree. When a complete QName is specified (a specific local-name in a specific namespace), it MUST refer to an existing node in the schema tree. However, if any wildcards are present which make the exact location in the schema tree unknown or ambiguous, then the agent may not be able to detect these errors. So while I agree with the sentiment, I do not know if a CLR can be written which is going to be future-proof, such that the CLR will make sense 5 or 10 years from now. If you can write the CLR properly, then this should be an error in YANG. > Cheers, > > David Andy From andy@netconfcentral.com Tue Jul 28 18:31:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924393A69D3 for ; Tue, 28 Jul 2009 18:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 k5se2eByIamq for ; Tue, 28 Jul 2009 18:31:53 -0700 (PDT) Received: from n22b.bullet.mail.mud.yahoo.com (n22b.bullet.mail.mud.yahoo.com [68.142.206.159]) by core3.amsl.com (Postfix) with SMTP id 8C2933A68AF for ; Tue, 28 Jul 2009 18:31:53 -0700 (PDT) Received: from [68.142.200.226] by n22.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 01:31:53 -0000 Received: from [68.142.201.64] by t7.bullet.mud.yahoo.com with NNFMP; 29 Jul 2009 01:31:53 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 01:31:53 -0000 X-Yahoo-Newman-Id: 421707.31863.bm@omp416.mail.mud.yahoo.com Received: (qmail 76114 invoked from network); 29 Jul 2009 01:31:52 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2009 01:31:52 -0000 X-YMail-OSG: dAx3xekVM1kVa94.thTVsw1h4jm8jFmP1RmtuanPpl7gHDnGXNPGz4oucUOKNLYBFD3ZFUiS_JKGoApqmRlOi6EbzNWtbkcoe2K2LUtdygT0QngU64.y8jitKPoJml0trtyHIjCVPETIoaT3lYeamT1itLEaHeqMnQ4em4mDuElVeUGWSmtc963NIojBZ6lld.w0z.npQczTVJW6TyIQOqiUy3rPCvGxH5GH1lSZuc97BU9MpA0SH9HwiGPV0rv0mhIS.TwNvMaR_kZRJKCnlS7n2kD7k4uMOxhINJ4.YTwZPaM5Gg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6FA652.40509@netconfcentral.com> Date: Tue, 28 Jul 2009 18:30:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <1246434352.6491.49.camel@missotis> <1246442411.6491.94.camel@missotis> <20090702.223647.12999120.mbj@tail-f.com> <1246609976.6530.17.camel@missotis> <000401ca0c82$7ef8d940$0601a8c0@allison> <1248464183.30014.42.camel@missotis> <4A6A109E.8000403@netconfcentral.com> <1248528840.9384.48.camel@nomad> In-Reply-To: <1248528840.9384.48.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 29 Jul 2009 01:31:54 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Pá 24. 07. 2009 v 12:50 -0700: .... > OK, so consider the following module: > > module foo { > namespace "http://example.net/foo"; > prefix foo; > grouping ggg { > ... > must "foo:bar < 42"; > leaf bar { type uint8; } > ... > } > ... > } > I finally see the problem. I checked my code, and it turns out I don't bind the namespace in the grouping for must/when. Instead, I bind at the uses-stmt context, doing what the YANG author wants, not what the YANG spec says. If I implemented this according to the early binding prefix rules, it does not matter whether prefixes are used or not: must "foo:bar < 42"; must "bar < 42"; These are equivalent according to YANG rules, in this example. IMO, this is an important concept to maintain. But it means that all must/when statements inside groupings can never refer to a node in the grouping, when the grouping is used outside the original file. It gets more complicated when the import-by-revision is used. Not only is the prefix to namespace mappping done in the original file (module foo), but the exact revision of the module is bound at this time as well. Even if prefixes were forced to be the same everywhere (yeah, right), this does not help because the revision-date could be different each time module 'foo' is imported. This applies to prefixes in default, type, augment, unique statements as well. These can be fully resolved in the grouping, so they are not a problem. Treating some QNames with early binding and others with late binding is very confusing. I agree there is a problem, but so far, no good solution exists. > Now, resolving the QName as early as possible means that "foo:bar" is > resolved to "{http://example.net/foo}bar". If module "foo" is imported > and grouping "ggg" is then used in another module, this QName should no > more mean the name of the adjacent leaf because the latter assumes the > namespace of the importing module. Using my rules, this would be a > consequence of using the prefixed name. However, if the must expression > was > > must "bar < 42"; > > it would be guaranteed that "bar" always refers to the adjacent leaf. > > Lada > Andy From mbj@tail-f.com Wed Jul 29 01:48:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AFE63A6F3D for ; Wed, 29 Jul 2009 01:48:11 -0700 (PDT) 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 EmyAqymeeios for ; Wed, 29 Jul 2009 01:48:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 79C6A3A6BB9 for ; Wed, 29 Jul 2009 01:48:09 -0700 (PDT) Received: from localhost (dhcp-16eb.meeting.ietf.org [130.129.22.235]) by mail.tail-f.com (Postfix) with ESMTPSA id 93B5A76C4F1; Wed, 29 Jul 2009 10:48:10 +0200 (CEST) Date: Wed, 29 Jul 2009 10:48:10 +0200 (CEST) Message-Id: <20090729.104810.146587921.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6F91A2.5080109@netconfcentral.com> References: <1248770342.5787.15.camel@nomad> <200907281651.30179.david.partain@ericsson.com> <4A6F91A2.5080109@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Wed, 29 Jul 2009 08:48:11 -0000 Andy Bierman wrote: > I changed my mind on this one. > > The issue is the usage of a complete QName within an absolute > or relative path expression, without any wildcards or references > to relative position of instances in the data tree. > > When a complete QName is specified (a specific local-name in > a specific namespace), it MUST refer to an existing node in > the schema tree. However, if any wildcards are present which > make the exact location in the schema tree unknown or ambiguous, > then the agent may not be able to detect these errors. In the following examples, the nodes "x" are undefined, but all others are defined. Would an ipmlementation have to detect: ../x current()/../x ../a[./x] ../a[./b/x] ../a[./b[./x]] ../a[current()/x < 0] The problem is that it requires not only parsing the expression, but also some semi-interpretation of the expression. > So while I agree with the sentiment, I do not know if > a CLR can be written which is going to be future-proof, > such that the CLR will make sense 5 or 10 years from now. > > If you can write the CLR properly, > then this should be an error in YANG. I think this is more or less bound to fail, and it would be confusing if some of these references are illegal, but some are not, depending on how good our CLR is. /martin From mbj@tail-f.com Wed Jul 29 01:55:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0EF3A6BB9 for ; Wed, 29 Jul 2009 01:55:25 -0700 (PDT) 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 jy8Vgb5ZRTBd for ; Wed, 29 Jul 2009 01:55:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9C0853A6A1D for ; Wed, 29 Jul 2009 01:54:21 -0700 (PDT) Received: from localhost (dhcp-16eb.meeting.ietf.org [130.129.22.235]) by mail.tail-f.com (Postfix) with ESMTPSA id 3104C76C4F1; Wed, 29 Jul 2009 10:54:22 +0200 (CEST) Date: Wed, 29 Jul 2009 10:54:21 +0200 (CEST) Message-Id: <20090729.105421.68915305.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6FA652.40509@netconfcentral.com> References: <4A6A109E.8000403@netconfcentral.com> <1248528840.9384.48.camel@nomad> <4A6FA652.40509@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 29 Jul 2009 08:55:25 -0000 Andy Bierman wrote: > Treating some QNames with early binding and others with late binding > is very confusing. I agree there is a problem, but so far, no good > solution exists. The idea is that all names with prefixes are resolved and "fixed" where there are defined (in a grouping or not), and names without prefixes are fixed to the module where there are used. (a node outside a grouping is used in the module where it is defined). /martin > > > > > Now, resolving the QName as early as possible means that "foo:bar" is > > resolved to "{http://example.net/foo}bar". If module "foo" is imported > > and grouping "ggg" is then used in another module, this QName should no > > more mean the name of the adjacent leaf because the latter assumes the > > namespace of the importing module. Using my rules, this would be a > > consequence of using the prefixed name. However, if the must expression > > was > > > > must "bar < 42"; > > > > it would be guaranteed that "bar" always refers to the adjacent leaf. > > > > > Lada > > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Wed Jul 29 02:56:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559C83A68D7 for ; Wed, 29 Jul 2009 02:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=0.200, 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 RARUa5cpI49M for ; Wed, 29 Jul 2009 02:56:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 32C543A6EAC for ; Wed, 29 Jul 2009 02:56:56 -0700 (PDT) Received: from [130.129.20.168] (dhcp-14a8.meeting.ietf.org [130.129.20.168]) by office2.cesnet.cz (Postfix) with ESMTP id 97FF1D800BD; Wed, 29 Jul 2009 11:56:56 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090729.105421.68915305.mbj@tail-f.com> References: <4A6A109E.8000403@netconfcentral.com> <1248528840.9384.48.camel@nomad> <4A6FA652.40509@netconfcentral.com> <20090729.105421.68915305.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 29 Jul 2009 11:56:52 +0200 Message-Id: <1248861412.5767.12.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 29 Jul 2009 09:56:57 -0000 Martin Bjorklund píše v St 29. 07. 2009 v 10:54 +0200: > Andy Bierman wrote: > > Treating some QNames with early binding and others with late binding > > is very confusing. I agree there is a problem, but so far, no good > > solution exists. > > The idea is that all names with prefixes are resolved and "fixed" > where there are defined (in a grouping or not), and names without Yes, doing it in the module where the grouping is used is problematic because the prefix may be different. > prefixes are fixed to the module where there are used. In most groupings the names in XPath expressions will be unprefixed and thus marked for "late binding" of the namespace. Otherwise, prefixed names are handled identically in groupings and outside them. (It would be even clearer if the default namespace wasn't used outside groupings because unprefixed names could then appear only in groupings, but I am not going to raise this issue again). Lada > > (a node outside a grouping is used in the module where it is defined). > > > /martin > > > > > > > > > > > > > Now, resolving the QName as early as possible means that "foo:bar" is > > > resolved to "{http://example.net/foo}bar". If module "foo" is imported > > > and grouping "ggg" is then used in another module, this QName should no > > > more mean the name of the adjacent leaf because the latter assumes the > > > namespace of the importing module. Using my rules, this would be a > > > consequence of using the prefixed name. However, if the must expression > > > was > > > > > > must "bar < 42"; > > > > > > it would be guaranteed that "bar" always refers to the adjacent leaf. > > > > > > > > Lada > > > > > > > > > Andy > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Jul 29 04:09:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857483A68A4 for ; Wed, 29 Jul 2009 04:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 FVLcD+DLlhmd for ; Wed, 29 Jul 2009 04:09:27 -0700 (PDT) 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 F2A453A6833 for ; Wed, 29 Jul 2009 04:09:26 -0700 (PDT) Received: (qmail 32706 invoked from network); 29 Jul 2009 11:09:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2009 11:09:25 -0000 X-YMail-OSG: N9t.bVUVM1kQ2C1qXYXXsf0fF0Aj4keiljHtAfZuv2lVOeNFCLJK8549CEhtq0GX7iW0d50ccdtBjW2ih_seUt1zB4Yr1tYPD_sjRNnZAzF04nMtmVOfZGlBI4N.nOZKRlbmyvZfT6SQWmlSq.v4oacG61nOq0LUqfzgdL6zV1nDkpF0HdI4jKNCg_3RAlvEAYmHNzc0y7JbXkFVhR7QHXB5.alfAsc4IRHc4m6ztnnOH8ZFJenLVMAoD.uGU9qQxpDLaYQ6bF9bcBCOnKrQWIlx62Il7fdoV5e5n6prcpSrzhnF1PppkPM2TBSyNQdpkHuwSeuqwO_t_DqltwEi4rWLFGkOp8N7KKU8Q_mnKm33qhk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A702DB4.3000209@netconfcentral.com> Date: Wed, 29 Jul 2009 04:08:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A6A109E.8000403@netconfcentral.com> <1248528840.9384.48.camel@nomad> <4A6FA652.40509@netconfcentral.com> <20090729.105421.68915305.mbj@tail-f.com> In-Reply-To: <20090729.105421.68915305.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 29 Jul 2009 11:09:27 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Treating some QNames with early binding and others with late binding >> is very confusing. I agree there is a problem, but so far, no good >> solution exists. > > The idea is that all names with prefixes are resolved and "fixed" > where there are defined (in a grouping or not), and names without > prefixes are fixed to the module where there are used. > > (a node outside a grouping is used in the module where it is defined). > > I do not think this is very intuitive at all. Most people reading a YANG module will not guess that identifiers without prefixes that happen to be inside a grouping are special 'late-binders', and the identifiers with prefixes are 'early-binders'. > /martin Andy From phil@juniper.net Wed Jul 29 04:59:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAC83A6F75 for ; Wed, 29 Jul 2009 04:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 ZgaUF4Zccb3v for ; Wed, 29 Jul 2009 04:59:16 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 9F7B93A6990 for ; Wed, 29 Jul 2009 04:59:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSnA5k4Td0tgeDOYx0lGfUQQYAyCAtaWN@postini.com; Wed, 29 Jul 2009 04:59:18 PDT 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.375.2; Wed, 29 Jul 2009 04:53:55 -0700 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, 29 Jul 2009 04:53:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 04:53:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 04:53:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6TBrrd80550; Wed, 29 Jul 2009 04:53:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6TBgOCT035074; Wed, 29 Jul 2009 11:42:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907291142.n6TBgOCT035074@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090729.104810.146587921.mbj@tail-f.com> Date: Wed, 29 Jul 2009 07:42:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Jul 2009 11:53:53.0706 (UTC) FILETIME=[3EDDD8A0:01CA1043] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Wed, 29 Jul 2009 11:59:17 -0000 Martin Bjorklund writes: >The problem is that it requires not only parsing the expression, but >also some semi-interpretation of the expression. I'm suggesting two bits: (a) that we say that this isn't valid yang, and (b) that we detect simple brokenness and not compile it. Thanks, Phil From mbj@tail-f.com Wed Jul 29 05:11:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606EF3A706E for ; Wed, 29 Jul 2009 05:11:54 -0700 (PDT) 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 iae6kV85GSAq for ; Wed, 29 Jul 2009 05:11:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 601CA3A6E92 for ; Wed, 29 Jul 2009 05:11:53 -0700 (PDT) Received: from localhost (dhcp-16eb.meeting.ietf.org [130.129.22.235]) by mail.tail-f.com (Postfix) with ESMTPSA id BB80876C54F; Wed, 29 Jul 2009 14:11:53 +0200 (CEST) Date: Wed, 29 Jul 2009 14:11:53 +0200 (CEST) Message-Id: <20090729.141153.09148967.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907291142.n6TBgOCT035074@idle.juniper.net> References: <20090729.104810.146587921.mbj@tail-f.com> <200907291142.n6TBgOCT035074@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath warnings 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: , X-List-Received-Date: Wed, 29 Jul 2009 12:11:54 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >The problem is that it requires not only parsing the expression, but > >also some semi-interpretation of the expression. > > I'm suggesting two bits: (a) that we say that this isn't valid yang, So you're saying that all above examples are invalid? > and (b) that we detect simple brokenness and not compile it. Define "simple brokenness". /martin From balazs.lengyel@ericsson.com Wed Jul 29 05:15:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E6E3A7073 for ; Wed, 29 Jul 2009 05:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SE=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 TS5Pdr9PECvw for ; Wed, 29 Jul 2009 05:15:00 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C721D3A701D for ; Wed, 29 Jul 2009 05:14:59 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-79-4a703d434fef Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C2.3C.18827.44D307A4; Wed, 29 Jul 2009 14:15:00 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:14:59 +0200 Received: from [127.0.0.1] ([10.42.207.84]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:14:54 +0200 Message-ID: <4A703D2E.3030402@ericsson.com> Date: Wed, 29 Jul 2009 14:14:38 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A6F214F.4040808@ericsson.com> <1248813364.18883.4.camel@nomad> In-Reply-To: <1248813364.18883.4.camel@nomad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jul 2009 12:14:59.0652 (UTC) FILETIME=[316DE040:01CA1046] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Dont reuse list and container names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:15:00 -0000 Hello, Yes name mangling can be done. However the more mangling is done the more difficult it is to see the connection between the original YANG and the generated documents, models, code. Is there any real need to reuse names? Balazs Ladislav Lhotka wrote: > Balazs Lengyel píše v Út 28. 07. 2009 v 18:03 +0200: >> Hello, >> YANG data modules will often be mapped to Java and C++ code and to other modeling >> languages, that use complex types and managed objects like 3GPP, SAF. Often these >> mappings will create a manage object or a class for each container and list. If the list >> names and container names are not unique the mapping will fail. Having unique names will > > Then these mappings can mangle names to make them unique. DSDL mapping > does this with names of groupings and types. > > Lada > >> also make YAMs easier to read. I propose to add to the Yang-Usage guidelines: >> >> "The common set of names of containers and lists in a YANG module and its submodules >> SHOULD only contain unique names." >> >> Balazs, >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From balazs.lengyel@ericsson.com Wed Jul 29 05:22:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829C73A6A2E for ; Wed, 29 Jul 2009 05:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=1.333, 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 l4dpX2VAfr6B for ; Wed, 29 Jul 2009 05:22:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 832D83A6966 for ; Wed, 29 Jul 2009 05:22:48 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb9ae000004f89-8b-4a703f189879 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 47.B9.20361.71F307A4; Wed, 29 Jul 2009 14:22:48 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:22:46 +0200 Received: from [127.0.0.1] ([10.42.207.84]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:22:45 +0200 Message-ID: <4A703F1C.6080000@ericsson.com> Date: Wed, 29 Jul 2009 14:22:52 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A6F214F.4040808@ericsson.com> <4A6F36BE.4090207@netconfcentral.com> In-Reply-To: <4A6F36BE.4090207@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2009 12:22:46.0341 (UTC) FILETIME=[4798F750:01CA1047] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Dont reuse list and container names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:22:49 -0000 Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> YANG data modules will often be mapped to Java and C++ code and to other >> modeling >> languages, that use complex types and managed objects like 3GPP, SAF. >> Often these >> mappings will create a manage object or a class for each container and >> list. If the list >> names and container names are not unique the mapping will fail. Having >> unique names will >> also make YAMs easier to read. I propose to add to the Yang-Usage >> guidelines: >> >> "The common set of names of containers and lists in a YANG module and >> its submodules >> SHOULD only contain unique names." >> > > I do not agree with this. > By definition, objects from groupings will have the same name. > XML does not place any requirement on nested name uniqueness, > just sibling name uniqueness. > > I think code generators need to deal with: > - objects from uses-stmt (duplicates will come up) > - the dash and dot chars are not allowed in identifiers within code. > - YANG identifiers can be infinite length > > So name mangling is already mandatory for tools to implement. > BALAZS: Some mangling will be mandatory for the tools. But the smaller the changes for mangling, and the less it is used, the better the readability of the generated document, code. Balazs From andy@netconfcentral.com Wed Jul 29 05:34:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB743A6A15 for ; Wed, 29 Jul 2009 05:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 X0axr8ZT36oR for ; Wed, 29 Jul 2009 05:34:21 -0700 (PDT) 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 BA91A3A700B for ; Wed, 29 Jul 2009 05:34:21 -0700 (PDT) Received: (qmail 53939 invoked from network); 29 Jul 2009 12:34:21 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2009 12:34:21 -0000 X-YMail-OSG: RHr9tEcVM1knfCSkFtng958AiIUNumScIDozDKr2IxQn6GA51nq2Z7AL2yw.Vhs4SmSKOxjTjAQnroAVG.eCK3k201q5Gp7jFIJJtZtHNZCP7My7JFPYZFJOeDUIzfXc4eQ_n0XsM.BlcNBO87L1B1jpsbKwSjHwPeg_K24bXMaX5JXUzb4Qjk.EtPLvkvewbzX44ijFyBue9XVaA4W3332Y2rjVkLUP7GbgOGLpld93SM1oMOEF1.eh23px5u1zrWYGzdeMK38aZb7FeWGB0e.JdmRATTbzl2Qn1uZiRS.ZVwMo1g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70419C.9020604@netconfcentral.com> Date: Wed, 29 Jul 2009 05:33:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: balazs.lengyel@ericsson.com References: <4A6F214F.4040808@ericsson.com> <1248813364.18883.4.camel@nomad> <4A703D2E.3030402@ericsson.com> In-Reply-To: <4A703D2E.3030402@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Dont reuse list and container names 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: , X-List-Received-Date: Wed, 29 Jul 2009 12:34:22 -0000 Balazs Lengyel wrote: > Hello, > Yes name mangling can be done. However the more mangling is done the > more difficult it is to see the connection between the original YANG and > the generated documents, models, code. Is there any real need to reuse > names? groupings cause names to be reused. > Balazs Andy From mark@ellisonsoftware.com Wed Jul 29 05:40:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213B43A68C1 for ; Wed, 29 Jul 2009 05:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7yRIFRsBfIb for ; Wed, 29 Jul 2009 05:40:15 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id C25743A67E7 for ; Wed, 29 Jul 2009 05:40:14 -0700 (PDT) Received: by gxk9 with SMTP id 9so1375664gxk.13 for ; Wed, 29 Jul 2009 05:40:14 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.150.200.8 with SMTP id x8mr1418976ybf.189.1248871214358; Wed, 29 Jul 2009 05:40:14 -0700 (PDT) Date: Wed, 29 Jul 2009 08:40:14 -0400 X-Google-Sender-Auth: 0e5fbd71b1ad60d3 Message-ID: <8a0268750907290540w4c17d137s368d149c4f728f70@mail.gmail.com> From: Mark Ellison To: netmod@ietf.org Content-Type: multipart/alternative; boundary=000e0cd3070a1a2172046fd77df9 Subject: [netmod] Issue 2 - data-and-time canonicalization 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: , X-List-Received-Date: Wed, 29 Jul 2009 12:40:16 -0000 --000e0cd3070a1a2172046fd77df9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Regarding UTC time: There appeared to me an issue regarding the time-zone location of a device if only UTC date-and-time is deployed. My comment earlier today in the NETMOD WG concerned whether operators would be able to know in which timezone a device resides. For a configuration that depends on the notion of local time an operator would be required to know the timezone for the target device in order to work with the canonical UTC. In reviewing the date-and-time typedef contained in draft-ietf-netmod-yang-types-03 it is clear that a zone offset is part of this typedef definition. So, the presence of the time offset eliminates my concern regarding the timezone in which a device resides. Regarding the canonicalization of the "...Z+02:00" portion of the UTC, I am in favor. In other words, I think all servers should respond with a canonical UTC date-and-time. I also think it would be okay for devices with only a notion of local time to report a string that omits the 'Z suffix'. FYI- the issue slide should reference WG email- http://www.ietf.org/mail-archive/web/netmod/current/msg03200.html (...not 03201...) Others' thoughts? Regards, Mark --000e0cd3070a1a2172046fd77df9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Regarding UTC time:=A0 There appeared to me an issue regarding t= he time-zone location of a device if only UTC date-and-time is deployed.=A0= My comment earlier today in the NETMOD WG concerned whether operators woul= d be able to know in which timezone a device resides.

For a configuration that depends on the notion of local time an operato= r would be required to know the timezone for the target device in order to = work with the canonical UTC.=A0 In reviewing the date-and-time typedef cont= ained in draft-ietf-netmod-yang-types-03 it is clear that a zone offset is = part of this typedef definition.

So, the presence of the time offset eliminates my concern regarding the= timezone in which a device resides.

Regarding the canonicalization = of the "...Z+02:00" portion of the UTC, I am in favor.=A0 In othe= r words, I think all servers should respond with a canonical UTC date-and-t= ime. I also think it would be okay for devices with only a notion of local = time to report a string that omits the 'Z suffix'.

FYI- the issue slide should reference WG email- http://www.ietf.org/= mail-archive/web/netmod/current/msg03200.html (...not 03201...)

Others' thoughts?

Regards,

Mark
--000e0cd3070a1a2172046fd77df9-- From j.schoenwaelder@jacobs-university.de Wed Jul 29 05:54:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12CE3A6F41 for ; Wed, 29 Jul 2009 05:54:20 -0700 (PDT) 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.040, 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 YKDkBsYLCwgL for ; Wed, 29 Jul 2009 05:54:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CBC843A6403 for ; Wed, 29 Jul 2009 05:54:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABB06C0068; Wed, 29 Jul 2009 14:54:20 +0200 (CEST) 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 BCBxS7krFEZv; Wed, 29 Jul 2009 14:54:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 033B2C0016; Wed, 29 Jul 2009 14:54:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3E5DB7080C; Wed, 29 Jul 2009 14:54:19 +0200 (CEST) Date: Wed, 29 Jul 2009 14:54:19 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090729125419.GB14258@elstar.local> Mail-Followup-To: Balazs Lengyel , Ladislav Lhotka , "netmod@ietf.org" References: <4A6F214F.4040808@ericsson.com> <1248813364.18883.4.camel@nomad> <4A703D2E.3030402@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A703D2E.3030402@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Dont reuse list and container names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:54:20 -0000 On Wed, Jul 29, 2009 at 02:14:38PM +0200, Balazs Lengyel wrote: > Yes name mangling can be done. However the more mangling is done the > more difficult it is to see the connection between the original YANG > and the generated documents, models, code. Is there any real need > to reuse names? Since we plan for success, a flat namespace will bite us. And repeating myself, the amount of name mangling code generators need to do is target language specific and in reality you almost always have to do some target language mangling. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Jul 29 06:03:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54923A6FFC for ; Wed, 29 Jul 2009 06:03:01 -0700 (PDT) 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.039, 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 HtZIUkUrfZiJ for ; Wed, 29 Jul 2009 06:03:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 88E053A6EE4 for ; Wed, 29 Jul 2009 06:03:00 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6AC9C0068; Wed, 29 Jul 2009 15:03:01 +0200 (CEST) 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 7UeIRXsn6XkJ; Wed, 29 Jul 2009 15:03:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 104B4C0016; Wed, 29 Jul 2009 15:03:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DFE82B70877; Wed, 29 Jul 2009 15:03:00 +0200 (CEST) Date: Wed, 29 Jul 2009 15:03:00 +0200 From: Juergen Schoenwaelder To: Mark Ellison Message-ID: <20090729130300.GA14369@elstar.local> Mail-Followup-To: Mark Ellison , "netmod@ietf.org" References: <8a0268750907290540w4c17d137s368d149c4f728f70@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a0268750907290540w4c17d137s368d149c4f728f70@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:03:01 -0000 On Wed, Jul 29, 2009 at 02:40:14PM +0200, Mark Ellison wrote: > Regarding UTC time: There appeared to me an issue regarding the > time-zone location of a device if only UTC date-and-time is > deployed. My comment earlier today in the NETMOD WG concerned > whether operators would be able to know in which timezone a device > resides. This is a data model issue; there should ideally be a standard core configuration data model that allows to read and configure the time-zone. But that is future work... > For a configuration that depends on the notion of local time an > operator would be required to know the timezone for the target > device in order to work with the canonical UTC. In reviewing the > date-and-time typedef contained in draft-ietf-netmod-yang-types-03 > it is clear that a zone offset is part of this typedef definition. There is an offset - so I can configure +02:00 but the box will return the configure value back to me in UTC. > So, the presence of the time offset eliminates my concern regarding > the timezone in which a device resides. See above, this would be a config leaf to be standardized. > Regarding the canonicalization of the "...Z+02:00" portion of the > UTC, I am in favor. In other words, I think all servers should > respond with a canonical UTC date-and-time. I also think it would be > okay for devices with only a notion of local time to report a string > that omits the 'Z suffix'. May be needed - I will take a look at this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Jul 29 06:39:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D0D3A6F49 for ; Wed, 29 Jul 2009 06:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 0e3FtMOh5GrA for ; Wed, 29 Jul 2009 06:39:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 00B2A3A70BA for ; Wed, 29 Jul 2009 06:39:08 -0700 (PDT) Received: from [10.43.1.112] (unknown [77.241.97.148]) by office2.cesnet.cz (Postfix) with ESMTP id 764FED800C8; Wed, 29 Jul 2009 15:38:47 +0200 (CEST) From: Ladislav Lhotka To: balazs.lengyel@ericsson.com In-Reply-To: <4A703D2E.3030402@ericsson.com> References: <4A6F214F.4040808@ericsson.com> <1248813364.18883.4.camel@nomad> <4A703D2E.3030402@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 29 Jul 2009 15:38:45 +0200 Message-Id: <1248874725.3654.5.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Dont reuse list and container names 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: , X-List-Received-Date: Wed, 29 Jul 2009 13:39:39 -0000 Balazs Lengyel píše v St 29. 07. 2009 v 14:14 +0200: > Hello, > Yes name mangling can be done. However the more mangling is done the more difficult it is > to see the connection between the original YANG and the generated documents, models, code. > Is there any real need to reuse names? Flat namespace was identified as one of the main shortcomings of DTD. In effect, name mangling would then happen in the primary data model: container ospf { container ospf-interface { .... } .... } Lada Lada > Balazs > > Ladislav Lhotka wrote: > > Balazs Lengyel píše v Út 28. 07. 2009 v 18:03 +0200: > >> Hello, > >> YANG data modules will often be mapped to Java and C++ code and to other modeling > >> languages, that use complex types and managed objects like 3GPP, SAF. Often these > >> mappings will create a manage object or a class for each container and list. If the list > >> names and container names are not unique the mapping will fail. Having unique names will > > > > Then these mappings can mangle names to make them unique. DSDL mapping > > does this with names of groupings and types. > > > > Lada > > > >> also make YAMs easier to read. I propose to add to the Yang-Usage guidelines: > >> > >> "The common set of names of containers and lists in a YANG module and its submodules > >> SHOULD only contain unique names." > >> > >> Balazs, > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Jul 29 07:49:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65973A67E7 for ; Wed, 29 Jul 2009 07:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 ybeCB6llfz9U for ; Wed, 29 Jul 2009 07:49:37 -0700 (PDT) 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 ADF5F3A6830 for ; Wed, 29 Jul 2009 07:49:01 -0700 (PDT) Received: (qmail 2983 invoked from network); 29 Jul 2009 14:49:01 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2009 14:49:00 -0000 X-YMail-OSG: ujfX0ioVM1mGp7Q0mHz.aHni9IkRKWTJs5nLRp7io_r7TpQFlXPBokxbXKqDimSCyyUjW3U8Y0Bl.knVvDRe9ZWRCaGGuPJhISFWB9PSKtVoJxU2VDIMevppjn8IggLVCpIaZBsguMigM_qUzAJK9yAuXhk_ZvPn52dKF7ZLuJm_1mmGSOQt1u1NlkFQrYF3EXZ8GceDmJLFIVjMTlL7zHT5uMgUPf7qlRTD.Jh2kUF.1k.W7LLEp2_YVzBkzVL5bStVd4vacBV8b97TKZ37UYbSU8Xqo7rnP_TqxkO.5J.H3gl43A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7061A6.6050903@netconfcentral.com> Date: Wed, 29 Jul 2009 07:50:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/mixed; boundary="------------030005040909000103070802" Subject: [netmod] prefixes in groupings 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: , X-List-Received-Date: Wed, 29 Jul 2009 14:49:39 -0000 This is a multi-part message in MIME format. --------------030005040909000103070802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I created 2 test modules (see attached) to see how yangdump would deal with it. Since the grouping 'ggg' is not actually used in module testfoo1, it does not cause any errors or even warnings. The error shows up via the uses-stmt in the testfoo2 module. (Note the bug -- line number, line position (12.10) is from testfoo1.yang file, not the testfoo2.yang module that is currently being parsed. Not sure how to report this, since there is no error in testfoo1.yang: Error: Module for prefix 'foo' not found testfoo2.yang:12.10: error(228): invalid name *** /home/andy/modules/test/testfoo2.yang: 1 Errors, 0 Warnings I don't really understand the current solution proposal. Maybe somebody can write it down in sufficient detail so I know for every possible usage of a prefix, or usage of a QName identifier that does not have a prefix, and all the special ways a YANG complier is supposed to interpret the same syntax in various contexts. I am concerned that groupings may be too fragile for reasonable usage by people other than the standards writers. Will a normal engineer or operator study the 113 page YANG RFC thoroughly enough to avoid making mistakes with groupings? Is there sufficiently low localized cost across all language features, or is the overall complexity too high, in order to support some corner-case features? (I'm just asking, who knows...) Andy --------------030005040909000103070802 Content-Type: text/plain; name="testfoo1.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testfoo1.yang" module testfoo1 { namespace "http://example.net/testfoo1"; prefix "foo"; revision 2009-07-28 { description "Initial revision."; } grouping ggg { container test-top { must "foo:bar < 42"; leaf bar { type uint8; } } } } --------------030005040909000103070802 Content-Type: text/plain; name="testfoo2.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testfoo2.yang" module testfoo2 { namespace "http://example.net/testfoo2"; prefix "foo2"; import testfoo1 { prefix foo1; } revision 2009-07-28 { description "Initial revision."; } container one { uses foo1:ggg; } } --------------030005040909000103070802-- From phil@juniper.net Wed Jul 29 07:57:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83533A6DFD for ; Wed, 29 Jul 2009 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 F7b9gToP9uHV for ; Wed, 29 Jul 2009 07:57:32 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 2A7143A67F4 for ; Wed, 29 Jul 2009 07:57:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSnBjUp7S9kDvnq7cZMV5kboVB+KVoSjO@postini.com; Wed, 29 Jul 2009 07:57:33 PDT 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.375.2; Wed, 29 Jul 2009 07:52:05 -0700 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, 29 Jul 2009 07:52:05 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:52:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 07:52:04 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6TEq3d08211; Wed, 29 Jul 2009 07:52:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6TEeYvY036427; Wed, 29 Jul 2009 14:40:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907291440.n6TEeYvY036427@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090729130300.GA14369@elstar.local> Date: Wed, 29 Jul 2009 10:40:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Jul 2009 14:52:04.0016 (UTC) FILETIME=[22C9B300:01CA105C] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization 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: , X-List-Received-Date: Wed, 29 Jul 2009 14:57:32 -0000 Juergen Schoenwaelder writes: >There is an offset - so I can configure +02:00 but the box will return >the configure value back to me in UTC. I thought UTC means the offset returned will always be "+0:00". Thanks, Phil From andy@netconfcentral.com Wed Jul 29 08:17:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E253A6AF7 for ; Wed, 29 Jul 2009 08:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 yKy3aV+jBgF1 for ; Wed, 29 Jul 2009 08:17:01 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id EEF143A6AA1 for ; Wed, 29 Jul 2009 08:17:00 -0700 (PDT) Received: (qmail 13306 invoked from network); 29 Jul 2009 15:17:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2009 15:17:00 -0000 X-YMail-OSG: lvSMFvUVM1nddCEqfB9Shpu3s7cqNDpDVIQ_SkzAMTpWK0I3rUFXGisi6bNPZmkGnrP2VjItwBG9o1oLrkmEMx0c.eRDF9TZne5NQVwckdf6Xht0cQIRTQM3EcYCECz5gD0WlTsDXV3X9RIQyR7p2cqgWG.2nO_duPeoHlPdfaXtYroAddBZbM0dYr.JVc.Ji6vN7a_qHBPWsF7oV6HMz3JeJPuDUtsEpcMU52X51Qzl5YkCAHNK3gszru1l3Ut7IZtulOsZk3cfeg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A706835.5020409@netconfcentral.com> Date: Wed, 29 Jul 2009 08:18:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907291440.n6TEeYvY036427@idle.juniper.net> In-Reply-To: <200907291440.n6TEeYvY036427@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization 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: , X-List-Received-Date: Wed, 29 Jul 2009 15:17:02 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> There is an offset - so I can configure +02:00 but the box will return >> the configure value back to me in UTC. > > I thought UTC means the offset returned will always be "+0:00". > not every operational problem can or should be solved with the YANG language. there needs to be 2 or 3 standards leafs: utc-time (type yang:date-and-time) local-time (type ???, maybe just "HH:MM:SS") utc-offset (type ???, maybe just ('+'|'-')"HH:MM") Then, authors of time-based-ACLs, or whatever feature, can decide which version of the current time to use in their YANG statements. IMO, it would be a bad idea to encode all these objects with a single (complicated) syntax. The yang:date-and-time data type should just be an absolute time-stamp. > Thanks, > Phil Andy From mark@ellisonsoftware.com Wed Jul 29 14:01:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46513A6F8E for ; Wed, 29 Jul 2009 14:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0znUWUO0pMy for ; Wed, 29 Jul 2009 14:01:32 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id E66DD3A6E40 for ; Wed, 29 Jul 2009 14:01:31 -0700 (PDT) Received: by ywh4 with SMTP id 4so221819ywh.17 for ; Wed, 29 Jul 2009 14:01:31 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.150.181.12 with SMTP id d12mr603751ybf.62.1248901291007; Wed, 29 Jul 2009 14:01:31 -0700 (PDT) In-Reply-To: <4A706835.5020409@netconfcentral.com> References: <200907291440.n6TEeYvY036427@idle.juniper.net> <4A706835.5020409@netconfcentral.com> Date: Wed, 29 Jul 2009 17:01:30 -0400 X-Google-Sender-Auth: 4acf56799096b154 Message-ID: <8a0268750907291401v58d1cf57k1a669186f9b0ab9e@mail.gmail.com> From: Mark Ellison To: Andy Bierman Content-Type: multipart/alternative; boundary=000e0cd6adcacf5fad046fde7dbc Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization 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: , X-List-Received-Date: Wed, 29 Jul 2009 21:01:32 -0000 --000e0cd6adcacf5fad046fde7dbc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Jul 29, 2009 at 11:18 AM, Andy Bierman wrote: > > there needs to be 2 or 3 standards leafs: > > utc-time (type yang:date-and-time) > > local-time (type ???, maybe just "HH:MM:SS") > > utc-offset (type ???, maybe just ('+'|'-')"HH:MM") > I can see something like this to config/initialize the current time on a device...but alternatively I can see some devices using an NTP server instead for this information and that would be a different set of config leaves. - Mark --000e0cd6adcacf5fad046fde7dbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2009 at 11:18 AM, Andy Bierman <andy@netconfcentral.com>= wrote:

there needs to be 2 or 3 standards leafs:

=A0 utc-time =A0(type yang:date-and-time)

=A0 local-time =A0(type ???, maybe just "HH:MM:SS")

=A0 utc-offset =A0(type ???, maybe just ('+'|'-')"HH:= MM")

I can see something like this to config/initialize th= e current time on a device...but alternatively I can see some devices using= an NTP server instead for this information and that would be a different s= et of config leaves.


- Mark
--000e0cd6adcacf5fad046fde7dbc-- From andy@netconfcentral.com Wed Jul 29 14:50:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A42A3A6BD9 for ; Wed, 29 Jul 2009 14:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 Tny36nkZpU6Q for ; Wed, 29 Jul 2009 14:50:02 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 6DBA93A6407 for ; Wed, 29 Jul 2009 14:50:02 -0700 (PDT) Received: (qmail 82968 invoked from network); 29 Jul 2009 21:50:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2009 21:50:01 -0000 X-YMail-OSG: dj0oBlAVM1lBis4r6VZjUoONWsny3av3LJgfQkucjqm2nl0tI3jJJfFEg56RBRRes0NfXVVrZ94XKrWTI5kBbd82jqXsdKO3h33Pq.EE5LOwWOCSc9zWCNlxBQaGBzFjygemb16buegLp3bZwxFabvtm03N5cxc0BJ1428u2n3nu6Ib0Tc3f3ELiqar5i_8TjKDtoFTpT6YZG0KTwlhJtNlbuDRFgywtL8lTfLNMjPIpgq6myrUJ15NdPiic3oz_mJzFoyMNo0eGmPthkBGbnGBev1MIUkKctKpJ4iMnh7VX1.ASVIEsENbsECJNA.0VE6llgfhCbxHoKw2kIf53.2dQwZ6mUK1y48m0d4.SmBOsLtk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70C390.6080609@netconfcentral.com> Date: Wed, 29 Jul 2009 14:48:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Mark Ellison References: <200907291440.n6TEeYvY036427@idle.juniper.net> <4A706835.5020409@netconfcentral.com> <8a0268750907291401v58d1cf57k1a669186f9b0ab9e@mail.gmail.com> In-Reply-To: <8a0268750907291401v58d1cf57k1a669186f9b0ab9e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization 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: , X-List-Received-Date: Wed, 29 Jul 2009 21:50:03 -0000 Mark Ellison wrote: > On Wed, Jul 29, 2009 at 11:18 AM, Andy Bierman > wrote: > > > there needs to be 2 or 3 standards leafs: > > utc-time (type yang:date-and-time) > > local-time (type ???, maybe just "HH:MM:SS") > > utc-offset (type ???, maybe just ('+'|'-')"HH:MM") > > > I can see something like this to config/initialize the current time on a > device...but alternatively I can see some devices using an NTP server > instead for this information and that would be a different set of config > leaves. > These are read-only leafs, but I can see that the config side would be more complicated. > > - Mark Andy From andy@netconfcentral.com Wed Jul 29 16:37:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AEB3A6819 for ; Wed, 29 Jul 2009 16:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 zVHMvliiDEIa for ; Wed, 29 Jul 2009 16:37:08 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 2B2F73A63C9 for ; Wed, 29 Jul 2009 16:37:08 -0700 (PDT) Received: from [68.142.200.226] by n18.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 23:37:08 -0000 Received: from [68.142.201.242] by t7.bullet.mud.yahoo.com with NNFMP; 29 Jul 2009 23:37:08 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 23:37:08 -0000 X-Yahoo-Newman-Id: 260800.73552.bm@omp403.mail.mud.yahoo.com Received: (qmail 63296 invoked from network); 29 Jul 2009 23:37:07 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2009 23:37:07 -0000 X-YMail-OSG: O_o3dXsVM1lz2O38S5XQI25kJOh9qipXIY.UpbDbdt71LKVIPGZNyQk7YiwpWZpvxXyuNiivaT0m6I2TWtoEAXTcgCx._7WesuugXxJsd_wjjHbljieGDUweuYUWYm3tzW9aWk9262LwIAv66rX22c0xNaSoEgDM7Epb838ZyQnctAddsw.wBPLixCr8Ix.4k4uzUIu9aR.XgHg39wKh7xzhDyJtVwwDBzjZ.hlsaCouH2L9seoVo_25yopFsOcy7.xeSmDgGCnnziAbF2iQKGoSItjo9BPSDbt7qIczfRqp8nRkXg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70DCA9.6060109@netconfcentral.com> Date: Wed, 29 Jul 2009 16:35:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Wed, 29 Jul 2009 23:37:09 -0000 Hi, The actual format of the temporary contents of the namespace statement needs to be finalized. - there may be more than 1 module in the I-D - it is useful to identify the document revision, in case early implementations actually exist. - a valid URI scheme is needed The current draft suggests the I-D name, without the revision or file suffix. The slide in the NETMOD meeting suggested the module name: module foo { namespace "file://foo.yang"; prefix foo; ... } *** New Proposed Solution: add the I-D version to the module name *** Also add 'tbd-assigned-by-IANA-tbd/' to path to make it more *** clear that this value will be replaced in the RFC version module foo { // note to IANA: replace this string with real namespace URI namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; prefix foo; ... } Any objections to this change? Andy From andy@netconfcentral.com Wed Jul 29 16:58:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2170B3A6FB7 for ; Wed, 29 Jul 2009 16:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, J_CHICKENPOX_84=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 JiWm-LO2EEhx for ; Wed, 29 Jul 2009 16:58:10 -0700 (PDT) Received: from n26.bullet.mail.mud.yahoo.com (n26.bullet.mail.mud.yahoo.com [68.142.206.221]) by core3.amsl.com (Postfix) with SMTP id 4FDA83A690A for ; Wed, 29 Jul 2009 16:58:10 -0700 (PDT) Received: from [68.142.200.225] by n26.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 23:58:10 -0000 Received: from [68.142.201.244] by t6.bullet.mud.yahoo.com with NNFMP; 29 Jul 2009 23:58:10 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 23:58:10 -0000 X-Yahoo-Newman-Id: 373411.75519.bm@omp405.mail.mud.yahoo.com Received: (qmail 3088 invoked from network); 29 Jul 2009 23:58:09 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2009 23:58:09 -0000 X-YMail-OSG: Rn_ZankVM1np7raavyvQnUYFbVYT7oqnYwpdhe6Ta93KwUR5hZSBlpzLdZ6dz55vvR5NrG3nN5dLMEXdZl1VwhH82qghucxneDsAevV8bO2jCvJCvJungcQCDvUZWJgy7b2wMEliTP9seoqvshq_lYWm31ShVvCM7yi7pRIqKqr_Sydn1qH_cwue7498dewYrI.g8eWOfMe0LNJl60vMe5MTZIZJtD4cxxCD0PBtWT1JxyjSeliMWjiMYQuhMZyoDr_.euS.ZQfN2CekXy1pKmm7cP9rEP4m89icre4cQMcITbF9qQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70E199.9000708@netconfcentral.com> Date: Wed, 29 Jul 2009 16:56:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang usage: template.yang 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: , X-List-Received-Date: Wed, 29 Jul 2009 23:58:11 -0000 Hi, In the next revision, I plan to add an appendix with a YANG module template. Hopefully, YANG writers will cut-and-paste as needed to more easily comply with the guidelines. Would it be better to pick some simple example like TOASTER-MIB, maybe blender.yang (any suggestions?) than complex examples (like ipfix), or junk names and data structures (like foo and goo)? IMO, something like blender.yang might be best to explain some of the guidelines. Should I reuse toaster? Any other simple appliances that would make a good template? thanks, Andy From phil@juniper.net Wed Jul 29 17:27:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A5D3A6938 for ; Wed, 29 Jul 2009 17:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 EPAysERGMuf0 for ; Wed, 29 Jul 2009 17:27:31 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id C2F263A6A48 for ; Wed, 29 Jul 2009 17:27:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSnDo9Gk7K8Fx/Ff26WKfx0uSY02G2Bc0@postini.com; Wed, 29 Jul 2009 17:27:33 PDT 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.375.2; Wed, 29 Jul 2009 17:24:28 -0700 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, 29 Jul 2009 17:24:28 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 17:24:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 17:24:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6U0OQd98041; Wed, 29 Jul 2009 17:24:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6U0CvH2039381; Thu, 30 Jul 2009 00:12:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907300012.n6U0CvH2039381@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A70DCA9.6060109@netconfcentral.com> Date: Wed, 29 Jul 2009 20:12:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 00:24:27.0010 (UTC) FILETIME=[18CEB620:01CA10AC] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 00:27:32 -0000 Andy Bierman writes: > module foo { > // note to IANA: replace this string with real namespace URI > namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; file:// seems bad. Consider instead a URN-based approach: namespace unn:ietf:params:xml:ns:yang:draft:-.txt This is consisent with the namespaces of NETCONF and YANG. Thanks, Phil From andy@netconfcentral.com Wed Jul 29 17:52:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690FC3A710D for ; Wed, 29 Jul 2009 17:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 MQEdIe4vmKUG for ; Wed, 29 Jul 2009 17:52:23 -0700 (PDT) Received: from n11b.bullet.mail.mud.yahoo.com (n11b.bullet.mail.mud.yahoo.com [209.191.125.178]) by core3.amsl.com (Postfix) with SMTP id AC93A3A7103 for ; Wed, 29 Jul 2009 17:52:23 -0700 (PDT) Received: from [209.191.108.96] by n11.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 00:52:22 -0000 Received: from [68.142.201.254] by t3.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 00:52:22 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 00:52:22 -0000 X-Yahoo-Newman-Id: 841079.61640.bm@omp415.mail.mud.yahoo.com Received: (qmail 15643 invoked from network); 30 Jul 2009 00:52:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 00:52:22 -0000 X-YMail-OSG: uSFIVpUVM1kw.dSDewL6cRcgTOJuY_mRdyNRsJkseXliyW91QU7L9PivxSJwmq5fvsvLqbKd6YbwEbnbu3QJ0UcL6qjTBOFtUyj6kZXtwpbcE5gDvH1w95u49AaE.i3xoqvh4GnnOjpB1rLCut0mkPPqf7zmrV.tCfd.cryzGIzccaelaEOBxjnf2iqAoppqpoc.WeXvk.KhU8VCYiZoqmj8T6jMIFH1UuHAQYWMp0lYrNSQl8katfsPl3NtgNDHscjf.0pmMshs9dg3R_akv8LR4OVGtv5xU3Q5sSX_joW9OuZD6A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70EEC8.2080809@netconfcentral.com> Date: Wed, 29 Jul 2009 17:52:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907300012.n6U0CvH2039381@idle.juniper.net> In-Reply-To: <200907300012.n6U0CvH2039381@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 00:52:24 -0000 Phil Shafer wrote: > Andy Bierman writes: >> module foo { >> // note to IANA: replace this string with real namespace URI >> namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; > > file:// seems bad. Consider instead a URN-based approach: > > namespace unn:ietf:params:xml:ns:yang:draft:-.txt > > This is consisent with the namespaces of NETCONF and YANG. > IMO this is too consistent. It looks very close to the real one that will be assigned later. It looks like we need to get IANA approval for the temporary namespace. We have some MIB experience that suggests that these temporary 'MIB roots' stick around way longer than originally anticipated. > Thanks, > Phil > Andy From andy@netconfcentral.com Wed Jul 29 18:00:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0673A67BE for ; Wed, 29 Jul 2009 18:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 3ZGsfmJ5EiVz for ; Wed, 29 Jul 2009 18:00:13 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id 0A4893A66B4 for ; Wed, 29 Jul 2009 18:00:12 -0700 (PDT) Received: from [68.142.200.227] by n13.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 01:00:13 -0000 Received: from [68.142.201.250] by t8.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 01:00:13 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 01:00:13 -0000 X-Yahoo-Newman-Id: 51066.89681.bm@omp411.mail.mud.yahoo.com Received: (qmail 35495 invoked from network); 30 Jul 2009 01:00:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 01:00:12 -0000 X-YMail-OSG: f2BCOHoVM1lSfS01ITftPn1tvTViY6Q.JW3t25oL9wsLsch73n1tjHdFhG4xr.t19_XX7n3PC9HJYA8uJymByw8C8EMF.J7UZutJ2Q7_JHDcu7QyFxi9gBl72uGMZAhX7XmJrbT8xW1Ip0WyeOakXtVETlz8IG.__ocBcUR8z1XMt4exStdjqacJzVLEbMUCY5u8fXGr2N9oAzYzjxIWhtPhF2cN0ay1nu6ood1rq9_N6IY.aBH8NIPKYXFAyzbkfMaTnnLvjpRpHW7RCuTCLTDI_INGj7WmS8mga2QlZBG8.jlyxw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70F09E.1040806@netconfcentral.com> Date: Wed, 29 Jul 2009 18:00:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907300012.n6U0CvH2039381@idle.juniper.net> In-Reply-To: <200907300012.n6U0CvH2039381@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 01:00:13 -0000 Phil Shafer wrote: > Andy Bierman writes: >> module foo { >> // note to IANA: replace this string with real namespace URI >> namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; > > file:// seems bad. Consider instead a URN-based approach: > Why does the 'file' scheme seem bad? It is clearly not an IANA-controlled scheme, so it will not cause confusion with the real URI assigned by IANA. > namespace unn:ietf:params:xml:ns:yang:draft:-.txt > > This is consisent with the namespaces of NETCONF and YANG. > > Thanks, > Phil > Andy From phil@juniper.net Wed Jul 29 20:12:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6563A6AEA for ; Wed, 29 Jul 2009 20:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 A8NEkF4V7fj8 for ; Wed, 29 Jul 2009 20:12:18 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 761F73A67B2 for ; Wed, 29 Jul 2009 20:12:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSnEPkmcatBd2Ix36ry3o/0JlNPQQ8o3U@postini.com; Wed, 29 Jul 2009 20:12:20 PDT 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.375.2; Wed, 29 Jul 2009 20:03:55 -0700 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, 29 Jul 2009 20:03:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 20:03:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 20:03:54 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6U33rd59733; Wed, 29 Jul 2009 20:03:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6U2qO0Y040215; Thu, 30 Jul 2009 02:52:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907300252.n6U2qO0Y040215@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A70EEC8.2080809@netconfcentral.com> Date: Wed, 29 Jul 2009 22:52:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 03:03:54.0218 (UTC) FILETIME=[5F4ECCA0:01CA10C2] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 03:12:19 -0000 Andy Bierman writes: >> namespace unn:ietf:params:xml:ns:yang:draft:-.txt >IMO this is too consistent. >It looks very close to the real one that will be assigned later. >It looks like we need to get IANA approval for the temporary namespace. We can ask them to delegate the leading string to drafts. >We have some MIB experience that suggests that these temporary 'MIB roots' >stick around way longer than originally anticipated. Well, that's to be expected, right? If I implement a draft in JUNOS, I will be shipping support for it for a long long time. When the final rfc appears, I'll add that. Customer disapprove when ou remove things that used to work, even when they know they are drafts. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Jul 29 22:39:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9243A6AA0 for ; Wed, 29 Jul 2009 22:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Soactu9gc5PP for ; Wed, 29 Jul 2009 22:39:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 16A2F3A680A for ; Wed, 29 Jul 2009 22:39:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65BE8C0028; Thu, 30 Jul 2009 07:39:30 +0200 (CEST) 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 KmU4PcMbV4OD; Thu, 30 Jul 2009 07:39:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B96AC0024; Thu, 30 Jul 2009 07:39:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 15399B71720; Thu, 30 Jul 2009 07:39:29 +0200 (CEST) Date: Thu, 30 Jul 2009 07:39:29 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090730053929.GA15264@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907300012.n6U0CvH2039381@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 05:39:30 -0000 On Thu, Jul 30, 2009 at 02:12:56AM +0200, Phil Shafer wrote: > Andy Bierman writes: > > module foo { > > // note to IANA: replace this string with real namespace URI > > namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; > > file:// seems bad. Consider instead a URN-based approach: > > namespace unn:ietf:params:xml:ns:yang:draft:-.txt > > This is consisent with the namespaces of NETCONF and YANG. Two little improvements and a bug fix: a) s/.txt// b) s/draft/DRAFT/ c) s/unn/urn ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Jul 29 22:46:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68533A6A8F for ; Wed, 29 Jul 2009 22:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_74=0.6, J_CHICKENPOX_84=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 kEmOMH7nw1mW for ; Wed, 29 Jul 2009 22:46:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B52243A693F for ; Wed, 29 Jul 2009 22:46:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 612E0C00B7; Thu, 30 Jul 2009 07:46:02 +0200 (CEST) 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 C00LWQvaHK6c; Thu, 30 Jul 2009 07:46:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC244C0024; Thu, 30 Jul 2009 07:46:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D612AB71786; Thu, 30 Jul 2009 07:46:01 +0200 (CEST) Date: Thu, 30 Jul 2009 07:46:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090730054601.GB15264@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4A70E199.9000708@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A70E199.9000708@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: template.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 05:46:02 -0000 On Thu, Jul 30, 2009 at 01:56:09AM +0200, Andy Bierman wrote: > Would it be better to pick some simple example like TOASTER-MIB, > maybe blender.yang (any suggestions?) than complex examples (like ipfix), > or junk names and data structures (like foo and goo)? > > IMO, something like blender.yang might be best to explain some > of the guidelines. Should I reuse toaster? Any other simple > appliances that would make a good template? You would need something that has sufficient configuration knobs; perhaps an espresso machine is a better target (some of the high-end espresso machines really would benefit from being NETCONF enabled). It also makes it clear that SNMP was good enough for toasters while NETCONF can easily deal with an espresso machine. ;-) /js (who needs some coffee now) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Thu Jul 30 02:34:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4653228C276 for ; Thu, 30 Jul 2009 02:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 A7x119dQxzsO for ; Thu, 30 Jul 2009 02:34:29 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 8B1C828C17B for ; Thu, 30 Jul 2009 02:34:17 -0700 (PDT) Received: from [68.142.200.225] by n14.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 09:34:17 -0000 Received: from [68.142.201.245] by t6.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 09:34:17 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 09:34:17 -0000 X-Yahoo-Newman-Id: 809932.43914.bm@omp406.mail.mud.yahoo.com Received: (qmail 34013 invoked from network); 30 Jul 2009 09:34:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 09:34:16 -0000 X-YMail-OSG: absfVoMVM1lciObXubR6i9T2NKy68oJPLP1J7iI5TSNbW5b6_8Yaz_ldhjtMyttuAXO3cCO1Rqa3rvXUhryMZGwtvXE5LszVlkwgXWpYWeDvCH7TYcis22YDEnBJw.YAZ1Jz9ie0dHy_RP4OnP1pkj1kUHdl4qZreaWgP8CkTGVO5Y1M0EmMr2STyPDi5UEqhdX5cFlTDpQuD4j6SvWM.TloAq2NiWnb3xi35d3TEaGPzvcwu5VrLlZDr1Wx_wELyYVPmxtzCeeaKw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71691C.5000808@netconfcentral.com> Date: Thu, 30 Jul 2009 02:34:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer , Andy Bierman , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> In-Reply-To: <20090730053929.GA15264@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 09:34:30 -0000 Juergen Schoenwaelder wrote: > On Thu, Jul 30, 2009 at 02:12:56AM +0200, Phil Shafer wrote: >> Andy Bierman writes: >>> module foo { >>> // note to IANA: replace this string with real namespace URI >>> namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; >> file:// seems bad. Consider instead a URN-based approach: >> >> namespace unn:ietf:params:xml:ns:yang:draft:-.txt >> >> This is consisent with the namespaces of NETCONF and YANG. > > Two little improvements and a bug fix: > > a) s/.txt// > > b) s/draft/DRAFT/ > > c) s/unn/urn ;-) > the problem with these cryptic strings is that it is so easy to get them wrong. 3 bugs on the first try? I'm not impressed, but if this is the string people want to hunt down in existing drafts and cut-and-paste for years to come, then fine. > /js > Andy From lhotka@cesnet.cz Thu Jul 30 02:50:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931283A68B3 for ; Thu, 30 Jul 2009 02:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Yv3ApimlhRKv for ; Thu, 30 Jul 2009 02:50:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 843E63A6814 for ; Thu, 30 Jul 2009 02:50:09 -0700 (PDT) Received: from [130.129.20.168] (dhcp-14a8.meeting.ietf.org [130.129.20.168]) by office2.cesnet.cz (Postfix) with ESMTP id F0BB4D800C5; Thu, 30 Jul 2009 11:50:09 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A7061A6.6050903@netconfcentral.com> References: <4A7061A6.6050903@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 30 Jul 2009 11:50:07 +0200 Message-Id: <1248947407.5754.24.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Thu, 30 Jul 2009 09:50:10 -0000 Andy Bierman píše v St 29. 07. 2009 v 07:50 -0700: > Hi, > > I created 2 test modules (see attached) to see how > yangdump would deal with it. > > Since the grouping 'ggg' is not actually used in module testfoo1, > it does not cause any errors or even warnings. > > The error shows up via the uses-stmt in the testfoo2 module. > (Note the bug -- line number, line position (12.10) > is from testfoo1.yang file, not the testfoo2.yang > module that is currently being parsed. Not sure how to report > this, since there is no error in testfoo1.yang: > > Error: Module for prefix 'foo' not found > testfoo2.yang:12.10: error(228): invalid name > > *** /home/andy/modules/test/testfoo2.yang: 1 Errors, 0 Warnings Can you trace down why the program thinks it's an error? I presume prefixed names of types appearing inside a grouping in an imported module are OK. Prefixed names in XPath expressions should be handled the same way. > > I don't really understand the current solution proposal. > Maybe somebody can write it down in sufficient detail > so I know for every possible usage of a prefix, or usage > of a QName identifier that does not have a prefix, and all > the special ways a YANG complier is supposed to interpret > the same syntax in various contexts. Yes, this is necessary, I think we can do it together with Martin. Lada > > I am concerned that groupings may be too fragile for reasonable > usage by people other than the standards writers. Will a normal > engineer or operator study the 113 page YANG RFC thoroughly enough to > avoid making mistakes with groupings? Is there sufficiently low > localized cost across all language features, > or is the overall complexity too high, in order to support > some corner-case features? (I'm just asking, who knows...) > > > Andy > > > > > > > > > > > Prostý textový dokument příloha (testfoo1.yang) > module testfoo1 { > > namespace "http://example.net/testfoo1"; > prefix "foo"; > > revision 2009-07-28 { > description "Initial revision."; > } > > grouping ggg { > container test-top { > must "foo:bar < 42"; > leaf bar { type uint8; } > } > } > > } > Prostý textový dokument příloha (testfoo2.yang) > module testfoo2 { > > namespace "http://example.net/testfoo2"; > prefix "foo2"; > > import testfoo1 { prefix foo1; } > > revision 2009-07-28 { > description "Initial revision."; > } > > container one { > uses foo1:ggg; > } > } > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Jul 30 03:35:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6C63A69AD for ; Thu, 30 Jul 2009 03:35:17 -0700 (PDT) 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.047, 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 1RhB0ZLThHKD for ; Thu, 30 Jul 2009 03:35:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E361B3A6908 for ; Thu, 30 Jul 2009 03:35:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAC92C00B8; Thu, 30 Jul 2009 12:35:17 +0200 (CEST) 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 I08EupoOnfUt; Thu, 30 Jul 2009 12:35:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C955C002B; Thu, 30 Jul 2009 12:35:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6820BB71F86; Thu, 30 Jul 2009 12:35:16 +0200 (CEST) Date: Thu, 30 Jul 2009 12:35:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090730103516.GB16076@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A71691C.5000808@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 10:35:17 -0000 On Thu, Jul 30, 2009 at 11:34:20AM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jul 30, 2009 at 02:12:56AM +0200, Phil Shafer wrote: > >> Andy Bierman writes: > >>> module foo { > >>> // note to IANA: replace this string with real namespace URI > >>> namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; > >> file:// seems bad. Consider instead a URN-based approach: > >> > >> namespace unn:ietf:params:xml:ns:yang:draft:-.txt > >> > >> This is consisent with the namespaces of NETCONF and YANG. > > > > Two little improvements and a bug fix: > > > > a) s/.txt// > > > > b) s/draft/DRAFT/ > > > > c) s/unn/urn ;-) > > > > the problem with these cryptic strings is that it is > so easy to get them wrong. 3 bugs on the first try? > I'm not impressed, but if this is the string people want to > hunt down in existing drafts and cut-and-paste for years to come, > then fine. I guess not every YANG module will be written in the middle of the night on a Wednesday evening at an IETF week. I think Phil was doing actually quite well. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Thu Jul 30 11:45:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63A43A682F for ; Thu, 30 Jul 2009 11:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 00D3efhP5R-4 for ; Thu, 30 Jul 2009 11:45:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 111C53A6782 for ; Thu, 30 Jul 2009 11:45:44 -0700 (PDT) Received: from [10.43.1.135] (unknown [77.241.97.148]) by office2.cesnet.cz (Postfix) with ESMTP id 4C06BD800BD for ; Thu, 30 Jul 2009 20:45:45 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Thu, 30 Jul 2009 20:45:41 +0200 Message-Id: <1248979541.14222.26.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] mandatory mess 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: , X-List-Received-Date: Thu, 30 Jul 2009 18:45:44 -0000 Hi, earlier today, when I was compiling the minutes from yesterday's meeting, I realized I was still very confused about the notion of "mandatory". Yes, the draft says: o If no such ancestor [which is not a non-presence container] exists, the leaf MUST exist. So the next question is: Where MUST it exist? And the answer is, I suppose: In the configuration datastore. However, at least one interpretation of datastore content claims that a datastore only contains data that were explicitly set by the client. So one has to come to the conclusion in this case that a mandatory node has to be set by the client in order to get into the datastore and thus cannot be supplied by the server in an "initial factory setting". I believe this is exactly what Andy asked about on Jabber yesterday but didn't get any satisfactory answer, AFAIK. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jul 30 11:50:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882EE3A6BE0 for ; Thu, 30 Jul 2009 11:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, 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 9piZa6V+myKh for ; Thu, 30 Jul 2009 11:50:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B01993A6B2B for ; Thu, 30 Jul 2009 11:49:30 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 698EC76C54A; Thu, 30 Jul 2009 20:49:31 +0200 (CEST) Date: Thu, 30 Jul 2009 20:49:31 +0200 (CEST) Message-Id: <20090730.204931.150474104.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1248979541.14222.26.camel@nomad> References: <1248979541.14222.26.camel@nomad> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] mandatory mess 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: , X-List-Received-Date: Thu, 30 Jul 2009 18:50:12 -0000 Ladislav Lhotka wrote: > Hi, > > earlier today, when I was compiling the minutes from yesterday's > meeting, I realized I was still very confused about the notion of > "mandatory". Yes, the draft says: > > o If no such ancestor [which is not a non-presence container] exists, > the leaf MUST exist. > > So the next question is: Where MUST it exist? And the answer is, I > suppose: In the configuration datastore. However, at least one > interpretation of datastore content claims that a datastore only > contains data that were explicitly set by the client. Can you provide a reference to this text? I search for "client" and "explicit" but did not find anything. /martin From j.schoenwaelder@jacobs-university.de Thu Jul 30 11:55:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51C43A71A9 for ; Thu, 30 Jul 2009 11:55:12 -0700 (PDT) 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.046, 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 YsEA6e2eyBG5 for ; Thu, 30 Jul 2009 11:55:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 39BA23A6BF8 for ; Thu, 30 Jul 2009 11:55:01 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 675DEC00CE; Thu, 30 Jul 2009 20:55:02 +0200 (CEST) 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 bOewfuJ7Tucc; Thu, 30 Jul 2009 20:55:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 443C7C00CA; Thu, 30 Jul 2009 20:55:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DDB4AB728DC; Thu, 30 Jul 2009 20:55:00 +0200 (CEST) Date: Thu, 30 Jul 2009 20:55:00 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090730185500.GA16690@elstar.local> Mail-Followup-To: Phil Shafer , Mark Ellison , "netmod@ietf.org" References: <20090729130300.GA14369@elstar.local> <200907291440.n6TEeYvY036427@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907291440.n6TEeYvY036427@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 18:55:12 -0000 On Wed, Jul 29, 2009 at 04:40:34PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >There is an offset - so I can configure +02:00 but the box will return > >the configure value back to me in UTC. > > I thought UTC means the offset returned will always be "+0:00". Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Thu Jul 30 12:04:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCED3A6C8A for ; Thu, 30 Jul 2009 12:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 EnEsmAhrhQi9 for ; Thu, 30 Jul 2009 12:04:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C4D3A3A71DF for ; Thu, 30 Jul 2009 12:03:54 -0700 (PDT) Received: from [10.43.1.135] (unknown [77.241.97.148]) by office2.cesnet.cz (Postfix) with ESMTP id 7E718D800BD; Thu, 30 Jul 2009 21:03:55 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090730.204931.150474104.mbj@tail-f.com> References: <1248979541.14222.26.camel@nomad> <20090730.204931.150474104.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 30 Jul 2009 21:03:52 +0200 Message-Id: <1248980632.14222.35.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] mandatory mess 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: , X-List-Received-Date: Thu, 30 Jul 2009 19:04:16 -0000 Martin Bjorklund píše v Čt 30. 07. 2009 v 20:49 +0200: > Can you provide a reference to this text? I search for "client" and > "explicit" but did not find anything. > 4741bis: "A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state." Doesn't this imply that the contents of the "initial default state" are not in the configuration datastore? If "desired operational state" is identical to "initial default state" does it mean that the configuration datastore is empty? YANG draft doesn't define what a datastore is (it should, in my opinion). Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Jul 30 12:04:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD4E3A6BE0 for ; Thu, 30 Jul 2009 12:04:16 -0700 (PDT) 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.045, 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 jqXUNYJ3HuY1 for ; Thu, 30 Jul 2009 12:04:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDEAC3A6CCE for ; Thu, 30 Jul 2009 12:03:45 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DE78C00CB; Thu, 30 Jul 2009 21:03:47 +0200 (CEST) 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 9-7G-67U24E2; Thu, 30 Jul 2009 21:03:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5442DC00CA; Thu, 30 Jul 2009 21:03:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 394C5B72947; Thu, 30 Jul 2009 21:03:46 +0200 (CEST) Date: Thu, 30 Jul 2009 21:03:46 +0200 From: Juergen Schoenwaelder To: Mark Ellison Message-ID: <20090730190346.GB16690@elstar.local> Mail-Followup-To: Mark Ellison , Andy Bierman , "netmod@ietf.org" References: <200907291440.n6TEeYvY036427@idle.juniper.net> <4A706835.5020409@netconfcentral.com> <8a0268750907291401v58d1cf57k1a669186f9b0ab9e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a0268750907291401v58d1cf57k1a669186f9b0ab9e@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue 2 - data-and-time canonicalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 19:04:16 -0000 On Wed, Jul 29, 2009 at 11:01:30PM +0200, Mark Ellison wrote: > I can see something like this to config/initialize the current time > on a device...but alternatively I can see some devices using an NTP > server instead for this information and that would be a different > set of config leaves. NTP does not tell a device which time zone it is in - how should an NTP server know. When you unpack a computer, you once have to say which time zone you are in - there is no way around this. So there should be a standard object to configure the time zone. And yes, it would be cool to have standard objects to configure NTP and a standard operation to set the time (I am saying operation since the current time clearly is not config data). We will sooner or later need a core data model - also standard operations to reboot/shutdown a device would be cool to have as these are the most basic operations you operationally need. But we first need to get YANG out of the door and this includes agreement on the date-and-time canonicalization. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jul 30 12:20:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713C63A7219 for ; Thu, 30 Jul 2009 12:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, 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 zTQ1gkKj3XjW for ; Thu, 30 Jul 2009 12:20:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 52DE53A6C9C for ; Thu, 30 Jul 2009 12:20:19 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CF2A176C54A; Thu, 30 Jul 2009 21:20:20 +0200 (CEST) Date: Thu, 30 Jul 2009 21:20:20 +0200 (CEST) Message-Id: <20090730.212020.11711141.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1248980632.14222.35.camel@nomad> References: <1248979541.14222.26.camel@nomad> <20090730.204931.150474104.mbj@tail-f.com> <1248980632.14222.35.camel@nomad> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] mandatory mess 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: , X-List-Received-Date: Thu, 30 Jul 2009 19:20:20 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMzAuIDA3LiAyMDA5IHYgMjA6NDkgKzAyMDA6DQo+IA0KPiA+IENh biB5b3UgcHJvdmlkZSBhIHJlZmVyZW5jZSB0byB0aGlzIHRleHQ/ICBJIHNlYXJjaCBmb3IgImNs aWVudCIgYW5kDQo+ID4gImV4cGxpY2l0IiBidXQgZGlkIG5vdCBmaW5kIGFueXRoaW5nLg0KPiA+ IA0KPiANCj4gNDc0MWJpczogIkEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgaXMgZGVmaW5lZCBh cyB0aGUgY29tcGxldGUgc2V0IG9mDQo+IGNvbmZpZ3VyYXRpb24gZGF0YSB0aGF0IGlzIHJlcXVp cmVkIHRvIGdldCBhIGRldmljZSBmcm9tIGl0cyBpbml0aWFsDQo+IGRlZmF1bHQgc3RhdGUgaW50 byBhIGRlc2lyZWQgb3BlcmF0aW9uYWwgc3RhdGUuIg0KDQpUaGUgdGV4dCBhYm92ZSBpcyBmcm9t IDUuMS4NCg0KS2luZCBvZiBmdW5ueSAtIGlmIHlvdSB3b25kZXIgd2hhdCAiY29uZmlndXJhdGlv biBkYXRhIiBtZWFucyBpbiB0aGUNCnRleHQgYWJvdmUsIDQ3NDEgcHJvdmlkZXMgYSBkZWZpbml0 aW9uIGluIHNlY3Rpb24gMS4zOg0KDQogICBDb25maWd1cmF0aW9uIGRhdGEgaXMgdGhlIHNldCBv ZiB3cml0YWJsZSBkYXRhIHRoYXQgaXMgcmVxdWlyZWQgdG8NCiAgIHRyYW5zZm9ybSBhIHN5c3Rl bSBmcm9tIGl0cyBpbml0aWFsIGRlZmF1bHQgc3RhdGUgaW50byBpdHMgY3VycmVudA0KICAgc3Rh dGUuIA0KDQpJIGd1ZXNzIHdlIGNhbiBhZGQgdG8gb3VyIGlzc3VlcyBsaXN0IHRoYXQgd2Ugc2hv dWxkIGNsZWFuIHRoaXMgdXAuDQoNCg0KL21hcnRpbg0K From lhotka@cesnet.cz Thu Jul 30 12:41:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F723A71B1 for ; Thu, 30 Jul 2009 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 BumdvIAj06C4 for ; Thu, 30 Jul 2009 12:41:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DDB7A3A6C59 for ; Thu, 30 Jul 2009 12:41:08 -0700 (PDT) Received: from [10.43.1.135] (unknown [77.241.97.148]) by office2.cesnet.cz (Postfix) with ESMTP id 4831FD800BD; Thu, 30 Jul 2009 21:41:07 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090730.212020.11711141.mbj@tail-f.com> References: <1248979541.14222.26.camel@nomad> <20090730.204931.150474104.mbj@tail-f.com> <1248980632.14222.35.camel@nomad> <20090730.212020.11711141.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 30 Jul 2009 21:41:05 +0200 Message-Id: <1248982865.14222.66.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] mandatory mess 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: , X-List-Received-Date: Thu, 30 Jul 2009 19:41:09 -0000 Martin Bjorklund píše v Čt 30. 07. 2009 v 21:20 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Čt 30. 07. 2009 v 20:49 +0200: > > > > > Can you provide a reference to this text? I search for "client" and > > > "explicit" but did not find anything. > > > > > > > 4741bis: "A configuration datastore is defined as the complete set of > > configuration data that is required to get a device from its initial > > default state into a desired operational state." > > The text above is from 5.1. > > Kind of funny - if you wonder what "configuration data" means in the > text above, 4741 provides a definition in section 1.3: > > Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state. OK, but still the same: configuration data are the complement of the initial default state. I suspect in most cases the mandatory configuration data that are initially supplied by the device actually represent the initial default state. Lada > > I guess we can add to our issues list that we should clean this up. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jul 30 12:48:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4E13A6B61 for ; Thu, 30 Jul 2009 12:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, 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 rs7-iyp1QeHP for ; Thu, 30 Jul 2009 12:47:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6EDFF3A6B1F for ; Thu, 30 Jul 2009 12:47:59 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E88B776C54A; Thu, 30 Jul 2009 21:48:00 +0200 (CEST) Date: Thu, 30 Jul 2009 21:48:00 +0200 (CEST) Message-Id: <20090730.214800.216128611.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <006d01ca0ba1$bc1344a0$0601a8c0@allison> References: <4A65EC7A.1060008@ericsson.com> <20090722.000948.206458951.mbj@tail-f.com> <006d01ca0ba1$bc1344a0$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-ietf-netmod-yang-07.txt 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: , X-List-Received-Date: Thu, 30 Jul 2009 19:48:00 -0000 Hi, Sorry for the late reply on this. "tom.petch" wrote: > Martin > > Some wordings that have bugged me for a while. > > 5.1 ..."by using the enterprise or organization name as a prefix." > Do you really mean prefix? only I think of prefix as shorthand and while IBM, > Cisco or HP might qualify, other organization names would not. The text you quoted is preceeded by an "e.g." -- this is just a friendly suggestion. If it is better, I can remove the quoted text. > 5.5 .."searches up the levels of hierarchy in the schema tree" > levels of hierarchy has a suggestion of all the nodes at a level whereas I > think > that this means search the path to the root. Me, Phil and Lada came up with this replacement text: OLD: When a YANG implementation resolves a reference to an unprefixed type or grouping, or one which uses the prefix of the local module, it searches up the levels of hierarchy in the schema tree, starting at the current level, for the definition of the type or grouping. NEW: A reference to an unprefixed type or grouping, or one which uses the prefix of the current module, is resolved by locating the closest matching "typedef" or "grouping" statement among the immediate substatments of each ancestor statement. > 6 " YANG modules are written in the UTF-8 [RFC3629] character set." > > UTF-8 is not a character set in the lexicons I use; character encoding, > transfer format, character syntax but not character set. NEW: YANG modules use the UTF-8 [RFC3629] character encoding. > 6.1.3 "up to at most the column of the double quote character." > seems imprecise, leaving the option of everything up to or some way short of or > whatever an implementation chooses How about this: If the double quoted string contains a line break followed by space or tab characters which is used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the string, up to the column of the double quote character, or to the first non-whitespace character, whichever occurs first. > 6.2.1 "All groupings defined within a parent node " > well no, grouping names, otherwise it sounds like the identifiers defined > within > the grouping. Fixed. > 7.1.3 "with the exception of data node identifiers defined inside a grouping " > well, only when they are 'uses'd in another module; needs adding IMO It says See section 7.12 for details. We have rewritten this section to: 7.12. The uses Statement The "uses" statement is used to reference a "grouping" definition. It takes one argument, which is the name of the grouping. The effect of a "uses" reference to a grouping is that the nodes defined by the grouping are copied into the current schema tree, and then updated according to the refinement and augment statements. The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, a which point they are bound to the namespace of the current module. > 9.9.2 "Predicates are used only for constraining the values for the > key nodes for list entries" > or leaflists? Fixed. /martin From andy@netconfcentral.com Thu Jul 30 13:20:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D7F3A6D19 for ; Thu, 30 Jul 2009 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 B8o-G4UnZ5dy for ; Thu, 30 Jul 2009 13:20:53 -0700 (PDT) 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 6B7E83A6D16 for ; Thu, 30 Jul 2009 13:20:53 -0700 (PDT) Received: (qmail 41966 invoked from network); 30 Jul 2009 20:20:52 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 20:20:52 -0000 X-YMail-OSG: evf6yvQVM1nm3rzAhRtT.4XLM3dJBn3js08l.nESBxSk_m5OxUIjh4ICIFxVPyCo9YIOFUFBquXzeW1kKQD55bIFtvfRzYRzMvbwU1Al6CF2HOjnOqJjoZlhGq4caYf_iY2JoF.qoHFyIkWVHkGLRUUxUTVxVODhuhKY01VcQTxNi5R5hwTe1WjajExZgl18gu0yKOreOtjlSVM0VaMSeJhJavRgYtiIDrNzvqvOT5IZUSujMEJfFhyZi._Vvj_wDq3Aiwz7rlWEqGlYAyE9HPtPdypo.B2CIDQIP8LYtPyUaUQzkF80ox1pjPfhRoXLbN1tABntXEKOfUF76pR2_w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7200AB.9030905@netconfcentral.com> Date: Thu, 30 Jul 2009 13:20:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A7061A6.6050903@netconfcentral.com> <1248947407.5754.24.camel@nomad> In-Reply-To: <1248947407.5754.24.camel@nomad> Content-Type: multipart/mixed; boundary="------------050700000504090301050804" Cc: NETMOD Working Group Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Thu, 30 Jul 2009 20:20:54 -0000 This is a multi-part message in MIME format. --------------050700000504090301050804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ladislav Lhotka wrote: > Andy Bierman píše v St 29. 07. 2009 v 07:50 -0700: >> Hi, >> >> I created 2 test modules (see attached) to see how >> yangdump would deal with it. >> >> Since the grouping 'ggg' is not actually used in module testfoo1, >> it does not cause any errors or even warnings. >> >> The error shows up via the uses-stmt in the testfoo2 module. >> (Note the bug -- line number, line position (12.10) >> is from testfoo1.yang file, not the testfoo2.yang >> module that is currently being parsed. Not sure how to report >> this, since there is no error in testfoo1.yang: >> >> Error: Module for prefix 'foo' not found >> testfoo2.yang:12.10: error(228): invalid name >> >> *** /home/andy/modules/test/testfoo2.yang: 1 Errors, 0 Warnings > > Can you trace down why the program thinks it's an error? I presume > prefixed names of types appearing inside a grouping in an imported > module are OK. Prefixed names in XPath expressions should be handled the > same way. > >> I don't really understand the current solution proposal. >> Maybe somebody can write it down in sufficient detail >> so I know for every possible usage of a prefix, or usage >> of a QName identifier that does not have a prefix, and all >> the special ways a YANG complier is supposed to interpret >> the same syntax in various contexts. > > Yes, this is necessary, I think we can do it together with Martin. > I updated my example to show some of the ambiguities that need to be cleared up. It would be nice if there was a simple consistent rule that applied to all statements, inside or outside a grouping, and regardless of which module contains the uses-stmt. > Lada Andy --------------050700000504090301050804 Content-Type: text/plain; name="testfoo1.yang" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="testfoo1.yang" bW9kdWxlIHRlc3Rmb28xIHsKCiAgICBuYW1lc3BhY2UgImh0dHA6Ly9leGFtcGxlLm5ldC90 ZXN0Zm9vMSI7CiAgICBwcmVmaXggImZvbyI7CgogICAgcmV2aXNpb24gMjAwOS0wNy0yOCB7 CiAgICAgICAgZGVzY3JpcHRpb24gIkluaXRpYWwgcmV2aXNpb24uIjsKICAgIH0KCiAgICB0 eXBlZGVmIE15VHlwZSB7CiAgICAgICB0eXBlIGludDMyOwogICAgfQoKICAgIGlkZW50aXR5 IE15QmFzZTsKCiAgICBpZGVudGl0eSBteS1pZGVudGl0eSB7CiAgICAgICBiYXNlIE15QmFz ZTsKICAgIH0KCiAgICBncm91cGluZyBnZ2cgewogICAgICAgY29udGFpbmVyIHRlc3QtdG9w IHsKICAgICAgICAgbXVzdCAiZm9vOmJhciA8IDQyIjsKICAgICAgICAgbGVhZiBiYXIgeyB0 eXBlIHVpbnQ4OyB9CiAgICAgICAgIGxlYWYgYmF6IHsgCiAgICAgICAgICAgICBtdXN0ICIu Li9nb28gPSAnbXktaWRlbnRpdHknIjsKICAgICAgICAgICAgIHR5cGUgTXlUeXBlOwogICAg ICAgICB9CiAgICAgICAgIGxlYWYgZ29vIHsgCiAgICAgICAgICAgIHR5cGUgaWRlbnRpdHly ZWYgewogICAgICAgICAgICAgICBiYXNlIE15QmFzZTsKICAgICAgICAgICAgfQogICAgICAg ICAgICBkZWZhdWx0IG15LWlkZW50aXR5OwogICAgICAgICB9CiAgICAgIH0KICAgfQoKfQo= --------------050700000504090301050804 Content-Type: text/plain; name="testfoo2.yang" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="testfoo2.yang" bW9kdWxlIHRlc3Rmb28yIHsKCiAgICBuYW1lc3BhY2UgImh0dHA6Ly9leGFtcGxlLm5ldC90 ZXN0Zm9vMiI7CiAgICBwcmVmaXggImZvbzIiOwoKICAgIGltcG9ydCB0ZXN0Zm9vMSB7IHBy ZWZpeCBmb28xOyB9CgogICAgcmV2aXNpb24gMjAwOS0wNy0yOCB7CiAgICAgICAgZGVzY3Jp cHRpb24gIkluaXRpYWwgcmV2aXNpb24uIjsKICAgIH0KCiAgICB0eXBlZGVmIE15VHlwZSB7 CiAgICAgICB0eXBlIGJvb2xlYW47CiAgICB9CgogICAgaWRlbnRpdHkgbXktaWRlbnRpdHkg ewogICAgICAgYmFzZSBmb28xOk15QmFzZTsKICAgIH0KCiAgICBjb250YWluZXIgb25lIHsK ICAgICAgICB1c2VzIGZvbzE6Z2dnOwogICAgfQp9Cg== --------------050700000504090301050804-- From andy@netconfcentral.com Thu Jul 30 15:34:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602DA3A67F2 for ; Thu, 30 Jul 2009 15:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 4opOrkT0Or2v for ; Thu, 30 Jul 2009 15:34:30 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 69C1B3A6C9F for ; Thu, 30 Jul 2009 15:34:28 -0700 (PDT) Received: (qmail 7031 invoked from network); 30 Jul 2009 22:34:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2009 22:34:28 -0000 X-Yahoo-SMTP: lZEgoqiswBBhrbcScc4Il618oJqVFCyDBDjlTkMv3Go- X-YMail-OSG: M36LGK8VM1nIhqAZOImHsmOPHrL_Oj1RLwzbHeHdCzkyGdnhqQo90268qpp8y9ZWr9dpV7IkUsJ9jIUCOXdw7p.0R2oamPBtxST_pEKPFnxngzZnQcHHa_AQywFHihlFOyQn9IByW1oGhR8i2bcbVr.DwcNZARr.N8yDyKk1oOM9xf7CxfEpUUk8igWlmChbauomySkOEbRAG8CzuhTaUjR9wwTbvbMlAJBhnWt2N5N_7GQz9vtdCNt6bNKCeUt4Qk70cJFjZbl.fRpZkgnsGYbluhVncrdVdWUJ08B25W9Kf7oHdA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A721FFB.9090500@netconfcentral.com> Date: Thu, 30 Jul 2009 15:34:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> In-Reply-To: <20090730103516.GB16076@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 22:34:31 -0000 Juergen Schoenwaelder wrote: > On Thu, Jul 30, 2009 at 11:34:20AM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Jul 30, 2009 at 02:12:56AM +0200, Phil Shafer wrote: >>>> Andy Bierman writes: >>>>> module foo { >>>>> // note to IANA: replace this string with real namespace URI >>>>> namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang"; >>>> file:// seems bad. Consider instead a URN-based approach: >>>> >>>> namespace unn:ietf:params:xml:ns:yang:draft:-.txt >>>> >>>> This is consisent with the namespaces of NETCONF and YANG. >>> Two little improvements and a bug fix: >>> >>> a) s/.txt// >>> >>> b) s/draft/DRAFT/ >>> >>> c) s/unn/urn ;-) >>> >> the problem with these cryptic strings is that it is >> so easy to get them wrong. 3 bugs on the first try? >> I'm not impressed, but if this is the string people want to >> hunt down in existing drafts and cut-and-paste for years to come, >> then fine. > > I guess not every YANG module will be written in the middle of the > night on a Wednesday evening at an IETF week. I think Phil was doing > actually quite well. ;-) > OK, we have a winner: namespace urn:ietf:params:xml:ns:yang:DRAFT:- e.g.: namespace urn:ietf:params:xml:ns:yang:DRAFT:foo-03 namespace urn:ietf:params:xml:ns:yang:DRAFT:foo-04 namespace urn:ietf:params:xml:ns:yang:DRAFT:bar-00 Is the IANA request for a registry for temporary namespace URIs (so they are never reissued), along with the template for all registry entries, supposed to go in this Informational RFC? Or will the co-chairs make a separate request? Uh-oh, another detail: Should 'yang' really be 'netmod'? IMO, yes. The naming authority is the NETMOD WG, not the YANG language. namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-03 namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-04 namespace urn:ietf:params:xml:ns:netmod:DRAFT:bar-00 So what is a real YANG module URN supposed to look like? namespace urn:ietf:params:xml:ns:netmod:RFC5991:foo namespace urn:ietf:params:xml:ns:netmod:RFC6210:foo namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar Where is this registry and template defined? > /js > Andy From phil@juniper.net Thu Jul 30 16:42:33 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5701C3A70E3 for ; Thu, 30 Jul 2009 16:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 RKdb4asUoe3g for ; Thu, 30 Jul 2009 16:42:32 -0700 (PDT) Received: from chip3og56.obsmtp.com (chip3og56.obsmtp.com [64.18.14.177]) by core3.amsl.com (Postfix) with ESMTP id 7F6373A67FD for ; Thu, 30 Jul 2009 16:42:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob56.postini.com ([64.18.6.12]) with SMTP ID DSNKSnIv5Lk8Qe79R3iDpGtMnDqUZwRKP8pV@postini.com; Thu, 30 Jul 2009 16:42:33 PDT 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.375.2; Thu, 30 Jul 2009 16:40:05 -0700 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, 30 Jul 2009 16:40:06 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:40:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:40:04 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6UNe1d43958; Thu, 30 Jul 2009 16:40:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6UNSUHZ047860; Thu, 30 Jul 2009 23:28:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907302328.n6UNSUHZ047860@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A721FFB.9090500@netconfcentral.com> Date: Thu, 30 Jul 2009 19:28:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 23:40:04.0557 (UTC) FILETIME=[10465FD0:01CA116F] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Thu, 30 Jul 2009 23:42:33 -0000 Andy Bierman writes: >Uh-oh, another detail: Should 'yang' really be 'netmod'? IMO, yes. I'd rather stick with "yang". These are "yang" modules, not "metnod" nodules, and the naming authority isn't the NETMOD WG, since the modules will be defined in their appropriate WG, not in ours. > namespace urn:ietf:params:xml:ns:netmod:RFC5991:foo > namespace urn:ietf:params:xml:ns:netmod:RFC6210:foo > namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar s/RFC/rfc/ DRAFT is caps to catch your eye. Thanks, Phil From phil@juniper.net Thu Jul 30 16:48:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF1E3A6BD6 for ; Thu, 30 Jul 2009 16:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 zLoTQrtv-PHG for ; Thu, 30 Jul 2009 16:48:11 -0700 (PDT) Received: from chip3og50.obsmtp.com (chip3og50.obsmtp.com [64.18.14.165]) by core3.amsl.com (Postfix) with ESMTP id D70B63A6AD2 for ; Thu, 30 Jul 2009 16:48:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob50.postini.com ([64.18.6.12]) with SMTP ID DSNKSnIxOkp3wfOlG3mpNJYRJc3/ONeJizUa@postini.com; Thu, 30 Jul 2009 16:48:13 PDT 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.375.2; Thu, 30 Jul 2009 16:45:17 -0700 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, 30 Jul 2009 16:45:17 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:45:17 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:45:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6UNjGd46407; Thu, 30 Jul 2009 16:45:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n6UNXiI7047938; Thu, 30 Jul 2009 23:33:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907302333.n6UNXiI7047938@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1248979541.14222.26.camel@nomad> Date: Thu, 30 Jul 2009 19:33:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 23:45:16.0424 (UTC) FILETIME=[CA298080:01CA116F] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] mandatory mess 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: , X-List-Received-Date: Thu, 30 Jul 2009 23:48:11 -0000 Ladislav Lhotka writes: >So one has to come to the conclusion in this case that a mandatory node >has to be set by the client in order to get into the datastore and thus >cannot be supplied by the server in an "initial factory setting". I don't grok the hangup here, but perhaps if you view it this way it will help. On some boxes, when the startup mechanism notices that the configuration database is empty, a "local client application" is triggered that loads some factory default configuration into the configuration database. And this "local client" need not be a NETCONF client, it can be something as mundane as: [ -s $config ] || cp $factory_defaults $config Thanks, Phil From mbj@tail-f.com Fri Jul 31 07:55:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975B728C33F for ; Fri, 31 Jul 2009 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.286, 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 fTSRtxw6pRHI for ; Fri, 31 Jul 2009 07:55:00 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D34C228C334 for ; Fri, 31 Jul 2009 07:54:59 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A55076C5EE; Fri, 31 Jul 2009 16:54:59 +0200 (CEST) Date: Fri, 31 Jul 2009 16:54:59 +0200 (CEST) Message-Id: <20090731.165459.141345776.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A721FFB.9090500@netconfcentral.com> References: <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang usage: temporary URI issue 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: , X-List-Received-Date: Fri, 31 Jul 2009 14:55:00 -0000 Andy Bierman wrote: > So what is a real YANG module URN supposed to look like? > > namespace urn:ietf:params:xml:ns:netmod:RFC5991:foo > namespace urn:ietf:params:xml:ns:netmod:RFC6210:foo > namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar Do not put the rfc number there - we use the revision parameter to indicate revision. When the ipfix model version 2 is published with only minor corrections, we don't want to change its namespace URI and break old clients. I don't really understand why we need all the extra characters in this uri, when e.g. urn:ietf:yang:ietf-foo would be enough (since all ietf module names are unique). But I guess it would be too simple. People might even remember them :) /martin From mbj@tail-f.com Fri Jul 31 07:55:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D3F28C345 for ; Fri, 31 Jul 2009 07:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.268, 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 Xzvo6tv+b8MX for ; Fri, 31 Jul 2009 07:55:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EF0E628C336 for ; Fri, 31 Jul 2009 07:55:13 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 85E8176C5A0; Fri, 31 Jul 2009 16:55:15 +0200 (CEST) Date: Fri, 31 Jul 2009 16:55:15 +0200 (CEST) Message-Id: <20090731.165515.82188649.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7200AB.9030905@netconfcentral.com> References: <4A7061A6.6050903@netconfcentral.com> <1248947407.5754.24.camel@nomad> <4A7200AB.9030905@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 31 Jul 2009 14:55:14 -0000 Andy Bierman wrote: > I updated my example to show some of the ambiguities > that need to be cleared up. > > It would be nice if there was a simple consistent rule > that applied to all statements, inside or outside a grouping, > and regardless of which module contains the uses-stmt. This is what we came up with: o The set of namespace declarations is the set of all "import" statements' prefix and namespace pairs in the module where the XPath expression is specified, and the "prefix" statement's prefix for the "namespace" statement's URI. This says that the prefix is bound to a namespace in the module where the must/when expression occurs. o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping that namespace is affected by where the grouping is used (see Section 7.12). And in section 7.12: The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, a which point they are bound to the namespace of the current module. /martin From mbj@tail-f.com Fri Jul 31 08:04:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856A928C373 for ; Fri, 31 Jul 2009 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.268, 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 gKBj3ng7KGNz for ; Fri, 31 Jul 2009 08:04:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E3D1928C377 for ; Fri, 31 Jul 2009 08:04:18 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 027BA76C5B7; Fri, 31 Jul 2009 16:54:52 +0200 (CEST) Date: Fri, 31 Jul 2009 11:47:28 +0200 (CEST) Message-Id: <20090731.114728.212391918.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7200AB.9030905@netconfcentral.com> References: <4A7061A6.6050903@netconfcentral.com> <1248947407.5754.24.camel@nomad> <4A7200AB.9030905@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 31 Jul 2009 15:04:37 -0000 Andy Bierman wrote: > I updated my example to show some of the ambiguities > that need to be cleared up. > > It would be nice if there was a simple consistent rule > that applied to all statements, inside or outside a grouping, > and regardless of which module contains the uses-stmt. This is what we came up with: o The set of namespace declarations is the set of all "import" statements' prefix and namespace pairs in the module where the XPath expression is specified, and the "prefix" statement's prefix for the "namespace" statement's URI. This says that the prefix is bound to a namespace in the module where the must/when expression occurs. o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping that namespace is affected by where the grouping is used (see Section 7.12). And in section 7.12: The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, a which point they are bound to the namespace of the current module. /martin From andy@netconfcentral.com Fri Jul 31 09:09:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D5428C333 for ; Fri, 31 Jul 2009 09:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 tcyKSZ-Wtw90 for ; Fri, 31 Jul 2009 09:09:39 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 7C80728C341 for ; Fri, 31 Jul 2009 09:09:18 -0700 (PDT) Received: (qmail 93933 invoked from network); 31 Jul 2009 16:09:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 31 Jul 2009 16:09:12 -0000 X-YMail-OSG: MuklKiIVM1nz49lA3LW45I2X.A2rQWeX1gGROtthf5xlt0sr3f.Ua_VaLFZ7yJ1w1TgqeMiv_2OZRhC1DgMWRnalJRTPAxGb9gx1yb1vgfBj4cL9_olGIdGTEWiKCRguh_F3zK8KPLtSXDgNjArPDD1SNwQpwKe.jxejqzRQ0WqIbH53e_qDDwgV0_GaOIBhV3zC7C0qaWV5IWNgqn8gxVf5xIn7KOqvKgLqn.mWgiFXViYVtHVnrdoArFUPtNGDFy2HC.qnDYzklNvJsdoTkW5jRBzjgxLn9sVij.9uwyYekOzEkXB.t00FMNYPpwqNMV_NrQp5JEU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7316BA.5090308@netconfcentral.com> Date: Fri, 31 Jul 2009 09:07:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7061A6.6050903@netconfcentral.com> <1248947407.5754.24.camel@nomad> <4A7200AB.9030905@netconfcentral.com> <20090731.114728.212391918.mbj@tail-f.com> In-Reply-To: <20090731.114728.212391918.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 31 Jul 2009 16:09:40 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I updated my example to show some of the ambiguities >> that need to be cleared up. >> >> It would be nice if there was a simple consistent rule >> that applied to all statements, inside or outside a grouping, >> and regardless of which module contains the uses-stmt. > > This is what we came up with: > > o The set of namespace declarations is the set of all "import" > statements' prefix and namespace pairs in the module where the > XPath expression is specified, and the "prefix" statement's prefix > for the "namespace" statement's URI. > > This says that the prefix is bound to a namespace in the module where > the must/when expression occurs. > > o Names without a namespace prefix belong to the same namespace as > the identifier of the current node. Inside a grouping that > namespace is affected by where the grouping is used (see > Section 7.12). > > And in section 7.12: > > The identifiers defined in the grouping are not bound to a namespace > until the contents of the grouping are added to the schema tree via a > "uses" statement that does not appear inside a "grouping" statement, > a which point they are bound to the namespace of the current module. > This text does not fully address the example I posted (footest2.yang). The problem is more complicated than just must/when expressions. If the local prefix is not used (the normal use-case), then the module with the uses-stmt will be used to find identities and types, and resolve the default-stmt. This is broken. So the rule is very simple. I think I heard Lada mention this over the audio feed. For every QName referenced within the grouping: - the prefix MUST be used if the definition is outside the grouping - the prefix SHOULD NOT be used if the definition is inside the grouping (the exception is when the author really intends to force the grouping to be used within one module namespace.) > > /martin > Andy From andy@netconfcentral.com Fri Jul 31 09:31:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541B33A68E2 for ; Fri, 31 Jul 2009 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 jOQ8Ikgumz1r for ; Fri, 31 Jul 2009 09:30:59 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 91E0F3A6807 for ; Fri, 31 Jul 2009 09:30:59 -0700 (PDT) Received: (qmail 88110 invoked from network); 31 Jul 2009 16:31:01 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 31 Jul 2009 16:31:01 -0000 X-YMail-OSG: wb_D9j0VM1lo8TFOOiTylZFVb7dzXOCcRqVsRG9SV6oivb2p520B4KMDnHfDWtE4tWbQWbHzhTsSVd3ZWtFjo8oyVwmZyFgiNUa0i.A2hFrUr2QiFx1iw1InPNXhBmyG6PK16I1O_cB4IoVdV4WI5V5x6vfIzntZQZYjRVKVPh8Vr3vLRr.37VQAcJwJHCeq1NR9Eri5nLWbKAsRo4wYc1sJt05AzRJLxrJ6sKpfew82l5m5uARmfok0izvo.h7uUQL.tjlOqBNbGGrWLbhwnbCJmPgzHGB2KbcZS1oSERpCZL2QeQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A731BD6.20109@netconfcentral.com> Date: Fri, 31 Jul 2009 09:29:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] YANG data model organization within a NETCONF database 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: , X-List-Received-Date: Fri, 31 Jul 2009 16:31:00 -0000 Hi, I heard one sequence on the audio feed from the last meeting that was kind of scary. There is an assumption that top-level data nodes within a YANG module that are supported by the agent are 'rooted' as children of the element. This needs to be more than an assumption. It MUST be the only way a conforming implementation locates top-level YANG data nodes in a NETCONF database. If agents do not locate all objects in the same place for the exact same YANG module, then IMO YANG is broken. The YANG object identifier that falls out from the YANG file definition MUST be the exact spot in the conceptual XML instance document where the object is found. e.g.: /interfaces/interface/name /ietf-netconf-state/schemas Andy From mark@ellisonsoftware.com Fri Jul 31 10:17:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0203A6D2B for ; Fri, 31 Jul 2009 10:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo0nWXDEHS0U for ; Fri, 31 Jul 2009 10:17:30 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 341483A6B7D for ; Fri, 31 Jul 2009 10:17:30 -0700 (PDT) Received: by gxk9 with SMTP id 9so3916116gxk.13 for ; Fri, 31 Jul 2009 10:17:29 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.150.195.6 with SMTP id s6mr5046627ybf.20.1249060648971; Fri, 31 Jul 2009 10:17:28 -0700 (PDT) In-Reply-To: <20090730190346.GB16690@elstar.local> References: <200907291440.n6TEeYvY036427@idle.juniper.net> <4A706835.5020409@netconfcentral.com> <8a0268750907291401v58d1cf57k1a669186f9b0ab9e@mail.gmail.com> <20090730190346.GB16690@elstar.local> Date: Fri, 31 Jul 2009 13:17:28 -0400 X-Google-Sender-Auth: cbb25d0b72af0ff4 Message-ID: <8a0268750907311017u6b88e26br9dee46d2667ec812@mail.gmail.com> From: Mark Ellison To: Juergen Schoenwaelder , Mark Ellison , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd4065248eea70470039809 Subject: Re: [netmod] Issue 2 - data-and-time canonicalization 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: , X-List-Received-Date: Fri, 31 Jul 2009 17:17:31 -0000 --000e0cd4065248eea70470039809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Jul 30, 2009 at 3:03 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jul 29, 2009 at 11:01:30PM +0200, Mark Ellison wrote: > > > I can see something like this to config/initialize the current time > > on a device...but alternatively I can see some devices using an NTP > > server instead for this information and that would be a different > > set of config leaves. > > NTP does not tell a device which time zone it is in - how should an > NTP server know. When you unpack a computer, you once have to say > which time zone you are in - there is no way around this. > okay. > So there should be a standard object to configure the time zone. And > yes, it would be cool to have standard objects to configure NTP and a > standard operation to set the time (I am saying operation since the > current time clearly is not config data). > okay. > > We will sooner or later need a core data model - also standard > operations to reboot/shutdown a device would be cool to have as these > are the most basic operations you operationally need. > yes, agreed- maybe these actions are best addressed in a new thread? > > But we first need to get YANG out of the door and this includes > agreement on the date-and-time canonicalization. > This thread has helped me gain a better understanding of the date-and-time canonicalization issue. The following summarizes my understanding: There is a date-and-time typedef contained in draft-ietf-netmod-yang-types-03 that has an /architectural space/ allowing for a offset from UTC. What is being proposed by NETMOD is a canonicalization of date-and-time information in rpc exchanges with a NETCONF server to follow the date-and-time typdef with the additional constraint that the offset is always Z+00:00 thereby conforming to the notion of UTC. For a NETCONF client to understand the 'local time' for a NETCONF served device a need exists for a configuration leaf that contains the timezone or offset from UTC for the device. The form of the value for the timezone/utc-offset configuration leaf remains a subject for further discussion- Andy has made a suggestion: utc-offset (type ???, maybe just ('+'|'-')"HH:MM") Standardizing the format of the value for the above NETMOD configuration leaf will improve the interoperability of NETCONF clients and servers. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- Mark Ellison Ellison Software Consulting, Inc. voice: +1 (603) 362-9270 38 Salem Road skype: ellison.software Atkinson, NH 03811, USA web: http://EllisonSoftware.com/ --000e0cd4065248eea70470039809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2009 at 3:03 PM, Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jul 29, 2009 at 11:01:30PM +0200, Mark Ellison wrote:

> I can see something like this to config/initialize the current time > on a device...but alternatively I can see some devices using an NTP > server instead for this information and that would be a different
> set of config leaves.

NTP does not tell a device which time zone it is in - how should an NTP server know. When you unpack a computer, you once have to say
which time zone you are in - there is no way around this.

okay.


So there should be a standard object to configure the time zone. And
yes, it would be cool to have standard objects to configure NTP and a
standard operation to set the time (I am saying operation since the
current time clearly is not config data).

okay.
=A0

We will sooner or later need a core data model - also standard
operations to reboot/shutdown a device would be cool to have as these
are the most basic operations you operationally need.

yes, agreed- maybe these actions are best addressed i= n a new thread?
=A0

But we first need to get YANG out of the door and this includes
agreement on the date-and-time canonicalization.

This thread has help= ed me gain a better understanding of the date-and-time canonicalization iss= ue.=A0 The following summarizes my understanding:

There is a date-an= d-time typedef contained in draft-ietf-netmod-yang-types-
03 that has an /architectural space/ allowing for a offset from UTC.
What is being proposed by NETMOD is a canonicalization of date-and-time in= formation in rpc exchanges with a NETCONF server to follow the date-and-tim= e typdef with the additional constraint that the offset is always Z+00:00 t= hereby conforming to the notion of UTC.

For a NETCONF client to understand the 'local time' for a NETCO= NF served device a need exists for a configuration leaf that contains the t= imezone or offset from UTC for the device.

The form of the value for= the timezone/utc-offset configuration leaf remains a subject for further d= iscussion- Andy has made a suggestion:

=A0 utc-offse= t =A0(type ???, maybe just ('+'|'-')"HH:MM")

Standardizing the format of the value for the above NETMOD configu= ration leaf will improve the interoperability of NETCONF clients and server= s.
=A0

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>



--
Mark Elliso= n =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ellison Software Cons= ulting, Inc.
voice: =A0+1 (603) 362-9270 =A0 =A0 =A0 =A038 Salem Roadskype: ellison.software =A0 =A0 =A0 =A0 =A0 =A0Atkinson, NH =A003811, USA<= br> web: =A0 =A0http:= //EllisonSoftware.com/
--000e0cd4065248eea70470039809-- From mbj@tail-f.com Fri Jul 31 12:16:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92F43A6974 for ; Fri, 31 Jul 2009 12:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.226, 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 9Nx3Hl1wuNzu for ; Fri, 31 Jul 2009 12:16:57 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CCD773A67B1 for ; Fri, 31 Jul 2009 12:16:56 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 086D676C5A0; Fri, 31 Jul 2009 21:16:57 +0200 (CEST) Date: Fri, 31 Jul 2009 21:16:56 +0200 (CEST) Message-Id: <20090731.211656.192693069.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7316BA.5090308@netconfcentral.com> References: <4A7200AB.9030905@netconfcentral.com> <20090731.114728.212391918.mbj@tail-f.com> <4A7316BA.5090308@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 31 Jul 2009 19:16:58 -0000 Andy Bierman wrote: > This text does not fully address the example I posted (footest2.yang). > > The problem is more complicated than just must/when expressions. > > If the local prefix is not used (the normal use-case), then > the module with the uses-stmt will be used to find > identities and types, and resolve the default-stmt. > This is broken. I agree that this would be broken. But that is not how it works. I was a bit unclear in my quote of the proposed text -- the text was from section 6.4.1, the XPath context, which applies to must/when/path only. Below I have attached the complete text for this section. The rules for non-xpath statements are the same as before. /martin 6.4.1. XPath Context All YANG XPath expressions share the following XPath context definition: o The set of namespace declarations is the set of all "import" statements' prefix and namespace pairs in the module where the XPath expression is specified, and the "prefix" statement's prefix for the "namespace" statement's URI. o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping that namespace is affected by where the grouping is used (see Section 7.12). o The function library is the core function library defined in [XPATH], and a function "current()" which returns a node set with the initial context node. o The set of variable bindings is empty. The mechanism for handling unprefixed names is adopted from XPath 2.0 [XPATH2.0], and helps simplify XPath expressions in YANG. No ambiguity may ever arise because YANG node identifiers are always qualified names with a non-null namespace URI. The context node varies with the YANG XPath expression, and is specified where the YANG statement with the XPath expression is defined. 7.12. The uses Statement The "uses" statement is used to reference a "grouping" definition. It takes one argument, which is the name of the grouping. The effect of a "uses" reference to a grouping is that the nodes defined by the grouping are copied into the current schema tree, and then updated according to the refinement and augment statements. The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, a which point they are bound to the namespace of the current module. From andy@netconfcentral.com Fri Jul 31 12:30:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865CD3A6BE5 for ; Fri, 31 Jul 2009 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 f5synvuv5rA1 for ; Fri, 31 Jul 2009 12:30:27 -0700 (PDT) Received: from n8.bullet.mail.mud.yahoo.com (n8.bullet.mail.mud.yahoo.com [209.191.86.156]) by core3.amsl.com (Postfix) with SMTP id 8D1D53A69C6 for ; Fri, 31 Jul 2009 12:30:27 -0700 (PDT) Received: from [209.191.108.97] by n8.bullet.mail.mud.yahoo.com with NNFMP; 31 Jul 2009 19:30:26 -0000 Received: from [68.142.201.247] by t4.bullet.mud.yahoo.com with NNFMP; 31 Jul 2009 19:30:26 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 31 Jul 2009 19:30:26 -0000 X-Yahoo-Newman-Id: 138187.19340.bm@omp408.mail.mud.yahoo.com Received: (qmail 25491 invoked from network); 31 Jul 2009 19:30:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 31 Jul 2009 19:30:25 -0000 X-YMail-OSG: GOWEl5kVM1k0RNE56nLplQs9XAa7gH_XOYQzY0pCzTTyV1f8S6emMEyUX6xllgqpveNqgeN1IDsfLOZ4hFx00lc3jERX59lmz5uL0WOFbS0Aw_OnJNRkPVX7ET9HJTdfnljga9qM8Z8PF1dpkvShnSuUASe15jWwBY9kZrE9ZkCjY0ebUr.NXX8SV9uAum.qNmFt0cHzyAUYUD90jW.q97Jnsq.d_vfrpw9PUhfxuLQaOX5XMqsacqM7AqKkJJq4iz.Dwpq9PLrKaEW1LU9oCYBJbcPRiA8z_vGI7uCbM5XrD0aN0ZQiMirCrL0RmHk.w2LkPVfhvxE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7345E4.9000508@netconfcentral.com> Date: Fri, 31 Jul 2009 12:28:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7200AB.9030905@netconfcentral.com> <20090731.114728.212391918.mbj@tail-f.com> <4A7316BA.5090308@netconfcentral.com> <20090731.211656.192693069.mbj@tail-f.com> In-Reply-To: <20090731.211656.192693069.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings 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: , X-List-Received-Date: Fri, 31 Jul 2009 19:30:28 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> This text does not fully address the example I posted (footest2.yang). >> >> The problem is more complicated than just must/when expressions. >> >> If the local prefix is not used (the normal use-case), then >> the module with the uses-stmt will be used to find >> identities and types, and resolve the default-stmt. >> This is broken. > > I agree that this would be broken. But that is not how it works. I > was a bit unclear in my quote of the proposed text -- the text was > from section 6.4.1, the XPath context, which applies to must/when/path > only. Below I have attached the complete text for this section. The > rules for non-xpath statements are the same as before. > how does this apply to types and identityrefs, and defaults? type foo:MyType; type MyType; default foo:my-identity; default my-identity; identity bar { base foo:MyBase; } identity bar { base MyBase; } type leafref { path ../foo:baz; } type leafref { path ../baz; } Before, all of these statements that use QNames will use the module that defined the statement as the local module, to resolve the missing prefix . Now these are all changing too, right? Are you saying that some prefixes (or missing prefixes) inside a grouping will mean one thing, and mean another thing just inside must/when statements? > > /martin Andy > > > 6.4.1. XPath Context > > All YANG XPath expressions share the following XPath context > definition: > > o The set of namespace declarations is the set of all "import" > statements' prefix and namespace pairs in the module where the > XPath expression is specified, and the "prefix" statement's prefix > for the "namespace" statement's URI. > > o Names without a namespace prefix belong to the same namespace as > the identifier of the current node. Inside a grouping that > namespace is affected by where the grouping is used (see > Section 7.12). > > o The function library is the core function library defined in > [XPATH], and a function "current()" which returns a node set with > the initial context node. > > o The set of variable bindings is empty. > > The mechanism for handling unprefixed names is adopted from XPath 2.0 > [XPATH2.0], and helps simplify XPath expressions in YANG. No > ambiguity may ever arise because YANG node identifiers are always > qualified names with a non-null namespace URI. > > The context node varies with the YANG XPath expression, and is > specified where the YANG statement with the XPath expression is > defined. > > 7.12. The uses Statement > > The "uses" statement is used to reference a "grouping" definition. > It takes one argument, which is the name of the grouping. > > The effect of a "uses" reference to a grouping is that the nodes > defined by the grouping are copied into the current schema tree, and > then updated according to the refinement and augment statements. > > The identifiers defined in the grouping are not bound to a namespace > until the contents of the grouping are added to the schema tree via a > "uses" statement that does not appear inside a "grouping" statement, > a which point they are bound to the namespace of the current module. > >