From mbj@tail-f.com Mon Jun 1 00:22: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 1E1263A69A1 for ; Mon, 1 Jun 2009 00:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 hzmnhKyV2bjP for ; Mon, 1 Jun 2009 00:22: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 5AC813A68E4 for ; Mon, 1 Jun 2009 00:22:45 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 0032776C502; Mon, 1 Jun 2009 09:22:41 +0200 (CEST) Date: Mon, 01 Jun 2009 09:22:42 +0200 (CEST) Message-Id: <20090601.092242.187818853.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A217C4D.3000503@netconfcentral.com> References: <4A217808.9060104@netconfcentral.com> <4A217C4D.3000503@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] must-stmt usage 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: Mon, 01 Jun 2009 07:22:46 -0000 Andy Bierman wrote: > Andy Bierman wrote: > > Hi, > > [Warning: enhancement request up ahead!] > > > I just remembered that the create-subscription operation > defines some useless added to it (bad-element). > Modeling all the error-info is more than I had in mind, > and the error-tag alone is not enough to automate the > error response correctly. Perhaps YANG2 should model > every error detail, but not now. Does this mean that your 'error-tag' statement should wait until YANG2 as well, or do you think it must be added now? /martin From lhotka@cesnet.cz Mon Jun 1 01:16: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 5E8FC3A67BD for ; Mon, 1 Jun 2009 01:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.95 X-Spam-Level: * X-Spam-Status: No, score=1.95 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwKbQvg2wsFN for ; Mon, 1 Jun 2009 01:16:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 364F13A6D71 for ; Mon, 1 Jun 2009 01:16:06 -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 51D4CD800BD; Mon, 1 Jun 2009 10:16:05 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A201E34.2090103@netconfcentral.com> References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <006901c9df6a$149e0ec0$0601a8c0@allison> <20090528.115655.03590098.mbj@tail-f.com> <002d01c9dfba$55470a80$0601a8c0@allison> <4A201E34.2090103@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 01 Jun 2009 10:16:05 +0200 Message-Id: <1243844165.6392.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 08:16:07 -0000 Andy Bierman píše v Pá 29. 05. 2009 v 10:41 -0700: > > The path-stmt in a leafref identifies one or more conceptual > nodes in the value tree, so there are no choice or case nodes > and there can be predicates for list keys. How about expressions like "foo//bar" or "foo/*/bar"? These are allowed in XSD's restricted XPath, but for YANG leafrefs it could lead to nodesets containing leaves of different data types. > > The value of an instance-identifier is an absolute path > expression representing one conceptual node in the value tree. What is the value tree (= "data tree" in YANG terminology) if an i-i leaf occurs in a notification or RPC? I understand it is an analogy of MIB instance identifiers, but what are actually their use cases in the context of NETCONF/YANG? > The prefixes are relative, so comparing instance-identifiers > is an implementation detail, i.e., not strcmp(). > > I find it much easier to conceptualize YANG by thinking > of how it would be implemented. Imagine a tree of > all available objects (rpc, notification, data-def-stmt). > Then imagine another 'mirror' tree, with zero or more instances > of each object node. It isn't really necessary to copy > all the YANG defaults into the value tree, so some > implementations don't. (That's why we need with-defaults.) Yes, I think it would help to use something like the model-view paradigm. The model in our case would be the full data tree (including all defaults) that allows for multiple views with different ways/levels of default suppression. The model will then be a well-defined and implementation-independent XML document that the XPath expressions always refer to. In particular, for the YANG fragment container ccc { leaf foo { type int8; default 42; } leaf fooref { type leafref { path "../foo"; require-instance true; } } } this will then be a valid configuration view: 42 (because "foo" exists in the model with the default value of 42). Lada > > The value tree doesn't have any config=false nodes in it, > but the object tree has them, so implementing require-instance=false > only requires some special code -- just a major XPath implementation > requirement to process the internal object tree, not some > XML instance document. It would be really inefficient to > process XPath by creating an XML document, so it is more > likely the value tree will be processed directly anyway. > > Then there is the issue of deleting invalid config leafrefs > when the non-config pointed-at leaf changes value. > This is a problem for implementors. I was thinking it was OK > to leave the invalid config leafref in , but what > about ? Either direct via or > indirect via mirroring, the invalid leafref will end up > in the config, causing a problem later. > > Removing the leafref may cause more problems than leaving it there, > due to must, when, mandatory, min-elements statements. > > IMO, config leafrefs are not very important to have, > except as foreign keys. But the problem doesn't > go away for foreign keys, so might as well support #4. > > SMIv2 can have simple INDEX clause because all the leaf names > must be unique. YANG would need to specify the schema path > as follows: > > container interfaces { > list interface { > key name; > leaf name { ... } > leaf ifIndex { > // what to do about read-only ifIndex? > // should that be supported? IMO, no > } > ... > } > } > > list oldIfEntry { > key "/interfaces/interface/ifIndex"; > // no leaf-stmt for ifIndex > leaf foo {} > } > > list extOldIfEntry { > key "/interfaces/interface/ifIndex localIndex"; > // no leaf-stmt for ifIndex > leaf localIndex {} > leaf foo {} > } > > Note how a local key is also a valid path expression, > consistent with the foreign keys? > > IMO, this would eliminate the need for config leafrefs, > and it is more direct. The SMIv2 'copy-fooIndex" > approach is too cut-and-paste. If you want a foreign > key, then it should be specified in the key-stmt. > Mixing foreign and local keys from the same namespace > would require some name collision checking, but > the YANG compiler does that already. > > > > >... > > > Tom Petch > >> /martin > > > > > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jun 1 01:25: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 624943A6E06 for ; Mon, 1 Jun 2009 01:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, 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 WZurv-hLihOE for ; Mon, 1 Jun 2009 01:25:25 -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 71E4F3A68FE for ; Mon, 1 Jun 2009 01:25:25 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 3861E76C502; Mon, 1 Jun 2009 10:25:24 +0200 (CEST) Date: Mon, 01 Jun 2009 10:25:24 +0200 (CEST) Message-Id: <20090601.102524.25062992.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1243844165.6392.65.camel@missotis> References: <002d01c9dfba$55470a80$0601a8c0@allison> <4A201E34.2090103@netconfcentral.com> <1243844165.6392.65.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] XPath issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 08:25:26 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFDDoSAyOS4gMDUuIDIwMDkgdiAxMDo0MSAtMDcwMDoNCj4gPiANCj4gPiBUaGUg cGF0aC1zdG10IGluIGEgbGVhZnJlZiBpZGVudGlmaWVzIG9uZSBvciBtb3JlIGNvbmNlcHR1YWwN Cj4gPiBub2RlcyBpbiB0aGUgdmFsdWUgdHJlZSwgc28gdGhlcmUgYXJlIG5vIGNob2ljZSBvciBj YXNlIG5vZGVzDQo+ID4gYW5kIHRoZXJlIGNhbiBiZSBwcmVkaWNhdGVzIGZvciBsaXN0IGtleXMu DQo+IA0KPiBIb3cgYWJvdXQgZXhwcmVzc2lvbnMgbGlrZSAiZm9vLy9iYXIiIG9yICJmb28vKi9i YXIiPyBUaGVzZSBhcmUgYWxsb3dlZA0KPiBpbiBYU0QncyByZXN0cmljdGVkIFhQYXRoLCBidXQg Zm9yIFlBTkcgbGVhZnJlZnMgaXQgY291bGQgbGVhZCB0bw0KPiBub2Rlc2V0cyBjb250YWluaW5n IGxlYXZlcyBvZiBkaWZmZXJlbnQgZGF0YSB0eXBlcy4NCg0KVGhlc2UgYXJlIG5vdCBhbGxvd2Vk IGluICdwYXRoJyAoc2VlICdwYXRoLXN0bXQnIGluIHRoZSBncmFtbWFyKS4NCg0KPiA+IFRoZSB2 YWx1ZSBvZiBhbiBpbnN0YW5jZS1pZGVudGlmaWVyIGlzIGFuIGFic29sdXRlIHBhdGgNCj4gPiBl eHByZXNzaW9uIHJlcHJlc2VudGluZyBvbmUgY29uY2VwdHVhbCBub2RlIGluIHRoZSB2YWx1ZSB0 cmVlLg0KPiANCj4gV2hhdCBpcyB0aGUgdmFsdWUgdHJlZSAoPSAiZGF0YSB0cmVlIiBpbiBZQU5H IHRlcm1pbm9sb2d5KSBpZiBhbiBpLWkNCj4gbGVhZiBvY2N1cnMgaW4gYSBub3RpZmljYXRpb24g b3IgUlBDPw0KDQpZZXMsIGl0IG5lZWRzIHRvIGJlIHNwZWNpZmllZC4gIFRoZSBpbnRlbnRpb24g aXMgdGhhdCBzdWNoIGFuDQppbnN0YW5jZS1pZGVudGlmaWVyIHJlZmVycyB0byBzdGF0ZSBvciBj b25maWcgZGF0YS4NCg0KPiBJIHVuZGVyc3RhbmQgaXQgaXMgYW4gYW5hbG9neSBvZiBNSUIgaW5z dGFuY2UgaWRlbnRpZmllcnMsIGJ1dCB3aGF0IGFyZQ0KPiBhY3R1YWxseSB0aGVpciB1c2UgY2Fz ZXMgaW4gdGhlIGNvbnRleHQgb2YgTkVUQ09ORi9ZQU5HPw0KDQpXaGVuIHlvdSBuZWVkIGEgcmVm ZXJlbmNlIHRvIHNvbWUgdW5rbm93biBkYXRhIGluIHRoZSB0cmVlLiAgQW4NCmV4YW1wbGUgZnJv bSBhbiBSUEMgaXMgPGVycm9yLXBhdGg+LiAgSW4gYSBkYXRhIG1vZGVsIHlvdSBtaWdodCB1c2Ug aXQNCmluIGFuIGFjY2VzcyBjb250cm9sIG1vZGVsLg0KDQoNCg0KL21hcnRpbg0K From lhotka@cesnet.cz Mon Jun 1 01:27:36 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 03D7E3A6D6C for ; Mon, 1 Jun 2009 01:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.65 X-Spam-Level: * X-Spam-Status: No, score=1.65 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfzv6D1sGHRY for ; Mon, 1 Jun 2009 01:27:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2ED433A68FE for ; Mon, 1 Jun 2009 01:27:35 -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 EA5D2D800BD for ; Mon, 1 Jun 2009 10:27:34 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090529.194815.74630685.mbj@tail-f.com> References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 01 Jun 2009 10:27:34 +0200 Message-Id: <1243844855.6392.69.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 08:27:36 -0000 Martin Bjorklund píše v Pá 29. 05. 2009 v 19:48 +0200: > > Since leafref just returns the value of the pointed-at node > > with no indication of the actual instance selected, > > it is not very useful for notifications. > > We changed keyref to leafref mainly for supporting leafref in > notifications. If you think we don't need to worry about > notifications, can we change leafref back to keyref? Could notifications use instance identifiers instead? The big advantage would be that the i-i XPath refers to a concrete instance document and needn't be specified in the data model as for leafrefs. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Jun 1 02:37: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 7883D3A6ACC for ; Mon, 1 Jun 2009 02:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srO2BTR78PEA for ; Mon, 1 Jun 2009 02:37:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B4E993A6A9B for ; Mon, 1 Jun 2009 02:37: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 BEB1AD800C7; Mon, 1 Jun 2009 11:37:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090601.102524.25062992.mbj@tail-f.com> References: <002d01c9dfba$55470a80$0601a8c0@allison> <4A201E34.2090103@netconfcentral.com> <1243844165.6392.65.camel@missotis> <20090601.102524.25062992.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 01 Jun 2009 11:37:19 +0200 Message-Id: <1243849039.6392.112.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 09:37:21 -0000 Martin Bjorklund píše v Po 01. 06. 2009 v 10:25 +0200: > > How about expressions like "foo//bar" or "foo/*/bar"? These are > allowed > > in XSD's restricted XPath, but for YANG leafrefs it could lead to > > nodesets containing leaves of different data types. > > These are not allowed in 'path' (see 'path-stmt' in the grammar). I see, but the text is less precise, so it should refer to the ABNF. Are the equality tests supposed to be performed as in XPath or using value-space values? I still think it would make sense to use XPath 1.0 or even XPath 2.0 expressions (but in each case exactly following the spec) for 'must' and 'when' and have YANG-specific path expressions for the rest, because the latter is in fact a very limited subset of XPath but on the other hand introduces certain syntactic and semantic differences (or such differences would be useful). Also, the "YPath" expressions can be made mandatory for all implementations whereas general XPath needn't. Interestingly, the upcoming XSD 1.1 spec introduces assertions, a concept quite similar to 'must' - they are XPath 2.0 expressions but can only see the subtree of the node where they are specified. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Jun 1 04:59: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 EA3513A6B74 for ; Mon, 1 Jun 2009 04:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 yFSo2TobUZff for ; Mon, 1 Jun 2009 04:59:25 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 0C9703A6B04 for ; Mon, 1 Jun 2009 04:59:24 -0700 (PDT) Received: (qmail 43657 invoked from network); 1 Jun 2009 11:59:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 1 Jun 2009 11:59:22 -0000 X-YMail-OSG: h9.DISwVM1lOShfZC7EKc1aSynJH1ds3dY565ioXqiyp8mAlPVu.rozXWy0Ai4NHsIJrbIpXd7gKSCzRgwo7Pkp9yfsoyCuHBiEdynM2HzYGeLLgTGws0DGWP.L_DSXQdWNi2D.5RkSxtyFVINhxAbHGhLdFyNhR8.Q0ZAZHMV8kxEWe_hx5RCQjgOA2HtGm2aHWf5lCCua8QcPR3jq5G2xe9vcbIZwC8djon0vM4Iggl5jdgefe_yzCL9uXscCHZOKBMWUz1AH0I2GrvBZ432d3_nD2mi2X9QgJSWFSRHcD58.aPvDJ2RoHH9T2_EjcrQQO7ffb0q_iiA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A23C282.50400@netconfcentral.com> Date: Mon, 01 Jun 2009 04:58:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A217808.9060104@netconfcentral.com> <4A217C4D.3000503@netconfcentral.com> <20090601.092242.187818853.mbj@tail-f.com> In-Reply-To: <20090601.092242.187818853.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] must-stmt usage 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: Mon, 01 Jun 2009 11:59:26 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Andy Bierman wrote: >>> Hi, >>> [Warning: enhancement request up ahead!] >> >> I just remembered that the create-subscription operation >> defines some useless added to it (bad-element). >> Modeling all the error-info is more than I had in mind, >> and the error-tag alone is not enough to automate the >> error response correctly. Perhaps YANG2 should model >> every error detail, but not now. > > Does this mean that your 'error-tag' statement should wait until YANG2 > as well, or do you think it must be added now? > wait until YANG2. I actually prefer the error construct you proposed awhile back, which is part of the 'rpc' construct (not part of range/length/etc.) > > /martin > > Andy From andy@netconfcentral.com Mon Jun 1 05:09: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 2A9D429440D for ; Mon, 1 Jun 2009 05:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_40=-0.185, 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 7tei4YLubteX for ; Mon, 1 Jun 2009 05:09:16 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id E138428C9F7 for ; Mon, 1 Jun 2009 05:03:31 -0700 (PDT) Received: (qmail 89267 invoked from network); 1 Jun 2009 12:03:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 1 Jun 2009 12:03:20 -0000 X-YMail-OSG: sSMVAwUVM1lPYOJ7Pl8x1IriGcKIzk4gT3Wi0FJs86M8Cy_NehWvTtaGkVhuM6.x2u1SfM2huPb6.xGZofkVFb5v0DZJ5X2WJ_pQP6UUonWy9J4ODWMz_Nc4icDw_TwC3IEcnOpm7Ne5JD2KN5cs.TFQamvvFpl9civRbepJK8t09td1fLfDS1.4F_59osI59N4baFbex3STM6b9QJbhGBI5Equ07r.SuUxogwK2GUVZo44pJjUCDPxkw5ne7pfQTDezOwOt_qxY.A_ZSI28HLSb9zltbpqObU6D3gdELlAiZqeVVJgC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A23C386.4020905@netconfcentral.com> Date: Mon, 01 Jun 2009 05:03:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <1243844855.6392.69.camel@missotis> In-Reply-To: <1243844855.6392.69.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 12:09:18 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Pá 29. 05. 2009 v 19:48 +0200: >>> Since leafref just returns the value of the pointed-at node >>> with no indication of the actual instance selected, >>> it is not very useful for notifications. >> We changed keyref to leafref mainly for supporting leafref in >> notifications. If you think we don't need to worry about >> notifications, can we change leafref back to keyref? > > Could notifications use instance identifiers instead? The big advantage > would be that the i-i XPath refers to a concrete instance document and > needn't be specified in the data model as for leafrefs. > What is needed is a variable binding -- the instance-identifier and the associated current value. Just knowing the value (leafref) or just knowing the ID (instance-identifier) is worthless. SNMP solved the notification varbind problem 2 decades ago. (How come NETCONF messed it up so badly?) > Lada > Andy From lhotka@cesnet.cz Mon Jun 1 05:42: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 E06693A69F6 for ; Mon, 1 Jun 2009 05:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NamvK2ptbfF for ; Mon, 1 Jun 2009 05:42:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E3E2928C37F for ; Mon, 1 Jun 2009 05:37:55 -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 1132DD800D1; Mon, 1 Jun 2009 14:37:55 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A23C386.4020905@netconfcentral.com> References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 01 Jun 2009 14:37:55 +0200 Message-Id: <1243859875.6392.117.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 12:42:33 -0000 Andy Bierman píše v Po 01. 06. 2009 v 05:03 -0700: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Pá 29. 05. 2009 v 19:48 +0200: > >>> Since leafref just returns the value of the pointed-at node > >>> with no indication of the actual instance selected, > >>> it is not very useful for notifications. > >> We changed keyref to leafref mainly for supporting leafref in > >> notifications. If you think we don't need to worry about > >> notifications, can we change leafref back to keyref? > > > > Could notifications use instance identifiers instead? The big advantage > > would be that the i-i XPath refers to a concrete instance document and > > needn't be specified in the data model as for leafrefs. > > > > What is needed is a variable binding -- the instance-identifier > and the associated current value. Just knowing the value (leafref) > or just knowing the ID (instance-identifier) is worthless. > SNMP solved the notification varbind problem 2 decades ago. > (How come NETCONF messed it up so badly?) I don't understand. Having a locator for a node in the data tree means that its value can be always determined, so IMO in notifications and RPC data the locator (path) should always suffice. Lada > > > > > Lada > > > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Jun 1 06:59: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 436A03A7138 for ; Mon, 1 Jun 2009 06:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=1.337, 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 x8cyjUap0cNz for ; Mon, 1 Jun 2009 06:59:27 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id F2FC03A716C for ; Mon, 1 Jun 2009 06:59:09 -0700 (PDT) Received: from [68.142.200.221] by n17.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2009 13:59:08 -0000 Received: from [68.142.201.70] by t9.bullet.mud.yahoo.com with NNFMP; 01 Jun 2009 13:59:08 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 01 Jun 2009 13:59:08 -0000 X-Yahoo-Newman-Id: 401091.99757.bm@omp422.mail.mud.yahoo.com Received: (qmail 76548 invoked from network); 1 Jun 2009 13:59:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 1 Jun 2009 13:59:07 -0000 X-YMail-OSG: pKbZIxQVM1l2HC8ckavKqptN3FTCFkfyo6DT57YPvz.1A2O5AXreDHHavpyp51c2mP2Zor5_4hRiZifYVwMTA44_2QxxNTqk0X.RNwWe.BjCbS79MEGsfXiVNfsrulrGVmuoWWQiCzpsrvpB1FqRGt3QMWyFooQKkxrLLGj08nPZZA9RoTWFsehBDO6AUkORMI6jwsGEY6KX_dEnbt.iTZC.2V9S1hCYjWsKrxcdG9lU7O5FJhIHCr_NwcIkQ_AzCCPOShJzlNvoRN9ynZXARzoK2fdNrVZkUkxGbz62YB5g0d8hMQXm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A23DEA9.4080206@netconfcentral.com> Date: Mon, 01 Jun 2009 06:59:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> <1243859875.6392.117.camel@missotis> In-Reply-To: <1243859875.6392.117.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 13:59:28 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 01. 06. 2009 v 05:03 -0700: >> Ladislav Lhotka wrote: >>> Martin Bjorklund píše v Pá 29. 05. 2009 v 19:48 +0200: >>>>> Since leafref just returns the value of the pointed-at node >>>>> with no indication of the actual instance selected, >>>>> it is not very useful for notifications. >>>> We changed keyref to leafref mainly for supporting leafref in >>>> notifications. If you think we don't need to worry about >>>> notifications, can we change leafref back to keyref? >>> Could notifications use instance identifiers instead? The big advantage >>> would be that the i-i XPath refers to a concrete instance document and >>> needn't be specified in the data model as for leafrefs. >>> >> What is needed is a variable binding -- the instance-identifier >> and the associated current value. Just knowing the value (leafref) >> or just knowing the ID (instance-identifier) is worthless. >> SNMP solved the notification varbind problem 2 decades ago. >> (How come NETCONF messed it up so badly?) > > I don't understand. Having a locator for a node in the data tree means > that its value can be always determined, so IMO in notifications and RPC > data the locator (path) should always suffice. > This introduces time-based skew in the data, and the application is forced to retrieve data that is normally delivered in the notification. > Lada > Andy From lhotka@cesnet.cz Mon Jun 1 07:30: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 378313A7142 for ; Mon, 1 Jun 2009 07:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=1.375, 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 WYEdJryKs9Vi for ; Mon, 1 Jun 2009 07:30:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3601E3A6A02 for ; Mon, 1 Jun 2009 07:30:44 -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 DEC5CD800CC for ; Mon, 1 Jun 2009 16:30:41 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A23DEA9.4080206@netconfcentral.com> References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com> <1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> <1243859875.6392.117.camel@missotis> <4A23DEA9.4080206@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 01 Jun 2009 16:30:42 +0200 Message-Id: <1243866642.6392.147.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 01 Jun 2009 14:30:45 -0000 Andy Bierman píše v Po 01. 06. 2009 v 06:59 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Po 01. 06. 2009 v 05:03 -0700: > >> Ladislav Lhotka wrote: > >>> Martin Bjorklund píše v Pá 29. 05. 2009 v 19:48 +0200: > >>>>> Since leafref just returns the value of the pointed-at node > >>>>> with no indication of the actual instance selected, > >>>>> it is not very useful for notifications. > >>>> We changed keyref to leafref mainly for supporting leafref in > >>>> notifications. If you think we don't need to worry about > >>>> notifications, can we change leafref back to keyref? > >>> Could notifications use instance identifiers instead? The big advantage > >>> would be that the i-i XPath refers to a concrete instance document and > >>> needn't be specified in the data model as for leafrefs. > >>> > >> What is needed is a variable binding -- the instance-identifier > >> and the associated current value. Just knowing the value (leafref) > >> or just knowing the ID (instance-identifier) is worthless. > >> SNMP solved the notification varbind problem 2 decades ago. > >> (How come NETCONF messed it up so badly?) > > > > I don't understand. Having a locator for a node in the data tree means > > that its value can be always determined, so IMO in notifications and RPC > > data the locator (path) should always suffice. > > > > This introduces time-based skew in the data, and the application > is forced to retrieve data that is normally delivered in the > notification. The notification can still deliver the value and the specification of its semantics will state that it is the value of the leaf pointed to by the instance-identifier. Anyway, if the notification contained both instance-identifier and leafref, there is no way in YANG to tell that both refer to the same leaf. Lada > > > > Lada > > > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Tue Jun 2 12:49: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 855933A6DE1 for ; Tue, 2 Jun 2009 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 HH2WG3GYgBmP for ; Tue, 2 Jun 2009 12:49:32 -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 71B733A6CA2 for ; Tue, 2 Jun 2009 12:49:20 -0700 (PDT) X-Trace: 109371596/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.102/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.102 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: AqoEAN0eJUo+vBFm/2dsb2JhbACDKYt1wFoIhAMF X-IronPort-AV: E=Sophos;i="4.41,292,1241391600"; d="scan'208";a="109371596" X-IP-Direction: IN Received: from 1cust102.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.102]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Jun 2009 20:49:18 +0100 Message-ID: <001c01c9e3b2$b196be60$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Ladislav Lhotka" References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com><1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> Date: Tue, 2 Jun 2009 20:21:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: Re: [netmod] leafref issues 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: Tue, 02 Jun 2009 19:49:33 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Ladislav Lhotka" Cc: Sent: Monday, June 01, 2009 2:03 PM Subject: Re: [netmod] leafref issues > > What is needed is a variable binding -- the instance-identifier > and the associated current value. Just knowing the value (leafref) > or just knowing the ID (instance-identifier) is worthless. > SNMP solved the notification varbind problem 2 decades ago. > (How come NETCONF messed it up so badly?) Andy It's not really to do with notifications but with getting anything from device to manager. SMI took the view that a device knowing nothing of the data model could still make some sense of the data it received, what its SYNTAX was, what value, where in the data tree it came from, this applies to get, get-next, report, anything, something I have used with success when I had gotten the contents of a proprietary MIB module, such as a CISCO one:-) NETCONF takes the view that the manager must have the data model to achieve even this, although with it, it can achieve more, just as an SMI manager can. We could introduce varbinds into YANG, at least for notification; it is only a complex type, of instance identifier and instance value. Tom Petch. > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From cfinss@dial.pipex.com Tue Jun 2 12:49: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 E3E173A6CA2 for ; Tue, 2 Jun 2009 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tvSr+T8Bw+p for ; Tue, 2 Jun 2009 12:49:33 -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 1309F3A6E32 for ; Tue, 2 Jun 2009 12:49:20 -0700 (PDT) X-Trace: 109371600/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.102/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.102 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: AqoEAN0eJUo+vBFm/2dsb2JhbACDKYt1wFoIhAMF X-IronPort-AV: E=Sophos;i="4.41,292,1241391600"; d="scan'208";a="109371600" X-IP-Direction: IN Received: from 1cust102.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.102]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Jun 2009 20:49:20 +0100 Message-ID: <001d01c9e3b2$b270f1c0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A1FF122.8000304@netconfcentral.com><20090529.194815.74630685.mbj@tail-f.com><4A2023CF.30105@netconfcentral.com> <20090529.223337.116612168.mbj@tail-f.com> Date: Tue, 2 Jun 2009 20:44:52 +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] leafref issues -semantics 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: Tue, 02 Jun 2009 19:49:34 -0000 OK, so leafref is copy by value, but I do not see that in the wording (which is perhaps why I have been so stubbornly not wanting to believe it). But two sentences in particular really give me grief. "Its value is constrained to be the same as the value of an existing leaf." "Its" - of course - refers back to the subject of the previous sentence, namely "The leafref type" so this tells me that the value of the leafref type (in XSD, everything has a value, so why not a leafref type in YANG?) is constrained to be the same as the value of an existing leaf. Which does not parse. The value of a type, in schema tree or data tree, is going to be different to the value of a leaf! So perhaps it means that the value of the leaf with the leafref type is constrained to be the same as the value etc. But this formulation is used in the next paragraph, so why not here, why the difference? Just what is that sentence "Its value ...." trying to say. Please spell it out. Likewise in 9.9.2. "The value of the referring leaf MUST match the type of the referred leaf." Again, I cannot make sense of a value matching a type. Either I must coerce the value into a type ie you mean that the value's type must match referred leaf's type or I must coerce the type into a value - ie the value of the referring leaf MUST match the value of the referred leaf or leafs. Neither of which you say. Please clarify. Some time back, Joel suggested substantial changes were needed to the wording if this description meant what you were saying on the list. My details may differ, but in principle, yes I agree. Tom Petch From phil@juniper.net Tue Jun 2 13: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 E20C13A69D5 for ; Tue, 2 Jun 2009 13:15:13 -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 oFeMPJK38NGd for ; Tue, 2 Jun 2009 13:15:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id CC7843A68AB for ; Tue, 2 Jun 2009 13:15:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSiWITUgO+2CF7c+gS5InKghhlQoXYuLU@postini.com; Tue, 02 Jun 2009 13:15:14 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.340.0; Tue, 2 Jun 2009 13:12:59 -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); Tue, 2 Jun 2009 13:12:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 13:12:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 13:12: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 n52KCwL86328; Tue, 2 Jun 2009 13:12:58 -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 n52K2QfL061249; Tue, 2 Jun 2009 20:02:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906022002.n52K2QfL061249@idle.juniper.net> To: "tom.petch" In-Reply-To: <001d01c9e3b2$b270f1c0$0601a8c0@allison> Date: Tue, 2 Jun 2009 16:02:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Jun 2009 20:12:59.0036 (UTC) FILETIME=[8620D5C0:01C9E3BE] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues -semantics X-BeenThere: netmod@ietf.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, 02 Jun 2009 20:15:14 -0000 "tom.petch" writes: >OK, so leafref is copy by value, but I do not see that in the wording >(which is perhaps why I have been so stubbornly not wanting to believe >it). leafref isn't copy by anything. There's no copying at all. It's a constraint on the value space of a leaf, meaning the leaf may only contain values that appear at some other particular spot in the configuration. leafref allows a modeler to enforce referential integrity, so that a reference to a name configuration item defined in one spot can be guaranteed to exist, and to not be a dangling reference. For example, an interface configuration can only use a firewall filter that's defined in the firewall filter configuration. Or a routing peer configuration can only use an import or export policy that's been configured under the policy configuration. /* Define a policy */ container policy-options { list policy { key name; leaf name { ... } } } /* BGP config refers to that policy */ container protocols { container bgp { list neighbor { key name; leaf name { ... } leaf import { type keyref { path ../../../policy-options/policy/name; } } } } } The config would look like: allow-static-routes ... 10.1.2.3 allow-static-routes ... If I set "import" to "allow-random-chaos", the configuration would be invalid and both the client and server can know that it would be invalid. Thanks, Phil From andy@netconfcentral.com Tue Jun 2 13:32: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 2D45228C19E for ; Tue, 2 Jun 2009 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, 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 VxR+WqwLtmyC for ; Tue, 2 Jun 2009 13:32:18 -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 490353A704B for ; Tue, 2 Jun 2009 13:32:18 -0700 (PDT) Received: (qmail 61806 invoked from network); 2 Jun 2009 20:32:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 2 Jun 2009 20:32:17 -0000 X-YMail-OSG: VVjoQ3EVM1lgni.eICnT5nBIdP3yqRp36YJYcXozf7TTxw_KAXxeCzpgv1xjMkmNFBsfX7.K6cjB_HnRa0AoCIAZPcytm6kBDGxxq8_YC5_tOxPyboY63vEBW8SPt41aaCpbOUawkCz_4Yd3fH5RAr641W7C6e2AvoSzqIqKGLvSwYK9CisCYxUlzDvkyr0HK8xiT9jVAs6aeZg7nPdlW4UeJepgVDAuT2zWi2ezAWswr.gJC4Y2gXvVtydtn8HZgbe.2jbcwMkYC2nVdDneQNdeU1hZBVwQCw56DkDWjewS3zRtHGIs5QDtmRVInqylz1lvKod2_IJ1Suz6KcMS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A258C4E.6000707@netconfcentral.com> Date: Tue, 02 Jun 2009 13:32:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com><1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> <001c01c9e3b2$b196be60$0601a8c0@allison> In-Reply-To: <001c01c9e3b2$b196be60$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 02 Jun 2009 20:32:19 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Ladislav Lhotka" > Cc: > Sent: Monday, June 01, 2009 2:03 PM > Subject: Re: [netmod] leafref issues >> What is needed is a variable binding -- the instance-identifier >> and the associated current value. Just knowing the value (leafref) >> or just knowing the ID (instance-identifier) is worthless. >> SNMP solved the notification varbind problem 2 decades ago. >> (How come NETCONF messed it up so badly?) > > Andy > > It's not really to do with notifications but with getting anything from > device to manager. SMI took the view that a device knowing nothing > of the data model could still make some sense of the data it received, > what its SYNTAX was, what value, where in the data tree it came from, > this applies to get, get-next, report, anything, something I have used > with success when I had gotten the contents of a proprietary MIB module, > such as a CISCO one:-) > I believe the OPS-NM area has received operator feedback requesting more info in a notification, not less. It is better to receive all the info needed to correlate an event at the same time, rather than getting some of it in a notification and the rest of it with subsequent polls. In NETCONF, the entire affected entry can be returned, but nobody is going to want to do this for big entries. One can always write description statements that indicate the semantic coupling between an instance-identifier leaf and 1 or more leafref sibling leafs which happen to have XPath targets which resolve to the same object. I prefer to avoid modeling really common semantics in description statements. But YANG has the extension-stmt for this sort of thing, so it is not really a big deal. > NETCONF takes the view that the manager must have the data model > to achieve even this, although with it, it can achieve more, just as an > SMI manager can. > > We could introduce varbinds into YANG, at least for notification; it is > only a complex type, of instance identifier and instance value. > YANG has two hard-wired complex types, but they are called list and container. They cannot be reused in any way like XSD complexType, so YANG does not call them types. > Tom Petch. >> Andy >> Andy From lhotka@cesnet.cz Wed Jun 3 01:55: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 6113C3A6F22 for ; Wed, 3 Jun 2009 01:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.594 X-Spam-Level: X-Spam-Status: No, score=0.594 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1b2J3fTXEou for ; Wed, 3 Jun 2009 01:55:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 81A673A6781 for ; Wed, 3 Jun 2009 01:55: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 253B1D800D1 for ; Wed, 3 Jun 2009 10:55:35 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Wed, 03 Jun 2009 10:55:34 +0200 Message-Id: <1244019335.6968.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 03 Jun 2009 08:55:53 -0000 Hi, I propose the following change to Sec. 6.4. I believe it is better to admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0 feature - rather than pretend that the trick with redefining the null namespace URI is legal. OLD ---------------------------------------------------------------------- XPath expressions are evaluated in the context of the current node, with the namespace of the current module defined as the null namespace. References to identifiers in external modules MUST be qualified with appropriate prefixes, and references to the current module and its submodules MAY use a prefix. ---------------------------------------------------------------------- NEW ---------------------------------------------------------------------- XPath expressions are evaluated in the context of the current node. The namespace URI of the current module is used for any unprefixed node name appearing in an XPath expression. 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. The above concept of default namespace is adopted from XPath 2.0 [XPATH2.0]. While it is a deviation from XPath 1.0, it 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. --------------------------------------------------------------------- Consequently, I propose to change the label for citing the XPath 1.0 spec to [XPATH1.0] and add the following reference: [XPATH2.0] Berglund A., Boag S., Chamberlin D., Fernandez M. F., Kay M., Robie J., and Simeon J., "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC-xpath20-20070123, Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Wed Jun 3 03:40: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 ECBA83A6C2D for ; Wed, 3 Jun 2009 03:40:44 -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 4FKyd0s9CVjD for ; Wed, 3 Jun 2009 03:40:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E55083A6AD3 for ; Wed, 3 Jun 2009 03:40:43 -0700 (PDT) X-AuditID: c1b4fb3e-b7b4bae00000395e-b6-4a265318153a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id AE.97.14686.813562A4; Wed, 3 Jun 2009 12:40:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 12:34:31 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 16:41:32 +0200 Message-ID: <4A253A1B.5000708@ericsson.com> Date: Tue, 02 Jun 2009 16:41:31 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <002d01c9dfba$55470a80$0601a8c0@allison> <4A201E34.2090103@netconfcentral.com> <1243844165.6392.65.camel@missotis> <20090601.102524.25062992.mbj@tail-f.com> In-Reply-To: <20090601.102524.25062992.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2009 14:41:32.0800 (UTC) FILETIME=[39020800:01C9E390] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] XPath issues X-BeenThere: netmod@ietf.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, 03 Jun 2009 10:40:45 -0000 Martin Bjorklund wrote: >> I understand it is an analogy of MIB instance identifiers, but what are >> actually their use cases in the context of NETCONF/YANG? > > When you need a reference to some unknown data in the tree. An > example from an RPC is . In a data model you might use it > in an access control model. Another example is the partial-lock reply or the data-model in the monitoring about partial-lock. Also I think we SHOULD have a mechanism to address/reference an arbitrary bit of YANG data, and store this reference in a compact way. Balazs From phil@juniper.net Wed Jun 3 10:19: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 CAB303A6E8D for ; Wed, 3 Jun 2009 10:19:54 -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 zNZTZWIeWYQ4 for ; Wed, 3 Jun 2009 10:19:54 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 1862D3A67DF for ; Wed, 3 Jun 2009 10:19:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSiawntP1jT7ELETYxBwjbju2nTEBsNqD@postini.com; Wed, 03 Jun 2009 10:19:56 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.340.0; Wed, 3 Jun 2009 10:18:15 -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, 3 Jun 2009 10:18:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 10:18:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 10:18:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n53HIDL53996; Wed, 3 Jun 2009 10:18: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 n53H7fKu092638; Wed, 3 Jun 2009 17:07:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906031707.n53H7fKu092638@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1244019335.6968.38.camel@missotis> Date: Wed, 3 Jun 2009 13:07:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2009 17:18:13.0948 (UTC) FILETIME=[46F11FC0:01C9E46F] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 03 Jun 2009 17:19:54 -0000 Ladislav Lhotka writes: >I propose the following change to Sec. 6.4. I believe it is better to >admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0 >feature - rather than pretend that the trick with redefining the null >namespace URI is legal. -1 to this. Defining the evaluation context is not a "trick". If it would, I would be against using it at all. Thanks, Phil From andy@netconfcentral.com Wed Jun 3 10:26: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 1FA653A704E for ; Wed, 3 Jun 2009 10:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 IU8QmijO5NSx for ; Wed, 3 Jun 2009 10:26:39 -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 4A2883A7040 for ; Wed, 3 Jun 2009 10:26:39 -0700 (PDT) Received: from [68.142.200.227] by n5.bullet.mud.yahoo.com with NNFMP; 03 Jun 2009 17:26:11 -0000 Received: from [68.142.201.69] by t8.bullet.mud.yahoo.com with NNFMP; 03 Jun 2009 17:26:11 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 03 Jun 2009 17:26:11 -0000 X-Yahoo-Newman-Id: 792423.18919.bm@omp421.mail.mud.yahoo.com Received: (qmail 56382 invoked from network); 3 Jun 2009 17:26:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 3 Jun 2009 17:26:10 -0000 X-YMail-OSG: ixvq7UMVM1mlKx7JAk8SJm5wAda_kszSGLZVDGopG6U5AwEtTPKlc4Q4fx25Cx2PZYTaMyldK1ub4k7ZaWEAh4wwpqvAsGzu381G8zqE2whWS0EQB7TL1jlghXOmJfgafv5QzKkCjuGobgxvcnFBSp1oW_dWEnNuAolkq6zH9x5AwMyfsCmbMtNEvdlLqEs4W8OuFO4iTLYfgys73QR52_C2tTKyMXMgpOrkPd4Fjjvp3Pwba94WHHerNP7KAKBfK4YF06VmLuQV1IVI X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A26B21B.2030202@netconfcentral.com> Date: Wed, 03 Jun 2009 10:25:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200906031707.n53H7fKu092638@idle.juniper.net> In-Reply-To: <200906031707.n53H7fKu092638@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 03 Jun 2009 17:26:40 -0000 Phil Shafer wrote: > Ladislav Lhotka writes: >> I propose the following change to Sec. 6.4. I believe it is better to >> admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0 >> feature - rather than pretend that the trick with redefining the null >> namespace URI is legal. > > -1 to this. Defining the evaluation context is not a "trick". If > it would, I would be against using it at all. > +1 on the -1 (0?) IMO, if a reference to XPath 2.0 is added, it will confuse people into thinking all of 2.0 is supported, not just 1 tiny part. > Thanks, > Phil Andy From phil@juniper.net Wed Jun 3 11:02: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 6DAE728C13E for ; Wed, 3 Jun 2009 11:02:06 -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 jn+p5Le0UMyN for ; Wed, 3 Jun 2009 11:02:05 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 95EBB3A694D for ; Wed, 3 Jun 2009 11:02:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSia6lAS/poo/OuIktm8Op/pLHokJTgR6@postini.com; Wed, 03 Jun 2009 11:02:07 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.340.0; Wed, 3 Jun 2009 10:56:33 -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, 3 Jun 2009 10:56:33 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 10:56:33 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 10:56:32 -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 n53HuVL73029; Wed, 3 Jun 2009 10:56:32 -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 n53HjxuH095095; Wed, 3 Jun 2009 17:45:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906031745.n53HjxuH095095@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A26B21B.2030202@netconfcentral.com> Date: Wed, 3 Jun 2009 13:45:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2009 17:56:32.0499 (UTC) FILETIME=[A0FC2C30:01C9E474] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 03 Jun 2009 18:02:06 -0000 Andy Bierman writes: >+1 on the -1 (0?) I oppose making this change. It's not needed and makes the draft less clear. Thanks, Phil From cfinss@dial.pipex.com Wed Jun 3 11: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 89DA23A69A4 for ; Wed, 3 Jun 2009 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 5UPW+KyBjZA5 for ; Wed, 3 Jun 2009 11:10:30 -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 5AE363A6DF9 for ; Wed, 3 Jun 2009 11:10:30 -0700 (PDT) X-Trace: 109737362/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.64/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.64 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: AuQEAOBYJko+vGlA/2dsb2JhbACDKVKLJ8MdCIQDBQ X-IronPort-AV: E=Sophos;i="4.41,299,1241391600"; d="scan'208";a="109737362" X-IP-Direction: IN Received: from 1cust64.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.64]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Jun 2009 19:10:23 +0100 Message-ID: <003f01c9e46e$0ab5ec80$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , "NETMOD Working Group" References: <1244019335.6968.38.camel@missotis> Date: Wed, 3 Jun 2009 19:05: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 Subject: Re: [netmod] default namespace in XPath 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: Wed, 03 Jun 2009 18:10:31 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "NETMOD Working Group" Sent: Wednesday, June 03, 2009 10:55 AM Subject: [netmod] default namespace in XPath > I propose the following change to Sec. 6.4. I believe it is better to > admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0 > feature - rather than pretend that the trick with redefining the null > namespace URI is legal. Sounds good. Be aware, as I am:-), that namespaces are also described in the context of XPath in 7.5.3 (must) and 7.19.5 (when) but are not described in 7.15 (augment), 9.9.2 (path) and 9.13 (instance-identifier) and whatever we end up with, I see and hear no reason why these five should be treated differently, ie all use just the description in 6.4 or all include additional text. Tom Petch > OLD > ---------------------------------------------------------------------- > XPath expressions are evaluated in the context of the current node, > with the namespace of the current module defined as the null > namespace. References to identifiers in external modules MUST be > qualified with appropriate prefixes, and references to the current > module and its submodules MAY use a prefix. > ---------------------------------------------------------------------- > > NEW > ---------------------------------------------------------------------- > XPath expressions are evaluated in the context of the current > node. The namespace URI of the current module is used for any > unprefixed node name appearing in an XPath expression. 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. > > The above concept of default namespace is adopted from XPath 2.0 > [XPATH2.0]. While it is a deviation from XPath 1.0, it 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. > --------------------------------------------------------------------- > > Consequently, I propose to change the label for citing the XPath 1.0 > spec to [XPATH1.0] and add the following reference: > > [XPATH2.0] > Berglund A., Boag S., Chamberlin D., Fernandez M. F., > Kay M., Robie J., and Simeon J., > "XML Path Language (XPath) 2.0", World Wide Web Consortium > Recommendation REC-xpath20-20070123, > > > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Wed Jun 3 11: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 EE6D83A6F23 for ; Wed, 3 Jun 2009 11:10:31 -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.627, 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 9sPjuHT6scEt for ; Wed, 3 Jun 2009 11:10:31 -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 F34653A6B17 for ; Wed, 3 Jun 2009 11:10:30 -0700 (PDT) X-Trace: 109737380/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.64/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.64 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: AuQEAOBYJko+vGlA/2dsb2JhbACDKVKLJ8MdCIQDBQ X-IronPort-AV: E=Sophos;i="4.41,299,1241391600"; d="scan'208";a="109737380" X-IP-Direction: IN Received: from 1cust64.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.64]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Jun 2009 19:10:28 +0100 Message-ID: <004001c9e46e$0c1e0800$0601a8c0@allison> From: "tom.petch" To: "David Partain" , References: <200905270847.17695.david.partain@ericsson.com> Date: Wed, 3 Jun 2009 19:05:52 +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 Subject: Re: [netmod] Working Group Last Call:draft-ietf-netmod-yang-types-03.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: Wed, 03 Jun 2009 18:10:32 -0000 ----- Original Message ----- From: "David Partain" To: Sent: Wednesday, May 27, 2009 8:47 AM Subject: [netmod] Working Group Last Call:draft-ietf-netmod-yang-types-03.txt > Dear all, > > This is the working group last call on the current working group document: > > - Common YANG Data Types: http://tools.ietf.org/html/draft-ietf-netmod-yang-types-03.txt > > The editor and the chairs think that this document is mature enough for WGLC. David^2, Mmmmmm I wonder if I read something similar about draft-ietf-netmod-yang-05.txt just recently. Whatever, for myself, I won't spend time reviewing this until I am clearer on where XPath and leafref (and perhaps mandatory, definitions, ...) are going in the base document. It is not a question of dependency, simply of having enough complexity up in the air for me already. Tom Petch > This WGLC will last until June 10, 2009. > > Please review and send comments to this list. > > Thanks. > > David^2 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Wed Jun 3 11:10: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 9DB093A6F23 for ; Wed, 3 Jun 2009 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.501, 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 o5-XTRhMV4rH for ; Wed, 3 Jun 2009 11:10:31 -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 996493A6D99 for ; Wed, 3 Jun 2009 11:10:31 -0700 (PDT) X-Trace: 109737384/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.64/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.64 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: AuQEAOBYJko+vGlA/2dsb2JhbACDKVKLJ8MdCII1gU4F X-IronPort-AV: E=Sophos;i="4.41,299,1241391600"; d="scan'208";a="109737384" X-IP-Direction: IN Received: from 1cust64.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.64]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Jun 2009 19:10:29 +0100 Message-ID: <004101c9e46e$0e372400$0601a8c0@allison> From: "tom.petch" To: "Lada" , "Martin Bjorklund" References: <1242894219.6931.59.camel@missotis><20090521.213717.193017582.mbj@tail-f.com><1242973685.6374.27.camel@missotis> <20090522.151526.32995613.mbj@tail-f.com> Date: Wed, 3 Jun 2009 19:06:24 +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] definitions 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: Wed, 03 Jun 2009 18:10:32 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Friday, May 22, 2009 3:15 PM > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Čt 21. 05. 2009 v 21:37 +0200: > > > The text says: > > > > > > The "import" statement makes definitions from one module available > > > inside another module or submodule. > > > > > > Could you propose text to make it more clear? > > > > The "import" statement makes identifiers from the namespace of the > > imported module available in the importing module. In particular, the > > importing module may > > > > o use groupings and typedefs defined at the top level of the imported > > module; > > > > o refer to features defined in the imported module; > > > > o use any data node of the imported module as the target node for the > > "augment" statement. > > > > Unlike "include", the "import" statement doesn't contribute the data > > tree from the imported to the importing module. > > I'm not sure this text is better than the current text. Does anyone > else have an opinion? Yes; both might be clearer:-( The bulleted list is an improvement, but I do not see "identifiers" as an improvement; it is more than identifiers, it is the identity, the concept that is being identified. Definitions is nearer the mark but still, for me, understates what is on offer. And in the last sentence, surely data tree is wrong; data node yes, but all in the schema tree. Tom Petch > > > BTW, RNG doesn't have 'import' does it? > > > > It's called "include". > > Exactly. YANG's include is more like RNG's include. So I don't see > why RNG users would be confused when YANG's import does not behave > like RNG's include. > > > /martin From cfinss@dial.pipex.com Wed Jun 3 11:10: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 23E023A6EA3 for ; Wed, 3 Jun 2009 11:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, 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 tKvl1gF6tAvX for ; Wed, 3 Jun 2009 11:10:33 -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 04D723A6B17 for ; Wed, 3 Jun 2009 11:10:32 -0700 (PDT) X-Trace: 109737398/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.64/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.64 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: AuQEAOBYJko+vGlA/2dsb2JhbACDKVKLJ8MdCIQDBQ X-IronPort-AV: E=Sophos;i="4.41,299,1241391600"; d="scan'208";a="109737398" X-IP-Direction: IN Received: from 1cust64.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.64]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Jun 2009 19:10:33 +0100 Message-ID: <004201c9e46e$0f082fa0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com><1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> <001c01c9e3b2$b196be60$0601a8c0@allison> <4A258C4E.6000707@netconfcentral.com> Date: Wed, 3 Jun 2009 19:07:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: Re: [netmod] leafref issues 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: Wed, 03 Jun 2009 18:10:34 -0000 ---- Original Message ----- From: "Andy Bierman" To: "tom.petch" Cc: "Ladislav Lhotka" ; Sent: Tuesday, June 02, 2009 10:32 PM > tom.petch wrote: > > ----- Original Message ----- > > From: "Andy Bierman" > > To: "Ladislav Lhotka" > > Cc: > > Sent: Monday, June 01, 2009 2:03 PM > > Subject: Re: [netmod] leafref issues > >> What is needed is a variable binding -- the instance-identifier > >> and the associated current value. Just knowing the value (leafref) > >> or just knowing the ID (instance-identifier) is worthless. > >> SNMP solved the notification varbind problem 2 decades ago. > >> (How come NETCONF messed it up so badly?) > > > > Andy > > > > It's not really to do with notifications but with getting anything from > > device to manager. SMI took the view that a device knowing nothing > > of the data model could still make some sense of the data it received, > > what its SYNTAX was, what value, where in the data tree it came from, > > this applies to get, get-next, report, anything, something I have used > > with success when I had gotten the contents of a proprietary MIB module, > > such as a CISCO one:-) > > > > I believe the OPS-NM area has received operator feedback > requesting more info in a notification, not less. > It is better to receive all the info needed to > correlate an event at the same time, rather than > getting some of it in a notification and the rest of > it with subsequent polls. > > In NETCONF, the entire affected entry can be returned, but > nobody is going to want to do this for big entries. > > One can always write description statements that indicate > the semantic coupling between an instance-identifier leaf > and 1 or more leafref sibling leafs which happen to > have XPath targets which resolve to the same object. > I prefer to avoid modeling really common semantics in > description statements. But YANG has the extension-stmt > for this sort of thing, so it is not really a big deal. > > > NETCONF takes the view that the manager must have the data model > > to achieve even this, although with it, it can achieve more, just as an > > SMI manager can. > > > > We could introduce varbinds into YANG, at least for notification; it is > > only a complex type, of instance identifier and instance value. > > YANG has two hard-wired complex types, > but they are called list and container. > They cannot be reused in any way like XSD complexType, > so YANG does not call them types. Andy True but rather I was referring, in my not very explicit way, to " YANG permits the definition of complex types using reusable grouping of nodes." Alternatively, we could say that the data modeller must design the data tree to make notifications straightforward, that is that there is in the data tree a set of objects which form a notification, eg a grouping{} or a container{}, and it is this set, possibly plus others, that must appear as one in a notification eg for an interface up or down, the set might be admin status, oper status, interface number, interface description, last error. The set would have a common index/path. It makes the notification tail wag the configuration dog, but if notifications are important enough, then it is worth it. And it would be simpler to specify than having a more generic mechanism which allows an arbitrary selection of objects to be brought together from arbitrary places in the data tree to form a notification, each with a potentially different index/path. Tom Petch > > Tom Petch. > >> Andy > >> > > Andy > From andy@netconfcentral.com Wed Jun 3 11:41: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 39B983A6ED3 for ; Wed, 3 Jun 2009 11:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 smz7bYu-k4uL for ; Wed, 3 Jun 2009 11:41:09 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 10C7A3A6EA3 for ; Wed, 3 Jun 2009 11:41:09 -0700 (PDT) Received: from [68.142.200.225] by n17.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2009 18:41:08 -0000 Received: from [68.142.201.243] by t6.bullet.mud.yahoo.com with NNFMP; 03 Jun 2009 18:41:08 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 03 Jun 2009 18:41:08 -0000 X-Yahoo-Newman-Id: 611359.52450.bm@omp404.mail.mud.yahoo.com Received: (qmail 47677 invoked from network); 3 Jun 2009 18:41:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 3 Jun 2009 18:41:07 -0000 X-YMail-OSG: 7KeMZvYVM1lguHlUZmMOKUS6T5R3r65XN63mKINVmHTep1Z4TYfcMbUHB4yRMNpw54kOZ34pnL6dMKXWCDQxhe_p564_PyUumfsC6xilxZtFOGI_7dZvZDzPl_7rBFhmHj6zd1PfiZCBW1yKFc4Elv0ZgC.0M20hbrUl3IVI16Uc.TQ.r6ScjA4afkoP3ykw_NesSxw55PmbCT0Hkn1SCqAA.Q7dbwylS9DB9euHrr5NrksM_k3pSwUp4mtfRQN4Ez0HFKljWIdbqkSdd.BOZQGugVAGy8EI2CRb.KABBlVVzdLXmbEdOFC_5WnKWlVNLoGVy9F9TGtLBRnUZVZmGndhsB2RIo059wWKenXF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A26C3AC.1070609@netconfcentral.com> Date: Wed, 03 Jun 2009 11:40:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <4A1F93B1.1040909@netconfcentral.com> <20090529.103004.12049218.mbj@tail-f.com> <4A1FF122.8000304@netconfcentral.com> <20090529.194815.74630685.mbj@tail-f.com><1243844855.6392.69.camel@missotis> <4A23C386.4020905@netconfcentral.com> <001c01c9e3b2$b196be60$0601a8c0@allison> <4A258C4E.6000707@netconfcentral.com> <004201c9e46e$0f082fa0$0601a8c0@allison> In-Reply-To: <004201c9e46e$0f082fa0$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref issues X-BeenThere: netmod@ietf.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, 03 Jun 2009 18:41:10 -0000 tom.petch wrote: > ---- Original Message ----- > From: "Andy Bierman" > To: "tom.petch" > Cc: "Ladislav Lhotka" ; > Sent: Tuesday, June 02, 2009 10:32 PM > >> tom.petch wrote: >>> ----- Original Message ----- >>> From: "Andy Bierman" >>> To: "Ladislav Lhotka" >>> Cc: >>> Sent: Monday, June 01, 2009 2:03 PM >>> Subject: Re: [netmod] leafref issues >>>> What is needed is a variable binding -- the instance-identifier >>>> and the associated current value. Just knowing the value (leafref) >>>> or just knowing the ID (instance-identifier) is worthless. >>>> SNMP solved the notification varbind problem 2 decades ago. >>>> (How come NETCONF messed it up so badly?) >>> Andy >>> >>> It's not really to do with notifications but with getting anything from >>> device to manager. SMI took the view that a device knowing nothing >>> of the data model could still make some sense of the data it received, >>> what its SYNTAX was, what value, where in the data tree it came from, >>> this applies to get, get-next, report, anything, something I have used >>> with success when I had gotten the contents of a proprietary MIB module, >>> such as a CISCO one:-) >>> >> I believe the OPS-NM area has received operator feedback >> requesting more info in a notification, not less. >> It is better to receive all the info needed to >> correlate an event at the same time, rather than >> getting some of it in a notification and the rest of >> it with subsequent polls. >> >> In NETCONF, the entire affected entry can be returned, but >> nobody is going to want to do this for big entries. >> >> One can always write description statements that indicate >> the semantic coupling between an instance-identifier leaf >> and 1 or more leafref sibling leafs which happen to >> have XPath targets which resolve to the same object. >> I prefer to avoid modeling really common semantics in >> description statements. But YANG has the extension-stmt >> for this sort of thing, so it is not really a big deal. >> >>> NETCONF takes the view that the manager must have the data model >>> to achieve even this, although with it, it can achieve more, just as an >>> SMI manager can. >>> >>> We could introduce varbinds into YANG, at least for notification; it is >>> only a complex type, of instance identifier and instance value. >> YANG has two hard-wired complex types, >> but they are called list and container. >> They cannot be reused in any way like XSD complexType, >> so YANG does not call them types. > > Andy > > True but rather I was referring, in my not very explicit way, to > " YANG permits the definition of complex types using reusable grouping > of nodes." > > Alternatively, we could say that the data modeller must design the data tree to > make notifications straightforward, that is that there is in the data tree a set > of objects which form a notification, eg a grouping{} or a container{}, and it > is this set, possibly plus others, that must appear as one in a notification eg > for an interface up or down, the set might be admin status, oper status, > interface number, interface description, last error. The set would have a common > index/path. > > It makes the notification tail wag the configuration dog, but if notifications > are important enough, then it is worth it. And it would be simpler to specify > than having a more generic mechanism which allows an arbitrary selection > of objects to be brought together from arbitrary places in the data tree > to form a notification, each with a potentially different index/path. > I do not agree this is a good use-case for grouping/uses. This is simply cut-and-paste with the ability to 'refine' config true to config false. SMIv2 has "MAX-ACCESS notify-only" to deal with this problem. All SNMP NOTIFICATION varbinds are pointers to database objects, except these special objects, which can be used by any notification definition. We should not say how the data modeler MUST design anything, beyond what is already there. This is not a real problem, since any application can be hard-wired to 'understand' that notification payloads are just copies, not in any way representing some actual config subtree in the system. Extensions can be used in conjunction with description statements to define semantic coupling of notification payload siblings, if that is desired. > Tom Petch Andy From lhotka@cesnet.cz Wed Jun 3 12:47: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 B2B563A692D for ; Wed, 3 Jun 2009 12:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.209 X-Spam-Level: X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[AWL=1.041, 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 x-4LWZ6Cd+-8 for ; Wed, 3 Jun 2009 12:47:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DE3143A6D0E for ; Wed, 3 Jun 2009 12:47:09 -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 9A67DD800C5; Wed, 3 Jun 2009 21:46:57 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200906031707.n53H7fKu092638@idle.juniper.net> References: <200906031707.n53H7fKu092638@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 03 Jun 2009 21:46:59 +0200 Message-Id: <1244058419.6968.49.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 03 Jun 2009 19:47:10 -0000 Phil Shafer píše v St 03. 06. 2009 v 13:07 -0400: > Ladislav Lhotka writes: > >I propose the following change to Sec. 6.4. I believe it is better to > >admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0 > >feature - rather than pretend that the trick with redefining the null > >namespace URI is legal. > > -1 to this. Defining the evaluation context is not a "trick". If > it would, I would be against using it at all. You should then. Saying that "null namespace URI" is a normal (non-null!) namespace URI is a very dirty trick. The default namespace is NOT part of evaluation context in XPath 1.0. XPath 2.0 has this [Definition: Default element/type namespace. This is a namespace URI or "none". The namespace URI, if present, is used for any unprefixed QName appearing in a position where an element or type name is expected.] In XPath 1.0, "none" is the only possibility and this is what "null namespace URI" denotes. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Jun 3 15:15:36 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 ADB173A6D8A for ; Wed, 3 Jun 2009 15:15:36 -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 SEYC1+HfGpMX for ; Wed, 3 Jun 2009 15:15:36 -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 856BB3A6CF7 for ; Wed, 3 Jun 2009 15:15:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9512261600B; Thu, 4 Jun 2009 00:15:35 +0200 (CEST) Date: Thu, 04 Jun 2009 00:15:46 +0200 (CEST) Message-Id: <20090604.001546.39671270.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1244058419.6968.49.camel@missotis> References: <200906031707.n53H7fKu092638@idle.juniper.net> <1244058419.6968.49.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] default namespace in XPath X-BeenThere: netmod@ietf.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, 03 Jun 2009 22:15:36 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgU3QgMDMuIDA2LiAyMDA5IHYgMTM6MDcgLTA0MDA6DQo+ID4gTGFkaXNsYXYgTGhv dGthIHdyaXRlczoNCj4gPiA+SSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIFNlYy4g Ni40LiBJIGJlbGlldmUgaXQgaXMgYmV0dGVyIHRvDQo+ID4gPmFkbWl0IGEgZGV2aWF0aW9uIGZy b20gWFBhdGggMS4wIC0gaW4gZmFjdCwgYWRvcHRpb24gb2YgYW4gWFBhdGggMi4wDQo+ID4gPmZl YXR1cmUgLSByYXRoZXIgdGhhbiBwcmV0ZW5kIHRoYXQgdGhlIHRyaWNrIHdpdGggcmVkZWZpbmlu ZyB0aGUgbnVsbA0KPiA+ID5uYW1lc3BhY2UgVVJJIGlzIGxlZ2FsLg0KPiA+IA0KPiA+IC0xIHRv IHRoaXMuICBEZWZpbmluZyB0aGUgZXZhbHVhdGlvbiBjb250ZXh0IGlzIG5vdCBhICJ0cmljayIu ICBJZg0KPiA+IGl0IHdvdWxkLCBJIHdvdWxkIGJlIGFnYWluc3QgdXNpbmcgaXQgYXQgYWxsLg0K PiANCj4gWW91IHNob3VsZCB0aGVuLiBTYXlpbmcgdGhhdCAibnVsbCBuYW1lc3BhY2UgVVJJIiBp cyBhIG5vcm1hbA0KPiAobm9uLW51bGwhKSBuYW1lc3BhY2UgVVJJIGlzIGEgdmVyeSBkaXJ0eSB0 cmljay4gVGhlIGRlZmF1bHQgbmFtZXNwYWNlDQo+IGlzIE5PVCBwYXJ0IG9mIGV2YWx1YXRpb24g Y29udGV4dCBpbiBYUGF0aCAxLjAuDQoNCk15IGludGVycHJldGF0aW9uIG9mIHRoZSBhcmd1bWVu dHMgc28gZmFyIGlzIHRoYXQgTGFkYSBkb2Vzbid0DQpsaWtlIHRoZSB0ZXJtICJudWxsIG5hbWVz cGFjZSIgYW5kIFBoaWwgYW5kIEFuZHkgdGhpbmtzIHRoZSByZWZlcmVuY2UNCnRvIFhQYXRoIDIu MCBpcyBtaXNsZWFkaW5nLg0KDQpTbyBjb3VsZCB3ZSByZXBsYWNlIHRoZSBjdXJyZW50IHRleHQg d2l0aCBqdXN0IHRoZSBmaXJzdCBvZiBMYWRhJ3MNCnBhcmFncmFwaHM6DQoNCk9MRA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICAgWFBhdGggZXhwcmVzc2lvbnMgYXJlIGV2YWx1YXRlZCBpbiB0aGUgY29udGV4 dCBvZiB0aGUgY3VycmVudCBub2RlLA0KICAgd2l0aCB0aGUgbmFtZXNwYWNlIG9mIHRoZSBjdXJy ZW50IG1vZHVsZSBkZWZpbmVkIGFzIHRoZSBudWxsDQogICBuYW1lc3BhY2UuICBSZWZlcmVuY2Vz IHRvIGlkZW50aWZpZXJzIGluIGV4dGVybmFsIG1vZHVsZXMgTVVTVCBiZQ0KICAgcXVhbGlmaWVk IHdpdGggYXBwcm9wcmlhdGUgcHJlZml4ZXMsIGFuZCByZWZlcmVuY2VzIHRvIHRoZSBjdXJyZW50 DQogICBtb2R1bGUgYW5kIGl0cyBzdWJtb2R1bGVzIE1BWSB1c2UgYSBwcmVmaXguDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCk5FVw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgWFBhdGggZXhwcmVzc2lvbnMgYXJlIGV2 YWx1YXRlZCBpbiB0aGUgY29udGV4dCBvZiB0aGUgY3VycmVudA0KICAgbm9kZS4gVGhlIG5hbWVz cGFjZSBVUkkgb2YgdGhlIGN1cnJlbnQgbW9kdWxlIGlzIHVzZWQgZm9yIGFueQ0KICAgdW5wcmVm aXhlZCBub2RlIG5hbWUgYXBwZWFyaW5nIGluIGFuIFhQYXRoIGV4cHJlc3Npb24uIFJlZmVyZW5j ZXMNCiAgIHRvIGlkZW50aWZpZXJzIGRlZmluZWQgaW4gZXh0ZXJuYWwgbW9kdWxlcyBNVVNUIGJl IHF1YWxpZmllZCB3aXRoDQogICBhcHByb3ByaWF0ZSBwcmVmaXhlcywgYW5kIHJlZmVyZW5jZXMg dG8gaWRlbnRpZmllcnMgZGVmaW5lZCBpbiB0aGUNCiAgIGN1cnJlbnQgbW9kdWxlIGFuZCBpdHMg c3VibW9kdWxlcyBNQVkgdXNlIGEgcHJlZml4Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQovbWFydGlu DQo= From phil@juniper.net Wed Jun 3 22:19: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 C2CCA3A6ED1 for ; Wed, 3 Jun 2009 22:19:46 -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 FA6b2MAB-b2w for ; Wed, 3 Jun 2009 22:19:45 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id D63A63A7063 for ; Wed, 3 Jun 2009 22:19:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSidZaxHE81gRJHQpkFbuASuCQAVfds/A@postini.com; Wed, 03 Jun 2009 22:19:43 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.340.0; Wed, 3 Jun 2009 22:15: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, 3 Jun 2009 22:15:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 22:15:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 22:15: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 n545FEL85526; Wed, 3 Jun 2009 22:15:14 -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 n5454fNm001340; Thu, 4 Jun 2009 05:04:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906040504.n5454fNm001340@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090604.001546.39671270.mbj@tail-f.com> Date: Thu, 4 Jun 2009 01:04:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Jun 2009 05:15:14.0864 (UTC) FILETIME=[7167F300:01C9E4D3] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 05:19:46 -0000 Martin Bjorklund writes: >My interpretation of the arguments so far is that Lada doesn't >like the term "null namespace" and Phil and Andy thinks the reference >to XPath 2.0 is misleading. I think we used this term to jibe with XPath: XPath fully supports XML Namespaces [XML Names]. Thus, the name of a node is modeled as a pair consisting of a local part and a possibly null namespace URI; this is called an expanded-name. The data model is described in detail in [5 Data Model]. But I think you are right that we should avoid this term. It isn't used as a complete term but as a "null" "namespace URI". >So could we replace the current text with just the first of Lada's >paragraphs: > >OLD >---------------------------------------------------------------------- > XPath expressions are evaluated in the context of the current node, > with the namespace of the current module defined as the null > namespace. References to identifiers in external modules MUST be > qualified with appropriate prefixes, and references to the current > module and its submodules MAY use a prefix. >---------------------------------------------------------------------- > >NEW >---------------------------------------------------------------------- > XPath expressions are evaluated in the context of the current > node. The namespace URI of the current module is used for any > unprefixed node name appearing in an XPath expression. 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. >--------------------------------------------------------------------- The xslt spec defines the evaluation context as: In XSLT, an outermost expression (i.e. an expression that is not part of another expression) gets its context as follows: - the context node comes from the current node - the context position comes from the position of the current node in the current node list; the first position is 1 - the context size comes from the size of the current node list - the variable bindings are the bindings in scope on the element which has the attribute in which the expression occurs (see [11 Variables and Parameters]) - the set of namespace declarations are those in scope on the element which has the attribute in which the expression occurs; this includes the implicit declaration of the prefix xml required by the the XML Namespaces Recommendation [XML Names]; the default namespace (as declared by xmlns) is not part of this set - the function library consists of the core function library together with the additional functions defined in [12 Additional Functions] and extension functions as described in [14 Extensions]; it is an error for an expression to include a call to any other function We should mimic parts of this text, but repair the fifth bullet to read "the module's namespace will be used as the default namespace is used to qualify any QName that has no prefix." Something like: In YANG, an outermost expression (i.e. an expression that is not part of another expression) gets its context as follows: - the context node is the current database node - the context position comes from the position of the current node within the current node list; the first position is 1 - the context size comes from the size of the current node list - the variable bindings are limited to $current, which is defined as the current node - the set of namespace declarations are those which are imported in the current module or submodule, along with the prefixes under which they were imported; this includes the implicit declaration of the prefix xml required by the the XML Namespaces Recommendation [XML Names]; the module's namespace will be used as the default namespace is used to qualify any QName that has no prefix Thanks, Phil From lhotka@cesnet.cz Thu Jun 4 00:09: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 5B04F3A6F4B for ; Thu, 4 Jun 2009 00:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.892, 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 8Srsr9S12U8x for ; Thu, 4 Jun 2009 00:09:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 448B83A6C42 for ; Thu, 4 Jun 2009 00:09:32 -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 02E32D800BD; Thu, 4 Jun 2009 09:09:33 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090604.001546.39671270.mbj@tail-f.com> References: <200906031707.n53H7fKu092638@idle.juniper.net> <1244058419.6968.49.camel@missotis> <20090604.001546.39671270.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 04 Jun 2009 09:09:33 +0200 Message-Id: <1244099373.6524.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] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 07:09:33 -0000 Martin Bjorklund píše v Čt 04. 06. 2009 v 00:15 +0200: > Ladislav Lhotka wrote: > > Phil Shafer píše v St 03. 06. 2009 v 13:07 -0400: > > > Ladislav Lhotka writes: > > > >I propose the following change to Sec. 6.4. I believe it is better to > > > >admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0 > > > >feature - rather than pretend that the trick with redefining the null > > > >namespace URI is legal. > > > > > > -1 to this. Defining the evaluation context is not a "trick". If > > > it would, I would be against using it at all. > > > > You should then. Saying that "null namespace URI" is a normal > > (non-null!) namespace URI is a very dirty trick. The default namespace > > is NOT part of evaluation context in XPath 1.0. > > My interpretation of the arguments so far is that Lada doesn't > like the term "null namespace" and Phil and Andy thinks the reference Rather, I don't like misinterpreting the following sentence from XPath 1.0 spec in the way that the "null namespace URI" can be arbitrarily defined: This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). > to XPath 2.0 is misleading. > > So could we replace the current text with just the first of Lada's > paragraphs: > > OLD > ---------------------------------------------------------------------- > XPath expressions are evaluated in the context of the current node, > with the namespace of the current module defined as the null > namespace. References to identifiers in external modules MUST be > qualified with appropriate prefixes, and references to the current > module and its submodules MAY use a prefix. > ---------------------------------------------------------------------- > > NEW > ---------------------------------------------------------------------- > XPath expressions are evaluated in the context of the current > node. The namespace URI of the current module is used for any > unprefixed node name appearing in an XPath expression. 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. > --------------------------------------------------------------------- > I am fine with this, but XML-savvy readers will notice that this is not allowed in XPath 1.0, which YANG claims to rely on. So I thought it would be useful to explain that this convention is perfectly OK in YANG because all identifiers belong to a non-null namespace, so the ambiguity between default and null namespace URI (which is why the above rule was accepted in XPath 1.0) can never arise. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jun 4 00:22: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 57FC03A6D48 for ; Thu, 4 Jun 2009 00:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=1.253, 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 lOzGMnU77RVn for ; Thu, 4 Jun 2009 00:22: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 7A9B33A6C83 for ; Thu, 4 Jun 2009 00:22:01 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 3EF05616004; Thu, 4 Jun 2009 09:21:58 +0200 (CEST) Date: Thu, 04 Jun 2009 09:20:06 +0200 (CEST) Message-Id: <20090604.092006.189072679.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200906040504.n5454fNm001340@idle.juniper.net> References: <20090604.001546.39671270.mbj@tail-f.com> <200906040504.n5454fNm001340@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] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 07:22:02 -0000 Phil Shafer wrote: > We should mimic parts of this text, but repair the fifth bullet to > read "the module's namespace will be used as the default namespace > is used to qualify any QName that has no prefix." > > Something like: > > In YANG, an outermost expression (i.e. an expression that is > not part of another expression) gets its context as follows: Can we simplify this - what is an expression that is part of another expression in YANG? In YANG, an XPath expression gets its context as follows: > - the context node is the current database node Ok. > - the context position comes from the position > of the current node within the current node list; > the first position is 1 > - the context size comes from the size of the current node list I must admit that I do not understand this. What exactly is the "current node list"? Also, stating that the first position is 1 is redundant, since that how it works in XPath. > - the variable bindings are limited to $current, which is defined > as the current node We got rid of $current in favor of current(), so we should say that the variable bindings are empty. > - the set of namespace declarations are those which are imported > in the current module or submodule, along with the prefixes under > which they were imported; this includes the implicit declaration > of the prefix xml required by the the XML Namespaces No, we should not have the prefix 'xml' implicitly declared! > Recommendation [XML Names]; the module's namespace will be used > as the default namespace is used to qualify any QName that has > no prefix /martin From mbj@tail-f.com Thu Jun 4 00:29: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 AB8CC3A6C83 for ; Thu, 4 Jun 2009 00:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=0.836, 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 4J8c6NFk9NrT for ; Thu, 4 Jun 2009 00:29: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 4A09228C291 for ; Thu, 4 Jun 2009 00:29:24 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 865DD61600B; Thu, 4 Jun 2009 09:29:14 +0200 (CEST) Date: Thu, 04 Jun 2009 09:29:14 +0200 (CEST) Message-Id: <20090604.092914.249603947.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1244099373.6524.17.camel@missotis> References: <1244058419.6968.49.camel@missotis> <20090604.001546.39671270.mbj@tail-f.com> <1244099373.6524.17.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] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 07:29:26 -0000 Ladislav Lhotka wrote: > I am fine with this, but XML-savvy readers will notice that this is not > allowed in XPath 1.0, which YANG claims to rely on. So I thought it > would be useful to explain that this convention is perfectly OK in YANG > because all identifiers belong to a non-null namespace, so the ambiguity > between default and null namespace URI (which is why the above rule was > accepted in XPath 1.0) can never arise. I agree with you; I also think it would be useful to state this. Maybe slightly change the words to: The above concept of default namespace is adopted from XPath 2.0 [XPATH2.0]. It 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. I am not worried by having XPath 2.0 as a non-normative reference. /martin From lhotka@cesnet.cz Thu Jun 4 00:39: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 89EB43A6B0F for ; Thu, 4 Jun 2009 00:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.781, 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 yJKaY0Bc7mCc for ; Thu, 4 Jun 2009 00:39:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4FB7F3A683A for ; Thu, 4 Jun 2009 00:39:44 -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 52753D800BD; Thu, 4 Jun 2009 09:39:43 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <004101c9e46e$0e372400$0601a8c0@allison> References: <1242894219.6931.59.camel@missotis> <20090521.213717.193017582.mbj@tail-f.com> <1242973685.6374.27.camel@missotis> <20090522.151526.32995613.mbj@tail-f.com> <004101c9e46e$0e372400$0601a8c0@allison> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 04 Jun 2009 09:39:42 +0200 Message-Id: <1244101182.6524.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] definitions X-BeenThere: netmod@ietf.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, 04 Jun 2009 07:39:45 -0000 tom.petch píše v St 03. 06. 2009 v 19:06 +0200: > > > The "import" statement makes identifiers from the namespace of the > > > imported module available in the importing module. In particular, the > > > importing module may > > > > > > o use groupings and typedefs defined at the top level of the imported > > > module; > > > > > > o refer to features defined in the imported module; > > > > > > o use any data node of the imported module as the target node for the > > > "augment" statement. > > > > > > Unlike "include", the "import" statement doesn't contribute the data > > > tree from the imported to the importing module. > > > > I'm not sure this text is better than the current text. Does anyone > > else have an opinion? > > Yes; both might be clearer:-( The bulleted list is an improvement, but I do not > see "identifiers" as an improvement; it is more than identifiers, it is the > identity, the concept that is being identified. Definitions is nearer the mark > but still, for me, understates what is on offer. Yes, but it is important to stress that the schema tree is not imported. Can you suggest another formulation? > > And in the last sentence, surely data tree is wrong; data node yes, but all in > the schema tree. You are right. Lada > > Tom Petch > > > > > BTW, RNG doesn't have 'import' does it? > > > > > > It's called "include". > > > > Exactly. YANG's include is more like RNG's include. So I don't see > > why RNG users would be confused when YANG's import does not behave > > like RNG's include. > > > > > > /martin > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Thu Jun 4 01:11:41 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 6F32728C26C for ; Thu, 4 Jun 2009 01:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3UJhD4OyolL for ; Thu, 4 Jun 2009 01:11:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 427F73A67A7 for ; Thu, 4 Jun 2009 01:11:40 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-cd-4a278165cef0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7E.44.05133.561872A4; Thu, 4 Jun 2009 10:10: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); Thu, 4 Jun 2009 10:09:37 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 10:09:37 +0200 Message-ID: <4A278141.6030807@ericsson.com> Date: Thu, 04 Jun 2009 10:09:37 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@netconfcentral.com> <20090527.211219.236583686.mbj@tail-f.com> <4A1DA01A.2090809@netconfcentral.com> In-Reply-To: <4A1DA01A.2090809@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2009 08:09:37.0636 (UTC) FILETIME=[CDB44240:01C9E4EB] X-Brightmail-Tracker: AAAAAA== Subject: [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: Thu, 04 Jun 2009 08:11:41 -0000 Hello, 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. Balazs Andy Bierman wrote: > (Think I posted this 2 or 3 times already. > > > notification foo { > > varbind a { > // 5 clauses, path mandatory, showing the defaults > path "/interfaces/interface/ifMtu"; > status current; > description "this is like an SMIv2 OBJECTS entry"; > reference "..."; > mandatory false; > } > > varbind b { > path "/interfaces/interface/ifInOctets"; > mandatory true; > } > > leaf local-var { > description > "this is likse an SMIv2 a notify-only data definition."; > type string; > } > } > > > > ... > > > /if:interfaces/if:interface[if:name='eth0']/if:ifMtu > > 1500 > > > > /if:interfaces/if:interface[if:name='eth0']/if:ifInOctets > > 38765552 > > > interface eth0 status string inserted here > > > > From j.schoenwaelder@jacobs-university.de Thu Jun 4 03: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 A1DEE3A6ADA for ; Thu, 4 Jun 2009 03:44:14 -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_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 mwZOXgox1Ili for ; Thu, 4 Jun 2009 03:44:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F11623A6959 for ; Thu, 4 Jun 2009 03:44:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B9B9C00E9; Thu, 4 Jun 2009 12:44:14 +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 FGT3oyWg5B9z; Thu, 4 Jun 2009 12:44:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B9FCC00B7; Thu, 4 Jun 2009 12:44:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7330CB2CE05; Thu, 4 Jun 2009 12:44:12 +0200 (CEST) Date: Thu, 4 Jun 2009 12:44:12 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090604104412.GC21823@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <4A1D5742.3000201@netconfcentral.com> <20090527.182615.118040817.mbj@tail-f.com> <4A1D7384.6030700@netconfcentral.com> <20090527.211219.236583686.mbj@tail-f.com> <4A1DA01A.2090809@netconfcentral.com> <4A278141.6030807@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A278141.6030807@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) 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 Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 10:44:14 -0000 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: a) Can the path point to arbitrary nodes or just leafs? b) Can this new feature be used in other contexts, e.g., operation (unfortunately called rpcs), perhaps even in the data tree? c) What are the reason for allowing/disallowing this feature in different YANG contexts? d) Is it possible to define a grouping using existing YANG constructs that essentially provides you the name/value pair you are looking for with existing mechanisms? If not, why not and can this be fixed? /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 Jun 4 03:49:36 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 C70293A6A41 for ; Thu, 4 Jun 2009 03:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=0.627, 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 CPBt5n5CIil4 for ; Thu, 4 Jun 2009 03:49:36 -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 125C83A69ED for ; Thu, 4 Jun 2009 03:49:36 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 2D82F616015; Thu, 4 Jun 2009 12:49:37 +0200 (CEST) Date: Thu, 04 Jun 2009 12:49:37 +0200 (CEST) Message-Id: <20090604.124937.28006847.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090604104412.GC21823@elstar.local> References: <4A1DA01A.2090809@netconfcentral.com> <4A278141.6030807@ericsson.com> <20090604104412.GC21823@elstar.local> 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] 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: Thu, 04 Jun 2009 10:49:36 -0000 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. /martin From andy@netconfcentral.com Thu Jun 4 05:19: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 C1CE73A7066 for ; Thu, 4 Jun 2009 05:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 NT762OlnfbzT for ; Thu, 4 Jun 2009 05:19:38 -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 750CD3A6B3D for ; Thu, 4 Jun 2009 05:18:49 -0700 (PDT) Received: (qmail 55015 invoked from network); 4 Jun 2009 12:18:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 4 Jun 2009 12:18:49 -0000 X-YMail-OSG: mNFk0CEVM1mXQLrTv.JifRWyMSl660thAMlwMpwgelUWc_zjkqZS_eI0bB49edv_jAyVIx5qX1bnK0eQw5RMYnWy6JPCyZipF0M_Qf_yIIqddfDvTDP0iQJJ6XPK7YQ1Z9jBhmYNd2_jz.MF5IO68iQp7GEx1hwMbZUm9LWvLVLgDqcleCBmE0ZNY5H3CbwWi8ofYoFQN8UsoqiD3vG4RIYYCLHK5WZfWjSz4KatMHoEu8hPovmc7sgqbdBaghuWzp7SIc6RQcQyHn6OqxNS4LUfibgsMRD7APCyEQlzIQ7_iu_ws7.pYkb7UpHQvuXvpPObZT6Jfx5dwLKoHmoxVlVJn303CVo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A27BBA6.1000206@netconfcentral.com> Date: Thu, 04 Jun 2009 05:18:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <4A1DA01A.2090809@netconfcentral.com> <4A278141.6030807@ericsson.com> <20090604104412.GC21823@elstar.local> <20090604.124937.28006847.mbj@tail-f.com> In-Reply-To: <20090604.124937.28006847.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Thu, 04 Jun 2009 12:19:38 -0000 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. > > We can leave this out, and wait until later. That doesn't mean leafref is going to work for notifications. Leafref is a mess. > > /martin Andy From phil@juniper.net Thu Jun 4 06:54: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 2B71D3A7090 for ; Thu, 4 Jun 2009 06:54:18 -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 rwEyxrHTO7qs for ; Thu, 4 Jun 2009 06:54:17 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B7BE828C0E8 for ; Thu, 4 Jun 2009 06:53:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSifRwnJbYHY4DuxB5FvfENTeLoKxeGR/@postini.com; Thu, 04 Jun 2009 06:53:49 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.340.0; Thu, 4 Jun 2009 06:49:06 -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, 4 Jun 2009 06:49:06 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 06:49:06 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 06:49:05 -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 n54Dn4L34476; Thu, 4 Jun 2009 06:49:04 -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 n54DcVVF004110; Thu, 4 Jun 2009 13:38:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906041338.n54DcVVF004110@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090604.092914.249603947.mbj@tail-f.com> Date: Thu, 4 Jun 2009 09:38:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Jun 2009 13:49:05.0568 (UTC) FILETIME=[39F00A00:01C9E51B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 13:54:18 -0000 Martin Bjorklund writes: > The above concept of default namespace is adopted from XPath 2.0 > [XPATH2.0]. It 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. I disagree, and see this as false. We did not adopt this from xpath-2.0. We copied xslt's use of xpath, where xslt defines the evaluation context for xpath expressions. No one even noticed how xpath-2.0 worked until much later. We mimic xslt and xslt uses xpath-1.0, so I'm completely surprised that this continues to be seen as a sticking point. Thanks, Phil From phil@juniper.net Thu Jun 4 06:56: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 AB6DB3A6E1B for ; Thu, 4 Jun 2009 06:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, FRT_SOMA2=2.199, 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 xfqUh1kMFhus for ; Thu, 4 Jun 2009 06:56:25 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 175D23A6B0B for ; Thu, 4 Jun 2009 06:56:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSifSfiHHCbdDS0bEVs33vqvygX0iUX0x@postini.com; Thu, 04 Jun 2009 06:56:24 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.340.0; Thu, 4 Jun 2009 06:45:15 -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, 4 Jun 2009 06:45:14 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 06:45:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 06:45: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 n54DjDL32817; Thu, 4 Jun 2009 06:45: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 n54DYeji004079; Thu, 4 Jun 2009 13:34:40 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906041334.n54DYeji004079@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090604.092006.189072679.mbj@tail-f.com> Date: Thu, 4 Jun 2009 09:34:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Jun 2009 13:45:14.0041 (UTC) FILETIME=[AFEFD290:01C9E51A] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 13:56:29 -0000 Martin Bjorklund writes: >Can we simplify this - what is an expression that is part of another >expression in YANG? must foo/goo[name != "fish"]; The context being defined is that of the outermost expression (goo), not the inner (name != "fish"). Note this is recursive, but rarely used (foo/goo[zoo/moo[name == "fish"]]). >> - the context size comes from the size of the current node list > >I must admit that I do not understand this. What exactly is the >"current node list"? Also, stating that the first position is 1 is >redundant, since that how it works in XPath. context size defines the value for "last()". >We got rid of $current in favor of current(), so we should say that >the variable bindings are empty. Doh! My bad. >> - the set of namespace declarations are those which are imported >> in the current module or submodule, along with the prefixes under >> which they were imported; this includes the implicit declaration >> of the prefix xml required by the the XML Namespaces > >No, we should not have the prefix 'xml' implicitly declared! We should, since they say it's required for namespaces. ;^) I've looked in rec-xml-names and don't see any use of "xml" as a prefix. It does say: Namespace constraint: Reserved Prefixes and Namespace Names The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be declared . Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. Element names MUST NOT have the prefix xmlns. I see xmlns (as in xmlns:junos="http://...") but don't see any use of the xml prefix or the "http://www.w3.org/XML/1998/namespace" namespace. Am I missing something? Should we ape XSLT even if we don't follow the reasoning? Rec-xml-names seems to say that it's somehow vital to the operation of namespaces, but I don't see it. Thanks, Phil From mbj@tail-f.com Thu Jun 4 07:01: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 8750A3A6BC0 for ; Thu, 4 Jun 2009 07:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, FRT_SOMA2=2.199, 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 Wr51dHFBz5a5 for ; Thu, 4 Jun 2009 07:01: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 5B4893A6A7A for ; Thu, 4 Jun 2009 07:01:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AFF2F61602B; Thu, 4 Jun 2009 16:01:30 +0200 (CEST) Date: Thu, 04 Jun 2009 16:01:44 +0200 (CEST) Message-Id: <20090604.160144.13425220.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200906041334.n54DYeji004079@idle.juniper.net> References: <20090604.092006.189072679.mbj@tail-f.com> <200906041334.n54DYeji004079@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] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 14:01:31 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Can we simplify this - what is an expression that is part of another > >expression in YANG? > > must foo/goo[name != "fish"]; > > The context being defined is that of the outermost expression > (goo), not the inner (name != "fish"). Note this is recursive, > but rarely used (foo/goo[zoo/moo[name == "fish"]]). But this is how XPath works, so why do we have to state it again? > >> - the context size comes from the size of the current node list > > > >I must admit that I do not understand this. What exactly is the > >"current node list"? Also, stating that the first position is 1 is > >redundant, since that how it works in XPath. > > context size defines the value for "last()". Sure, but my question is what the "current node list" is. > >> - the set of namespace declarations are those which are imported > >> in the current module or submodule, along with the prefixes under > >> which they were imported; this includes the implicit declaration > >> of the prefix xml required by the the XML Namespaces > > > >No, we should not have the prefix 'xml' implicitly declared! > > We should, since they say it's required for namespaces. ;^) It's a predefined prefix in XML instance documents. If it was required for all XPath usages, it would have been specified as one member of the prefix-to-uri map in the XPath spec. /martin From lhotka@cesnet.cz Thu Jun 4 07:12:47 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 A8E4A3A6E30 for ; Thu, 4 Jun 2009 07:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=0.694, 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 VqeoUgczfi7c for ; Thu, 4 Jun 2009 07:12:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D43AC3A6B3B for ; Thu, 4 Jun 2009 07:12:46 -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 15412D800BD; Thu, 4 Jun 2009 16:12:48 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200906041338.n54DcVVF004110@idle.juniper.net> References: <200906041338.n54DcVVF004110@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 04 Jun 2009 16:12:48 +0200 Message-Id: <1244124768.6524.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 14:12:47 -0000 Phil Shafer píše v Čt 04. 06. 2009 v 09:38 -0400: > Martin Bjorklund writes: > > The above concept of default namespace is adopted from XPath 2.0 > > [XPATH2.0]. It 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. > > I disagree, and see this as false. We did not adopt this from > xpath-2.0. We copied xslt's use of xpath, where xslt defines the > evaluation context for xpath expressions. No one even noticed how > xpath-2.0 worked until much later. We mimic xslt and xslt uses > xpath-1.0, so I'm completely surprised that this continues to > be seen as a sticking point. No, it doesn't work like this in XSLT. Element names in XPath expressions that carry no namespace prefix are considered to have the null namespace URI and will not match elements in another (non-null) namespace even if this namespace is declared as default (via xmlns) in the XSL stylesheet. That's why YANG XPath expressions will have to be transformed (explicit prefixes added) before they can be used e.g. in Schematron. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Jun 4 07:17: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 DBC833A6C72 for ; Thu, 4 Jun 2009 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEGFIS8cj2LW for ; Thu, 4 Jun 2009 07:17:45 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id E7B203A6B5B for ; Thu, 4 Jun 2009 07:17:44 -0700 (PDT) Received: (qmail 35702 invoked from network); 4 Jun 2009 14:17:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 4 Jun 2009 14:17:45 -0000 X-YMail-OSG: cQbU4fsVM1nfIzHN4rSRKk1XgfbkCjWQzOLmkJ5W_qrl3l.ilvpW8J2QK8FJW.eOelb52uED0TuekCD4f19lL9WIdldLRgJFMUa4VMfwAmbdwbwE4S4XZ1raiYfcsBhlXODzHad31pVzuVJkwKkboKeM7sDVDtLSX72lEgMly1L9rTsyFfGcNU0_R6QRLNiSFJFs7p1jcjhSVRY2HhQ_l8rw7PcyFMKNr0F0Fcva_gT0l6chVnoAmdrTAnykjJ1cRmTXf2LE4PFUyZOOxWJUEOEWLSJwYOGEIQh_shk5pmuUUc.paulODeExt5.3CYlbWaDInSwWFOOP45tEpQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A27D788.3020904@netconfcentral.com> Date: Thu, 04 Jun 2009 07:17:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200906041334.n54DYeji004079@idle.juniper.net> In-Reply-To: <200906041334.n54DYeji004079@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 14:17:45 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> Can we simplify this - what is an expression that is part of another >> expression in YANG? > > must foo/goo[name != "fish"]; > > The context being defined is that of the outermost expression > (goo), not the inner (name != "fish"). Note this is recursive, > but rarely used (foo/goo[zoo/moo[name == "fish"]]). > >>> - the context size comes from the size of the current node list >> I must admit that I do not understand this. What exactly is the >> "current node list"? Also, stating that the first position is 1 is >> redundant, since that how it works in XPath. > > context size defines the value for "last()". > context is recursive, e.g., "//*[2]". The context size will be different in each subtree. The ordering (depends on forward or reverse axis) is associated with the match expression, not the document: (foo/goo[name != "fish"])[2] >> We got rid of $current in favor of current(), so we should say that >> the variable bindings are empty. > > Doh! My bad. > Vendors may want to use variable bindings. They show up in XPath filtering, not just must/when. We should say it is out of scope how the bindings get set, and in the future, there may even be standard variables. If we say the list is empty in YANG 1.0, we will never be able to change it. >>> - the set of namespace declarations are those which are imported >>> in the current module or submodule, along with the prefixes under >>> which they were imported; this includes the implicit declaration >>> of the prefix xml required by the the XML Namespaces >> No, we should not have the prefix 'xml' implicitly declared! > > We should, since they say it's required for namespaces. ;^) > > I've looked in rec-xml-names and don't see any use of "xml" as > a prefix. It does say: > > Namespace constraint: Reserved Prefixes and Namespace Names > > The prefix xml is by definition bound to the namespace name > http://www.w3.org/XML/1998/namespace. It MAY, but need not, be > declared, and MUST NOT be bound to any other namespace name. > Other prefixes MUST NOT be bound to this namespace name, and > it MUST NOT be declared as the default namespace. > > The prefix xmlns is used only to declare namespace bindings and > is by definition bound to the namespace name > http://www.w3.org/2000/xmlns/. It MUST NOT be declared . Other > prefixes MUST NOT be bound to this namespace name, and it MUST > NOT be declared as the default namespace. Element names MUST > NOT have the prefix xmlns. > > I see xmlns (as in xmlns:junos="http://...") but don't see any > use of the xml prefix or the "http://www.w3.org/XML/1998/namespace" > namespace. > I think some XSD validators will hardwire the 'xml' prefix, and complain if you explicitly import '1998' into the XSD. > Am I missing something? Should we ape XSLT even if we don't > follow the reasoning? Rec-xml-names seems to say that it's > somehow vital to the operation of namespaces, but I don't > see it. > > Thanks, > Phil Andy From phil@juniper.net Thu Jun 4 08:11: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 96F903A6C97 for ; Thu, 4 Jun 2009 08:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 r-rIuuIyXb1V for ; Thu, 4 Jun 2009 08:11:10 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C30E23A6AF1 for ; Thu, 4 Jun 2009 08:11:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSifkDCd4QpzhmtKObx/+5d+9XCX8Dh+8@postini.com; Thu, 04 Jun 2009 08:11: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.340.0; Thu, 4 Jun 2009 08:09:23 -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, 4 Jun 2009 08:09:22 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 08:09:22 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 08:09:22 -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 n54F9LL74506; Thu, 4 Jun 2009 08:09:21 -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 n54Ewmfo006836; Thu, 4 Jun 2009 14:58:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200906041458.n54Ewmfo006836@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090604.160144.13425220.mbj@tail-f.com> Date: Thu, 4 Jun 2009 10:58:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Jun 2009 15:09:22.0148 (UTC) FILETIME=[70D7D240:01C9E526] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 15:11:11 -0000 Martin Bjorklund writes: >But this is how XPath works, so why do we have to state it again? I would just follow the way XSLT handles it, so yes, state it again. We are defining the context for the outermost expression. >Sure, but my question is what the "current node list" is. Hmm... I guess for us, there is none. None of our expressions are evaluated against a node set, so the position isn't an issue for the evaluation context. It would still matter in the other contexts (the non-outermost expression), where saying foo[goo[1] == 'fish'] makes position important. >It's a predefined prefix in XML instance documents. If it was >required for all XPath usages, it would have been specified as one >member of the prefix-to-uri map in the XPath spec. Rec-xml-names says they are predefined, and xslt refers to that. I'd mimic xslt again. Thanks, Phil From lhotka@cesnet.cz Thu Jun 4 08:13: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 21F9928C122 for ; Thu, 4 Jun 2009 08:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=0.624, 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 otXw+1cgyDqO for ; Thu, 4 Jun 2009 08:13:05 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 872293A692C for ; Thu, 4 Jun 2009 08:13: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 8C8BDD800C5 for ; Thu, 4 Jun 2009 17:13:05 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A27DFA2.3030607@joelhalpern.com> References: <200906041338.n54DcVVF004110@idle.juniper.net> <1244124768.6524.58.camel@missotis> <4A27DFA2.3030607@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 04 Jun 2009 17:13:05 +0200 Message-Id: <1244128386.6524.66.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] default namespace in XPath X-BeenThere: netmod@ietf.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, 04 Jun 2009 15:13:07 -0000 Joel M. Halpern píše v Čt 04. 06. 2009 v 10:52 -0400: > I am not sure that I understood you. > Let me try to paraphrase, in a pure XML context. > In an XPath expression (in XSLT, and maybe elsewhere?) the default > namespace is irrelevant. There i sno way to refer to an element in the > default namespace (assuming that the default namespace has been > declared) excpet my explicitly using the non-default namespace > designator for that particular namespace. > > I.e. The default namespace declaration has no effect on the meaning of > terms in the XPath expression. > Yes, this is correct. I guess every XSLT developer has been bitten by this behaviour and it is a mandatory entry in every XSLT FAQ. > Is that the way it works? (I believe that is indeed the case for > attributes. I had not realized it was the case for XPath element names.) This is just what the XPath spec says: "if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded)". Lada > > Yours, > Joel > > Ladislav Lhotka wrote: > > Phil Shafer píše v Čt 04. 06. 2009 v 09:38 -0400: > >> Martin Bjorklund writes: > >>> The above concept of default namespace is adopted from XPath 2.0 > >>> [XPATH2.0]. It 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. > >> I disagree, and see this as false. We did not adopt this from > >> xpath-2.0. We copied xslt's use of xpath, where xslt defines the > >> evaluation context for xpath expressions. No one even noticed how > >> xpath-2.0 worked until much later. We mimic xslt and xslt uses > >> xpath-1.0, so I'm completely surprised that this continues to > >> be seen as a sticking point. > > > > No, it doesn't work like this in XSLT. Element names in XPath > > expressions that carry no namespace prefix are considered to have the > > null namespace URI and will not match elements in another (non-null) > > namespace even if this namespace is declared as default (via xmlns) in > > the XSL stylesheet. > > > > That's why YANG XPath expressions will have to be transformed (explicit > > prefixes added) before they can be used e.g. in Schematron. > > > > Lada > > > >> Thanks, > >> Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Fri Jun 5 03:56: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 E20F13A6B87 for ; Fri, 5 Jun 2009 03:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 2jAlxC4kllD5 for ; Fri, 5 Jun 2009 03:56:50 -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 CCB543A6829 for ; Fri, 5 Jun 2009 03:56:49 -0700 (PDT) X-Trace: 254701056/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.217/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.217 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: AuIEANuWKEo+vGTZ/2dsb2JhbACDKVKLNcA8CIQCBQ X-IronPort-AV: E=Sophos;i="4.41,310,1241391600"; d="scan'208";a="254701056" X-IP-Direction: IN Received: from 1cust217.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.217]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2009 11:56:50 +0100 Message-ID: <003901c9e5c3$cc324600$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , "Martin Bjorklund" References: <200906041338.n54DcVVF004110@idle.juniper.net> <1244124768.6524.58.camel@missotis> Date: Fri, 5 Jun 2009 10:47:42 +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] default namespace in XPath 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, 05 Jun 2009 10:56:51 -0000 Martin I am (very much with) Lada on this and I am happy with your formulation herein (and apologies that I am never going to be right up with the cut and thrust of e-mails threads such as this. My way of working is more of a considered response some time later). Null is well defined is XPath (and XSD) and so I think the wording in -05 is not as respectful of X... as it could be and that your text is an improvement. I think it good to have a informative reference to XPath 2.0. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Phil Shafer" Cc: Sent: Thursday, June 04, 2009 4:12 PM Subject: Re: [netmod] default namespace in XPath > Phil Shafer píše v Čt 04. 06. 2009 v 09:38 -0400: > > Martin Bjorklund writes: > > > The above concept of default namespace is adopted from XPath 2.0 > > > [XPATH2.0]. It 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. > > > > I disagree, and see this as false. We did not adopt this from > > xpath-2.0. We copied xslt's use of xpath, where xslt defines the > > evaluation context for xpath expressions. No one even noticed how > > xpath-2.0 worked until much later. We mimic xslt and xslt uses > > xpath-1.0, so I'm completely surprised that this continues to > > be seen as a sticking point. > > No, it doesn't work like this in XSLT. Element names in XPath > expressions that carry no namespace prefix are considered to have the > null namespace URI and will not match elements in another (non-null) > namespace even if this namespace is declared as default (via xmlns) in > the XSL stylesheet. > > That's why YANG XPath expressions will have to be transformed (explicit > prefixes added) before they can be used e.g. in Schematron. > > Lada > > > Thanks, > > Phil > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Fri Jun 5 03:56: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 0FBE73A6C5F for ; Fri, 5 Jun 2009 03:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 q0aWRjL0MMpg for ; Fri, 5 Jun 2009 03:56:51 -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 E5F6C3A6BF1 for ; Fri, 5 Jun 2009 03:56:50 -0700 (PDT) X-Trace: 254701073/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.217/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.217 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: AuIEANuWKEo+vGTZ/2dsb2JhbACDKVKLNcA8CII1gU0F X-IronPort-AV: E=Sophos;i="4.41,310,1241391600"; d="scan'208";a="254701073" X-IP-Direction: IN Received: from 1cust217.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.217]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2009 11:56:52 +0100 Message-ID: <003a01c9e5c3$cd0c7960$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" References: <1242894219.6931.59.camel@missotis> <20090521.213717.193017582.mbj@tail-f.com> <1242973685.6374.27.camel@missotis> <20090522.151526.32995613.mbj@tail-f.com> <004101c9e46e$0e372400$0601a8c0@allison> <1244101182.6524.27.camel@missotis> Date: Fri, 5 Jun 2009 11:23:28 +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] definitions 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, 05 Jun 2009 10:56:52 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "tom.petch" Cc: "Martin Bjorklund" ; Sent: Thursday, June 04, 2009 9:39 AM Subject: Re: [netmod] definitions > tom.petch píše v St 03. 06. 2009 v 19:06 +0200: > > > > The "import" statement makes identifiers from the namespace of the > > > > imported module available in the importing module. In particular, the > > > > importing module may > > > > > > > > o use groupings and typedefs defined at the top level of the imported > > > > module; > > > > > > > > o refer to features defined in the imported module; > > > > > > > > o use any data node of the imported module as the target node for the > > > > "augment" statement. > > > > > > > > Unlike "include", the "import" statement doesn't contribute the data > > > > tree from the imported to the importing module. > > > > > > I'm not sure this text is better than the current text. Does anyone > > > else have an opinion? > > > > Yes; both might be clearer:-( The bulleted list is an improvement, but I do not > > see "identifiers" as an improvement; it is more than identifiers, it is the > > identity, the concept that is being identified. Definitions is nearer the mark > > but still, for me, understates what is on offer. > > Yes, but it is important to stress that the schema tree is not imported. > Can you suggest another formulation? I would go for 'objects' or 'entities' (or 'items') both of which have technical meanings in some contexts, but also can safely be used more generically. And add that phrase, giving The "import" statement makes objects, but not the schema tree, from the namespace of the imported module available in the importing module. In particular, the importing module may:- Tom Petch > > > > > And in the last sentence, surely data tree is wrong; data node yes, but all in > > the schema tree. > > You are right. > > Lada > > > > > Tom Petch > > > > > > > BTW, RNG doesn't have 'import' does it? > > > > > > > > It's called "include". > > > > > > Exactly. YANG's include is more like RNG's include. So I don't see > > > why RNG users would be confused when YANG's import does not behave > > > like RNG's include. > > > > > > > > > /martin > > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > From cfinss@dial.pipex.com Fri Jun 5 03:56: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 6ACFB3A6C84 for ; Fri, 5 Jun 2009 03:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaYYpK946NsT for ; Fri, 5 Jun 2009 03:56:53 -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 C5E333A6C20 for ; Fri, 5 Jun 2009 03:56:52 -0700 (PDT) X-Trace: 254701096/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.217/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.217 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: AuIEANuWKEo+vGTZ/2dsb2JhbACDKVKLNcA8CIQCBQ X-IronPort-AV: E=Sophos;i="4.41,310,1241391600"; d="scan'208";a="254701096" X-IP-Direction: IN Received: from 1cust217.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.217]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2009 11:56:54 +0100 Message-ID: <003b01c9e5c3$ce5c2ae0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <20090604.092006.189072679.mbj@tail-f.com><200906041334.n54DYeji004079@idle.juniper.net> <20090604.160144.13425220.mbj@tail-f.com> Date: Fri, 5 Jun 2009 11:52:04 +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: Re: [netmod] default namespace in XPath 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, 05 Jun 2009 10:56:54 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, June 04, 2009 4:01 PM > Phil Shafer wrote: > > Martin Bjorklund writes: > > >Can we simplify this - what is an expression that is part of another > > >expression in YANG? > > > > must foo/goo[name != "fish"]; > > > > The context being defined is that of the outermost expression > > (goo), not the inner (name != "fish"). Note this is recursive, > > but rarely used (foo/goo[zoo/moo[name == "fish"]]). > > But this is how XPath works, so why do we have to state it again? > > > >> - the context size comes from the size of the current node list > > > > > >I must admit that I do not understand this. What exactly is the > > >"current node list"? Also, stating that the first position is 1 is > > >redundant, since that how it works in XPath. > > > > context size defines the value for "last()". > > Sure, but my question is what the "current node list" is. Martin, Not sure where you have got to on this, but stepping back, an XPath 1.0 context consists of: a context node, a pair of positive integers (context position and context size), a set of variable bindings, a function library, a set of namespace declarations. During evaluation, the context node, position and size can vary, the others do not. Predicates change position and size; expressions change the context node. A step in a location path selects a set of nodes each of which is then is then used in the evaluation of the next step (eg all those in a YANG list{}). I do not see the term 'current node list' in XPath, only in XSLT, but take it to be that set, that sequence of nodes. XPath 2.0 has a better description but has generalised context node to context item. I do not think that XSLT gets the XPath terminology quite right ('outer expression', 'current node list', ..) . XQuery does it better. Tom Petch > > >> - the set of namespace declarations are those which are imported > > >> in the current module or submodule, along with the prefixes under > > >> which they were imported; this includes the implicit declaration > > >> of the prefix xml required by the the XML Namespaces > > > > > >No, we should not have the prefix 'xml' implicitly declared! > > > > We should, since they say it's required for namespaces. ;^) > > It's a predefined prefix in XML instance documents. If it was > required for all XPath usages, it would have been specified as one > member of the prefix-to-uri map in the XPath spec. > > /martin From andy@netconfcentral.com Mon Jun 8 20:18: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 F33D93A68A8 for ; Mon, 8 Jun 2009 20:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.179, 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 zDx5jdRLArA7 for ; Mon, 8 Jun 2009 20:18:09 -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 4BF473A682E for ; Mon, 8 Jun 2009 20:18:09 -0700 (PDT) Received: (qmail 10246 invoked from network); 9 Jun 2009 03:18:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 03:18:12 -0000 X-YMail-OSG: JOplW1IVM1k5CXAFRzlTMf2Ww.bL_9Oe5TqrjKvJBmKoAlvIwKwDwzXPYERG5UYRZfhhqygL84lhRPOlO3MK80AUOj_a2yp6SXOfzKEfNz4UyBNIcj8yMTuVMG8Fpq3c7Nd63kCM2_TPm.MDfgCFlWvfpJBeR.jFHcZ3i2wQZoiGBa.xPlWxBHsZgU_0GCfcq.eeYQxwR9hEgg4fGahCd_oMXs78oe2lz84MrqnQsL1_KFekN3AUzHeHqTOuX.ewvFgceMbraoy2JEsTGURoEuXekNFy4b7eb1EH9ZT51tpnAKZ5494z X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2DD45C.7050607@netconfcentral.com> Date: Mon, 08 Jun 2009 20:17:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] date-and-time vs. dateTime X-BeenThere: netmod@ietf.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, 09 Jun 2009 03:18:10 -0000 Hi, The notification data model in RFC 5277 is an XSD and uses the XSD data type 'dateTime'. But YANG only has the 'date-and-time' date type. As documented in the description statement, the 2 types are different. We should start out with as little cruft and baggage as possible with standard CM content. I prefer the date-and-time version. I'm not sure what 'negative' dateTime is used for, but I'm pretty sure it isn't needed in NETCONF. Both data types allow infinite length strings, due to the 'time-secfrac' field. (How fun.) It may not be clear from the YANG spec, but the agent is going to convert localtime to gmtime because it MUST return the canonical form, so any 'insert' operation or retrieval via or should take that into account. So: how to fix this little mess? I propose that RFC 5277 be "clarified" to indicate that YANG date-and-time encoding rules SHOULD be used instead of XSD dateTime. The only differences are pathological corner-cases that have no utility in the operation. Andy From j.schoenwaelder@jacobs-university.de Mon Jun 8 22:46: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 0DDFA3A694A for ; Mon, 8 Jun 2009 22:46:26 -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_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 bwm0OFvg2Kq7 for ; Mon, 8 Jun 2009 22:46:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E54523A67D7 for ; Mon, 8 Jun 2009 22:46:24 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C6BAC0075; Tue, 9 Jun 2009 07:46:29 +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 Nj7LwEQg8L+9; Tue, 9 Jun 2009 07:46:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8FDBC0071; Tue, 9 Jun 2009 07:46:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 688E4B34687; Tue, 9 Jun 2009 07:46:26 +0200 (CEST) Date: Tue, 9 Jun 2009 07:46:26 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090609054626.GC2691@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4A2DD45C.7050607@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2DD45C.7050607@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] date-and-time vs. dateTime 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, 09 Jun 2009 05:46:26 -0000 On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote: > I propose that RFC 5277 be "clarified" to indicate > that YANG date-and-time encoding rules SHOULD be > used instead of XSD dateTime. The only differences > are pathological corner-cases that have no utility > in the operation. I think RFC 5277 is a product of the NETCONF WG and thus your message should have gone to the NETCONF mailing list and not to the NETMOD mailing list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Mon Jun 8 22:58: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 5F7B13A6C62 for ; Mon, 8 Jun 2009 22:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.167, 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 EU7u9pEewYsj for ; Mon, 8 Jun 2009 22:58:02 -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 3E5B53A6C34 for ; Mon, 8 Jun 2009 22:58:02 -0700 (PDT) Received: (qmail 68513 invoked from network); 9 Jun 2009 05:51:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 05:51:27 -0000 X-YMail-OSG: pT0GtXwVM1mP24anIW816Ud10hp6ZpgkrJRB9iGFD_XCgirJyebJNAIT.2yBrrLnAARsSVFoCGnCEiAjef31BMsdSDs_R6XR4140cWHVzRT4Ov96VwqvNdLEVOb1d9W95ziw1nc.qoe7NU5ksEZR6FOHGcwaA4kARYA1.7cF9jb2jwjZgEt1ZDtZrtO0jV6NBxtszHfgOQnhTjT3x3wpQdR5J.rQ070UFR6cHYpxDS9HfdR.liVtuQJpxWdvulqh1_k9TAN4gJujxJgC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2DF85D.50308@netconfcentral.com> Date: Mon, 08 Jun 2009 22:51:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> In-Reply-To: <20090609054626.GC2691@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [netmod] date-and-time vs. dateTime X-BeenThere: netmod@ietf.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, 09 Jun 2009 05:58:02 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote: > >> I propose that RFC 5277 be "clarified" to indicate >> that YANG date-and-time encoding rules SHOULD be >> used instead of XSD dateTime. The only differences >> are pathological corner-cases that have no utility >> in the operation. > > I think RFC 5277 is a product of the NETCONF WG and thus your message > should have gone to the NETCONF mailing list and not to the NETMOD > mailing list. > OK -- another possible solution is to remove (or change) any YANG data type that is not exactly like its XSD counterpart. That would affect YANG, not NETCONF. > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Jun 8 23:38:41 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 ABF1E3A6CD9; Mon, 8 Jun 2009 23:38:41 -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_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 s3Us6ua8Sm4H; Mon, 8 Jun 2009 23:38:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 116133A6CD5; Mon, 8 Jun 2009 23:38:40 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FD63C0076; Tue, 9 Jun 2009 08:38:45 +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 q-KiKLVlWmKo; Tue, 9 Jun 2009 08:38: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 A917DC0071; Tue, 9 Jun 2009 08:38:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B0AAB346F9; Tue, 9 Jun 2009 08:38:43 +0200 (CEST) Date: Tue, 9 Jun 2009 08:38:43 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090609063843.GA2798@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group , NETCONF References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2DF85D.50308@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETCONF , NETMOD Working Group Subject: Re: [netmod] [Netconf] date-and-time vs. dateTime 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, 09 Jun 2009 06:38:41 -0000 On Tue, Jun 09, 2009 at 07:51:25AM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote: > > > >> I propose that RFC 5277 be "clarified" to indicate > >> that YANG date-and-time encoding rules SHOULD be > >> used instead of XSD dateTime. The only differences > >> are pathological corner-cases that have no utility > >> in the operation. > > > > I think RFC 5277 is a product of the NETCONF WG and thus your message > > should have gone to the NETCONF mailing list and not to the NETMOD > > mailing list. > > > > OK -- another possible solution is to remove (or change) > any YANG data type that is not exactly like its XSD counterpart. > That would affect YANG, not NETCONF. Is that a serious proposal or just noise? /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 Jun 9 03:26: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 E3B6A3A69B9 for ; Tue, 9 Jun 2009 03:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.156, 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 kK01SbyvYmst for ; Tue, 9 Jun 2009 03:26:58 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 8798E3A699A for ; Tue, 9 Jun 2009 03:26:58 -0700 (PDT) Received: (qmail 62179 invoked from network); 9 Jun 2009 10:27:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 10:27:02 -0000 X-YMail-OSG: 8A16cV0VM1mjkMH_mo6ZRmNG.yp27bU0IJwb3Wr.b2uLO0xcmxGs_lj.NuuRk9RGRt86BMLMDKOPfHLOpcmHiqmb3WTceALUyPt3HSZfZjRzdBPpttWhqlWbEqVCv34fmnHeJIAqccSdc27KehQhWjVJnAyDa8eeyBD5pQx62cMg_cFD01O376FS5a7tb.r4QSWe9MGQmxfPzdHtglEdzqf.eYg84B_VPsIa.eQqEcu1kIRm2KZqH8bG3cbVlK0xFBo1El6SSDaCT8tRYa.2XF.EnZG0K3cA33Qkp8PuyrtfKQplnntt X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2E38F4.6030600@netconfcentral.com> Date: Tue, 09 Jun 2009 03:27:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group , NETCONF References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> In-Reply-To: <20090609063843.GA2798@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] date-and-time vs. dateTime X-BeenThere: netmod@ietf.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, 09 Jun 2009 10:27:00 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 09, 2009 at 07:51:25AM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote: >>> >>>> I propose that RFC 5277 be "clarified" to indicate >>>> that YANG date-and-time encoding rules SHOULD be >>>> used instead of XSD dateTime. The only differences >>>> are pathological corner-cases that have no utility >>>> in the operation. >>> I think RFC 5277 is a product of the NETCONF WG and thus your message >>> should have gone to the NETCONF mailing list and not to the NETMOD >>> mailing list. >>> >> OK -- another possible solution is to remove (or change) >> any YANG data type that is not exactly like its XSD counterpart. >> That would affect YANG, not NETCONF. > > Is that a serious proposal or just noise? > Quite serious. The NETCONF WG is writing data models in XSD and the NETMOD WG is writing YANG as if XSD did not really exist. Why do we need 2 sets of almost-compatible data types? > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Jun 9 03:52: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 960373A6C07; Tue, 9 Jun 2009 03:52:12 -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=[AWL=0.000, 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 tiMi+jOkVxwR; Tue, 9 Jun 2009 03:52: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 3E64E3A685A; Tue, 9 Jun 2009 03:52:08 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAAA0C00A5; Tue, 9 Jun 2009 12:52:13 +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 CVUVE6vvbAXW; Tue, 9 Jun 2009 12:52: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 62FD5C0093; Tue, 9 Jun 2009 12:52:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 35476B34C5A; Tue, 9 Jun 2009 12:52:11 +0200 (CEST) Date: Tue, 9 Jun 2009 12:52:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090609105211.GC3133@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group , NETCONF References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2E38F4.6030600@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETCONF , NETMOD Working Group Subject: Re: [netmod] [Netconf] date-and-time vs. dateTime 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, 09 Jun 2009 10:52:12 -0000 On Tue, Jun 09, 2009 at 12:27:00PM +0200, Andy Bierman wrote: > Quite serious. > The NETCONF WG is writing data models in XSD > and the NETMOD WG is writing YANG as if XSD did not > really exist. The NETCONF WG is producing a protocol, the NETMOD WG is producing a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. So there is a difference, even though the use of XML for everything makes it hard to see the border. > Why do we need 2 sets of almost-compatible data types? This question can't answered in the abstract because you have to pay attention to the reasons for any differences there are. What concerns the ietf-yang-types module, I tried to document where the differences are. Wrt data-and-time, the concensus so far was to follow RFC 3339 (Proposed Standard) in some corner cases instead of XSD. While I personally do not care much about negative years and what they might mean, I think the distinction between -00:00 and +00:00 and Z made in RFC 3339 is actually a very useful one. If you have further issues with any of the ietf-yang-types data types, please start separate threads so we can work them out and see what the concensus is. /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 Jun 9 08:28: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 E3F473A6C8A for ; Tue, 9 Jun 2009 08:28:21 -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 ZzoeXGCeHTLu for ; Tue, 9 Jun 2009 08:28:21 -0700 (PDT) Received: from n11.bullet.mail.mud.yahoo.com (n11.bullet.mail.mud.yahoo.com [209.191.125.210]) by core3.amsl.com (Postfix) with SMTP id E2F263A67DA for ; Tue, 9 Jun 2009 08:28:20 -0700 (PDT) Received: from [209.191.108.96] by n11.bullet.mail.mud.yahoo.com with NNFMP; 09 Jun 2009 15:28:25 -0000 Received: from [68.142.201.69] by t3.bullet.mud.yahoo.com with NNFMP; 09 Jun 2009 15:28:25 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 09 Jun 2009 15:28:25 -0000 X-Yahoo-Newman-Id: 254392.4333.bm@omp421.mail.mud.yahoo.com Received: (qmail 38681 invoked from network); 9 Jun 2009 15:28:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 15:28:24 -0000 X-YMail-OSG: _T1_mwgVM1mZmCPYw8.WUMhSWBrrXM7oYIQyEGMel4XexAzrCpfVRl3NZc4h4N25gtCq08kuJU0KfUEzEC.DDPDHz..41kCUy8Z5.VEF0X5Uigofc2ZcvVCZpikcSNN.Vh0rpw1V.fX1.pNmgZoXZF.3Oo.EkmzwsxNoZU97q8D6A_6gKS1kkObGoI0k3QfBkhv3f_eaKnBuxFB.uWIWhAQRg2iIz4__CvPDac36sSHP5bMqHA6kE8_.Zl95fmof6K78.HeZGzCiG_Idj2QfELCr55AOd2XmsDaCJx8yC.IrXwtggfiT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2E7F96.3060903@netconfcentral.com> Date: Tue, 09 Jun 2009 08:28:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group , NETCONF References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> <20090609105211.GC3133@elstar.local> In-Reply-To: <20090609105211.GC3133@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] date-and-time vs. dateTime X-BeenThere: netmod@ietf.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, 09 Jun 2009 15:28:22 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 09, 2009 at 12:27:00PM +0200, Andy Bierman wrote: > >> Quite serious. >> The NETCONF WG is writing data models in XSD >> and the NETMOD WG is writing YANG as if XSD did not >> really exist. > > The NETCONF WG is producing a protocol, the NETMOD WG is producing a > data modeling language used to model configuration and state data > manipulated by the NETCONF protocol, NETCONF remote procedure calls, > and NETCONF notifications. So there is a difference, even though the > use of XML for everything makes it hard to see the border. > The NETCONF WG is producing content. In fact, the ONLY standard content for NETCONF that exists has been done by the NETCONF WG. - notification monitoring and create-subscription operation - ietf-netconf-state anf get-schema operation - partial-lock and partial unlock operations - with-defaults parameter extension to some operations All of these documents have content at the layers that YANG is intended to cover. >> Why do we need 2 sets of almost-compatible data types? > > This question can't answered in the abstract because you have to pay > attention to the reasons for any differences there are. What concerns > the ietf-yang-types module, I tried to document where the differences > are. Wrt data-and-time, the concensus so far was to follow RFC 3339 > (Proposed Standard) in some corner cases instead of XSD. While I > personally do not care much about negative years and what they might > mean, I think the distinction between -00:00 and +00:00 and Z made in > RFC 3339 is actually a very useful one. > > If you have further issues with any of the ietf-yang-types data types, > please start separate threads so we can work them out and see what the > concensus is. > The subject line says date-and-time and that is the issue here. Remove it, change it, or change ALL of the NETCONF content that uses dateTime to perfectly align with the YANG language. I was hoping we were going to avoid the same sort of compartmental politics that plagued EOS/SMIng. I guess not. > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Jun 9 08:59: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 AA61D3A68F9; Tue, 9 Jun 2009 08:59:13 -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_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 swfJ5y3NbsYP; Tue, 9 Jun 2009 08:59: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 6F43A3A6784; Tue, 9 Jun 2009 08:59:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2D25C00B6; Tue, 9 Jun 2009 17:59:17 +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 hFvztgMHSNXO; Tue, 9 Jun 2009 17:59:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0279C0062; Tue, 9 Jun 2009 17:59:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8F4A5B356FF; Tue, 9 Jun 2009 17:59:15 +0200 (CEST) Date: Tue, 9 Jun 2009 17:59:15 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090609155915.GG4194@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group , NETCONF References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> <20090609105211.GC3133@elstar.local> <4A2E7F96.3060903@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2E7F96.3060903@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETCONF , NETMOD Working Group Subject: Re: [netmod] [Netconf] date-and-time vs. dateTime 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, 09 Jun 2009 15:59:13 -0000 On Tue, Jun 09, 2009 at 05:28:22PM +0200, Andy Bierman wrote: > The subject line says date-and-time and that is the issue here. > Remove it, change it, or change ALL of the NETCONF content > that uses dateTime to perfectly align with the YANG language. > > I was hoping we were going to avoid the same sort of compartmental > politics that plagued EOS/SMIng. I guess not. YANG started late and some data models were started before and this explains the situation (and this particularly applies to RFC 5277, published in July 2008). I do not see compartmental politics - just the IETF working as it is. Concerning RFC 5277, I like to quote section 2.2.1: Parameters: eventTime The time the event was generated by the event source. This parameter is of type dateTime and compliant to [RFC3339]. Implementations must support time zones. This says eventTime is compliant to RFC3339 and thus I believe it is actually compliant with date-and-time (but perhaps the WG was not aware of the corner case differences between XSD dateTime and RFC3339 ietf-yang-types is pointing out). The more interesting question for me is whether eventTime is part of the content or part of the protocol. For me, it seems to be more part of the protocol as it is hardwired to the message but I understand that this piece of the design can be debated. /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 Jun 9 09:20: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 F2F3128C1A8 for ; Tue, 9 Jun 2009 09:20:07 -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, 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 qbC-yk6A+62b for ; Tue, 9 Jun 2009 09:20:07 -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 94A2728C189 for ; Tue, 9 Jun 2009 09:20:05 -0700 (PDT) Received: (qmail 98370 invoked from network); 9 Jun 2009 16:13:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 16:13:32 -0000 X-YMail-OSG: 4PXVdrMVM1nT9Fv9x8np03w05rn0emBpUMa9O3yBYb64MzOQNckOQDTo0MqX54rPnyGiK5mEVCzyDlIF4UMWL6IU6l.Ttz2KW7VRfAR7zG6Re1Hzjx0LGrMj.aJ8q8gLxyUvyPp3aXibshZWMhcebPwYgQpDbf1Xh_r8nl5WrB3d8xpI5uYHys15r6CaBz3DPrxbgfiGVg_t7VJQsOGKgtcSq_KxNTunrNpExjqSNnob4h2kw0Z_TPKtsLQII80CeDbWCshj9eir17g6Afjn4gZ9H3iz15ZPVhFv3UlT_qAI6Q_Awktf X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2E8A14.4020308@netconfcentral.com> Date: Tue, 09 Jun 2009 09:13:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group , NETCONF References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> <20090609105211.GC3133@elstar.local> <4A2E7F96.3060903@netconfcentral.com> <20090609155915.GG4194@elstar.local> In-Reply-To: <20090609155915.GG4194@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] date-and-time vs. dateTime X-BeenThere: netmod@ietf.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, 09 Jun 2009 16:20:08 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 09, 2009 at 05:28:22PM +0200, Andy Bierman wrote: > >> The subject line says date-and-time and that is the issue here. >> Remove it, change it, or change ALL of the NETCONF content >> that uses dateTime to perfectly align with the YANG language. >> >> I was hoping we were going to avoid the same sort of compartmental >> politics that plagued EOS/SMIng. I guess not. > > YANG started late and some data models were started before and this > explains the situation (and this particularly applies to RFC 5277, > published in July 2008). I do not see compartmental politics - just > the IETF working as it is. > > Concerning RFC 5277, I like to quote section 2.2.1: > > Parameters: > > eventTime > > The time the event was generated by the event source. This > parameter is of type dateTime and compliant to [RFC3339]. > Implementations must support time zones. > This text is why I proposed an RFC Errata to fix the problem. I do not think the NETCONF WG understood the differences at the time. However, the XSD clearly uses dateTime as the data type, not string. RFC 5277 does not say what to do with startTime and/or stopTime with negative dateTime. Is -2010-06-09T12:00:00Z before 'now'? (What were the XSD designers thinking!?!) So problem solved. The text you quoted above is correct and the XSD is wrong, and an RFC Erratta note is needed for RFC 5277 after all. From now on, all time values in NETCONF/YANG MUST be date-and-time. > This says eventTime is compliant to RFC3339 and thus I believe it is > actually compliant with date-and-time (but perhaps the WG was not > aware of the corner case differences between XSD dateTime and RFC3339 > ietf-yang-types is pointing out). > > The more interesting question for me is whether eventTime is part of > the content or part of the protocol. For me, it seems to be more part > of the protocol as it is hardwired to the message but > I understand that this piece of the design can be debated. > eventTime is another problem, but at least it is read-only and the agent generates only canonical format, so the differences never show up. > /js > Andy From spakes@snmp.com Tue Jun 9 10:05: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 459583A6C55 for ; Tue, 9 Jun 2009 10:05:25 -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 TKY67hDH9hau for ; Tue, 9 Jun 2009 10:05:24 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id C7D883A6BE9 for ; Tue, 9 Jun 2009 10:05:23 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA18333; Tue, 9 Jun 2009 13:05:28 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA13914; Tue, 9 Jun 2009 13:05:28 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 9 Jun 2009 13:05:27 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: Message-ID: References: <20090516142006.GB2645@elstar.local> <4A0EDCD0.9020806@netconfcentral.com> <20090518.160947.204829148.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.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, 09 Jun 2009 17:05:25 -0000 On Tue, 19 May 2009, David Spakes wrote: > If the group decision is not in favor of Juergen's proposal to make the > fraction-digits substatement optional, I would still like to see the > typedef of union find a place in draft-ietf-netmod-yang-types-03.txt as > originally proposed. Last month's discussion about decimal64 for draft-ietf-netmod-yang-06.txt ended (I believe) with a decision that fraction-digits would continue to be a required substatement. Therefore, before the end date of the WGLC for draft-ietf-netmod-yang-types-03.txt, I want to make sure that my proposal for the "real" type is still on the table for addition to the yang-types document. Here is the latest version of the proposed text: typedef real { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } type decimal64 { fraction-digits 17; range "-9.99999999999999999 .. 9.99999999999999999"; } type decimal64 { fraction-digits 16; range "-99.9999999999999999 .. 99.9999999999999999"; } type decimal64 { fraction-digits 15; range "-999.999999999999999 .. 999.999999999999999"; } type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The real type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type real is able to express configuration and state data as any of the real numbers in the set. The real type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. Positive numbers larger than 99999999999999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -99999999999999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -99999999999999999.9 and 99999999999999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the real type through rounding or truncation. For example, pi could be rounded (up) to 3.14159265358979324 or truncated to 3.14159265358979323 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } Regards, David Spakes On Wed, 27 May 2009, David Partain wrote: > This is the working group last call on the current working group > document: > > - Common YANG Data Types: > http://tools.ietf.org/html/draft-ietf-netmod-yang-types-03.txt > > The editor and the chairs think that this document is mature enough for > WGLC. This WGLC will last until June 10, 2009. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From lhotka@cesnet.cz Wed Jun 10 23:43: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 835AE3A68FF for ; Wed, 10 Jun 2009 23:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFKb8pMmxCSR for ; Wed, 10 Jun 2009 23:43:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2F77C3A6B82 for ; Wed, 10 Jun 2009 23:43:09 -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 0ECC0D800C8 for ; Thu, 11 Jun 2009 08:43:16 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Thu, 11 Jun 2009 08:43:15 +0200 Message-Id: <1244702595.6390.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 06:43:15 -0000 Hi, derived types with specified defaults may cause an ambiguity if they are used in a union: typedef foo { type string; default "foo"; } typedef bar { type string; default "bar"; } typedef foo-bar { type union { type foo; type bar; } } leaf foobar { type foo-bar; } Now, the default value for leaf foobar can be either "foo" or "bar". Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jun 11 05:21: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 748213A6C71 for ; Thu, 11 Jun 2009 05:21:23 -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 ZA-iI-HkOXnf for ; Thu, 11 Jun 2009 05:21:22 -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 B66B83A6C5D for ; Thu, 11 Jun 2009 05:21:22 -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 9D6D361600D; Thu, 11 Jun 2009 14:21:28 +0200 (CEST) Date: Thu, 11 Jun 2009 14:21:28 +0200 (CEST) Message-Id: <20090611.142128.97622298.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1244702595.6390.7.camel@missotis> References: <1244702595.6390.7.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] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 12:21:23 -0000 Hi, Ladislav Lhotka wrote: > derived types with specified defaults may cause an ambiguity if they are > used in a union: > > typedef foo { > type string; > default "foo"; > } > typedef bar { > type string; > default "bar"; > } > typedef foo-bar { > type union { > type foo; > type bar; > } > } > leaf foobar { > type foo-bar; > } > > Now, the default value for leaf foobar can be either "foo" or "bar". Yes, I think we need to say that the default value is not inherited in the case of a union. /martin From andy@netconfcentral.com Thu Jun 11 07:33: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 ED7553A6B5E for ; Thu, 11 Jun 2009 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 Vljl1Z1EDi4X for ; Thu, 11 Jun 2009 07:33:56 -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 2FB7A3A6AF1 for ; Thu, 11 Jun 2009 07:33:51 -0700 (PDT) Received: (qmail 28254 invoked from network); 11 Jun 2009 14:33:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 11 Jun 2009 14:33:56 -0000 X-YMail-OSG: 2bngT1cVM1k1V7mPL_pmpUWPazgtC6cv6kN9baso4jsrNsK_1TOD4ogHKo377Z4SLoSx3YXBvU1ASEq3yZcZkzbcCFOTdPxQLOmTN0UQ4WVY1soT76yCGxf8Wsez5S2u2AYIQUm_oZk_ot4Z1GLTVQydgr9NCx_Zc5JihFrWY9GJmjePB5dv2r12kjIY6i2XVEZOjsF8U9B1VGPCZek2xKZiOzDu8etzmjhx4GoAN68nNKKGnf.5zxbzPVyuCsH2OY1QcXB_pY5g4h9PP69v.VfHdwxsy1xuksBCX3dzyUomJINBLg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3115D2.1070700@netconfcentral.com> Date: Thu, 11 Jun 2009 07:33:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> In-Reply-To: <20090611.142128.97622298.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 14:33:57 -0000 Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: >> derived types with specified defaults may cause an ambiguity if they are >> used in a union: >> >> typedef foo { >> type string; >> default "foo"; >> } >> typedef bar { >> type string; >> default "bar"; >> } >> typedef foo-bar { >> type union { >> type foo; >> type bar; >> } >> } >> leaf foobar { >> type foo-bar; >> } >> >> Now, the default value for leaf foobar can be either "foo" or "bar". > > Yes, I think we need to say that the default value is not inherited in > the case of a union. > this is not very good. What if the foobar typedef is itself used inside another union type-stmt (could be in a leaf). The typedef-default may not be obvious to spot. Of course, any default-stmt appearing in a leaf is going to be used, regardless of this problem, so this special case for union typedefs will be very confusing. Union type statements are always processed in schema order. The default for foobar is always 'foo'. So what's the problem? Garbage in == Garbage out, just like this: type union { type string; type uint32; // will never get picked } > > /martin Andy From lhotka@cesnet.cz Thu Jun 11 09:08: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 706693A69BD for ; Thu, 11 Jun 2009 09:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[AWL=0.629, 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 ZhU0702bXczD for ; Thu, 11 Jun 2009 09:08:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 95B393A689D for ; Thu, 11 Jun 2009 09:08:15 -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 AE1FAD800C8; Thu, 11 Jun 2009 18:08:20 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A3115D2.1070700@netconfcentral.com> References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 11 Jun 2009 18:08:21 +0200 Message-Id: <1244736501.1662.11.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 16:08:16 -0000 Andy Bierman píše v Čt 11. 06. 2009 v 07:33 -0700: > > type union { > type string; > type uint32; // will never get picked > } > But what if you had type union { type string; type myuint; } typedef myuint { type uint32; default "42"; } Will such a leaf get the default from "myuint" even though this type is never picked from the union as the leaf's type? I'd rather support Martin's suggestion to ignore all typedef-based defaults in union leafs. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Jun 11 09:37: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 9E8FD3A683D for ; Thu, 11 Jun 2009 09:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 DXDDiVzozZPZ for ; Thu, 11 Jun 2009 09:37:56 -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 DDF7F3A67AA for ; Thu, 11 Jun 2009 09:37:56 -0700 (PDT) Received: (qmail 58112 invoked from network); 11 Jun 2009 16:38:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 11 Jun 2009 16:38:01 -0000 X-YMail-OSG: OFICL1wVM1lP8JskfiV81_PRJPl4ajkwYzTl_bMn.tS7Ya8ah0a92jjCVoQ6bTTEMq8FE0FIOJO4g.8GT6eOUPaOJCdJ4PQaoMmV6d0wKM0SIN1WXvOa4072R2RByhiZjq09hZ7HFFwytWakQpNhmNb6R.Q623Ib6oaISxEIq3teEag7JRrJZawLBMjx8ScWmkkjGa0xVbwBBw7tjcmO8GAxX14hxiDvawLWLNftW6fceWZmeys9OF1NwAT_welvTo0f033anFLNXVOd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3132D2.1090703@netconfcentral.com> Date: Thu, 11 Jun 2009 09:37:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@netconfcentral.com> <1244736501.1662.11.camel@missotis> In-Reply-To: <1244736501.1662.11.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 16:37:57 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Čt 11. 06. 2009 v 07:33 -0700: > >> type union { >> type string; >> type uint32; // will never get picked >> } >> > > But what if you had > > type union { > type string; > type myuint; > } > typedef myuint { > type uint32; > default "42"; > } > > Will such a leaf get the default from "myuint" even though this type is > never picked from the union as the leaf's type? > > I'd rather support Martin's suggestion to ignore all typedef-based > defaults in union leafs. > I don't, because it is confusing. In your garbage example, you would get garbage results. The default would be set to whatever the XML text() node contains, because that is what you asked for. typedef Example1 { type uint32 { range "1 .. 10 | 100 .. 200"; } default 7; } typedef Example2 { type union { type uint32 { range "1 .. 10"; } type uint32 { range "100 .. 200"; } } default 7; } So if the typedef Example1 is used, then the default '7' is applied, but if typedef Example2 is used, the default '7' is silently ignored? This is rather confusing. I don't see using a named type should make any difference: typedef Num1 { type uint32 { range "1 .. 10 | 100 .. 200"; } default 7; } typedef Example1 { type Num1; } What about: typedef Example1 { type Num1; default 181; } Is there any text needed about which typedef default has precedence (181, not 7)? > Lada > Andy From mbj@tail-f.com Thu Jun 11 10:03: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 D39913A6D5D for ; Thu, 11 Jun 2009 10:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.366, 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 tvQtozmJxevC for ; Thu, 11 Jun 2009 10:03:22 -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 15BE03A6D53 for ; Thu, 11 Jun 2009 10:03:21 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CC8F6616006; Thu, 11 Jun 2009 19:03:27 +0200 (CEST) Date: Thu, 11 Jun 2009 19:04:09 +0200 (CEST) Message-Id: <20090611.190409.231051975.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A3115D2.1070700@netconfcentral.com> References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@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] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 17:03:22 -0000 Andy Bierman wrote: > Of course, any default-stmt appearing in a leaf is going > to be used, regardless of this problem, so this special > case for union typedefs will be very confusing. I don't see what is confusing. Today, the text is not clear. It says (about the typedef's default statement, which I believe we are discussing). If the base type has a default value, and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. This is not clear - in the case of a union there is no "base type", just a list of "member types". /martin From j.schoenwaelder@jacobs-university.de Thu Jun 11 10:15: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 1F8B03A6D83 for ; Thu, 11 Jun 2009 10:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, 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 QybJS9FM2E8p for ; Thu, 11 Jun 2009 10:15:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5421B3A6B51 for ; Thu, 11 Jun 2009 10:15:43 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85C49C0016; Thu, 11 Jun 2009 19:15:50 +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 yg+uBGeGn-um; Thu, 11 Jun 2009 19:15:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEAC3C000B; Thu, 11 Jun 2009 19:15:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5BB72B3B9F8; Thu, 11 Jun 2009 19:15:47 +0200 (CEST) Date: Thu, 11 Jun 2009 19:15:47 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090611171547.GB388@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@netconfcentral.com> <1244736501.1662.11.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1244736501.1662.11.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] defaults and union 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, 11 Jun 2009 17:15:44 -0000 On Thu, Jun 11, 2009 at 06:08:21PM +0200, Ladislav Lhotka wrote: > Andy Bierman p????e v ??t 11. 06. 2009 v 07:33 -0700: > > > > > type union { > > type string; > > type uint32; // will never get picked > > } > > > > But what if you had > > type union { > type string; > type myuint; > } > typedef myuint { > type uint32; > default "42"; > } > > Will such a leaf get the default from "myuint" even though this type is > never picked from the union as the leaf's type? > > I'd rather support Martin's suggestion to ignore all typedef-based > defaults in union leafs. +1 /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 Thu Jun 11 10:27: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 742E23A6BCD for ; Thu, 11 Jun 2009 10:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.084, 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 ZhWQXHn4+uD1 for ; Thu, 11 Jun 2009 10:27:25 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 20A033A69BF for ; Thu, 11 Jun 2009 10:27:24 -0700 (PDT) Received: (qmail 96264 invoked from network); 11 Jun 2009 17:27:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 11 Jun 2009 17:27:29 -0000 X-YMail-OSG: k2cP4YIVM1lVT46lfFGpgkUmcMT2STxRVoma9NcJ3DlQ2t4D9M1Rz8A8wZ2mtCkqPwUSyTlmYXHEWCNK2of_bBa1dPJNRjNHNTTGxDfZqqoUungMyiI2kzAlqPFXReBMsfh_AaitCbiARAosqwNb9pHhUl0Hh9U_p_UJoViXYGLUZx1Q7T0x8udhDOmUhnR9zMmRlltFRlJYus.Hf9eit4EswItixMMNsrBXbwKJxkRH2ODNcak.Zi..W269YKfD4H.AgDTPvqXn8MgexsFlHL0C2JRrljWgqIODXvwbU1L3e0I7foF6o4b5srwyvwGtYBsFAB4a9683YA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A313E7E.1070907@netconfcentral.com> Date: Thu, 11 Jun 2009 10:27:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@netconfcentral.com> <20090611.190409.231051975.mbj@tail-f.com> In-Reply-To: <20090611.190409.231051975.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 17:27:26 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Of course, any default-stmt appearing in a leaf is going >> to be used, regardless of this problem, so this special >> case for union typedefs will be very confusing. > > I don't see what is confusing. Today, the text is not clear. It > says (about the typedef's default statement, which I believe we are > discussing). > > If the base type has a default value, and the new derived type does > not specify a new default value, the base type's default value is > also the default value of the new derived type. > > This is not clear - in the case of a union there is no "base type", > just a list of "member types". > > typedef A { type uint32; default 5; } typedef B { type A; } typedef C { type union { type uint32; type string; } default fred; } typedef D { type C; } typedef E { type string; default fred; } typedef F { union { type uint32; type E; } } type default --------------------- A 5 B 5 C fred D fred E fred F IMO, it is confusing that named types pass their default sometimes (B, D) but not others (F). It seems confusing that C and F do not produce the same results. So what is your proposed text? > /martin > > Andy From j.schoenwaelder@jacobs-university.de Thu Jun 11 12:43: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 232F328C180 for ; Thu, 11 Jun 2009 12:43:08 -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 O-H75y1Pq3rO for ; Thu, 11 Jun 2009 12:43:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0BF2428C17C for ; Thu, 11 Jun 2009 12:43:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F389C0028; Thu, 11 Jun 2009 21:43:14 +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 lsq9Sm-Zwb8H; Thu, 11 Jun 2009 21:43:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DBF2C0014; Thu, 11 Jun 2009 21:43:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 113DBB3BBFE; Thu, 11 Jun 2009 21:43:12 +0200 (CEST) Date: Thu, 11 Jun 2009 21:43:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090611194311.GB612@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@netconfcentral.com> <20090611.190409.231051975.mbj@tail-f.com> <4A313E7E.1070907@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A313E7E.1070907@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] defaults and union 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, 11 Jun 2009 19:43:08 -0000 On Thu, Jun 11, 2009 at 07:27:26PM +0200, Andy Bierman wrote: > typedef A { > type uint32; > default 5; > } > > typedef B { > type A; > } > > typedef C { > type union { > type uint32; > type string; > } > default fred; > } > > typedef D { > type C; > } > > typedef E { > type string; > default fred; > } > > typedef F { > union { > type uint32; > type E; > } > } > > type default > --------------------- > A 5 > B 5 > C fred > D fred > E fred > F > > IMO, it is confusing that named types pass their > default sometimes (B, D) but not others (F). > It seems confusing that C and F do not produce the > same results. C and F do not produce the same result since they are different. The equivalent to C is this: typedef F { union { type uint32; type E; } default fred; } I think we have the same with other type properties: typedef apple { type uint32; units "apples"; } typedef peach { type stirng; units "peaches"; } typedef fruits { union { type apple; type peach; } } Again, fruits do not have an associated unit (I hope ;-) and I think this makes sense. /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 Thu Jun 11 15:42: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 303DF3A6E03 for ; Thu, 11 Jun 2009 15:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 x9-HkDHaZDGR for ; Thu, 11 Jun 2009 15:42:18 -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 549CA3A6DFE for ; Thu, 11 Jun 2009 15:42:18 -0700 (PDT) Received: (qmail 6543 invoked from network); 11 Jun 2009 22:42:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 11 Jun 2009 22:42:23 -0000 X-YMail-OSG: 4.NZwjcVM1lH23NrPAwoR_6zPELs8Ji.UW9YhW7dT9JlvxHuaq345CNiWct_BI64iTxIdFAaWLCIjtzqhx5cuVJ.Lg_1aRK4dJzPyEoKS2nW3II7fWcWvIBplqZOm0u1M.g3LykXAaI0zkabx6BsxkYVXRmudDs3f7jc4U8tHGARu.HLN.hJxGiJ.ogRZyfE2XwusD7tpmMvX6fcbPdWL0HBvcvtW3p_dpUmn.kGfcCBK1BDjGnjvHCWgHpnYR..VkfJ6nJ.vDbavFAO8nS47u.aLQIXt9vlSe_S6utELf.wIRgOmKhI X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A318837.5050505@netconfcentral.com> Date: Thu, 11 Jun 2009 15:41:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <1244702595.6390.7.camel@missotis> <20090611.142128.97622298.mbj@tail-f.com> <4A3115D2.1070700@netconfcentral.com> <20090611.190409.231051975.mbj@tail-f.com> <4A313E7E.1070907@netconfcentral.com> <20090611194311.GB612@elstar.local> In-Reply-To: <20090611194311.GB612@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] defaults and union X-BeenThere: netmod@ietf.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, 11 Jun 2009 22:42:19 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 11, 2009 at 07:27:26PM +0200, Andy Bierman wrote: > >> typedef A { >> type uint32; >> default 5; >> } >> >> typedef B { >> type A; >> } >> >> typedef C { >> type union { >> type uint32; >> type string; >> } >> default fred; >> } >> >> typedef D { >> type C; >> } >> >> typedef E { >> type string; >> default fred; >> } >> >> typedef F { >> union { >> type uint32; >> type E; >> } >> } >> >> type default >> --------------------- >> A 5 >> B 5 >> C fred >> D fred >> E fred >> F >> >> IMO, it is confusing that named types pass their >> default sometimes (B, D) but not others (F). >> It seems confusing that C and F do not produce the >> same results. > > C and F do not produce the same result since they are different. The > equivalent to C is this: > > typedef F { > union { > type uint32; > type E; > } > default fred; > } > OK -- I guess you are right. The default for a typedef-stmt can only be valid if there is an explicit default-stmt as a sub-statement of typedef-stmt. If a derived type is used, then all parent types are checked the same way. (Check the parent only if a direct derived type, not a derived type within a union.) typedef G { type B; } typedef H { type G; } default for type H is 5 > I think we have the same with other type properties: > > typedef apple { type uint32; units "apples"; } > typedef peach { type stirng; units "peaches"; } > > typedef fruits { > union { type apple; type peach; } > } > > Again, fruits do not have an associated unit (I hope ;-) and I think > this makes sense. > > /js > Andy From andy@netconfcentral.com Thu Jun 11 16:01: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 B9D133A6E0B for ; Thu, 11 Jun 2009 16:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 KmbVeC37Jbkt for ; Thu, 11 Jun 2009 16:01:15 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id BAFCD3A6A37 for ; Thu, 11 Jun 2009 16:01:14 -0700 (PDT) Received: (qmail 83364 invoked from network); 11 Jun 2009 23:01:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Jun 2009 23:01:19 -0000 X-YMail-OSG: FJJvKugVM1kzbdcgN0AyjAr7rKMJQj96zV971.zJ607c2v_FKki_uB73YKQt1jnTVQ88tRX8CI_5BR2XLZ9jTByuadoy9AqWCPIugbStVxASf3Y26HYYJYMVLfXarLIBxGgkJgw9lCs.5LgGBZS.8OJke_41c5MU6TRWwxrXjzj_7mg_QN5SxtYpIYTGU6ory7bQbPOIiQj3Lkr7Q660TQW_LB1HqD2CRQFjSKZRMuGnVN.RIznODvD4Ma4Yv8Lw8sFl2jJHNmtHcUUnpp_DBwrnUuciL0j1CPscO3hYFjmfxNySg95D X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A318CBD.4060702@netconfcentral.com> Date: Thu, 11 Jun 2009 16:01:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] defaults and ranges X-BeenThere: netmod@ietf.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, 11 Jun 2009 23:01:15 -0000 Hi, Just reading sec. 9.2.4 again, to be sure, and the draft says it is OK to restrict the range further. typedef A { type uint32; default 42; } typedef B { type A { range "14 .. max"; } } typedef C { type B { range "min .. 41"; } } leaf busted { type C; } Type B is OK because the default 42 is still valid. What about type C? The range there is 14 .. 41, and the default of 32 is no longer valid. I just check my code and it does the wrong thing in both places: 1) fails to detect that typedef C is invalid 2) attempts to assign a default of 42 to leaf busted So what is the right answer? IMO, typedef C is invalid YANG. Andy From mbj@tail-f.com Thu Jun 11 23:18: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 02C593A6B92 for ; Thu, 11 Jun 2009 23:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.275, 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 J4tHWUG1bvgr for ; Thu, 11 Jun 2009 23:18:09 -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 393DD3A6AAA for ; Thu, 11 Jun 2009 23:18:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A2DCE616001; Fri, 12 Jun 2009 08:18:15 +0200 (CEST) Date: Fri, 12 Jun 2009 08:18:59 +0200 (CEST) Message-Id: <20090612.081859.82116593.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A318CBD.4060702@netconfcentral.com> References: <4A318CBD.4060702@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] defaults and ranges X-BeenThere: netmod@ietf.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, 12 Jun 2009 06:18:10 -0000 Andy Bierman wrote: > typedef A { > type uint32; > default 42; > } > > typedef B { > type A { > range "14 .. max"; > } > } > > typedef C { > type B { > range "min .. 41"; > } > } > > leaf busted { type C; } > > > Type B is OK because the default 42 is still valid. > What about type C? The range there is 14 .. 41, > and the default of 32 is no longer valid. [...] > So what is the right answer? > IMO, typedef C is invalid YANG. Section 7.3.4 says: If the base type has a default value, and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. If the base type's default value is not valid according to the new restrictions, the derived type MUST define a new default value. So this C is not legal. /martin From Washam.Fan@huaweisymantec.com Fri Jun 12 02:30: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 6B35F3A6A86 for ; Fri, 12 Jun 2009 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 wnPopNMJsB3l for ; Fri, 12 Jun 2009 02:30:50 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 6B4E63A6CB0 for ; Fri, 12 Jun 2009 02:30:50 -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.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KL400BQWD3KEN60@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Fri, 12 Jun 2009 17:30:56 +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 <0KL400GHUD3KEK10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 12 Jun 2009 17:30:56 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 12 Jun 2009 17:30:56 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Fri, 12 Jun 2009 17:30:56 +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: <4A318CBD.4060702@netconfcentral.com> References: <4A318CBD.4060702@netconfcentral.com> Cc: NETMOD Working Group Subject: Re: [netmod] defaults and ranges X-BeenThere: netmod@ietf.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, 12 Jun 2009 09:30:51 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Friday, June 12, 2009 7:01 am Subject: [netmod] defaults and ranges To: NETMOD Working Group > Hi, > > Just reading sec. 9.2.4 again, to be sure, > and the draft says it is OK to restrict the > range further. > > > typedef A { > type uint32; > default 42; > } > > typedef B { > type A { > range "14 .. max"; > } > } > > typedef C { > type B { > range "min .. 41"; > } > } > > leaf busted { type C; } > > > Type B is OK because the default 42 is still valid. > What about type C? The range there is 14 .. 41, > and the default of 32 is no longer valid. > > I just check my code and it does the wrong thing > in both places: > > 1) fails to detect that typedef C is invalid > 2) attempts to assign a default of 42 to leaf busted > > So what is the right answer? > IMO, typedef C is invalid YANG. IMO. if typedef C is equivalent to semantically typedef C { type uint32; range "14..41"; default 42; } then C in invalid. washam From dromasca@avaya.com Mon Jun 15 00:21: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 5BB1B3A6C1F for ; Mon, 15 Jun 2009 00:21:17 -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.175, 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 M5qsibxUSs3n for ; Mon, 15 Jun 2009 00:21:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 32BF828C0ED for ; Mon, 15 Jun 2009 00:21:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,220,1243828800"; d="txt'?scan'208,217";a="148533775" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2009 03:21:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jun 2009 03:21:20 -0400 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_01C9ED89.CDEA490D" Date: Mon, 15 Jun 2009 09:20:46 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAKCkWQ From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: [drinks] request for input X-BeenThere: netmod@ietf.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, 15 Jun 2009 07:21:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ED89.CDEA490D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9ED89.CDEA490D" ------_=_NextPart_002_01C9ED89.CDEA490D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Monday, June 15, 2009 5:37 AM To: drinks@ietf.org Subject: [drinks] request for input =09 =09 The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. =20 Thank you. Please reply to the list. =20 =20 ------_=_NextPart_002_01C9ED89.CDEA490D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: drinks-bounces@ietf.org=20 [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah=20 A
Sent: Monday, June 15, 2009 5:37 AM
To:=20 drinks@ietf.org
Subject: [drinks] request for=20 input

The protocol design team has been working on a = data model=20 and protocol for the registry provisioning interface.

We have associated with each public identifier = routing=20 information in the form of resolution answers on the name = server. =20 Initially we looked at specific types of routing info – such as = NS and NAPTR=20 Resource Records. We have heard feedback that this is too DNS-centric. = We are=20 discussing collapsing these into a “generic” Route Object. = This may lead to a=20 long set of attributes, one would be route type, but many others would = be=20 optional and may only apply to a given route type.

We would appreciate some feedback –does it = make sense to=20 collapse into a generic Route Object? Other suggestions are=20 welcome.

 

Thank you. Please reply to the = list.

 

 

------_=_NextPart_002_01C9ED89.CDEA490D-- ------_=_NextPart_001_01C9ED89.CDEA490D Content-Type: text/plain; name="ATT18853855.txt" Content-Transfer-Encoding: base64 Content-Description: ATT18853855.txt Content-Disposition: inline; filename="ATT18853855.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRyaW5rcyBt YWlsaW5nIGxpc3QNCmRyaW5rc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kcmlua3MNCg== ------_=_NextPart_001_01C9ED89.CDEA490D-- From reid@snmp.com Thu Jun 18 08:21: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 9FAC628C14F for ; Thu, 18 Jun 2009 08:21:17 -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 DnlmCKG5u1l5 for ; Thu, 18 Jun 2009 08:21:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 9D3733A6819 for ; Thu, 18 Jun 2009 08:21:16 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA12078 for ; Thu, 18 Jun 2009 11:21:28 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA23126 for ; Thu, 18 Jun 2009 11:21:23 -0400 (EDT) Message-Id: <200906181521.LAA23126@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 18 Jun 2009 11:21:23 -0400 From: David Reid Subject: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 15:21:17 -0000 I have a question about error codes. If I try to set an object to a value that is the wrong type or is out of range, what is the correct error-tag? >From rfc4741, I thought it should be bad-element. But the yang spec clearly says invalid-value. rfc4741: Tag: bad-element Error-type: rpc, protocol, application Severity: error Error-info: : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch. Yang: o If a leaf data value does not match the type constraints for the leaf, including those defined in the type's range, length, and pattern properties, the server MUST reply with an "invalid-value" error-tag in the rpc-error, and with the error-app-tag and error- message assoicated with the constraint, if any exist. -David Reid From andy@netconfcentral.com Thu Jun 18 08:32: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 29DE328C3E5 for ; Thu, 18 Jun 2009 08:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.772, 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 dImbH39Ragb8 for ; Thu, 18 Jun 2009 08:32:48 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 5ADE628C3E2 for ; Thu, 18 Jun 2009 08:32:48 -0700 (PDT) Received: (qmail 26102 invoked from network); 18 Jun 2009 15:32:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 15:32:57 -0000 X-YMail-OSG: Ue8StKcVM1mZJAwFQTkBcwiKExGwOZeluyMX.XTF5gcSG9giwi1nKSkOK2kk8A1ZzLBykpOqAbBRiD9wh5gMcMdPaowI2pOvojr4hgz7wmWcUCuLwCH2mRcrg06B6hcugixLHv7pUdDzIWzFY_9tFxHTD8L333l0nWy03UtJUa6aH8o40T63HEjxIA58k4iBRfV2oXpFpulSILnILJv0flCrGie7iEQHBZJowfIdFWT4r.TEB4UqNNOhslHXkH5RIWYf75H.qNQ1Qp46 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3A5E27.1000402@netconfcentral.com> Date: Thu, 18 Jun 2009 08:32:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200906181521.LAA23126@adminfs.snmp.com> In-Reply-To: <200906181521.LAA23126@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 15:32:52 -0000 David Reid wrote: > I have a question about error codes. If I try to set an object to a value > that is the wrong type or is out of range, what is the correct error-tag? >>From rfc4741, I thought it should be bad-element. But the yang spec clearly > says invalid-value. > > rfc4741: > Tag: bad-element > Error-type: rpc, protocol, application > Severity: error > Error-info: : name of the element w/ bad value > Description: An element value is not correct; e.g., wrong type, > out of range, pattern mismatch. > > > Yang: > o If a leaf data value does not match the type constraints for the > leaf, including those defined in the type's range, length, and > pattern properties, the server MUST reply with an "invalid-value" > error-tag in the rpc-error, and with the error-app-tag and error- > message assoicated with the constraint, if any exist. > > I think this error-tag overlaps with invalid-value. I would follow the YANG spec, and use instead of to identify the error node. > -David Reid Andy From reid@snmp.com Thu Jun 18 08:55: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 45C7828C0EA for ; Thu, 18 Jun 2009 08:55:54 -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 Sd8X0RBos+vF for ; Thu, 18 Jun 2009 08:55:53 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id AC38A3A6CAB for ; Thu, 18 Jun 2009 08:55:52 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA15795; Thu, 18 Jun 2009 11:56:03 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA23589; Thu, 18 Jun 2009 11:56:02 -0400 (EDT) Message-Id: <200906181556.LAA23589@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Thu, 18 Jun 2009 08:32:55 -0700. <4A3A5E27.1000402@netconfcentral.com> Date: Thu, 18 Jun 2009 11:56:02 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 15:55:54 -0000 > I think this error-tag overlaps with invalid-value. > I would follow the YANG spec, and use > instead of to identify the error node. OK, thanks. A follow-up question: when do I use error-path and when do I use error-info? I'm looking at the example on page 15 of rfc4741 which uses error-info to identify the error node. application invalid-value error MTU value 25000 is not within range 256..9192 Ethernet0/0 25000 Let me try an example: module foo { namespace "http://example.com/foo"; prefix "foo"; list interface { key "name"; config true; leaf name { type string; } leaf speed { type enumeration { enum 10m; enum 100m; enum auto; } } leaf observed-speed { type uint32; config false; } } } I issue the following edit-config request with an invalid value for interface/speed: Ethernet0/0 BAD 10000 ]]>]]> My error reply looks something like this: application invalid-value error /interface[name=Ethernet0/0]/speed ]]>]]> Is my error-path right? Should there be anything for error-info? Is "application" the correct error-type? -David Reid From andy@netconfcentral.com Thu Jun 18 09:42: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 B4BA03A69D9 for ; Thu, 18 Jun 2009 09:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=1.717, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTXwWImIVf1h for ; Thu, 18 Jun 2009 09:42:42 -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 77AAC3A6CDA for ; Thu, 18 Jun 2009 09:42:42 -0700 (PDT) Received: (qmail 39254 invoked from network); 18 Jun 2009 16:42:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 16:42:53 -0000 X-YMail-OSG: cpwPQVMVM1nrcAEjxB36hIY7dL8zd8Y4eRUje5wz.WEXMXi3DQLZYZms_YfIYJwjYGURbW449MRw7kQx4z.2oLLJNnK5AsUmL6W_cv3FQdXwNSCquCLvt.TCNlVSPomjuVliBi3.i.OIz7gbrhBpPexOW.Cijwod8xb9xaPBNquEVNktu_heV8zHLDf2KykCMf7pTSZf.aRVlwOjTZDmx80NxykSdff6JC6qkO.ox1RHJxHOvaz2c_W4EIEcHS0SiwoqseHSETSwxoWuOzunbEXqijuZ._1jbpCpu3dGheOOjtRZ3N9t X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3A6E8A.1020707@netconfcentral.com> Date: Thu, 18 Jun 2009 09:42:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200906181556.LAA23589@adminfs.snmp.com> In-Reply-To: <200906181556.LAA23589@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 16:42:43 -0000 David Reid wrote: >> I think this error-tag overlaps with invalid-value. >> I would follow the YANG spec, and use >> instead of to identify the error node. > > OK, thanks. > > A follow-up question: when do I use error-path and when do I use error-info? > I'm looking at the example on page 15 of rfc4741 which uses error-info to > identify the error node. > > > application > invalid-value > error > > MTU value 25000 is not within range 256..9192 > > > > > Ethernet0/0 > 25000 > > > > > > IMO, most of the 'content' related examples in RFC 4741 and 5277 are horrible. They demonstrate how little the WG understood XPath, and the content layer at the time. (Including me.) > Let me try an example: > > module foo { > namespace "http://example.com/foo"; > prefix "foo"; > > list interface { > key "name"; > config true; > > leaf name { > type string; > } > leaf speed { > type enumeration { > enum 10m; > enum 100m; > enum auto; > } > } > leaf observed-speed { > type uint32; > config false; > } > } > } > > I issue the following edit-config request with an invalid value for > interface/speed: > > > > > > > Ethernet0/0 > BAD > 10000 > > > > > ]]>]]> > > > My error reply looks something like this: > > > > application > invalid-value > error > /interface[name=Ethernet0/0]/speed > > > ]]>]]> > > Is my error-path right? almost. /foo:interface[foo:name='Ethernet0/0']/foo:speed Of course, some implementations work whether the XML namespaces are present or not. This isn't XML to the letter I guess, but not as fragile either. BTW, you need to generate an additional for the writing to (config=false). > Should there be anything for error-info? whatever you want (in your namespace of course). I like to add whatever data I think can help the operator solve the problem faster. Fishing for more data wastes time. (e.g., , , etc.) I suggest using and every time as well. Use them before using . > Is "application" the correct error-type? yes If the error was with bogus, then the error-type would be 'operation'. > > -David Reid > > Andy From reid@snmp.com Thu Jun 18 10:49: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 CDB5C28C3D6 for ; Thu, 18 Jun 2009 10:49:06 -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 qAsnYfI0MaT5 for ; Thu, 18 Jun 2009 10:49:06 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 58D393A68F9 for ; Thu, 18 Jun 2009 10:48:49 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA24898; Thu, 18 Jun 2009 13:48:30 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA24813; Thu, 18 Jun 2009 13:48:25 -0400 (EDT) Message-Id: <200906181748.NAA24813@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Thu, 18 Jun 2009 09:42:50 -0700. <4A3A6E8A.1020707@netconfcentral.com> Date: Thu, 18 Jun 2009 13:48:24 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 17:49:06 -0000 > > I issue the following edit-config request with an invalid value for > > interface/speed: > > > > > > > > > > > > > > Ethernet0/0 > > BAD > > 10000 > > > > > > > > > > ]]>]]> > > > > > > My error reply looks something like this: > > > > > > > > application > > invalid-value > > error > > /interface[name=Ethernet0/0]/speed > > > > > > ]]>]]> > > > > Is my error-path right? > > > almost. > > > /foo:interface[foo:name='Ethernet0/0']/foo:speed > How do I know what the root node in my xpath expression should be? Why is it not /rpc/edit-config/config/interface[name='Ethernet0/0']/speed? -David Reid From andy@netconfcentral.com Thu Jun 18 10:55: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 5547028C444 for ; Thu, 18 Jun 2009 10:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 gGv+4lvhvk9b for ; Thu, 18 Jun 2009 10:55:34 -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 830F528C412 for ; Thu, 18 Jun 2009 10:55:34 -0700 (PDT) Received: (qmail 14347 invoked from network); 18 Jun 2009 17:55:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 17:55:47 -0000 X-YMail-OSG: .QxTnVMVM1nqLhzMC.BW2vsGyNlBKsfL2gW_4BVu5NP3WoenF5_re79DlVcrJvuKHWa9uXGwQRJfCBrvNdMriy7Ol24_Bevl4cp2Pi_lG59dT3D7dPL6eU1GnIArs19EVSqrT7IXL_wbXWs3rywZjHSIyRi7JZL3V4BH4asn.5tM37tcQ46zSMzJs2nrJb3gz1e9UTG7zu5lUyIbgdXIR4EmZcWl7SbpYeSNQYq4hGrorgzTMnHjJr8_3Ij2g.VhKvCjCnKu35Ua1NDbO0RUuiDL6iGkZQOtagDLpt0YLc6RX2gynpXKSvqOAnP42juaAE1K81SPJtWrBvwikeVhuGtv X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3A7FA1.1020903@netconfcentral.com> Date: Thu, 18 Jun 2009 10:55:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200906181748.NAA24813@adminfs.snmp.com> In-Reply-To: <200906181748.NAA24813@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 17:55:35 -0000 David Reid wrote: >>> I issue the following edit-config request with an invalid value for >>> interface/speed: >>> >>> >>> >>> >>> >>> >>> Ethernet0/0 >>> BAD >>> 10000 >>> >>> >>> >>> >>> ]]>]]> >>> >>> >>> My error reply looks something like this: >>> >>> >>> >>> application >>> invalid-value >>> error >>> /interface[name=Ethernet0/0]/speed >>> >>> >>> ]]>]]> >>> >>> Is my error-path right? >> >> almost. >> >> >> /foo:interface[foo:name='Ethernet0/0']/foo:speed >> > > How do I know what the root node in my xpath expression should be? Why is > it not /rpc/edit-config/config/interface[name='Ethernet0/0']/speed? > oops! you are right! It should be the path all the way back to /rpc if it exists. For and , the other form is used, starting with the data root. > -David Reid > > Andy From mbj@tail-f.com Thu Jun 18 10:59: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 3242428C373 for ; Thu, 18 Jun 2009 10:59:34 -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 JrZSUAVANIVf for ; Thu, 18 Jun 2009 10:59:33 -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 5F8F03A688A for ; Thu, 18 Jun 2009 10:59:33 -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 5555E616001; Thu, 18 Jun 2009 19:59:44 +0200 (CEST) Date: Thu, 18 Jun 2009 19:59:43 +0200 (CEST) Message-Id: <20090618.195943.162212110.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A3A7FA1.1020903@netconfcentral.com> References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@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 error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 17:59:34 -0000 Andy Bierman wrote: > David Reid wrote: > >>> I issue the following edit-config request with an invalid value for > >>> interface/speed: > >>> > >>> > >>> > >>> > >>> > >>> > >>> Ethernet0/0 > >>> BAD > >>> 10000 > >>> > >>> > >>> > >>> > >>> ]]>]]> > >>> > >>> > >>> My error reply looks something like this: > >>> > >>> > >>> > >>> application > >>> invalid-value > >>> error > >>> /interface[name=Ethernet0/0]/speed > >>> > >>> > >>> ]]>]]> > >>> > >>> Is my error-path right? > >> > >> almost. > >> > >> > >> /foo:interface[foo:name='Ethernet0/0']/foo:speed > >> > > How do I know what the root node in my xpath expression should be? Why is > > it not /rpc/edit-config/config/interface[name='Ethernet0/0']/speed? > > > > oops! > you are right! > It should be the path all the way back to /rpc > if it exists. For and , > the other form is used, starting with the data root. Well, this is one of the open issues for 4741bis. The current spec for error-path says: This element will not be present if no appropriate payload element can be associated with a particular error condition, so when you do , no error-path should be returned, according to 4741. (The info is of course needed, so if it is not returned in error-path it must be returned in some other element.) /martin From reid@snmp.com Thu Jun 18 11:30: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 813283A6A1C for ; Thu, 18 Jun 2009 11:30:12 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP+1MAWwCojl for ; Thu, 18 Jun 2009 11:30:11 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 5D88C3A6A8A for ; Thu, 18 Jun 2009 11:30:11 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA28487 for ; Thu, 18 Jun 2009 14:30:22 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA25683 for ; Thu, 18 Jun 2009 14:30:22 -0400 (EDT) Message-Id: <200906181830.OAA25683@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Thu, 18 Jun 2009 10:55:45 -0700. <4A3A7FA1.1020903@netconfcentral.com> Date: Thu, 18 Jun 2009 14:30:21 -0400 Sender: reid@snmp.com Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 18:30:12 -0000 > >>> Is my error-path right? > >> > >> almost. > >> > >> > >> /foo:interface[foo:name='Ethernet0/0']/foo:speed > >> > > > > How do I know what the root node in my xpath expression should be? Why is > > it not /rpc/edit-config/config/interface[name='Ethernet0/0']/speed? > > > > oops! > you are right! > It should be the path all the way back to /rpc > if it exists. I think it would be helpful to have an example rpc-error in the yang document. -David Reid From j.schoenwaelder@jacobs-university.de Thu Jun 18 13:35: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 871863A6981 for ; Thu, 18 Jun 2009 13:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 cI3GAW6+FbIE for ; Thu, 18 Jun 2009 13:35: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 929523A682A for ; Thu, 18 Jun 2009 13:35:00 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 686DBC004C; Thu, 18 Jun 2009 22:35:05 +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 qeUYK1HF7Mro; Thu, 18 Jun 2009 22:35: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 41E8FC004B; Thu, 18 Jun 2009 22:35:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 37950B47A3E; Thu, 18 Jun 2009 22:35:03 +0200 (CEST) Date: Thu, 18 Jun 2009 22:35:03 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090618203503.GB12298@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , "netmod@ietf.org" References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3A7FA1.1020903@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang error codes 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, 18 Jun 2009 20:35:01 -0000 On Thu, Jun 18, 2009 at 07:55:45PM +0200, Andy Bierman wrote: > oops! > you are right! > It should be the path all the way back to /rpc > if it exists. For and , > the other form is used, starting with the data root. Really? /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 Thu Jun 18 13:56: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 3F5783A6C00 for ; Thu, 18 Jun 2009 13:56:31 -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.460, 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 zq5IEBxEcVB6 for ; Thu, 18 Jun 2009 13:56:30 -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 61D343A6A50 for ; Thu, 18 Jun 2009 13:56:30 -0700 (PDT) Received: (qmail 68226 invoked from network); 18 Jun 2009 20:56:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 20:56:40 -0000 X-YMail-OSG: 236CEKoVM1m80wtWh6cTMJ2_wlYOZLd191FoXTw1dru4XqP58_IfQYXyqYbX7YB61ZPAfy_OENmFkI39npYlayyhOJTNcY52XOrZYAq2l9RFmJDjAWgKn8A7ZkIp0n6OQ1K1P0gqGiHM0lrUzjUzwQBS_FaUCKNhW0w.wOY6zkkvMBWVj3TNjB1Auz9ZbARq4tZw7VOJYKix.atTP546FX59X7XYrGTZG02GzZoR1afRWFpfEmMaYcy5xn5htwVY7Cyqu9c__RB6o8uv X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3AAA06.2080501@netconfcentral.com> Date: Thu, 18 Jun 2009 13:56:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , David Reid , "netmod@ietf.org" References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@netconfcentral.com> <20090618203503.GB12298@elstar.local> In-Reply-To: <20090618203503.GB12298@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 20:56:31 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 18, 2009 at 07:55:45PM +0200, Andy Bierman wrote: > >> oops! >> you are right! >> It should be the path all the way back to /rpc >> if it exists. For and , >> the other form is used, starting with the data root. > > Really? > well, if you want the operator to know why the failed, then using the instance-identifier of the node that had the error is useful. I should attach a disclaimer to every email: "Opinions expressed are my own." I don't let a careless sentence or two written 5 years ago get in the way of running code. NETCONF didn't have an i-i data type then. Put whatever you want in the . The market will decide if the data is useful or not. Clearly the WG (5 years ago) had very little clue what was useful or not. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Jun 18 14:00: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 7FB9E3A6B84 for ; Thu, 18 Jun 2009 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 wnNCmtFuiNLM for ; Thu, 18 Jun 2009 14:00:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AF73F3A6A50 for ; Thu, 18 Jun 2009 14:00:56 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 183A7C004F; Thu, 18 Jun 2009 23:01:09 +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 ttmQpoHmwm4k; Thu, 18 Jun 2009 23:01:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56447C004B; Thu, 18 Jun 2009 23:01:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0DB81B47BCE; Thu, 18 Jun 2009 23:01:06 +0200 (CEST) Date: Thu, 18 Jun 2009 23:01:05 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090618210105.GA12393@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , "netmod@ietf.org" References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@netconfcentral.com> <20090618203503.GB12298@elstar.local> <4A3AAA06.2080501@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3AAA06.2080501@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang error codes 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, 18 Jun 2009 21:00:57 -0000 On Thu, Jun 18, 2009 at 10:56:38PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jun 18, 2009 at 07:55:45PM +0200, Andy Bierman wrote: > > > >> oops! > >> you are right! > >> It should be the path all the way back to /rpc > >> if it exists. For and , > >> the other form is used, starting with the data root. > > > > Really? > > > > well, if you want the operator to know why the > failed, then using the instance-identifier of the node > that had the error is useful. This does not answer why the root has to be /rpc. And sorry for asking questions. /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 Thu Jun 18 14:04: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 0AE813A69AE for ; Thu, 18 Jun 2009 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, 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 A1DojNEylWpw for ; Thu, 18 Jun 2009 14:04:41 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id 0337D3A6923 for ; Thu, 18 Jun 2009 14:04:40 -0700 (PDT) Received: from [68.142.200.221] by n21.bullet.mail.mud.yahoo.com with NNFMP; 18 Jun 2009 21:04:50 -0000 Received: from [68.142.201.68] by t9.bullet.mud.yahoo.com with NNFMP; 18 Jun 2009 21:04:50 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 18 Jun 2009 21:04:50 -0000 X-Yahoo-Newman-Id: 492809.97987.bm@omp420.mail.mud.yahoo.com Received: (qmail 64070 invoked from network); 18 Jun 2009 21:04:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2009 21:04:49 -0000 X-YMail-OSG: 3hEJ3scVM1mZbxm8ISbC4vikSykRvPuixFwFo2v2VG.FCLnL6D4QwP8Qu6XFbGuDlaSrURUtJI59OyfxgqSea13DmpStaRkjQ5K1Ckxs2ktZSIWY.2r_WbTFF1erZvxU31RYRPXnkLVm2BbiOJ7oRSCq0rGDJFtPtAKtJwFQgsVL3LPVJfEtsEMwIM.nVmYQUkesRF8BXMkHpBKVHIBYu5d.svXi5WoFZy9NNvbc_SzBzUyCYpTg92bHkh5LEl.qEyTJ2Fe50pezvKTR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3AABF0.40200@netconfcentral.com> Date: Thu, 18 Jun 2009 14:04:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , David Reid , "netmod@ietf.org" References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@netconfcentral.com> <20090618203503.GB12298@elstar.local> In-Reply-To: <20090618203503.GB12298@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 21:04:42 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 18, 2009 at 07:55:45PM +0200, Andy Bierman wrote: > >> oops! >> you are right! >> It should be the path all the way back to /rpc >> if it exists. For and , >> the other form is used, starting with the data root. > > Really? > Actually, this is exactly what the YANG spec (sec. 13) says to do with the field for the 'instance-required' and 'missing-choice' errors. So, really. > /js > Andy From andy@netconfcentral.com Thu Jun 18 14:34: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 5EBC83A6CAE for ; Thu, 18 Jun 2009 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.251, 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 IgtHIuQIo03b for ; Thu, 18 Jun 2009 14:34:16 -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 84A713A6825 for ; Thu, 18 Jun 2009 14:34:16 -0700 (PDT) Received: (qmail 59345 invoked from network); 18 Jun 2009 21:34:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2009 21:34:26 -0000 X-YMail-OSG: ToaTk_wVM1mly8oBvAfqmCDZjjnyypjtAh8IE.EYC2P2TPLPgGgNFl9wJgDB4VxrL.UG1uimB7fOLNsSw4iUuuRZ7TeYUfjRXk4wL8esEX41rueTD5mLrQROpz87UyLCdpBwrK7tJJMm55AybsfWogkc8I81i.YwDA0RfMTP15BSp8dBZR8ojiz97TSESKnNepVEf3aR_zgj.scFC.BHB80awXuRPqxapjwFs9DwIsrphK0vO.05Uy4JllKxKRHqQj7AMp.TwahHEhn1 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3AB2E0.7050505@netconfcentral.com> Date: Thu, 18 Jun 2009 14:34:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , David Reid , "netmod@ietf.org" References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@netconfcentral.com> <20090618203503.GB12298@elstar.local> <4A3AAA06.2080501@netconfcentral.com> <20090618210105.GA12393@elstar.local> In-Reply-To: <20090618210105.GA12393@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 18 Jun 2009 21:34:17 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 18, 2009 at 10:56:38PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Jun 18, 2009 at 07:55:45PM +0200, Andy Bierman wrote: >>> >>>> oops! >>>> you are right! >>>> It should be the path all the way back to /rpc >>>> if it exists. For and , >>>> the other form is used, starting with the data root. >>> Really? >>> >> well, if you want the operator to know why the >> failed, then using the instance-identifier of the node >> that had the error is useful. > > This does not answer why the root has to be /rpc. And sorry > for asking questions. > error-path: Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace. My interpretation of this text is that the absolute XPath expression refers to the request PDU (i.e., element). > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Jun 18 23:12: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 9773428C0DE for ; Thu, 18 Jun 2009 23:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.028, 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 PvgHxvcCxpeS for ; Thu, 18 Jun 2009 23:12:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 54DA73A6B0A for ; Thu, 18 Jun 2009 23:12:33 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BA42C004F; Fri, 19 Jun 2009 08:12:45 +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 mECjDuNLG8Na; Fri, 19 Jun 2009 08:12: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 4C5CBC004E; Fri, 19 Jun 2009 08:12:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F17F6B47FA7; Fri, 19 Jun 2009 08:12:42 +0200 (CEST) Date: Fri, 19 Jun 2009 08:12:42 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090619061242.GA12665@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , "netmod@ietf.org" References: <200906181748.NAA24813@adminfs.snmp.com> <4A3A7FA1.1020903@netconfcentral.com> <20090618203503.GB12298@elstar.local> <4A3AABF0.40200@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3AABF0.40200@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang error codes 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, 19 Jun 2009 06:12:35 -0000 On Thu, Jun 18, 2009 at 11:04:48PM +0200, Andy Bierman wrote: > Actually, this is exactly what the YANG spec (sec. 13) > says to do with the field for > the 'instance-required' and 'missing-choice' errors. > So, really. I found this text: Error-path: Path to the element with the require-instance statement Error-path: Path to the element with the missing choice. The question was what the root for this path is. I do not find this spelled out anywhere - can you help me find it? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Fri Jun 19 06:25:36 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 13FDB3A6A66 for ; Fri, 19 Jun 2009 06:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 ePxu0uSkwrQb for ; Fri, 19 Jun 2009 06:25:34 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 9974D3A6A57 for ; Fri, 19 Jun 2009 06:25:34 -0700 (PDT) X-Trace: 224532160/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.207/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.207 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: AqkEAMcuO0o+vGnP/2dsb2JhbACDK1OLWq9sCZADAgeCToEyBQ X-IronPort-AV: E=Sophos;i="4.42,252,1243810800"; d="scan'208";a="224532160" X-IP-Direction: IN Received: from 1cust207.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.207]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Jun 2009 14:25:44 +0100 Message-ID: <002401c9f0d8$e0007ba0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "Andy Bierman" , "Martin Bjorklund" References: <200906181748.NAA24813@adminfs.snmp.com><4A3A7FA1.1020903@netconfcentral.com><20090618203503.GB12298@elstar.local><4A3AABF0.40200@netconfcentral.com> <20090619061242.GA12665@elstar.local> Date: Fri, 19 Jun 2009 14:22:50 +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: Re: [netmod] yang error codes 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, 19 Jun 2009 13:25:36 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" Sent: Friday, June 19, 2009 8:12 AM > On Thu, Jun 18, 2009 at 11:04:48PM +0200, Andy Bierman wrote: > > > Actually, this is exactly what the YANG spec (sec. 13) > > says to do with the field for > > the 'instance-required' and 'missing-choice' errors. > > So, really. > > I found this text: > > Error-path: Path to the element with the require-instance > statement > > Error-path: Path to the element with the missing choice. > > The question was what the root for this path is. I do not find this > spelled out anywhere - can you help me find it? Perhaps time to resurrect the thread that died out at the start of the month. Just to recap, XPath defines a root node which is the parent of the document element; that is what is, and I believe we should stick with it. So the question is what is the document element? This has to be defined whereever we use XPath since what is a 'document' is not obvious. 'must' and 'when' covers this, other places do not. Needs fixing. I do not have strong views about what the document element should be; I do have strong views that whereever we use XPath, it needs defining. was covered by Martin 28th May 2009. Tom Petch > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Fri Jun 19 07:24: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 ECCBD3A6966 for ; Fri, 19 Jun 2009 07:24:18 -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.397, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU4hCm33GhVy for ; Fri, 19 Jun 2009 07:24:18 -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 0CE273A67FC for ; Fri, 19 Jun 2009 07:24:18 -0700 (PDT) Received: (qmail 61178 invoked from network); 19 Jun 2009 14:24:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 Jun 2009 14:24:29 -0000 X-YMail-OSG: 3nmDEh4VM1lv47yW3_r9ei91IHNwqCMaQszPZEJjyoHeMmET7reC_IlL3T6OKf9DKaxrBwtICZgVZS5tA4c7RKPPyhXMxMNI8574myBzDx3iAp39_ca8e6m9dDLIRkOZ3YyjmC.fxo6Y7JTdDzh5FcUvcbSuMhNLwW3O.LFA.bh3U32axXVCqS7vtEwH1uQa9g6y1bewFC7YzfMADt8n1I6oXd9sHWzE0LZ1z2P5a6OFEDzE76lE8RnvdMhgLRnteTxRpPVoPKeTj0UpnOuh0Iy2dXHErdKzBGrjG2L8UwHdTWdpF9d4UkLidKUB.sgHx6gbxN0jxAe7TI.spmbZxzZYK2zonjk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3B9F86.2040806@netconfcentral.com> Date: Fri, 19 Jun 2009 07:24:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <200906181748.NAA24813@adminfs.snmp.com><4A3A7FA1.1020903@netconfcentral.com><20090618203503.GB12298@elstar.local><4A3AABF0.40200@netconfcentral.com> <20090619061242.GA12665@elstar.local> <002401c9f0d8$e0007ba0$0601a8c0@allison> In-Reply-To: <002401c9f0d8$e0007ba0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 19 Jun 2009 14:24:19 -0000 tom.petch wrote: > ---- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Friday, June 19, 2009 8:12 AM > >> On Thu, Jun 18, 2009 at 11:04:48PM +0200, Andy Bierman wrote: >> >>> Actually, this is exactly what the YANG spec (sec. 13) >>> says to do with the field for >>> the 'instance-required' and 'missing-choice' errors. >>> So, really. >> I found this text: >> >> Error-path: Path to the element with the require-instance >> statement >> >> Error-path: Path to the element with the missing choice. >> >> The question was what the root for this path is. I do not find this >> spelled out anywhere - can you help me find it? > > Perhaps time to resurrect the thread that died out at the start of the month. > > Just to recap, XPath defines a root node which is the parent of the document > element; that is what is, and I believe we should stick with it. So the > question is what is the document element? > > This has to be defined whereever we use XPath since what is a 'document' is not > obvious. 'must' and 'when' covers this, other places do not. Needs fixing. I > do not have strong views about what the document element should be; I do have > strong views that whereever we use XPath, it needs defining. > > was covered by Martin 28th May 2009. > You cannot equate YANG and NETCONF for all usage of XPath. YANG ignores the RPC layer in NETCONF, but cannot do the same. Obviously, starting the error-path at for ignores the top-level element, so any problems there would not be reportable. That is unacceptable. The error-path needs to identify any error node, whether it is in the input PDU or the database. It is trivial for an application to tell the difference, because nobody is ever allowed to define a YANG data node named in the NETCONF namespace. So, /nc:rpc cannot possibly be confused with a data node. Starting at any other point, such as the method name, would introduce ambiguity. Starting with /rpc is the only deterministic solution possible, without introducing new error fields, which means a new protocol version. > Tom Petch > >> /js >> Andy From andy@netconfcentral.com Fri Jun 19 11:27: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 C0D083A6A22 for ; Fri, 19 Jun 2009 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.215, 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 N0PoFd6u5D6e for ; Fri, 19 Jun 2009 11:27:03 -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 1F0D03A6807 for ; Fri, 19 Jun 2009 11:27:02 -0700 (PDT) Received: (qmail 11716 invoked from network); 19 Jun 2009 18:27:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2009 18:27:13 -0000 X-YMail-OSG: mF8hD.sVM1nGcQTpkA.P6YElhvEzHtAyZ0_8G7piRNCBgwy8yBQ543WASsxrxsV4U1jyE7hF30LCbzVwt5bNPG51kFa0emyoY.Mx48tGD.r1Bdy5jcN6J7O413qjKirYiM902ZKYXfmB4qBwVPoxZ1Ph0R53qI4DD9FJtatcbQ_JK4n2LcqUvqNTI.9lkcZz6VHnhQX14xEAV6UdOqTes2d7EIegDb5qHhFAbtAzYV5rQIB17uWmYNKYbCkOPsMCXc8VdVwPMPJ7ByMp80KjJaZE56APqZhcEQiMfqwtUDFkIBlqfjEtjJfw9YLXPZ5nGorXPdz5WC2roE7Z5tOTeiNH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3BD880.3070007@netconfcentral.com> Date: Fri, 19 Jun 2009 11:27:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] more yang-types (!) X-BeenThere: netmod@ietf.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, 19 Jun 2009 18:27:03 -0000 Hi, IMO, ietf-yang-types should define an 'admin-string' type. Also, why not add these 'time types' to ietf-yang-types as well: - years - months - weeks - days - hours - minutes - seconds - milli-seconds - micro-seconds - nano-seconds Instead of relying on individual usage of the units-stmt, put it in the typedef, so generic uint32 or uint64 is not the only semantics defined. These types may or may not matter to NETCONF. There should be comments in them that they are for SNMP compatibility. - object-identifier - object-identifier-128 - timeticks - timestamp YANG needs a real object-identifier derived type to go along with the instance-identifier built-in type. It should follow the absolute-schema-nodeid ABNF rule, except the prefixes will be XML prefixes, not YANG prefixes. e.g., /if:interfaces/if:interface/if:ifInOctets YANG needs a real time-stamp, which should be 'date-and-time' in canonical (UTC) format. Perhaps a 'time-delta' type as well. Andy From andy@andybierman.com Fri Jun 19 20:26: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 BAA033A6BB3 for ; Fri, 19 Jun 2009 20:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOZqkAS6CZSX for ; Fri, 19 Jun 2009 20:26:32 -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 56A943A6A7D for ; Fri, 19 Jun 2009 20:26:30 -0700 (PDT) Received: (qmail 2828 invoked from network); 20 Jun 2009 03:26:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 20 Jun 2009 03:26:41 -0000 X-YMail-OSG: it7tpu0VM1ks5jcGxLwNX3XB7xoGbfvi6HTSaVCf_HcyoHXA_1PIgpyfoxJnCMBigI_lz9vNmqmGYzq92LDLe30MEeg4y5Fs9RqVCrrmiZJhKl.KsnEOGBOfAvlgl.FKNS78oUvlyddTn3ViaoGH6Q5yLthSAgDk_9URw_0iuj4wrvznbrX2R4JnP.G4I4Q7YCmldDkmFdgvIlw8o3U4fTIrk0qcxtmEvOUc2URN2Qp24pQqq1PQm7r9li0whAeVAEv1k.FWD_z9r1w4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3C56F0.8070707@andybierman.com> Date: Fri, 19 Jun 2009 20:26:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] union CLR in the way X-BeenThere: netmod@ietf.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, 20 Jun 2009 03:26:35 -0000 Hi, I just ran into the 'no empty allowed in a union' CLR. I know Juergen wanted this before, and now I'm implementing a YANG-based CLI, I have another use case. rpc history { // descriptions deleted for brevity input { // default if no choice entered ncx:default-parm show; choice history-action { default show; leaf show { type union { type uint32; type empty; } default 25; } leaf save { type union { type string; type empty; } default "~/.yangcli_history"; } leaf load { type union { type string; type empty; } default "~/.yangcli_history"; } leaf clear { type empty; } } } } The point is that for the show, save, and load variants of the command, there can be 2 forms. The empty form will signal that the default be used, even though that won't be the final data type. E.g., history [same as history show] history show [same as history show=25] history save [saves with the default name] history save=temp_history_file [saves with the specified name] But yangdump issues fatal errors about 'empty type in a union'. IMO, empty in a key is a problem, but empty in a union is a feature. Andy From andy@netconfcentral.com Fri Jun 19 21:24: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 1644F3A6822 for ; Fri, 19 Jun 2009 21:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.206, 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 GxmghbKat45W for ; Fri, 19 Jun 2009 21:24:43 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 764E43A6778 for ; Fri, 19 Jun 2009 21:24:43 -0700 (PDT) Received: (qmail 92833 invoked from network); 20 Jun 2009 04:24:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 20 Jun 2009 04:24:52 -0000 X-YMail-OSG: VBINih4VM1lHoGvjO6GVWahUyFXJxEopilnDlyYOgQS80i7Z_yS4Est_zZAAyIvv_PrXrG7R_Na89OWQQTfZoLq3dbqOAThJuJQpfeisGZMzDpummtqIyYFmvMD5Nq9ddgE66hxcjL98NY6tRdGQN9W6hmF3T17ILLhWij1FmKryhpxBFMxr3dXXgQVFtgqmbDbsMWg9Nd28sZfihmo9a.fFzc8nkMYOTBHF0rnDLauW_feLbM7JA65HZdZup81APoZnnFpQYXfQ6RyVnrDGe.9GLtUhCa3B4KQqcv4m05pCTo7PekeB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3C6493.4010201@netconfcentral.com> Date: Fri, 19 Jun 2009 21:24:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group References: <4A3C56F0.8070707@andybierman.com> In-Reply-To: <4A3C56F0.8070707@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] union CLR in the way X-BeenThere: netmod@ietf.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, 20 Jun 2009 04:24:44 -0000 .... > IMO, empty in a key is a problem, Actually, empty in a key is not a problem. The ABNF for a key predicate now requires a value, but XPath does not require that. A predicate in an instance-identifier could have the form [foo] (for empty), or [foo='value'] (for all other types). > but empty in a union is a feature. > > Andy From Washam.Fan@huaweisymantec.com Sun Jun 21 19:17:36 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 51F9228C193 for ; Sun, 21 Jun 2009 19:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.332, 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 oMzy67s82N6v for ; Sun, 21 Jun 2009 19:17:35 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 3C54628C184 for ; Sun, 21 Jun 2009 19:17:35 -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 <0KLM00DNXBPOX650@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Mon, 22 Jun 2009 10:17:48 +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 <0KLM00BUWBPOQP00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Mon, 22 Jun 2009 10:17:48 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 22 Jun 2009 10:17:48 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 22 Jun 2009 10:17:48 +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: <4A3C56F0.8070707@andybierman.com> References: <4A3C56F0.8070707@andybierman.com> Cc: NETMOD Working Group Subject: Re: [netmod] union CLR in the way X-BeenThere: netmod@ietf.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, 22 Jun 2009 02:17:36 -0000 Hi, Why the empty type implies default is used? It is no value setting that implies default is used. If I define as, e.g., leaf show { type unit32: default 25; } The belowing is ture, since no value setting implies default is used: history show [same as history show=25] By the way, if show belongs to empty type, it can NOT have any value. washam ----- Original Message ----- From: Andy Bierman Date: Saturday, June 20, 2009 11:27 am Subject: [netmod] union CLR in the way To: NETMOD Working Group > Hi, > > I just ran into the 'no empty allowed in a union' CLR. > > I know Juergen wanted this before, and now I'm implementing > a YANG-based CLI, I have another use case. > > rpc history { > // descriptions deleted for brevity > input { > // default if no choice entered > ncx:default-parm show; > > choice history-action { > default show; > > leaf show { > type union { > type uint32; > type empty; > } > default 25; > } > > leaf save { > type union { > type string; > type empty; > } > default "~/.yangcli_history"; > } > > leaf load { > type union { > type string; > type empty; > } > default "~/.yangcli_history"; > } > > leaf clear { > type empty; > } > } > } > } > > The point is that for the show, save, and load variants > of the command, there can be 2 forms. The empty form > will signal that the default be used, even though that > won't be the final data type. E.g., > > history > [same as history show] > > history show > [same as history show=25] > > history save > [saves with the default name] > > history save=temp_history_file > [saves with the specified name] > > > But yangdump issues fatal errors about 'empty type in a union'. > > IMO, empty in a key is a problem, > but empty in a union is a feature. > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Mon Jun 22 05:42: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 8054B28C1CF for ; Mon, 22 Jun 2009 05:42:56 -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_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 1ifHk0maYiJ6 for ; Mon, 22 Jun 2009 05:42:55 -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 676DD3A67F2 for ; Mon, 22 Jun 2009 05:42:55 -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 2DE2E616001; Mon, 22 Jun 2009 14:43:09 +0200 (CEST) Date: Mon, 22 Jun 2009 14:43:08 +0200 (CEST) Message-Id: <20090622.144308.153231311.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <003a01c9e5c3$cd0c7960$0601a8c0@allison> References: <004101c9e46e$0e372400$0601a8c0@allison> <1244101182.6524.27.camel@missotis> <003a01c9e5c3$cd0c7960$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] definitions X-BeenThere: netmod@ietf.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, 22 Jun 2009 12:42:56 -0000 SGksDQoNCiJ0b20ucGV0Y2giIDxjZmluc3NAZGlhbC5waXBleC5jb20+IHdyb3RlOg0KPiAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJMYWRpc2xhdiBMaG90a2EiIDxsaG90 a2FAY2VzbmV0LmN6Pg0KPiBUbzogInRvbS5wZXRjaCIgPGNmaW5zc0BkaWFsLnBpcGV4LmNvbT4N Cj4gQ2M6ICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+OyA8bmV0bW9kQGlldGYu b3JnPg0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAwNCwgMjAwOSA5OjM5IEFNDQo+IFN1YmplY3Q6 IFJlOiBbbmV0bW9kXSBkZWZpbml0aW9ucw0KPiANCj4gDQo+ID4gdG9tLnBldGNoIHDDrcWhZSB2 IFN0IDAzLiAwNi4gMjAwOSB2IDE5OjA2ICswMjAwOg0KPiA+ID4gPiA+IFRoZSAiaW1wb3J0IiBz dGF0ZW1lbnQgbWFrZXMgaWRlbnRpZmllcnMgZnJvbSB0aGUgbmFtZXNwYWNlIG9mIHRoZQ0KPiA+ ID4gPiA+IGltcG9ydGVkIG1vZHVsZSBhdmFpbGFibGUgaW4gdGhlIGltcG9ydGluZyBtb2R1bGUu IEluIHBhcnRpY3VsYXIsIHRoZQ0KPiA+ID4gPiA+IGltcG9ydGluZyBtb2R1bGUgbWF5DQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBvIHVzZSBncm91cGluZ3MgYW5kIHR5cGVkZWZzIGRlZmluZWQgYXQg dGhlIHRvcCBsZXZlbCBvZiB0aGUgaW1wb3J0ZWQNCj4gPiA+ID4gPiAgIG1vZHVsZTsNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IG8gcmVmZXIgdG8gZmVhdHVyZXMgZGVmaW5lZCBpbiB0aGUgaW1wb3J0 ZWQgbW9kdWxlOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gbyB1c2UgYW55IGRhdGEgbm9kZSBvZiB0 aGUgaW1wb3J0ZWQgbW9kdWxlIGFzIHRoZSB0YXJnZXQgbm9kZSBmb3IgdGhlDQo+ID4gPiA+ID4g ICAiYXVnbWVudCIgc3RhdGVtZW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVW5saWtlICJpbmNs dWRlIiwgdGhlICJpbXBvcnQiIHN0YXRlbWVudCBkb2Vzbid0IGNvbnRyaWJ1dGUgdGhlIGRhdGEN Cj4gPiA+ID4gPiB0cmVlIGZyb20gdGhlIGltcG9ydGVkIHRvIHRoZSBpbXBvcnRpbmcgbW9kdWxl Lg0KPiA+ID4gPg0KPiA+ID4gPiBJJ20gbm90IHN1cmUgdGhpcyB0ZXh0IGlzIGJldHRlciB0aGFu IHRoZSBjdXJyZW50IHRleHQuICBEb2VzIGFueW9uZQ0KPiA+ID4gPiBlbHNlIGhhdmUgYW4gb3Bp bmlvbj8NCj4gPiA+DQo+ID4gPiBZZXM7IGJvdGggbWlnaHQgYmUgY2xlYXJlcjotKCBUaGUgYnVs bGV0ZWQgbGlzdCBpcyBhbiBpbXByb3ZlbWVudCwgYnV0IEkgZG8NCj4gbm90DQo+ID4gPiBzZWUg ImlkZW50aWZpZXJzIiBhcyBhbiBpbXByb3ZlbWVudDsgaXQgaXMgbW9yZSB0aGFuIGlkZW50aWZp ZXJzLCBpdCBpcyB0aGUNCj4gPiA+IGlkZW50aXR5LCB0aGUgY29uY2VwdCB0aGF0IGlzIGJlaW5n IGlkZW50aWZpZWQuICBEZWZpbml0aW9ucyBpcyBuZWFyZXIgdGhlDQo+IG1hcmsNCj4gPiA+IGJ1 dCBzdGlsbCwgZm9yIG1lLCB1bmRlcnN0YXRlcyB3aGF0IGlzIG9uIG9mZmVyLg0KPiA+DQo+ID4g WWVzLCBidXQgaXQgaXMgaW1wb3J0YW50IHRvIHN0cmVzcyB0aGF0IHRoZSBzY2hlbWEgdHJlZSBp cyBub3QgaW1wb3J0ZWQuDQo+ID4gQ2FuIHlvdSBzdWdnZXN0IGFub3RoZXIgZm9ybXVsYXRpb24/ DQo+IA0KPiBJIHdvdWxkIGdvIGZvciAnb2JqZWN0cycgb3IgJ2VudGl0aWVzJyAob3IgJ2l0ZW1z JykgYm90aCBvZiB3aGljaCBoYXZlDQo+IHRlY2huaWNhbA0KPiBtZWFuaW5ncyBpbiBzb21lIGNv bnRleHRzLCBidXQgYWxzbyBjYW4gc2FmZWx5IGJlIHVzZWQgbW9yZSBnZW5lcmljYWxseS4NCj4g DQo+IEFuZCBhZGQgdGhhdCBwaHJhc2UsIGdpdmluZw0KPiANCj4gVGhlICJpbXBvcnQiIHN0YXRl bWVudCBtYWtlcyBvYmplY3RzLCBidXQgbm90IHRoZSBzY2hlbWEgdHJlZSwgZnJvbSB0aGUNCj4g bmFtZXNwYWNlIG9mIHRoZSBpbXBvcnRlZCBtb2R1bGUgYXZhaWxhYmxlIGluIHRoZSBpbXBvcnRp bmcgbW9kdWxlLiBJbg0KPiBwYXJ0aWN1bGFyLCB0aGUgaW1wb3J0aW5nIG1vZHVsZSBtYXk6LQ0K DQpJIGRvbid0IHRoaW5rICJvYmplY3QiIGlzIGEgZ29vZCB3b3JkOyBpdCBpcyBub3Qgb2J2aW91 cyB0aGF0IGUuZy4gYQ0KZmVhdHVyZSBpcyBhbiAib2JqZWN0Ii4gIEFsc28sIEkgZG9uJ3QgdGhp bmsgaXQgaXMgYWNjdXJhdGUgdG8gc2F5DQp0aGF0IHRoZSBzY2hlbWEgdHJlZSBpcyBub3QgYXZh aWxhYmxlLCBzaW5jZSBpdCBpcyBsZWdhbCB0byByZWZlciB0bw0Kbm9kZXMgaW4gdGhlIHNjaGVt YSB0cmVlIGluIGUuZy4gYXVnbWVudC4gIFNvIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nDQpjb21w cm9taXNlOg0KDQo3LjEuNS4gIFRoZSBpbXBvcnQgU3RhdGVtZW50DQoNCiAgIFRoZSAiaW1wb3J0 IiBzdGF0ZW1lbnQgbWFrZXMgZGVmaW5pdGlvbnMgZnJvbSBvbmUgbW9kdWxlIGF2YWlsYWJsZQ0K ICAgaW5zaWRlIGFub3RoZXIgbW9kdWxlIG9yIHN1Ym1vZHVsZS4gIFRoZSBhcmd1bWVudCBpcyB0 aGUgbmFtZSBvZiB0aGUNCiAgIG1vZHVsZSB0byBpbXBvcnQsIGFuZCB0aGUgc3RhdGVtZW50IGlz IGZvbGxvd2VkIGJ5IGEgYmxvY2sgb2YNCiAgIHN1YnN0YXRlbWVudHMgdGhhdCBob2xkcyBkZXRh aWxlZCBpbXBvcnQgaW5mb3JtYXRpb24uICBXaGVuIGEgbW9kdWxlDQogICBpcyBpbXBvcnRlZCwg dGhlIGltcG9ydGluZyBtb2R1bGUgbWF5Og0KDQogICBvICB1c2UgYW55IGdyb3VwaW5nIGFuZCB0 eXBlZGVmIGRlZmluZWQgYXQgdGhlIHRvcC1sZXZlbCBpbiB0aGUNCiAgICAgIGltcG9ydGVkIG1v ZHVsZSBvciBpdHMgc3VibW9kdWxlcw0KDQogICBvICB1c2UgYW55IGV4dGVuc2lvbiwgZmVhdHVy ZSwgYW5kIGlkZW50aXR5IGRlZmluZWQgaW4gdGhlIGltcG9ydGVkDQogICAgICBtb2R1bGUgb3Ig aXRzIHN1Ym1vZHVsZXMNCg0KICAgbyAgdXNlIGFueSBub2RlIGluIHRoZSBpbXBvcnRlZCBtb2R1 bGUncyBzY2hlbWEgdHJlZSBpbiBhdWdtZW50LA0KICAgICAgbXVzdCwgcGF0aCwgYW5kIHdoZW4g c3RhdGVtZW50cw0KDQoNCi9tYXJ0aW4NCg== From mbj@tail-f.com Mon Jun 22 05:55: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 80C8B3A6846 for ; Mon, 22 Jun 2009 05:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, 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 gwPeUeXHVW5F for ; Mon, 22 Jun 2009 05:55:09 -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 9A0783A67F2 for ; Mon, 22 Jun 2009 05:55:09 -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 4392D6160AD; Mon, 22 Jun 2009 14:55:22 +0200 (CEST) Date: Mon, 22 Jun 2009 14:54:38 +0200 (CEST) Message-Id: <20090622.145438.263050460.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090611194311.GB612@elstar.local> References: <20090611.190409.231051975.mbj@tail-f.com> <4A313E7E.1070907@netconfcentral.com> <20090611194311.GB612@elstar.local> 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] defaults and union X-BeenThere: netmod@ietf.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, 22 Jun 2009 12:55:10 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 11, 2009 at 07:27:26PM +0200, Andy Bierman wrote: > > > typedef A { > > type uint32; > > default 5; > > } > > > > typedef B { > > type A; > > } > > > > typedef C { > > type union { > > type uint32; > > type string; > > } > > default fred; > > } > > > > typedef D { > > type C; > > } > > > > typedef E { > > type string; > > default fred; > > } > > > > typedef F { > > union { > > type uint32; > > type E; > > } > > } > > > > type default > > --------------------- > > A 5 > > B 5 > > C fred > > D fred > > E fred > > F > > > > IMO, it is confusing that named types pass their > > default sometimes (B, D) but not others (F). > > It seems confusing that C and F do not produce the > > same results. > > C and F do not produce the same result since they are different. The > equivalent to C is this: > > typedef F { > union { > type uint32; > type E; > } > default fred; > } > > I think we have the same with other type properties: > > typedef apple { type uint32; units "apples"; } > typedef peach { type stirng; units "peaches"; } > > typedef fruits { > union { type apple; type peach; } > } > > Again, fruits do not have an associated unit (I hope ;-) and I think > this makes sense. I agree. Would this text help in section 9.12: Any default values or units properties defined in the member types are not inherited to the union type. /martin From andy@netconfcentral.com Mon Jun 22 08:38: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 C6FE13A6A08 for ; Mon, 22 Jun 2009 08:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 38hMLSw0ykWx for ; Mon, 22 Jun 2009 08:38:04 -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 30BB13A6DEC for ; Mon, 22 Jun 2009 08:38:04 -0700 (PDT) Received: (qmail 33785 invoked from network); 22 Jun 2009 15:38:17 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 22 Jun 2009 15:38:17 -0000 X-YMail-OSG: BoK1o_sVM1ntSo1WwCw8HhSABDGoE.3Z4kn_OymQ2x1h6eMb1t81IVqHRdD78_S9SrnEMDdwc1WXdE9Skrz9l3yTKqfGjQFDP6Fz4UuUY1Z9eSpUXoLr10uykGBHsRsRAgythASFxwtI9y85ryRp3fUAiPHFlSotfPDiH8ztceibpaFYGWYG6lLxV0MmyTK7CU_a3x8LhAD6.SZbA2lnDTedjfazJ_cu3mYzmAaY.yd.JvW5Q57NUucl0TjXZNDioXIqV_de9geydG5CGf5Uxmd.qaUB7mwBl71KZT.58WRUaKDPlfqg X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3FA53F.5080207@netconfcentral.com> Date: Mon, 22 Jun 2009 08:37:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: WashamFan References: <4A3C56F0.8070707@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] union CLR in the way X-BeenThere: netmod@ietf.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, 22 Jun 2009 15:38:04 -0000 WashamFan wrote: > Hi, > > Why the empty type implies default is used? > It is no value setting that implies default is used. > If I define as, e.g., > > leaf show { > type unit32: > default 25; > } > > The belowing is ture, since no value setting implies default > is used: > > history show > [same as history show=25] > We should not confuse proprietary CLI encoding with standard XML encoding. It is not within the charter at all. > By the way, if show belongs to empty type, it can NOT have > any value. In XML, we already have the feature I want, because 'string' is allowed to be empty, which can be encoded 2 ways: Some applications ignore XML encoding rules wrt/ significant whitespace, so an agent might even accept this as an empty as well: I can do the same thing in my CLI. foo foo = '' can mean the same thing. So I don't care if the union/key CLRs get removed. They are a good little test for people who think they know YANG, but really don't. Unfortunately, I have found that several smart people I know read some of the drafts and extrapolate the rest. Their logical assumptions are mostly wrong, since CLRs are usually illogical. > > washam Andy From andy@netconfcentral.com Mon Jun 22 09:27: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 1D9D928C1CF for ; Mon, 22 Jun 2009 09:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 d0E2nBmNJN6t for ; Mon, 22 Jun 2009 09:27:22 -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 4966B3A6AC6 for ; Mon, 22 Jun 2009 09:27:22 -0700 (PDT) Received: (qmail 72865 invoked from network); 22 Jun 2009 16:27:35 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 22 Jun 2009 16:27:35 -0000 X-YMail-OSG: TwGFN6gVM1mJKfd7knaf2spDMGVkrtX8TQL5J4tyxvO64AvmQ9bGM1Ms8umy_Kt4DeDX_YoGJNvjy8LfeE0ITQVe1ux_TF0RZp4SBEzYvV5ZL4atfoB2FYoWw18S5X_ojbK3iv1cfblIXeHkEP2.dF5VY7tdytUCUravNrq8r.X_hZDlor.zp8gH2BVKBs6C3xAo2jJJjd0Ah12gTnyzIcxJay783AmjwpvFkyu8NmWXLWR7VNUQVN19a2DpO_DijbHhGrqfcrQZgdZAh3GsgeGdag4FerwZ0108oN3fZesspIq3VqQ_eDDOpgrzEdLUiXyRiVZ6_qgntU8Men5X X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3FB0CD.80303@netconfcentral.com> Date: Mon, 22 Jun 2009 09:26:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Martin Bjorklund References: <004101c9e46e$0e372400$0601a8c0@allison> <1244101182.6524.27.camel@missotis> <003a01c9e5c3$cd0c7960$0601a8c0@allison> <20090622.144308.153231311.mbj@tail-f.com> In-Reply-To: <20090622.144308.153231311.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] definitions X-BeenThere: netmod@ietf.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, 22 Jun 2009 16:27:23 -0000 Martin Bjorklund wrote: > Hi, > > "tom.petch" wrote: >> ----- Original Message ----- >> From: "Ladislav Lhotka" >> To: "tom.petch" >> Cc: "Martin Bjorklund" ; >> Sent: Thursday, June 04, 2009 9:39 AM >> Subject: Re: [netmod] definitions >> >> >>> tom.petch píše v St 03. 06. 2009 v 19:06 +0200: >>>>>> The "import" statement makes identifiers from the namespace of the >>>>>> imported module available in the importing module. In particular, the >>>>>> importing module may >>>>>> >>>>>> o use groupings and typedefs defined at the top level of the imported >>>>>> module; >>>>>> >>>>>> o refer to features defined in the imported module; >>>>>> >>>>>> o use any data node of the imported module as the target node for the >>>>>> "augment" statement. >>>>>> >>>>>> Unlike "include", the "import" statement doesn't contribute the data >>>>>> tree from the imported to the importing module. >>>>> I'm not sure this text is better than the current text. Does anyone >>>>> else have an opinion? >>>> Yes; both might be clearer:-( The bulleted list is an improvement, but I do >> not >>>> see "identifiers" as an improvement; it is more than identifiers, it is the >>>> identity, the concept that is being identified. Definitions is nearer the >> mark >>>> but still, for me, understates what is on offer. >>> Yes, but it is important to stress that the schema tree is not imported. >>> Can you suggest another formulation? >> I would go for 'objects' or 'entities' (or 'items') both of which have >> technical >> meanings in some contexts, but also can safely be used more generically. >> >> And add that phrase, giving >> >> The "import" statement makes objects, but not the schema tree, from the >> namespace of the imported module available in the importing module. In >> particular, the importing module may:- > > I don't think "object" is a good word; Agreed. We should make sure that YANG and the Usage Guidelines drafts use consistent and deliberate terminology. I like the current 'data node' and 'schema node', but they are not 1:1 and that is important to remember. I like the term "YANG content" to refer to anything in a NETCONF PDU that YANG covers (rpc, rpc-reply, notification content). The term 'data node' is just for a YANG-accessible XML element which is (conceptually) contained within a NETCONF configuration database. The term "YANG-accessible" refers to the XML (PDU) nodes which NETCONF/YANG operations MUST be supported. The contents of an 'anyxml' node, as well as any XML attributes outside the YANG and NETCONF namespaces, are not YANG-accessible. it is not obvious that e.g. a > feature is an "object". Also, I don't think it is accurate to say > that the schema tree is not available, since it is legal to refer to > nodes in the schema tree in e.g. augment. So I suggest the following > compromise: > > 7.1.5. The import Statement > > The "import" statement makes definitions from one module available > inside another module or submodule. The argument is the name of the > module to import, and the statement is followed by a block of > substatements that holds detailed import information. When a module > is imported, the importing module may: > > o use any grouping and typedef defined at the top-level in the > imported module or its submodules > > o use any extension, feature, and identity defined in the imported > module or its submodules > > o use any node in the imported module's schema tree in augment, > must, path, and when statements > this is good > > /martin Andy From wjhns1@hardakers.net Mon Jun 22 16:31: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 86E793A68D9 for ; Mon, 22 Jun 2009 16:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 dtJP2LoUgnzV for ; Mon, 22 Jun 2009 16:31:22 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id E01AC3A6A8C for ; Mon, 22 Jun 2009 16:31:21 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id A333098145; Mon, 22 Jun 2009 16:31:34 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 557B9399C38; Mon, 22 Jun 2009 16:31:32 -0700 (PDT) From: Wes Hardaker To: Martin Bjorklund Organization: Sparta References: <20090524.160238.199634663.mbj@tail-f.com> Date: Mon, 22 Jun 2009 16:31:31 -0700 In-Reply-To: <20090524.160238.199634663.mbj@tail-f.com> (Martin Bjorklund's message of "Sun, 24 May 2009 16:02:38 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] comments on netmod-yang-05 X-BeenThere: netmod@ietf.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, 22 Jun 2009 23:31:23 -0000 Martin, Sorry about the delay in a response but most of your note didn't need a response and it fell to my "response not immediately critical" time frame. Thanks for incorporating and/or reviewing my suggestions. I'm only responding to a few extra points that looked like they needed a more direct followup. WH> Section 4.2.3: WH> The example adds a few things not discussed so far: WH> "config true;" at the top: what's the default value? It must be true WH> based on the other examples? You should state one way or the other WH> (maybe in a // comment) that it's the default or not. MB> The second sentence in 4.2.3 says: MB> When a node is tagged with "config false", MB> its subhierarchy is flagged as state data MB> So it implies that if the node is not tagged with config false, and MB> does not belong to such a subhierarchy, then it is is config data. Understood. The thing I think, though, that might confuse a reader is why the first "config true;" is in there at all. If it's the default, leave it out to show it's the default. [4.2.8] MB> How about this rewording, and simplification: MB> NEW: MB> YANG allows a module to extend data models with additional nodes. I agree, that's better. > 6.1.3: > > It should be noted that many definitions of "whitespace" include > newlines, including standard regular expressions. > > # perl -l -e 'print "hello" if ("\n" =~ /\s/);' > hello > > But this section deviates from that and discusses whitespace heavily > but the examples show that newlines are exempt from being called > whitespace (and you really mean just spaces and tabs). (mostly in the > paragraph "trailing whitespace is stripped..." which would remove the \n) MB> We can't simply s/whitespace/space or tab/. Why not? Or simply state up front that whitespace in this document means just spaces and tabs and not newlines or returns. MB> Do you think it would work if we write: MB> If a string contains any whitespace characters (space or tab), I'd make it more explicit because you mention whitespace in multiple places and adding the () text in each instance you didn't want to do. > "A module SHOULD have the following layout:" > > What if it doesn't? Does that mean a parser implementation doesn't > have to accept it? (this is an example of text written toward the > author when it's the parser implementation that will be the most > affected but yet the text doesn't describe the requirements of the > implementation). MB> The exact rules are specified in the grammar. This text is there to MB> give the reader a quick overwiew of a what a module contains, instead MB> of having to figure it out from the grammar. Would it be better to MB> write MB> A module has the following layout: MB> or would that just make it worse? err... Different? If it's specified somewhere else that you should not expect things to definitively follow that order, then the SHOULD there is fine. If I'm an implementer of a parser all I want is to know whether I need to support YANG documents that are arbitrarily ordered. > 7.1.2: > > Is yang-version technically a string, decimal64 or binary blob? MB> Or an uint8, uint64... Does it matter what it is? Well, people may choose a data type in their code and APIs to pass around yang version references. If you later decide that "1.1.1" is a valid yang version and I had picked an uint8 I'll have to go change a bunch of APIs and code. Declaring it up front as a string or a float in the document prevents implementations from making incorrect choices (and also limits you in the future, which is likely ok as well). > 7.7.5: > > What happens when a client requests data from a system ordered set of > data, jumbles it (say makes it alphabetical according to how a user > sorted it on the screen) and sends it back (eg, via a replace)? This > isn't discussed... > > 1) can the server reject it? > 2) does the server have to parse it? MB> Why would the server reject it? Since there is no semantic order MB> defined, the client can send the data in any order, but the server is MB> free to re-order (but it doesn't have to). Because it's expensive to reorder if the cheap router server detects the ordering doesn't match their internal storage ordering requirements? The "ordered-by server" statement gives me the impression that something other than me (the user) is deciding what the proper ordering is and that is decided upon by the server. The text, however, is not clear as to whether or not it's allowed that the management console can reorder at will because it feels like it and the server has to accept it, or if the server does in deed have authority over the ordering because it's "the authoritative ordering source" and "thou shall not reorder my data". > 3) is the server allowed to define internal semantics of it's own > ordering? (see large routing table implementations) MB> I don't understand what you mean with "define internal semantics"? Consider the classic example of route table ordering. Different router implementations have different ways of storing routing data that is optimized for their internal processing requirements. If I, as a client, take a set of 10k routes and reorder them arbitrarily and give it back to the router it may be computationally intensive to reorder them. Honestly, I actually don't care one way or the other. My thinking is that documenting whether or not something marked as "ordered-by server" means that ordering CAN be important to the server (but you, the client, may not know what it is) is probably important. Simply stating that "ordered-by server" actually means "no ordering at all and feel free to jumble at will" is probably sufficient. Maybe change "ordered-by server" to "ordered-by none" would make more sense. Wes From mbj@tail-f.com Tue Jun 23 01:25: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 234893A692A for ; Tue, 23 Jun 2009 01:25:19 -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 G6XTMj8Debis for ; Tue, 23 Jun 2009 01:25:18 -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 A38BF3A68A5 for ; Tue, 23 Jun 2009 01:25:17 -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 A58D776C5C0; Tue, 23 Jun 2009 10:25:31 +0200 (CEST) Date: Tue, 23 Jun 2009 10:25:03 +0200 (CEST) Message-Id: <20090623.102503.97344494.mbj@tail-f.com> To: wjhns1@hardakers.net From: Martin Bjorklund In-Reply-To: References: <20090524.160238.199634663.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 Subject: Re: [netmod] comments on netmod-yang-05 X-BeenThere: netmod@ietf.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, 23 Jun 2009 08:25:19 -0000 Hi Wes, Wes Hardaker wrote: > WH> Section 4.2.3: > WH> The example adds a few things not discussed so far: > WH> "config true;" at the top: what's the default value? It must be true > WH> based on the other examples? You should state one way or the other > WH> (maybe in a // comment) that it's the default or not. > > > MB> The second sentence in 4.2.3 says: > > MB> When a node is tagged with "config false", > MB> its subhierarchy is flagged as state data > > MB> So it implies that if the node is not tagged with config false, and > MB> does not belong to such a subhierarchy, then it is is config data. > > > Understood. The thing I think, though, that might confuse a reader is > why the first "config true;" is in there at all. If it's the default, > leave it out to show it's the default. Ok. I will remove the first "config true;" statement. > > 6.1.3: > > > > It should be noted that many definitions of "whitespace" include > > newlines, including standard regular expressions. > > > > # perl -l -e 'print "hello" if ("\n" =~ /\s/);' > > hello > > > > But this section deviates from that and discusses whitespace heavily > > but the examples show that newlines are exempt from being called > > whitespace (and you really mean just spaces and tabs). (mostly in the > > paragraph "trailing whitespace is stripped..." which would remove the \n) > > MB> We can't simply s/whitespace/space or tab/. > > Why not? Or simply state up front that whitespace in this document > means just spaces and tabs and not newlines or returns. > > MB> Do you think it would work if we write: > > MB> If a string contains any whitespace characters (space or tab), > > I'd make it more explicit because you mention whitespace in multiple > places and adding the () text in each instance you didn't want to do. Ok, I will do s/whitespace/space or tab/ in some places to get e.g: If the double quoted string contains space or tab characters before a line break, this trailing whitespace is stripped from the string. Would that work? > > 7.1.2: > > > > Is yang-version technically a string, decimal64 or binary blob? > > MB> Or an uint8, uint64... Does it matter what it is? > > Well, people may choose a data type in their code and APIs to pass > around yang version references. If you later decide that "1.1.1" is a > valid yang version and I had picked an uint8 I'll have to go change a > bunch of APIs and code. Declaring it up front as a string or a float in > the document prevents implementations from making incorrect choices (and > also limits you in the future, which is likely ok as well). Ok. I will state that the argument is a string. That leaves us flexibility for the future. > > 7.7.5: > > > > What happens when a client requests data from a system ordered set of > > data, jumbles it (say makes it alphabetical according to how a user > > sorted it on the screen) and sends it back (eg, via a replace)? This > > isn't discussed... > > > > 1) can the server reject it? > > 2) does the server have to parse it? > > MB> Why would the server reject it? Since there is no semantic order > MB> defined, the client can send the data in any order, but the server is > MB> free to re-order (but it doesn't have to). > > Because it's expensive to reorder if the cheap router server detects the > ordering doesn't match their internal storage ordering requirements? But again, the cheap server doesn't have to reorder - it can choose to keep the data in the order it was given by the client, or any internal order. > The "ordered-by server" statement gives me the impression that something > other than me (the user) is deciding what the proper ordering is and > that is decided upon by the server. The text, however, is not clear as > to whether or not it's allowed that the management console can reorder > at will because it feels like it and the server has to accept it, or if > the server does in deed have authority over the ordering because it's > "the authoritative ordering source" and "thou shall not reorder my > data". > > > 3) is the server allowed to define internal semantics of it's own > > ordering? (see large routing table implementations) > > MB> I don't understand what you mean with "define internal semantics"? > > Consider the classic example of route table ordering. Different router > implementations have different ways of storing routing data that is > optimized for their internal processing requirements. If I, as a > client, take a set of 10k routes and reorder them arbitrarily and give > it back to the router it may be computationally intensive to reorder > them. > > > Honestly, I actually don't care one way or the other. My thinking is > that documenting whether or not something marked as "ordered-by server" > means that ordering CAN be important to the server (but you, the client, > may not know what it is) is probably important. Simply stating that > "ordered-by server" actually means "no ordering at all and feel free to > jumble at will" is probably sufficient. > > Maybe change "ordered-by server" to "ordered-by none" would make more sense. The text says: Thus an implementation is free to sort the entries in the most appropriate order. What should we write to make it more clear? /martin From cfinss@dial.pipex.com Tue Jun 23 03:59: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 489953A6B85 for ; Tue, 23 Jun 2009 03:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, 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 mg6PWFsW+Q-7 for ; Tue, 23 Jun 2009 03:59:34 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 2E5703A6A9A for ; Tue, 23 Jun 2009 03:59:34 -0700 (PDT) X-Trace: 225629200/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.105/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.105 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: AqgEAAdTQEo+vGlp/2dsb2JhbACDK1SLU79uCYI0gU0F X-IronPort-AV: E=Sophos;i="4.42,275,1243810800"; d="scan'208";a="225629200" X-IP-Direction: IN Received: from 1cust105.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.105]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Jun 2009 11:59:47 +0100 Message-ID: <003601c9f3e9$232ab220$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <200906181748.NAA24813@adminfs.snmp.com><4A3A7FA1.1020903@netconfcentral.com><20090618203503.GB12298@elstar.local><4A3AABF0.40200@netconfcentral.com> <20090619061242.GA12665@elstar.local> <002401c9f0d8$e0007ba0$0601a8c0@allison> <4A3B9F86.2040806@netconfcentral.com> Date: Tue, 23 Jun 2009 10:57:37 +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: Re: [netmod] yang error codes 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: Tue, 23 Jun 2009 10:59:35 -0000 ---- Original Message ----- From: "Andy Bierman" To: "tom.petch" Sent: Friday, June 19, 2009 4:24 PM > tom.petch wrote: > > ---- Original Message ----- > > From: "Juergen Schoenwaelder" > > Sent: Friday, June 19, 2009 8:12 AM > > > >> On Thu, Jun 18, 2009 at 11:04:48PM +0200, Andy Bierman wrote: > >> > >>> Actually, this is exactly what the YANG spec (sec. 13) > >>> says to do with the field for > >>> the 'instance-required' and 'missing-choice' errors. > >>> So, really. > >> I found this text: > >> > >> Error-path: Path to the element with the require-instance > >> statement > >> > >> Error-path: Path to the element with the missing choice. > >> > >> The question was what the root for this path is. I do not find this > >> spelled out anywhere - can you help me find it? > > > > Perhaps time to resurrect the thread that died out at the start of the month. > > > > Just to recap, XPath defines a root node which is the parent of the document > > element; that is what is, and I believe we should stick with it. So the > > question is what is the document element? > > > > This has to be defined whereever we use XPath since what is a 'document' is not > > obvious. 'must' and 'when' covers this, other places do not. Needs fixing. I > > do not have strong views about what the document element should be; I do have > > strong views that whereever we use XPath, it needs defining. > > > > was covered by Martin 28th May 2009. > > > > You cannot equate YANG and NETCONF for all usage of XPath. > YANG ignores the RPC layer in NETCONF, but > cannot do the same. > > Obviously, starting the error-path at for > ignores the top-level element, so any problems there > would not be reportable. That is unacceptable. > The error-path needs to identify any error node, > whether it is in the input PDU or the database. > It is trivial for an application to tell the difference, > because nobody is ever allowed to define a YANG data node > named in the NETCONF namespace. So, /nc:rpc cannot > possibly be confused with a data node. > > Starting at any other point, such as the method name, > would introduce ambiguity. Starting with /rpc is the > only deterministic solution possible, without introducing > new error fields, which means a new protocol version. Andy Um. I agree that we do not have to make the XPath context the same for YANG and Netconf; but making them different may confuse, which is how I understand your suggestion. For an absolute XPath expression for YANG, we currently have /validate/source/... whereas for Netconf's error-path you are suggesting /rpc/validate/source/.. I agree with you on the need for in the error-path; I would see it simpler to be consistent and to add that to YANG (which is what you suggested last December, as I recall). More generally, I think that rfc4741bis needs to spell out the XPath context in more detail, as has been done in YANG for 'must'. Tom Petch > > Tom Petch > > > >> /js > > Andy From andy@netconfcentral.com Tue Jun 23 06:06: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 A662328C2F9 for ; Tue, 23 Jun 2009 06:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 FyVVksXHm+cG for ; Tue, 23 Jun 2009 06:06:39 -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 B102128C2DD for ; Tue, 23 Jun 2009 06:06:39 -0700 (PDT) Received: (qmail 65095 invoked from network); 23 Jun 2009 13:06:54 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 23 Jun 2009 13:06:53 -0000 X-YMail-OSG: cgUUjPcVM1nZiX.Fgm2tnUy3LjTT4p0r7Pwni5ZwZ0HAKStGp_HwHrzm0gOyZgcgap0gXxJfNYdQPfJYxjCLjHA4tURRK3YpRgIIRbyfwjQGQltvMNarHzIsf9J7FOBgCBOcnYz2RcfikW8EdUDxUL_Wp5iKisMhfHq1n.L9YzB9OyoPC0UvF9t1ljw97BG78iVfnZmbDQrRjEOIfEPTxEtlIps5hGtj031QA.y.wtNfOql6jt1peCOOiX5xj3trTVb0ug.8krks9cEo_UE7YIPQLPydQxHw5XDPbOGvoeOgUIcpBWHh0OcK0Sd7eT2IPFz_mTK_.h1DjjfVlILTSQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A40D340.6040503@netconfcentral.com> Date: Tue, 23 Jun 2009 06:06:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "tom.petch" References: <200906181748.NAA24813@adminfs.snmp.com><4A3A7FA1.1020903@netconfcentral.com><20090618203503.GB12298@elstar.local><4A3AABF0.40200@netconfcentral.com> <20090619061242.GA12665@elstar.local> <002401c9f0d8$e0007ba0$0601a8c0@allison> <4A3B9F86.2040806@netconfcentral.com> <003601c9f3e9$232ab220$0601a8c0@allison> In-Reply-To: <003601c9f3e9$232ab220$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang error codes X-BeenThere: netmod@ietf.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, 23 Jun 2009 13:06:40 -0000 tom.petch wrote: > ---- Original Message ----- > From: "Andy Bierman" > To: "tom.petch" > Sent: Friday, June 19, 2009 4:24 PM > > >> tom.petch wrote: >>> ---- Original Message ----- >>> From: "Juergen Schoenwaelder" >>> Sent: Friday, June 19, 2009 8:12 AM >>> >>>> On Thu, Jun 18, 2009 at 11:04:48PM +0200, Andy Bierman wrote: >>>> >>>>> Actually, this is exactly what the YANG spec (sec. 13) >>>>> says to do with the field for >>>>> the 'instance-required' and 'missing-choice' errors. >>>>> So, really. >>>> I found this text: >>>> >>>> Error-path: Path to the element with the require-instance >>>> statement >>>> >>>> Error-path: Path to the element with the missing choice. >>>> >>>> The question was what the root for this path is. I do not find this >>>> spelled out anywhere - can you help me find it? >>> Perhaps time to resurrect the thread that died out at the start of the > month. >>> Just to recap, XPath defines a root node which is the parent of the document >>> element; that is what is, and I believe we should stick with it. So the >>> question is what is the document element? >>> >>> This has to be defined whereever we use XPath since what is a 'document' is > not >>> obvious. 'must' and 'when' covers this, other places do not. Needs fixing. > I >>> do not have strong views about what the document element should be; I do > have >>> strong views that whereever we use XPath, it needs defining. >>> >>> was covered by Martin 28th May 2009. >>> >> You cannot equate YANG and NETCONF for all usage of XPath. >> YANG ignores the RPC layer in NETCONF, but >> cannot do the same. >> >> Obviously, starting the error-path at for >> ignores the top-level element, so any problems there >> would not be reportable. That is unacceptable. >> The error-path needs to identify any error node, >> whether it is in the input PDU or the database. >> It is trivial for an application to tell the difference, >> because nobody is ever allowed to define a YANG data node >> named in the NETCONF namespace. So, /nc:rpc cannot >> possibly be confused with a data node. >> >> Starting at any other point, such as the method name, >> would introduce ambiguity. Starting with /rpc is the >> only deterministic solution possible, without introducing >> new error fields, which means a new protocol version. > > Andy > > Um. > > I agree that we do not have to make the XPath context the same for YANG and > Netconf; but making them different may confuse, which is how I understand your > suggestion. > > For an absolute XPath expression for YANG, we currently have > /validate/source/... > whereas for Netconf's error-path you are suggesting > /rpc/validate/source/.. > no I am not, unless it is wrong rumming If the error node you are reporting in the is directly contained in the , then the error-path should start with /rpc. If not (e.g., a must-violation), then start with the YANG top-level element, since /foo/bar/broken was never in the request PDU. > I agree with you on the need for in the error-path; I would see it simpler > to be consistent and to add that to YANG (which is what you suggested last > December, as I recall). > > More generally, I think that rfc4741bis needs to spell out the XPath context in > more detail, as has been done in YANG for 'must'. > I think we are trying to agree on those details right now. As I said before, if the error-path starts with /nc:rpc, there is no ambiguity, so what is the problem? I don't think there is one. If you don't want to use the optional , then don't use it, but don't tell others that a well-formed absolute XPath expression is wrong. It's valid XPath, so the manager can figure it out. > Tom Petch > >>> Tom Petch >>> >>>> /js >> Andy > > Andy From wes@hardakers.net Tue Jun 23 10:55: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 821D928C39A for ; Tue, 23 Jun 2009 10:55:48 -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 K4dvPEkCTDiZ for ; Tue, 23 Jun 2009 10:55:47 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 94E8928C306 for ; Tue, 23 Jun 2009 10:55:47 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 719F69805E; Tue, 23 Jun 2009 10:56:02 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D5F5D399B17; Tue, 23 Jun 2009 10:56:00 -0700 (PDT) From: Wes Hardaker To: Martin Bjorklund Organization: Sparta References: <20090524.160238.199634663.mbj@tail-f.com> <20090623.102503.97344494.mbj@tail-f.com> Date: Tue, 23 Jun 2009 10:56:00 -0700 In-Reply-To: <20090623.102503.97344494.mbj@tail-f.com> (Martin Bjorklund's message of "Tue, 23 Jun 2009 10:25:03 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] comments on netmod-yang-05 X-BeenThere: netmod@ietf.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, 23 Jun 2009 17:55:48 -0000 >>>>> On Tue, 23 Jun 2009 10:25:03 +0200 (CEST), Martin Bjorklund said: MB> If the double quoted string contains space or tab characters before MB> a line break, this trailing whitespace is stripped from the string. MB> Would that work? That looks good. I didn't check the rest of the text. MB> Ok. I will state that the argument is a string. That leaves MB> us flexibility for the future. Agreed; I think that's the right choice (though it does nuke the possibility of >, == and < comparisons which might be helpful). Didn't yang module version numbers end up being a float after a discussion at the last IETF ? If so, maybe syncing with that would make the most sense. MB> The text says: MB> Thus an implementation is free to sort the entries in the most MB> appropriate order. MB> What should we write to make it more clear? How about: Thus an implementation is free to sort the entries in the most appropriate order. A netconf client and server should not expect their preferred ordering to be kept consistent by the other side. -- \ Wes Hardaker http://pontifications.hardakers.net / \_____ "In the bathtub of history the truth is harder to hold than ________/ \_______ the soap, and much more difficult to find." _______/ \_________ -- Terry Pratchett ______________/ \__________________/ From cfinss@dial.pipex.com Tue Jun 23 11:08: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 81C0C28C404 for ; Tue, 23 Jun 2009 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 IuG4sayyd7LH for ; Tue, 23 Jun 2009 11:08:29 -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 477DD28C401 for ; Tue, 23 Jun 2009 11:08:29 -0700 (PDT) X-Trace: 115622837/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.146/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.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: AjQFAFe3QEo+vGmS/2dsb2JhbABEgmc8FYtXw1AJgjWBTAU X-IronPort-AV: E=Sophos;i="4.42,276,1243810800"; d="scan'208";a="115622837" X-IP-Direction: IN Received: from 1cust146.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.146]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Jun 2009 19:08:18 +0100 Message-ID: <000401c9f425$001f7a40$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <004101c9e46e$0e372400$0601a8c0@allison><1244101182.6524.27.camel@missotis><003a01c9e5c3$cd0c7960$0601a8c0@allison> <20090622.144308.153231311.mbj@tail-f.com> Date: Tue, 23 Jun 2009 15:01:48 +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] definitions 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: Tue, 23 Jun 2009 18:08:30 -0000 ---- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Monday, June 22, 2009 2:43 PM Subject: Re: [netmod] definitions > Hi, > > "tom.petch" wrote: > > ----- Original Message ----- > > From: "Ladislav Lhotka" > > To: "tom.petch" > > Cc: "Martin Bjorklund" ; > > Sent: Thursday, June 04, 2009 9:39 AM > > Subject: Re: [netmod] definitions > > > > > > > tom.petch píše v St 03. 06. 2009 v 19:06 +0200: > > > > > > The "import" statement makes identifiers from the namespace of the > > > > > > imported module available in the importing module. In particular, the > > > > > > importing module may > > > > > > > > > > > > o use groupings and typedefs defined at the top level of the imported > > > > > > module; > > > > > > > > > > > > o refer to features defined in the imported module; > > > > > > > > > > > > o use any data node of the imported module as the target node for the > > > > > > "augment" statement. > > > > > > > > > > > > Unlike "include", the "import" statement doesn't contribute the data > > > > > > tree from the imported to the importing module. > > > > > > > > > > I'm not sure this text is better than the current text. Does anyone > > > > > else have an opinion? > > > > > > > > Yes; both might be clearer:-( The bulleted list is an improvement, but I do > > not > > > > see "identifiers" as an improvement; it is more than identifiers, it is the > > > > identity, the concept that is being identified. Definitions is nearer the > > mark > > > > but still, for me, understates what is on offer. > > > > > > Yes, but it is important to stress that the schema tree is not imported. > > > Can you suggest another formulation? > > > > I would go for 'objects' or 'entities' (or 'items') both of which have > > technical > > meanings in some contexts, but also can safely be used more generically. > > > > And add that phrase, giving > > > > The "import" statement makes objects, but not the schema tree, from the > > namespace of the imported module available in the importing module. In > > particular, the importing module may:- > > I don't think "object" is a good word; it is not obvious that e.g. a > feature is an "object". Also, I don't think it is accurate to say > that the schema tree is not available, since it is legal to refer to > nodes in the schema tree in e.g. augment. So I suggest the following > compromise: > > 7.1.5. The import Statement > > The "import" statement makes definitions from one module available > inside another module or submodule. The argument is the name of the > module to import, and the statement is followed by a block of > substatements that holds detailed import information. When a module > is imported, the importing module may: > > o use any grouping and typedef defined at the top-level in the > imported module or its submodules > > o use any extension, feature, and identity defined in the imported > module or its submodules > > o use any node in the imported module's schema tree in augment, > must, path, and when statements > ok, good enough Tom Petch > > /martin > From Emmanuel.Nataf@loria.fr Wed Jun 24 05: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 E1A733A6F10 for ; Wed, 24 Jun 2009 05:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 nwa3C8yn6-bu for ; Wed, 24 Jun 2009 05:55:00 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id B41C33A6C8C for ; Wed, 24 Jun 2009 05:54:59 -0700 (PDT) From: Emmanuel.Nataf@loria.fr X-IronPort-AV: E=Sophos;i="4.42,283,1243807200"; d="scan'208,217";a="31851870" Received: from leod.loria.fr ([152.81.15.93]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 24 Jun 2009 14:54:40 +0200 Message-Id: <15DE4328-5173-4F63-ADF8-BD6E5AC3969F@loria.fr> To: netmod@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-57--894575440 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 14:54:40 +0200 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 24 Jun 2009 06:11:41 -0700 Subject: [netmod] Release of jYang available for download X-BeenThere: netmod@ietf.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, 24 Jun 2009 13:10:33 -0000 --Apple-Mail-57--894575440 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear "Yanger", Over the last months we have been working on the alignment of our Yang parser (jYang implemented in Java) to the lattest evolutions of the draft. The parser which does both syntax and semantics check can be freely (under a GPL license) downloaded from : http://jyang.gforge.inria.fr The development of this free environment is supported by the EMANICS European Network of Excellence. The tool is currently being integrated in the Ensuite Netconf framework (ensuite.sf.org) Comments and feeback are welcome! Best Regards Emmanuel Nataf & Olivier Festor The MADYNES Researach team @ INRIA & Nancy University --Apple-Mail-57--894575440 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear "Yanger",

Over the last months we have been working on the alignment of our Yang parser (jYang implemented in Java) to the lattest evolutions of the draft. The parser which does both syntax and semantics check can be freely (under a GPL license) downloaded from :

http://jyang.gforge.inria.fr

The development of this free environment is supported by the EMANICS European Network of Excellence. The tool is currently being integrated in the Ensuite Netconf framework (ensuite.sf.org)

Comments and feeback are welcome!


Best Regards

Emmanuel Nataf & Olivier Festor
The MADYNES Researach team @ INRIA & Nancy University --Apple-Mail-57--894575440-- From root@core3.amsl.com Thu Jun 25 13:00:02 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 271263A6ACF; Thu, 25 Jun 2009 13:00: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: <20090625200002.271263A6ACF@core3.amsl.com> Date: Thu, 25 Jun 2009 13:00:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-06.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, 25 Jun 2009 20:00:02 -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-06.txt Pages : 173 Date : 2009-06-25 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-25125724.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Thu Jun 25 13:14: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 2C67D3A69B3 for ; Thu, 25 Jun 2009 13:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.183, 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 pQnevosRnMca for ; Thu, 25 Jun 2009 13:14: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 6515B3A67E1 for ; Thu, 25 Jun 2009 13:14:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 23C2A616004 for ; Thu, 25 Jun 2009 22:12:16 +0200 (CEST) Date: Thu, 25 Jun 2009 22:12:12 +0200 (CEST) Message-Id: <20090625.221212.156013903.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20090625200002.271263A6ACF@core3.amsl.com> References: <20090625200002.271263A6ACF@core3.amsl.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 Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-06.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, 25 Jun 2009 20:14:30 -0000 Hi, I have submitted a new version, which hopefully addresses the WGLC comments. The major changes are: The XPath context has been defined for the statements "must", "when", "augement", "path" and for type "instance-identifier". Section 6.4.1. describes the common part of the XPath context. The description of leafref has been clarified. "require-instance" has been removed for leafref. /martin From cfinss@dial.pipex.com Fri Jun 26 07:55: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 36F163A68D4 for ; Fri, 26 Jun 2009 07:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=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 vfEgRbp5Gm-e for ; Fri, 26 Jun 2009 07:55:36 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 3829C3A6882 for ; Fri, 26 Jun 2009 07:55:36 -0700 (PDT) X-Trace: 172623664/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.161/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.161 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: AsQEAJt+REo+vGmh/2dsb2JhbACDK1SLXcBCCYQEBQ X-IronPort-AV: E=Sophos;i="4.42,297,1243810800"; d="scan'208";a="172623664" X-IP-Direction: IN Received: from 1cust161.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.161]) by smtp.pipex.tiscali.co.uk with SMTP; 26 Jun 2009 15:55:17 +0100 Message-ID: <003d01c9f665$85f00800$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" , References: <000401c9f4aa$128e40a0$0601a8c0@allison><20090624.204028.254085652.mbj@tail-f.com><001c01c9f5c8$2856a0c0$0601a8c0@allison> <20090625.221933.155398855.mbj@tail-f.com> Date: Fri, 26 Jun 2009 15:33:23 +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 Subject: [netmod] yang-06 XPath issues 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, 26 Jun 2009 14:55:37 -0000 I like the changes in the coverage of XPath in -06, I find this much clearer and I think that the coverage of unprefixed names most decorous. I think though that there is a glitch in "augment" ' o The context node is the target node in the schema tree.' seems circular since the whole point of the XPath is to define an augment's target node. I think that the two cases need splitting. "augment" at the top level uses an absolute XPath expression so the initial context node is irrelevant (as far as I can know). We probably should say what the context node is but I suspect it has to be the first ancestor schema node except that there isn't one and saying that might make people wonder why does it matter:-( "augment" as a substatement of "uses" (not really 'in' as the text has it) has as context node for the relative XPath expression the grouping which is the argument of the "uses". Lada did say last month 'The context is quite clear for "augment", but the document is the corresponding schema tree, unlike the other uses of XPath.' so he may have a better idea of how to word it. For this, and for the other uses of XPath, we should have examples. The discussions about this over several months have shown uncertainty, particularly about just what an absolute XPath expression looks like, what comes after the first solidus, but also about when predicates and functions are and are not allowed and about the names without prefixes. I am thinking of a relative and an absolute example with predicates and functions for each of the five cases, where those options are allowed ie 9 examples in all. Tom Petch From lhotka@cesnet.cz Mon Jun 29 00:30: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 A208D3A67FA for ; Mon, 29 Jun 2009 00:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=0.580, 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 vmjiKZEB6iX4 for ; Mon, 29 Jun 2009 00:30:05 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C092E3A67B2 for ; Mon, 29 Jun 2009 00:30:02 -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 1F78FD800CC for ; Mon, 29 Jun 2009 09:30:22 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <003d01c9f665$85f00800$0601a8c0@allison> References: <000401c9f4aa$128e40a0$0601a8c0@allison> <20090624.204028.254085652.mbj@tail-f.com> <001c01c9f5c8$2856a0c0$0601a8c0@allison> <20090625.221933.155398855.mbj@tail-f.com> <003d01c9f665$85f00800$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Mon, 29 Jun 2009 09:30:21 +0200 Message-Id: <1246260621.6394.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 07:30:06 -0000 tom.petch píše v Pá 26. 06. 2009 v 15:33 +0200: > I like the changes in the coverage of XPath in -06, I find this much clearer and > I think that the coverage of unprefixed names most decorous. > > I think though that there is a glitch in "augment" > > ' o The context node is the target node in the schema tree.' > > seems circular since the whole point of the XPath is to define an augment's > target node. > > I think that the two cases need splitting. Yes, and IMO two different keywords are needed, otherwise the specification will be quite confusing. It has been already agreed to change the keyword for "augment under uses" but the problem apparently is that no suitable alternative has been found yet. > > "augment" at the top level uses an absolute XPath expression so the initial > context node is irrelevant (as far as I can know). We probably should say what > the context node is but I suspect it has to be the first ancestor schema node > except that there isn't one and saying that might make people wonder why does it > matter:-( Perhaps the context node could be the root node (in XPath sense)? > > "augment" as a substatement of "uses" (not really 'in' as the text has it) has > as context node for the relative XPath expression the grouping which is the > argument of the "uses". I think the context node should rather be the data node under which 'uses' appears, so that the namespace of the nodes appearing in the XPath expression is fixed - data nodes defined in a grouping get a namespace only after the grouping is expanded. > > Lada did say last month > 'The context is quite clear for "augment", but the document is the > corresponding schema tree, unlike the other uses of XPath.' > so he may have a better idea of how to word it. I meant that in the case of 'augment' (both variants) there was no doubt about the document the expression applies to. > > For this, and for the other uses of XPath, we should have examples. The > discussions about this over several months have shown uncertainty, particularly > about just what an absolute XPath expression looks like, what comes after the > first solidus, but also about when predicates and functions are and are not > allowed and about the names without prefixes. I am thinking of a relative and > an absolute example with predicates and functions for each of the five cases, > where those options are allowed ie 9 examples in all. This would help but the source for the uncertainty will remain, which is the sheer number of different ways and contexts in which XPath or quasi-XPath is used in YANG. I am not aware of any other XML-related technology that stretches poor XPath 1.0 this far. Lada > > Tom Petch > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jun 29 01:15: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 3DF8128C19D for ; Mon, 29 Jun 2009 01:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmorpHSD0Y+I for ; Mon, 29 Jun 2009 01:15:36 -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 6357428C184 for ; Mon, 29 Jun 2009 01:15:36 -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 2C04B616011; Mon, 29 Jun 2009 10:15:56 +0200 (CEST) Date: Mon, 29 Jun 2009 10:15:55 +0200 (CEST) Message-Id: <20090629.101555.99489591.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246260621.6394.41.camel@missotis> References: <20090625.221933.155398855.mbj@tail-f.com> <003d01c9f665$85f00800$0601a8c0@allison> <1246260621.6394.41.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] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 08:15:37 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gdG9tLnBldGNoIHDD rcWhZSB2IFDDoSAyNi4gMDYuIDIwMDkgdiAxNTozMyArMDIwMDoNCj4gPiAiYXVnbWVudCIgYXQg dGhlIHRvcCBsZXZlbCB1c2VzIGFuIGFic29sdXRlIFhQYXRoIGV4cHJlc3Npb24gc28gdGhlIGlu aXRpYWwNCj4gPiBjb250ZXh0IG5vZGUgaXMgaXJyZWxldmFudCAoYXMgZmFyIGFzIEkgY2FuIGtu b3cpLiAgV2UgcHJvYmFibHkgc2hvdWxkIHNheQ0KPiA+IHdoYXQNCj4gPiB0aGUgY29udGV4dCBu b2RlIGlzIGJ1dCBJIHN1c3BlY3QgaXQgaGFzIHRvIGJlIHRoZSBmaXJzdCBhbmNlc3RvciBzY2hl bWEgbm9kZQ0KPiA+IGV4Y2VwdCB0aGF0IHRoZXJlIGlzbid0IG9uZSBhbmQgc2F5aW5nIHRoYXQg bWlnaHQgbWFrZSBwZW9wbGUgd29uZGVyIHdoeSBkb2VzDQo+ID4gaXQNCj4gPiBtYXR0ZXI6LSgN Cj4gDQo+IFBlcmhhcHMgdGhlIGNvbnRleHQgbm9kZSBjb3VsZCBiZSB0aGUgcm9vdCBub2RlIChp biBYUGF0aCBzZW5zZSk/DQoNCk9rLg0KDQo+ID4gImF1Z21lbnQiIGFzIGEgc3Vic3RhdGVtZW50 IG9mICJ1c2VzIiAobm90IHJlYWxseSAnaW4nIGFzIHRoZSB0ZXh0IGhhcyBpdCkNCj4gPiBoYXMN Cj4gPiBhcyBjb250ZXh0IG5vZGUgZm9yIHRoZSByZWxhdGl2ZSBYUGF0aCBleHByZXNzaW9uIHRo ZSBncm91cGluZyB3aGljaCBpcyB0aGUNCj4gPiBhcmd1bWVudCBvZiB0aGUgInVzZXMiLg0KPiAN Cj4gSSB0aGluayB0aGUgY29udGV4dCBub2RlIHNob3VsZCByYXRoZXIgYmUgdGhlIGRhdGEgbm9k ZSB1bmRlciB3aGljaA0KPiAndXNlcycgYXBwZWFycw0KDQpZZXMuDQoNClNvIGhvdyBhYm91dCB0 aGlzOg0KDQogICBUaGUgImF1Z21lbnQiIFhQYXRoIGV4cHJlc3Npb24gaXMgY29uY2VwdHVhbGx5 IGV2YWx1YXRlZCBpbiB0aGUNCiAgIGZvbGxvd2luZyBjb250ZXh0LCBpbiBhZGRpdGlvbiB0byB0 aGUgZGVmaW5pdGlvbiBpbiBTZWN0aW9uIDYuNC4xOg0KDQogICBvICBJZiB0aGUgImF1Z21lbnQi IHN0YXRlbWVudCBpcyBvbiB0aGUgdG9wLWxldmVsLCB0aGUgY29udGV4dCBub2RlDQogICAgICBp cyB0aGUgWFBhdGggcm9vdCBub2RlLiAgVGhlIFhQYXRoIHJvb3Qgbm9kZSBoYXMgYWxsIHRvcC1s ZXZlbA0KICAgICAgc2NoZW1hIG5vZGVzIGluIGFsbCBtb2R1bGVzIGFzIGNoaWxkcmVuLg0KDQog ICBvICBJZiB0aGUgImF1Z21lbnQiIHN0YXRlbWVudCBpcyBhIHN1YnN0YXRlbWVudCB0byAidXNl cyIsIHRoZQ0KICAgICAgY29udGV4dCBub2RlIGlzIHRoZSBub2RlIGluIHRoZSBkYXRhIHRyZWUg Zm9yIHdoaWNoIHRoZSAidXNlcyINCiAgICAgIHN0YXRlbWVudCBpcyBkZWZpbmVkLg0KDQoNCi9t YXJ0aW4NCg== From lhotka@cesnet.cz Mon Jun 29 01:46: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 D39B428C1B2 for ; Mon, 29 Jun 2009 01:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.218 X-Spam-Level: X-Spam-Status: No, score=0.218 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mekg4T0nDup for ; Mon, 29 Jun 2009 01:46:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1101728C1B1 for ; Mon, 29 Jun 2009 01:46: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 9D1E7D80095; Mon, 29 Jun 2009 10:46:54 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090629.101555.99489591.mbj@tail-f.com> References: <20090625.221933.155398855.mbj@tail-f.com> <003d01c9f665$85f00800$0601a8c0@allison> <1246260621.6394.41.camel@missotis> <20090629.101555.99489591.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 29 Jun 2009 10:46:53 +0200 Message-Id: <1246265213.6394.63.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 08:46:35 -0000 Martin Bjorklund píše v Po 29. 06. 2009 v 10:15 +0200: > > So how about this: > > The "augment" XPath expression is conceptually evaluated in the > following context, in addition to the definition in Section 6.4.1: > > o If the "augment" statement is on the top-level, the context node > is the XPath root node. The XPath root node has all top-level > schema nodes in all modules as children. The document should also be specified: o If the "augment" statement is on the top-level, the context node is the XPath root node of the overall schema tree, which is the union of schema trees of the local module and all imported modules. The XPath root node has all top-level schema nodes in all modules as children. > > o If the "augment" statement is a substatement to "uses", the > context node is the node in the data tree for which the "uses" > statement is defined. But wait, the expressions in 'augment' may contain choice nodes, so it is the schema tree and not the data tree that the expression addresses. BTW, the nodes in both the schema and data tree are in the same namespace, right? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jun 29 01:53: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 23ED828C192 for ; Mon, 29 Jun 2009 01:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 OAdV52p0uwmX for ; Mon, 29 Jun 2009 01:53: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 612EE28C184 for ; Mon, 29 Jun 2009 01:53:13 -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 42C3C616011; Mon, 29 Jun 2009 10:53:33 +0200 (CEST) Date: Mon, 29 Jun 2009 10:53:33 +0200 (CEST) Message-Id: <20090629.105333.236799433.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246265213.6394.63.camel@missotis> References: <1246260621.6394.41.camel@missotis> <20090629.101555.99489591.mbj@tail-f.com> <1246265213.6394.63.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] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 08:53:15 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAyOS4gMDYuIDIwMDkgdiAxMDoxNSArMDIwMDoNCj4gPiANCj4gPiBT byBob3cgYWJvdXQgdGhpczoNCj4gPiANCj4gPiAgICBUaGUgImF1Z21lbnQiIFhQYXRoIGV4cHJl c3Npb24gaXMgY29uY2VwdHVhbGx5IGV2YWx1YXRlZCBpbiB0aGUNCj4gPiAgICBmb2xsb3dpbmcg Y29udGV4dCwgaW4gYWRkaXRpb24gdG8gdGhlIGRlZmluaXRpb24gaW4gU2VjdGlvbiA2LjQuMToN Cj4gPiANCj4gPiAgICBvICBJZiB0aGUgImF1Z21lbnQiIHN0YXRlbWVudCBpcyBvbiB0aGUgdG9w LWxldmVsLCB0aGUgY29udGV4dCBub2RlDQo+ID4gICAgICAgaXMgdGhlIFhQYXRoIHJvb3Qgbm9k ZS4gIFRoZSBYUGF0aCByb290IG5vZGUgaGFzIGFsbCB0b3AtbGV2ZWwNCj4gPiAgICAgICBzY2hl bWEgbm9kZXMgaW4gYWxsIG1vZHVsZXMgYXMgY2hpbGRyZW4uDQo+IA0KPiBUaGUgZG9jdW1lbnQg c2hvdWxkIGFsc28gYmUgc3BlY2lmaWVkOg0KPiANCj4gICAgbyAgSWYgdGhlICJhdWdtZW50IiBz dGF0ZW1lbnQgaXMgb24gdGhlIHRvcC1sZXZlbCwgdGhlIGNvbnRleHQgbm9kZQ0KPiAgICAgICBp cyB0aGUgWFBhdGggcm9vdCBub2RlIG9mIHRoZSBvdmVyYWxsIHNjaGVtYSB0cmVlLCB3aGljaCBp cyB0aGUgDQo+ICAgICAgIHVuaW9uIG9mIHNjaGVtYSB0cmVlcyBvZiB0aGUgbG9jYWwgbW9kdWxl IGFuZCBhbGwgaW1wb3J0ZWQgDQo+ICAgICAgIG1vZHVsZXMuIFRoZSBYUGF0aCByb290IG5vZGUg aGFzIGFsbCB0b3AtbGV2ZWwgc2NoZW1hIG5vZGVzIGluIA0KPiAgICAgICBhbGwgbW9kdWxlcyBh cyBjaGlsZHJlbi4NCg0KT2suDQoNCj4gDQo+ID4gDQo+ID4gICAgbyAgSWYgdGhlICJhdWdtZW50 IiBzdGF0ZW1lbnQgaXMgYSBzdWJzdGF0ZW1lbnQgdG8gInVzZXMiLCB0aGUNCj4gPiAgICAgICBj b250ZXh0IG5vZGUgaXMgdGhlIG5vZGUgaW4gdGhlIGRhdGEgdHJlZSBmb3Igd2hpY2ggdGhlICJ1 c2VzIg0KPiA+ICAgICAgIHN0YXRlbWVudCBpcyBkZWZpbmVkLg0KPiANCj4gQnV0IHdhaXQsIHRo ZSBleHByZXNzaW9ucyBpbiAnYXVnbWVudCcgbWF5IGNvbnRhaW4gY2hvaWNlIG5vZGVzLCBzbyBp dA0KPiBpcyB0aGUgc2NoZW1hIHRyZWUgYW5kIG5vdCB0aGUgZGF0YSB0cmVlIHRoYXQgdGhlIGV4 cHJlc3Npb24gYWRkcmVzc2VzLg0KDQpZZXMsIGNvcHkmcGFzdGUgZXJyb3IuICBzL2RhdGEgdHJl ZS9zY2hlbWEgdHJlZS8gIGRvbmUuDQoNCj4gQlRXLCB0aGUgbm9kZXMgaW4gYm90aCB0aGUgc2No ZW1hIGFuZCBkYXRhIHRyZWUgYXJlIGluIHRoZSBzYW1lDQo+IG5hbWVzcGFjZSwgcmlnaHQ/DQoN Clllcy4NCg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Mon Jun 29 04:38: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 01A603A6878 for ; Mon, 29 Jun 2009 04:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_40=-0.185, 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 Arq4k6qQ9peR for ; Mon, 29 Jun 2009 04:38:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3FEC63A6945 for ; Mon, 29 Jun 2009 04:38:51 -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 D2896D800C0 for ; Mon, 29 Jun 2009 13:39:10 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Mon, 29 Jun 2009 13:39:11 +0200 Message-Id: <1246275551.6394.90.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] leafref questions X-BeenThere: netmod@ietf.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, 29 Jun 2009 11:38:52 -0000 Hi, three questions regarding 'leafref': 1. Can leafref point to another leafref? If so, circular references should probably be forbidden. 2. Does a default specified for the target leaf apply to the leafref pointing to that target? 3. Is it OK to specify a default for the leafref itself? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jun 29 05:01: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 916393A6893 for ; Mon, 29 Jun 2009 05:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 SeNsif-2lGV6 for ; Mon, 29 Jun 2009 05:01:48 -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 2F5FE28C1E3 for ; Mon, 29 Jun 2009 05:01:48 -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 7E95F616011; Mon, 29 Jun 2009 14:02:07 +0200 (CEST) Date: Mon, 29 Jun 2009 14:02:07 +0200 (CEST) Message-Id: <20090629.140207.135166300.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246275551.6394.90.camel@missotis> References: <1246275551.6394.90.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] leafref questions X-BeenThere: netmod@ietf.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, 29 Jun 2009 12:01:50 -0000 Ladislav Lhotka wrote: > Hi, > > three questions regarding 'leafref': > > 1. Can leafref point to another leafref? If so, circular references > should probably be forbidden. Yes. There MUST NOT be any circular chains of leafrefs. > 2. Does a default specified for the target leaf apply to the leafref > pointing to that target? > > 3. Is it OK to specify a default for the leafref itself? We discussed this a bit before... I think it would be ok to a CLR that says that a leafref cannot have a default value. IIRC this was also Andy's suggestion at the time. /martin From andy@netconfcentral.com Mon Jun 29 05:13: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 E356F3A6910 for ; Mon, 29 Jun 2009 05:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, 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 rBnniujuDeEu for ; Mon, 29 Jun 2009 05:13:23 -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 24EB43A6907 for ; Mon, 29 Jun 2009 05:13:23 -0700 (PDT) Received: (qmail 91141 invoked from network); 29 Jun 2009 12:13:39 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 29 Jun 2009 12:13:38 -0000 X-YMail-OSG: XfHJGgAVM1mhHeqsIHHgeNkucUULst4h_GwuH_kMdFZOVi8NCKBGBT6j4peLxxgg2Bv5wSCxOMlGEXvyLNOGZtL049auz2zrgJGE32Braq2OLGu_v9WsJS3C2hnt5OlQj.gdTvquECxDIzDM.jS_MO2M5lYK8CP37lvahXvHgqP.L0gBzWM.y2G_dkSVByNG5uczPeBmnf7XwqkTsnIB4itoygJv9yjdne6dQrKFfr_kYaNHjo8zazKaTC1ioIwrrudj1hm6fpPB4fmpliGR_4kZ7asRLHLzS6BJOvGL_IzOKP4IyQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A48AFE7.6000401@netconfcentral.com> Date: Mon, 29 Jun 2009 05:13:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090625.221933.155398855.mbj@tail-f.com> <003d01c9f665$85f00800$0601a8c0@allison> <1246260621.6394.41.camel@missotis> <20090629.101555.99489591.mbj@tail-f.com> In-Reply-To: <20090629.101555.99489591.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 12:13:24 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> tom.petch píše v Pá 26. 06. 2009 v 15:33 +0200: >>> "augment" at the top level uses an absolute XPath expression so the initial >>> context node is irrelevant (as far as I can know). We probably should say >>> what >>> the context node is but I suspect it has to be the first ancestor schema node >>> except that there isn't one and saying that might make people wonder why does >>> it >>> matter:-( >> Perhaps the context node could be the root node (in XPath sense)? > > Ok. > >>> "augment" as a substatement of "uses" (not really 'in' as the text has it) >>> has >>> as context node for the relative XPath expression the grouping which is the >>> argument of the "uses". >> I think the context node should rather be the data node under which >> 'uses' appears > > Yes. > > So how about this: > > The "augment" XPath expression is conceptually evaluated in the > following context, in addition to the definition in Section 6.4.1: > > o If the "augment" statement is on the top-level, the context node > is the XPath root node. The XPath root node has all top-level > schema nodes in all modules as children. > > o If the "augment" statement is a substatement to "uses", the > context node is the node in the data tree for which the "uses" > statement is defined. > what if the uses-stmt is itself within a grouping? > > /martin Andy From lhotka@cesnet.cz Mon Jun 29 05:16: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 182E33A6993 for ; Mon, 29 Jun 2009 05:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=0.605, 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 sJGlL2+JuWln for ; Mon, 29 Jun 2009 05:16:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 424213A680F for ; Mon, 29 Jun 2009 05:16:07 -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 D8333D800C0; Mon, 29 Jun 2009 14:16:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090629.140207.135166300.mbj@tail-f.com> References: <1246275551.6394.90.camel@missotis> <20090629.140207.135166300.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 29 Jun 2009 14:16:28 +0200 Message-Id: <1246277788.6394.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] leafref questions X-BeenThere: netmod@ietf.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, 29 Jun 2009 12:16:09 -0000 Martin Bjorklund píše v Po 29. 06. 2009 v 14:02 +0200: > Ladislav Lhotka wrote: > > Hi, > > > > three questions regarding 'leafref': > > > > 1. Can leafref point to another leafref? If so, circular references > > should probably be forbidden. > > Yes. There MUST NOT be any circular chains of leafrefs. > > > 2. Does a default specified for the target leaf apply to the leafref > > pointing to that target? > > > > 3. Is it OK to specify a default for the leafref itself? > > We discussed this a bit before... I think it would be ok to a CLR that > says that a leafref cannot have a default value. IIRC this was also > Andy's suggestion at the time. I don't remember but agree. :-) How about the second question? For example: must "bar > 1"; leaf foo { type uint8; default 2; } leaf bar { type leafref { path "../foo"; } } Is the must contraint satisfied or not if neither 'foo' nor 'bar' exists in the instance document? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jun 29 05:23: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 BBD043A6D83 for ; Mon, 29 Jun 2009 05:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.112, 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 FSzT2r5AH15B for ; Mon, 29 Jun 2009 05:23: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 E57BD3A6D3A for ; Mon, 29 Jun 2009 05:23: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 ACA93616011; Mon, 29 Jun 2009 14:23:58 +0200 (CEST) Date: Mon, 29 Jun 2009 14:23:58 +0200 (CEST) Message-Id: <20090629.142358.53185785.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246277788.6394.102.camel@missotis> References: <1246275551.6394.90.camel@missotis> <20090629.140207.135166300.mbj@tail-f.com> <1246277788.6394.102.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] leafref questions X-BeenThere: netmod@ietf.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, 29 Jun 2009 12:23:40 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAyOS4gMDYuIDIwMDkgdiAxNDowMiArMDIwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPiANCj4g PiA+IHRocmVlIHF1ZXN0aW9ucyByZWdhcmRpbmcgJ2xlYWZyZWYnOg0KPiA+ID4gDQo+ID4gPiAx LiBDYW4gbGVhZnJlZiBwb2ludCB0byBhbm90aGVyIGxlYWZyZWY/IElmIHNvLCBjaXJjdWxhciBy ZWZlcmVuY2VzIA0KPiA+ID4gICAgc2hvdWxkIHByb2JhYmx5IGJlIGZvcmJpZGRlbi4NCj4gPiAN Cj4gPiBZZXMuICBUaGVyZSBNVVNUIE5PVCBiZSBhbnkgY2lyY3VsYXIgY2hhaW5zIG9mIGxlYWZy ZWZzLg0KPiA+IA0KPiA+ID4gMi4gRG9lcyBhIGRlZmF1bHQgc3BlY2lmaWVkIGZvciB0aGUgdGFy Z2V0IGxlYWYgYXBwbHkgdG8gdGhlIGxlYWZyZWYgDQo+ID4gPiAgICBwb2ludGluZyB0byB0aGF0 IHRhcmdldD8NCj4gPiA+IA0KPiA+ID4gMy4gSXMgaXQgT0sgdG8gc3BlY2lmeSBhIGRlZmF1bHQg Zm9yIHRoZSBsZWFmcmVmIGl0c2VsZj8NCj4gPiANCj4gPiBXZSBkaXNjdXNzZWQgdGhpcyBhIGJp dCBiZWZvcmUuLi4gSSB0aGluayBpdCB3b3VsZCBiZSBvayB0byBhIENMUiB0aGF0DQo+ID4gc2F5 cyB0aGF0IGEgbGVhZnJlZiBjYW5ub3QgaGF2ZSBhIGRlZmF1bHQgdmFsdWUuICBJSVJDIHRoaXMg d2FzIGFsc28NCj4gPiBBbmR5J3Mgc3VnZ2VzdGlvbiBhdCB0aGUgdGltZS4NCj4gDQo+IEkgZG9u J3QgcmVtZW1iZXIgYnV0IGFncmVlLiA6LSkNCj4gDQo+IEhvdyBhYm91dCB0aGUgc2Vjb25kIHF1 ZXN0aW9uPyBGb3IgZXhhbXBsZToNCj4gDQo+IG11c3QgImJhciA+IDEiOw0KPiBsZWFmIGZvbyB7 DQo+ICAgICB0eXBlIHVpbnQ4Ow0KPiAgICAgZGVmYXVsdCAyOw0KPiB9DQo+IGxlYWYgYmFyIHsN Cj4gICAgIHR5cGUgbGVhZnJlZiB7DQo+ICAgICAgICAgcGF0aCAiLi4vZm9vIjsNCj4gICAgIH0N Cj4gfQ0KPiANCj4gSXMgdGhlIG11c3QgY29udHJhaW50IHNhdGlzZmllZCBvciBub3QgaWYgbmVp dGhlciAnZm9vJyBub3IgJ2JhcicgZXhpc3RzDQo+IGluIHRoZSBpbnN0YW5jZSBkb2N1bWVudD8N Cg0KSWYgd2UgYWRkIHRoZSBDTFIgdGhhdCBzYXlzIHRoYXQgYSBsZWFmcmVmIGNhbm5vdCBoYXZl IGEgZGVmYXVsdCwgdGhlbg0KaXQgYXBwbGllcyB0byB0aGlzIGNhc2UgYXMgd2VsbCAtIHRodXMg dGhlIG11c3QgY29udHJhaW50IHdvdWxkIG5vdCBiZQ0Kc2F0aXNmaWVkLg0KDQoNCi9tYXJ0aW4N Cg== From lhotka@cesnet.cz Mon Jun 29 05:29: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 9FC7A3A68ED for ; Mon, 29 Jun 2009 05:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=0.569, 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 Cj5yfKd0oQmn for ; Mon, 29 Jun 2009 05:29:14 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CECF63A6CA4 for ; Mon, 29 Jun 2009 05:29:13 -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 E85C9D800CC; Mon, 29 Jun 2009 14:29:31 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A48AFE7.6000401@netconfcentral.com> References: <20090625.221933.155398855.mbj@tail-f.com> <003d01c9f665$85f00800$0601a8c0@allison> <1246260621.6394.41.camel@missotis> <20090629.101555.99489591.mbj@tail-f.com> <4A48AFE7.6000401@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 29 Jun 2009 14:29:32 +0200 Message-Id: <1246278572.6394.111.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 12:29:14 -0000 Andy Bierman píše v Po 29. 06. 2009 v 05:13 -0700: > > > > o If the "augment" statement is on the top-level, the context node > > is the XPath root node. The XPath root node has all top-level > > schema nodes in all modules as children. > > > > o If the "augment" statement is a substatement to "uses", the > > context node is the node in the data tree for which the "uses" > > statement is defined. > > > > what if the uses-stmt is itself within a grouping? Very good question! In this case it would be natural to follow the chameleon-like nature of groupings, but what if any of the nodes in the augment argument contained explicit namespace prefixes? Strictly speaking, the nodes defined inside a grouping have the null namespace URI (= are not assigned to any namespace) and so there indeed is an ambiguity between the default/local namespace URI and the null URI. Lada > > > > > > /martin > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Jun 29 05:57: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 398A33A6DC8 for ; Mon, 29 Jun 2009 05:57:35 -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 v1tpk66ysImj for ; Mon, 29 Jun 2009 05:57:34 -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 140753A6DC7 for ; Mon, 29 Jun 2009 05:57:34 -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 68BD7616011; Mon, 29 Jun 2009 14:56:55 +0200 (CEST) Date: Mon, 29 Jun 2009 14:56:55 +0200 (CEST) Message-Id: <20090629.145655.78149245.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246278572.6394.111.camel@missotis> References: <20090629.101555.99489591.mbj@tail-f.com> <4A48AFE7.6000401@netconfcentral.com> <1246278572.6394.111.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] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 12:57:35 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFBvIDI5LiAwNi4gMjAwOSB2IDA1OjEzIC0wNzAwOg0KPiANCj4gPiA+IA0KPiA+ ID4gICAgbyAgSWYgdGhlICJhdWdtZW50IiBzdGF0ZW1lbnQgaXMgb24gdGhlIHRvcC1sZXZlbCwg dGhlIGNvbnRleHQgbm9kZQ0KPiA+ID4gICAgICAgaXMgdGhlIFhQYXRoIHJvb3Qgbm9kZS4gIFRo ZSBYUGF0aCByb290IG5vZGUgaGFzIGFsbCB0b3AtbGV2ZWwNCj4gPiA+ICAgICAgIHNjaGVtYSBu b2RlcyBpbiBhbGwgbW9kdWxlcyBhcyBjaGlsZHJlbi4NCj4gPiA+IA0KPiA+ID4gICAgbyAgSWYg dGhlICJhdWdtZW50IiBzdGF0ZW1lbnQgaXMgYSBzdWJzdGF0ZW1lbnQgdG8gInVzZXMiLCB0aGUN Cj4gPiA+ICAgICAgIGNvbnRleHQgbm9kZSBpcyB0aGUgbm9kZSBpbiB0aGUgZGF0YSB0cmVlIGZv ciB3aGljaCB0aGUgInVzZXMiDQo+ID4gPiAgICAgICBzdGF0ZW1lbnQgaXMgZGVmaW5lZC4NCj4g PiA+IA0KPiA+IA0KPiA+IHdoYXQgaWYgdGhlIHVzZXMtc3RtdCBpcyBpdHNlbGYgd2l0aGluIGEg Z3JvdXBpbmc/DQo+IA0KPiBWZXJ5IGdvb2QgcXVlc3Rpb24hIEluIHRoaXMgY2FzZSBpdCB3b3Vs ZCBiZSBuYXR1cmFsIHRvIGZvbGxvdyB0aGUNCj4gY2hhbWVsZW9uLWxpa2UgbmF0dXJlIG9mIGdy b3VwaW5ncywgYnV0IHdoYXQgaWYgYW55IG9mIHRoZSBub2RlcyBpbiB0aGUNCj4gYXVnbWVudCBh cmd1bWVudCBjb250YWluZWQgZXhwbGljaXQgbmFtZXNwYWNlIHByZWZpeGVzPw0KDQpUaGUgY29u dGV4dCBub2RlICguKSBzaG91bGQgaGF2ZSBhcyBpdHMgY2hpbGRyZW4gb25seSB0aGUgY2hpbGRy ZW4gb2YNCnRoZSBncm91cGluZyBzdGF0ZW1lbnQuICBUaGlzIHVzZXMgc3RhdGVtZW50IGlzIG5v dCBhbGxvd2VkIHRvIHJlZmVyDQp0byBhbnkgbm9kZSBvdXRzaWRlIHRoZSBncm91cGluZy4gIERv IHdlIGhhdmUgdG8gaW52ZW50IHNvbWUgYXJ0aWZpY2FsDQpjb250ZXh0IG5vZGU/DQoNCj4gU3Ry aWN0bHkgc3BlYWtpbmcsIHRoZSBub2RlcyBkZWZpbmVkIGluc2lkZSBhIGdyb3VwaW5nIGhhdmUg dGhlIG51bGwNCj4gbmFtZXNwYWNlIFVSSSAoPSBhcmUgbm90IGFzc2lnbmVkIHRvIGFueSBuYW1l c3BhY2UpIGFuZCBzbyB0aGVyZSBpbmRlZWQNCj4gaXMgYW4gYW1iaWd1aXR5IGJldHdlZW4gdGhl IGRlZmF1bHQvbG9jYWwgbmFtZXNwYWNlIFVSSSBhbmQgdGhlIG51bGwNCj4gVVJJLg0KDQpIbW0u LiBJJ20gbm90IHN1cmUgSSBmb2xsb3cuLi4gSXNuJ3QgdGhpcyBleGFtcGxlIGNvcnJlY3QgaW4g eW91cg0Kb3BpbmlvbjoNCg0KICAgbW9kdWxlIHggew0KICAgICBwcmVmaXggeDsNCiAgICAgLi4u DQoNCiAgICAgZ3JvdXBpbmcgYmFyIHsNCiAgICAgICBjb250YWluZXIgYSB7IC4uLiB9DQogICAg IH0NCg0KICAgICBncm91cGluZyBmb28gew0KICAgICAgIHVzZXMgYmFyIHsNCiAgICAgICAgICBh dWdtZW50ICJ4OmEiIHsgIC8vIGxlZ2FsIHJlZmVyZW5jZSB0byBhPz8NCiAgICAgICAgICAgIGxl YWYgeiB7IC4uLiB9DQogICAgICAgICAgfQ0KICAgICAgIH0NCiAgICAgfQ0KICB9DQoNCg0KDQov bWFydGluDQo= From lhotka@cesnet.cz Mon Jun 29 06: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 2E79B28C282 for ; Mon, 29 Jun 2009 06:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=0.538, 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 voX02Qyv3s6q for ; Mon, 29 Jun 2009 06:50:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4CCD83A6ADF for ; Mon, 29 Jun 2009 06:50: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 294B0D800CC; Mon, 29 Jun 2009 15:50:56 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090629.145655.78149245.mbj@tail-f.com> References: <20090629.101555.99489591.mbj@tail-f.com> <4A48AFE7.6000401@netconfcentral.com> <1246278572.6394.111.camel@missotis> <20090629.145655.78149245.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 29 Jun 2009 15:50:56 +0200 Message-Id: <1246283456.6394.151.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 13:50:38 -0000 Martin Bjorklund píše v Po 29. 06. 2009 v 14:56 +0200: > > > Strictly speaking, the nodes defined inside a grouping have the null > > namespace URI (= are not assigned to any namespace) and so there indeed > > is an ambiguity between the default/local namespace URI and the null > > URI. > > Hmm.. I'm not sure I follow... Isn't this example correct in your > opinion: Yes, this is the problem: I don't think 'a' is in the namespace of module 'x' - for sure it isn't if 'foo' is used in another module. Groupings don't contribute to the schema tree, so if we wanted to have the context node for 'augment-uses' in the schema tree, this could only be after all the groupings are expanded and namespaces assigned. It seems we have to define the context node to be the grouping (as Tom suggested) and treat all nodes inside the grouping as having no namespace. So in your example, 'augment "a"' would work but 'augment "x:a"' wouldn't match anything. When the nodes defined in a grouping are eventually installed in the schema tree, they assume the namespace of the module that used the grouping, and this should be true also for nodes appearing in XPath expressions - consider must "a/z > 1"; inside grouping foo in your example. Having "x:" or other NS prefixes in that expression would be a nonsense. Lada > > module x { > prefix x; > ... > > grouping bar { > container a { ... } > } > > grouping foo { > uses bar { > augment "x:a" { // legal reference to a?? > leaf z { ... } > } > } > } > } > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Jun 29 07:28: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 B8D1C28C2A9 for ; Mon, 29 Jun 2009 07:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXkYia3x3IEx for ; Mon, 29 Jun 2009 07:28:12 -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 E38BC28C291 for ; Mon, 29 Jun 2009 07:28:12 -0700 (PDT) Received: (qmail 80393 invoked from network); 29 Jun 2009 14:28:25 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Jun 2009 14:28:25 -0000 X-YMail-OSG: MdOZWrMVM1n_jiSzlhqlXOHEEUpmNGiz3uoUeEUta8zuuCh.SPAeZaDjyn7.NTyEZ0zfi8xdsanTatP1FfYtbQY587EI8_j4i5GpJSAI7sIxRAsnmUFvUfsEWL_RoqEU31XsJf7yyrJJ37sGchy_7AqCzVL2WwPzg4sK98LPBAfLfBlPPdU95Fduq1tQTBryrbSctuN7h8NRcLq64EcysjraM2uaIoD3sLO2y2ErXq6VRVzLIaQHBgB1qW2KT5nZM7OXfREHOZBVHoG6eQ3pnp10qaxnk6HZxOCzNweD9VU_3mHhJbbR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A48CF7D.50209@netconfcentral.com> Date: Mon, 29 Jun 2009 07:28:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090629.101555.99489591.mbj@tail-f.com> <4A48AFE7.6000401@netconfcentral.com> <1246278572.6394.111.camel@missotis> <20090629.145655.78149245.mbj@tail-f.com> <1246283456.6394.151.camel@missotis> In-Reply-To: <1246283456.6394.151.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-06 XPath issues X-BeenThere: netmod@ietf.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, 29 Jun 2009 14:28:14 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Po 29. 06. 2009 v 14:56 +0200: > >>> Strictly speaking, the nodes defined inside a grouping have the null >>> namespace URI (= are not assigned to any namespace) and so there indeed >>> is an ambiguity between the default/local namespace URI and the null >>> URI. >> Hmm.. I'm not sure I follow... Isn't this example correct in your >> opinion: > > Yes, this is the problem: I don't think 'a' is in the namespace of > module 'x' - for sure it isn't if 'foo' is used in another module. > Groupings don't contribute to the schema tree, so if we wanted to have > the context node for 'augment-uses' in the schema tree, this could only > be after all the groupings are expanded and namespaces assigned. > Prefixes in grouping bar and foo are evaluated in module x. That's how groupings are defined. Your XPath code needs to be clever enough to check for well-formed XPath in the grouping, bind the prefixes to namespace IDs in the grouping, but nothing else. Then your clever XPath code knows (when the final cooked objects are put into place), that it is okay to validate the objects for real, using the previous prefix mappings. We went though all this when 'import-by-revision' was discussed. You better evaluate your prefixes in the right place, or you might pick up the wrong module or the wrong version. > It seems we have to define the context node to be the grouping (as Tom > suggested) and treat all nodes inside the grouping as having no > namespace. So in your example, 'augment "a"' would work but > 'augment "x:a"' wouldn't match anything. > no -- all the 'uses' within the grouping 'foo will be evaluated before any 'uses foo' statement is itself evaluated. If you write the code correctly, everything just works. You can't follow it with the naked eye sometimes, but so what. All objects (all the time) are defined within a module namespace, and there is a valid prefix that can be used at any time. > When the nodes defined in a grouping are eventually installed in the > schema tree, they assume the namespace of the module that used the > grouping, and this should be true also for nodes appearing in XPath > expressions - consider > > must "a/z > 1"; > > inside grouping foo in your example. Having "x:" or other NS prefixes in > that expression would be a nonsense. > > Lada > > Andy >> module x { >> prefix x; >> ... >> >> grouping bar { >> container a { ... } >> } >> >> grouping foo { >> uses bar { >> augment "x:a" { // legal reference to a?? >> leaf z { ... } >> } >> } >> } >> } >> >> >> >> /martin From andy@netconfcentral.com Mon Jun 29 08:21: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 0722B3A6A32 for ; Mon, 29 Jun 2009 08:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlDnEnEQIAa8 for ; Mon, 29 Jun 2009 08:21:29 -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 648423A69DA for ; Mon, 29 Jun 2009 08:21:29 -0700 (PDT) Received: (qmail 52089 invoked from network); 29 Jun 2009 15:21:47 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 29 Jun 2009 15:21:47 -0000 X-YMail-OSG: SnpG.fsVM1l.eY.fQWnrbzoCe8Wxr8kK6RHaWOfqh2LS.MqXt0PkkBCYNynJq6e65yRQJbKo1tUmehXFr4kxeQ_PGV1q0iT3jhf4waI2DIZvxhGrcmQCBlt1VExWdet1hYt7LEzHrP5FDV_4JsSF03wA5qV8LFs8BWlYNe_VDvtUgJKNkOnx5rv6EpRNcviHtad39gfoEjDGc84XsAMls5vKW62qxizS.pm.nzaQc.8BFa3z1DxaLkXBGPPfu_n28lYMXmpXn46opzzQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A48DBFF.7010803@netconfcentral.com> Date: Mon, 29 Jun 2009 08:21: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] 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, 29 Jun 2009 15:21:30 -0000 Hi, module x { prefix x; ... import my-identities { prefix y; revision-date 2009-05-04; } identity B { base y:A; } grouping bar { container a { ... } } grouping foo { uses bar { augment "x:a" { // legal reference to a?? (yes!) leaf z { ... } } } leaf xxx { type identityref { base y:A; } default x:B; } } } Is it clear from leaf xxx that this issue has nothing to do with XPath? The prefixes declared in module x are the ones available for use everywhere in module x. Anything less would be too confusing. I strongly oppose any special handling of XPath expressions within groupings. YANG's version of XPath is special enough already. It's more work to enforce the proposed CLR, than it is to just do the right thing. You have to resolve prefixes everywhere within the grouping. Andy From lhotka@cesnet.cz Mon Jun 29 09:09: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 546FC3A6D87 for ; Mon, 29 Jun 2009 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=0.510, 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 Rp2-AGOA2ZX2 for ; Mon, 29 Jun 2009 09:09:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 94C423A6A32 for ; Mon, 29 Jun 2009 09:09: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 190CFD800C1; Mon, 29 Jun 2009 18:08:45 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A48DBFF.7010803@netconfcentral.com> References: <4A48DBFF.7010803@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 29 Jun 2009 18:08:45 +0200 Message-Id: <1246291725.6394.163.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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, 29 Jun 2009 16:09:21 -0000 Andy Bierman píše v Po 29. 06. 2009 v 08:21 -0700: > > I strongly oppose any special handling of > XPath expressions within groupings. YANG's version > of XPath is special enough already. It's more work to > enforce the proposed CLR, than it is to just do the right thing. > You have to resolve prefixes everywhere within the grouping. > > So what's the right thing if you have an expression inside a grouping like this: must "a < x:b and x:b < ../y:c"; where "x" is the prefix of the module in which the grouping appears? When and how are the QNames resolved? Does the result depend on the module where the grouping is used - whether it is "x", "y" or yet another module? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Jun 29 09:35: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 916F728C2B9 for ; Mon, 29 Jun 2009 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 avhZEnodpzO4 for ; Mon, 29 Jun 2009 09:35:45 -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 8333D28C28B for ; Mon, 29 Jun 2009 09:35:45 -0700 (PDT) Received: from [68.142.200.227] by n22.bullet.mail.mud.yahoo.com with NNFMP; 29 Jun 2009 16:36:04 -0000 Received: from [68.142.201.72] by t8.bullet.mud.yahoo.com with NNFMP; 29 Jun 2009 16:36:04 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 29 Jun 2009 16:36:04 -0000 X-Yahoo-Newman-Id: 347966.40265.bm@omp424.mail.mud.yahoo.com Received: (qmail 87924 invoked from network); 29 Jun 2009 16:36:03 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 29 Jun 2009 16:36:03 -0000 X-YMail-OSG: vf9vCTsVM1luWUHk3fDtSI9DjyGgp6P9VN.gdNzgwvh2lnn5bUB9rCCroaFajp1LY1w2ebo4Pb1XvoRezq3Z0zh2edQZfW_dN_mxwsyFexNEDSHJHr535ySxZ099993eFQy.8aOCTRpmP6dh9DSn7GLfQWK1.VGLNSaMMP9Gw5Fz7ZMLCwdYh6uJx.f8ryAt5NZW5CzyupofYFCNRx_xGUql5OHfZvvgyrLNSElgdJqG3wELdZexytlNySjym.CM8tOIVOD6xPJnKV5iylpaMN6fY.Gy4POIAOmPhF6M7I2hEN173_pr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A48ED67.9060302@netconfcentral.com> Date: Mon, 29 Jun 2009 09:35:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A48DBFF.7010803@netconfcentral.com> <1246291725.6394.163.camel@missotis> In-Reply-To: <1246291725.6394.163.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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, 29 Jun 2009 16:35:46 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 29. 06. 2009 v 08:21 -0700: > >> I strongly oppose any special handling of >> XPath expressions within groupings. YANG's version >> of XPath is special enough already. It's more work to >> enforce the proposed CLR, than it is to just do the right thing. >> You have to resolve prefixes everywhere within the grouping. >> >> > > So what's the right thing if you have an expression inside a grouping > like this: > > must "a < x:b and x:b < ../y:c"; > > where "x" is the prefix of the module in which the grouping appears? > When and how are the QNames resolved? Does the result depend on the > module where the grouping is used - whether it is "x", "y" or yet > another module? > All prefixes need to be resolved in the module where they are appear. Any string with prefixes in it has to be resolved this way. Prefixes cannot be resolved in the 'uses' module. uses x:foo; This is an internal expansion. It is not a text replacement like #define in C. Note that a deviation-stmt like this may not work if it is in a different module than your grouping: deviation blah/a { deviate delete { must "a < x:b and x:b < ../y:c"; } } Unless the imports/prefixes match in both modules, this deviation statement is going to do the wrong thing. This goes for applying defaults, resolving types, whatever. Nobody said it was a goal to make YANG easy to use for tool developers. For YANG writers, if you stick to what you know, you're OK. In other words, the localized cost is good. It's easy to do most things right, and not so easy for the rest. > Lada > Andy From lhotka@cesnet.cz Tue Jun 30 00:45: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 268BB3A6E0C for ; Tue, 30 Jun 2009 00:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=0.484, 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 7OBt0T9cdNv2 for ; Tue, 30 Jun 2009 00:45:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 533FD3A6B46 for ; Tue, 30 Jun 2009 00:45:41 -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 BE2F1D800C5 for ; Tue, 30 Jun 2009 09:45:39 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A48ED67.9060302@netconfcentral.com> References: <4A48DBFF.7010803@netconfcentral.com> <1246291725.6394.163.camel@missotis> <4A48ED67.9060302@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 30 Jun 2009 09:45:37 +0200 Message-Id: <1246347937.6511.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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: Tue, 30 Jun 2009 07:45:42 -0000 Andy Bierman píše v Po 29. 06. 2009 v 09:35 -0700: > > So what's the right thing if you have an expression inside a grouping > > like this: > > > > must "a < x:b and x:b < ../y:c"; > > > > where "x" is the prefix of the module in which the grouping appears? > > When and how are the QNames resolved? Does the result depend on the > > module where the grouping is used - whether it is "x", "y" or yet > > another module? > > > > All prefixes need to be resolved in the module where they are appear. > Any string with prefixes in it has to be resolved this way. > Prefixes cannot be resolved in the 'uses' module. > YANG rules state that unprefixed names belong to the namespace of the local module, so "a" above would be equivalent to "x:a". But we want this to work in the module where the grouping is used: grouping lease-times { container lease-times { must "lease-time <= max-lease-time"; leaf lease-time { ... } leaf max-lease-time { ... } } } I think it would be quite consistent (no CLR at all) to say that unprefixed names in groupings have null NS URI and these and only these names adopt the namespace of the module where the grouping is used. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Jun 30 05:36: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 657943A6AC1 for ; Tue, 30 Jun 2009 05:36:15 -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.202, 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 BKrIUzmepWQG for ; Tue, 30 Jun 2009 05:36:14 -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 98E333A67FD for ; Tue, 30 Jun 2009 05:36:14 -0700 (PDT) Received: (qmail 28100 invoked from network); 30 Jun 2009 12:36:18 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 30 Jun 2009 12:36:17 -0000 X-YMail-OSG: 40dYjVAVM1kP2JKdWVnSJNTPG1LRixFpqyj5EnQu0KmTpy6RIllna0IJKxJR.MfQIOp7yOizyHHgk8PzisHOoj6sxttmALCQsPT2AHySR5r5jseOgYEgmWKRMxUVa1dsl1lv5LHFT4qRJ5Spd_uONdyY_KpuOJwp_eZ5jiTOXFFsaHSVSTXTh4E1GaoLan62EObY28UvJ0I2HUg3Xmnbs2jIHF7MHUO82hzAstUvf0Db9BMJhuB_cW5lbevxxQuuoJugi_mtx921u_US X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4A0639.3000107@netconfcentral.com> Date: Tue, 30 Jun 2009 05:34:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A48DBFF.7010803@netconfcentral.com> <1246291725.6394.163.camel@missotis> <4A48ED67.9060302@netconfcentral.com> <1246347937.6511.16.camel@missotis> In-Reply-To: <1246347937.6511.16.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Tue, 30 Jun 2009 12:36:15 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 29. 06. 2009 v 09:35 -0700: >>> So what's the right thing if you have an expression inside a grouping >>> like this: >>> >>> must "a < x:b and x:b < ../y:c"; >>> >>> where "x" is the prefix of the module in which the grouping appears? >>> When and how are the QNames resolved? Does the result depend on the >>> module where the grouping is used - whether it is "x", "y" or yet >>> another module? >>> >> All prefixes need to be resolved in the module where they are appear. >> Any string with prefixes in it has to be resolved this way. >> Prefixes cannot be resolved in the 'uses' module. >> > > YANG rules state that unprefixed names belong to the namespace of the > local module, so "a" above would be equivalent to "x:a". But we want > this to work in the module where the grouping is used: > > grouping lease-times { > container lease-times { > must "lease-time <= max-lease-time"; > leaf lease-time { ... } > leaf max-lease-time { ... } > } > } > > I think it would be quite consistent (no CLR at all) to say that > unprefixed names in groupings have null NS URI and these and only these > names adopt the namespace of the module where the grouping is used. > I disagree. All the prefixes need to be resolved at the same time, using the same set of prefix to namespace mappings. Just because the XPath expression is in a grouping is not a special condition. must "../foo = 7 or ../x:foo = 9"; Are foo and x:foo the same node? Only the data model writer of this module, where this expression appears, knows that for sure. The expression cannot mean x:foo in one module and something else in another module. That's why all the namespaces are resolved in the [sub]module where they appear. > Lada > Andy From lhotka@cesnet.cz Tue Jun 30 07:45:41 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 A4DE43A68E5 for ; Tue, 30 Jun 2009 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=0.161, 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 CgUQwxpxVsUE for ; Tue, 30 Jun 2009 07:45:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6EFD53A679F for ; Tue, 30 Jun 2009 07:45:40 -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 AB58FD800C1 for ; Tue, 30 Jun 2009 16:44:08 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A4A0639.3000107@netconfcentral.com> References: <4A48DBFF.7010803@netconfcentral.com> <1246291725.6394.163.camel@missotis> <4A48ED67.9060302@netconfcentral.com> <1246347937.6511.16.camel@missotis> <4A4A0639.3000107@netconfcentral.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Tue, 30 Jun 2009 16:44:09 +0200 Message-Id: <1246373049.6511.62.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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: Tue, 30 Jun 2009 14:45:41 -0000 Andy Bierman píše v Út 30. 06. 2009 v 05:34 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Po 29. 06. 2009 v 09:35 -0700: > >>> So what's the right thing if you have an expression inside a grouping > >>> like this: > >>> > >>> must "a < x:b and x:b < ../y:c"; > >>> > >>> where "x" is the prefix of the module in which the grouping appears? > >>> When and how are the QNames resolved? Does the result depend on the > >>> module where the grouping is used - whether it is "x", "y" or yet > >>> another module? > >>> > >> All prefixes need to be resolved in the module where they are appear. > >> Any string with prefixes in it has to be resolved this way. > >> Prefixes cannot be resolved in the 'uses' module. > >> > > > > YANG rules state that unprefixed names belong to the namespace of the > > local module, so "a" above would be equivalent to "x:a". But we want > > this to work in the module where the grouping is used: > > > > grouping lease-times { > > container lease-times { > > must "lease-time <= max-lease-time"; > > leaf lease-time { ... } > > leaf max-lease-time { ... } > > } > > } > > > > I think it would be quite consistent (no CLR at all) to say that > > unprefixed names in groupings have null NS URI and these and only these > > names adopt the namespace of the module where the grouping is used. > > > > I disagree. > All the prefixes need to be resolved at the same time, > using the same set of prefix to namespace mappings. > Just because the XPath expression is in a grouping > is not a special condition. > > > must "../foo = 7 or ../x:foo = 9"; I the schema tree (outside any grouping) "../foo" and "../x:foo" indeed are the same node if "x" is the NS prefix of the local module. I don't know, maybe we mean the same thing, you probably also want the unprefixed names in XPath expressions within groupings to get the namespace of the module where the grouping is used, right? In, other words: module xxx { prefix x; namespace "http://example.com/xxx"; import yyy { prefix y; } grouping ggg { x:foo ---> ns="http://example.com/xxx", localname="foo" (fixed) y:bar ---> ns="http://example.com/yyy", localname="bar" (fixed) baz ---> ns=, localname="baz" (gets NS of the module where ggg is used). } } Or do you want to resolve "baz" right away to ns="http://example.com/xxx", localname="baz" and never change it? Lada > > Are foo and x:foo the same node? > Only the data model writer of this module, > where this expression appears, knows that for sure. > The expression cannot mean x:foo in one module > and something else in another module. That's > why all the namespaces are resolved in the [sub]module where > they appear. > > > Lada > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Jun 30 08:55: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 0AE403A6A5D for ; Tue, 30 Jun 2009 08:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=-0.189, 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 iQMuPBQsTtGa for ; Tue, 30 Jun 2009 08:55:31 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 22F433A685B for ; Tue, 30 Jun 2009 08:55:30 -0700 (PDT) Received: from [68.142.200.225] by n17.bullet.mail.mud.yahoo.com with NNFMP; 30 Jun 2009 15:54:31 -0000 Received: from [68.142.201.64] by t6.bullet.mud.yahoo.com with NNFMP; 30 Jun 2009 15:54:31 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 30 Jun 2009 15:54:31 -0000 X-Yahoo-Newman-Id: 846585.65298.bm@omp416.mail.mud.yahoo.com Received: (qmail 33664 invoked from network); 30 Jun 2009 15:54:31 -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; 30 Jun 2009 15:54:31 -0000 X-YMail-OSG: OC95xDwVM1kwoITpFhnVaetl2t2GrFPyEaqwVjX0T_1K9cW29OsDzz5L7Mrv0r0XD7fy0fmOrk4YvhgI74oie9bJ99hROry6L8YIcIDGAYhqwQkDaNyykqHEPrbhcBEWBQtYSv6O5Y3_MIbTaACJORDmEZNaR_zi6IMqOZX8NrKd5C2aoL3k3w9RnlRnBR_pKUxSj.FNULji2DPlYx0pQmskWv.EKTcYJF80t5GQufL.74dcriYUIGh3YWu4johz7R6UfRhepyJN1Uoobr0fAnVmxweaIdUr4w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4A3527.1070504@netconfcentral.com> Date: Tue, 30 Jun 2009 08:54:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A48DBFF.7010803@netconfcentral.com> <1246291725.6394.163.camel@missotis> <4A48ED67.9060302@netconfcentral.com> <1246347937.6511.16.camel@missotis> <4A4A0639.3000107@netconfcentral.com> <1246373049.6511.62.camel@missotis> In-Reply-To: <1246373049.6511.62.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Tue, 30 Jun 2009 15:55:32 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Út 30. 06. 2009 v 05:34 -0700: >> Ladislav Lhotka wrote: >>> Andy Bierman píše v Po 29. 06. 2009 v 09:35 -0700: >>>>> So what's the right thing if you have an expression inside a grouping >>>>> like this: >>>>> >>>>> must "a < x:b and x:b < ../y:c"; >>>>> >>>>> where "x" is the prefix of the module in which the grouping appears? >>>>> When and how are the QNames resolved? Does the result depend on the >>>>> module where the grouping is used - whether it is "x", "y" or yet >>>>> another module? >>>>> >>>> All prefixes need to be resolved in the module where they are appear. >>>> Any string with prefixes in it has to be resolved this way. >>>> Prefixes cannot be resolved in the 'uses' module. >>>> >>> YANG rules state that unprefixed names belong to the namespace of the >>> local module, so "a" above would be equivalent to "x:a". But we want >>> this to work in the module where the grouping is used: >>> >>> grouping lease-times { >>> container lease-times { >>> must "lease-time <= max-lease-time"; >>> leaf lease-time { ... } >>> leaf max-lease-time { ... } >>> } >>> } >>> >>> I think it would be quite consistent (no CLR at all) to say that >>> unprefixed names in groupings have null NS URI and these and only these >>> names adopt the namespace of the module where the grouping is used. >>> >> I disagree. >> All the prefixes need to be resolved at the same time, >> using the same set of prefix to namespace mappings. >> Just because the XPath expression is in a grouping >> is not a special condition. >> >> >> must "../foo = 7 or ../x:foo = 9"; > > I the schema tree (outside any grouping) "../foo" and "../x:foo" indeed > are the same node if "x" is the NS prefix of the local module. > > I don't know, maybe we mean the same thing, you probably also want the > unprefixed names in XPath expressions within groupings to get the > namespace of the module where the grouping is used, right? > > In, other words: > > module xxx { > prefix x; > namespace "http://example.com/xxx"; > import yyy { prefix y; } > grouping ggg { > x:foo ---> ns="http://example.com/xxx", localname="foo" (fixed) > y:bar ---> ns="http://example.com/yyy", localname="bar" (fixed) > baz ---> ns=, localname="baz" (gets NS of the module > where ggg is used). > } > } > > Or do you want to resolve "baz" right away to > ns="http://example.com/xxx", localname="baz" and never change it? > I don't understand this grouping 'ggg'. It is not legal YANG. You cannot declare the 'y:bar' object. Module xxx can only declare its own objects in a grouping. The objects themselves will end up with the namespace of the final 'uses stmt'. This is not the same as prefixes used in sub-statements within these objects, like type-stmt, unique-stmt, default-stmt, etc. The leaf-stmt syntax does not allow the identifier to have a prefix, even if it is the local module prefix. leaf foo { } leaf x:foo { } // not allowed > Lada Andy > >> Are foo and x:foo the same node? >> Only the data model writer of this module, >> where this expression appears, knows that for sure. >> The expression cannot mean x:foo in one module >> and something else in another module. That's >> why all the namespaces are resolved in the [sub]module where >> they appear. >> >>> Lada >>> >> Andy >> From lhotka@cesnet.cz Tue Jun 30 10:34: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 E5A8D3A6C7F for ; Tue, 30 Jun 2009 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=0.154, 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 m+3RvPsY41zP for ; Tue, 30 Jun 2009 10:34:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0F2D33A69A4 for ; Tue, 30 Jun 2009 10:34:43 -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 7CEDBD800C0; Tue, 30 Jun 2009 19:01:18 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A4A3527.1070504@netconfcentral.com> References: <4A48DBFF.7010803@netconfcentral.com> <1246291725.6394.163.camel@missotis> <4A48ED67.9060302@netconfcentral.com> <1246347937.6511.16.camel@missotis> <4A4A0639.3000107@netconfcentral.com> <1246373049.6511.62.camel@missotis> <4A4A3527.1070504@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 30 Jun 2009 19:01:19 +0200 Message-Id: <1246381279.6511.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Tue, 30 Jun 2009 17:34:44 -0000 Andy Bierman píše v Út 30. 06. 2009 v 08:54 -0700: > > > > module xxx { > > prefix x; > > namespace "http://example.com/xxx"; > > import yyy { prefix y; } > > grouping ggg { > > x:foo ---> ns="http://example.com/xxx", localname="foo" (fixed) > > y:bar ---> ns="http://example.com/yyy", localname="bar" (fixed) > > baz ---> ns=, localname="baz" (gets NS of the module > > where ggg is used). > > } > > } > > > > Or do you want to resolve "baz" right away to > > ns="http://example.com/xxx", localname="baz" and never change it? > > > > > I don't understand this grouping 'ggg'. > It is not legal YANG. You cannot declare Yes, this was just a schematic shortcut. These symbols were supposed to be in XPath expressions, for example 'must'. Lada > the 'y:bar' object. Module xxx can > only declare its own objects in a grouping. > The objects themselves will end up with the namespace > of the final 'uses stmt'. > > This is not the same as prefixes used in sub-statements > within these objects, like type-stmt, unique-stmt, default-stmt, etc. > > The leaf-stmt syntax does not allow the identifier to have > a prefix, even if it is the local module prefix. > > leaf foo { } > > leaf x:foo { } // not allowed > > > > Lada > > > Andy > > > > >> Are foo and x:foo the same node? > >> Only the data model writer of this module, > >> where this expression appears, knows that for sure. > >> The expression cannot mean x:foo in one module > >> and something else in another module. That's > >> why all the namespaces are resolved in the [sub]module where > >> they appear. > >> > >>> Lada > >>> > >> Andy > >> > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 30 10:44: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 1B17028C20C for ; Tue, 30 Jun 2009 10:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.221, 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 c7zJDBOxKHmt for ; Tue, 30 Jun 2009 10:44:36 -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 738EA3A6E9D for ; Tue, 30 Jun 2009 10:44:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A1DA276C52F; Tue, 30 Jun 2009 19:42:56 +0200 (CEST) Date: Tue, 30 Jun 2009 19:42:56 +0200 (CEST) Message-Id: <20090630.194256.266517464.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246381279.6511.70.camel@missotis> References: <1246373049.6511.62.camel@missotis> <4A4A3527.1070504@netconfcentral.com> <1246381279.6511.70.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] 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: Tue, 30 Jun 2009 17:44:37 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IMOadCAzMC4gMDYuIDIwMDkgdiAwODo1NCAtMDcwMDoNCj4gPiA+IA0KPiA+ID4g bW9kdWxlIHh4eCB7DQo+ID4gPiAgICAgcHJlZml4IHg7DQo+ID4gPiAgICAgbmFtZXNwYWNlICJo dHRwOi8vZXhhbXBsZS5jb20veHh4IjsNCj4gPiA+ICAgICBpbXBvcnQgeXl5IHsgcHJlZml4IHk7 IH0NCj4gPiA+ICAgICBncm91cGluZyBnZ2cgew0KPiA+ID4gICAgICAgICB4OmZvbyAtLS0+IG5z PSJodHRwOi8vZXhhbXBsZS5jb20veHh4IiwgbG9jYWxuYW1lPSJmb28iIChmaXhlZCkNCj4gPiA+ ICAgICAgICAgeTpiYXIgLS0tPiBucz0iaHR0cDovL2V4YW1wbGUuY29tL3l5eSIsIGxvY2FsbmFt ZT0iYmFyIiAoZml4ZWQpDQo+ID4gPiAgICAgICAgIGJheiAgIC0tLT4gbnM9PG51bGw+LCBsb2Nh bG5hbWU9ImJheiIgKGdldHMgTlMgb2YgdGhlIG1vZHVsZSANCj4gPiA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hlcmUgZ2dnIGlzIHVzZWQpLg0KPiA+ ID4gICAgIH0NCj4gPiA+IH0NCj4gPiA+IA0KPiA+ID4gT3IgZG8geW91IHdhbnQgdG8gcmVzb2x2 ZSAiYmF6IiByaWdodCBhd2F5IHRvDQo+ID4gPiBucz0iaHR0cDovL2V4YW1wbGUuY29tL3h4eCIs IGxvY2FsbmFtZT0iYmF6IiBhbmQgbmV2ZXIgY2hhbmdlIGl0Pw0KPiA+ID4gDQo+ID4gDQo+ID4g DQo+ID4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgZ3JvdXBpbmcgJ2dnZycuDQo+ID4gSXQgaXMg bm90IGxlZ2FsIFlBTkcuICBZb3UgY2Fubm90IGRlY2xhcmUNCj4gDQo+IFllcywgdGhpcyB3YXMg anVzdCBhIHNjaGVtYXRpYyBzaG9ydGN1dC4gVGhlc2Ugc3ltYm9scyB3ZXJlIHN1cHBvc2VkIHRv DQo+IGJlIGluIFhQYXRoIGV4cHJlc3Npb25zLCBmb3IgZXhhbXBsZSAnbXVzdCcuDQoNCkknbSBu b3Qgc3VyZSBJIGFncmVlLiAgTGV0J3MgdHJ5IGEgc2ltcGxlciBleGFtcGxlLCB3L28gWFBhdGg6 DQoNCiAgbW9kdWxlIHggew0KICAgIHByZWZpeCBwOw0KICAgIC4uLg0KICAgIA0KICAgIGdyb3Vw aW5nIGZvbyB7DQogICAgICB0eXBlZGVmIHsNCiAgICAgICAgdHlwZSBpbnQzMjsNCiAgICAgIH0N CiAgICAgIGxlYWYgYSB7DQogICAgICAgIHR5cGUgcDp0MTsNCiAgICAgIH0NCiAgICB9DQogIH0N Cg0KICBtb2R1bGUgeSB7DQogICAgcHJlZml4IHA7DQogICAgLi4uDQogICAgaW1wb3J0IHggew0K ICAgICAgcHJlZml4IHg7DQogICAgfQ0KICAgIHR5cGVkZWYgdDEgew0KICAgICAgdHlwZSBzdHJp bmc7DQogICAgfQ0KDQogICAgdXNlcyBmb287DQogIH0NCg0KTm93LCBpbiBtb2R1bGUgJ3knLCB0 aGVyZSB3aWxsIGJlIGEgbGVhZiAnYScuICBUaGUgdHlwZSBvZiAnYScgaXMgJ3QxJw0KYXMgZGVm aW5lZCBpbiB0aGUgZ3JvdXBpbmcgJ2ZvbycgaW4gbW9kdWxlICd4JywgaS5lLiBhbiBpbnQzMi4g ICBJdCBpcw0KTk9UIGEgc3RyaW5nLiAgU28sIHN5bWJvbHMgYXJlICJsZXhpY2FsbHkgc2NvcGVk IiwgaS5lLiB0aGUgc3ltYm9sIGlzDQppZGVudGlmaWVkIGZyb20gaXRzIGxleGljYWwgc2NvcGUu DQoNCldlIHdhbnQgdGhlIHNhbWUgaGFuZGxpbmcgZm9yIG5vZGUgaWRlbnRpZmllcnMgaW4gJ2F1 Z21lbnQnLCAnbXVzdCcNCmV0YywgaS5lLiBhbHNvIGluIFhQYXRoLg0KDQoNCi9tYXJ0aW4NCg0K DQoNCg== From lhotka@cesnet.cz Tue Jun 30 11:23: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 DFA5F28C404 for ; Tue, 30 Jun 2009 11:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=0.447, 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 8JKm1ZxR-Idn for ; Tue, 30 Jun 2009 11:23:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F16E33A6CCC for ; Tue, 30 Jun 2009 11:23:09 -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 04951D800C1; Tue, 30 Jun 2009 20:22:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090630.194256.266517464.mbj@tail-f.com> References: <1246373049.6511.62.camel@missotis> <4A4A3527.1070504@netconfcentral.com> <1246381279.6511.70.camel@missotis> <20090630.194256.266517464.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 30 Jun 2009 20:22:27 +0200 Message-Id: <1246386147.6511.86.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: Tue, 30 Jun 2009 18:23:11 -0000 Martin Bjorklund píše v Út 30. 06. 2009 v 19:42 +0200: > > I'm not sure I agree. Let's try a simpler example, w/o XPath: > > module x { > prefix p; > ... > > grouping foo { > typedef { > type int32; > } > leaf a { > type p:t1; > } > } > } > > module y { > prefix p; > ... > import x { > prefix x; > } > typedef t1 { > type string; > } > > uses foo; > } > > Now, in module 'y', there will be a leaf 'a'. The type of 'a' is 't1' > as defined in the grouping 'foo' in module 'x', i.e. an int32. It is > NOT a string. So, symbols are "lexically scoped", i.e. the symbol is > identified from its lexical scope. 'uses foo;' means that 'leaf a', which is defined in a grouping in module 'x' becomes part of the data tree in module 'y' and assumes the namespace of 'y'. If 'grouping foo' in addition contained the same symbol 'a' in an XPath expression, e.g. in 'must', it is IMO necessary that when the XPath expression is evaluated, 'a' in it still corresponds to the same 'leaf a'. This means that it must be the same QName, i.e., have the namespace of module y. Otherwise the 'must condition' in my earlier example cound never work properly. grouping lease-times { container lease-times { must "lease-time <= max-lease-time"; leaf lease-time { ... } leaf max-lease-time { ... } } } I agree that all symbols with explicit namespace prefixes should keep the namespace corresponding to that prefix in the module where the grouping is defined. Lada > > We want the same handling for node identifiers in 'augment', 'must' > etc, i.e. also in XPath. > > > /martin > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Jun 30 11:49: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 313023A698D for ; Tue, 30 Jun 2009 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 m0TxOj6Jk7Gg for ; Tue, 30 Jun 2009 11:49:17 -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 5651A3A6A38 for ; Tue, 30 Jun 2009 11:48:51 -0700 (PDT) Received: (qmail 97061 invoked from network); 30 Jun 2009 18:48:47 -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; 30 Jun 2009 18:48:47 -0000 X-YMail-OSG: UtQmlFMVM1n3oHhRL7Pm6UMICEiPuzpPemTJinxyY8h1nh55DRBgDRJ4uu76QXwt53Wty4y8JtjXs394Vb97ebq.IJ6_K_yHibtZKL1e67MPShJ_fz0RrauzZ2oBrtm2PqMgkr8CaUdRJa0nEdoe8ajCODDi1jY0VcID2pvIPQrgdqbcrJQcFno3yquJIW3h1J..jm9FwZu6jLzGp0OD88oH68bwTg_RHV1v4mKFO2oPYiQTbLaaBHtRygcQRoohzSU7FE38uOv4C_efCX7gmcxOiFSKZ6vsRsvpW2c7Vgh6U5BLWDxY X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4A5D85.90602@netconfcentral.com> Date: Tue, 30 Jun 2009 11:46:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <1246373049.6511.62.camel@missotis> <4A4A3527.1070504@netconfcentral.com> <1246381279.6511.70.camel@missotis> <20090630.194256.266517464.mbj@tail-f.com> In-Reply-To: <20090630.194256.266517464.mbj@tail-f.com> 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: Tue, 30 Jun 2009 18:49:18 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Andy Bierman píše v Út 30. 06. 2009 v 08:54 -0700: >>>> module xxx { >>>> prefix x; >>>> namespace "http://example.com/xxx"; >>>> import yyy { prefix y; } >>>> grouping ggg { >>>> x:foo ---> ns="http://example.com/xxx", localname="foo" (fixed) >>>> y:bar ---> ns="http://example.com/yyy", localname="bar" (fixed) >>>> baz ---> ns=, localname="baz" (gets NS of the module >>>> where ggg is used). >>>> } >>>> } >>>> >>>> Or do you want to resolve "baz" right away to >>>> ns="http://example.com/xxx", localname="baz" and never change it? >>>> >>> >>> I don't understand this grouping 'ggg'. >>> It is not legal YANG. You cannot declare >> Yes, this was just a schematic shortcut. These symbols were supposed to >> be in XPath expressions, for example 'must'. > > I'm not sure I agree. Let's try a simpler example, w/o XPath: > > module x { > prefix p; > ... > > grouping foo { > typedef { > type int32; > } > leaf a { > type p:t1; > } > } > } > > module y { > prefix p; > ... > import x { > prefix x; > } > typedef t1 { > type string; > } > > uses foo; > } > > Now, in module 'y', there will be a leaf 'a'. The type of 'a' is 't1' > as defined in the grouping 'foo' in module 'x', i.e. an int32. It is > NOT a string. So, symbols are "lexically scoped", i.e. the symbol is > identified from its lexical scope. > > We want the same handling for node identifiers in 'augment', 'must' > etc, i.e. also in XPath. > That's what we already implemented, right? It is obvious by inspection that all prefixes in the grouping are relative to the current [sub]module, and uses/grouping is in no way, shape, or form, anything like #define in C? Imagine if there were locally scoped identityref typedefs, locally scoped groupings with this entire scenario repeated recursively, all inside the context of module y. YANG requires that the correct namespace-to-prefix associations are done in the correct context, all the time. What text in the draft even suggests anything different? > > /martin > > Andy From mbj@tail-f.com Tue Jun 30 11:52: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 EB80A28C447 for ; Tue, 30 Jun 2009 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 5n8XNQn31Rjk for ; Tue, 30 Jun 2009 11:52:27 -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 3D2C828C444 for ; Tue, 30 Jun 2009 11:52:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E90676C547; Tue, 30 Jun 2009 20:51:48 +0200 (CEST) Date: Tue, 30 Jun 2009 20:51:48 +0200 (CEST) Message-Id: <20090630.205148.128258196.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A4A5D85.90602@netconfcentral.com> References: <1246381279.6511.70.camel@missotis> <20090630.194256.266517464.mbj@tail-f.com> <4A4A5D85.90602@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: Tue, 30 Jun 2009 18:52:28 -0000 Andy Bierman wrote: > That's what we already implemented, right? Exactly. Lada, do you have any concerns at this point? /martin From lhotka@cesnet.cz Tue Jun 30 13:02: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 22F103A6EF7 for ; Tue, 30 Jun 2009 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=0.428, 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 B7f6aGOQbeHK for ; Tue, 30 Jun 2009 13:02:22 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4D4ED3A6EF4 for ; Tue, 30 Jun 2009 13:02:22 -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 C35AAD800CC; Tue, 30 Jun 2009 22:02:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090630.205148.128258196.mbj@tail-f.com> References: <1246381279.6511.70.camel@missotis> <20090630.194256.266517464.mbj@tail-f.com> <4A4A5D85.90602@netconfcentral.com> <20090630.205148.128258196.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 30 Jun 2009 22:02:20 +0200 Message-Id: <1246392140.6511.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: Tue, 30 Jun 2009 20:02:23 -0000 Martin Bjorklund píše v Út 30. 06. 2009 v 20:51 +0200: > Andy Bierman wrote: > > That's what we already implemented, right? > > Exactly. > > Lada, do you have any concerns at this point? Still the same concern: what happens to unprefixed names in XPath expressions that appear inside groupings, specifically, which namespace URI they have if they are evaluated in a different module - not the one where the grouping is defined. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 30 13:12: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 1E95228C44D for ; Tue, 30 Jun 2009 13:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.087, 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 yvMNo-1cI6ll for ; Tue, 30 Jun 2009 13:12: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 4F5DE28C445 for ; Tue, 30 Jun 2009 13:12:53 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7EE1C76C52F; Tue, 30 Jun 2009 22:13:13 +0200 (CEST) Date: Tue, 30 Jun 2009 22:13:13 +0200 (CEST) Message-Id: <20090630.221313.227787400.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1246392140.6511.94.camel@missotis> References: <4A4A5D85.90602@netconfcentral.com> <20090630.205148.128258196.mbj@tail-f.com> <1246392140.6511.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=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: Tue, 30 Jun 2009 20:12:54 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMzAuIDA2LiAyMDA5IHYgMjA6NTEgKzAyMDA6DQo+ID4gQW5keSBC aWVybWFuIDxhbmR5QG5ldGNvbmZjZW50cmFsLmNvbT4gd3JvdGU6DQo+ID4gPiBUaGF0J3Mgd2hh dCB3ZSBhbHJlYWR5IGltcGxlbWVudGVkLCByaWdodD8NCj4gPiANCj4gPiBFeGFjdGx5Lg0KPiA+ IA0KPiA+IExhZGEsIGRvIHlvdSBoYXZlIGFueSBjb25jZXJucyBhdCB0aGlzIHBvaW50Pw0KPiAN Cj4gU3RpbGwgdGhlIHNhbWUgY29uY2Vybjogd2hhdCBoYXBwZW5zIHRvIHVucHJlZml4ZWQgbmFt ZXMgaW4gWFBhdGgNCj4gZXhwcmVzc2lvbnMgdGhhdCBhcHBlYXIgaW5zaWRlIGdyb3VwaW5ncywg c3BlY2lmaWNhbGx5LCB3aGljaCBuYW1lc3BhY2UNCj4gVVJJIHRoZXkgaGF2ZSBpZiB0aGV5IGFy ZSBldmFsdWF0ZWQgaW4gYSBkaWZmZXJlbnQgbW9kdWxlIC0gbm90IHRoZSBvbmUNCj4gd2hlcmUg dGhlIGdyb3VwaW5nIGlzIGRlZmluZWQuDQoNCklmIGEgbXVzdC93aGVuIGV4cHJlc3Npb24gaW4g YSBncm91cGluZyByZWZlcnMgdG8gYSBub2RlIGluIHRoZQ0KZ3JvdXBpbmcgLSB3aXRoIG9yIHdp dGhvdXQgcHJlZml4IC0gYXQgY29uY2VwdHVhbCBldmFsdWF0aW9uIHRpbWUgdGhleQ0Kd2lsbCBh bHdheXMgcmVmZXIgdG8gdGhlIG5vZGUgd2l0aGluIHRoZSBncm91cGluZywgaS5lLiB3aXRoIHRo ZQ0KbmFtZXNwYWNlIG9mIHRoZSBtb2R1bGUgd2hlcmUgdGhlIGdyb3VwaW5nIGlzIHVzZWQuDQoN Cg0KL21hcnRpbg0K From mbj@tail-f.com Tue Jun 30 13:31: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 736EF3A6A96 for ; Tue, 30 Jun 2009 13:31:37 -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 fMG2PuTS9wMY for ; Tue, 30 Jun 2009 13:31:36 -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 A243B3A6891 for ; Tue, 30 Jun 2009 13:31:36 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7EF9076C52F for ; Tue, 30 Jun 2009 22:31:23 +0200 (CEST) Date: Tue, 30 Jun 2009 22:31:23 +0200 (CEST) Message-Id: <20090630.223123.09049480.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [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: Tue, 30 Jun 2009 20:31:37 -0000 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 From Washam.Fan@huaweisymantec.com Tue Jun 30 19: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 DC1A03A6AAF for ; Tue, 30 Jun 2009 19:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7Ec4NOi6wRz for ; Tue, 30 Jun 2009 19:15:11 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 0615E3A67B4 for ; Tue, 30 Jun 2009 19:15:11 -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 <0KM2008RSZLMNH60@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 01 Jul 2009 10:15:22 +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 <0KM200IVCZLL9J00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 01 Jul 2009 10:15:22 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 01 Jul 2009 10:15:21 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Wed, 01 Jul 2009 10:15:21 +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: <20090630.223123.09049480.mbj@tail-f.com> References: <20090630.223123.09049480.mbj@tail-f.com> Cc: netmod@ietf.org 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 02:15:11 -0000 I agree. Node identifier would be used to identify a schema node which should be target node argument of those stmts like augment. XPath would be used to express conditions which should be arguments of those stmts like when/must. washam ----- Original Message ----- From: Martin Bjorklund Date: Wednesday, July 1, 2009 4:32 am Subject: [netmod] xpath in augment To: netmod@ietf.org > 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 > From lhotka@cesnet.cz Tue Jun 30 23:02: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 752E928C13F for ; Tue, 30 Jun 2009 23:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=0.411, 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 hAEeboC3BXuO for ; Tue, 30 Jun 2009 23:02:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9A2EE28C101 for ; Tue, 30 Jun 2009 23:02:58 -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 E2A8CD800C8; Wed, 1 Jul 2009 08:03:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090630.221313.227787400.mbj@tail-f.com> References: <4A4A5D85.90602@netconfcentral.com> <20090630.205148.128258196.mbj@tail-f.com> <1246392140.6511.94.camel@missotis> <20090630.221313.227787400.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 01 Jul 2009 08:03:19 +0200 Message-Id: <1246428199.6491.18.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 06:02:59 -0000 Martin Bjorklund píše v Út 30. 06. 2009 v 22:13 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 30. 06. 2009 v 20:51 +0200: > > > Andy Bierman wrote: > > > > That's what we already implemented, right? > > > > > > Exactly. > > > > > > Lada, do you have any concerns at this point? > > > > Still the same concern: what happens to unprefixed names in XPath > > expressions that appear inside groupings, specifically, which namespace > > URI they have if they are evaluated in a different module - not the one > > where the grouping is defined. > > 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. 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"; 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." Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C