From netmod-bounces@ietf.org Sun Feb 1 02:54:26 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB2728C158; Sun, 1 Feb 2009 02:54:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9427B28C158 for ; Sun, 1 Feb 2009 02:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 3SfonEH-DicT for ; Sun, 1 Feb 2009 02:54:24 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id C2C7728C14B for ; Sun, 1 Feb 2009 02:54:22 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED00AA3VLYUT30@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Sun, 01 Feb 2009 18:54:00 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED004UCVLWBW00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Sun, 01 Feb 2009 18:53:58 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sun, 01 Feb 2009 18:53:56 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sun, 01 Feb 2009 18:53:56 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49854056.2070208@netconfcentral.com> References: <49849EA9.5090908@netconfcentral.com> <20090131.210512.120353109.mbj@tail-f.com> <4984B290.3080706@netconfcentral.com> <49854056.2070208@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, > >> >> Issue 5) The revision is optional in the file format, so I am > not > >> >> sure what value it has at all. Does that mean there > >> >> is no revision, or does it mean the user just felt > >> >> like leaving it out? > >> > > >> > Both, but maybe we should be more restrictive, i.e. say that if > the > >> > module has a revision stmt, then the filename SHOULD include the > >> > latest revision date? > >> > > >> > >> case 1) > >> > >> import A { prefix a; revision X; } > >> > >> - if A has no revision X, then the import MUST fail > >> (no module used for A) > >> - A is considered 'revision X' if and only if its highest valued > >> revision-date is X. > > > > I got a little confused. X is nonsense if it does not equal highest > valued revision-date, i.e, we should always import the most recent > module. So Why should we need 'revision X' in the statement? > > > > no. > > as modules get updated over time, it is important to > preserve pre-existing modules. Consider a module A that > imports a grouping from module B. The contents of A > do not change over time even if the grouping in B > does change over time. Import-by-revision allows > module A to 'freeze' its version of the grouping, > even if other modules import newer versions of B, > and the grouping has different contents in those > other modules. OK. So the most recent module does not obsolete its previous versions. I.e, all versions listed in most recent module's revision statement should be valid if Netconf agent can find all of them. When I write a new module B which would augment a grouping from module A, I do not have to augment the one in the newest module A. washam > > > washam > > Andy > > > > >> - A has no revision if it has no revision-stmts. > >> Any import of A requresting a specific version MUST fail > >> > >> case 2) > >> > >> import A ( prefix a; } > >> > >> - if A has revision-stmts (in each instance) > >> then the instance with the highest valued revision-date > >> SHOULD be used > >> > >> - if A does not have revision-stmts (in each instance) > >> then it is implementation-specific which instance > >> of module A is used > > > > > > > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Feb 1 05:25:05 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B84028C3C3; Sun, 1 Feb 2009 05:25:05 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D131428C3C3 for ; Sun, 1 Feb 2009 05:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 fhVKE4ImeZ9d for ; Sun, 1 Feb 2009 05:25:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5522A28E155 for ; Sun, 1 Feb 2009 05:09:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58A8EC0042; Sun, 1 Feb 2009 14:09:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JTS2QW+aoEBi; Sun, 1 Feb 2009 14:09:13 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70771C0002; Sun, 1 Feb 2009 14:09:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 248F291EC26; Sun, 1 Feb 2009 14:09:08 +0100 (CET) Date: Sun, 1 Feb 2009 14:09:08 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090201130908.GA18045@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group , Ladislav Lhotka References: <4984C6A6.6030904@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4984C6A6.6030904@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] 2 more data types (!) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, Jan 31, 2009 at 01:46:14PM -0800, Andy Bierman wrote: > I know this would be a significant change, > so it is OK if we handle it with extensions > until later. > > 1) qname > 2) xpath > > Both of these data types are special because of their content: > 1) the manager must provide xmlns decls for the YANG prefixes > 2) the agent must match xmlns decls to YANG namespaces > > The data type 'instance-identifier' is already covered, > but it would be on this special list as well. My idea was to add a typedef for a type called xpath to yang-types. Since an xpath type has already shown up in YANG modules, I suppose this is useful to have. I have not seen a qname in a YANG module yet but adding a definition of a qname type to yang-types should not be too difficult either. Or was your proposal to add these types to the builtin types? This would be a bigger surgery and it is not obvious why these types should be builtin types. Perhaps you can clarify what you wanted to propose. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Feb 1 09:03:09 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67803A67EC; Sun, 1 Feb 2009 09:03:09 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2607A3A68AB for ; Sun, 1 Feb 2009 09:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyacoFfY-a0j for ; Sun, 1 Feb 2009 09:03:07 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 625D63A689C for ; Sun, 1 Feb 2009 09:03:07 -0800 (PST) Received: (qmail 52251 invoked from network); 1 Feb 2009 17:02:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 1 Feb 2009 17:02:47 -0000 X-YMail-OSG: eH0y37UVM1nMfCRHEaiPkR9DzYHZKfW9X7feDroh5pIw8bnEixdwZbWWDm3Q2iqXx4nV0AfbjBZd.mDfDhcrE_NQN4httXgyp9U.UG4ap17HbUk.gafPAgJnZUaVVXjKz2f7B319PIfic8SzqceinG5p X-Yahoo-Newman-Property: ymail-3 Message-ID: <4985D5B6.30601@netconfcentral.com> Date: Sun, 01 Feb 2009 09:02:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group , Ladislav Lhotka References: <4984C6A6.6030904@netconfcentral.com> <20090201130908.GA18045@elstar.local> In-Reply-To: <20090201130908.GA18045@elstar.local> Subject: Re: [netmod] 2 more data 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Sat, Jan 31, 2009 at 01:46:14PM -0800, Andy Bierman wrote: > >> I know this would be a significant change, >> so it is OK if we handle it with extensions >> until later. >> >> 1) qname >> 2) xpath >> >> Both of these data types are special because of their content: >> 1) the manager must provide xmlns decls for the YANG prefixes >> 2) the agent must match xmlns decls to YANG namespaces >> >> The data type 'instance-identifier' is already covered, >> but it would be on this special list as well. > > My idea was to add a typedef for a type called xpath to yang-types. > Since an xpath type has already shown up in YANG modules, I suppose > this is useful to have. I have not seen a qname in a YANG module yet > but adding a definition of a qname type to yang-types should not be > too difficult either. > > Or was your proposal to add these types to the builtin types? This > would be a bigger surgery and it is not obvious why these types should > be builtin types. Perhaps you can clarify what you wanted to propose. > I was thinking built-in types, but I think the yang-types draft would be fine. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Feb 1 09:17:06 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D113A6874; Sun, 1 Feb 2009 09:17:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855EC28C102 for ; Sun, 1 Feb 2009 09:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS6axzDh-y-p for ; Sun, 1 Feb 2009 09:17:04 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id CA0A93A6874 for ; Sun, 1 Feb 2009 09:17:04 -0800 (PST) Received: (qmail 42796 invoked from network); 1 Feb 2009 17:16:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 1 Feb 2009 17:16:45 -0000 X-YMail-OSG: b9wjZ9cVM1kjilsIrmcsSPA223.ExG7u.F9buy6ofYJvQpoArU9YTxRk9IGvew3VDff30zZKjcYfIxAi2jfHcY24sZQiEEnVpsSC27ctRVp1tcjsDnVnqgPXsHPLzu.TYWFXOEAWe9gZN_DC77yap9bL X-Yahoo-Newman-Property: ymail-3 Message-ID: <4985D8FD.5060704@netconfcentral.com> Date: Sun, 01 Feb 2009 09:16:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: WashamFan References: <49849EA9.5090908@netconfcentral.com> <20090131.210512.120353109.mbj@tail-f.com> <4984B290.3080706@netconfcentral.com> <49854056.2070208@netconfcentral.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org WashamFan wrote: > Hi, >> >> >> Issue 5) The revision is optional in the file format, so I am >> not >> >> >> sure what value it has at all. Does that mean there >> >> >> is no revision, or does it mean the user just felt >> >> >> like leaving it out? >> >> > >> >> > Both, but maybe we should be more restrictive, i.e. say that if >> the >> >> > module has a revision stmt, then the filename SHOULD include the >> >> > latest revision date? >> >> > >> >> >> >> case 1) >> >> >> >> import A { prefix a; revision X; } >> >> >> >> - if A has no revision X, then the import MUST fail >> >> (no module used for A) >> >> - A is considered 'revision X' if and only if its highest valued >> >> revision-date is X. >> > >> > I got a little confused. X is nonsense if it does not equal highest >> valued revision-date, i.e, we should always import the most recent >> module. So Why should we need 'revision X' in the statement? >> > >> >> no. >> >> as modules get updated over time, it is important to >> preserve pre-existing modules. Consider a module A that >> imports a grouping from module B. The contents of A >> do not change over time even if the grouping in B >> does change over time. Import-by-revision allows >> module A to 'freeze' its version of the grouping, >> even if other modules import newer versions of B, >> and the grouping has different contents in those >> other modules. > > OK. So the most recent module does not obsolete its previous versions. I.e, all versions listed in most recent module's revision statement should be valid if Netconf agent can find all of them. When I write a new module B which would augment a grouping from module A, I do not have to augment the one in the newest module A. > You inadvertently brought up a different topic, which is the status-stmt (current, deprecated, obsolete). YANG guidelines have yet to be determined for this clause, as it relates to YANG versions and conformance. Also, groupings cannot be augmented. Two huge differences in the complexity of module management (between SMIv2 and YANG), stem from the reusable 'grouping', and the 'typedef', (which can refine other typedefs, not just built-in types). Groupings can contain 'uses' for other groupings, as well. In SMIv2, there can only be 2 modules involved in the 'definition skew'. In YANG, 2 becomes N. > washam Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Feb 1 11:59:12 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3C23A67AC; Sun, 1 Feb 2009 11:59:12 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A626E3A682B for ; Sun, 1 Feb 2009 11:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc7sr7W9ILPf for ; Sun, 1 Feb 2009 11:59:10 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D57E93A67AC for ; Sun, 1 Feb 2009 11:59:09 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6893976C50A; Sun, 1 Feb 2009 20:58:49 +0100 (CET) Date: Sun, 01 Feb 2009 20:58:48 +0100 (CET) Message-Id: <20090201.205848.243097138.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <4984D784.1090106@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] require-instance bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org WashamFan wrote: > Hi, > from last part of sec 9.9.6: > The following notification defines two leafrefs to refer to an > existing ifIndex: > > notification link-failure { > leaf if-name { > path "/interfaces/interface/name"; > } > leaf index { > path "/interfaces/interface[name = current()/../if-name]" > + "/ifIndex"; > } > } > > Washam: Seems "type leafdef{ ... }" was omitted. Fixed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Feb 1 18:13:36 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7C43A69CF; Sun, 1 Feb 2009 18:13:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC253A6B00 for ; Sun, 1 Feb 2009 18:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3AamHUL78km for ; Sun, 1 Feb 2009 18:13:34 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id DB2CA3A6AD6 for ; Sun, 1 Feb 2009 18:13:33 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEF00AKE25VUT80@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Mon, 02 Feb 2009 10:13:09 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEF0033J25USB20@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Mon, 02 Feb 2009 10:13:07 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 02 Feb 2009 10:13:06 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Mon, 02 Feb 2009 10:13:06 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <1233002354.12696.15.camel@missotis> References: <1233002354.12696.15.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, > > if I understand the new draft -03 correctly, augment is now allowed only > at (sub)module top level and inside uses-stmt. However: > 1. augment remained in the tables of substatements (container, > leaf, ...) > 2. Sec. 7.15 says: The "augment" statement allows a module or > submodule > to add to the schema tree defined in another module or submodule. > This omits the uses-augment-stmt case. I think the latter > should really be renamed, so how about "amend"? > > Question: Can the target node for the top-level augment be inside a > grouping in the foreign module? >From 2nd sentence in para 1 in sec 7.15 : "The argument is a string which identifies a node in the schema tree. This node is called the augment's target node." I don't think node inside a grouping is in the schema tree. So no IMO. washam > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Feb 1 23:46:48 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B99B3A68A5; Sun, 1 Feb 2009 23:46:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C033A68BF for ; Sun, 1 Feb 2009 23:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCUlyh7nuhUa for ; Sun, 1 Feb 2009 23:46:45 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4620E3A68A5 for ; Sun, 1 Feb 2009 23:46:41 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 50084D800C0; Mon, 2 Feb 2009 08:46:20 +0100 (CET) From: Ladislav Lhotka To: WashamFan In-Reply-To: References: <1233002354.12696.15.camel@missotis> Organization: CESNET Date: Mon, 02 Feb 2009 08:46:19 +0100 Message-Id: <1233560779.7030.57.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org V2FzaGFtRmFuIHDDrcWhZSB2IFBvIDAyLiAwMi4gMjAwOSB2IDEwOjEzICswODAwOgo+IEhpLAo+ ID4gIAo+ID4gIGlmIEkgdW5kZXJzdGFuZCB0aGUgbmV3IGRyYWZ0IC0wMyBjb3JyZWN0bHksIGF1 Z21lbnQgaXMgbm93IGFsbG93ZWQgb25seQo+ID4gIGF0IChzdWIpbW9kdWxlIHRvcCBsZXZlbCBh bmQgaW5zaWRlIHVzZXMtc3RtdC4gSG93ZXZlcjoKPiA+ICAxLiBhdWdtZW50IHJlbWFpbmVkIGlu IHRoZSB0YWJsZXMgb2Ygc3Vic3RhdGVtZW50cyAoY29udGFpbmVyLCAKPiA+ICAgICBsZWFmLCAu Li4pCj4gPiAgMi4gU2VjLiA3LjE1IHNheXM6IFRoZSAiYXVnbWVudCIgc3RhdGVtZW50IGFsbG93 cyBhIG1vZHVsZSBvciAKPiA+IHN1Ym1vZHVsZSAKPiA+ICAgICB0byBhZGQgdG8gdGhlIHNjaGVt YSB0cmVlIGRlZmluZWQgaW4gYW5vdGhlciBtb2R1bGUgb3Igc3VibW9kdWxlLgo+ID4gICAgIFRo aXMgb21pdHMgdGhlIHVzZXMtYXVnbWVudC1zdG10IGNhc2UuIEkgdGhpbmsgdGhlIGxhdHRlciAK PiA+ICAgICBzaG91bGQgcmVhbGx5IGJlIHJlbmFtZWQsIHNvIGhvdyBhYm91dCAiYW1lbmQiPwo+ ID4gIAo+ID4gIFF1ZXN0aW9uOiBDYW4gdGhlIHRhcmdldCBub2RlIGZvciB0aGUgdG9wLWxldmVs IGF1Z21lbnQgYmUgaW5zaWRlIGEKPiA+ICBncm91cGluZyBpbiB0aGUgZm9yZWlnbiBtb2R1bGU/ Cj4gCj4gRnJvbSAybmQgc2VudGVuY2UgaW4gcGFyYSAxIGluIHNlYyA3LjE1IDoKPiAiVGhlIGFy Z3VtZW50IGlzIGEgc3RyaW5nIHdoaWNoIGlkZW50aWZpZXMgYSBub2RlIGluIHRoZSBzY2hlbWEg dHJlZS4gIFRoaXMgbm9kZSBpcyBjYWxsZWQgdGhlIGF1Z21lbnQncyB0YXJnZXQgbm9kZS4iCj4g SSBkb24ndCB0aGluayBub2RlIGluc2lkZSBhIGdyb3VwaW5nIGlzIGluIHRoZSBzY2hlbWEgdHJl ZS4gU28gbm8gSU1PLgoKVGhlIG5vdGlvbiBvZiAic2NoZW1hIHRyZWUiIHNob3VsZCBiZSBzcGVj aWZpZWQgbW9yZSBjbGVhcmx5IGluIHRoZQpkcmFmdC4gSW50dWl0aXZlbHksIGZyb20gdGhlIHBv aW50IG9mIHZpZXcgb2YgWE1MIHNjaGVtYSBsYW5ndWFnZXMsCllBTkcgbW9kdWxlID09IHNjaGVt YSBhbmQgc28gZ3JvdXBpbmcgbm9kZXMgYmVsb25nIHRvIGl0cyB0cmVlLgoKVGhlIGZvbGxvd2lu ZyAob3Igc2ltaWxhcikgY2hhbmdlcyBjb3VsZCBoZWxwIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVu Y2U6CgpTZWMuIDM6CgpvICBzY2hlbWEgdHJlZTogVGhlIGRlZmluaXRpb24gaGllcmFyY2h5IHNw ZWNpZmllZCB3aXRoaW4gYSBtb2R1bGUuCgpzaG91bGQgYmUKCm8gIHNjaGVtYSB0cmVlOiBUaGUg ZGVmaW5pdGlvbiBoaWVyYXJjaHkgc3BlY2lmaWVkIHdpdGhpbiBhIG1vZHVsZSwKZXhjZXB0IHRo ZSBjb250ZW50cyBvZiBncm91cGluZ3MuCgpTZWMuIDcuNToKClRoZSAiY29udGFpbmVyIiBzdGF0 ZW1lbnQgaXMgdXNlZCB0byBkZWZpbmUgYW4gaW50ZXJpb3Igbm9kZSBpbiB0aGUKc2NoZW1hIHRy ZWUuCgpzaG91bGQgYmUKClRoZSAiY29udGFpbmVyIiBzdGF0ZW1lbnQgaXMgdXNlZCB0byBkZWZp bmUgYW4gaW50ZXJpb3Igbm9kZSBpbiB0aGUKc2NoZW1hIHRyZWUgb3IgaW4gYSBncm91cGluZy4K CihBbmQgc2ltaWxhcmx5IGZvciBhbGwgb3RoZXIgZGF0YSBkZWZpbml0aW9uIHN0YXRlbWVudHMu KQoKU2VjLiA3LjExCgpUaGUgZ3JvdXBpbmcgc3RhdGVtZW50IGlzIG5vdCBhIGRhdGEgZGVmaW5p dGlvbiBzdGF0ZW1lbnQgYW5kLCBhcyBzdWNoLApkb2VzIG5vdCBkZWZpbmUgYW55IG5vZGVzIGlu IHRoZSBzY2hlbWEgdHJlZS4KCnNob3VsZCBiZQoKVGhlIGdyb3VwaW5nIHN0YXRlbWVudCBkb2Vz IG5vdCBkZWZpbmUgYW55IG5vZGVzIGluIHRoZSBzY2hlbWEgdHJlZS4gVGhlCmRhdGEgbm9kZXMg ZGVmaW5lZCBpbnNpZGUgdGhpcyBzdGF0ZW1lbnQgYXJlIG5vdCBjb250cmlidXRlZCB0byB0aGUg ZGF0YQp0cmVlIHVudGlsIHRoZSBncm91cGluZyBpcyBhcHBsaWVkIHZpYSB0aGUgInVzZXMiIHN0 YXRlbWVudC4gVGhlCmlkZW50aWZpZXJzIG9mIGRhdGEgbm9kZXMgZGVmaW5lZCBpbnNpZGUgYSBn cm91cGluZyBhbHNvIGRvIG5vdCBiZWxvbmcKdG8gYW55IG5hbWVzcGFjZSBhbmQgTVVTVCBOT1Qg dXNlIGFueSBuYW1lc3BhY2UgcHJlZml4IC0gdGhleSBhZG9wdCB0aGUKbmFtZXNwYWNlIG9mIHRo ZSBZQU5HIG1vZHVsZSB3aGVyZSB0aGUgZ3JvdXBpbmcgaXMgdXNlZC4KCkxhZGEKCj4gCj4gd2Fz aGFtCj4gCj4gPiAgTGFkYQo+ID4gIAo+ID4gIC0tIAo+ID4gIExhZGlzbGF2IExob3RrYSwgQ0VT TkVUCj4gPiAgUEdQIEtleSBJRDogRTc0RThDMEMKPiA+ICAKPiA+ICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gIG5ldG1vZCBtYWlsaW5nIGxpc3QK PiA+ICBuZXRtb2RAaWV0Zi5vcmcKPiA+ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo+ID4gIAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJ RDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Feb 2 00:37:26 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1FB3A689A; Mon, 2 Feb 2009 00:37:25 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DC93A69AB for ; Mon, 2 Feb 2009 00:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My6Cg3iDOqX7 for ; Mon, 2 Feb 2009 00:37:23 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9A5303A6816 for ; Mon, 2 Feb 2009 00:37:23 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C4CF676C516; Mon, 2 Feb 2009 09:37:03 +0100 (CET) Date: Mon, 02 Feb 2009 09:37:03 +0100 (CET) Message-Id: <20090202.093703.222249143.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20090131.210512.120353109.mbj@tail-f.com> References: <49849EA9.5090908@netconfcentral.com> <20090131.210512.120353109.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > > Issue 3) The '.' char is allowed in module-or-submodule-name, > > so it should not be used as a separator in this file format. > > Some operating systems may not like multiple '.' chars > > in the filename either. Maybe underscore '_' would be better. > > And some OSs use 8+3 filenames. I suggest changing the first '.' to '_'. This won't work either, of course, since underscore is also allowed in a module name. But is this really a problem? The filename SHOULD (not MUST) be on this form, but if you use a OS which supports 8+3 characters (or whatever other restriction) then your filenames will not be in this form. The one time a tool might be confused is if your module is called something like 'FOO.2008-04-01' which does not have any revision statements, and you also have a module called 'FOO' with latest revision '2008-04-01'. Both these modules would be stored as "FOO.2008-04-01.yang". /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 05:45:47 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADF828C210; Mon, 2 Feb 2009 05:45:47 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEF228C211 for ; Mon, 2 Feb 2009 05:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 LvGZdFKExl5j for ; Mon, 2 Feb 2009 05:45:45 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 7BE6D28C210 for ; Mon, 2 Feb 2009 05:45:44 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSYb45klGWOgqZ1sPbeyikTzdF29bAJNv@postini.com; Mon, 02 Feb 2009 05:45:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 2 Feb 2009 05:43:40 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 05:43:40 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 05:43:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 05:42:58 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n12DgwM95253; Mon, 2 Feb 2009 05:42:58 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n12DajHW055889; Mon, 2 Feb 2009 13:36:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902021336.n12DajHW055889@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090131.210512.120353109.mbj@tail-f.com> Date: Mon, 2 Feb 2009 08:36:45 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Feb 2009 13:42:58.0949 (UTC) FILETIME=[2904EB50:01C9853C] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >> Issue 3) The '.' char is allowed in module-or-submodule-name, >> so it should not be used as a separator in this file format. "_" is also allowed. I don't see the point. >> Some operating systems may not like multiple '.' chars >> in the filename either. Maybe underscore '_' would be better. > >And some OSs use 8+3 filenames. I suggest changing the first '.' to '_'. Are we trying to be DOS compatible? Do we need to support OSs that lack subdirectory support, or boot from floopy disks? Specific OSs with issues like this need individual solutions that are outside of our scope. I vote to stick with one separator, the period, rather than mixing two. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 06:15:00 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404A13A677E; Mon, 2 Feb 2009 06:15:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8208E3A677E for ; Mon, 2 Feb 2009 06:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os4Sc+a832vf for ; Mon, 2 Feb 2009 06:14:55 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C6AE93A69E0 for ; Mon, 2 Feb 2009 06:14:55 -0800 (PST) Received: (qmail 11416 invoked from network); 2 Feb 2009 14:14:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Feb 2009 14:14:36 -0000 X-YMail-OSG: VeX9wvcVM1kBVic__fk3t8LluhcfcGjl3BjWBDKhXKYtl.B5x8eAr1494gkLHvPEMwWq_J.1ZS2Ozc6eO22s3CVSZ9TsJ7JEJ3ON3lS1XLHnd_0MHeqTWuh08SabulqOuRMzr3WTTdD8vl1.jWgT22g2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4986FFCA.4090307@netconfcentral.com> Date: Mon, 02 Feb 2009 06:14:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902021336.n12DajHW055889@idle.juniper.net> In-Reply-To: <200902021336.n12DajHW055889@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >>> Issue 3) The '.' char is allowed in module-or-submodule-name, >>> so it should not be used as a separator in this file format. > > "_" is also allowed. I don't see the point. > >>> Some operating systems may not like multiple '.' chars >>> in the filename either. Maybe underscore '_' would be better. >> And some OSs use 8+3 filenames. I suggest changing the first '.' to '_'. > > Are we trying to be DOS compatible? Do we need to support OSs that > lack subdirectory support, or boot from floopy disks? Specific OSs > with issues like this need individual solutions that are outside > of our scope. I vote to stick with one separator, the period, > rather than mixing two. > I want to know why this section exists in normative text at all. It should be moved to a non-normative appendix, and made clear that it is not part of the standard. Either that, or tackle the problem of universally acceptable file naming conventions as a standard. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 07:05:48 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164C43A6A1A; Mon, 2 Feb 2009 07:05:48 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FF228C23A for ; Mon, 2 Feb 2009 07:05:46 -0800 (PST) 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.051, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLJ2KbPmbVuP for ; Mon, 2 Feb 2009 07:05:45 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id B55053A6A1A for ; Mon, 2 Feb 2009 07:05:45 -0800 (PST) Received: (qmail 59262 invoked from network); 2 Feb 2009 15:05:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Feb 2009 15:05:25 -0000 X-YMail-OSG: 7Oa7GzgVM1knNpJnzCa7NUIkQQ7jE39pN9atyLqqMpGo8fnxzH8_MK4Lc1OMPsJXVg5Q3PG55410_zPcNs86GDnmtzaohdpO_aG2hhb9eLxCsCdmfI_pwLAvoXAqym8.FevxaSimEnp_oCa0B5lu4F9a X-Yahoo-Newman-Property: ymail-3 Message-ID: <49870BB3.5030404@netconfcentral.com> Date: Mon, 02 Feb 2009 07:05:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, This section on 'payload parsing' (8.3.1) contains some normative restrictions of NETCONF protocol usage which do not belong in this spec. o Leaf data values MUST match the type constraints for those leafs, including those defined in the type's range, length, and pattern properties. o Key data MUST be present for all list instances. o Only data for a single case MUST be present for any choices. Already covered by NETCONF invalid-value. No value added by NETMOD here. o Data for nodes tagged with "if-feature" MUST NOT be present if the feature is not supported by the device. Why? What if the agent supports some, but not all of the feature objects, so it cannot advertise it? Why forbid a manager from sending any request it wants? It is up to each individual agent to answer, and existing NETCONF error codes are sufficient to address the problem. BTW, just because an agent advertises a feature does not mean the manager can assume anything about the success of any individual . o Data for nodes tagged with "when" MUST NOT be present if the condition does not evaluate to "true". Again, why? The agent will send the appropriate error for any PDU it does not support. o For insert handling, the value for the attributes "before" and "after" MUST be valid for the type of the appropriate key leafs. o The attributes "before" and "after" MUST NOT appear for lists whose "ordered-by" property is "system". This is backwards. The YANG spec just needs to specify what an agent does if these conditions occur (invalid-value or operation-failed?) Section 8.3.2 is completely redundant (covered by NETCONF), except for bullet 3 which is under-specified. Which error-tag is returned? Better yet, which sub-section (13.5?) contains the normative error handling behavior? Also bullet 4 is a problem: o If the NETCONF operation modifies a data node such that any node's "when" expression becomes false, then that node is deleted by the server. I strongly object to this AUTOMATIC DELETION 'server behavior' slipped into this section. This issue needs more discussion and WG consensus. The idea that changing the value of knob X is going to silently and automatically delete portions of the config is going to (appropriately) be a concern to operators. All it takes is 1 mistake, setting knob X to a 'wrong value', and big chunks of config just vanish? That's not a feature, IMO. All deletes (except 'choice' subtrees) MUST be explicitly requested by the operator. IMO, the 'when' statement is just a hint to applications. The server just needs to implement it correctly (like 'must'). Therefore, the first paragraph of 8.2 is a problem: 8.2. Hierarchy of Constraints Conditions on parent nodes affect constraints on child nodes as a natural consequence of the hierarchy of nodes. "must" and "mandatory" constraints are not enforced if the parent node has a "when" or "if- feature" property that is not satisfied on the current device. This should say that 'must' and 'mandatory' are enforced if the parent exists. The 'when' and 'if-feature' statements should not be coupled to these other constraints. If implemented correctly, and the XPath is correct, then these nodes will not exist. But if the node does exist, then 'must' and 'mandatory' need to be enforced. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 07:24:39 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D7C3A680E; Mon, 2 Feb 2009 07:24:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726DC3A680E for ; Mon, 2 Feb 2009 07:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 VEVHX56pR84J for ; Mon, 2 Feb 2009 07:24:37 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E6B713A6A13 for ; Mon, 2 Feb 2009 07:24:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSYcQIN3LabrmNT/h/Dqi1jZzgoB89IGJ@postini.com; Mon, 02 Feb 2009 07:24:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 2 Feb 2009 07:13:09 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 07:13:06 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 07:13:02 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 07:10:42 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n12FAeM43498; Mon, 2 Feb 2009 07:10:41 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n12F4RPh060651; Mon, 2 Feb 2009 15:04:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902021504.n12F4RPh060651@idle.juniper.net> To: Andy Bierman In-Reply-To: <4986FFCA.4090307@netconfcentral.com> Date: Mon, 2 Feb 2009 10:04:27 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Feb 2009 15:10:42.0818 (UTC) FILETIME=[6A879620:01C98548] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I want to know why this section exists in normative text at all. >It should be moved to a non-normative appendix, and made clear >that it is not part of the standard. IIRC someone at the interim wanted to have concrete recommendations for file naming so 15 different tool sets didn't use 15 different conventions. This was done in the spirit of interoperability. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 07:39:12 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C9E3A6896; Mon, 2 Feb 2009 07:39:12 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CE03A6B36 for ; Mon, 2 Feb 2009 07:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, 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 bNBNKZWh2PhS for ; Mon, 2 Feb 2009 07:39:10 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 698233A6A36 for ; Mon, 2 Feb 2009 07:39:10 -0800 (PST) Received: (qmail 98242 invoked from network); 2 Feb 2009 15:38:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Feb 2009 15:38:51 -0000 X-YMail-OSG: _9vSRnEVM1lKxy9ZPkQda7WLDyB7hHnIpTYN3A06MWE4lnk.l0RVoCRHeNdkUonc7vVc1MYDvRUo00N0ThpoBqdZoNHBBNV7v0M9QvsqNg5NAmbJ0a2zGHhlaIalBGb5VzEr.2_cYoOt8AZIYWE713.w X-Yahoo-Newman-Property: ymail-3 Message-ID: <49871389.6090600@netconfcentral.com> Date: Mon, 02 Feb 2009 07:38:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, From 9.13, para 2: The syntax for an instance-identifier is a subset of the XPath syntax, which is used to uniquely identify a node in the data tree. It is an absolute XPath location path in abbreviated syntax, where axes are not permitted, and predicates are used only for specifying the values for the key nodes for list entries, or a value of a leaf- list. This text is correct. From 9.13, para 4: The syntax is formally defined by the rule "absolute-instid" in Section 12. This text is not correct. The rule 'instance-identifier-str' in the ABNF defines the syntax. The ABNF in sec. 12 is not correct: instance-identifier-str = < a string which matches the rule instance-identifier > instance-identifier = absolute-instid / relative-instid absolute-instid = 1*("/" (node-identifier *predicate)) relative-instid = descendant-instid / (("." / "..") "/" *relative-instid) descendant-instid = node-identifier *predicate absolute-instid predicate = "[" *WSP predicate-expr *WSP "]" predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) Relative instance-identifiers do not make any sense. The whole point of this exercise is to have a context-free NETCONF database node identifier. The text in 9.13, para 2 says this is an absolute instance-identifier. Corrected ABNF: instance-identifier-str = < a string which matches the rule instance-identifier > instance-identifier = absolute-instid absolute-instid = 1*("/" (node-identifier *predicate)) predicate = "[" *WSP predicate-expr *WSP "]" predicate-expr = node-identifier *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) (BTW, please add some indentation to the ABNF, instead of starting on column 1). Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 07:43:20 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FD93A689F; Mon, 2 Feb 2009 07:43:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D97B3A6863 for ; Mon, 2 Feb 2009 07:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, 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 90mi+60kKeht for ; Mon, 2 Feb 2009 07:43:15 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 9D5A63A6B71 for ; Mon, 2 Feb 2009 07:42:13 -0800 (PST) Received: (qmail 13404 invoked from network); 2 Feb 2009 15:41:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 2 Feb 2009 15:41:53 -0000 X-YMail-OSG: PR9at1YVM1lOw7knAmWLnTC_UoPrIPkrsSIpr7Lrrm3gjqCyVU.t0raxKy7H.k7iClWxyNmv_cgnp27Vuw6CDbp5fIu1wZH.nmQhRMIwhDbSZ83xzIGj8HdjBNvzObi14VEaXv7qsbVzCYvg5q9tGmoS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4987143F.1090000@netconfcentral.com> Date: Mon, 02 Feb 2009 07:41:51 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902021504.n12F4RPh060651@idle.juniper.net> In-Reply-To: <200902021504.n12F4RPh060651@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I want to know why this section exists in normative text at all. >> It should be moved to a non-normative appendix, and made clear >> that it is not part of the standard. > > IIRC someone at the interim wanted to have concrete recommendations > for file naming so 15 different tool sets didn't use 15 different > conventions. This was done in the spirit of interoperability. > Fine. It still needs to be in the proper standards-track RFC section. Since these are guidelines, they MUST go in a separate BCP document or in a non-normative appendix of this document. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 07:47:45 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E143A68F8; Mon, 2 Feb 2009 07:47:45 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A889B3A6A34 for ; Mon, 2 Feb 2009 07:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCxGMm852G7A for ; Mon, 2 Feb 2009 07:47:43 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 1693D28C234 for ; Mon, 2 Feb 2009 07:46:53 -0800 (PST) Received: (qmail 6878 invoked from network); 2 Feb 2009 15:46:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 2 Feb 2009 15:46:33 -0000 X-YMail-OSG: G5odESgVM1lsSP4vubMY8pS5IhNQQ4Aqlu6JkGUO0t9kNf6De9QpsBOnXu1byVtb0sWuXO65G6_VlGsat6pR8_tTTQld._TMRcdV1LXoHNsKwiwS_e_Y50Hy5d60zfNhI2SoPuhKaJnPP0.J115_8iiE X-Yahoo-Newman-Property: ymail-3 Message-ID: <49871558.5040100@netconfcentral.com> Date: Mon, 02 Feb 2009 07:46:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group References: <49871389.6090600@netconfcentral.com> In-Reply-To: <49871389.6090600@netconfcentral.com> Subject: Re: [netmod] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org .... > Corrected ABNF: > > instance-identifier-str > = < a string which matches the rule > instance-identifier > > > instance-identifier = absolute-instid > > absolute-instid = 1*("/" (node-identifier *predicate)) > > > predicate = "[" *WSP predicate-expr *WSP "]" > > predicate-expr = node-identifier *WSP "=" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) > I took out '.' by mistake. It is needed for a leaf-list instance-identifier. predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) The old 'predicate-expr' was correct. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 08:11:31 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475C73A69F8; Mon, 2 Feb 2009 08:11:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95A13A6990 for ; Mon, 2 Feb 2009 08:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 yHCrQoqtzvy7 for ; Mon, 2 Feb 2009 08:11:27 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 1E52A28C10C for ; Mon, 2 Feb 2009 08:11:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSYcbE/RaKxBG1itFwjM3ykPZrYGgmoSS@postini.com; Mon, 02 Feb 2009 08:11:08 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Mon, 2 Feb 2009 08:04:41 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 08:04:39 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 08:04:38 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 08:04:18 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n12G4HM86267; Mon, 2 Feb 2009 08:04:17 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n12Fw4ej063537; Mon, 2 Feb 2009 15:58:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902021558.n12Fw4ej063537@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090202.093703.222249143.mbj@tail-f.com> Date: Mon, 2 Feb 2009 10:58:04 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Feb 2009 16:04:18.0266 (UTC) FILETIME=[E71603A0:01C9854F] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >The one time a tool might be confused is if your module is called >something like 'FOO.2008-04-01' which does not have any revision >statements, and you also have a module called 'FOO' with latest >revision '2008-04-01'. Both these modules would be stored as >"FOO.2008-04-01.yang". Should we say something about what to do in this case (modules with no revision statement)? "Use '0' as the revision string"? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 12:27:43 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626DF3A6825; Mon, 2 Feb 2009 12:27:43 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865E23A6825 for ; Mon, 2 Feb 2009 12:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.197, 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 AoX6fNh8ChfT for ; Mon, 2 Feb 2009 12:27:41 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 189BB3A6933 for ; Mon, 2 Feb 2009 12:27:40 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id B5ie1b00a0SCNGk598TNuG; Mon, 02 Feb 2009 20:27:22 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id B8TN1b00G0UQ6dC3V8TNyP; Mon, 02 Feb 2009 20:27:22 +0000 From: "David Harrington" To: Date: Mon, 2 Feb 2009 15:27:21 -0500 Message-ID: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03A1_01C9854A.BDD35E70" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmFbWifuVHcjq6sQ+mkDUYIbhMMIAABg8kQ Subject: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_03A1_01C9854A.BDD35E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03A2_01C9854A.BDD81960" ------=_NextPart_001_03A2_01C9854A.BDD81960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Thought I would point out that there is a YAM BOF being consdiered for ietf74 (see http://trac.tools.ietf.org/bof/trac/wiki/YamCharter) If you want to call YANG models YAMs, you probably should move to protect the acronym from other IETF usage. You will probably need to demonstrate a WG consensus to adopt that term for YANG models. Personally, i think anything based on "yet another" is likely to continually hit conflicts. I think for the users of yang models, who probably already have experience in SMI MIBs, it will be apparent what a YANG MIB would be - a management information base written using YANG. YMMV dbh _____ From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Lisa Dusseault Sent: Monday, February 02, 2009 1:45 PM To: Lisa Dusseault's Chairs; Apps Discuss Subject: Lisa's Apps area Activity Report for Jan 2009 News, Updates Quite a few BOFs getting requested for the next meeting, see http://trac.tools.ietf.org/bof/trac/wiki for more details on each: - OAUTH - charter revised recently on list - YAM, BOF on advancing core email standards - MMOX, BOF on Massive Multiplayer Online Interactions - XMPP, revising base specs and doing some transport and security stuff - Interest in other HTTP topics: Cookies, Origin header -- not sure if there will be a BOF around this The BOF approval call is Feb 5 and scheduling of these BOFs will happen after that. Document Status and Progress Active documents, my action: Active documents, waiting on other: - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - drat-montemurro-gsma-imei-urn (Exp): Waiting on revision from authors - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt review - draft-ietf-usefor-usepro (PS): Waiting for last WG issue to get resolved - draft-ietf-calsify-2446bis (PS): Waiting for a revision - draft-ietf-calsify-rfc2445bis (PS): Waiting for a revision - draft-snell-atompub-bidi (PS): Waiting for a revision - draft-wilde-sms-uri (PS): Waiting for a revision Finished processing -- new in RFC Ed queue and new RFCs - draft-melnikov-sieve-imapext-metadata (PS): approved, announcement sent - draft-freed-sieve-ihave (PS): In RFC Ed queue - draft-ietf-sieve-managesieve (PS): In RFC Ed queue - draft-kucherawy-sender-auth-header (PS): In RFC Ed queue WG Status ALTO, HTTPBIS, IDNABIS and SIEVE are meeting in SF / IETF74 ALTO: mostly quiet CALSIFY: Working through open issues HTTPBIS: Interesting issues and great discussion on "Origin" header or other fix/replacement to "Referer" header IDNABIS: Great discussion on goals and tradeoffs e.g. simplicity and invariability of assignments SIEVE: Published several documents and pushing more through USEFOR: Prompted the WG last week to close their last one or two issues, to finish their last doc --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. ------=_NextPart_001_03A2_01C9854A.BDD81960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Thought I would point out that there is a YAM = BOF being=20 consdiered for ietf74 (see http://trac.= tools.ietf.org/bof/trac/wiki/YamCharter)
 
If you want to call YANG models YAMs, you = probably=20 should move to protect the acronym from other IETF usage. You will = probably need=20 to demonstrate a WG consensus to adopt that term for YANG=20 models.
 
Personally, i think anything based on "yet = another" is=20 likely to continually hit conflicts.
I think for the users of yang models, who = probably=20 already have experience in SMI MIBs, it will be apparent what a YANG MIB = would=20 be - a management information base written using YANG. = YMMV
 
dbh

From: apps-discuss-bounces@ietf.org=20 [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Lisa=20 Dusseault
Sent: Monday, February 02, 2009 1:45 = PM
To: Lisa=20 Dusseault's Chairs; Apps Discuss
Subject: Lisa's Apps area = Activity=20 Report for Jan 2009


News, Updates
Quite a few BOFs getting requested for the next meeting, = see http://trac.tools.ietf.= org/bof/trac/wiki=20 for more details on each:
 - OAUTH - charter revised recently on list
 - YAM, BOF on advancing core email standards
 - MMOX, BOF on Massive Multiplayer Online Interactions
 - XMPP, revising base specs and doing some transport and = security=20 stuff
 - Interest in other HTTP topics: Cookies, Origin header -- = not sure=20 if there will be a BOF around this

The BOF approval call is Feb 5 and scheduling of these BOFs will = happen=20 after that.


Document Status and Progress
Active documents, my action:

Active documents, waiting on other:
 - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing = shepherd=20 review and writeup
 - drat-montemurro-gsma-imei-urn (Exp): Waiting on revision = from=20 authors
 - draft-ietf-sieve-mime-loop (PS): Waiting on authors to = respond to=20 GenArt review
 - draft-ietf-usefor-usepro (PS): Waiting for last WG issue to = get=20 resolved
 - draft-ietf-calsify-2446bis (PS): Waiting for a = revision
 - draft-ietf-calsify-rfc2445bis (PS): Waiting for a=20 revision
 - draft-snell-atompub-bidi (PS): Waiting for a = revision
 - draft-wilde-sms-uri (PS): Waiting for a revision

Finished processing -- new in RFC Ed queue and new RFCs
 - draft-melnikov-sieve-imapext-metadata (PS): approved,=20 announcement sent
 - draft-freed-sieve-ihave (PS): In RFC Ed queue
 - draft-ietf-sieve-managesieve (PS): In RFC Ed = queue
 - draft-kucherawy-sender-auth-header (PS): In RFC Ed = queue

WG Status

ALTO, HTTPBIS, IDNABIS and SIEVE are meeting in SF / IETF74

ALTO: mostly quiet 
CALSIFY: Working through open issues
HTTPBIS: Interesting issues and great discussion on "Origin" header = or=20 other fix/replacement to "Referer" header
IDNABIS: Great discussion on goals and tradeoffs = e.g. simplicity and=20 invariability of assignments
SIEVE: Published several documents and pushing more through
USEFOR: Prompted the WG last week to close their last one or two = issues, to=20 finish their last doc
--- Scanned by M+ Guardian Messaging Firewall = ---=20 Messaging Architects sponsors The Spamhaus Project. ------=_NextPart_001_03A2_01C9854A.BDD81960-- ------=_NextPart_000_03A1_01C9854A.BDD35E70 Content-Type: text/plain; name="ATT00907.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00907.txt" _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_03A1_01C9854A.BDD35E70 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_03A1_01C9854A.BDD35E70-- From netmod-bounces@ietf.org Mon Feb 2 18:19:28 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0433A67EF; Mon, 2 Feb 2009 18:19:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308A43A696E for ; Mon, 2 Feb 2009 18:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAWYgeAugrLk for ; Mon, 2 Feb 2009 18:19:26 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 25CC33A67EF for ; Mon, 2 Feb 2009 18:19:25 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEG007R6X3QMS00@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Tue, 03 Feb 2009 10:19:04 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEG00F0DX3O8900@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Tue, 03 Feb 2009 10:19:02 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 03 Feb 2009 10:19:00 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 03 Feb 2009 10:19:00 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49870BB3.5030404@netconfcentral.com> References: <49870BB3.5030404@netconfcentral.com> Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, > > This section on 'payload parsing' (8.3.1) contains some normative > restrictions of NETCONF protocol usage which do not belong in this spec. > > > o Leaf data values MUST match the type constraints for those leafs, > including those defined in the type's range, length, and pattern > properties. > > o Key data MUST be present for all list instances. > > o Only data for a single case MUST be present for any choices. > > Already covered by NETCONF invalid-value. > No value added by NETMOD here. > > > o Data for nodes tagged with "if-feature" MUST NOT be present if > the > feature is not supported by the device. > > Why? > What if the agent supports some, but not all of > the feature objects, so it cannot advertise it? > Why forbid a manager from sending any request it wants? > It is up to each individual agent to answer, and > existing NETCONF error codes are sufficient to address > the problem. BTW, just because an agent advertises > a feature does not mean the manager can assume > anything about the success of any individual . > > > o Data for nodes tagged with "when" MUST NOT be present if the > condition does not evaluate to "true". > > Again, why? > The agent will send the appropriate error for > any PDU it does not support. I think we should spell out what agents should react if operators have sent such *bad* requests, an error returned or session closed? What does "MUST NOT" here exactly mean? > Therefore, the first paragraph of 8.2 is a problem: > > 8.2. Hierarchy of Constraints > > Conditions on parent nodes affect constraints on child nodes as a > natural consequence of the hierarchy of nodes. "must" and "mandatory" > constraints are not enforced if the parent node has a "when" or "if- > feature" property that is not satisfied on the current device. > > > This should say that 'must' and 'mandatory' are enforced if the > parent exists. The 'when' and 'if-feature' statements should not > be coupled to these other constraints. If implemented correctly, > and the XPath is correct, then these nodes will not exist. > But if the node does exist, then 'must' and 'mandatory' > need to be enforced. Yes. That makes more sense. washam > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Feb 2 22:30:27 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9D63A6959; Mon, 2 Feb 2009 22:30:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFD73A6C0B for ; Mon, 2 Feb 2009 22:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.059, 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 CuMDgK4LiYT4 for ; Mon, 2 Feb 2009 22:30:26 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 7B61E3A6959 for ; Mon, 2 Feb 2009 22:30:24 -0800 (PST) Received: (qmail 60535 invoked from network); 3 Feb 2009 06:30:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 3 Feb 2009 06:30:04 -0000 X-YMail-OSG: epCVZ6UVM1lKk4f1kKELAEYJx0BU4ZMpKw9eqabgOS2Zy6p6U7lR3BXTlgGxkGrgNXv7FMeYP_ubAp1.LZ3YOPAF.OfxqJ0h8GC1JC17ZsZI1Q_0ebLPS94dNMa9nz0wJYwCrmCaODcU7byNSIsH5YkefYDFlb6qMoW0OYY9Eaz5H6FG7dEmOypL X-Yahoo-Newman-Property: ymail-3 Message-ID: <4987E46A.4080807@netconfcentral.com> Date: Mon, 02 Feb 2009 22:30:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Harrington References: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> In-Reply-To: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Harrington wrote: > Hi, > > Thought I would point out that there is a YAM BOF being consdiered for > ietf74 (see http://trac.tools.ietf.org/bof/trac/wiki/YamCharter) > > If you want to call YANG models YAMs, you probably should move to > protect the acronym from other IETF usage. You will probably need to > demonstrate a WG consensus to adopt that term for YANG models. > > Personally, i think anything based on "yet another" is likely to > continually hit conflicts. > I think for the users of yang models, who probably already have > experience in SMI MIBs, it will be apparent what a YANG MIB would be - a > management information base written using YANG. YMMV > The term 'YANG data model module or submodule' is verbose. Even 'YANG module or submodule' is verbose. Most of the time, the term 'module' is generic, but not close to all the time. I don't care what the acronym is. YAM does not stand for Yet Another Module. > dbh Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Feb 3 02:44:14 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718E828C15C; Tue, 3 Feb 2009 02:44:14 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4377828C15E for ; Tue, 3 Feb 2009 02:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, 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 y4Kqbk8g9+7s for ; Tue, 3 Feb 2009 02:44:12 -0800 (PST) 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 6A9E228C15C for ; Tue, 3 Feb 2009 02:44:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,371,1231131600"; d="scan'208,217";a="136260523" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Feb 2009 05:43:48 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Feb 2009 05:43:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 11:43:28 +0100 Message-ID: In-Reply-To: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009 thread-index: AcmFbWifuVHcjq6sQ+mkDUYIbhMMIAABg8kQAB4HkiA= References: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , Subject: Re: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122898107==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --===============2122898107== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C985EC.403D0433" This is a multi-part message in MIME format. ------_=_NextPart_001_01C985EC.403D0433 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Acronyms clashes have already happened in the past in the IETF. Of course, if they can be avoided it's better. If there was a published WG document that already uses the YAM acronyms I could point it to the IESG and IAB and try to prevent the clash using the prior usage argument. However there is none that I am aware about in NETMOD.=20 =20 Dan =20 PS - this led me looking at the status of the documents in NETMOD and it looks like you guys start accumulating delay relative to the charter milestones - but the chairs and the rest of the WG probably know it and are taking the appropriate measures - right?=20 ________________________________ From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of David Harrington Sent: Monday, February 02, 2009 10:27 PM To: netmod@ietf.org Subject: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009 =09 =09 Hi, =20 Thought I would point out that there is a YAM BOF being consdiered for ietf74 (see http://trac.tools.ietf.org/bof/trac/wiki/YamCharter) =20 If you want to call YANG models YAMs, you probably should move to protect the acronym from other IETF usage. You will probably need to demonstrate a WG consensus to adopt that term for YANG models. =20 Personally, i think anything based on "yet another" is likely to continually hit conflicts.=20 I think for the users of yang models, who probably already have experience in SMI MIBs, it will be apparent what a YANG MIB would be - a management information base written using YANG. YMMV =20 dbh ________________________________ From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Lisa Dusseault Sent: Monday, February 02, 2009 1:45 PM To: Lisa Dusseault's Chairs; Apps Discuss Subject: Lisa's Apps area Activity Report for Jan 2009 =09 =09 News, Updates Quite a few BOFs getting requested for the next meeting, see http://trac.tools.ietf.org/bof/trac/wiki for more details on each: - OAUTH - charter revised recently on list - YAM, BOF on advancing core email standards - MMOX, BOF on Massive Multiplayer Online Interactions - XMPP, revising base specs and doing some transport and security stuff - Interest in other HTTP topics: Cookies, Origin header -- not sure if there will be a BOF around this The BOF approval call is Feb 5 and scheduling of these BOFs will happen after that. Document Status and Progress Active documents, my action: Active documents, waiting on other: - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - drat-montemurro-gsma-imei-urn (Exp): Waiting on revision from authors - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt review - draft-ietf-usefor-usepro (PS): Waiting for last WG issue to get resolved - draft-ietf-calsify-2446bis (PS): Waiting for a revision - draft-ietf-calsify-rfc2445bis (PS): Waiting for a revision - draft-snell-atompub-bidi (PS): Waiting for a revision - draft-wilde-sms-uri (PS): Waiting for a revision Finished processing -- new in RFC Ed queue and new RFCs - draft-melnikov-sieve-imapext-metadata (PS): approved, announcement sent - draft-freed-sieve-ihave (PS): In RFC Ed queue - draft-ietf-sieve-managesieve (PS): In RFC Ed queue - draft-kucherawy-sender-auth-header (PS): In RFC Ed queue WG Status =09 ALTO, HTTPBIS, IDNABIS and SIEVE are meeting in SF / IETF74 ALTO: mostly quiet=20 CALSIFY: Working through open issues HTTPBIS: Interesting issues and great discussion on "Origin" header or other fix/replacement to "Referer" header IDNABIS: Great discussion on goals and tradeoffs e.g. simplicity and invariability of assignments SIEVE: Published several documents and pushing more through USEFOR: Prompted the WG last week to close their last one or two issues, to finish their last doc --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project.=20 ------_=_NextPart_001_01C985EC.403D0433 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Acronyms clashes have already happened in the past = in the=20 IETF. Of course, if they can be avoided it's better. If there was a = published WG=20 document that already uses the YAM acronyms I could point it to the IESG = and IAB=20 and try to prevent the clash using the prior usage argument. However = there is=20 none that I am aware about in NETMOD.
 
Dan
 
PS - this led me looking at the status of the documents in = NETMOD and it=20 looks like you guys start accumulating delay relative to the charter = milestones=20 - but the chairs and the rest of the WG probably know it and are taking = the=20 appropriate measures - right?

From: netmod-bounces@ietf.org=20 [mailto:netmod-bounces@ietf.org] On Behalf Of David=20 Harrington
Sent: Monday, February 02, 2009 10:27 = PM
To:=20 netmod@ietf.org
Subject: [netmod] FW: Lisa's Apps area = Activity=20 Report for Jan 2009

Hi,
 
Thought I would point out that there is a = YAM BOF=20 being consdiered for ietf74 (see http://trac.= tools.ietf.org/bof/trac/wiki/YamCharter)
 
If you want to call YANG models YAMs, you = probably=20 should move to protect the acronym from other IETF usage. You will = probably=20 need to demonstrate a WG consensus to adopt that term for YANG=20 models.
 
Personally, i think anything based on "yet = another"=20 is likely to continually hit conflicts.
I think for the users of yang models, who = probably=20 already have experience in SMI MIBs, it will be apparent what a YANG = MIB would=20 be - a management information base written using YANG.=20 YMMV
 
dbh

From: = apps-discuss-bounces@ietf.org=20 [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Lisa=20 Dusseault
Sent: Monday, February 02, 2009 1:45 = PM
To: Lisa=20 Dusseault's Chairs; Apps Discuss
Subject: Lisa's Apps area = Activity=20 Report for Jan 2009


News, Updates
Quite a few BOFs getting requested for the next meeting, = see http://trac.tools.ietf.= org/bof/trac/wiki=20 for more details on each:
 - OAUTH - charter revised recently on list
 - YAM, BOF on advancing core email standards
 - MMOX, BOF on Massive Multiplayer Online = Interactions
 - XMPP, revising base specs and doing some transport and = security=20 stuff
 - Interest in other HTTP topics: Cookies, Origin header -- = not sure=20 if there will be a BOF around this

The BOF approval call is Feb 5 and scheduling of these BOFs will = happen=20 after that.


Document Status and Progress
Active documents, my action:

Active documents, waiting on other:
 - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing = shepherd=20 review and writeup
 - drat-montemurro-gsma-imei-urn (Exp): Waiting on revision = from=20 authors
 - draft-ietf-sieve-mime-loop (PS): Waiting on authors to = respond to=20 GenArt review
 - draft-ietf-usefor-usepro (PS): Waiting for last WG issue = to get=20 resolved
 - draft-ietf-calsify-2446bis (PS): Waiting for a=20 revision
 - draft-ietf-calsify-rfc2445bis (PS): Waiting for a=20 revision
 - draft-snell-atompub-bidi (PS): Waiting for a = revision
 - draft-wilde-sms-uri (PS): Waiting for a = revision

Finished processing -- new in RFC Ed queue and new RFCs
 - draft-melnikov-sieve-imapext-metadata (PS): = approved,=20 announcement sent
 - draft-freed-sieve-ihave (PS): In RFC Ed queue
 - draft-ietf-sieve-managesieve (PS): In RFC Ed = queue
 - draft-kucherawy-sender-auth-header (PS): In RFC Ed=20 queue

WG Status

ALTO, HTTPBIS, IDNABIS and SIEVE are meeting in SF / IETF74

ALTO: mostly quiet 
CALSIFY: Working through open issues
HTTPBIS: Interesting issues and great discussion on "Origin" = header or=20 other fix/replacement to "Referer" header
IDNABIS: Great discussion on goals and tradeoffs = e.g. simplicity and=20 invariability of assignments
SIEVE: Published several documents and pushing more through
USEFOR: Prompted the WG last week to close their last one or two = issues,=20 to finish their last doc
--- Scanned by M+ Guardian Messaging = Firewall=20 --- Messaging Architects sponsors The Spamhaus Project.=20 ------_=_NextPart_001_01C985EC.403D0433-- --===============2122898107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============2122898107==-- From netmod-bounces@ietf.org Tue Feb 3 02:52:35 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58403A687C; Tue, 3 Feb 2009 02:52:35 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5AC3A6A8C for ; Tue, 3 Feb 2009 02:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 YPJ9HMTais3d for ; Tue, 3 Feb 2009 02:52:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E23B13A687C for ; Tue, 3 Feb 2009 02:52:32 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27F32C0170; Tue, 3 Feb 2009 11:52:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qUC0AgX0UTFe; Tue, 3 Feb 2009 11:52:06 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B10DAC0161; Tue, 3 Feb 2009 11:52:06 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 5C65795D1DC; Tue, 3 Feb 2009 11:52:05 +0100 (CET) Date: Tue, 3 Feb 2009 11:52:05 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090203105205.GA27289@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , netmod@ietf.org References: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Feb 03, 2009 at 11:43:28AM +0100, Romascanu, Dan (Dan) wrote: > Acronyms clashes have already happened in the past in the IETF. Of > course, if they can be avoided it's better. If there was a published WG > document that already uses the YAM acronyms I could point it to the IESG > and IAB and try to prevent the clash using the prior usage argument. > However there is none that I am aware about in NETMOD. For written documents, the term "YANG module" just seems to be right. For everything else, I do not really care. > PS - this led me looking at the status of the documents in NETMOD and it > looks like you guys start accumulating delay relative to the charter > milestones - but the chairs and the rest of the WG probably know it and > are taking the appropriate measures - right? Yes, there is more important work to do than find the ultimate acronym. While it is your job to check progress against the charter, I am sure you also noted that some important but not chartered work is being done as well. (Andy posted two new individual drafts and I posted another one and I believe all these documents are important for the overall success of what the WG is chartered to deliver.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Feb 3 02:58:31 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0773A6A55; Tue, 3 Feb 2009 02:58:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1813A6A55 for ; Tue, 3 Feb 2009 02:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2jNBNhOlLYmz for ; Tue, 3 Feb 2009 02:58:29 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id E9F1B3A67EA for ; Tue, 3 Feb 2009 02:58:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,371,1231131600"; d="scan'208";a="150940510" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 03 Feb 2009 05:58:08 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Feb 2009 05:58:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 11:57:49 +0100 Message-ID: In-Reply-To: <20090203105205.GA27289@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: charter and milestones (was: RE: [netmod] FW: Lisa's Apps area Activity Report for Jan 2009) thread-index: AcmF7Xqi//0yhzkASjqpBSgl4YRa1AAADuhg References: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> <20090203105205.GA27289@elstar.iuhb02.iu-bremen.de> From: "Romascanu, Dan (Dan)" To: Cc: netmod@ietf.org Subject: [netmod] charter and milestones (was: RE: FW: Lisa's Apps area Activity Report for Jan 2009) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > > > PS - this led me looking at the status of the documents in > NETMOD and > > it looks like you guys start accumulating delay relative to the > > charter milestones - but the chairs and the rest of the WG probably > > know it and are taking the appropriate measures - right? > > Yes, there is more important work to do than find the > ultimate acronym. While it is your job to check progress > against the charter, I am sure you also noted that some > important but not chartered work is being done as well. (Andy > posted two new individual drafts and I posted another one and > I believe all these documents are important for the overall > success of what the WG is chartered to deliver.) > Of course. And I am concerned not that much about the execution of every intermediate step, as by the danger of accumulating delays which would result in the WG being late with its core pieces of work. There was a lot of debate about urgency and time to market by the time the WG was discussed and approved. Should I not be concerned? Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Feb 3 04:17:35 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F4B3A695D; Tue, 3 Feb 2009 04:17:35 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B85E3A68FF for ; Tue, 3 Feb 2009 04:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 iiY9p2wNNyXd for ; Tue, 3 Feb 2009 04:17:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B43873A67B2 for ; Tue, 3 Feb 2009 04:17:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69CF6C0169; Tue, 3 Feb 2009 13:17:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wCnbAsXtMqsy; Tue, 3 Feb 2009 13:17:07 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44CAAC0176; Tue, 3 Feb 2009 13:17:07 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 28E4595D361; Tue, 3 Feb 2009 13:17:06 +0100 (CET) Date: Tue, 3 Feb 2009 13:17:06 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090203121706.GB27315@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , netmod@ietf.org References: <03a001c98574$a6a96670$0600a8c0@china.huawei.com> <20090203105205.GA27289@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] charter and milestones (was: RE: FW: Lisa's Apps area Activity Report for Jan 2009) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Feb 03, 2009 at 11:57:49AM +0100, Romascanu, Dan (Dan) wrote: > Of course. And I am concerned not that much about the execution of every > intermediate step, as by the danger of accumulating delays which would > result in the WG being late with its core pieces of work. There was a > lot of debate about urgency and time to market by the time the WG was > discussed and approved. Should I not be concerned? You should, it is your job. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Feb 3 08:00:07 2009 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0122328C1C9; Tue, 3 Feb 2009 08:00:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C750D28C1A5 for ; Tue, 3 Feb 2009 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rveU5uMuOfHN for ; Tue, 3 Feb 2009 08:00:05 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 1CC613A6C2E for ; Tue, 3 Feb 2009 08:00:05 -0800 (PST) Received: (qmail 71760 invoked from network); 3 Feb 2009 15:59:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 3 Feb 2009 15:59:45 -0000 X-YMail-OSG: u6EJ6nUVM1nyyTtwlAmlH_wfBl10H6hgGqqOidFHW24rcl_Aai22ytTIxkJWz6tWgjkMF5C.JWKYhDGmjEPKUuQEK1RgxbV8DhE12Btzt10vvFK5oKvmXVqS8TxxevyDQ1OHSoC7HN2I4SkDWB2cfnwI X-Yahoo-Newman-Property: ymail-3 Message-ID: <498869F0.2000803@netconfcentral.com> Date: Tue, 03 Feb 2009 07:59:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group References: <49871389.6090600@netconfcentral.com> In-Reply-To: <49871389.6090600@netconfcentral.com> Subject: Re: [netmod] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ... > predicate-expr = node-identifier *WSP "=" *WSP > ((DQUOTE string DQUOTE) / > (SQUOTE string SQUOTE)) > > Why is only one form of a PrimaryExpr allowed here (literal)? What about 'number' results? XPath: /foo/bar[index=7] YANG: /foo/bar[index='7'] There are significant differences between the 2 expressions. (Read XPath, 3.4 for fun ;-) Also, somebody familiar with XPath might think numbers should be OK, instead of 'invalid-value'. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Tue Feb 3 14:08: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 9D2A13A66B4 for ; Tue, 3 Feb 2009 14:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e29dIKzO7m2n for ; Tue, 3 Feb 2009 14:08:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D0FC93A6A28 for ; Tue, 3 Feb 2009 14:08:43 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 46DE561600C; Tue, 3 Feb 2009 23:08:23 +0100 (CET) Date: Tue, 03 Feb 2009 23:08:22 +0100 (CET) Message-Id: <20090203.230822.224136518.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49871389.6090600@netconfcentral.com> References: <49871389.6090600@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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Feb 2009 22:08:44 -0000 Andy Bierman wrote: > From 9.13, para 4: > > The syntax is formally defined by the rule "absolute-instid" in > Section 12. > > This text is not correct. > The rule 'instance-identifier-str' in the ABNF defines the syntax. > > The ABNF in sec. 12 is not correct: [...] > Relative instance-identifiers do not make any sense. > The whole point of this exercise is to have a context-free > NETCONF database node identifier. The text in 9.13, para 2 > says this is an absolute instance-identifier. Ok, but strictly speaking this falls under the category of "correct but confusing" - the text *does* reference the absolut form, and the relative form is not used. I will make the changes you suggest, but I will reduce it some more to: instance-identifier = 1*("/" (node-identifier *predicate)) predicate = "[" *WSP predicate-expr *WSP "]" predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) and then let the text refer to 'instance-identifier'. /martin From mbj@tail-f.com Tue Feb 3 22:53: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 437C93A694C for ; Tue, 3 Feb 2009 22:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRlftMYhHhWR for ; Tue, 3 Feb 2009 22:53:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 856163A68FD for ; Tue, 3 Feb 2009 22:53:29 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D6B5576C2AB; Wed, 4 Feb 2009 07:53:07 +0100 (CET) Date: Wed, 04 Feb 2009 07:53:07 +0100 (CET) Message-Id: <20090204.075307.188586183.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090201130908.GA18045@elstar.local> References: <4984C6A6.6030904@netconfcentral.com> <20090201130908.GA18045@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] 2 more data 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: Wed, 04 Feb 2009 06:53:30 -0000 Juergen Schoenwaelder wrote: > My idea was to add a typedef for a type called xpath to yang-types. > Since an xpath type has already shown up in YANG modules, I suppose > this is useful to have. I agree, and I think ietf-yang-types (name?) is the correct module to add them to. > I have not seen a qname in a YANG module yet > but adding a definition of a qname type to yang-types should not be > too difficult either. I think we should stick to the idea of being conservative in what we add. FWIW, we support this type in our DML, but I haven't seen anyone using it. /martin From j.schoenwaelder@jacobs-university.de Wed Feb 4 02: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 67B4028C1B0 for ; Wed, 4 Feb 2009 02:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 MnIdJonIuONt for ; Wed, 4 Feb 2009 02:49:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5BDC43A68AA for ; Wed, 4 Feb 2009 02:49:05 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B6E6C002B; Wed, 4 Feb 2009 11:48:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JARufZ1J-1eg; Wed, 4 Feb 2009 11:48:39 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9E1FC0009; Wed, 4 Feb 2009 11:48:38 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 94C9495E9C0; Wed, 4 Feb 2009 11:48:37 +0100 (CET) Date: Wed, 4 Feb 2009 11:48:37 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <4984C6A6.6030904@netconfcentral.com> <20090201130908.GA18045@elstar.local> <20090204.075307.188586183.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090204.075307.188586183.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] 2 more data types (!) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 10:49:06 -0000 On Wed, Feb 04, 2009 at 07:53:07AM +0100, Martin Bjorklund wrote: > > I have not seen a qname in a YANG module yet but adding a > > definition of a qname type to yang-types should not be too > > difficult either. > > I think we should stick to the idea of being conservative in what we > add. > > FWIW, we support this type in our DML, but I haven't seen anyone using > it. Andy's YANG model for NETCONF uses qnames for things such as bad-attribute, bad-element, ok-element, err-element, and noop-element. Can you check whether you agree these are qnames? If you do agree, then it might be a reason to add a qname type. And yes, it is likely that YANG modules using qname and xpath types are going to define NETCONF extensions (e.g., definition of new protocol operations) while normal data models may not need these types so much. /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 Wed Feb 4 03:14: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 1061B28C111 for ; Wed, 4 Feb 2009 03:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU5TRevhArns for ; Wed, 4 Feb 2009 03:14:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 934173A6881 for ; Wed, 4 Feb 2009 03:14:29 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2543976C2AC; Wed, 4 Feb 2009 12:14:09 +0100 (CET) Date: Wed, 04 Feb 2009 12:14:08 +0100 (CET) Message-Id: <20090204.121408.71696267.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> References: <20090201130908.GA18045@elstar.local> <20090204.075307.188586183.mbj@tail-f.com> <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] 2 more data 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: Wed, 04 Feb 2009 11:14:31 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 04, 2009 at 07:53:07AM +0100, Martin Bjorklund wrote: > > > > I have not seen a qname in a YANG module yet but adding a > > > definition of a qname type to yang-types should not be too > > > difficult either. > > > > I think we should stick to the idea of being conservative in what we > > add. > > > > FWIW, we support this type in our DML, but I haven't seen anyone using > > it. > > Andy's YANG model for NETCONF uses qnames for things such as > bad-attribute, bad-element, ok-element, err-element, and > noop-element. Can you check whether you agree these are qnames? Yes, they are QNames. However, I have argued in the past that the ok-, err-, and noop-elements are not very useful (see http://ops.ietf.org/lists/netconf/netconf.2006/msg00115.html) > And yes, it is likely that YANG modules using qname and xpath types > are going to define NETCONF extensions (e.g., definition of new > protocol operations) while normal data models may not need these types > so much. Yes. /martin From andy@netconfcentral.com Thu Feb 5 09:52:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDE13A6AD3 for ; Thu, 5 Feb 2009 09:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGd68WAuYivU for ; Thu, 5 Feb 2009 09:52:19 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 55D9028C13A for ; Thu, 5 Feb 2009 09:52:17 -0800 (PST) Received: (qmail 41732 invoked from network); 5 Feb 2009 17:51:57 -0000 Received: from unknown (HELO localhost.localdomain) (andy@68.120.81.203 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 5 Feb 2009 17:51:57 -0000 X-YMail-OSG: xcajLPUVM1m65y9iBOL8gKkU_hCeJ9U15EKDSo7PAM1bFqo.gIq_YuF4OZm4tkn2mmTDsAX9HCMDXdg9JFKWX.gKfM032_fQf3.oTsEA5Fv3qfqlLjgDvF1flMY4zF6zGiQQl9sTjtR0ZhwoTasjvcqd X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B26BD.60602@netconfcentral.com> Date: Thu, 05 Feb 2009 09:49:49 -0800 From: andy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] yang-03, sec. 9.9, leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 17:52:20 -0000 Hi, sec. 9.9: The leafref type is used to reference a particular leaf instance in the data tree. Its value is constrained to be the same as the value of an existing leaf. If the leaf with the leafref type represents configuration data, and the "require-instance" property (Section 9.9.3) is "true", the leaf it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All leafref nodes MUST reference existing leaf instances for the data to be valid. This constraint is enforced according to the rules in Section 8. The require-instance section (9.9.3) does not really address leafref issues. The "require-instance" statement, which is a substatement to the "type" statement, MAY be present if the type is "leafref" or "instance-identifier". It takes as an argument the string "true" or "false". If this statement is not present, it defaults to "true". If "require-instance" is "true", it means that the instance being referred MUST exist for the data to be valid. This constraint is enforced according to the rules in Section 8. I object to the current 9.9, para 2 text. The require-instance flag should not have anything to do with config = true/false. The agreement I think was reached at the last IETF was : If require-instance is true for a leafref, then the value set (determined by the path-stmt) is restricted to existing instance values. If require-instance=false, then a leafref is constrained by the type or typedef associated with the object indicated by the path-stmt. Andy From mbj@tail-f.com Thu Feb 5 11:57: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 0D3F13A68A8 for ; Thu, 5 Feb 2009 11:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgFaKMocFNDF for ; Thu, 5 Feb 2009 11:57:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 40E0C3A6806 for ; Thu, 5 Feb 2009 11:57:40 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7183A76C22F; Thu, 5 Feb 2009 20:57:40 +0100 (CET) Date: Thu, 05 Feb 2009 20:57:40 +0100 (CET) Message-Id: <20090205.205740.62623536.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <498869F0.2000803@netconfcentral.com> References: <49871389.6090600@netconfcentral.com> <498869F0.2000803@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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 19:57:44 -0000 Andy Bierman wrote: > ... > > predicate-expr = node-identifier *WSP "=" *WSP > > ((DQUOTE string DQUOTE) / > > (SQUOTE string SQUOTE)) > > > > Why is only one form of a PrimaryExpr allowed here (literal)? > What about 'number' results? > > XPath: > > /foo/bar[index=7] > > YANG: > > /foo/bar[index='7'] > > > There are significant differences between the 2 expressions. > (Read XPath, 3.4 for fun ;-) Yes, there is a difference, and the difference works in favor for using literals - when literals are used, exact string comparison is done, but with numbers, 64 bit floating point comparison is done. So with this data: 922337203685477581 The expression: /foo/bar[index=922337203685477580] will match the instance, but the expression /foo/bar[index='922337203685477580'] will not match. /martin From mbj@tail-f.com Thu Feb 5 12:08:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915053A6A1A for ; Thu, 5 Feb 2009 12:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGwo6c7a6bgF for ; Thu, 5 Feb 2009 12:08:51 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 33E683A696A for ; Thu, 5 Feb 2009 12:07:02 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 514B076C22F; Thu, 5 Feb 2009 21:07:03 +0100 (CET) Date: Thu, 05 Feb 2009 21:07:02 +0100 (CET) Message-Id: <20090205.210702.72234554.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <498B26BD.60602@netconfcentral.com> References: <498B26BD.60602@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-03, sec. 9.9, leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 20:08:55 -0000 andy wrote: > I object to the current 9.9, para 2 text. > The require-instance flag should not have anything > to do with config = true/false. The agreement I think > was reached at the last IETF was : > > If require-instance is true for a leafref, then the value set (determined > by the path-stmt) is restricted to existing instance values. Yes, but w/o this rule you might have a pointer from config data to state data, and there is no guarantee that the state data does not change. If the state instance is removed by the system, you would have a dangling 'require-instance' pointer in the config, which makes the config invalid! If you need a pointer from config to state data, require-instance must be set to false. /martin From andy@netconfcentral.com Thu Feb 5 13:18: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 1392C3A68E5 for ; Thu, 5 Feb 2009 13:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FWDmaK9Gm6x for ; Thu, 5 Feb 2009 13:18:44 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 374063A696B for ; Thu, 5 Feb 2009 13:18:34 -0800 (PST) Received: (qmail 83812 invoked from network); 5 Feb 2009 21:18:35 -0000 Received: from unknown (HELO localhost.localdomain) (andy@68.120.81.203 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 5 Feb 2009 21:18:35 -0000 X-YMail-OSG: W.34yxUVM1kMDD_MjtWsKkweCpBDL2ifI71y1hWv9265dwi011SsKZsH5Hhaon8mrbUuGaDDCUhpta4I1qhcCKRyOesE4pLjMIEkvcvkXGXh9pYkidTevadxub63N_t6zpPe7NP7lxrjjZMkRwPJdQjqFG8TN8GLJ60qLz__sybEQQjhn1uSjwkEw.xzm6XqndQYlbxW0gUXAnTVz_C5xw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B572B.40809@netconfcentral.com> Date: Thu, 05 Feb 2009 13:16:27 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Bjorklund References: <49871389.6090600@netconfcentral.com> <498869F0.2000803@netconfcentral.com> <20090205.205740.62623536.mbj@tail-f.com> In-Reply-To: <20090205.205740.62623536.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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:18:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> ... >>> predicate-expr = node-identifier *WSP "=" *WSP >>> ((DQUOTE string DQUOTE) / >>> (SQUOTE string SQUOTE)) >>> >> Why is only one form of a PrimaryExpr allowed here (literal)? >> What about 'number' results? >> >> XPath: >> >> /foo/bar[index=7] >> >> YANG: >> >> /foo/bar[index='7'] >> >> >> There are significant differences between the 2 expressions. >> (Read XPath, 3.4 for fun ;-) > > Yes, there is a difference, and the difference works in favor for > using literals - when literals are used, exact string comparison is > done, but with numbers, 64 bit floating point comparison is done. So > with this data: > > > > 922337203685477581 > > > > The expression: /foo/bar[index=922337203685477580] will match the > instance, but the expression /foo/bar[index='922337203685477580'] > will not match. > Well, there are are plenty or cornser cases I guess. Using a string literal, then '1' and '1.0' do not match either. I find the limited subset of XPath used by YANG to be somewhat arbitrary, and that makes it confusing. > > /martin Andy From j.schoenwaelder@jacobs-university.de Thu Feb 5 13:19: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 E554D3A6765 for ; Thu, 5 Feb 2009 13:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 bstSbIUaqdUJ for ; Thu, 5 Feb 2009 13:19:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B6CA33A68B8 for ; Thu, 5 Feb 2009 13:19:11 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9C18C007F; Thu, 5 Feb 2009 22:19:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e5bHCmQH8Hlt; Thu, 5 Feb 2009 22:19:05 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DC66C01F9; Thu, 5 Feb 2009 22:19:05 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 7FA98961417; Thu, 5 Feb 2009 22:19:04 +0100 (CET) Date: Thu, 5 Feb 2009 22:19:04 +0100 From: Juergen Schoenwaelder To: Simon Leinen Message-ID: <20090205211904.GC3320@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Simon Leinen , netmod@ietf.org References: <20081218161352.GC6703@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 address normalization ?? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:19:13 -0000 On Tue, Dec 23, 2008 at 08:12:04PM +0100, Simon Leinen wrote: > I would also add that the :: subsitution should only be applied to > sequences of two or more all-zero chunks, i.e. you shouldn't compress > > 2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7 > > This is a matter of taste and convention. The existing inet_ntop() > code that I checked doesn't compress a single zero. It seems the inet_ntop() code Paul Vixie wrote and which is part of glibc (and I think also some BSD libcs) does compress a single all-zero chunk. I would prefer to keep it this way. I am wondering which code you checked... /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 Feb 5 13: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 146B63A696B for ; Thu, 5 Feb 2009 13:21:30 -0800 (PST) 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.117, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2870u69HqDtO for ; Thu, 5 Feb 2009 13:21:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 353CD3A6765 for ; Thu, 5 Feb 2009 13:21:29 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9922D76C22F; Thu, 5 Feb 2009 22:21:29 +0100 (CET) Date: Thu, 05 Feb 2009 22:21:29 +0100 (CET) Message-Id: <20090205.222129.169856078.mbj@tail-f.com> To: simon.leinen@switch.ch From: Martin Bjorklund In-Reply-To: References: <20081218161352.GC6703@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] =?iso-8859-1?q?ipv6_address_normalization_=B6?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:21:30 -0000 Simon Leinen wrote: > Juergen Schoenwaelder writes: > > * Allow multiple formats and representations > > * Make the shortened format the canonical format > > * The :: substitution must be applied to the longest sequence of > > zeros in an IPv6 address (if there is a tie, the first sequence > > of zeros is replaced by ::) > > "Sequence of zeros"... I would prefer "sequence of all-zero 16-bit > chunks", as that is clearer (if more verbose). I support Juergen's proposal with this clarification. > I would also add that the :: subsitution should only be applied to > sequences of two or more all-zero chunks, i.e. you shouldn't compress > > 2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7 > > This is a matter of taste and convention. The existing inet_ntop() > code that I checked doesn't compress a single zero. I agree with this - we should do what the standard functions do. /martin From andy@netconfcentral.com Thu Feb 5 13:21: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 0CC7F28C10C for ; Thu, 5 Feb 2009 13:21:33 -0800 (PST) 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.241, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS7sBwgfKv-B for ; Thu, 5 Feb 2009 13:21:32 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 5EC4D28C10A for ; Thu, 5 Feb 2009 13:21:32 -0800 (PST) Received: (qmail 70774 invoked from network); 5 Feb 2009 21:21:34 -0000 Received: from unknown (HELO localhost.localdomain) (andy@68.120.81.203 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 5 Feb 2009 21:21:33 -0000 X-YMail-OSG: ZtUI9PgVM1kfH46vIcA59Mbk7BKvykT4.Bfo3QY5TUHUB4aMuWd.lJDhI6GPabV2CtwPXAm5H839mjIl..ITxdn8omjL0MhQb3OgMX.SObrNHqpTjryFzSuTKeZQ2rpnYWBIfRSWv67ogFpVtH6yk0EK0ZTlxJB6l5m_sFNwfpV_74Iojs3KE0LSr7c_yQayMjECHub3.I_cpSiL8yjLQg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B57DE.9030700@netconfcentral.com> Date: Thu, 05 Feb 2009 13:19:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Bjorklund References: <498B26BD.60602@netconfcentral.com> <20090205.210702.72234554.mbj@tail-f.com> In-Reply-To: <20090205.210702.72234554.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] yang-03, sec. 9.9, leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:21:33 -0000 Martin Bjorklund wrote: > andy wrote: >> I object to the current 9.9, para 2 text. >> The require-instance flag should not have anything >> to do with config = true/false. The agreement I think >> was reached at the last IETF was : >> >> If require-instance is true for a leafref, then the value set (determined >> by the path-stmt) is restricted to existing instance values. > > Yes, but w/o this rule you might have a pointer from config data to > state data, and there is no guarantee that the state data does not > change. If the state instance is removed by the system, you would > have a dangling 'require-instance' pointer in the config, which makes > the config invalid! > > If you need a pointer from config to state data, require-instance must > be set to false. > The YANG draft states in several places that config=false is not even part of the database. I do not see how sometimes it is part of the database, and other times it isn't. Very confusing. If it is not part of the datbase, then why do we even allow must/when on config=false? It is not very important to support that IMO. > > /martin Andy From mbj@tail-f.com Thu Feb 5 13:22: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 37DF33A6ACC for ; Thu, 5 Feb 2009 13:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWRRlo7STydZ for ; Thu, 5 Feb 2009 13:22:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6CCBE3A6765 for ; Thu, 5 Feb 2009 13:22:53 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 96DC776C22F; Thu, 5 Feb 2009 22:22:54 +0100 (CET) Date: Thu, 05 Feb 2009 22:22:54 +0100 (CET) Message-Id: <20090205.222254.173558994.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081218161426.GD6703@elstar.local> References: <20081218161426.GD6703@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] ipv4-prefix / ipv6-prefix normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:22:54 -0000 Juergen Schoenwaelder wrote: > Description: The two representations 192.0.2.0/24 and 192.0.2.8/24 > mean the same thing. > > Discussion: Proposal: > > * Require that all bits that are not part of the prefix are set to > zero (192.0.2.8/24 becomes an invalid representation of an IPv4 > prefix) > * For IPv6, the shortened form will be the canonical format, other > representations are allowed > * Results in a 1:1 mapping between lexical representation and the > value space for IPv4 but not for IPv6 I support this. Maybe you can refer to the normalized form of the ipv4-address and ipv6-address types. /martin From mbj@tail-f.com Thu Feb 5 13:24:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C453A6ACC for ; Thu, 5 Feb 2009 13:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzFKdvk6d-z5 for ; Thu, 5 Feb 2009 13:24:58 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3037A3A6765 for ; Thu, 5 Feb 2009 13:24:58 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 51AB276C22F; Thu, 5 Feb 2009 22:24:59 +0100 (CET) Date: Thu, 05 Feb 2009 22:24:59 +0100 (CET) Message-Id: <20090205.222459.119256301.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081218161305.GA6703@elstar.local> References: <20081218161305.GA6703@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] types-012: date-and-time normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:24:59 -0000 Juergen Schoenwaelder wrote: > Description: The time-offset Z and +00:00 mean the same thing (but > note that -00:00 means unknown time zone according to RFC 3339 but the > same as Z according to XSD). > > Discussion: XSD says the canonical time-offset format is Z. Proposal: > > * Make Z the canonical time-offset format > * Clarify that -00:00 means unknown time zone > * Clarify that 00:00 and Z mean the same thing I support this proposal. It makes sense to follow RFC 3339. /martin From mbj@tail-f.com Thu Feb 5 13:32:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224EF3A6827 for ; Thu, 5 Feb 2009 13:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTGbaUlcxz5t for ; Thu, 5 Feb 2009 13:32:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 527033A67F6 for ; Thu, 5 Feb 2009 13:32:03 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 660D276C22F; Thu, 5 Feb 2009 22:32:04 +0100 (CET) Date: Thu, 05 Feb 2009 22:32:04 +0100 (CET) Message-Id: <20090205.223204.258883173.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090205211904.GC3320@elstar.iuhb02.iu-bremen.de> References: <20081218161352.GC6703@elstar.local> <20090205211904.GC3320@elstar.iuhb02.iu-bremen.de> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 address normalization ?? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:32:04 -0000 Juergen Schoenwaelder wrote: > On Tue, Dec 23, 2008 at 08:12:04PM +0100, Simon Leinen wrote: > > > I would also add that the :: subsitution should only be applied to > > sequences of two or more all-zero chunks, i.e. you shouldn't compress > > > > 2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7 > > > > This is a matter of taste and convention. The existing inet_ntop() > > code that I checked doesn't compress a single zero. > > It seems the inet_ntop() code Paul Vixie wrote and which is part of > glibc (and I think also some BSD libcs) does compress a single > all-zero chunk. I would prefer to keep it this way. I am wondering > which code you checked... I tried this with glibc 2.8.90, and it did not compress a single zero. /martin From mbj@tail-f.com Thu Feb 5 13: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 C83293A6A16 for ; Thu, 5 Feb 2009 13:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 82UWA6Cyb18L for ; Thu, 5 Feb 2009 13:38:04 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0D3683A6AC8 for ; Thu, 5 Feb 2009 13:38:03 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1864776C22F; Thu, 5 Feb 2009 22:38:05 +0100 (CET) Date: Thu, 05 Feb 2009 22:38:04 +0100 (CET) Message-Id: <20090205.223804.135364694.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <498B57DE.9030700@netconfcentral.com> References: <498B26BD.60602@netconfcentral.com> <20090205.210702.72234554.mbj@tail-f.com> <498B57DE.9030700@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-03, sec. 9.9, leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:38:04 -0000 Andy Bierman wrote: > The YANG draft states in several places that > config=false is not even part of the database. Right. > I do not see how sometimes it is part of the database, > and other times it isn't. Very confusing. When is config false part of the database? > If it is not part of the datbase, then why do > we even allow must/when on config=false? > It is not very important to support that IMO. Well, I agree with you that it's not very important, but this was the consensus from the interim, and there's also a ML thread called "Proposed consensus mail on yang-00172". /martin From mbj@tail-f.com Thu Feb 5 13:42: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 0CB843A6AC8 for ; Thu, 5 Feb 2009 13:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCw12kRmSdUu for ; Thu, 5 Feb 2009 13:42:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3B33A3A6AB8 for ; Thu, 5 Feb 2009 13:42:24 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5360576C22F; Thu, 5 Feb 2009 22:42:25 +0100 (CET) Date: Thu, 05 Feb 2009 22:42:25 +0100 (CET) Message-Id: <20090205.224225.50451258.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <498B572B.40809@netconfcentral.com> References: <498869F0.2000803@netconfcentral.com> <20090205.205740.62623536.mbj@tail-f.com> <498B572B.40809@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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 21:42:25 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> ... > >>> predicate-expr = node-identifier *WSP "=" *WSP > >>> ((DQUOTE string DQUOTE) / > >>> (SQUOTE string SQUOTE)) > >>> > >> Why is only one form of a PrimaryExpr allowed here (literal)? > >> What about 'number' results? > >> > >> XPath: > >> > >> /foo/bar[index=7] > >> > >> YANG: > >> > >> /foo/bar[index='7'] > >> > >> > >> There are significant differences between the 2 expressions. > >> (Read XPath, 3.4 for fun ;-) > > Yes, there is a difference, and the difference works in favor for > > using literals - when literals are used, exact string comparison is > > done, but with numbers, 64 bit floating point comparison is done. So > > with this data: > > > > > > 922337203685477581 > > > > > > The expression: /foo/bar[index=922337203685477580] will match the > > instance, but the expression /foo/bar[index='922337203685477580'] > > will not match. > > > > Well, there are are plenty or cornser cases I guess. > Using a string literal, then '1' and '1.0' do not match either. > I find the limited subset of XPath used by YANG to be > somewhat arbitrary, and that makes it confusing. Do you mean "used by YANG in the instance-identifier expressions"? Would it be less arbitrary and confusing if we allow numbers? I don't have a problem with that. /martin From j.schoenwaelder@jacobs-university.de Thu Feb 5 14:13:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0EB28C145 for ; Thu, 5 Feb 2009 14:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 cyU6DGZN8Beh for ; Thu, 5 Feb 2009 14:13:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 48E253A69B7 for ; Thu, 5 Feb 2009 14:13:37 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C72FC0023; Thu, 5 Feb 2009 23:13:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id w3fc6DkmfXSy; Thu, 5 Feb 2009 23:13:32 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6698EC007C; Thu, 5 Feb 2009 23:13:32 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 44FC1961558; Thu, 5 Feb 2009 23:13:31 +0100 (CET) Date: Thu, 5 Feb 2009 23:13:31 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090205221331.GD3320@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , simon.leinen@switch.ch, netmod@ietf.org References: <20081218161352.GC6703@elstar.local> <20090205211904.GC3320@elstar.iuhb02.iu-bremen.de> <20090205.223204.258883173.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090205.223204.258883173.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 address normalization ?? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 22:13:39 -0000 On Thu, Feb 05, 2009 at 10:32:04PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Dec 23, 2008 at 08:12:04PM +0100, Simon Leinen wrote: > > > > > I would also add that the :: subsitution should only be applied to > > > sequences of two or more all-zero chunks, i.e. you shouldn't compress > > > > > > 2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7 > > > > > > This is a matter of taste and convention. The existing inet_ntop() > > > code that I checked doesn't compress a single zero. > > > > It seems the inet_ntop() code Paul Vixie wrote and which is part of > > glibc (and I think also some BSD libcs) does compress a single > > all-zero chunk. I would prefer to keep it this way. I am wondering > > which code you checked... > > I tried this with glibc 2.8.90, and it did not compress a single > zero. Hm. Wrong window. I stand corrected. The Paul Vixie code does indeed not compress single all-zero chunks. The relevant line in his source code is this: if (best.base != -1 && best.len < 2) best.base = -1; But MacOS X does seem to always compress. Can someone check on Win32? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From per@tail-f.com Thu Feb 5 14:25: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 9D3B53A6AE1 for ; Thu, 5 Feb 2009 14:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 xvaVYW+3GXCr for ; Thu, 5 Feb 2009 14:25:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6B52D3A6ADF for ; Thu, 5 Feb 2009 14:25:44 -0800 (PST) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id A58BA76C22F; Thu, 5 Feb 2009 23:25:44 +0100 (CET) Message-ID: <498B6764.9010305@tail-f.com> Date: Thu, 05 Feb 2009 23:25:40 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de References: <20081218161352.GC6703@elstar.local> <20090205211904.GC3320@elstar.iuhb02.iu-bremen.de> <20090205.223204.258883173.mbj@tail-f.com> <20090205221331.GD3320@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090205221331.GD3320@elstar.iuhb02.iu-bremen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 address normalization ?? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 22:25:45 -0000 On 2009-02-05 23:13, Juergen Schoenwaelder wrote: > On Thu, Feb 05, 2009 at 10:32:04PM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Tue, Dec 23, 2008 at 08:12:04PM +0100, Simon Leinen wrote: >>> >>>> I would also add that the :: subsitution should only be applied to >>>> sequences of two or more all-zero chunks, i.e. you shouldn't compress >>>> >>>> 2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7 >>>> >>>> This is a matter of taste and convention. The existing inet_ntop() >>>> code that I checked doesn't compress a single zero. >>> It seems the inet_ntop() code Paul Vixie wrote and which is part of >>> glibc (and I think also some BSD libcs) does compress a single >>> all-zero chunk. I would prefer to keep it this way. I am wondering >>> which code you checked... >> I tried this with glibc 2.8.90, and it did not compress a single >> zero. > > Hm. Wrong window. I stand corrected. The Paul Vixie code does indeed > not compress single all-zero chunks. The relevant line in his source > code is this: > > if (best.base != -1 && best.len < 2) > best.base = -1; > > But MacOS X does seem to always compress. Can someone check on Win32? Sorry, not me, but here are a few other data points: FreeBSD 6.0 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 FreeBSD 7.0 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 Linux glibc 2.4 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 Linux glibc 2.7 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 NetBSD 3.1 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 NetBSD 4.0 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 SunOS 5.10 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 QNX 6.3.2 2000:0:2:3:4:5:6:7 -> 2000:0:2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 Darwin 9.6.0 2000:0:2:3:4:5:6:7 -> 2000::2:3:4:5:6:7 2000:0:0:3:4:5:6:7 -> 2000::3:4:5:6:7 --Per Hedeland From david.kessens@nsn.com Thu Feb 5 14:54: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 821E228C148 for ; Thu, 5 Feb 2009 14:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NiGvLYrV5WL for ; Thu, 5 Feb 2009 14:54:37 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A2BAB3A6AAD for ; Thu, 5 Feb 2009 14:54:37 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n15MsXm3011745; Thu, 5 Feb 2009 16:54:36 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 00:54:34 +0200 Received: from localhost.localdomain ([10.241.59.233]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 00:54:33 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n15MsA7q010695; Thu, 5 Feb 2009 14:54:10 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n15Ms8vJ010690; Thu, 5 Feb 2009 14:54:08 -0800 Date: Thu, 5 Feb 2009 14:54:08 -0800 From: David Kessens To: Martin Bjorklund Message-ID: <20090205225408.GD18938@nsn.com> References: <20081218161426.GD6703@elstar.local> <20090205.222254.173558994.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090205.222254.173558994.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 05 Feb 2009 22:54:33.0842 (UTC) FILETIME=[B65A1520:01C987E4] X-Nokia-AV: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ipv4-prefix / ipv6-prefix normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Feb 2009 22:54:38 -0000 On Thu, Feb 05, 2009 at 10:22:54PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Description: The two representations 192.0.2.0/24 and 192.0.2.8/24 > > mean the same thing. > > > > Discussion: Proposal: > > > > * Require that all bits that are not part of the prefix are set to > > zero (192.0.2.8/24 becomes an invalid representation of an IPv4 > > prefix) > > * For IPv6, the shortened form will be the canonical format, other > > representations are allowed Note that http://tools.ietf.org/html/rfc4291 says in section "2.2. Text Representation of Addresses": 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. The abbreviated form is available for convenience. Basically, do we really want to do something else than the "preferred" format which is unambiguous and clear although a bit long ? David Kessens --- From andy@netconfcentral.com Thu Feb 5 17:08: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 93ACB3A6A18 for ; Thu, 5 Feb 2009 17:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDV9aKRx0L+i for ; Thu, 5 Feb 2009 17:08:47 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 9F6AD3A69CB for ; Thu, 5 Feb 2009 17:08:47 -0800 (PST) Received: (qmail 34328 invoked from network); 6 Feb 2009 01:08:49 -0000 Received: from unknown (HELO localhost.localdomain) (andy@68.120.81.203 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 6 Feb 2009 01:08:48 -0000 X-YMail-OSG: bFJR02IVM1mCvPL3o8sjg6MS4TP2966.U2yakKX9257Sam9YYnzToOkl_VEiXRrkGE48k5T4NvA5D4dgcFGia4eAgrXxpk2njhgjOAdyStBUQVQ66_0Hau9qPbR5JW1Cd1STBgpDmqpoNaLCMQ6VO_M8l9NpbOIrsc8f1fZCgPbcXSqYDGlTaMq1PVDWSt1Rd8vFNppL3OwgXKMweqGPkw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B8D20.5060003@netconfcentral.com> Date: Thu, 05 Feb 2009 17:06:40 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Bjorklund References: <498869F0.2000803@netconfcentral.com> <20090205.205740.62623536.mbj@tail-f.com> <498B572B.40809@netconfcentral.com> <20090205.224225.50451258.mbj@tail-f.com> In-Reply-To: <20090205.224225.50451258.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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Feb 2009 01:08:48 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> ... >>>>> predicate-expr = node-identifier *WSP "=" *WSP >>>>> ((DQUOTE string DQUOTE) / >>>>> (SQUOTE string SQUOTE)) >>>>> >>>> Why is only one form of a PrimaryExpr allowed here (literal)? >>>> What about 'number' results? >>>> >>>> XPath: >>>> >>>> /foo/bar[index=7] >>>> >>>> YANG: >>>> >>>> /foo/bar[index='7'] >>>> >>>> >>>> There are significant differences between the 2 expressions. >>>> (Read XPath, 3.4 for fun ;-) >>> Yes, there is a difference, and the difference works in favor for >>> using literals - when literals are used, exact string comparison is >>> done, but with numbers, 64 bit floating point comparison is done. So >>> with this data: >>> >>> >>> 922337203685477581 >>> >>> >>> The expression: /foo/bar[index=922337203685477580] will match the >>> instance, but the expression /foo/bar[index='922337203685477580'] >>> will not match. >>> >> Well, there are are plenty or cornser cases I guess. >> Using a string literal, then '1' and '1.0' do not match either. >> I find the limited subset of XPath used by YANG to be >> somewhat arbitrary, and that makes it confusing. > > Do you mean "used by YANG in the instance-identifier expressions"? > I prefer to minimize all the little differences. It is better to allow both literal and number in leafref and instance-identifier, and include some text that says where literal is better than number and vice versa. Let the data modeller decide what to do. Number is only unsafe for RelationalExpr, for int64 and uint64. Why forbid its use for data types that will barely get used? A warning that only safe expressions SHOULD be used is good enough. One more big leafref/instance-identifier open issue I just thought of. The text seems to imply that the require-instance check is applied when the value is created. This is of course not the case for , only for . We must not introduce PDU order dependencies, that we have been careful to avoid so far. There should be some text in the Constraints section that says leafref/instance-identifier 'require-instance' check (and leafref validation if it is false) is performed prior to 'commit' for , or right away for . There could be PDUs where one subtree creates a leafref or instance-identifier that points off to another part of the config that is getting deleted or modified in the same PDU. The config could be changed by later PDUs, such that the will eventually fail because the leafref/instance-identifier set in the first PDU is no longer valid. > Would it be less arbitrary and confusing if we allow numbers? I don't > have a problem with that. > > > /martin > > Andy From andy@netconfcentral.com Thu Feb 5 17: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 90D113A69CB for ; Thu, 5 Feb 2009 17:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OirzeMWJin5H for ; Thu, 5 Feb 2009 17:15:35 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id B0C173A67F6 for ; Thu, 5 Feb 2009 17:15:35 -0800 (PST) Received: (qmail 56286 invoked from network); 6 Feb 2009 01:15:37 -0000 Received: from unknown (HELO localhost.localdomain) (andy@68.120.81.203 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 6 Feb 2009 01:15:36 -0000 X-YMail-OSG: t6w9Jv0VM1m5oEag_dmR06GxcibQi7Q73BGhoCJg8IOZ6nnDlhPL_hnt9Yp.xnwYubIMdp.BTNXlngihvSMye9v3IohCJYtz3p02PN1qskL5xowhkbuwVqfbHchhp9GFsCPoqZRj7Ff.zLXIFNJ5ONY3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B8EB9.1060201@netconfcentral.com> Date: Thu, 05 Feb 2009 17:13:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] require-instance error-app-tag X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Feb 2009 01:15:36 -0000 Hi, There doesn't seem to be any good error codes for a require-instance = true violation for a leafref or instance-identifier. Perhaps a new error-app-tag and sub-section of 13.x should be added to make that stand out, especially since the default is true. Andy From andy@netconfcentral.com Thu Feb 5 17:23: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 E767D3A6AE3 for ; Thu, 5 Feb 2009 17:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijtbV0hfcq1k for ; Thu, 5 Feb 2009 17:23:28 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 4C60E3A698A for ; Thu, 5 Feb 2009 17:23:27 -0800 (PST) Received: (qmail 58975 invoked from network); 6 Feb 2009 01:23:29 -0000 Received: from unknown (HELO localhost.localdomain) (andy@68.120.81.203 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 6 Feb 2009 01:23:28 -0000 X-YMail-OSG: FuzfsFYVM1nVFiBPmYJV9D1SVCwQwYkmcQGPveOe3huPp8m7eyI4A5dW42x7kw_YPf46zTyM0qg_9oaJ4yEHm_DPuUTryTCOmzpmxT1e5wcsC7OnMJ31ZEq6o4hOaW1oHmSWBbxAy2UoN4CgXHlyPRClpCUetul.vjdTmUFmuEN94_x6dHVIk6yf X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B9091.5040104@netconfcentral.com> Date: Thu, 05 Feb 2009 17:21:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Bjorklund References: <498869F0.2000803@netconfcentral.com> <20090205.205740.62623536.mbj@tail-f.com> <498B572B.40809@netconfcentral.com> <20090205.224225.50451258.mbj@tail-f.com> <498B8D20.5060003@netconfcentral.com> In-Reply-To: <498B8D20.5060003@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Feb 2009 01:23:29 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Martin Bjorklund wrote: >>>> Andy Bierman wrote: >>>>> ... >>>>>> predicate-expr = node-identifier *WSP "=" *WSP >>>>>> ((DQUOTE string DQUOTE) / >>>>>> (SQUOTE string SQUOTE)) >>>>>> >>>>> Why is only one form of a PrimaryExpr allowed here (literal)? >>>>> What about 'number' results? >>>>> >>>>> XPath: >>>>> >>>>> /foo/bar[index=7] >>>>> >>>>> YANG: >>>>> >>>>> /foo/bar[index='7'] >>>>> >>>>> >>>>> There are significant differences between the 2 expressions. >>>>> (Read XPath, 3.4 for fun ;-) >>>> Yes, there is a difference, and the difference works in favor for >>>> using literals - when literals are used, exact string comparison is >>>> done, but with numbers, 64 bit floating point comparison is done. So >>>> with this data: >>>> >>>> >>>> 922337203685477581 >>>> >>>> >>>> The expression: /foo/bar[index=922337203685477580] will match the >>>> instance, but the expression /foo/bar[index='922337203685477580'] >>>> will not match. >>>> >>> Well, there are are plenty or cornser cases I guess. >>> Using a string literal, then '1' and '1.0' do not match either. >>> I find the limited subset of XPath used by YANG to be >>> somewhat arbitrary, and that makes it confusing. >> >> Do you mean "used by YANG in the instance-identifier expressions"? >> > I changed my mind about numbers in leafref/instance-identifier predicates. These path expressions are not really XPath, they are YANG. The numbers are YANG numbers, not IEEE754 numbers. It would be too confusing and prone to errors. The single-quoted string is the same in both YANG and XPath, so it is safer to stick with that. Andy > I prefer to minimize all the little differences. > It is better to allow both literal and number in leafref > and instance-identifier, and include some text that says > where literal is better than number and vice versa. > Let the data modeller decide what to do. Number is > only unsafe for RelationalExpr, for int64 and uint64. > Why forbid its use for data types that will barely get used? > A warning that only safe expressions SHOULD be used is good enough. > > One more big leafref/instance-identifier open issue I just > thought of. The text seems to imply that the require-instance > check is applied when the value is created. This is of course > not the case for , only for . > We must not introduce PDU order dependencies, > that we have been careful to avoid so far. > > There should be some text in the Constraints section > that says leafref/instance-identifier 'require-instance' > check (and leafref validation if it is false) is performed > prior to 'commit' for , or right away for . > > There could be PDUs where one subtree creates a > leafref or instance-identifier that points off to another part > of the config that is getting deleted or modified > in the same PDU. The config could be changed by later PDUs, > such that the will eventually fail because the > leafref/instance-identifier set in the first PDU is no longer valid. > > > > > >> Would it be less arbitrary and confusing if we allow numbers? I don't >> have a problem with that. >> >> >> /martin >> >> > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From Washam.Fan@huaweisymantec.com Thu Feb 5 18:04: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 8A4743A6AE5 for ; Thu, 5 Feb 2009 18:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 I5W9564qPfVR for ; Thu, 5 Feb 2009 18:04:46 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id A5F953A67A2 for ; Thu, 5 Feb 2009 18:04:46 -0800 (PST) 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-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEM00LTCGFVFV40@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 06 Feb 2009 10:04:45 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEM000ASGFUB520@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 06 Feb 2009 10:04:43 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 06 Feb 2009 10:04:42 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Fri, 06 Feb 2009 10:04:42 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090205.222129.169856078.mbj@tail-f.com> References: <20081218161352.GC6703@elstar.local> <20090205.222129.169856078.mbj@tail-f.com> Cc: netmod@ietf.org Subject: [netmod] yang-03, sec 9.9.6, leafref 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: Fri, 06 Feb 2009 02:04:47 -0000 Hi, definition: list interface { key "name"; leaf name { type string; } leaf ifIndex { type uint32; } list address { key "ip"; leaf ip { type yang:ip-address; } } } but the corresponding XML snippet: eth0
192.0.2.1
192.0.2.2
lo
127.0.0.1
where is , this node is referenced by following notification. washam From andy@netconfcentral.com Thu Feb 5 18:19: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 796BE28C14B for ; Thu, 5 Feb 2009 18:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=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 D9AgUmv6i-ER for ; Thu, 5 Feb 2009 18:19:24 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 800EA28C125 for ; Thu, 5 Feb 2009 18:19:24 -0800 (PST) Received: (qmail 57710 invoked from network); 6 Feb 2009 02:19:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.203 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 6 Feb 2009 02:19:25 -0000 X-YMail-OSG: GKdXTnMVM1kbHhFMVSESzpZKyaW.RJA2Or4qy4hfEcgB5s88utGY2yBCPTMR7xBEIAiOgNmTrzCa3eOzT0QJlzKWdulAiSc4xYd0LrLQhc.ZDVM.DU4XScCxy6dbYq77ghlEudSCaUVGXkz8YLATdLtdRWiKbCl.O_FNVx87zI.ANVomT2EE0Cx9DpfWlFcyAZ4NzDM71xmYoJd6aajLnHoCCXnT3YHTp1eN_n6JBe4qE0btyaA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <498B9E2B.6010504@netconfcentral.com> Date: Thu, 05 Feb 2009 18:19:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <4984C6A6.6030904@netconfcentral.com> <20090201130908.GA18045@elstar.local> <20090204.075307.188586183.mbj@tail-f.com> <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] 2 more data 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, 06 Feb 2009 02:19:25 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 04, 2009 at 07:53:07AM +0100, Martin Bjorklund wrote: > >>> I have not seen a qname in a YANG module yet but adding a >>> definition of a qname type to yang-types should not be too >>> difficult either. >> I think we should stick to the idea of being conservative in what we >> add. >> >> FWIW, we support this type in our DML, but I haven't seen anyone using >> it. > > Andy's YANG model for NETCONF uses qnames for things such as > bad-attribute, bad-element, ok-element, err-element, and > noop-element. Can you check whether you agree these are qnames? > If you do agree, then it might be a reason to add a qname type. > HTML: http://www.netconfcentral.org/modules/xsd/2007-12-06 YANG: http://www.netconfcentral.org/src/xsd_2007-12-06.yang This is the 'work-in-progress' xsd.yang that I wrote awhile back. It needs some 'pattern and XSD expert' to finish off some of the string types. Not sure if you want to cherry-pick, ignore, or consider a a standard xsd.yang module. It's not very important, considering the current status of XSD within the WG. But if there are some types that might get replicated over and over, then it could be worth it. > And yes, it is likely that YANG modules using qname and xpath types > are going to define NETCONF extensions (e.g., definition of new > protocol operations) while normal data models may not need these types > so much. > > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Feb 5 23:52: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 A9A2F3A6959 for ; Thu, 5 Feb 2009 23:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 tZjyzgPiOYMA for ; Thu, 5 Feb 2009 23:52:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8FE7C3A6880 for ; Thu, 5 Feb 2009 23:52:27 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92A01C001A; Fri, 6 Feb 2009 08:52:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3t2Sx4ACy2dr; Fri, 6 Feb 2009 08:52:22 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 012EDC002F; Fri, 6 Feb 2009 08:52:21 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id DBA009618CD; Fri, 6 Feb 2009 08:52:20 +0100 (CET) Date: Fri, 6 Feb 2009 08:52:20 +0100 From: Juergen Schoenwaelder To: David Kessens Message-ID: <20090206075220.GA3565@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Kessens , Martin Bjorklund , netmod@ietf.org References: <20081218161426.GD6703@elstar.local> <20090205.222254.173558994.mbj@tail-f.com> <20090205225408.GD18938@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090205225408.GD18938@nsn.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] ipv4-prefix / ipv6-prefix normalization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:52:29 -0000 On Thu, Feb 05, 2009 at 02:54:08PM -0800, David Kessens wrote: > Note that http://tools.ietf.org/html/rfc4291 says in section "2.2. > Text Representation of Addresses": > > 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to > four hexadecimal digits of the eight 16-bit pieces of the address. > > The abbreviated form is available for convenience. Basically, do > we really want to do something else than the "preferred" format which > is unambiguous and clear although a bit long ? >From a format point of view, this is a defendable position. However, since most inet_ntop() implementations seem to suppress 0s, this simply not the representation generated by many devices (and this is probably most notable when we consider ::1). On the other hand, since 0 supression rules do not seem the same everywhere, a portable implementation can't rely on inet_ntop() anyway. /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 Fri Feb 6 02:02: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 D47C23A6B68 for ; Fri, 6 Feb 2009 02:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq592xt6dYTJ for ; Fri, 6 Feb 2009 02:02:57 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DD1133A6BB3 for ; Fri, 6 Feb 2009 02:02:56 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0BDB376C2AC; Fri, 6 Feb 2009 11:02:57 +0100 (CET) Date: Fri, 06 Feb 2009 11:02:56 +0100 (CET) Message-Id: <20090206.110256.177637688.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090205.222129.169856078.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] yang-03, sec 9.9.6, leafref 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: Fri, 06 Feb 2009 10:02:57 -0000 WashamFan wrote: > where is Bug, now fixed. /martin From david.partain@ericsson.com Mon Feb 9 06:00: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 4ABF43A6C92 for ; Mon, 9 Feb 2009 06:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q6-W1VsFLua for ; Mon, 9 Feb 2009 06:00:22 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 945C73A6C32 for ; Mon, 9 Feb 2009 06:00:22 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8CB03208EE for ; Mon, 9 Feb 2009 15:00:26 +0100 (CET) X-AuditID: c1b4fb3c-aca88bb00000127c-42-499036f9d828 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F0A4820969 for ; Mon, 9 Feb 2009 15:00:25 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 15:00:17 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 15:00:17 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 9 Feb 2009 15:00:17 +0100 User-Agent: KMail/1.9.10 References: <20081230.143906.130384865.mbj@tail-f.com> <495A5A27.4010100@netconfcentral.com> <20090105.110118.138972369.mbj@tail-f.com> In-Reply-To: <20090105.110118.138972369.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902091500.17517.david.partain@ericsson.com> X-OriginalArrivalTime: 09 Feb 2009 14:00:17.0622 (UTC) FILETIME=[BD021760:01C98ABE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 14:00:28 -0000 On Monday 05 January 2009 11.01.18 Martin Bjorklund wrote: > Andy Bierman wrote: > > XPath parsers will not accept the "+/- exponent" part, > > and will (incorrectly) accept an AdditiveExpr [rule 25] instead. > > > > Since that won't work, even though it exactly meets > > the real needs of the NETCONF community, setting > > the precision manually for the %f option seems > > the obvious next choice. The values to set manually > > are not so obvious. > > So, to summarize... we'd like to be compatible with existing > technology. At a first glance, XSD seems to be the obvious candidate, > but XSD defines the canonical form to be in a form that XPath does not > understand. So if we use the XSD definition, XPath won't work. > > So we need to come up with our own definition. > > So, what value should we use for the precision in %f? Is there a > theoretical maximum we could use? Otherwise we'll have to pick a > "large" number. Unfortunately, %f pads with trailing zeros, but OTOH, > since it's straightforward to remove these trailing zeros after the > call to snprintf, we could state that trailing zeros are removed in > the canonical form. > > Also, if we use "%f" we might want to align our "[-]INF" and "NaN" to > "[-]inf" and "nan". As this issue remains in -03 (see section 9.3.2)... and the thread went cold about a month ago. I'd like to see comments on Martin's suggestion (that we come up with our own definition and that we use %f). To me, this seems like a reasonable way of dealing with this. Cheers, David From andy@netconfcentral.com Mon Feb 9 06:30: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 323CD3A6C7F for ; Mon, 9 Feb 2009 06:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.070, 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 7U9UtPa+C+jl for ; Mon, 9 Feb 2009 06:30:09 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id E5B323A6AED for ; Mon, 9 Feb 2009 06:30:09 -0800 (PST) Received: (qmail 91826 invoked from network); 9 Feb 2009 14:30:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.203 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 9 Feb 2009 14:30:14 -0000 X-YMail-OSG: pTkPH9cVM1lvht4d4NxHhW.0wqHlA7La2efVw_ZNmgbMWuDk8JX8DjHwi1F3kYYRgW8usO9fi3.3GthtCLQZ.Nk3A1.bC1o.SwzqcPvCC7Z7Mxpg.h4uJ9g_XVefJzG7HIQE6oScxP6AASKGCes.UZdFu5Nd_.gAfcJCIT3V6lxyiFTdKoPvF.uS8j.ucU8.cGuifufzEEkgoeW4fDC81A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49903DF4.1050001@netconfcentral.com> Date: Mon, 09 Feb 2009 06:30:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Partain References: <20081230.143906.130384865.mbj@tail-f.com> <495A5A27.4010100@netconfcentral.com> <20090105.110118.138972369.mbj@tail-f.com> <200902091500.17517.david.partain@ericsson.com> In-Reply-To: <200902091500.17517.david.partain@ericsson.com> Content-Type: multipart/mixed; boundary="------------000105040503080908030108" Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 14:30:11 -0000 This is a multi-part message in MIME format. --------------000105040503080908030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Partain wrote: > On Monday 05 January 2009 11.01.18 Martin Bjorklund wrote: >> Andy Bierman wrote: >>> XPath parsers will not accept the "+/- exponent" part, >>> and will (incorrectly) accept an AdditiveExpr [rule 25] instead. >>> >>> Since that won't work, even though it exactly meets >>> the real needs of the NETCONF community, setting >>> the precision manually for the %f option seems >>> the obvious next choice. The values to set manually >>> are not so obvious. >> So, to summarize... we'd like to be compatible with existing >> technology. At a first glance, XSD seems to be the obvious candidate, >> but XSD defines the canonical form to be in a form that XPath does not >> understand. So if we use the XSD definition, XPath won't work. >> >> So we need to come up with our own definition. >> >> So, what value should we use for the precision in %f? Is there a >> theoretical maximum we could use? Otherwise we'll have to pick a >> "large" number. Unfortunately, %f pads with trailing zeros, but OTOH, >> since it's straightforward to remove these trailing zeros after the >> call to snprintf, we could state that trailing zeros are removed in >> the canonical form. >> >> Also, if we use "%f" we might want to align our "[-]INF" and "NaN" to >> "[-]inf" and "nan". > > > As this issue remains in -03 (see section 9.3.2)... and the thread went cold > about a month ago. > > I'd like to see comments on Martin's suggestion (that we come up with our own > definition and that we use %f). To me, this seems like a reasonable way of > dealing with this. > I did some experiments: - %.14f seems to be safest, although sometimes 15 decimal places of precision is OK. - the only glibc option that matches YANG and XPath is %f, and you have to manually remove trailing zeros and maybe the decimal point as well. - strtof is broken in glibc, so float32 is quite problematic. strtod works fine, so 'double' is not affected, just 'float'. (try strtof('1.3')). - I prefer to use the glibc names for inf, -inf, and nan, instead of inventing new terms. Attached is a terse summary of the precision issue (x.c and its output) > Cheers, > > David Andy --------------000105040503080908030108 Content-Type: text/plain; name="x.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x.c" #include int main (void) { double d; d = 1.3; printf("\n%.14f", d); printf("\n%.15f", d); printf("\n%.16f", d); printf("\n%.17f", d); printf("\n%.18f", d); printf("\n"); d = 1.99999999999999; printf("\n%.14f", d); printf("\n%.15f", d); printf("\n%.16f", d); printf("\n%.17f", d); printf("\n%.18f", d); printf("\n"); d = 1.999999999999999; printf("\n%.14f", d); printf("\n%.15f", d); printf("\n%.16f", d); printf("\n%.17f", d); printf("\n%.18f", d); printf("\n"); d = 1.9999999999999999; printf("\n%.14f", d); printf("\n%.15f", d); printf("\n%.16f", d); printf("\n%.17f", d); printf("\n%.18f", d); printf("\n"); return 0; } --------------000105040503080908030108 Content-Type: text/plain; name="x.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x.log" 1.30000000000000 1.300000000000000 1.3000000000000000 1.30000000000000004 1.300000000000000044 1.99999999999999 1.999999999999990 1.9999999999999900 1.99999999999999001 1.999999999999990008 2.00000000000000 1.999999999999999 1.9999999999999989 1.99999999999999889 1.999999999999998890 2.00000000000000 2.000000000000000 2.0000000000000000 2.00000000000000000 2.000000000000000000 --------------000105040503080908030108-- From j.schoenwaelder@jacobs-university.de Mon Feb 9 06:33:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDEA28C0F3 for ; Mon, 9 Feb 2009 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Q5V1frXazIYq for ; Mon, 9 Feb 2009 06:33:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7BE573A6BA0 for ; Mon, 9 Feb 2009 06:33:01 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D9CBC0056; Mon, 9 Feb 2009 15:33:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A2bwdRonKxNX; Mon, 9 Feb 2009 15:32:58 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6574C0049; Mon, 9 Feb 2009 15:32:57 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id BA43C989807; Mon, 9 Feb 2009 15:32:56 +0100 (CET) Date: Mon, 9 Feb 2009 15:32:56 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Partain , netmod@ietf.org References: <20081230.143906.130384865.mbj@tail-f.com> <495A5A27.4010100@netconfcentral.com> <20090105.110118.138972369.mbj@tail-f.com> <200902091500.17517.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902091500.17517.david.partain@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 14:33:03 -0000 On Mon, Feb 09, 2009 at 03:00:17PM +0100, David Partain wrote: > On Monday 05 January 2009 11.01.18 Martin Bjorklund wrote: > > Andy Bierman wrote: > > > XPath parsers will not accept the "+/- exponent" part, > > > and will (incorrectly) accept an AdditiveExpr [rule 25] instead. > > > > > > Since that won't work, even though it exactly meets > > > the real needs of the NETCONF community, setting > > > the precision manually for the %f option seems > > > the obvious next choice. The values to set manually > > > are not so obvious. > > > > So, to summarize... we'd like to be compatible with existing > > technology. At a first glance, XSD seems to be the obvious candidate, > > but XSD defines the canonical form to be in a form that XPath does not > > understand. So if we use the XSD definition, XPath won't work. > > > > So we need to come up with our own definition. > > > > So, what value should we use for the precision in %f? Is there a > > theoretical maximum we could use? Otherwise we'll have to pick a > > "large" number. Unfortunately, %f pads with trailing zeros, but OTOH, > > since it's straightforward to remove these trailing zeros after the > > call to snprintf, we could state that trailing zeros are removed in > > the canonical form. > > > > Also, if we use "%f" we might want to align our "[-]INF" and "NaN" to > > "[-]inf" and "nan". > > > As this issue remains in -03 (see section 9.3.2)... and the thread > went cold about a month ago. > > I'd like to see comments on Martin's suggestion (that we come up > with our own definition and that we use %f). To me, this seems like > a reasonable way of dealing with this. I understanding is that %f alone limits the precision to 6 digits which is likely not what we want. So what is the suggested precision? /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 Feb 9 08:47: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 A8B4E3A69B1 for ; Mon, 9 Feb 2009 08:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6ofJibtGjLS for ; Mon, 9 Feb 2009 08:47:09 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 11AFA3A6874 for ; Mon, 9 Feb 2009 08:47:05 -0800 (PST) Received: (qmail 395 invoked from network); 9 Feb 2009 16:47:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.203 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 9 Feb 2009 16:47:07 -0000 X-YMail-OSG: KYh45yoVM1kLjZbyJcf5iVP.CNH2Q4q0mUfaVhbaimhnNyefhz3j1KPwL2d6cH87.yQrF61ilXIEdThX5uV9BzDnPeb2ooPJhc.jzdyYfmjyYvSIA0H4aTO9P1SgRPALeHpRN02p6H1IeMqd5L9kQdeG X-Yahoo-Newman-Property: ymail-3 Message-ID: <49905E0A.4090109@netconfcentral.com> Date: Mon, 09 Feb 2009 08:47:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Feb 2009 16:47:09 -0000 Hi, I really do not like the 2nd para of 9.2.1, because it creates a lot of confusion with XML and XPath. It requires that implementations and users be aware of the context in which a leading zero is used (XML or YANG). 033 is an octal number in a YANG default but a valid decimal number everywhere else. 08 and 09 are invalid octal numbers in YANG but are valid decimal numbers everywhere else. IMO, this is confusing. I do not understand why octal notation needs to be supported. Hex notation is more modern, and should be sufficient. Andy From david.kessens@nsn.com Mon Feb 9 11:17: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 C49FC28C16E for ; Mon, 9 Feb 2009 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmVRvA0yfXqi for ; Mon, 9 Feb 2009 11:17:47 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D2CBD28C16D for ; Mon, 9 Feb 2009 11:17:46 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n19JHVR6010972; Mon, 9 Feb 2009 21:17:47 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 21:17:36 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 21:17:35 +0200 Received: from localhost.localdomain ([10.241.59.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 21:17:32 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n19JHU38011224; Mon, 9 Feb 2009 11:17:30 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n19JHTKl011223; Mon, 9 Feb 2009 11:17:29 -0800 Date: Mon, 9 Feb 2009 11:17:29 -0800 From: David Kessens To: Andy Bierman Message-ID: <20090209191729.GD4313@nsn.com> References: <49905E0A.4090109@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49905E0A.4090109@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 09 Feb 2009 19:17:35.0220 (UTC) FILETIME=[104D0340:01C98AEB] X-Nokia-AV: Clean Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Feb 2009 19:17:47 -0000 On Mon, Feb 09, 2009 at 08:47:06AM -0800, Andy Bierman wrote: > > I do not understand why octal notation needs to be supported. > Hex notation is more modern, and should be sufficient. I agree (speaking as an individual working group contributor). Speaking as one of the cochairs: Our charter is fairly tight in terms of timelines. We can have long discussions on features/options that might be useful but that we have no actual users for. Or we can move on and remove such things and work on more important issues that actually make a difference. Basically, when there is doubt about something, in the interest of meeting our timelines it seems prudent to have a bias towards making things simpler. Obviously, this message is not to overrule anybodies opinion, but a reminder that we need to keep our timelines in mind as well when discussing features/options etc. David Kessens --- From randy_presuhn@mindspring.com Mon Feb 9 12:11: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 3407D3A68AC for ; Mon, 9 Feb 2009 12:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq-MRUTlnhCN for ; Mon, 9 Feb 2009 12:11:22 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 73B463A67D6 for ; Mon, 9 Feb 2009 12:11:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OthXBxEW8vNreka0MHJ2aZRMDiNz7pux5lvmK/X1XOLftKq/8I7yp+BCxf7ifwaa; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.85] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LWcTS-0002rB-Gy for netmod@ietf.org; Mon, 09 Feb 2009 15:11:22 -0500 Message-ID: <004701c98af2$8cdecc20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20081230.143906.130384865.mbj@tail-f.com> <495A5A27.4010100@netconfcentral.com> <20090105.110118.138972369.mbj@tail-f.com><200902091500.17517.david.partain@ericsson.com> <49903DF4.1050001@netconfcentral.com> Date: Mon, 9 Feb 2009 12:11:09 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17343d8c0fc578731e7d953675e076ee3f9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.85 Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 20:11:23 -0000 Hi - > From: "Andy Bierman" > To: "David Partain" > Cc: > Sent: Monday, February 09, 2009 6:30 AM > Subject: Re: [netmod] canonical form of floats ... > Attached is a terse summary of the precision issue (x.c and its output) ... Thanks for making such a clear demonstration of why converting things to floats may have results surprising to many humans, and why the choice of comparison as string / comparison as float / comparison of internal representation of whatever the data type is matters. In addition to the precision issue, there's also a question of accuracy (e.g, 1.3 does not have an exact representation), as well as the question of how you'd like the various flavours of NaN, negative zero, and so on to appear. Randy From mbj@tail-f.com Mon Feb 9 12:46: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 BE07B3A6BB2 for ; Mon, 9 Feb 2009 12:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2jyQgXiGNtp for ; Mon, 9 Feb 2009 12:46:08 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D14723A68AC for ; Mon, 9 Feb 2009 12:46:07 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6B30476C322; Mon, 9 Feb 2009 21:46:08 +0100 (CET) Date: Mon, 09 Feb 2009 21:46:08 +0100 (CET) Message-Id: <20090209.214608.218111424.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <498B8EB9.1060201@netconfcentral.com> References: <498B8EB9.1060201@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] require-instance error-app-tag X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Feb 2009 20:46:08 -0000 Andy Bierman wrote: > Hi, > > There doesn't seem to be any good error codes for a > require-instance = true violation for a leafref or instance-identifier. > Perhaps a new error-app-tag and sub-section of 13.x should be > added to make that stand out, especially since the default > is true. I agree. 'missing-instance' is already used. How about 'instance-required'? What should the error-tag be? 'operation-failed', or could 'data-missing' be used? /martin From mbj@tail-f.com Mon Feb 9 12:48: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 1E10D3A6B07 for ; Mon, 9 Feb 2009 12:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izjs9v7-plWK for ; Mon, 9 Feb 2009 12:48:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 47C3E3A68AC for ; Mon, 9 Feb 2009 12:48:18 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5867776C322; Mon, 9 Feb 2009 21:48:20 +0100 (CET) Date: Mon, 09 Feb 2009 21:48:20 +0100 (CET) Message-Id: <20090209.214820.126439217.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <498B8D20.5060003@netconfcentral.com> References: <498B572B.40809@netconfcentral.com> <20090205.224225.50451258.mbj@tail-f.com> <498B8D20.5060003@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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Feb 2009 20:48:19 -0000 Hi, Andy Bierman wrote: > One more big leafref/instance-identifier open issue I just > thought of. The text seems to imply that the require-instance > check is applied when the value is created. That's not the intention. > This is of course > not the case for , only for . > We must not introduce PDU order dependencies, > that we have been careful to avoid so far. The current text says: All leafref nodes MUST reference existing leaf instances for the data to be valid. This constraint is enforced according to the rules in ^constraints^. And @constraints@ says: - If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. And *** Validation says: When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing time according to the datastore. If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. What needs to be done to make it more clear? /martin From andy@netconfcentral.com Mon Feb 9 13: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 D14553A6BB4 for ; Mon, 9 Feb 2009 13:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-wt8d1+Q7PC for ; Mon, 9 Feb 2009 13:38:52 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 423743A68AC for ; Mon, 9 Feb 2009 13:38:51 -0800 (PST) Received: (qmail 13441 invoked from network); 9 Feb 2009 21:38:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.203 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 9 Feb 2009 21:38:52 -0000 X-YMail-OSG: WOKy0CcVM1kCQM6t0du08u_MeoCI3FERgjVqkYd6NZy7gu970GOJhdPMKwEdbe9epLNtGpWDMvJ_GGGAFVKpiCcGmrPvVHwklYn9.WtuxTPziXGtToKpuGTxvfUvNHNeXExKzzNK1p6EMUCzBth5CHtV1SyPTmwWHkza_F4JLJlWGZpAFX5Xht7ir0wEHFoCLKwA8B1lPO0XE3mrU6aNcg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4990A26A.5010201@netconfcentral.com> Date: Mon, 09 Feb 2009 13:38:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <498B572B.40809@netconfcentral.com> <20090205.224225.50451258.mbj@tail-f.com> <498B8D20.5060003@netconfcentral.com> <20090209.214820.126439217.mbj@tail-f.com> In-Reply-To: <20090209.214820.126439217.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] instance-identifier bugs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Feb 2009 21:38:52 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> One more big leafref/instance-identifier open issue I just >> thought of. The text seems to imply that the require-instance >> check is applied when the value is created. > > That's not the intention. > >> This is of course >> not the case for , only for . >> We must not introduce PDU order dependencies, >> that we have been careful to avoid so far. > > The current text says: > > All leafref nodes MUST reference existing leaf instances for the > data to be valid. This constraint is enforced according to the > rules in ^constraints^. > > And @constraints@ says: > > - If the constraint is defined on configuration data, it MUST be true in > a valid configuration data tree. > > And *** Validation says: > > When datastore processing is complete, the final contents MUST obey > all validation constraints. This validation processing is performed > at differing time according to the datastore. If the datastore is > or , these constraints MUST be enforced at the > end of the or operation. If the > datastore is , the constraint enforcement is delayed > until a or operation. > > > What needs to be done to make it more clear? > This is good enough. The constraints could say that only the configuration is required to be valid at all times. (If not, the agent has a bug, or maybe the YANG file is wrong.) IMO, startup is an open-issue. There is a use-case for allowing it to be invalid within the current running agent: 1) copy-config(next-config, startup) 2) upload-next-image(image-file) 3) reboot NETCONF access to startup is not mandatory anyway. For , this config is never required to be valid. The operation applies the requested changes to , and that is the config database that must be valid. > > > /martin > Andy From andy@netconfcentral.com Mon Feb 9 17:16: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 528553A6D52 for ; Mon, 9 Feb 2009 17:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRidnhWjOEE2 for ; Mon, 9 Feb 2009 17:16:52 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 739D73A6D56 for ; Mon, 9 Feb 2009 17:16:51 -0800 (PST) Received: (qmail 74215 invoked from network); 10 Feb 2009 01:16:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.203 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 10 Feb 2009 01:16:53 -0000 X-YMail-OSG: _rbSfpcVM1ngAb0lReDiUPhQenAU4uL8fsv0EOf9jXKNjVCZqu92vR6g575_U06h9NEL.nHRVK1igHp9erADTSTrHXcy305M_nrZMQlKfH8pcEVgG_VlzLKnAWSUTFqJ6_ttWTaN7J5m64TYn3AoPD3N X-Yahoo-Newman-Property: ymail-3 Message-ID: <4990D582.7000102@netconfcentral.com> Date: Mon, 09 Feb 2009 17:16:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Kessens References: <49905E0A.4090109@netconfcentral.com> <20090209191729.GD4313@nsn.com> In-Reply-To: <20090209191729.GD4313@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Feb 2009 01:16:56 -0000 David Kessens wrote: > On Mon, Feb 09, 2009 at 08:47:06AM -0800, Andy Bierman wrote: >> I do not understand why octal notation needs to be supported. >> Hex notation is more modern, and should be sufficient. > > I agree (speaking as an individual working group contributor). > > Speaking as one of the cochairs: > > Our charter is fairly tight in terms of timelines. > We can have long discussions on features/options that might > be useful but that we have no actual users for. > Or we can move on and remove such things and work on more important issues > that actually make a difference. > > Basically, when there is doubt about something, in the interest of > meeting our timelines it seems prudent to have a bias towards making > things simpler. Obviously, this message is not to overrule anybodies > opinion, but a reminder that we need to keep our timelines in mind as > well when discussing features/options etc. > Does simpler mean leave octal in YANG and move on? I don't care that much. Nobody is ever going to think of using octal notation anyway. Most people know to avoid leading zeros in integers as well, so the problem will not likely show up. It seems a bit odd to be worried about the YANG draft milestone now (due in September), while the architecture draft WGLC milestone (due in February) or the initial draft of the the architecture draft (due last October) does not raise any flags. > David Kessens > --- > Andy From andy@netconfcentral.com Mon Feb 9 17:39: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 204903A6919 for ; Mon, 9 Feb 2009 17:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgHa5ryCELQK for ; Mon, 9 Feb 2009 17:39:40 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 675A43A6B5E for ; Mon, 9 Feb 2009 17:39:40 -0800 (PST) Received: (qmail 45728 invoked from network); 10 Feb 2009 01:39:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.203 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 10 Feb 2009 01:39:42 -0000 X-YMail-OSG: akCuMN8VM1lLpq1Vz5Qs7EbLJvlogs4gia61YY5CQ60InpidfuvNUJoCQNCqbTLD3QHTwpNPT1tl3A0zGU75aUy73wKGDuoVQDNoZjotp5U1twHYuF560ftRN6were_Gl7dLlUqaTrTYXcOsvl9XRMHJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4990DADB.8070409@netconfcentral.com> Date: Mon, 09 Feb 2009 17:39:39 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 01:39:41 -0000 Hi, I do not understand how the text in 7.8.3 is supposed to be implemented for complex examples, where 2 or more leaf targets in the unique-stmt are nested inside other lists: list foo { key a; unique "b bb/bbb cc/ccc"; leaf a { type string; } leaf b { type string; } list bb { key bbkey; leaf bbkey { type string; } leaf bbb { type string; } } list cc { key cckey; leaf cckey { type string; } leaf ccc { type string; } } } I do not understand which instances get compared in each 3-tuple, since 'bb' and 'cc' are different lists and have nothing to do with each other. The trivial example in the draft makes sense to me, because all the nodes in the unique-stmt are siblings of each other. I prefer that a CLR be added that unique-stmt tuple members MUST be siblings (even if they are nested in many lists). If not, then lots more text is needed explaining the expected behavior for the unique-stmt. Andy From david.kessens@nsn.com Mon Feb 9 18:16: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 12C9B28C182 for ; Mon, 9 Feb 2009 18:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWc6nv42JteM for ; Mon, 9 Feb 2009 18:16:55 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A042828C19A for ; Mon, 9 Feb 2009 18:16:54 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1A2Gopo030741; Tue, 10 Feb 2009 04:16:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 04:16:49 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 04:16:49 +0200 Received: from localhost.localdomain ([10.241.59.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 04:16:47 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n1A2GknN029876; Mon, 9 Feb 2009 18:16:46 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n1A2Gj5A029875; Mon, 9 Feb 2009 18:16:45 -0800 Date: Mon, 9 Feb 2009 18:16:45 -0800 From: David Kessens To: Andy Bierman Message-ID: <20090210021645.GJ4313@nsn.com> References: <49905E0A.4090109@netconfcentral.com> <20090209191729.GD4313@nsn.com> <4990D582.7000102@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4990D582.7000102@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 10 Feb 2009 02:16:48.0574 (UTC) FILETIME=[A0DE3DE0:01C98B25] X-Nokia-AV: Clean Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Feb 2009 02:16:56 -0000 Andy, On Mon, Feb 09, 2009 at 05:16:50PM -0800, Andy Bierman wrote: > > Does simpler mean leave octal in YANG and move on? > I don't care that much. Nobody is ever going to think > of using octal notation anyway. Most people know > to avoid leading zeros in integers as well, so > the problem will not likely show up. I think I was pretty clear by stating (my personal opinion) that I agreed with you: if there is no obvious use for it remove it. Keeping it means more rules and complexity in order to keep apart the different representations. > It seems a bit odd to be worried about the YANG draft > milestone now (due in September), while the architecture draft WGLC > milestone (due in February) or the initial draft of the the > architecture draft (due last October) does not raise any flags. We are and should be concerned about all the milestones in general. This issue just happened to be a nice example to raise awareness of such concerns. David Kessens --- From andy@netconfcentral.com Mon Feb 9 20:45: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 C6A6B3A6A80 for ; Mon, 9 Feb 2009 20:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S0+aqLlWd+l for ; Mon, 9 Feb 2009 20:45:56 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 2F2A13A68F4 for ; Mon, 9 Feb 2009 20:45:56 -0800 (PST) Received: (qmail 98679 invoked from network); 10 Feb 2009 04:45:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 10 Feb 2009 04:45:58 -0000 X-YMail-OSG: 2SUPRsoVM1k5qbKERFvC80dPuaLm9aPw_9sv3skTGWs8KBzXSwdYlWkRkDWT_bWQexOzPYRVlg4tH6uUUj00TTsGMbsU6dZ9yoQPglyJSv7K6CHnTwgAB_Mwep0cCW7aXSHCum4eCXBB1NHonNXB_B4m X-Yahoo-Newman-Property: ymail-3 Message-ID: <49910684.9010802@netconfcentral.com> Date: Mon, 09 Feb 2009 20:45:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Kessens References: <49905E0A.4090109@netconfcentral.com> <20090209191729.GD4313@nsn.com> <4990D582.7000102@netconfcentral.com> <20090210021645.GJ4313@nsn.com> In-Reply-To: <20090210021645.GJ4313@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Feb 2009 04:45:56 -0000 David Kessens wrote: > Andy, > > On Mon, Feb 09, 2009 at 05:16:50PM -0800, Andy Bierman wrote: >> Does simpler mean leave octal in YANG and move on? >> I don't care that much. Nobody is ever going to think >> of using octal notation anyway. Most people know >> to avoid leading zeros in integers as well, so >> the problem will not likely show up. > > I think I was pretty clear by stating (my personal opinion) that I > agreed with you: if there is no obvious use for it remove it. Keeping > it means more rules and complexity in order to keep apart the > different representations. > I found a workaround in the code, which is simply to run the 'number-format' test according to the YANG rules, but for XML/XPath, if the answer is 'octal', change it to 'decimal'. (Then run strtol with a forced radix). The issue before was that somebody will expect octal to be supported, because the 'strtol' fn supports octal. The 'least astonishment' principle is quite subjective, changing the notion of 'expected behavior' for each person. >> It seems a bit odd to be worried about the YANG draft >> milestone now (due in September), while the architecture draft WGLC >> milestone (due in February) or the initial draft of the the >> architecture draft (due last October) does not raise any flags. > > We are and should be concerned about all the milestones in general. > This issue just happened to be a nice example to raise awareness of > such concerns. > I want to get done ASAP too. We should hurry the other drafts up, not slow down on YANG. > David Kessens > --- > Andy From johan.rydberg@edgeware.tv Tue Feb 10 00:23:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD42E3A6B9E for ; Tue, 10 Feb 2009 00:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIwDMsDeUiL7 for ; Tue, 10 Feb 2009 00:23:23 -0800 (PST) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id 355B63A688C for ; Tue, 10 Feb 2009 00:23:21 -0800 (PST) Received: from [192.168.99.223] (unknown [192.168.99.223]) by mail.edgeware.tv (Postfix) with ESMTPSA id 8889F51B608E; Tue, 10 Feb 2009 09:23:08 +0100 (CET) Message-ID: <49913973.2010308@edgeware.tv> Date: Tue, 10 Feb 2009 09:23:15 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andy Bierman References: <49905E0A.4090109@netconfcentral.com> In-Reply-To: <49905E0A.4090109@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Feb 2009 08:23:24 -0000 Andy Bierman skrev: > I do not understand why octal notation needs to be supported. > Hex notation is more modern, and should be sufficient. I for one use have a "umask" leaf in my data model, and file permissions in UNIX tend to be defined using octal numbers. It will be horrible to have to convert those to hex-humbers or decimal. From andy@netconfcentral.com Tue Feb 10 03:38:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E4E3A6901 for ; Tue, 10 Feb 2009 03:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLczHbzwILnU for ; Tue, 10 Feb 2009 03:38:23 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 049F33A6998 for ; Tue, 10 Feb 2009 03:38:22 -0800 (PST) Received: (qmail 51528 invoked from network); 10 Feb 2009 11:38:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 10 Feb 2009 11:38:25 -0000 X-YMail-OSG: fygqmRIVM1lEUyf1PR5nJzw4UEiXy8X1QvoADSbQI7QRgcUqR4RoCyCSn02ZXgajBkt0qC1wP.I.dyQgbo1No1C0g4bSw7ovCV0ToSUN4tIie7wEyDL4MVkP3AYySjWlbl6WqAsYyeilbaJGbCsypkuH X-Yahoo-Newman-Property: ymail-3 Message-ID: <49916730.3080402@netconfcentral.com> Date: Tue, 10 Feb 2009 03:38:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Johan Rydberg References: <49905E0A.4090109@netconfcentral.com> <49913973.2010308@edgeware.tv> In-Reply-To: <49913973.2010308@edgeware.tv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Feb 2009 11:38:24 -0000 Johan Rydberg wrote: > Andy Bierman skrev: > >> I do not understand why octal notation needs to be supported. >> Hex notation is more modern, and should be sufficient. > > I for one use have a "umask" leaf in my data model, and file > permissions in UNIX tend to be defined using octal numbers. > > It will be horrible to have to convert those to hex-humbers > or decimal. > > You understand that octal is only available for the the default-stmt, and not for setting the value via NETCONF, right? There is no built-in type called 'octal', just a YANG file data format. Andy From johan.rydberg@edgeware.tv Tue Feb 10 04:23:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF573A67F5 for ; Tue, 10 Feb 2009 04:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXao5GAj5yoO for ; Tue, 10 Feb 2009 04:23:38 -0800 (PST) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id C09763A6B40 for ; Tue, 10 Feb 2009 04:23:37 -0800 (PST) Received: from [192.168.99.223] (unknown [192.168.99.223]) by mail.edgeware.tv (Postfix) with ESMTPSA id 87D2A51B6095; Tue, 10 Feb 2009 13:23:21 +0100 (CET) Message-ID: <499171C0.6070102@edgeware.tv> Date: Tue, 10 Feb 2009 13:23:28 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andy Bierman References: <49905E0A.4090109@netconfcentral.com> <49913973.2010308@edgeware.tv> <49916730.3080402@netconfcentral.com> In-Reply-To: <49916730.3080402@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Feb 2009 12:23:39 -0000 > You understand that octal is only available for the > the default-stmt, and not for setting the value via NETCONF, right? > There is no built-in type called 'octal', just a YANG file data format. Of course! From david.partain@ericsson.com Wed Feb 11 02:22: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 D14A93A67EE for ; Wed, 11 Feb 2009 02:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbOYPp95Icoy for ; Wed, 11 Feb 2009 02:22:13 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C61BD3A68AD for ; Wed, 11 Feb 2009 02:22:12 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A525B200B8 for ; Wed, 11 Feb 2009 11:22:15 +0100 (CET) X-AuditID: c1b4fb3e-ad8bebb000001315-5f-4992a6d73e3b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8C868211DF for ; Wed, 11 Feb 2009 11:22:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 11:22:15 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.32.77]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 11:22:15 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 11 Feb 2009 11:22:18 +0100 User-Agent: KMail/1.9.10 References: <200901061611.n06GBhEO047660@idle.juniper.net> <49638BD7.90200@netconfcentral.com> In-Reply-To: <49638BD7.90200@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111122.19156.david.partain@ericsson.com> X-OriginalArrivalTime: 11 Feb 2009 10:22:15.0027 (UTC) FILETIME=[9C000430:01C98C32] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] canonical order X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 10:22:13 -0000 Hi, An unclosed thread... On Tuesday 06 January 2009 17.50.31 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> Do we at least agree that the order must be consistent within > >> a single implementation? > > > > Sounded like you and Martin disagree on whether XPath allows this > > sort of order issues. Within a single element type, I don't see > > how para[3] could differ between implementations, but I certainly > > see that *[3] or node()[3] would be implementation specific. > > We are just talking about 1 manager issuing a > or a with a an XPath filter to 1 particular agent. > > If the manager issues the same command 2 times in a row > with the same XPath (I don't care what it is), and no nodes > have been added or removed from the database, > and no values in the database have changed at all: > > Will the manager get the same answer or not? > > If not, why not? > > I understand that results from different agents > may not be the same, even for the same (*) > database contents. > > > * configurations can only be compared outside the database, > represented as XML documents. Previously, Andy also wrote: > Do we at least agree that the order must be consistent within > a single implementation? > If the affected portion of the database has not > changed at all, and if a manager retrieves /foo[3] or > runs a must-test on /foo[3] at T0 and then T1, will > the result be the same each time? > IMO, MUST be yes. I absolutely think that, within an implementation, this should be consistent. Should the text that Andy suggested be added? David From david.partain@ericsson.com Wed Feb 11 02:32: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 D74D93A6AB9 for ; Wed, 11 Feb 2009 02:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSEjOEosqGm4 for ; Wed, 11 Feb 2009 02:32:18 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0F9C43A6A4F for ; Wed, 11 Feb 2009 02:32:17 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D97B220D49 for ; Wed, 11 Feb 2009 11:32:20 +0100 (CET) X-AuditID: c1b4fb3c-ad289bb00000127c-24-4992a934beeb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BF9BC20CD5 for ; Wed, 11 Feb 2009 11:32:20 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 11:32:20 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.32.77]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 11:32:20 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 11 Feb 2009 11:32:24 +0100 User-Agent: KMail/1.9.10 References: <49905E0A.4090109@netconfcentral.com> <49916730.3080402@netconfcentral.com> <499171C0.6070102@edgeware.tv> In-Reply-To: <499171C0.6070102@edgeware.tv> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111132.24894.david.partain@ericsson.com> X-OriginalArrivalTime: 11 Feb 2009 10:32:20.0339 (UTC) FILETIME=[04CB4C30:01C98C34] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 10:32:18 -0000 Hi, There's been an awful lot of mail about octal numbers... Could those who see a problem please suggest some delta text from the -03 draft so we'll have something concrete to decide on? Thanks. David From david.partain@ericsson.com Wed Feb 11 02:34: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 0620B3A694E for ; Wed, 11 Feb 2009 02:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxK8s+paH0A7 for ; Wed, 11 Feb 2009 02:34:31 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2DEF33A69F4 for ; Wed, 11 Feb 2009 02:34:31 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3568820FCA for ; Wed, 11 Feb 2009 11:34:34 +0100 (CET) X-AuditID: c1b4fb3e-ab8babb000001315-e8-4992a9bafc66 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1EC62206C1 for ; Wed, 11 Feb 2009 11:34:34 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 11:34:33 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.32.77]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 11:34:33 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 11 Feb 2009 11:34:38 +0100 User-Agent: KMail/1.9.10 References: <498B8EB9.1060201@netconfcentral.com> <20090209.214608.218111424.mbj@tail-f.com> In-Reply-To: <20090209.214608.218111424.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111134.38359.david.partain@ericsson.com> X-OriginalArrivalTime: 11 Feb 2009 10:34:33.0665 (UTC) FILETIME=[54433B10:01C98C34] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] require-instance error-app-tag X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 10:34:32 -0000 Hi, On Monday 09 February 2009 21.46.08 Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > There doesn't seem to be any good error codes for a > > require-instance = true violation for a leafref or instance-identifier. > > Perhaps a new error-app-tag and sub-section of 13.x should be > > added to make that stand out, especially since the default > > is true. > > I agree. 'missing-instance' is already used. How about > 'instance-required'? Seems fine to me. > What should the error-tag be? > 'operation-failed', or could 'data-missing' be used? data-missing makes good sense. David From lhotka@cesnet.cz Wed Feb 11 03:44: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 DF04C3A6CA4 for ; Wed, 11 Feb 2009 03:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, GB_I_LETTER=-2, 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 mKVcSYzqAtP9 for ; Wed, 11 Feb 2009 03:44:11 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7641B3A694E for ; Wed, 11 Feb 2009 03:44:11 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A7F1DD800C5 for ; Wed, 11 Feb 2009 12:44:10 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200902111132.24894.david.partain@ericsson.com> References: <49905E0A.4090109@netconfcentral.com> <49916730.3080402@netconfcentral.com> <499171C0.6070102@edgeware.tv> <200902111132.24894.david.partain@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 11 Feb 2009 12:44:10 +0100 Message-Id: <1234352650.6477.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 11:44:13 -0000 David Partain píše v St 11. 02. 2009 v 11:32 +0100: > Hi, > > There's been an awful lot of mail about octal numbers... > > Could those who see a problem please suggest some delta text from the -03 > draft so we'll have something concrete to decide on? See below. The same literal such as '010' meaning different things in a default statement and in XPath expressions could be very confusing. Lada --- draft-ietf-netmod-yang-03.txt 2009-01-19 14:46:03.000000000 +0100 +++ draft-ietf-netmod-yang-03.new 2009-02-11 12:41:58.000000000 +0100 @@ -6125,18 +6125,10 @@ is specified, "+" is assumed. For convenience, when specifying a default value for an integer in a - YANG module, an alternative lexicographic representation can be used, - which represents the value in a hexadecimal or octal notation. The - hexadecimal notation consists of an optional sign ("+" or "-"), the + YANG module, the hexadecimal notation can be used, + which consists of an optional sign ("+" or "-"), the characters "0x" followed a number of hexadecimal digits, where - letters may be upper- or lowercase. The octal notation consists of - an optional sign ("+" or "-"), the character "0" followed a number of - octal digits. - - Note that if a default value in a YANG module has a leading zero - ("0"), it is interpreted as an octal number. In the XML encoding, an - integer is always interpreted as a decimal number, and leading zeros - are allowed. + letters may be upper- or lowercase. Examples: @@ -6146,7 +6138,6 @@ -123 // legal negative value 0xf00f // legal positive hexadecimal value -0xf // legal negative hexadecimal value - 052 // legal positive octal value // illegal values - 1 // illegal intermediate space -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Feb 11 04:04: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 ECCE23A67B4 for ; Wed, 11 Feb 2009 04:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn+MYK2TgOpf for ; Wed, 11 Feb 2009 04:04:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3CED53A6A98 for ; Wed, 11 Feb 2009 04:04:43 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F48076C2AC; Wed, 11 Feb 2009 13:04:44 +0100 (CET) Date: Wed, 11 Feb 2009 13:04:44 +0100 (CET) Message-Id: <20090211.130444.93633765.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1234352650.6477.65.camel@missotis> References: <499171C0.6070102@edgeware.tv> <200902111132.24894.david.partain@ericsson.com> <1234352650.6477.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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 12:04:47 -0000 Ladislav Lhotka wrote: > The same literal such as '010' meaning different things in a > default statement and in XPath expressions could be very confusing. But with this logic we should also remove the hexadecimal notation. I think people will be able to understand that the notation for defaults is different. /martin From lhotka@cesnet.cz Wed Feb 11 04:17:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D033A657C for ; Wed, 11 Feb 2009 04:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=0.198, 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 u2hVuZEW9yGn for ; Wed, 11 Feb 2009 04:17:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AD4AB3A69FE for ; Wed, 11 Feb 2009 04:17:18 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 68C73D800BD; Wed, 11 Feb 2009 13:17:22 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090211.130444.93633765.mbj@tail-f.com> References: <499171C0.6070102@edgeware.tv> <200902111132.24894.david.partain@ericsson.com> <1234352650.6477.65.camel@missotis> <20090211.130444.93633765.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 11 Feb 2009 13:17:22 +0100 Message-Id: <1234354642.6477.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 12:17:24 -0000 Martin Bjorklund píše v St 11. 02. 2009 v 13:04 +0100: > Ladislav Lhotka wrote: > > The same literal such as '010' meaning different things in a > > default statement and in XPath expressions could be very confusing. > > But with this logic we should also remove the hexadecimal notation. No, the difference is that 0x10 is an error in XPath. > > I think people will be able to understand that the notation for > defaults is different. leaf umask { type uint8; default 0022; } leaf foo { when "../umask = 0022"; ... } This bug would be very easy to make and hard to spot. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Wed Feb 11 04:21:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246A43A6928 for ; Wed, 11 Feb 2009 04:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR1-784eseSf for ; Wed, 11 Feb 2009 04:21:48 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 106713A657C for ; Wed, 11 Feb 2009 04:21:48 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C1F820B8E for ; Wed, 11 Feb 2009 13:21:51 +0100 (CET) X-AuditID: c1b4fb3e-ac0bbbb000001315-14-4992c2defcb4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F2F1821247 for ; Wed, 11 Feb 2009 13:21:50 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 13:21:50 +0100 Received: from selic023.ki.sw.ericsson.se ([147.214.32.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 13:21:49 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 11 Feb 2009 13:21:54 +0100 User-Agent: KMail/1.9.10 References: <4984C6A6.6030904@netconfcentral.com> <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> <498B9E2B.6010504@netconfcentral.com> In-Reply-To: <498B9E2B.6010504@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111321.54894.david.partain@ericsson.com> X-OriginalArrivalTime: 11 Feb 2009 12:21:49.0905 (UTC) FILETIME=[508F8410:01C98C43] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] 2 more data 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: Wed, 11 Feb 2009 12:21:49 -0000 Hi, On Friday 06 February 2009 03.19.23 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Wed, Feb 04, 2009 at 07:53:07AM +0100, Martin Bjorklund wrote: > >>> I have not seen a qname in a YANG module yet but adding a > >>> definition of a qname type to yang-types should not be too > >>> difficult either. > >> > >> I think we should stick to the idea of being conservative in what we > >> add. > >> > >> FWIW, we support this type in our DML, but I haven't seen anyone using > >> it. > > > > Andy's YANG model for NETCONF uses qnames for things such as > > bad-attribute, bad-element, ok-element, err-element, and > > noop-element. Can you check whether you agree these are qnames? > > If you do agree, then it might be a reason to add a qname type. > > HTML: > http://www.netconfcentral.org/modules/xsd/2007-12-06 > > YANG: > http://www.netconfcentral.org/src/xsd_2007-12-06.yang > > > This is the 'work-in-progress' xsd.yang that I wrote awhile back. > It needs some 'pattern and XSD expert' to finish off some of > the string types. Not sure if you want to cherry-pick, > ignore, or consider a a standard xsd.yang module. > It's not very important, considering the current status of XSD > within the WG. But if there are some types that might get > replicated over and over, then it could be worth it. > > > And yes, it is likely that YANG modules using qname and xpath types > > are going to define NETCONF extensions (e.g., definition of new > > protocol operations) while normal data models may not need these types > > so much. I think that putting an xpath type in the yang-types draft is fine. I personally don't see any consensus on whether to move forward with a qname type or not. David From j.schoenwaelder@jacobs-university.de Wed Feb 11 04:57: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 042283A6A4F for ; Wed, 11 Feb 2009 04:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078, 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 QQuXxPcBqIbb for ; Wed, 11 Feb 2009 04:57:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C64B53A6935 for ; Wed, 11 Feb 2009 04:57:21 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB166C0017; Wed, 11 Feb 2009 13:57:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LRwoIbWmAMdq; Wed, 11 Feb 2009 13:57:18 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF593C003F; Wed, 11 Feb 2009 13:57:18 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 919F6992B9C; Wed, 11 Feb 2009 13:57:17 +0100 (CET) Date: Wed, 11 Feb 2009 13:57:17 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20090211125717.GB7552@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Partain , netmod@ietf.org References: <4984C6A6.6030904@netconfcentral.com> <20090204104837.GA29559@elstar.iuhb02.iu-bremen.de> <498B9E2B.6010504@netconfcentral.com> <200902111321.54894.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902111321.54894.david.partain@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] 2 more data types (!) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:57:23 -0000 On Wed, Feb 11, 2009 at 01:21:54PM +0100, David Partain wrote: > I think that putting an xpath type in the yang-types draft is fine. I > personally don't see any consensus on whether to move forward with a qname > type or not. I agree. /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 Wed Feb 11 06:59: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 CBD113A69D0 for ; Wed, 11 Feb 2009 06:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.079, 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 pAniUNFj0T6y for ; Wed, 11 Feb 2009 06:59:07 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 253F33A68D7 for ; Wed, 11 Feb 2009 06:59:07 -0800 (PST) Received: (qmail 5487 invoked from network); 11 Feb 2009 14:59:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2009 14:59:10 -0000 X-YMail-OSG: WB042RwVM1mSu9xU7i5cfEN27tNIcEDQL3cNJMBMhjN0sqptramrUX8Usxc919HzsmoQsYe2s4bTedwvftZ0wmZhpsk60ZAEhGu7TZyhcPCgnEWDGz8dw3Vu7w2GrUQPTrPc_TgI.TZ3yGemMVoQBotC1wCDmgygKRBL5mlZniViSghmIEU5GUI4bZO3k6B.MaVwOJocD4Zq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4992E7BD.1020403@netconfcentral.com> Date: Wed, 11 Feb 2009 06:59:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <499171C0.6070102@edgeware.tv> <200902111132.24894.david.partain@ericsson.com> <1234352650.6477.65.camel@missotis> <20090211.130444.93633765.mbj@tail-f.com> <1234354642.6477.70.camel@missotis> In-Reply-To: <1234354642.6477.70.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] octal numbers (again) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 14:59:07 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v St 11. 02. 2009 v 13:04 +0100: >> Ladislav Lhotka wrote: >>> The same literal such as '010' meaning different things in a >>> default statement and in XPath expressions could be very confusing. >> But with this logic we should also remove the hexadecimal notation. > > No, the difference is that 0x10 is an error in XPath. > >> I think people will be able to understand that the notation for >> defaults is different. > > leaf umask { > type uint8; > default 0022; > } > > leaf foo { > when "../umask = 0022"; > ... > } > > This bug would be very easy to make and hard to spot. > That was my original point exactly, and I was hesitant to raise the issue again, but this was the exact use-case that made me send the email. Both statements (default and when) above are perfectly legal, but one sets the umask to 18 and the other checks if it is equal to 22. XML values (via edit-config) and XPath expressions (when, must, select) will accept octal numbers as decimal numbers. There are dozens of details the user must get right, which each occupy 2 sentences of text in a 168 page draft. At a certain point the WG needs to accept that YANG is full of 'surprises', and a new user should study all 168 pages before starting to use YANG. There is too much complexity for it to stand out and be easily recognized. So go ahead an leave octal in YANG. There is one use-case, unlike some features that have almost one. It is just one of many things for a newbie to trip over. > Lada > >> >> /martin Andy From andy@netconfcentral.com Wed Feb 11 09:38: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 2F4923A690A for ; Wed, 11 Feb 2009 09:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPihg8BUTwqg for ; Wed, 11 Feb 2009 09:38:15 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 6F5423A6782 for ; Wed, 11 Feb 2009 09:38:14 -0800 (PST) Received: (qmail 55166 invoked from network); 11 Feb 2009 17:38:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2009 17:38:18 -0000 X-YMail-OSG: YUb1PJEVM1luHKmposkVH9LaoEJ7n8_AuQK3W9Fcm50vw_Zlr8R91wiB2r2XLOvCNur5cf500f2uzol2.pv13vAyfBgpIE783X_ZC.vRorQWzql8Wb.z2MBsExRbcxe24W.H9nFXtzmZ.80C_IljzLT2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49930D08.1010805@netconfcentral.com> Date: Wed, 11 Feb 2009 09:38:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Partain References: <200901061611.n06GBhEO047660@idle.juniper.net> <49638BD7.90200@netconfcentral.com> <200902111122.19156.david.partain@ericsson.com> In-Reply-To: <200902111122.19156.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] canonical order X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 17:38:16 -0000 David Partain wrote: > Hi, > > An unclosed thread... > > On Tuesday 06 January 2009 17.50.31 Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Do we at least agree that the order must be consistent within >>>> a single implementation? >>> Sounded like you and Martin disagree on whether XPath allows this >>> sort of order issues. Within a single element type, I don't see >>> how para[3] could differ between implementations, but I certainly >>> see that *[3] or node()[3] would be implementation specific. >> We are just talking about 1 manager issuing a >> or a with a an XPath filter to 1 particular agent. >> >> If the manager issues the same command 2 times in a row >> with the same XPath (I don't care what it is), and no nodes >> have been added or removed from the database, >> and no values in the database have changed at all: >> >> Will the manager get the same answer or not? >> >> If not, why not? >> >> I understand that results from different agents >> may not be the same, even for the same (*) >> database contents. >> >> >> * configurations can only be compared outside the database, >> represented as XML documents. > > Previously, Andy also wrote: > >> Do we at least agree that the order must be consistent within >> a single implementation? > >> If the affected portion of the database has not >> changed at all, and if a manager retrieves /foo[3] or >> runs a must-test on /foo[3] at T0 and then T1, will >> the result be the same each time? > >> IMO, MUST be yes. > > I absolutely think that, within an implementation, this should be consistent. > Should the text that Andy suggested be added? > Not so sure about the must-test anymore. Just and . What about a warning that the order MAY NOT be stable instead? It is possible that internal natural sort order within the agent changes due to tree balancing or some internal periodic 'cleanup routine'. Let's stay far away from standardizing agent internals, and stick to the PDU exchanges instead. IMO, the first point is the main one -- an application can compare the content of PDUs. Period. That is the only XML instance document in NETCONF, and the only way full XPath can be used reliably. > David Andy From andy@netconfcentral.com Wed Feb 11 10:09: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 93BE828C1EF for ; Wed, 11 Feb 2009 10:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.081, 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 xY-AyPcnpxOI for ; Wed, 11 Feb 2009 10:09:00 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id C45143A6D3B for ; Wed, 11 Feb 2009 10:09:00 -0800 (PST) Received: (qmail 90230 invoked from network); 11 Feb 2009 18:09:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2009 18:09:04 -0000 X-YMail-OSG: 5z.9w8YVM1nk.4GNDfEie5yqV4ZoYzgZifWtW2d_4miYf95IkE3TpIC7RCtkiYUnQ0weGUDlo5AEdsiBbZMgqH.O.1PjyalRTEeWU0n1bIzshN7ouOFqXAqrZsBMD73_PtXCZqYnB3ZI3cpxKVwAeoAk X-Yahoo-Newman-Property: ymail-3 Message-ID: <4993143E.5040408@netconfcentral.com> Date: Wed, 11 Feb 2009 10:09:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group References: <4990DADB.8070409@netconfcentral.com> In-Reply-To: <4990DADB.8070409@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:09:01 -0000 Andy Bierman wrote: > Hi, > I will try an example, because the unique-stmt is powerful (IMO too powerful) and it needs to be interoperable as well. In this example the nodes tested for uniqueness are optional, not instance-related, and the numbers of each are all different. XML: a1 red item1 up item2 item3 down row1 left row2 right row3 center row4 center YANG: unique "b bb/bbb cc/ccc"; Nodes: (1) /foo[a='a1']/b = 'red' (2) /foo[a='a1']/bb[bbkey='item1']/bbb = 'up' (3) /foo[a='a1']/bb[bbkey='item3']/bbb = 'down' (4) /foo[a='a1']/cc[cckey='row1']/ccc = 'left' (5) /foo[a='a1']/cc[cckey='row1']/ccc = 'right' (6) /foo[a='a1']/cc[cckey='row1']/ccc = 'center' (7) /foo[a='a1']/cc[cckey='row1']/ccc = 'center' Tuples: T1 = [1, 2, 4] = (red, up, left) T2 = [1, 2, 5] = (red, up, right) T3 = [1, 2, 6] = (red, up, center) T4 = [1, 2, 7] = (red, up, center) T5 = [1, 3, 4] = (red, down, left) T6 = [1, 3, 5] = (red, down, right) T7 = [1, 3, 6] = (red, down, center) T8 = [1, 3, 7] = (red, down, center) Result: data-not-unique error generated for T3 = T4 data-not-unique error generated for T7 = T8 Is this right? The agent should internally construct these tuples, and compare each one to every other tuple? I do not see how the 'b' and 'bbb' nodes affect the result in this example. The unique-stmt design seems to assume some instance relationship between the nodes, without specifying it. > I do not understand how the text in 7.8.3 is supposed > to be implemented for complex examples, where 2 or > more leaf targets in the unique-stmt are nested inside > other lists: > > list foo { > key a; > unique "b bb/bbb cc/ccc"; > > leaf a { type string; } > > leaf b { type string; } > > list bb { > key bbkey; > leaf bbkey { type string; } > leaf bbb { type string; } > } > > list cc { > key cckey; > leaf cckey { type string; } > leaf ccc { type string; } > } > } > > > I do not understand which instances get compared in > each 3-tuple, since 'bb' and 'cc' are different lists > and have nothing to do with each other. > > The trivial example in the draft makes sense to me, > because all the nodes in the unique-stmt are siblings > of each other. I prefer that a CLR be added that > unique-stmt tuple members MUST be siblings > (even if they are nested in many lists). > > If not, then lots more text is needed explaining > the expected behavior for the unique-stmt. > > > Andy > Andy From mbj@tail-f.com Wed Feb 11 12:54: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 56E4D3A6C63 for ; Wed, 11 Feb 2009 12:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=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 K1Aa-IfOOTQv for ; Wed, 11 Feb 2009 12:54:56 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8874B3A6C14 for ; Wed, 11 Feb 2009 12:54:53 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AD49676C22D; Wed, 11 Feb 2009 21:54:56 +0100 (CET) Date: Wed, 11 Feb 2009 21:54:56 +0100 (CET) Message-Id: <20090211.215456.77006683.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4993143E.5040408@netconfcentral.com> References: <4990DADB.8070409@netconfcentral.com> <4993143E.5040408@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] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:54:57 -0000 Andy Bierman wrote: > Andy Bierman wrote: > > Hi, > > > > I will try an example, because the unique-stmt is > powerful (IMO too powerful) Yes I agree. I think we need to restrict it the same way as XSD does for xs:unique. For each list entry instance, exactly one tuple is constructed, and this tuple must be unique across all list entry instances. The tuple consists of as many elements as there are schema node identifiers in the unique expression. Each such schema node identifier MUST select zero (*) or one leaf (**). If one of the schema node identifiers selects zero leafs, then the entire tuple is ignored. (*) this can happen if the leaf is optional, and not set for a particular instance. (**) this corresponds to the XSD restriction in xs:unique (each xs:field must return a nodeset with at most element) So in your example: > unique "b bb/bbb cc/ccc"; each tuple would have 3 elements. However, since both bb and cc are lists, 'bb/bbb' will (may) select more than one leaf, and this would an invalid constraint. We could simply state that each node in the schema node identifier MUST be a 'container' or a 'leaf'. I.e. it would not be possible to go into sublists in a unique expression. /martin From mbj@tail-f.com Wed Feb 11 12:56: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 E24BC3A6AB2 for ; Wed, 11 Feb 2009 12:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_05=-1.11, 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 KuLCfvWUtV7D for ; Wed, 11 Feb 2009 12:56:56 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B2433A6C14 for ; Wed, 11 Feb 2009 12:56:56 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8DDE176C22D; Wed, 11 Feb 2009 21:57:00 +0100 (CET) Date: Wed, 11 Feb 2009 21:57:00 +0100 (CET) Message-Id: <20090211.215700.256348686.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20090211.215456.77006683.mbj@tail-f.com> References: <4990DADB.8070409@netconfcentral.com> <4993143E.5040408@netconfcentral.com> <20090211.215456.77006683.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] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:56:57 -0000 Martin Bjorklund wrote: > We could simply state that each node in the schema node identifier > MUST be a 'container' or a 'leaf'. Or 'choice' or 'case'. This would still select at most one leaf. /martin From andy@netconfcentral.com Wed Feb 11 13:29: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 B8FFB3A680B for ; Wed, 11 Feb 2009 13:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTtqWHUWBk0G for ; Wed, 11 Feb 2009 13:29:59 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 1BEB23A659C for ; Wed, 11 Feb 2009 13:29:59 -0800 (PST) Received: (qmail 92968 invoked from network); 11 Feb 2009 21:30:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2009 21:30:02 -0000 X-YMail-OSG: hAbN.PMVM1kxDyZc5AiFTJO4aPlqIeBvIYn.z8p.58UsIg3k8b2_wnIiv4yMN91PKF5.RCIazOAEder9x.MuXirRlLum7KzVh2mHNs46l1BB7gZ4LRUqtLfi_9fH_clyR_hg1kwG.WgThEb_HlAb5qOuz9O5NmDBhZASaHHu.Q0luUtfeG8j2dzHVmYIGiiBdkxFtwG.wQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49934358.5010000@netconfcentral.com> Date: Wed, 11 Feb 2009 13:30:00 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <4990DADB.8070409@netconfcentral.com> <4993143E.5040408@netconfcentral.com> <20090211.215456.77006683.mbj@tail-f.com> <20090211.215700.256348686.mbj@tail-f.com> In-Reply-To: <20090211.215700.256348686.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] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:29:59 -0000 Martin Bjorklund wrote: > Martin Bjorklund wrote: >> We could simply state that each node in the schema node identifier >> MUST be a 'container' or a 'leaf'. > > Or 'choice' or 'case'. This would still select at most one leaf. > This solution is fine with me. Does this work for the use case you brought up awhile back, about the unique address within the interface list? This example is not a problem, because there is only 1 node in the unique-stmt: list interface { key ...; unique "subsys/address"; list subsys { key ...; // why not just put 'unique address;' here? leaf address { type inet:inet-address; } } } Can you show an example with multiple nodes in the unique-stmt, with targets at different nest levels? list interface { key ...; unique "subsys/address port"; list subsys { key ...; leaf address { type inet:inet-address; } } leaf port { type uint8; } } Is this valid? > > /martin > Andy From mbj@tail-f.com Wed Feb 11 13:39:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF783A6A1A for ; Wed, 11 Feb 2009 13:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.672, 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 6BR3+Rk13GKx for ; Wed, 11 Feb 2009 13:39:58 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0353B3A67A7 for ; Wed, 11 Feb 2009 13:39:57 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 63D0176C22D; Wed, 11 Feb 2009 22:40:02 +0100 (CET) Date: Wed, 11 Feb 2009 22:40:01 +0100 (CET) Message-Id: <20090211.224001.150375319.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49934358.5010000@netconfcentral.com> References: <20090211.215456.77006683.mbj@tail-f.com> <20090211.215700.256348686.mbj@tail-f.com> <49934358.5010000@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] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:39:58 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Martin Bjorklund wrote: > >> We could simply state that each node in the schema node identifier > >> MUST be a 'container' or a 'leaf'. > > Or 'choice' or 'case'. This would still select at most one leaf. > > > > This solution is fine with me. > > Does this work for the use case you brought up awhile back, > about the unique address within the interface list? > > This example is not a problem, because there is only 1 node > in the unique-stmt: > > list interface { > key ...; > > unique "subsys/address"; > > list subsys { > > key ...; > > // why not just put 'unique address;' here? > > leaf address { type inet:inet-address; } > } > } Maybe the example is not perfect, since it can be ok to have the same address on different interfaces. But no, this use case would not be covered. > Can you show an example with multiple nodes in the unique-stmt, > with targets at different nest levels? Targets at different nested list levels would not be allowed. Nesting in containers would be ok: list server { key ...; unique "address/ip address/port"; container address { leaf ip { ... } leaf port { ... } } } > list interface { > key ...; > > unique "subsys/address port"; > > list subsys { > > key ...; > > leaf address { type inet:inet-address; } > } > > leaf port { type uint8; } > } > > > Is this valid? No it would not be valid. /martin From phil@juniper.net Wed Feb 11 13:54: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 D910728C120 for ; Wed, 11 Feb 2009 13:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1YFgfdqijBl for ; Wed, 11 Feb 2009 13:54:09 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id AE1833A688B for ; Wed, 11 Feb 2009 13:54:08 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSZNJBbAmJoPawOwz++KYV66wo4m4OaNB@postini.com; Wed, 11 Feb 2009 13:54:14 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 11 Feb 2009 13:51:01 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 13:51:01 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 13:51:01 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 13:51:00 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1BLp0M16731; Wed, 11 Feb 2009 13:51:00 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n1BLicUf064946; Wed, 11 Feb 2009 21:44:38 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902112144.n1BLicUf064946@idle.juniper.net> To: Andy Bierman In-Reply-To: <49870BB3.5030404@netconfcentral.com> Date: Wed, 11 Feb 2009 16:44:37 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Feb 2009 21:51:00.0860 (UTC) FILETIME=[D41DB3C0:01C98C92] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 21:54:10 -0000 Andy Bierman writes: >Hi, > >This section on 'payload parsing' (8.3.1) contains some normative >restrictions of NETCONF protocol usage which do not belong in this spec. > > > o Leaf data values MUST match the type constraints for those leafs, > including those defined in the type's range, length, and pattern > properties. > > o Key data MUST be present for all list instances. > > o Only data for a single case MUST be present for any choices. > >Already covered by NETCONF invalid-value. >No value added by NETMOD here. No, NETCONF makes no restriction on either what values may be transmitted in elements, nor when those errors are reported. YANG adds these restrictions for YANG-based models. > o Data for nodes tagged with "if-feature" MUST NOT be present if the > feature is not supported by the device. > >Why? >What if the agent supports some, but not all of >the feature objects, so it cannot advertise it? Then it can either roll its own model or use deviations to report its underimplementation of the standard model. Either way, the nodes should not be present of the feature is not supported. >Why forbid a manager from sending any request it wants? This seems like an odd question. Why define a protocol at all? We define it to allow clients to know what they can send and what they will receive in reply, as well as allowing servers to know what they will receive and what they need to send in reply. >It is up to each individual agent to answer, and >existing NETCONF error codes are sufficient to address >the problem. It is up to the YANG standard to define how and when NETCONF content is restricted and what error are sent, even if the error is defined in the NETCONF standard. >BTW, just because an agent advertises >a feature does not mean the manager can assume >anything about the success of any individual . No, but it means the client and server understand the semantic and syntactic rules the model defines. > o Data for nodes tagged with "when" MUST NOT be present if the > condition does not evaluate to "true". > >Again, why? >The agent will send the appropriate error for >any PDU it does not support. Yes, the server will fail RPCs that are not valid, but the YANG standard is defining that is and is not valid. If you send data the server does not understand, you will get an error. The sentence above says that the server will not understand nodes that are tagged with "when" when the "when" isn't true. > o For insert handling, the value for the attributes "before" and > "after" MUST be valid for the type of the appropriate key leafs. > > o The attributes "before" and "after" MUST NOT appear for lists > whose "ordered-by" property is "system". > >This is backwards. The YANG spec just needs to specify >what an agent does if these conditions occur >(invalid-value or operation-failed?) I think both are true here. We need to say "don't to that" as well as defining standard behavior when the client does not behave correctly. >Also bullet 4 is a problem: > > o If the NETCONF operation modifies a data node such that any node's > "when" expression becomes false, then that node is deleted by the > server. > >I strongly object to this AUTOMATIC DELETION >'server behavior' slipped into this section. This behavior is used in other operations, like setting a value (the old value is deleted), changing a choice (the other choices are deleted), etc. These rules help keep the data aligned with the known rules and avoid scenarios where invalid data is allowed to remain in the database. This is normal, real world behavior, as implemented in many devices. >IMO, the 'when' statement is just a hint to applications. >The server just needs to implement it correctly (like 'must'). If the modeler wanted "must", they would have used it. "when" gives different functionality. >Therefore, the first paragraph of 8.2 is a problem: > >8.2. Hierarchy of Constraints > > Conditions on parent nodes affect constraints on child nodes as a > natural consequence of the hierarchy of nodes. "must" and "mandatory" > constraints are not enforced if the parent node has a "when" or "if- > feature" property that is not satisfied on the current device. > > >This should say that 'must' and 'mandatory' are enforced if the >parent exists. The 'when' and 'if-feature' statements should not >be coupled to these other constraints. If implemented correctly, and the XPath is correct, then these nodes will not exist. >But if the node does exist, then 'must' and 'mandatory' >need to be enforced. Um, I think you argued it the other way previously. If a non-presence container has a "when", you wanted "must" contraints enforced even if the n-p container does not exist. This section means that if the "when" is false, these are not enforced. I would be happy to remove the enforcement of "must"s when the parent does not exist, if that is your new position. All this language was added based on the concensus reached at the interim. Thanks, Phil From andy@netconfcentral.com Wed Feb 11 14:04: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 1DAF93A6BFD for ; Wed, 11 Feb 2009 14:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.929, 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 Pt2rMWDZzR7q for ; Wed, 11 Feb 2009 14:04:56 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 65FC33A6A11 for ; Wed, 11 Feb 2009 14:04:56 -0800 (PST) Received: (qmail 34589 invoked from network); 11 Feb 2009 22:05:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2009 22:05:00 -0000 X-YMail-OSG: nB9uWboVM1nO2l1ktMr4MLApELZ4mb8eA0xpDgtjvXhuQUjaT0JVUYgRKwAYglw7VXNBCWR5vHA.vxKu9pGWynCWXcVBcy8OOplS4091wNvVHzaTEEX8Qyeo99NwkGAa_dHPPiGXCfE7rVu0ysQ0TBl6CfS5d_REFlCtayTrdFWensWWqHPq.lJFwapYoEw.T2I_93pci4EXcT96zPRx4w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49934B8A.7040508@netconfcentral.com> Date: Wed, 11 Feb 2009 14:04:58 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090211.215456.77006683.mbj@tail-f.com> <20090211.215700.256348686.mbj@tail-f.com> <49934358.5010000@netconfcentral.com> <20090211.224001.150375319.mbj@tail-f.com> In-Reply-To: <20090211.224001.150375319.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] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:04:57 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Martin Bjorklund wrote: >>>> We could simply state that each node in the schema node identifier >>>> MUST be a 'container' or a 'leaf'. >>> Or 'choice' or 'case'. This would still select at most one leaf. >>> >> This solution is fine with me. >> >> Does this work for the use case you brought up awhile back, >> about the unique address within the interface list? >> >> This example is not a problem, because there is only 1 node >> in the unique-stmt: >> >> list interface { >> key ...; >> >> unique "subsys/address"; >> >> list subsys { >> >> key ...; >> >> // why not just put 'unique address;' here? >> >> leaf address { type inet:inet-address; } >> } >> } > > Maybe the example is not perfect, since it can be ok to have the same > address on different interfaces. But no, this use case would not be > covered. > OK >> Can you show an example with multiple nodes in the unique-stmt, >> with targets at different nest levels? > > Targets at different nested list levels would not be allowed. Nesting > in containers would be ok: > > list server { > key ...; > unique "address/ip address/port"; > > container address { > leaf ip { ... } > leaf port { ... } > } > } > Do you mean the all nodes specified in the unique-stmt must be siblings? Same level can mean different parents. >> list interface { >> key ...; >> >> unique "subsys/address port"; >> >> list subsys { >> >> key ...; >> >> leaf address { type inet:inet-address; } >> } >> >> leaf port { type uint8; } >> } >> >> >> Is this valid? > > No it would not be valid. > OK. So even if there were no restrictions, my previous example would have stopped cold because there was only one '/foo' list entry. Only 0 or 1 tuple can come out of each list entry. The unique-stmt is always applied across all entries, never within a single entry. > > > /martin > Andy From mbj@tail-f.com Wed Feb 11 14:20: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 DEEC728C37F for ; Wed, 11 Feb 2009 14:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.448, 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 WtR4xy6Vc4-x for ; Wed, 11 Feb 2009 14:20:38 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0B83328C102 for ; Wed, 11 Feb 2009 14:20:38 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 74E8076C22D; Wed, 11 Feb 2009 23:20:20 +0100 (CET) Date: Wed, 11 Feb 2009 23:20:20 +0100 (CET) Message-Id: <20090211.232020.128797926.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49934B8A.7040508@netconfcentral.com> References: <49934358.5010000@netconfcentral.com> <20090211.224001.150375319.mbj@tail-f.com> <49934B8A.7040508@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] unique-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:20:39 -0000 Andy Bierman wrote: > Do you mean the all nodes specified in the unique-stmt > must be siblings? Same level can mean different parents. No, this would be ok as well: list foo { key ...; unique "a/b c"; container a { leaf b { ... } } leaf c { ... } } The point is that each "schema node identifier" part of the unique expression (i.e. "a/b" and "c") selects at most one node. /martin From andy@netconfcentral.com Wed Feb 11 14:21: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 7F27228C388 for ; Wed, 11 Feb 2009 14:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4feeKT0NE9A for ; Wed, 11 Feb 2009 14:21:43 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 50A1128C375 for ; Wed, 11 Feb 2009 14:21:42 -0800 (PST) Received: (qmail 18833 invoked from network); 11 Feb 2009 22:21:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2009 22:21:24 -0000 X-YMail-OSG: EffTsqAVM1kqpJOfNOO56R4_yuW3nltXUwy5AcBn3.e9h_WgV6WrwvNH8r.TzvaQmaJsgLmtBQFiArKKn3Zf0V7_D7JqL7CbxvR6PygXM3BRe8_F5sL51h2.cTDVtJWp8v6YXKACu6aFJbD3A0hjw.Mi X-Yahoo-Newman-Property: ymail-3 Message-ID: <49934F62.1090909@netconfcentral.com> Date: Wed, 11 Feb 2009 14:21:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902112144.n1BLicUf064946@idle.juniper.net> In-Reply-To: <200902112144.n1BLicUf064946@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Feb 2009 22:21:44 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Hi, >> >> This section on 'payload parsing' (8.3.1) contains some normative >> restrictions of NETCONF protocol usage which do not belong in this spec. >> >> >> o Leaf data values MUST match the type constraints for those leafs, >> including those defined in the type's range, length, and pattern >> properties. >> >> o Key data MUST be present for all list instances. >> >> o Only data for a single case MUST be present for any choices. >> >> Already covered by NETCONF invalid-value. >> No value added by NETMOD here. > > No, NETCONF makes no restriction on either what values may be > transmitted in elements, nor when those errors are reported. YANG > adds these restrictions for YANG-based models. > I disagree. The NETCONF protocol defines what agent MUST, SHOULD, MAY accept. That is sufficient. There is no point in mandating what NETCONF managers can send inside the YANG spec. > >> o Data for nodes tagged with "if-feature" MUST NOT be present if the >> feature is not supported by the device. >> >> Why? >> What if the agent supports some, but not all of >> the feature objects, so it cannot advertise it? > > Then it can either roll its own model or use deviations to report > its underimplementation of the standard model. > > Either way, the nodes should not be present of the feature is not > supported. > >> Why forbid a manager from sending any request it wants? > > This seems like an odd question. Why define a protocol at all? > We define it to allow clients to know what they can send and what > they will receive in reply, as well as allowing servers to know > what they will receive and what they need to send in reply. > The NETCONF RFC already defines the protocol operations. The agent should respond appropriately to any request. If any additional requirements are needed, then 4741-bis should define them, not the YANG RFC. >> It is up to each individual agent to answer, and >> existing NETCONF error codes are sufficient to address >> the problem. > > It is up to the YANG standard to define how and when > NETCONF content is restricted and what error are sent, > even if the error is defined in the NETCONF standard. > >> BTW, just because an agent advertises >> a feature does not mean the manager can assume >> anything about the success of any individual . > > No, but it means the client and server understand the > semantic and syntactic rules the model defines. > >> o Data for nodes tagged with "when" MUST NOT be present if the >> condition does not evaluate to "true". >> >> Again, why? >> The agent will send the appropriate error for >> any PDU it does not support. > > Yes, the server will fail RPCs that are not valid, but the YANG > standard is defining that is and is not valid. If you send > data the server does not understand, you will get an error. > The sentence above says that the server will not understand > nodes that are tagged with "when" when the "when" isn't true. > There is already an unexpected-element error for YANG nodes that the agent does not understand. IMO it is confusing to have multiple flavors of the NETCONF protocol, each defined separately in an ad-hoc fashion, each for only the portion of the database associated with that document. I prefer that 4741-bis be the only document that defines how edit-config works. >> o For insert handling, the value for the attributes "before" and >> "after" MUST be valid for the type of the appropriate key leafs. >> >> o The attributes "before" and "after" MUST NOT appear for lists >> whose "ordered-by" property is "system". >> >> This is backwards. The YANG spec just needs to specify >> what an agent does if these conditions occur >> (invalid-value or operation-failed?) > > I think both are true here. We need to say "don't to that" as > well as defining standard behavior when the client does not > behave correctly. > You could go through the entire NETCONF RFC and write an inverse manager rule for every agent rule found. I prefer this entire section be moved to a non-normative guidelines appendix at the end. A set of usage tips would be helpful, if they were all grouped together. >> Also bullet 4 is a problem: >> >> o If the NETCONF operation modifies a data node such that any node's >> "when" expression becomes false, then that node is deleted by the >> server. >> >> I strongly object to this AUTOMATIC DELETION >> 'server behavior' slipped into this section. > > This behavior is used in other operations, like setting a value > (the old value is deleted), changing a choice (the other choices > are deleted), etc. These rules help keep the data aligned with the > known rules and avoid scenarios where invalid data is allowed to > remain in the database. This is normal, real world behavior, as > implemented in many devices. > >> IMO, the 'when' statement is just a hint to applications. >> The server just needs to implement it correctly (like 'must'). > > If the modeler wanted "must", they would have used it. "when" gives > different functionality. > >> Therefore, the first paragraph of 8.2 is a problem: >> >> 8.2. Hierarchy of Constraints >> >> Conditions on parent nodes affect constraints on child nodes as a >> natural consequence of the hierarchy of nodes. "must" and "mandatory" >> constraints are not enforced if the parent node has a "when" or "if- >> feature" property that is not satisfied on the current device. >> >> >> This should say that 'must' and 'mandatory' are enforced if the >> parent exists. The 'when' and 'if-feature' statements should not >> be coupled to these other constraints. If implemented correctly, > and the XPath is correct, then these nodes will not exist. >> But if the node does exist, then 'must' and 'mandatory' >> need to be enforced. > > Um, I think you argued it the other way previously. If a non-presence > container has a "when", you wanted "must" contraints enforced even > if the n-p container does not exist. This section means that if > the "when" is false, these are not enforced. I would be happy to > remove the enforcement of "must"s when the parent does not exist, > if that is your new position. > > All this language was added based on the concensus reached at the > interim. > I do not remember any discussion of delete-all-false-when-stmt objects, at the interim or on the mailing list. IMO, consensus is TBD. But if this 'feature' stays, there should be a standard 'config-changed' notification defined ASAP to let managers know what happened to chunks of YANG config when they changed that knob with the complicated 'when-stmt' XPath expression they ignored. > Thanks, > Phil > Andy From root@core3.amsl.com Wed Feb 11 15:15:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A70DD3A6A66; Wed, 11 Feb 2009 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090211231501.A70DD3A6A66@core3.amsl.com> Date: Wed, 11 Feb 2009 15:15:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-00.txt Pages : 72 Date : 2009-02-11 This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-dsdl-map-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-11151216.I-D@ietf.org> --NextPart-- From lhotka@cesnet.cz Wed Feb 11 23:42: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 DB69D3A699A for ; Wed, 11 Feb 2009 23:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=1.084, 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 azOQUETuUGLe for ; Wed, 11 Feb 2009 23:42:06 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F149D3A6975 for ; Wed, 11 Feb 2009 23:42:05 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 40D6ED800BD for ; Thu, 12 Feb 2009 08:42:08 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 12 Feb 2009 08:42:07 +0100 Message-Id: <1234424527.6976.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: [netmod] [Fwd: New Version Notification for draft-ietf-netmod-dsdl-map-00] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 07:42:06 -0000 Hi, I submitted the -00 version of the DSDL mapping draft. Specification of the first step (YANG->conceptual tree schema) is fairly complete and also implemented in pyang by the "rng" plugin. Specification of the second step (conceptual tree schema->validating DSDL schemas) is very cursory and consist mainly of placeholders. My plan is to work on this part and submit a -01 revision before March 09. Lada -------- Přeposlaná zpráva -------- Od: IETF I-D Submission Tool Komu: lhotka@cesnet.cz Kopie: rohan@ekabal.com, schishol@nortel.com Předmět: New Version Notification for draft-ietf-netmod-dsdl-map-00 Datum: Wed, 11 Feb 2009 15:12:16 -0800 (PST) A new version of I-D, draft-ietf-netmod-dsdl-map-00.txt has been successfuly submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-ietf-netmod-dsdl-map Revision: 00 Title: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Creation_date: 2009-02-11 WG ID: netmod Number_of_pages: 72 Abstract: This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL). The IETF Secretariat. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Thu Feb 12 05:51: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 87A1D3A6975 for ; Thu, 12 Feb 2009 05:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmn6I2BKjOwe for ; Thu, 12 Feb 2009 05:51:01 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id E244E3A6902 for ; Thu, 12 Feb 2009 05:51:00 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSZQpSiPQabKMfyfOMZ6u/TOjDhcpqOCN@postini.com; Thu, 12 Feb 2009 05:51:07 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 05:37:14 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 05:37:14 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 05:37:14 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 05:37:13 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CDbDM96239; Thu, 12 Feb 2009 05:37:13 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n1CDUou8070390; Thu, 12 Feb 2009 13:30:50 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902121330.n1CDUou8070390@idle.juniper.net> To: Andy Bierman In-Reply-To: <49934F62.1090909@netconfcentral.com> Date: Thu, 12 Feb 2009 08:30:50 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Feb 2009 13:37:13.0531 (UTC) FILETIME=[0343D0B0:01C98D17] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 13:51:02 -0000 Andy Bierman writes: >The NETCONF protocol defines what agent MUST, SHOULD, MAY accept. >That is sufficient. There is no point in mandating what NETCONF >managers can send inside the YANG spec. NETCONF defines an RPC-based protocol for transmitting data. The content and nature of that data is not specified. The data model has complete control over the organization and content of the data. The model determines when content violates those rules and what errors should be reported. NETCONF defines some errors, but the model defines when a value is in error. >There is already an unexpected-element error for YANG nodes >that the agent does not understand. IMO it is confusing to >have multiple flavors of the NETCONF protocol, each defined >separately in an ad-hoc fashion, each for only the portion of the >database associated with that document. I prefer that 4741-bis >be the only document that defines how edit-config works. Andy, I don't think I or anyone else is suggesting "multiple flavors of the NETCONF protocol". This is a red herring. >I prefer this entire section >be moved to a non-normative guidelines appendix at the end. I don't think a non-normative appendix was the concensus. >A set of usage tips would be helpful, if they were all grouped together. These aren't helpful tips. They are rules that govern how servers that implement YANG-based models must behave. >I do not remember any discussion of delete-all-false-when-stmt objects, >at the interim or on the mailing list. IMO, consensus is TBD. This was a lengthy discussion at the interim. >But if this 'feature' stays, there should be a standard 'config-changed' >notification defined ASAP to let managers know what happened to >chunks of YANG config when they changed that knob with the >complicated 'when-stmt' XPath expression they ignored. A draft defining a standard 'config-changed' notification is a topic that should addressed in the NETCONF WG, since the YANG WG doesn't want to step on NETCONF's turf. Thanks, Phil From andy@netconfcentral.com Thu Feb 12 07:45:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5973A6985 for ; Thu, 12 Feb 2009 07:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.232, 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 acUtIyVGJwmU for ; Thu, 12 Feb 2009 07:45:19 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3DB6F3A6973 for ; Thu, 12 Feb 2009 07:45:19 -0800 (PST) Received: (qmail 66268 invoked from network); 12 Feb 2009 15:45:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 12 Feb 2009 15:45:23 -0000 X-YMail-OSG: rP48GO4VM1nLgoIPR76iqAQFSYfrDD3YTCaD9AKFJ.UjNfMbYOKDTbMA8CnGVFqb6meBMp2m2Lits7x6abSx8gHxMhlgFA_xviUZ2g3_PR9nB476B4CcLC8XSDgRQz3qSzVAtpf0WImZJQPVp_P9qlgN X-Yahoo-Newman-Property: ymail-3 Message-ID: <49944411.5020904@netconfcentral.com> Date: Thu, 12 Feb 2009 07:45:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902121330.n1CDUou8070390@idle.juniper.net> In-Reply-To: <200902121330.n1CDUou8070390@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 15:45:20 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The NETCONF protocol defines what agent MUST, SHOULD, MAY accept. >> That is sufficient. There is no point in mandating what NETCONF >> managers can send inside the YANG spec. > > NETCONF defines an RPC-based protocol for transmitting data. The > content and nature of that data is not specified. The data model > has complete control over the organization and content of the data. > The model determines when content violates those rules and what > errors should be reported. NETCONF defines some errors, but the > model defines when a value is in error. > >> There is already an unexpected-element error for YANG nodes >> that the agent does not understand. IMO it is confusing to >> have multiple flavors of the NETCONF protocol, each defined >> separately in an ad-hoc fashion, each for only the portion of the >> database associated with that document. I prefer that 4741-bis >> be the only document that defines how edit-config works. > > Andy, I don't think I or anyone else is suggesting "multiple flavors > of the NETCONF protocol". This is a red herring. > >> I prefer this entire section >> be moved to a non-normative guidelines appendix at the end. > > I don't think a non-normative appendix was the concensus. > >> A set of usage tips would be helpful, if they were all grouped together. > > These aren't helpful tips. They are rules that govern how servers > that implement YANG-based models must behave. > Rules for servers to follow as they process NETCONF PDUs for YANG data models are fine. (If they do not simply repeat what RFC 4741 says to do.) Rules for managers that send NETCONF PDUs are not fine. This implies that every NETCONF application that sends an MUST: 1) be aware of all the YANG data models that the agent supports. (Even though you and Martin argued earlier that we need 'deviations=' in the capability URI, because a manager is free to ignore any capability URI it wants.) 2) be aware of the full current contents of the target database and have XPath tools to process every when-stmt in affect on the agent, before invoking any database operations. Our experience with 'mib-walker' and other common denominator applications strongly suggests that there will be NETCONF applications that do not choose to understand every YANG capability URI sent to them (maybe none of them), and therefore will send requests for data they do not know has some if-feature-stmt and when-stmt false conditions. Since the agent will always answer with an 'unexpected-element' error for all these cases, it doesn't matter how much or how little effort the application does on pre-filtering the requests. No extra work for the agent, but a ton of work for the manager, and no change in protocol outcome for any of the application developer's efforts. >> I do not remember any discussion of delete-all-false-when-stmt objects, >> at the interim or on the mailing list. IMO, consensus is TBD. > > This was a lengthy discussion at the interim. > >> But if this 'feature' stays, there should be a standard 'config-changed' >> notification defined ASAP to let managers know what happened to >> chunks of YANG config when they changed that knob with the >> complicated 'when-stmt' XPath expression they ignored. > > A draft defining a standard 'config-changed' notification is a topic > that should addressed in the NETCONF WG, since the YANG WG doesn't > want to step on NETCONF's turf. > > Thanks, > Phil > Andy From phil@juniper.net Thu Feb 12 10:23: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 6365028C0CE for ; Thu, 12 Feb 2009 10:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqS9NN3bMYhl for ; Thu, 12 Feb 2009 10:23:02 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 169C73A69FB for ; Thu, 12 Feb 2009 10:23:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSZRpC3XOD2Pt3hA0h7MP4tiS7m+GqEmO@postini.com; Thu, 12 Feb 2009 10:23:08 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 10:21:08 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 10:21:08 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 10:21:08 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 10:21:07 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CIL7M27481; Thu, 12 Feb 2009 10:21:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n1CIEitQ072382; Thu, 12 Feb 2009 18:14:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902121814.n1CIEitQ072382@idle.juniper.net> To: Andy Bierman In-Reply-To: <49944411.5020904@netconfcentral.com> Date: Thu, 12 Feb 2009 13:14:44 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Feb 2009 18:21:07.0782 (UTC) FILETIME=[AC783E60:01C98D3E] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 18:23:03 -0000 Andy Bierman writes: >Rules for managers that send NETCONF PDUs are not fine. Sorry, but I don't see this. YANG defines the orgnaization of the model's elements, which turn into rules for the client. If the model list "name" as a key, the name element must appear when needed. >This implies that every NETCONF application that sends >an MUST: > 1) be aware of all the YANG data models that the agent > supports. (Even though you and Martin argued earlier > that we need 'deviations=' in the capability URI, > because a manager is free to ignore any capability URI > it wants.) Not true. Applications need only pay attention to the models which they care about. An application doing OSPF need not know anything about ISIS data models. > 2) be aware of the full current contents of the target database > and have XPath tools to process every when-stmt in affect > on the agent, before invoking any database operations. No, they need to understand their own data models. If there is a "when" constraint in the /protocols/isis hierachy, the OSPF application need not know it. >Since the agent will always answer with an 'unexpected-element' >error for all these cases, it doesn't matter how much >or how little effort the application does on pre-filtering the >requests. No extra work for the agent, but a ton of work >for the manager, and no change in protocol outcome for >any of the application developer's efforts. So you are wanting to allow any garbage from the client, as long as the server is allowed to give errors? I don't see the point. We want to give both the client and server strong constraints on what they can send and what they will receive in order to increase interoperability and help folks do the right think. Thanks, Phil From andy@netconfcentral.com Thu Feb 12 11:12: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 AEDB73A684A for ; Thu, 12 Feb 2009 11:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etZmaNdKHxlJ for ; Thu, 12 Feb 2009 11:12:01 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 03ABB3A6781 for ; Thu, 12 Feb 2009 11:12:01 -0800 (PST) Received: (qmail 149 invoked from network); 12 Feb 2009 19:12:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 12 Feb 2009 19:12:06 -0000 X-YMail-OSG: j1JkO4kVM1kaDm6ZKExRgPzes12DtJw9n8xtRrfGP4GGKXcZDzTef7.VPRJ7xFyHh4nrUQRO6UkU2_Z8WWGWcJNUMpCPKJWURHLY9kmcvQGMWYkA3CgHQ73Q0QIgAhs6QcDtMfoXBHe.LqtuKJRxtbTh X-Yahoo-Newman-Property: ymail-3 Message-ID: <49947484.8070609@netconfcentral.com> Date: Thu, 12 Feb 2009 11:12:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200902121814.n1CIEitQ072382@idle.juniper.net> In-Reply-To: <200902121814.n1CIEitQ072382@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 19:12:01 -0000 .... > So you are wanting to allow any garbage from the client, as long > as the server is allowed to give errors? I don't see the point. > We want to give both the client and server strong constraints on > what they can send and what they will receive in order to increase > interoperability and help folks do the right think. > The server is 'required' to give errors, not 'allowed' to give errors. It seems strange to mandate with MUST-type normative text that the manager MUST NOT send certain requests that the agent will answer with an 'unknown-element' error. This is based on certain YANG clause values that need to be validated with the proper YANG modules, XPath tools, and fresh copy of the configuration database. IMO, this is not important and not required in the text. There is no difference between a manager sending a request to edit '/foo/garbage' or '/feature-not-loaded-into-agent'. than a request to edit '/foo/false-when-clause-object' or '/foo/false-if-feature-object'. All of these requests are just errors for non-existent nodes. Why are YANG if-feature and when-stmt missing nodes different from a generic 'unknown-element' error? You might as well say the manager MUST NOT send any request that the agent does not fully understand. > Thanks, > Phil > Andy From phil@juniper.net Thu Feb 12 11:33: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 4004328C138 for ; Thu, 12 Feb 2009 11:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQOgfgUox8kr for ; Thu, 12 Feb 2009 11:33:24 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id ABB8F3A6AF4 for ; Thu, 12 Feb 2009 11:33:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSZR5id7j7qnClyORckmM1htuo3HXcC9G@postini.com; Thu, 12 Feb 2009 11:33:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 11:30:42 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 11:30:42 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 11:30:42 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 11:30:41 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CJUfM60701; Thu, 12 Feb 2009 11:30:41 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n1CJOIiM073244; Thu, 12 Feb 2009 19:24:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200902121924.n1CJOIiM073244@idle.juniper.net> To: Andy Bierman In-Reply-To: <49947484.8070609@netconfcentral.com> Date: Thu, 12 Feb 2009 14:24:18 -0500 From: Phil Shafer X-OriginalArrivalTime: 12 Feb 2009 19:30:41.0722 (UTC) FILETIME=[6454F1A0:01C98D48] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 19:33:25 -0000 Andy Bierman writes: >It seems strange to mandate with MUST-type normative text >that the manager MUST NOT send certain requests that >the agent will answer with an 'unknown-element' error. So you don't want the spec to say what is and isn't allowed, you prefer to just say "if you send this, the agent MUST send an error"? >There is no difference between a manager sending a >request to edit '/foo/garbage' or '/feature-not-loaded-into-agent'. >than a request to edit '/foo/false-when-clause-object' >or '/foo/false-if-feature-object'. Is there a difference between saying "don't request an edit on non-existent nodes" and "if you send an edit on non-existent node, the server MUST respond with blah-blah error"? >All of these requests are just errors for non-existent nodes. >Why are YANG if-feature and when-stmt missing nodes different >from a generic 'unknown-element' error? You are targeting "when" and "feature", but this is a broader content issue. Consider the following text from the draft: - Key data MUST be present for all list instances. Should this be rephrased as an error-emitting opportunity? - If key data is not present in all list instances, the server MUST generate an appropriate error. Would you prefer a remark at the top or bottom of this list (under the "Payload Parsing" section) saying something like: If the payload does not comply with any of these rules, the server MUST generate an appropriate error. >You might as well say the manager MUST NOT send any request >that the agent does not fully understand. We're trying to define rules that allow clients to know what is and isn't valid, so they can always send requests that the server fully understands. Thanks, Phil From mbj@tail-f.com Thu Feb 12 11:50: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 5226B3A6800 for ; Thu, 12 Feb 2009 11:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.269, 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 ZQ41fnK2kMsg for ; Thu, 12 Feb 2009 11:50:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 80C8E3A6B20 for ; Thu, 12 Feb 2009 11:50:55 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EEC1E61600A; Thu, 12 Feb 2009 20:51:00 +0100 (CET) Date: Thu, 12 Feb 2009 20:51:00 +0100 (CET) Message-Id: <20090212.205100.62765552.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49947484.8070609@netconfcentral.com> References: <200902121814.n1CIEitQ072382@idle.juniper.net> <49947484.8070609@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-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 19:50:56 -0000 Andy Bierman wrote: > .... > > So you are wanting to allow any garbage from the client, as long > > as the server is allowed to give errors? I don't see the point. > > We want to give both the client and server strong constraints on > > what they can send and what they will receive in order to increase > > interoperability and help folks do the right think. > > > > The server is 'required' to give errors, not 'allowed' to give errors. > It seems strange to mandate with MUST-type normative text > that the manager MUST NOT send certain requests that > the agent will answer with an 'unknown-element' error. I agree with you. What if rephrase the text we're discussing so that it instead specifies which error the server MUST send? For example, instead of: Leaf data values MUST match the type constraints for those leafs, including those defined in the type's range, length, and pattern properties. we could say: 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. I'm not sure if the original text also tried to put requirements on data sent by the server as replies to e.g. requests. /martin From andy@netconfcentral.com Thu Feb 12 12:18: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 326E23A6B26 for ; Thu, 12 Feb 2009 12:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8Y44KBr0EUy for ; Thu, 12 Feb 2009 12:18:31 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 2B18E3A69A3 for ; Thu, 12 Feb 2009 12:18:31 -0800 (PST) Received: (qmail 20479 invoked from network); 12 Feb 2009 20:18:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.159.31 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 12 Feb 2009 20:18:36 -0000 X-YMail-OSG: DJEKeMIVM1kwNHgvfozD7BrHhjNpftCidC6xlXDD2axruW3md1YV8l9XUlxzYGtoocZdzZZnV4Y42qOvCUhyxjJ.Uk7Bs2fc2KymLhoT7.LISxoMKAIHO1kDEZYdscon_VUjCmpLprTMqytcH9VtjeYHzMTJnhUTCyuWNFVaalA_f3tvh4eQo0eCov3GFbfkrms5UWQiYwQEDIQH3P7xlw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4994841A.2020007@netconfcentral.com> Date: Thu, 12 Feb 2009 12:18:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <200902121814.n1CIEitQ072382@idle.juniper.net> <49947484.8070609@netconfcentral.com> <20090212.205100.62765552.mbj@tail-f.com> In-Reply-To: <20090212.205100.62765552.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] yang-03, 8.3.x, stepping on NETCONF turf X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Feb 2009 20:18:32 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> .... >>> So you are wanting to allow any garbage from the client, as long >>> as the server is allowed to give errors? I don't see the point. >>> We want to give both the client and server strong constraints on >>> what they can send and what they will receive in order to increase >>> interoperability and help folks do the right think. >>> >> The server is 'required' to give errors, not 'allowed' to give errors. >> It seems strange to mandate with MUST-type normative text >> that the manager MUST NOT send certain requests that >> the agent will answer with an 'unknown-element' error. > > I agree with you. What if rephrase the text we're discussing so that > it instead specifies which error the server MUST send? > > For example, instead of: > > Leaf data values MUST match the type constraints for those leafs, > including those defined in the type's range, length, and pattern > properties. > > we could say: > > 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. > This is excellent. The necessary and sufficient text in the YANG document should be limited to how (and when) a NETCONF agent enforces the behavior in particular YANG constructs. > > I'm not sure if the original text also tried to put requirements on > data sent by the server as replies to e.g. requests. > The YANG draft (e.g., canonical XML representation) certainly puts requirements on what an agent can send. That is OK. > > > /martin > > Andy From david.partain@ericsson.com Mon Feb 16 00:56: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 55E1A3A6BE7 for ; Mon, 16 Feb 2009 00:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMdCbHvWWiH4 for ; Mon, 16 Feb 2009 00:56:05 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 79B693A69FC for ; Mon, 16 Feb 2009 00:56:05 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5339020A28 for ; Mon, 16 Feb 2009 09:56:13 +0100 (CET) X-AuditID: c1b4fb3c-ad289bb00000127c-f0-49992a2dce91 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F4DA20A0B for ; Mon, 16 Feb 2009 09:56:13 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 09:56:12 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Feb 2009 09:56:12 +0100 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Mon, 16 Feb 2009 09:56:11 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902160956.12103.david.partain@ericsson.com> X-OriginalArrivalTime: 16 Feb 2009 08:56:12.0355 (UTC) FILETIME=[6ADF8930:01C99014] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Meetings at the upcoming IETF X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Feb 2009 08:56:06 -0000 Hi all, The following NETMOD meetings have been scheduled in San Francisco. NETMOD Session 1 (2 hours) Monday, Afternoon Session III 1740-1940 Room Name: Breakout 4 NETMOD Session 2 (2 hours) Wednesday, Morning Session I 0900-1015 Room Name: Breakout 4 Please submit issues you want to be on the agenda to the chairs. The normal caveats apply in that the IETF agenda does sometimes change. Cheers, David From mbj@tail-f.com Mon Feb 16 23:28: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 53EC83A699D for ; Mon, 16 Feb 2009 23:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t1LSWU56Bu3 for ; Mon, 16 Feb 2009 23:28:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4B2B43A6A60 for ; Mon, 16 Feb 2009 23:28:18 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3CE6076C32E; Tue, 17 Feb 2009 08:28:27 +0100 (CET) Date: Tue, 17 Feb 2009 08:28:26 +0100 (CET) Message-Id: <20090217.082826.31679778.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> References: <20090105.110118.138972369.mbj@tail-f.com> <200902091500.17517.david.partain@ericsson.com> <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 07:28:19 -0000 Juergen Schoenwaelder wrote: > > I'd like to see comments on Martin's suggestion (that we come up > > with our own definition and that we use %f). To me, this seems like > > a reasonable way of dealing with this. > > I understanding is that %f alone limits the precision to 6 digits > which is likely not what we want. So what is the suggested precision? The problem with %f is that if we want to be able to print all float64 values, the precision has to be Very Large (300+?) For example, the value 1E-300 will be printed as 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 And large values (1E300) will not be easy to ready: 1000000000000000052504760255204420248704468581108159154915854115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233794788090059368953234970799945081119038967640880074652742780142494579258788820056842838115669472196386865459400540160.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 That's why I suggested %.17E as an alternative. I believe that this ensures that all float64 (double) values can be printed as decimal and converted back to the same value, which seems to be a useful property. One drawback with this is that XPath 1.0 does not understand this form. If it is important, we could solve this for YANG's "must" and "when" expressions by introducing a new XPath function (e.g. strtod()), but we would still have an issue with NETCONF XPath filtering. I would rather use "%.17E" (with trailing zeros removed) and loose the ability to use XPath filters, then having to use "%.300f". /martin From andy@netconfcentral.com Tue Feb 17 03:35: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 4E3F628C13D for ; Tue, 17 Feb 2009 03:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4RD9UncrnH2 for ; Tue, 17 Feb 2009 03:35:29 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 823343A6968 for ; Tue, 17 Feb 2009 03:35:29 -0800 (PST) Received: (qmail 2771 invoked from network); 17 Feb 2009 11:35:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.241.167 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 11:35:39 -0000 X-YMail-OSG: KfMUuPEVM1nLijbU8KKNkAHUSCV6vXqJlgZrOmZBWVALTvbaH2nvzkobKFVa7I1.HU1HLmIUShKoWr1utmtEDEoYrthZABT0J9RLbbYUYoo3oIMvU5brmiTTOX.czHw9nlPQIGm06vvKQHyAi_KLoH80OvsaGy7Sj4YS.MO5e.aK.q1_Cps2Do1c8LF8eql2beDdL2qRYW51T_W6utN_99KXdZnA.6VHGgPGaTc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499AA109.9020403@netconfcentral.com> Date: Tue, 17 Feb 2009 03:35:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090105.110118.138972369.mbj@tail-f.com> <200902091500.17517.david.partain@ericsson.com> <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> In-Reply-To: <20090217.082826.31679778.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] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 11:35:30 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >>> I'd like to see comments on Martin's suggestion (that we come up >>> with our own definition and that we use %f). To me, this seems like >>> a reasonable way of dealing with this. >> I understanding is that %f alone limits the precision to 6 digits >> which is likely not what we want. So what is the suggested precision? > > The problem with %f is that if we want to be able to print all float64 > values, the precision has to be Very Large (300+?) For example, the > value 1E-300 will be printed as > > 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 > > And large values (1E300) will not be easy to ready: > > 1000000000000000052504760255204420248704468581108159154915854115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233794788090059368953234970799945081119038967640880074652742780142494579258788820056842838115669472196386865459400540160.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > > That's why I suggested %.17E as an alternative. I believe that this > ensures that all float64 (double) values can be printed as decimal and > converted back to the same value, which seems to be a useful property. > > One drawback with this is that XPath 1.0 does not understand this > form. If it is important, we could solve this for YANG's "must" and > "when" expressions by introducing a new XPath function > (e.g. strtod()), but we would still have an issue with NETCONF XPath > filtering. > This is more than a drawback. This is a full-stop, XPath is the wrong hammer, kind of decision. We looked at this months ago and realized that the %e or %E format will be misinterpreted in XPath as an AdditiveExpr. container foo { must "bar+1.45234+E7 I would rather use "%.17E" (with trailing zeros removed) and loose the > ability to use XPath filters, then having to use "%.300f". You mean drop must/when completely? You mean drop :xpath "select" from 4741? (I prefer to keep must/when and :xpath). If we were to choose the correct hammer from the toolbox, what would it look like? > > > /martin Andy From mbj@tail-f.com Tue Feb 17 03:49: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 8DD8F3A6B11 for ; Tue, 17 Feb 2009 03:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvWMhI7CPHgT for ; Tue, 17 Feb 2009 03:49:58 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C22E93A67B3 for ; Tue, 17 Feb 2009 03:49:58 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 14CAE76C310; Tue, 17 Feb 2009 12:50:08 +0100 (CET) Date: Tue, 17 Feb 2009 12:50:07 +0100 (CET) Message-Id: <20090217.125007.166508893.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <499AA109.9020403@netconfcentral.com> References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@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] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 11:49:59 -0000 Andy Bierman wrote: > This is more than a drawback. > This is a full-stop, XPath is the wrong hammer, kind of decision. We *can* use %.350f and accept the more-than-ugly output. Then XPath will work. Note that this is an issue with plain NETCONF and :xpath, regardless of data modelling language. If floats are sent using the exponent format, XPath filtering will not work the way you might think. > We looked at this months ago and realized that the %e or %E > format will be misinterpreted in XPath as an AdditiveExpr. > > container foo { > must "bar+1.45234+E7 > I would rather use "%.17E" (with trailing zeros removed) and loose the > > ability to use XPath filters, then having to use "%.300f". > > You mean drop must/when completely? No. I mean either introduce 'strtod' as above or accept that you will not be able to compare floats in must/when expressions. > You mean drop :xpath "select" from 4741? No. I mean that you will not be able to compare floats in the select expression. (unless strtod() is introduced in :xpath as well). > If we were to choose the correct hammer from the toolbox, > what would it look like? An "adapted subset" of XPath 1.0 - which does not sound too attractive. What is your suggestion for how to deal with this? %.350f? /martin From andy@netconfcentral.com Tue Feb 17 04:16: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 EAAAE3A6847 for ; Tue, 17 Feb 2009 04:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oNc+hHUCAOR for ; Tue, 17 Feb 2009 04:16:03 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 3DC253A69CF for ; Tue, 17 Feb 2009 04:16:03 -0800 (PST) Received: (qmail 23985 invoked from network); 17 Feb 2009 12:16:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.241.167 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 12:16:13 -0000 X-YMail-OSG: c.NMzPQVM1lKfOkhB4ZMnem2I4j2SvwOqU._1bTNSlVbZgHYslR1V1i2FSdvZ8sS3g9AGVKBw0T9utU._0AMS4GDUIFh37f4NW80BDmc2KWVquiDEk3z.puprbDghXYLYHLNZ7FAKN4ayHFdBtfPUKKn89O6NxYVCk.64Yk4GHYc65TkUmHPTNPkyUuGVm7QRMcYOFznKKeVVExgP0OEoQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499AAA8B.2010104@netconfcentral.com> Date: Tue, 17 Feb 2009 04:16:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> In-Reply-To: <20090217.125007.166508893.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] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 12:16:04 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> This is more than a drawback. >> This is a full-stop, XPath is the wrong hammer, kind of decision. > > We *can* use %.350f and accept the more-than-ugly output. Then XPath > will work. > > Note that this is an issue with plain NETCONF and :xpath, regardless > of data modelling language. If floats are sent using the exponent > format, XPath filtering will not work the way you might think. > >> We looked at this months ago and realized that the %e or %E >> format will be misinterpreted in XPath as an AdditiveExpr. >> >> container foo { >> must "bar+1.45234+E7 > Right, so we *could* solve this with: > > must "bar+strtod('1.45234+E7') >>> I would rather use "%.17E" (with trailing zeros removed) and loose the >>> ability to use XPath filters, then having to use "%.300f". >> You mean drop must/when completely? > > No. I mean either introduce 'strtod' as above or accept that you will > not be able to compare floats in must/when expressions. > >> You mean drop :xpath "select" from 4741? > > No. I mean that you will not be able to compare floats in the select > expression. (unless strtod() is introduced in :xpath as well). > >> If we were to choose the correct hammer from the toolbox, >> what would it look like? > > An "adapted subset" of XPath 1.0 - which does not sound too > attractive. > > > What is your suggestion for how to deal with this? %.350f? > no. FP numbers are more complicated than that. Asking for too much precision produces garbage results. You end up with spurious numbers in the fraction, not all zeros. (So 3 might turn into 3.000000000000000000000000000000000065). IMO, FP numbers are an extremely low priority in our NM problem space. We deal with Counter32 and Counter64. On very rare occasions when FP has been needed, suitable hacks using ordinal numbers or more than 1 MIB object have been sufficient instead. Statistical analysis is usually done on the NMS, so FP division is not even needed for that on the agent. What are the priorities for the solution? The strtod() function looks promising for input. How does the agent generate FP numbers in rpc-reply and notification responses for float32 and float64 data types? > > /martin > > Andy From andy@netconfcentral.com Tue Feb 17 04:45: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 37C543A684D for ; Tue, 17 Feb 2009 04:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zHTTe6RVprW for ; Tue, 17 Feb 2009 04:45:02 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 881AE3A6954 for ; Tue, 17 Feb 2009 04:45:02 -0800 (PST) Received: (qmail 76383 invoked from network); 17 Feb 2009 12:45:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.241.167 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 12:45:13 -0000 X-YMail-OSG: 8LJuGgkVM1mkWVHNzD7EfJoQduWRkwEi39J2qMxArWYdKdJDcujpV5JVZxdXILUcTFgsWENIan1U6YGpQZRAy7F4h4tL.sBzbkK5pmH4KB8_T_TF9j3tGcWqr7GFKFOb4aKc53CjwxcWQKIYlAfBSODFvf9ssCJFz2jECGMUQBzYySC3e9ioSSAKSG9ZP2IprXGE_PqYEG0O8_siFtX4Ng-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499AB157.7070404@netconfcentral.com> Date: Tue, 17 Feb 2009 04:45:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> In-Reply-To: <20090217.125007.166508893.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] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 12:45:03 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> This is more than a drawback. >> This is a full-stop, XPath is the wrong hammer, kind of decision. > > We *can* use %.350f and accept the more-than-ugly output. Then XPath > will work. > > Note that this is an issue with plain NETCONF and :xpath, regardless > of data modelling language. If floats are sent using the exponent > format, XPath filtering will not work the way you might think. > >> We looked at this months ago and realized that the %e or %E >> format will be misinterpreted in XPath as an AdditiveExpr. >> >> container foo { >> must "bar+1.45234+E7 > Right, so we *could* solve this with: > > must "bar+strtod('1.45234+E7') >>> I would rather use "%.17E" (with trailing zeros removed) and loose the >>> ability to use XPath filters, then having to use "%.300f". >> You mean drop must/when completely? > > No. I mean either introduce 'strtod' as above or accept that you will > not be able to compare floats in must/when expressions. > >> You mean drop :xpath "select" from 4741? > > No. I mean that you will not be able to compare floats in the select > expression. (unless strtod() is introduced in :xpath as well). > >> If we were to choose the correct hammer from the toolbox, >> what would it look like? > > An "adapted subset" of XPath 1.0 - which does not sound too > attractive. > No, but in reality it is extremely close to 'real' XPath. Out of around 450 implementation details, about 5 of them are different for YANG. In every instance of unexpected behavior (if you are an XPath expert), there are better ways to use XPath also available to the data modeler that do not have problems (e.g., foo[name='fred'], not foo[3]). IMO, a function library extension for some really useful NM-stuff is a feature, not a bug. Advertise a :yanglib capability and it is no different than anything else we put in the data model. > > What is your suggestion for how to deal with this? %.350f? Take a look at %g output in glibc. That looks really nice -- the format is fixed for small numbers and all the trailing zero 'cleanup' is done by glibc. > > > /martin > > Andy From andy@netconfcentral.com Tue Feb 17 05:20: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 5CFBE3A6822 for ; Tue, 17 Feb 2009 05:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSem1MbgrdhQ for ; Tue, 17 Feb 2009 05:20:41 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id B58623A68B5 for ; Tue, 17 Feb 2009 05:20:41 -0800 (PST) Received: (qmail 74455 invoked from network); 17 Feb 2009 13:20:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.241.167 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 13:20:51 -0000 X-YMail-OSG: kKn5j.UVM1k8mIon6CYqB83DyNmJNq.Zsa9.h2b1gdj9EW_ffeccpUOgLf0Mir6TdQcC0mMrfjofSXaPO.HF.vha6_d_42QAR_0X3Q7lYcUMYL7jk8a0x3ns1kcIQ7gQahRA.NLg_Q5PrW4N0GBplfsNuEt5yXi0luLpgbHcB6YMz3iatvSz7CeCfn8m8nlQFoF4e1tazxveBgBY55MTyQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499AB9B1.8030409@netconfcentral.com> Date: Tue, 17 Feb 2009 05:20:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> In-Reply-To: <20090217.125007.166508893.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] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 13:20:42 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: ... >> container foo { >> must "bar+1.45234+E7 > Right, so we *could* solve this with: > > must "bar+strtod('1.45234+E7') Actually, the syntax is 1.45234E+07. This is slightly better, since it will cause a fatal XPath error, rather than being silently accepted as the wrong kind of expression. > /martin > > Andy From andy@netconfcentral.com Tue Feb 17 06:50: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 0F8F03A69D6 for ; Tue, 17 Feb 2009 06:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_20=-0.74, 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 jJfWPe5uhYsU for ; Tue, 17 Feb 2009 06:49:59 -0800 (PST) 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 B1C103A67A5 for ; Tue, 17 Feb 2009 06:49:59 -0800 (PST) Received: from [68.142.194.243] by n21.bullet.mail.mud.yahoo.com with NNFMP; 17 Feb 2009 14:50:10 -0000 Received: from [68.142.201.68] by t1.bullet.mud.yahoo.com with NNFMP; 17 Feb 2009 14:50:10 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 17 Feb 2009 14:50:10 -0000 X-Yahoo-Newman-Id: 230779.71217.bm@omp420.mail.mud.yahoo.com Received: (qmail 2158 invoked from network); 17 Feb 2009 14:50:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.241.167 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 14:50:09 -0000 X-YMail-OSG: hRcTCoIVM1mJVcyoidkWozCAqT0Ve9CvPMMdABFiyR2CLOHKhjHPgCkpj1MT.WmuZV0axtaZvtXwIQhJNxBe.xrUowP4GviGjtqiU8al4U.PBeaNghPP8bSW_Mvq2248yWVd0tskf4OscKjcEloo9Hzc X-Yahoo-Newman-Property: ymail-3 Message-ID: <499ACE9F.4030202@netconfcentral.com> Date: Tue, 17 Feb 2009 06:50:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 14:50:01 -0000 Hi, Consider the example below. Does the agent advertise capabilities for both module revisions for 'Z'? Or just the highest value? Does the draft need some text that says a manager must inspect all the module capabilities for a given module-name, because there may be more than 1? Advertising N versions is confusing, but advertising 'Y', which uses an unadvertised revision of 'Z' is also confusing. The agent is only required to support 1 version of the 'foo' container, so which one is it? What happens when module X tries to refine leaf y-A, (that is defined with module Y's notion of type Z:A)? Module Z is using a different typedef for y-A. Is this an error? Does one version win out over the other? Does an implementor just choose whatever they want to do? Supporting multiple versions of the same YANG construct within the same module is confusing. Important semantic changes can be effectively buried in nested revision differences. Andy ------------------------------- module X { ... revision "2009-02-17" { description ""; } import Y { prefix Y; revision "2009-01-01"; } import Z { prefix Y; revision "2009-02-01"; } leaf X-a { type Z:A; } uses Y:YAZ { refine y-A { ... } } } module Y { ... revision "2009-01-01" { description ""; } import Z { prefix Y; revision "2008-12-12"; } leaf Y-a { type Z:A; } grouping YAZ { leaf Y-a { type Z:A; } } } module Z { ... revision "2009-02-01" { description ""; } typedef A { } container foo { ... leaf new-leaf { ... } } } module Z { ... revision "2008-12-12" { description ""; } typedef A { ... } container foo { ... } } From mbj@tail-f.com Tue Feb 17 07:18: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 DF5C43A69ED for ; Tue, 17 Feb 2009 07:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 9S+zryskfMTn for ; Tue, 17 Feb 2009 07:18:15 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 291123A6833 for ; Tue, 17 Feb 2009 07:18:14 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C4AD776C310; Tue, 17 Feb 2009 16:18:25 +0100 (CET) Date: Tue, 17 Feb 2009 16:18:25 +0100 (CET) Message-Id: <20090217.161825.79948319.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <499ACE9F.4030202@netconfcentral.com> References: <499ACE9F.4030202@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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:18:16 -0000 Andy Bierman wrote: > Hi, > > Consider the example below. > Does the agent advertise capabilities for both module > revisions for 'Z'? No. > Or just the highest value? It would advertise Z only if it implements the container 'foo', and it would advertise the version it implements. "library modules" are not advertised. > Does the draft need some text that says a manager must inspect > all the module capabilities for a given module-name, > because there may be more than 1? Never more than 1. > What happens when module X tries to refine leaf y-A, > (that is defined with module Y's notion of type Z:A)? > Module Z is using a different typedef for y-A. > Is this an error? Does one version win out over the other? > Does an implementor just choose whatever they want to do? All type- and grouping references are resolved at "compile time". Thus, leaf Y-a is always the same in module X, regardless of which version of Z is imported by module X, or other modules. /martin From balazs.lengyel@ericsson.com Tue Feb 17 08:42: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 25EA83A69E9 for ; Tue, 17 Feb 2009 08:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 itTe3MMrnJrz for ; Tue, 17 Feb 2009 08:42:46 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5ED1D3A68C5 for ; Tue, 17 Feb 2009 08:42:46 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EF7CF21157; Tue, 17 Feb 2009 17:42:55 +0100 (CET) X-AuditID: c1b4fb3e-ae8c0bb000001315-12-499ae90fdf64 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D339A21152; Tue, 17 Feb 2009 17:42:55 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 17:42:55 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 17:42:55 +0100 Message-ID: <499AE90F.10201@ericsson.com> Date: Tue, 17 Feb 2009 17:42:55 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> In-Reply-To: <20090217.161825.79948319.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2009 16:42:55.0595 (UTC) FILETIME=[C8849BB0:01C9911E] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:42:47 -0000 Hello, Martin Bjorklund wrote: >> Or just the highest value? > > It would advertise Z only if it implements the container 'foo', and it > would advertise the version it implements. > > "library modules" are not advertised. > BALAZS: - I assume that library modules are visible in the monitoring schema. True? - I assume that all used versions of library modules (YAMs) are available in the monitoring schema. True? - I assume that in the monitoring schema it will be possible to find out if a YAM is used just as a library or if its data nodes are implemented as well. True? Balazs From mbj@tail-f.com Tue Feb 17 09:17: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 D1DBF3A67FB for ; Tue, 17 Feb 2009 09:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.192, 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 X1LzJ-hJw5KM for ; Tue, 17 Feb 2009 09:17:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0A9593A6A01 for ; Tue, 17 Feb 2009 09:17:03 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2904076C310; Tue, 17 Feb 2009 18:17:13 +0100 (CET) Date: Tue, 17 Feb 2009 18:17:12 +0100 (CET) Message-Id: <20090217.181712.267150690.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <499AE90F.10201@ericsson.com> References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> <499AE90F.10201@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:17:03 -0000 Balazs Lengyel wrote: > Hello, > > Martin Bjorklund wrote: > >> Or just the highest value? > > It would advertise Z only if it implements the container 'foo', and it > > would advertise the version it implements. > > "library modules" are not advertised. > > > > BALAZS: > - I assume that library modules are visible in the monitoring schema. True? Yes. All modules are listed in the 'schema' list. > - I assume that all used versions of library modules (YAMs) are available in > the monitoring schema. True? Yes. > - I assume that in the monitoring schema it will be possible to find out if a > YAM is used just as a library or if its data nodes are implemented as > well. True? Yes, since the capabilites from hello are repeated in the 'capability' leaf-list. /martin From cfinss@dial.pipex.com Tue Feb 17 11:34: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 9A3CE3A6B38 for ; Tue, 17 Feb 2009 11:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_05=-1.11, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZVVH-0fXAHI for ; Tue, 17 Feb 2009 11:34:13 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id D2B723A63EC for ; Tue, 17 Feb 2009 11:34:11 -0800 (PST) X-Trace: 132824416/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.62/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.62 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFALyfmkk+vBE+/2dsb2JhbACDQECKDcVtB4QMBg X-IronPort-AV: E=Sophos;i="4.38,224,1233532800"; d="scan'208";a="132824416" X-IP-Direction: IN Received: from 1cust62.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.62]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Feb 2009 19:34:20 +0000 Message-ID: <002001c9912e$2e257660$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "David Partain" References: <200901061611.n06GBhEO047660@idle.juniper.net> <49638BD7.90200@netconfcentral.com><200902111122.19156.david.partain@ericsson.com> <49930D08.1010805@netconfcentral.com> Date: Mon, 16 Feb 2009 17:58:07 +0100 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] canonical order 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, 17 Feb 2009 19:34:14 -0000 ----- Original Message ----- From: "Andy Bierman" To: "David Partain" Cc: Sent: Wednesday, February 11, 2009 6:38 PM Subject: Re: [netmod] canonical order > David Partain wrote: > > > > An unclosed thread... Yup, just one of .... :-( > > > > On Tuesday 06 January 2009 17.50.31 Andy Bierman wrote: > >> Phil Shafer wrote: > >>> Andy Bierman writes: > >>>> Do we at least agree that the order must be consistent within > >>>> a single implementation? > >>> Sounded like you and Martin disagree on whether XPath allows this > >>> sort of order issues. Within a single element type, I don't see > >>> how para[3] could differ between implementations, but I certainly > >>> see that *[3] or node()[3] would be implementation specific. > >> We are just talking about 1 manager issuing a > >> or a with a an XPath filter to 1 particular agent. > >> > >> If the manager issues the same command 2 times in a row > >> with the same XPath (I don't care what it is), and no nodes > >> have been added or removed from the database, > >> and no values in the database have changed at all: > >> > >> Will the manager get the same answer or not? > >> > >> If not, why not? > >> > >> I understand that results from different agents > >> may not be the same, even for the same (*) > >> database contents. > >> > >> > >> * configurations can only be compared outside the database, > >> represented as XML documents. > > > > Previously, Andy also wrote: > > > >> Do we at least agree that the order must be consistent within > >> a single implementation? > > > >> If the affected portion of the database has not > >> changed at all, and if a manager retrieves /foo[3] or > >> runs a must-test on /foo[3] at T0 and then T1, will > >> the result be the same each time? > > > >> IMO, MUST be yes. > > > > I absolutely think that, within an implementation, this should be consistent. > > Should the text that Andy suggested be added? > > > > Not so sure about the must-test anymore. > Just and . > > What about a warning that the order MAY NOT be stable instead? That is what I expect from a database, unless there is a defined sort order. One large, highly respectable, relational database gives me a different answer almost every time to my identical SQL query, even a few seconds later. I have found empirically that unless I specify a sort, the order is that of least recently used, except that a large reply will have several blocks within each of which the order is least recently used and the order of the blocks is To Be Ascertained:-( All doubtless very natural to the implementer of the code. Some schemes of object identifiers have a fairly natural and obvious sort order; YANG does not so I do not think that positional predicates will ever make sense. So, IMO, MUST be No. Tom Petch > It is possible that internal natural sort order > within the agent changes due to tree balancing > or some internal periodic 'cleanup routine'. > Let's stay far away from standardizing agent internals, > and stick to the PDU exchanges instead. > > IMO, the first point is the main one -- an application > can compare the content of PDUs. Period. > That is the only XML instance document in NETCONF, and the > only way full XPath can be used reliably. > > > David > > Andy From andy@netconfcentral.com Tue Feb 17 13:44:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DFC3A6A15 for ; Tue, 17 Feb 2009 13:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRTkoGQKrwIX for ; Tue, 17 Feb 2009 13:44:48 -0800 (PST) Received: from n29.bullet.mail.mud.yahoo.com (n29.bullet.mail.mud.yahoo.com [68.142.207.48]) by core3.amsl.com (Postfix) with SMTP id A7E9C3A6964 for ; Tue, 17 Feb 2009 13:44:43 -0800 (PST) Received: from [209.191.108.96] by n29.bullet.mail.mud.yahoo.com with NNFMP; 17 Feb 2009 21:44:55 -0000 Received: from [68.142.201.245] by t3.bullet.mud.yahoo.com with NNFMP; 17 Feb 2009 21:44:55 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 17 Feb 2009 21:44:55 -0000 X-Yahoo-Newman-Id: 227529.77602.bm@omp406.mail.mud.yahoo.com Received: (qmail 64670 invoked from network); 17 Feb 2009 21:44:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.70.173 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 21:44:54 -0000 X-YMail-OSG: XK82jRgVM1nfLi5elpigFLkcfI5wnXpj7NTlYE3gEPFso8H1VU1FutWQO9OwtCzAu.n8Glo_XobosKZsvdu7k4Q1z.Wz6vXdggwVhltup3IBn3WjradDtgUgs2MRhZoNUDqzT2tvITC7Uh10Wji2j9i4_yylUBIxbc3NP6F7r6fehM9OSDn1cOq5YIVg4gIVEQjoQNg_hHPWzvVCVmiS9Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499B2FD5.60909@netconfcentral.com> Date: Tue, 17 Feb 2009 13:44:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> In-Reply-To: <20090217.161825.79948319.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:44:49 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Consider the example below. >> Does the agent advertise capabilities for both module >> revisions for 'Z'? > > No. > >> Or just the highest value? > > It would advertise Z only if it implements the container 'foo', and it > would advertise the version it implements. > > "library modules" are not advertised. > >> Does the draft need some text that says a manager must inspect >> all the module capabilities for a given module-name, >> because there may be more than 1? > > Never more than 1. > >> What happens when module X tries to refine leaf y-A, >> (that is defined with module Y's notion of type Z:A)? >> Module Z is using a different typedef for y-A. >> Is this an error? Does one version win out over the other? >> Does an implementor just choose whatever they want to do? > > All type- and grouping references are resolved at "compile time". > Thus, leaf Y-a is always the same in module X, regardless of which > version of Z is imported by module X, or other modules. > > thanks. Implementation makes a little more sense now. This is not intuitive for the module 'X' data model writer, who will need to know that objects from groupings may not have the same typedef semantics as objects that are not from groupings. It is critical to follow the prefixes. > > /martin > > Andy From andy@netconfcentral.com Tue Feb 17 14:01: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 0C9673A6A15 for ; Tue, 17 Feb 2009 14:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 X+yIcpkLv4qb for ; Tue, 17 Feb 2009 14:01:36 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 6452F3A67D7 for ; Tue, 17 Feb 2009 14:01:36 -0800 (PST) Received: (qmail 81864 invoked from network); 17 Feb 2009 22:01:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.70.173 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 22:01:47 -0000 X-YMail-OSG: LTkE7q0VM1k5qxmVIpBd.paugDC_GPPLXA8P82HIWgPKF22eidCHE_fxcmTIOebIBwrV27jrhTSMQFI9xZM_9WABsEmNeQT0UZeFkbEhaYdiE2ZOzsklykHEnHAPHpqaaPPbtSHGjC11jyTkJXihNYAh X-Yahoo-Newman-Property: ymail-3 Message-ID: <499B33C9.2070900@netconfcentral.com> Date: Tue, 17 Feb 2009 14:01:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> In-Reply-To: <20090217.161825.79948319.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:01:37 -0000 Hi, What about multiple imports or includes within the same [sub]module? The text in 7.1.6 and 7.1.7 seems to suggest the opposite. IMO, it MUST be an error to directly include or import multiple revisions of the same [sub]module. I think this was the consensus at the interim. module X { ... revision "2009-02-17" { description ""; } import Y { prefix Y; revision "2009-01-01"; } import Z { prefix Z1; revision "2009-02-01"; } import Z { prefix Z2; revision "2008-12-12"; } leaf a1 { type Z1:A; } leaf a2 { type Z2:A; } uses Y:YAZ { refine Y-a { ... } } } This is just complexity waiting to fall off the slippery slope. The data modeler must be forced to choose one version of 'Z' to import. > /martin > > Andy From mbj@tail-f.com Tue Feb 17 14:19: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 6746B3A68BC for ; Tue, 17 Feb 2009 14:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.168, 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 VVQlnbD6gn05 for ; Tue, 17 Feb 2009 14:19:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9977C3A6812 for ; Tue, 17 Feb 2009 14:19:28 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2605476C32E; Tue, 17 Feb 2009 23:19:33 +0100 (CET) Date: Tue, 17 Feb 2009 23:19:32 +0100 (CET) Message-Id: <20090217.231932.141813894.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <499B33C9.2070900@netconfcentral.com> References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> <499B33C9.2070900@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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:19:29 -0000 Andy Bierman wrote: > Hi, > > What about multiple imports or includes within the same [sub]module? > > The text in 7.1.6 and 7.1.7 seems to suggest the opposite. > > IMO, it MUST be an error to directly include or import > multiple revisions of the same [sub]module. > I think this was the consensus at the interim. Yes, I think you're right about this being the consensus. > leaf a1 { type Z1:A; } > > leaf a2 { type Z2:A; } But note that there are not really any theoretical problems with this; just look at the two leafs a1 and a2 above. They clearly use different types, and each type is resolved (and fixed) when it is used. If we don't allow multiple imports, there is a workaroud by using submodules: submodule s1 { belongs-to Y { ... } import Z { prefix Z1; revision "2009-02-01"; } typedef A-s1 { type Z1:a; } } submodule s2 { belongs-to Y { ... } import Z { prefix Z2; revision "2008-12-12"; } typedef A-s2 { type Z2:a; } } module Y { ... include s1; include s2; leaf a1 { type A-s1; } leaf a2 { type A-s2; } } Multiple includes will not work though. /martin From andy@netconfcentral.com Tue Feb 17 14:34: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 98E2B3A67A7 for ; Tue, 17 Feb 2009 14:34:41 -0800 (PST) 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.234, 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 MbAQZEln5KtS for ; Tue, 17 Feb 2009 14:34:40 -0800 (PST) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by core3.amsl.com (Postfix) with SMTP id CCFC43A67D7 for ; Tue, 17 Feb 2009 14:34:40 -0800 (PST) Received: from [216.252.122.216] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 17 Feb 2009 22:19:14 -0000 Received: from [68.142.200.227] by t1.bullet.sp1.yahoo.com with NNFMP; 17 Feb 2009 22:34:52 -0000 Received: from [68.142.201.249] by t8.bullet.mud.yahoo.com with NNFMP; 17 Feb 2009 22:34:52 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 17 Feb 2009 22:34:52 -0000 X-Yahoo-Newman-Id: 13565.28706.bm@omp410.mail.mud.yahoo.com Received: (qmail 64165 invoked from network); 17 Feb 2009 22:34:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.70.173 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2009 22:34:51 -0000 X-YMail-OSG: c3ASnR0VM1k9w97B0sv8VxM4RXT8_BPU2xPwuBxivc4sPDqXx0wlZIdf5cCFxZM3IY5UhOaL8PbBaydPc1IsFzv9UT1PsyNGnXw6jrAdKn6BXm_yXB6GcZEwytKdEwY53QCbu5ApR68QppIECWnlGVWmRhPcTekFrIjZuIrCGuLKKie7wkrZ7Fjlv7kS6.T3H2TMvHp8ulM6EjWKZ.4aMQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499B3B89.2050506@netconfcentral.com> Date: Tue, 17 Feb 2009 14:34:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> <499B33C9.2070900@netconfcentral.com> <20090217.231932.141813894.mbj@tail-f.com> In-Reply-To: <20090217.231932.141813894.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:34:41 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> What about multiple imports or includes within the same [sub]module? >> >> The text in 7.1.6 and 7.1.7 seems to suggest the opposite. >> >> IMO, it MUST be an error to directly include or import >> multiple revisions of the same [sub]module. >> I think this was the consensus at the interim. > > Yes, I think you're right about this being the consensus. > >> leaf a1 { type Z1:A; } >> >> leaf a2 { type Z2:A; } > > But note that there are not really any theoretical problems with > this; just look at the two leafs a1 and a2 above. They clearly use > different types, and each type is resolved (and fixed) when it is > used. > > If we don't allow multiple imports, there is a workaroud by using > submodules: > > submodule s1 { > belongs-to Y { ... } > > import Z { > prefix Z1; > revision "2009-02-01"; > } > > typedef A-s1 { > type Z1:a; > } > } > > submodule s2 { > belongs-to Y { ... } > > import Z { > prefix Z2; > revision "2008-12-12"; > } > > typedef A-s2 { > type Z2:a; > } > } > > module Y { > ... > include s1; > include s2; > > leaf a1 { type A-s1; } > leaf a2 { type A-s2; } > } > > > Multiple includes will not work though. > This is one of the reasons I was against adding import-by-revision at the interim -- sub-modules can each have different revisions for all their imports. IMO this breaks the concept that sub-modules are merely physical partitions of a main module into multiple files. Instead they are really full-blown modules that happen to all use the same XML namespace. (BTW, are submodules advertised in the module capabilities? IMO this is too much detail, but what if the include does not specify a revision, like in your example)? > > > /martin > > Andy From balazs.lengyel@ericsson.com Wed Feb 18 01:47: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 B369528C0F5 for ; Wed, 18 Feb 2009 01:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVqy68F9njGA for ; Wed, 18 Feb 2009 01:47:09 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AF0BB3A6AB0 for ; Wed, 18 Feb 2009 01:47:08 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4C10922592; Wed, 18 Feb 2009 10:44:16 +0100 (CET) X-AuditID: c1b4fb3c-a9281bb00000127c-ea-499bd79166cf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 351452223A; Wed, 18 Feb 2009 10:40:33 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 10:39:45 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 10:39:45 +0100 Message-ID: <499BD760.2010208@ericsson.com> Date: Wed, 18 Feb 2009 10:39:44 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> <499AAA8B.2010104@netconfcentral.com> In-Reply-To: <499AAA8B.2010104@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2009 09:39:45.0094 (UTC) FILETIME=[D5035E60:01C991AC] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 09:47:09 -0000 Ericsson has nodes with a proprietary programming language that does not even have a float datatype. I fully agree this is very low priority. Did you ever need more then 3 digits of precision in any counters, config parameters? Balazs Andy Bierman wrote: > IMO, FP numbers are an extremely low priority > in our NM problem space. We deal with Counter32 and Counter64. > On very rare occasions when FP has been needed, suitable hacks > using ordinal numbers or more than 1 MIB object have been > sufficient instead. Statistical analysis is usually done > on the NMS, so FP division is not even needed for that on the agent. From j.schoenwaelder@jacobs-university.de Wed Feb 18 02:13: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 4717728C176 for ; Wed, 18 Feb 2009 02:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, 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 zTYug2jxV0ax for ; Wed, 18 Feb 2009 02:13:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 34A1C28C125 for ; Wed, 18 Feb 2009 02:13:30 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 096BAC0078; Wed, 18 Feb 2009 11:13:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GDRjsuvuYeQV; Wed, 18 Feb 2009 11:13:36 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAF51C010D; Wed, 18 Feb 2009 11:13:35 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id B8D239A509B; Wed, 18 Feb 2009 11:13:34 +0100 (CET) Date: Wed, 18 Feb 2009 11:13:34 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090218101334.GB8933@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Balazs Lengyel , Andy Bierman , netmod@ietf.org References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> <499AAA8B.2010104@netconfcentral.com> <499BD760.2010208@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499BD760.2010208@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 10:13:31 -0000 On Wed, Feb 18, 2009 at 10:39:44AM +0100, Balazs Lengyel wrote: > Ericsson has nodes with a proprietary programming language that does not > even have a float datatype. I fully agree this is very low priority. > > Did you ever need more then 3 digits of precision in any counters, config parameters? Precision definitely yes - especially if you mention counters in the way SNMP people understand counters. And I believe if we do floats, we would be badly advised to limit their precision to 3 digits. /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 Wed Feb 18 02:16: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 ECD5D28C1F6 for ; Wed, 18 Feb 2009 02:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 EQ2MSKTFUI55 for ; Wed, 18 Feb 2009 02:16:51 -0800 (PST) Received: from n7.bullet.mud.yahoo.com (n7.bullet.mud.yahoo.com [216.252.100.58]) by core3.amsl.com (Postfix) with SMTP id 6B44728C1E3 for ; Wed, 18 Feb 2009 02:16:47 -0800 (PST) Received: from [68.142.194.243] by n7.bullet.mud.yahoo.com with NNFMP; 18 Feb 2009 10:16:59 -0000 Received: from [68.142.201.251] by t1.bullet.mud.yahoo.com with NNFMP; 18 Feb 2009 10:16:59 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 18 Feb 2009 10:16:59 -0000 X-Yahoo-Newman-Id: 343157.5806.bm@omp412.mail.mud.yahoo.com Received: (qmail 93784 invoked from network); 18 Feb 2009 10:16:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.70.173 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 18 Feb 2009 10:16:58 -0000 X-YMail-OSG: bqjyMG8VM1lioUXfi1ZIXZK_cJtqFJVdtafhM8S5vvUywLpnvBHvw6IrrNZsXJavK4gvg2VKQv9tCJ90WTwEChLN4NAOhSvKnMJdFw0OUqtAH0.W7J3QF0O5Fq4IbAvxiiiYIG9Xt87dCrHEFlW9MSsi X-Yahoo-Newman-Property: ymail-3 Message-ID: <499BE018.9010002@netconfcentral.com> Date: Wed, 18 Feb 2009 02:16:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> <499AAA8B.2010104@netconfcentral.com> <499BD760.2010208@ericsson.com> In-Reply-To: <499BD760.2010208@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 10:16:52 -0000 Balazs Lengyel wrote: > Ericsson has nodes with a proprietary programming language that does not > even have a float datatype. I fully agree this is very low priority. > > Did you ever need more then 3 digits of precision in any counters, > config parameters? Actually, SNMP counter size is picked based on whether or not the counter can roll over in less than an hour. (I worked on IOS for 10 years, which didn't have FP at all. The interrupts were 'borrowed' for other purposes on some platforms.) As I've said before: Adding FP support for network management is a non-starter on so many levels. But a YANG implementation can hardwire the must/when (as the draft points out), and not really do any FP math at all (yeah, right ;-) > Balazs > Andy > Andy Bierman wrote: >> IMO, FP numbers are an extremely low priority >> in our NM problem space. We deal with Counter32 and Counter64. >> On very rare occasions when FP has been needed, suitable hacks >> using ordinal numbers or more than 1 MIB object have been >> sufficient instead. Statistical analysis is usually done >> on the NMS, so FP division is not even needed for that on the agent. > > From balazs.lengyel@ericsson.com Wed Feb 18 02:40: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 6B76C3A6358 for ; Wed, 18 Feb 2009 02:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.166 X-Spam-Level: X-Spam-Status: No, score=-5.166 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 UvZmaDFfxTEl for ; Wed, 18 Feb 2009 02:40:39 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 56F383A6920 for ; Wed, 18 Feb 2009 02:40:39 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 228E5214D0; Wed, 18 Feb 2009 11:40:50 +0100 (CET) X-AuditID: c1b4fb3e-af0c1bb000001315-c1-499be5ae5605 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 011A721599; Wed, 18 Feb 2009 11:40:47 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 11:40:35 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 11:40:35 +0100 Message-ID: <499BE5A3.7000804@ericsson.com> Date: Wed, 18 Feb 2009 11:40:35 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , Andy Bierman , netmod@ietf.org References: <20090209143256.GA26625@elstar.iuhb02.iu-bremen.de> <20090217.082826.31679778.mbj@tail-f.com> <499AA109.9020403@netconfcentral.com> <20090217.125007.166508893.mbj@tail-f.com> <499AAA8B.2010104@netconfcentral.com> <499BD760.2010208@ericsson.com> <20090218101334.GB8933@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090218101334.GB8933@elstar.iuhb02.iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2009 10:40:35.0194 (UTC) FILETIME=[54A46DA0:01C991B5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] canonical form of floats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 10:40:40 -0000 I meant float values with a precision of more then 3 digits. (I know counter64 has more then 3 digits.) I am curios whether you have ever used float values with more then 3 digits of precision? Sorry for the misunderstanding. Balazs Juergen Schoenwaelder wrote: > On Wed, Feb 18, 2009 at 10:39:44AM +0100, Balazs Lengyel wrote: >> Ericsson has nodes with a proprietary programming language that does not >> even have a float datatype. I fully agree this is very low priority. >> >> Did you ever need more then 3 digits of precision in any counters, config parameters? > > Precision definitely yes - especially if you mention counters in the > way SNMP people understand counters. > > And I believe if we do floats, we would be badly advised to limit > their precision to 3 digits. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From j.schoenwaelder@jacobs-university.de Wed Feb 18 05:58: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 B40823A6D15 for ; Wed, 18 Feb 2009 05:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 l6crLSKeAsZ3 for ; Wed, 18 Feb 2009 05:58:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 618FF3A6887 for ; Wed, 18 Feb 2009 05:58:41 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35C73C0123 for ; Wed, 18 Feb 2009 14:58:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r7rKPUur7sgr; Wed, 18 Feb 2009 14:58:47 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6185FC0012; Wed, 18 Feb 2009 14:58:47 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 3ED739A5B4A; Wed, 18 Feb 2009 14:58:46 +0100 (CET) Date: Wed, 18 Feb 2009 14:58:46 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090218135846.GC9755@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] enumerate / bits restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:58:42 -0000 The YANG language does not support the restricting of enumeration and bits types. The following example is therefore not legal YANG: typedef color { type enumeration { enum black { value 0x000000; } enum red { value 0xff0000; } enum green { value 0x00ff00; } enum blue { value 0x0000ff; } enum white { value 0xffffff; } } } typedef monochrome { type color { enum white; enum black; } } leaf status { type color { enum red; enum green; } } Note that the SMIv2 does allow the restriction of named numbers when you write object definitions or in conformance statements and this is being used in MIB modules. The proposal is to support this kind of subtying in YANG. This requires to replace the text in section 9.6.4 with something like this: An enumeration type can be restricted to a subset of the enumerated values by using the "enum" statement (Section XYZ). Note that restrictions can not add new enums to a type nor can they change the value associated with an enum. And similarly for the section 9.7.4, add the following: The named bits can be restricted using the "bit" statement (Section XYZ). Note that restrictions can not add new bits to a type nor can they change the position associated with an enum. /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 Fri Feb 20 17:35: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 A50C13A6A10 for ; Fri, 20 Feb 2009 17:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly05t7wQ7TFQ for ; Fri, 20 Feb 2009 17:35:26 -0800 (PST) Received: from n6.bullet.mud.yahoo.com (n6.bullet.mud.yahoo.com [216.252.100.57]) by core3.amsl.com (Postfix) with SMTP id 96D9D3A6964 for ; Fri, 20 Feb 2009 17:35:26 -0800 (PST) Received: from [68.142.194.243] by n6.bullet.mud.yahoo.com with NNFMP; 21 Feb 2009 01:35:41 -0000 Received: from [68.142.201.252] by t1.bullet.mud.yahoo.com with NNFMP; 21 Feb 2009 01:35:41 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 21 Feb 2009 01:35:41 -0000 X-Yahoo-Newman-Id: 765210.64994.bm@omp413.mail.mud.yahoo.com Received: (qmail 6376 invoked from network); 21 Feb 2009 01:35:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.71 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 21 Feb 2009 01:35:40 -0000 X-YMail-OSG: CXS8z.0VM1m_ZI0oYAUFBofUHpoEHBDZs6RZ8i6WnVcgZF9SR6PPRRwJQOcsANjaBjhMJwkxegAeAVzETRvawm__3rcpyMAXMVXJl_bOcclXUasr1_x0T6PFhYBd28zLTjBfE4agTCqELDgIvXu4lAr6s_60F_jIwRNv75R1lg9tqOIPf9F0.o21nbVbxxQ5jTsfV1FpmhP7NNHeO3YOKA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499F5A6B.4010101@netconfcentral.com> Date: Fri, 20 Feb 2009 17:35:39 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> In-Reply-To: <20090217.161825.79948319.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 01:35:27 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Consider the example below. >> Does the agent advertise capabilities for both module >> revisions for 'Z'? > > No. > >> Or just the highest value? > > It would advertise Z only if it implements the container 'foo', and it > would advertise the version it implements. > > "library modules" are not advertised. > module A { ... import B { prefix B; } ... container foo { uses B:Group1; } } I ran into some implementation problems on this one. Consider module 'A' which imports 'B'. The manager will know the correct version of 'A' to use because it will be in the . But the manager has N versions of 'B' available. Module B just has groupings and typedefs in it, and since it is a library module, it is not advertised at all. IMO, it takes a major commitment to use import-by-revision, making sure the revision dates line up exactly right. It may be left out often, in which case (of course) the manager is back at square one, not knowing which version of 'Group1' to use. There seems to be no solution possible without the agent advertising the library file 'B', but there might be N active versions of 'B' within the agent, so that doesn't always work either. But if the agent implements 1 or 2 of 10 versions it would help. The only other solution seems to be to make the revision mandatory, and the WG consensus is against that. I think the draft should be changed to allow the agent to advertise all the modules it implements if it wants. More info helps debugging. It also helps applications put up more intelligent dialog boxes to pick the right version. I never understood this CLR from the start, and now in implementation, it is getting in the way. Andy From mbj@tail-f.com Sat Feb 21 03:07:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25653A69C7 for ; Sat, 21 Feb 2009 03:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.137, 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 R6LeQ8P7rmyJ for ; Sat, 21 Feb 2009 03:07:20 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 36B433A6A93 for ; Sat, 21 Feb 2009 03:07:20 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0794176C310; Sat, 21 Feb 2009 12:07:34 +0100 (CET) Date: Sat, 21 Feb 2009 12:07:33 +0100 (CET) Message-Id: <20090221.120733.133989549.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <499F5A6B.4010101@netconfcentral.com> References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> <499F5A6B.4010101@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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 11:07:21 -0000 Andy Bierman wrote: > I think the draft should be changed to allow the agent to > advertise all the modules it implements if it wants. So we should change this text: Modules that do not contribute any data definitions, rpcs, notifications, or deviations to the device are not advertised in the message. with s/are not/SHOULD NOT/ s/are not/MAY be/ ? You're reasoning works fine for pure library modules, but if B in your example also define some data definition nodes, and your agent does not implement them, it would be wrong to advertise it. /martin From andy@netconfcentral.com Sat Feb 21 07:28: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 50A2F3A68F9 for ; Sat, 21 Feb 2009 07:28:04 -0800 (PST) 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 G+BOT+Yuhqsw for ; Sat, 21 Feb 2009 07:28:03 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B0B3C3A68CC for ; Sat, 21 Feb 2009 07:28:03 -0800 (PST) Received: (qmail 35219 invoked from network); 21 Feb 2009 15:28:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.71 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 21 Feb 2009 15:28:18 -0000 X-YMail-OSG: 1XySdlcVM1mmDCVv0XTthTa32PHmA92IsfwJTKPI9nnD1Sog_651cyDWd0vcdTGlZBhOPL3QZ3xVuf3xBNS7Xs1eHDOpwQf9ZstNnuyrPNQbnozPZwq5NuN3_esG333IfBKMjV7x8HZcpibCNFgsEpSPINDIfTAe9ITpjfpUJLMMkbmt.ZKfanqujYNb4c5Y.B5RXa0TU2O2iyLsZ1WMDg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A01D90.80700@netconfcentral.com> Date: Sat, 21 Feb 2009 07:28:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> <499F5A6B.4010101@netconfcentral.com> <20090221.120733.133989549.mbj@tail-f.com> In-Reply-To: <20090221.120733.133989549.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 15:28:04 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I think the draft should be changed to allow the agent to >> advertise all the modules it implements if it wants. > > So we should change this text: > > Modules that do not contribute any data definitions, rpcs, > notifications, or deviations to the device are not advertised in the > message. > > with s/are not/SHOULD NOT/ > s/are not/MAY be/ > > ? > > You're reasoning works fine for pure library modules, but if B in your > example also define some data definition nodes, and your agent does > not implement them, it would be wrong to advertise it. > It is not fool-proof, but if there is one version of the library module then it solves the problem completely. If there are objects in the module though, then the agent will advertise more than one version of it. The logic at it stands now is already broken. What if there are objects that are conditional due to false 'if-feature' or 'when' statements? I can advertise module 'A', and the submodules of 'A' can pull in all kinds different definitions via 'uses' and none of it may be visible to the manager. IMO, the module capability URI is something of a hack, and loading it down with CLRs doesn't change that. In any event, I don't see how giving more information to the manager impair interoperability. It seems to only help in most scenarios. > > > /martin > > Andy From andy@netconfcentral.com Sat Feb 21 08:09: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 0AFD73A688F for ; Sat, 21 Feb 2009 08:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IygejOc0dmMm for ; Sat, 21 Feb 2009 08:09:12 -0800 (PST) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 3353B3A685C for ; Sat, 21 Feb 2009 08:09:12 -0800 (PST) Received: (qmail 68194 invoked from network); 21 Feb 2009 16:09:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.71 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 21 Feb 2009 16:09:27 -0000 X-YMail-OSG: JBxv2xgVM1kcWRhOoMrUWzrVsQQJxq6vFeyNgemigPEk.QAVGrlRQOHySDPLyqRs9FpXQPxXHnx6onHbUIY.loLdBUv1PvWFLDTVP_sDIdeKbW2DkE0simkg0aZNg1qbMVcZJLXwY0tzJEVa3A2uFxuBE8Y8rEbora2l6NvUCegkRu1F2TALmYhwn6SsdIhVOD_esCI2PIXsnLlsD_67xQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A02736.3070500@netconfcentral.com> Date: Sat, 21 Feb 2009 08:09:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499ACE9F.4030202@netconfcentral.com> <20090217.161825.79948319.mbj@tail-f.com> <499F5A6B.4010101@netconfcentral.com> <20090221.120733.133989549.mbj@tail-f.com> In-Reply-To: <20090221.120733.133989549.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 16:09:13 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I think the draft should be changed to allow the agent to >> advertise all the modules it implements if it wants. > > So we should change this text: > > Modules that do not contribute any data definitions, rpcs, > notifications, or deviations to the device are not advertised in the > message. > > with s/are not/SHOULD NOT/ > s/are not/MAY be/ > > ? > > You're reasoning works fine for pure library modules, but if B in your > example also define some data definition nodes, and your agent does > not implement them, it would be wrong to advertise it. > Perhaps you could add some text in the draft that just says that usage of groupings and typedefs across modules or sub-modules needs to be done carefully, if those definitions ever need to be changed during the lifetime of the data model. I think an example module with a grouping would help. (e.g., version 1 has a leaf, version 2 adds a leaf). When import/include by revision is complete (no missing revision dates at all), it works perfectly, and is even quite impressive. No matter how you scramble the definitions, everything just works. But as soon as the 'revision-date chain' is broken, it all starts to fall apart. Keeping typedefs/groupings in a separate module from any objects/rpcs/notifications will certainly help. This concept has already proven useful in SMIv2, and will really be important in YANG. > > > /martin > > Andy From mbj@tail-f.com Sat Feb 21 13:36: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 BA1453A6917 for ; Sat, 21 Feb 2009 13:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.126, 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 4vgfafMhElKv for ; Sat, 21 Feb 2009 13:36:09 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CFB4E3A68A9 for ; Sat, 21 Feb 2009 13:36:08 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EA4E576C32E; Sat, 21 Feb 2009 22:36:22 +0100 (CET) Date: Sat, 21 Feb 2009 22:36:22 +0100 (CET) Message-Id: <20090221.223622.27389259.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A01D90.80700@netconfcentral.com> References: <499F5A6B.4010101@netconfcentral.com> <20090221.120733.133989549.mbj@tail-f.com> <49A01D90.80700@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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 21:36:09 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I think the draft should be changed to allow the agent to > >> advertise all the modules it implements if it wants. > > So we should change this text: > > Modules that do not contribute any data definitions, rpcs, > > notifications, or deviations to the device are not advertised in the > > message. > > with s/are not/SHOULD NOT/ > > s/are not/MAY be/ > > ? > > You're reasoning works fine for pure library modules, but if B in your > > example also define some data definition nodes, and your agent does > > not implement them, it would be wrong to advertise it. > > > > It is not fool-proof, but if there is one version of the library module > then it solves the problem completely. Yes. > If there are objects in the > module though, then the agent will advertise more than one version of it. > > The logic at it stands now is already broken. > What if there are objects that are conditional > due to false 'if-feature' The agent advertises the module uri with the 'features' parameter. > or 'when' statements? Objects covered by 'when' statements are implemented, but might not be present due to the dynamic nature of the when expression. > IMO, the module capability URI is something of a hack, > and loading it down with CLRs doesn't change that. > In any event, I don't see how giving more information to > the manager impair interoperability. It seems to only > help in most scenarios. So if my proposals for changed text was not what you were looking for, could you suggest some text? /martin From mbj@tail-f.com Sat Feb 21 13:39: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 E392D3A69A8 for ; Sat, 21 Feb 2009 13:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.117, 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 6eF3vNWxgh6j for ; Sat, 21 Feb 2009 13:39:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 210DA3A6892 for ; Sat, 21 Feb 2009 13:39:32 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C7ED976C32E; Sat, 21 Feb 2009 22:39:47 +0100 (CET) Date: Sat, 21 Feb 2009 22:39:47 +0100 (CET) Message-Id: <20090221.223947.221293998.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A02736.3070500@netconfcentral.com> References: <499F5A6B.4010101@netconfcentral.com> <20090221.120733.133989549.mbj@tail-f.com> <49A02736.3070500@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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 21:39:33 -0000 Andy Bierman wrote: > When import/include by revision is complete (no missing > revision dates at all), it works perfectly, and is even > quite impressive. No matter how you scramble the definitions, > everything just works. > > But as soon as the 'revision-date chain' is broken, it > all starts to fall apart. Keeping typedefs/groupings in > a separate module from any objects/rpcs/notifications > will certainly help. This concept has already proven > useful in SMIv2, and will really be important in YANG. Right. But in one case it might work better w/o import by revision; with a module like IANAifType-MIB. OTOH, maybe this kind of information would be better defined using identities in YANG. /martin From andy@netconfcentral.com Sat Feb 21 15: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 E21D33A6825 for ; Sat, 21 Feb 2009 15:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phxezpif0KY1 for ; Sat, 21 Feb 2009 15:02:05 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id EA0DF3A6816 for ; Sat, 21 Feb 2009 15:02:05 -0800 (PST) Received: (qmail 99787 invoked from network); 21 Feb 2009 23:02:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.52 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 21 Feb 2009 23:02:20 -0000 X-YMail-OSG: C.ueyREVM1lhgi6f7SXT8c31OJPg0qSB3C9XqQxKN5goIA3i1tPZTO38CEVtOf6zwgMTJPFYCFR7eolg75C_Y1l0nSYwCCFKAkrLB_FIywHdZ24vWREhnKSeicqoOWVyUMYhNUg4rlYXCQ2rXzQwk_rCWkwl_zV3uNccnC8vHRPRLnpTs6.sMwvlqzW9zV6PEjJrFygYyrfM7v2K16VO.w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A087FB.4000908@netconfcentral.com> Date: Sat, 21 Feb 2009 15:02:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <499F5A6B.4010101@netconfcentral.com> <20090221.120733.133989549.mbj@tail-f.com> <49A01D90.80700@netconfcentral.com> <20090221.223622.27389259.mbj@tail-f.com> In-Reply-To: <20090221.223622.27389259.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:02:07 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> I think the draft should be changed to allow the agent to >>>> advertise all the modules it implements if it wants. >>> So we should change this text: >>> Modules that do not contribute any data definitions, rpcs, >>> notifications, or deviations to the device are not advertised in the >>> message. >>> with s/are not/SHOULD NOT/ >>> s/are not/MAY be/ >>> ? >>> You're reasoning works fine for pure library modules, but if B in your >>> example also define some data definition nodes, and your agent does >>> not implement them, it would be wrong to advertise it. >>> >> It is not fool-proof, but if there is one version of the library module >> then it solves the problem completely. > > Yes. > >> If there are objects in the >> module though, then the agent will advertise more than one version of it. >> >> The logic at it stands now is already broken. >> What if there are objects that are conditional >> due to false 'if-feature' > > The agent advertises the module uri with the 'features' parameter. > right -- forgot about that. (BTW, is there any text about what the agent does if it can no longer support a feature it gave to a currently open session? Drop the session? Resend the ?) >> or 'when' statements? > > Objects covered by 'when' statements are implemented, but might not be > present due to the dynamic nature of the when expression. > >> IMO, the module capability URI is something of a hack, >> and loading it down with CLRs doesn't change that. >> In any event, I don't see how giving more information to >> the manager impair interoperability. It seems to only >> help in most scenarios. > > So if my proposals for changed text was not what you were looking for, > could you suggest some text? > I should have looked closer. It looks like multiple choice. I prefer: s/are not/MAY be/ How about adding a sentence that says the agent SHOULD omit any redundant module capability information (without going into details or CLRs)? > > /martin > > Andy From andy@andybierman.com Sun Feb 22 11:21: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 5C6C13A68AC for ; Sun, 22 Feb 2009 11:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=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 Q-BpX-Z2mc-X for ; Sun, 22 Feb 2009 11:21:03 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id A169C3A6823 for ; Sun, 22 Feb 2009 11:21:00 -0800 (PST) Received: (qmail 46244 invoked from network); 22 Feb 2009 19:21:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.52 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 22 Feb 2009 19:21:17 -0000 X-YMail-OSG: IfeHRZIVM1mk.ujTZ8NPS5.bherEyjy7D31avSKFuAA6G5Fd8AbFzWs3WcQcM7mSmpJI5cgxGGtpX0L97tpj7AIwS9bk.5LSb1x8N1fZtm8LlPbE6Te0PJXnPxdtyj_X9Z2FWduKehdINoQu3J5qrRFm X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A1A5AC.90901@andybierman.com> Date: Sun, 22 Feb 2009 11:21:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] import-by-revision guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:21:04 -0000 Hi, I changed my mind about some elaborate scheme to pick the 'best' revision if it is left out. I think the draft had it right the first time -- implementation-dependent. If revision specified in import/include: that exact revision must match Else: tool will find module in implementation-dependent manner I plan to put a section in the YANG usage guidelines draft about import-by-revision, but hopefully there will be consensus on the details first. Of course, standards-track modules MUST use revision dates, but there are a lot of considerations for other types of YANG modules. The following applies to submodules/include as well. There are 3 independent boolean variables: importer: module with the import-stmt yes: import X { prefix x; revision 2009-01-01; } no: import X { prefix x; } imported: module being imported yes: revision 2009-01-01 { description ""; } no: // no revision-stmts filename: yes: X.2009-01-01.yang no: X.yang +---------------------------------+--------+ | importer | imported | filename | result | +-----------+----------+----------+--------+ | no | no | no | (1) | +-----------+----------+----------+--------+ | no | no | yes | (1) | +-----------+----------+----------+--------+ | no | yes | no | (1) | +-----------+----------+----------+--------+ | no | yes | yes | (2) | +-----------+----------+----------+--------+ | yes | no | no | (3) | +-----------+----------+----------+--------+ | yes | no | yes | (3) | +-----------+----------+----------+--------+ | yes | yes | no | (4) | +-----------+----------+----------+--------+ | yes | yes | yes | (5) | +-----------+----------+----------+--------+ (1) Always accepted if any instance of module X found (2) Search first for X.yang, which fails; Then search for X.*.yang and return any instance of module X found (very implementation dependent) (3) Search fails, requested version not found (4) If any X.yang found, it is accepted only if its highest valued revision date matches the 'importer' value. (5) If any X.2009-01-01.yang found, it is accepted only if its highest valued revision date matches the 'importer' value. Andy From mbj@tail-f.com Sun Feb 22 12:44: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 E2E8628C116 for ; Sun, 22 Feb 2009 12:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.110, 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 4fqgul6cJ2Ci for ; Sun, 22 Feb 2009 12:44:52 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0B61028C0F6 for ; Sun, 22 Feb 2009 12:44:51 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3533B76C4D7; Sun, 22 Feb 2009 21:45:07 +0100 (CET) Date: Sun, 22 Feb 2009 21:45:06 +0100 (CET) Message-Id: <20090222.214506.192826457.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A087FB.4000908@netconfcentral.com> References: <49A01D90.80700@netconfcentral.com> <20090221.223622.27389259.mbj@tail-f.com> <49A087FB.4000908@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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:44:53 -0000 Hi, Andy Bierman wrote: > (BTW, is there any text about what the agent does if > it can no longer support a feature it gave to a > currently open session? Drop the session? Resend the ?) I think this is a general NETCONF issue - what if an agent no longer can support a capability it advertised? We have talked about this in the discussions about the monitoring draft. > > So if my proposals for changed text was not what you were looking for, > > could you suggest some text? > > > > I should have looked closer. > It looks like multiple choice. > I prefer: > > s/are not/MAY be/ Ok. > How about adding a sentence that says the agent SHOULD omit > any redundant module capability information (without going into > details > or CLRs)? I'd be hesitant to add this, because I think people might wonder what was meant with the word "redundant", and different implementors might interpret this differently. We should aim for clear rules about which uris MUST and MUST NOT be advertised, and say that the agent MAY advertise anything else. /martin From andy@netconfcentral.com Sun Feb 22 12:58: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 53AF928C128 for ; Sun, 22 Feb 2009 12:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epp-pWwhCiwg for ; Sun, 22 Feb 2009 12:58:44 -0800 (PST) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 5203A28C11C for ; Sun, 22 Feb 2009 12:58:44 -0800 (PST) Received: from [209.191.108.96] by n14.bullet.mail.mud.yahoo.com with NNFMP; 22 Feb 2009 20:59:01 -0000 Received: from [68.142.201.247] by t3.bullet.mud.yahoo.com with NNFMP; 22 Feb 2009 20:59:01 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 22 Feb 2009 20:59:01 -0000 X-Yahoo-Newman-Id: 12233.88503.bm@omp408.mail.mud.yahoo.com Received: (qmail 93401 invoked from network); 22 Feb 2009 20:59:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.52 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 22 Feb 2009 20:59:00 -0000 X-YMail-OSG: _Llm1RUVM1lgjFKW4Kd9Ao8C9Rw2OQeBa.KhUfAMJ5EV1urmUZpndRS5cgI1poGSqib4e93bolRujLh2P4uVsIu9zcyreBX1wZK9rfgClDCZO1zIJ_.I84LeWDnwoaQDvkb0XV__yKGYGDWcCaxTQEqEOgv7NtHuLCypp.0CSzmbh6KisZ5T8EQLsbVVuG3nYFlmnga5DfswCWx1QN85_w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A1BC92.7070207@netconfcentral.com> Date: Sun, 22 Feb 2009 12:58:58 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A01D90.80700@netconfcentral.com> <20090221.223622.27389259.mbj@tail-f.com> <49A087FB.4000908@netconfcentral.com> <20090222.214506.192826457.mbj@tail-f.com> In-Reply-To: <20090222.214506.192826457.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] module capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:58:45 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> (BTW, is there any text about what the agent does if >> it can no longer support a feature it gave to a >> currently open session? Drop the session? Resend the ?) > > I think this is a general NETCONF issue - what if an agent no longer > can support a capability it advertised? We have talked about this in > the discussions about the monitoring draft. > >>> So if my proposals for changed text was not what you were looking for, >>> could you suggest some text? >>> >> I should have looked closer. >> It looks like multiple choice. >> I prefer: >> >> s/are not/MAY be/ > > Ok. > >> How about adding a sentence that says the agent SHOULD omit >> any redundant module capability information (without going into >> details >> or CLRs)? > > I'd be hesitant to add this, because I think people might wonder what > was meant with the word "redundant", and different implementors might > interpret this differently. We should aim for clear rules about which > uris MUST and MUST NOT be advertised, and say that the agent MAY > advertise anything else. > good -- leave it out. another detail? what about submodules? Leave that for the monitoring draft, right? (It would require even more variants of the module-capability-URI.) > > /martin > > Andy From mbj@tail-f.com Sun Feb 22 13:00:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8914F28C18F for ; Sun, 22 Feb 2009 13:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_05=-1.11, 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 GCISG20GsTcA for ; Sun, 22 Feb 2009 13:00:57 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C651028C11C for ; Sun, 22 Feb 2009 13:00:57 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 68AB6616012; Sun, 22 Feb 2009 22:01:14 +0100 (CET) Date: Sun, 22 Feb 2009 22:01:14 +0100 (CET) Message-Id: <20090222.220114.172244782.mbj@tail-f.com> To: andy@andybierman.com From: Martin Bjorklund In-Reply-To: <49A1A5AC.90901@andybierman.com> References: <49A1A5AC.90901@andybierman.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] import-by-revision guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:00:58 -0000 Hi, Andy Bierman wrote: > I plan to put a section in the YANG usage guidelines draft > about import-by-revision, but hopefully there will be > consensus on the details first. I agree with your table (it's a bit unclear how row two could be, but the logic is fine.), and I think it is a very good idea to write about this in the guidelines draft (and I hope this draft will be a WG item) /martin From andy@netconfcentral.com Sun Feb 22 13:13: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 A7DD33A6ADA for ; Sun, 22 Feb 2009 13:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsOduG8tlHo6 for ; Sun, 22 Feb 2009 13:13:54 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 1005028C1C8 for ; Sun, 22 Feb 2009 13:11:30 -0800 (PST) Received: (qmail 93734 invoked from network); 22 Feb 2009 21:11:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.52 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 22 Feb 2009 21:11:46 -0000 X-YMail-OSG: opT0rmoVM1mIB3.r3K9PrtGgb4MK6VIdKWDlCFZTKRr0QgrU_Gqlt7y57Q.ZimwkxxC0MmT9tf0gvCASycTFrvDnVmn9Ub1.rBNTH2Lv6eyZFVLC2Hn3HgqQ9OIYjgZ8WfOfNPPqd_gs1aB173TzV3PQW.TcJ.XuU0i4_Suq1mOiJ4xcJNalhsdpDVVSgHr6iKBr.mmiJvwy1NQrgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A1BF91.50201@netconfcentral.com> Date: Sun, 22 Feb 2009 13:11:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A1A5AC.90901@andybierman.com> <20090222.220114.172244782.mbj@tail-f.com> In-Reply-To: <20090222.220114.172244782.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] import-by-revision guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:13:54 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I plan to put a section in the YANG usage guidelines draft >> about import-by-revision, but hopefully there will be >> consensus on the details first. > > I agree with your table (it's a bit unclear how row two could be, but > the logic is fine.), and I think it is a very good idea to write about > this in the guidelines draft (and I hope this draft will be a WG item) > > (sharp as ever) that is a cut-and-paste bug -- the result should be (2) instead > /martin Andy From andy@netconfcentral.com Wed Feb 25 02:31: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 AD4BD3A69B2 for ; Wed, 25 Feb 2009 02:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-1.058, 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 v5zzppHIvbl9 for ; Wed, 25 Feb 2009 02:31:02 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 1DDF13A697E for ; Wed, 25 Feb 2009 02:31:01 -0800 (PST) Received: (qmail 50189 invoked from network); 25 Feb 2009 10:31:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 10:31:21 -0000 X-YMail-OSG: qlC4OV4VM1kEEcb1CV6rlEmSEg9yHXB2zWCL87bVLUO5dDRT8t1pLlQPTtVVx9S3hUjebNb9QPOBo1ErQbFSnb9pych0W8W1J_9h6qxd_AnLEBvDyxoOoKtrmU_pBjfZfFdHMt0QDwWfWjGd1zMHopQU X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A51DF8.7030000@netconfcentral.com> Date: Wed, 25 Feb 2009 02:31:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] instance-identifier ABNF broken X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 10:31:02 -0000 Hi, The instance-identifier syntax does not allow for positional entries (/foo[3]). This is needed for lists without any keys. The only way to specify such a node is by its relative position. Andy From lhotka@cesnet.cz Wed Feb 25 03:00: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 8A2263A697F for ; Wed, 25 Feb 2009 03:00:43 -0800 (PST) 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.331, 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 dqYLOvAG-rEh for ; Wed, 25 Feb 2009 03:00:42 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BC8E63A6978 for ; Wed, 25 Feb 2009 03:00:42 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A9AB2D800D1 for ; Wed, 25 Feb 2009 12:01:01 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Wed, 25 Feb 2009 12:01:01 +0100 Message-Id: <1235559661.6385.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 11:00:43 -0000 Hi, Section 11.2 describing YANG-2-YIN algoritm should specify the namespace for the argument attribute/element - it is important for YIN encoding of extensions. I propose the following change to the 5th paragraph: the argument's "yin-element". If "yin-element" is false, the argument is encoded as an XML attribute to the keyword's element. If "yin-element" is true, the argument is encoded as a subelement to the - keyword's element. The name of the attribute or element is the name - of the argument. + keyword's element. The local name of the attribute or element is the + name of the argument. The attribute has no namespace whereas the + element is in the same namespace as the keyword's element. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Feb 25 06:46: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 397D53A6AC5 for ; Wed, 25 Feb 2009 06:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.237, 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 I2TlOVMBK8Iy for ; Wed, 25 Feb 2009 06:46:17 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 77A0B3A6AB5 for ; Wed, 25 Feb 2009 06:46:17 -0800 (PST) Received: (qmail 83509 invoked from network); 25 Feb 2009 14:46:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 14:46:37 -0000 X-YMail-OSG: izDwQKAVM1k19oFGroZK210jIucqFgIO3Dcna6AD1wQNLjyNTgoreJ1ubrehb3o1Ikt4AJq2I667Q00_8TQMiMqRXW7PjMMpfeHUvDoCKiEtkqBw0GWcK22z4Wp3xptx5JY95jPfMrK4SKEpU.ttSFtT X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A559CC.3030307@netconfcentral.com> Date: Wed, 25 Feb 2009 06:46:36 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1235559661.6385.38.camel@missotis> In-Reply-To: <1235559661.6385.38.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 14:46:18 -0000 Ladislav Lhotka wrote: > Hi, > > Section 11.2 describing YANG-2-YIN algoritm should specify the namespace > for the argument attribute/element - it is important for YIN encoding of > extensions. I propose the following change to the 5th paragraph: > > the argument's "yin-element". If "yin-element" is false, the > argument is encoded as an XML attribute to the keyword's element. If > "yin-element" is true, the argument is encoded as a subelement to the > - keyword's element. The name of the attribute or element is the name > - of the argument. > + keyword's element. The local name of the attribute or element is the > + name of the argument. The attribute has no namespace whereas the > + element is in the same namespace as the keyword's element. > The attribute needs a namespace. No namespace is not the element namespace. It is NULL. There aren't going to be any 'special' rules for YIN, right? It is not some 'special' XML that works almost the same as regular XML, except for 3 or 4 things? We already have an XPath like that. What happens if there are multiple XML attributes within an element in a YIN document? Is this allowed? If so, then the mapping is not symmetrical because XML attributes are unordered within an element. XML parsers do no preserve the relative order of attributes. There are some YANG statements where the relative order of the statements is important. How does YIN preserve statement order in this case? IMO YIN is under-specified. Is it possible to convert from YANG to YIN and back to YANG perfectly? Even comments? If not, why not? Explain in all cases what exact information can be lost. Explain how every single element and attribute in a YIN document maps to exactly 1 construct in the YANG ABNF, since all the normative text is in terms of the YANG clauses. It is not clear how any particular node in a YIN document maps to a precise subset of the YANG ABNF. Doesn't the draft need a detailed YIN-2-YANG algorithm as well as YANG-2-YIN? There are no examples of YIN in the entire draft. Is this going to change? > Lada > Andy From mbj@tail-f.com Wed Feb 25 07:07: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 D7E2E3A6AEC for ; Wed, 25 Feb 2009 07:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.190, 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 yBReSV9mWvwc for ; Wed, 25 Feb 2009 07:07:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CE7353A691F for ; Wed, 25 Feb 2009 07:07:30 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D8CE76C225; Wed, 25 Feb 2009 16:07:49 +0100 (CET) Date: Wed, 25 Feb 2009 16:07:48 +0100 (CET) Message-Id: <20090225.160748.200259580.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A559CC.3030307@netconfcentral.com> References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 15:07:31 -0000 Hi, Andy Bierman wrote: > There aren't going to be any 'special' rules for YIN, right? No. > What happens if there are multiple XML attributes within > an element in a YIN document? Is this allowed? No; this needs to be specified. > If so, then the mapping is not symmetrical because > XML attributes are unordered within an element. > XML parsers do no preserve the relative order of > attributes. There are some YANG statements > where the relative order of the statements is important. > How does YIN preserve statement order in this case? I think this is not a problem since there is just one attribute, right? > IMO YIN is under-specified. So now is a good time to fix that! > Is it possible to convert from YANG to YIN and back to YANG > perfectly? Yes, with the exception of whitespace and comments. > Even comments? If not, why not? We currently say: Comments in YANG MAY be transformed into XML comments. and: XML comments in YIN MAY be transformed into YANG comments. Comments should not be used to carry semantic information. Most comments *can* easily be translated; except for constructs like: description "foo" + /* one */ "bar" + /* two *' "baz"; > Explain in all cases what exact information can be lost. I will add text that explains that whitespace and comments can be lost. > Explain how every single element and attribute in a YIN > document maps to exactly 1 construct in the YANG ABNF, > since all the normative text is in terms of the YANG clauses. I think this is covered by the text in 11.3 and the table in 11.2. > It is not clear how any particular node in a YIN document > maps to a precise subset of the YANG ABNF. Doesn't the > draft need a detailed YIN-2-YANG algorithm as well > as YANG-2-YIN? See 11.3 > There are no examples of YIN in the > entire draft. Is this going to change? There is one! See 11.2.1. Do we need more examples? /martin From lhotka@cesnet.cz Wed Feb 25 07:09: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 6B4DA3A68A9 for ; Wed, 25 Feb 2009 07:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[AWL=0.441, 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 p04V04l6TkEi for ; Wed, 25 Feb 2009 07:09:14 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 552773A6866 for ; Wed, 25 Feb 2009 07:09:14 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4E1D0D800CE; Wed, 25 Feb 2009 16:09:34 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49A559CC.3030307@netconfcentral.com> References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 25 Feb 2009 16:09:34 +0100 Message-Id: <1235574574.6385.56.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 15:09:15 -0000 Andy Bierman píše v St 25. 02. 2009 v 06:46 -0800: > Ladislav Lhotka wrote: > > Hi, > > > > Section 11.2 describing YANG-2-YIN algoritm should specify the namespace > > for the argument attribute/element - it is important for YIN encoding of > > extensions. I propose the following change to the 5th paragraph: > > > > the argument's "yin-element". If "yin-element" is false, the > > argument is encoded as an XML attribute to the keyword's element. If > > "yin-element" is true, the argument is encoded as a subelement to the > > - keyword's element. The name of the attribute or element is the name > > - of the argument. > > + keyword's element. The local name of the attribute or element is the > > + name of the argument. The attribute has no namespace whereas the > > + element is in the same namespace as the keyword's element. > > > > The attribute needs a namespace. No namespace > is not the element namespace. It is NULL. Right, but this is the normal handling of attributes in XML under namespaces. Unlike elements, attributes do not get the default namespace within the XML instance and are thus mostly in the null namespace, unless an explicit prefix is used. In YIN, these argument attributes could be also in the keyword's elemnt namespace but I don't see any reason for this - it's just more typing. > > There aren't going to be any 'special' rules for YIN, right? > It is not some 'special' XML that works almost the same > as regular XML, except for 3 or 4 things? We already have an XPath > like that. It is not special at all: Here the rpc element is in the netconf namespace but message-id attribute has no namespace. > > What happens if there are multiple XML attributes within > an element in a YIN document? Is this allowed? How could this happen? Every YANG statement has at most one argument hence the corresponding YIN element may have zero or one attribute. ... > IMO YIN is under-specified. > > Is it possible to convert from YANG to YIN and back to YANG > perfectly? Even comments? If not, why not? I think the conversion is perfect in both directions. Perhaps the specification may be improved in some places but I would call it underspecified. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Feb 25 07:24: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 05B003A68AC for ; Wed, 25 Feb 2009 07:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 Ie58spv2urCS for ; Wed, 25 Feb 2009 07:24:55 -0800 (PST) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id CDB743A67AD for ; Wed, 25 Feb 2009 07:24:54 -0800 (PST) Received: from [68.142.194.243] by n10.bullet.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 15:25:14 -0000 Received: from [68.142.201.249] by t1.bullet.mud.yahoo.com with NNFMP; 25 Feb 2009 15:25:14 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 15:25:14 -0000 X-Yahoo-Newman-Id: 709706.12367.bm@omp410.mail.mud.yahoo.com Received: (qmail 42330 invoked from network); 25 Feb 2009 15:25:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 15:25:04 -0000 X-YMail-OSG: 6NFC77AVM1kcJbCOrLDXKNTxbY_V38uWW47eyxTcVlEQbSNatiGH7kX4ViFHC_Yu6.C1FmfHEuKziLFsL3Sp3rM6_Vvk4T1AHC2K8LjTBCoimdOtWc5_ausb2YOZEXBXhyTAZtmWIWgcv6a_VdTn2Pc0wS1nBwnFMdu40bQdRQ9HQHtmFH9HuV_mqisq X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A562CE.4080309@netconfcentral.com> Date: Wed, 25 Feb 2009 07:25:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <1235574574.6385.56.camel@missotis> In-Reply-To: <1235574574.6385.56.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 15:24:56 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 25. 02. 2009 v 06:46 -0800: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> Section 11.2 describing YANG-2-YIN algoritm should specify the namespace >>> for the argument attribute/element - it is important for YIN encoding of >>> extensions. I propose the following change to the 5th paragraph: >>> >>> the argument's "yin-element". If "yin-element" is false, the >>> argument is encoded as an XML attribute to the keyword's element. If >>> "yin-element" is true, the argument is encoded as a subelement to the >>> - keyword's element. The name of the attribute or element is the name >>> - of the argument. >>> + keyword's element. The local name of the attribute or element is the >>> + name of the argument. The attribute has no namespace whereas the >>> + element is in the same namespace as the keyword's element. >>> >> The attribute needs a namespace. No namespace >> is not the element namespace. It is NULL. > > Right, but this is the normal handling of attributes in XML under > namespaces. Unlike elements, attributes do not get the default namespace > within the XML instance and are thus mostly in the null namespace, > unless an explicit prefix is used. In YIN, these argument attributes > could be also in the keyword's elemnt namespace but I don't see any > reason for this - it's just more typing. > We agree on how XML works. I think the attribute namespace always has to be specified. It MUST be the YIN namespace or an extension namespace. Machines are generating YIN and processing it. That is the reason it exists, according to the draft. 'YIN readability' is not a design goal. >> There aren't going to be any 'special' rules for YIN, right? >> It is not some 'special' XML that works almost the same >> as regular XML, except for 3 or 4 things? We already have an XPath >> like that. > > It is not special at all: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:ex="http://example.net/content/1.0" > ex:user-id="fred"> > > > Interesting example. I actually send Here the rpc element is in the netconf namespace but message-id > attribute has no namespace. > >> What happens if there are multiple XML attributes within >> an element in a YIN document? Is this allowed? > > How could this happen? Every YANG statement has at most one argument > hence the corresponding YIN element may have zero or one attribute. > > ... > >> IMO YIN is under-specified. >> >> Is it possible to convert from YANG to YIN and back to YANG >> perfectly? Even comments? If not, why not? > > I think the conversion is perfect in both directions. Perhaps the > specification may be improved in some places but I would call it > underspecified. > > Lada > Andy From andy@netconfcentral.com Wed Feb 25 07:50:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE643A6A87 for ; Wed, 25 Feb 2009 07:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=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 p57hhbb8BLJq for ; Wed, 25 Feb 2009 07:50:16 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id CBA003A6A7A for ; Wed, 25 Feb 2009 07:50:16 -0800 (PST) Received: (qmail 29025 invoked from network); 25 Feb 2009 15:50:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 15:50:34 -0000 X-YMail-OSG: _n32na4VM1kkH4DaRpcYzGiX09U4sc6I2Gr3.1VvUqxibbVP2t1Cv81Nwg5ypyaxc7MODe2TLg9MARqObRa.Gsme4Qsj8JegBQfXfwWe01zTNwYMEZSANTh2JTQ7IT2KOR1PdO49ndW04Z4xpOcNGATV6BV0yr9o0UNG86p1MA3QBqrleB57bGOZGIt.jnjr85FyCSJ6uRRtyuz2RK_yQA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A568C8.40005@netconfcentral.com> Date: Wed, 25 Feb 2009 07:50:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> In-Reply-To: <20090225.160748.200259580.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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 15:50:20 -0000 Martin Bjorklund wrote: > Hi, > > > Andy Bierman wrote: >> There aren't going to be any 'special' rules for YIN, right? > > No. > >> What happens if there are multiple XML attributes within >> an element in a YIN document? Is this allowed? > > No; this needs to be specified. > >> If so, then the mapping is not symmetrical because >> XML attributes are unordered within an element. >> XML parsers do no preserve the relative order of >> attributes. There are some YANG statements >> where the relative order of the statements is important. >> How does YIN preserve statement order in this case? > > I think this is not a problem since there is just one attribute, > right? > I am still unclear on the text about the YIN XML namespace prefix exactly matching the YANG module prefix. YANG module prefixes are not unique. That's why the prefix can be specified in the import-stmt (to give the data modeler the joy of resolving all the prefix collisions manually ;-) So how does YIN deal with this problem? IMO this prefix mapping is all broken. It needs to work the same way our XPath code has to work. XML prefix --> namespace URI --> module namespace-stmt value Leave module prefixes out of it. >> IMO YIN is under-specified. > > So now is a good time to fix that! > Great! :-( What about the XPath prefix issues? How are all the prefixes within must/when path expressions represented? What happens when they are missing? Is this behavior different for elements vs. attributes? Why does YIN need to use attributes at all? Why can't YANG and YIN be simplified by always using elements in YIN? (This should be in the draft.) The draft also says that YIN can be schema-validated. Theoretically, yes, but who is going to write the XSD or DSDL for YIN, or better yet, the yin.yang module? >> Is it possible to convert from YANG to YIN and back to YANG >> perfectly? > > Yes, with the exception of whitespace and comments. > >> Even comments? If not, why not? > > We currently say: > > Comments in YANG MAY be transformed into XML comments. > > and: > > XML comments in YIN MAY be transformed into YANG comments. > > Comments should not be used to carry semantic information. > > Most comments *can* easily be translated; except for constructs like: > > description "foo" + /* one */ "bar" + /* two *' "baz"; > > >> Explain in all cases what exact information can be lost. > > I will add text that explains that whitespace and comments can be > lost. > >> Explain how every single element and attribute in a YIN >> document maps to exactly 1 construct in the YANG ABNF, >> since all the normative text is in terms of the YANG clauses. > > I think this is covered by the text in 11.3 and the table in 11.2. > >> It is not clear how any particular node in a YIN document >> maps to a precise subset of the YANG ABNF. Doesn't the >> draft need a detailed YIN-2-YANG algorithm as well >> as YANG-2-YIN? > > See 11.3 > >> There are no examples of YIN in the >> entire draft. Is this going to change? > > There is one! See 11.2.1. Do we need more examples? > you always need more examples! But only correct ones. Bugs in examples are worse than no examples. > > /martin > > Andy From lhotka@cesnet.cz Wed Feb 25 07: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 2B8343A6A13 for ; Wed, 25 Feb 2009 07:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=0.407, 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 NG2f6oMyOfjr for ; Wed, 25 Feb 2009 07:59:33 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4EBA03A6805 for ; Wed, 25 Feb 2009 07:59:33 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E34F3D800F0 for ; Wed, 25 Feb 2009 16:59:52 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <49A562CE.4080309@netconfcentral.com> References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <1235574574.6385.56.camel@missotis> <49A562CE.4080309@netconfcentral.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Wed, 25 Feb 2009 16:59:53 +0100 Message-Id: <1235577593.6385.82.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 15:59:34 -0000 Andy Bierman píše v St 25. 02. 2009 v 07:25 -0800: > > We agree on how XML works. > I think the attribute namespace always has > to be specified. It MUST be the YIN namespace > or an extension namespace. Why? There cannot be any confusion since the attributes are enclosed in and actually belong to an element that has a non-null namespace. I'd guess some 90 % XML attributes are handled this way. Namespace is really needed only for global attributes that are attached randomly to elements from foreign namespaces. BTW, the YIN translator in pyang does it exactly as it is said in the text I proposed. > > Machines are generating YIN and processing it. > That is the reason it exists, according to > the draft. 'YIN readability' is not a design goal. Well, I for one write YIN by hand - the fantastic nxml mode in emacs knows all the YIN keywords and autocompletes them so it's actually less typing than writing YANG. > > > >> There aren't going to be any 'special' rules for YIN, right? > >> It is not some 'special' XML that works almost the same > >> as regular XML, except for 3 or 4 things? We already have an XPath > >> like that. > > > > It is not special at all: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:ex="http://example.net/content/1.0" > > ex:user-id="fred"> > > > > > > > > Interesting example. > I actually send because the XSD says the attribute is defined > in a target namespace. But the agent accepts 'nc' or none > in every case because the RFC says to do it wrong. > I'm sure 4741-bis will fix it though. Then I think the XML Schema is broken and should be fixed. > > > > I think the conversion is perfect in both directions. Perhaps the > > specification may be improved in some places but I would call it > > underspecified. Oh, I wanted to say "... I would NOT call it underspecified." Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Feb 25 08:03:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F28E3A6AB3 for ; Wed, 25 Feb 2009 08:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 R3WgyTvpf0zi for ; Wed, 25 Feb 2009 08:03:19 -0800 (PST) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id 9FBB73A6AA2 for ; Wed, 25 Feb 2009 08:03:19 -0800 (PST) Received: from [209.191.108.97] by n25.bullet.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 16:03:39 -0000 Received: from [68.142.201.245] by t4.bullet.mud.yahoo.com with NNFMP; 25 Feb 2009 16:03:39 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 16:03:39 -0000 X-Yahoo-Newman-Id: 945290.72698.bm@omp406.mail.mud.yahoo.com Received: (qmail 86765 invoked from network); 25 Feb 2009 16:03:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 16:03:38 -0000 X-YMail-OSG: I.v5xwIVM1l3j4gAUzxRLMWdrCdZot_s78z237QzH2cSk.JKYBj3KWstx2ujnMJVMdVZlqjWxkL1uOJYSyOb0udSfiFZK40g4rLTOqzl0Z1xhVFcC3fSv0tjH9eCVnWy3q9BeGmOXBW4p.hESR2DTiQO X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A56BD9.3060309@netconfcentral.com> Date: Wed, 25 Feb 2009 08:03:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> In-Reply-To: <20090225.160748.200259580.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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 16:03:20 -0000 Martin Bjorklund wrote: .... > Comments should not be used to carry semantic information. > > Most comments *can* easily be translated; except for constructs like: > > description "foo" + /* one */ "bar" + /* two *' "baz"; > > >> Explain in all cases what exact information can be lost. > > I will add text that explains that whitespace and comments can be > lost. > What about YANG strings? There are very specific semantics for double-quote strings vs. single-quote strings. How are these semantics preserved in YIN <--> YANG round-trip translation? Especially all the formatting and whitespace rules for double-quotes. How is string concatenation preserved? must "/foo" + "/bar" + '[name = "fred"]' + "< 4"; What is the YIN translation of this must-stmt (in element and attribute form if different)? > /martin > > Andy From andy@netconfcentral.com Wed Feb 25 08:15: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 D84E228C148 for ; Wed, 25 Feb 2009 08:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 SxMKu70xFNEW for ; Wed, 25 Feb 2009 08:15:03 -0800 (PST) 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 067A03A6AB5 for ; Wed, 25 Feb 2009 08:14:58 -0800 (PST) Received: from [209.191.108.96] by n11.bullet.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 16:15:19 -0000 Received: from [68.142.201.251] by t3.bullet.mud.yahoo.com with NNFMP; 25 Feb 2009 16:15:19 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 16:15:19 -0000 X-Yahoo-Newman-Id: 435764.33875.bm@omp412.mail.mud.yahoo.com Received: (qmail 81159 invoked from network); 25 Feb 2009 16:15:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 16:15:18 -0000 X-YMail-OSG: SXAaCqoVM1nyruQeoiZFpz.tb6PQMBNwd0AugzUxYP.AmVXK9FIxUjt2QAhjjbHPbFS0GPfu822fEMNsHlVYQc1TGsYzUWGKC.qYoy0NcRSlOyhQyX4jhS93TBxk.fos669Hi4c66ZfXl6efWd9MNTISp_jEKMgJ3oeb_Q24.4zcvGLOXOvJOwsaYcZm X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A56E94.7040401@netconfcentral.com> Date: Wed, 25 Feb 2009 08:15:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <1235574574.6385.56.camel@missotis> <49A562CE.4080309@netconfcentral.com> <1235577593.6385.82.camel@missotis> In-Reply-To: <1235577593.6385.82.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 16:15:06 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 25. 02. 2009 v 07:25 -0800: >> We agree on how XML works. >> I think the attribute namespace always has >> to be specified. It MUST be the YIN namespace >> or an extension namespace. > > Why? There cannot be any confusion since the attributes are enclosed in > and actually belong to an element that has a non-null namespace. I'd > guess some 90 % XML attributes are handled this way. Namespace is really > needed only for global attributes that are attached randomly to elements > from foreign namespaces. > > BTW, the YIN translator in pyang does it exactly as it is said in the > text I proposed. > OK. Just make it clear in the draft. I do not mind having the draft match the free tool for this feature. Nobody else is going to write one. >> Machines are generating YIN and processing it. >> That is the reason it exists, according to >> the draft. 'YIN readability' is not a design goal. > > Well, I for one write YIN by hand - the fantastic nxml mode in emacs > knows all the YIN keywords and autocompletes them so it's actually less > typing than writing YANG. > IMO, debating implementation and tool choices can never really be productive. In this case, we might even end up in the "emacs vs. vi" tar-pit. :-) >> >>>> There aren't going to be any 'special' rules for YIN, right? >>>> It is not some 'special' XML that works almost the same >>>> as regular XML, except for 3 or 4 things? We already have an XPath >>>> like that. >>> It is not special at all: >>> >>> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >>> xmlns:ex="http://example.net/content/1.0" >>> ex:user-id="fred"> >>> >>> >>> >> Interesting example. >> I actually send > because the XSD says the attribute is defined >> in a target namespace. But the agent accepts 'nc' or none >> in every case because the RFC says to do it wrong. >> I'm sure 4741-bis will fix it though. > > Then I think the XML Schema is broken and should be fixed. > >>> I think the conversion is perfect in both directions. Perhaps the >>> specification may be improved in some places but I would call it >>> underspecified. > > Oh, I wanted to say "... I would NOT call it underspecified." > I think after a little more work it will be fine. > Lada > Andy From lhotka@cesnet.cz Wed Feb 25 08:34: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 863583A6B6F for ; Wed, 25 Feb 2009 08:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPK1Tg5VAKHS for ; Wed, 25 Feb 2009 08:34:26 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B20423A6B62 for ; Wed, 25 Feb 2009 08:34:26 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AF4BBD800EF for ; Wed, 25 Feb 2009 17:34:46 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <49A56BD9.3060309@netconfcentral.com> References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A56BD9.3060309@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 25 Feb 2009 17:34:47 +0100 Message-Id: <1235579687.6385.93.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 16:34:27 -0000 Andy Bierman píše v St 25. 02. 2009 v 08:03 -0800: > What about YANG strings? > There are very specific semantics for double-quote strings > vs. single-quote strings. How are these semantics preserved > in YIN <--> YANG round-trip translation? Especially all > the formatting and whitespace rules for double-quotes. IMO, the value-space value of the YANG string must be taken and put as the argument attribute value or element text, substituting entities like < where necessary. > > How is string concatenation preserved? > > must "/foo" + "/bar" + '[name = "fred"]' + "< 4"; > > What is the YIN translation of this must-stmt > (in element and attribute form if different)? The draft says the argument of must goes to the "condition" attribute, so it cannot be an element. The result will be . Lada > > > /martin > > > > > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Feb 25 08:56: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 D179E28C14A for ; Wed, 25 Feb 2009 08:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=0.353, 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 4Wh0J7UteUyt for ; Wed, 25 Feb 2009 08:56:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0393E3A68E4 for ; Wed, 25 Feb 2009 08:56:02 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5174DD800EF; Wed, 25 Feb 2009 17:56:22 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090225.160748.200259580.mbj@tail-f.com> References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 25 Feb 2009 17:56:23 +0100 Message-Id: <1235580983.6385.100.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 16:56:02 -0000 Martin Bjorklund píše v St 25. 02. 2009 v 16:07 +0100: > > > It is not clear how any particular node in a YIN document > > maps to a precise subset of the YANG ABNF. Doesn't the > > draft need a detailed YIN-2-YANG algorithm as well > > as YANG-2-YIN? > > See 11.3 Actually, I wrote the RELAX NG schema for YIN pretty much by directly translating the ABNF grammar: http://www.yang-central.org/twiki/pub/Main/YangTools/yin.html Perhaps this schema should also appear in an appendix of the draft - I'd have to update it to the current syntax though. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Feb 25 08: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 122C028C16F for ; Wed, 25 Feb 2009 08:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 o1rA7VjiPK0f for ; Wed, 25 Feb 2009 08:56:47 -0800 (PST) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id B662228C187 for ; Wed, 25 Feb 2009 08:56:35 -0800 (PST) Received: from [68.142.194.243] by n13.bullet.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 16:56:55 -0000 Received: from [68.142.201.73] by t1.bullet.mud.yahoo.com with NNFMP; 25 Feb 2009 16:56:55 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 25 Feb 2009 16:56:55 -0000 X-Yahoo-Newman-Id: 678239.91214.bm@omp425.mail.mud.yahoo.com Received: (qmail 42052 invoked from network); 25 Feb 2009 16:56:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 16:56:54 -0000 X-YMail-OSG: pXXvtowVM1nHtXLyHwV.M_.pzbC1zSO94U81w_OxLRz_dAPIKY4b1_cJC5zWMMO4LfLjfmgtP86zrHTnfixCo_oWgI5AH881B3Lxetlf2HoCICkMQw.6sSgFaE9uGryea.RftFIVV4tzWDxqoC3y60gD X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A57854.4090600@netconfcentral.com> Date: Wed, 25 Feb 2009 08:56:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A56BD9.3060309@netconfcentral.com> <1235579687.6385.93.camel@missotis> In-Reply-To: <1235579687.6385.93.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 16:56:52 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 25. 02. 2009 v 08:03 -0800: >> What about YANG strings? >> There are very specific semantics for double-quote strings >> vs. single-quote strings. How are these semantics preserved >> in YIN <--> YANG round-trip translation? Especially all >> the formatting and whitespace rules for double-quotes. > > IMO, the value-space value of the YANG string must be taken and put as > the argument attribute value or element text, substituting entities like > < where necessary. > >> How is string concatenation preserved? >> >> must "/foo" + "/bar" + '[name = "fred"]' + "< 4"; >> >> What is the YIN translation of this must-stmt >> (in element and attribute form if different)? > > The draft says the argument of must goes to the "condition" attribute, > so it cannot be an element. The result will be > > . > So the draft needs to say that all YANG string features are lost in translation and any YANG module which uses them may not translate correctly (e.g., \n left in the string vs. converted to an actual newline). String concatenation is not translated at all. There are some corner-cases that I have found (e.g., patterns) where the YANG double-quotes break the pattern and single-quoted strings must be used instead. In your example, some dbl-quoted strings were grouped together into a single-quoted string. I think this can change the semantics of some YANG strings. > Lada > > >>> /martin >>> >>> >> Andy >> >> Andy From lhotka@cesnet.cz Wed Feb 25 09:14: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 266A428C252 for ; Wed, 25 Feb 2009 09:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=0.331, 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 05NhhulXrw14 for ; Wed, 25 Feb 2009 09:14:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4F48C28C19C for ; Wed, 25 Feb 2009 09:14:03 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 20B98D800D1; Wed, 25 Feb 2009 18:14:21 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49A57854.4090600@netconfcentral.com> References: <1235559661.6385.38.camel@missotis> <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A56BD9.3060309@netconfcentral.com> <1235579687.6385.93.camel@missotis> <49A57854.4090600@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 25 Feb 2009 18:14:22 +0100 Message-Id: <1235582062.6385.112.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 17:14:04 -0000 Andy Bierman píše v St 25. 02. 2009 v 08:56 -0800: > > There are some corner-cases that I have found (e.g., patterns) > where the YANG double-quotes break the pattern and > single-quoted strings must be used instead. > In your example, some dbl-quoted strings were > grouped together into a single-quoted string. > I think this can change the semantics of some YANG strings. > It shouldn't. These single/double quotes and concatenation are just features of the lexical representation of strings in YANG, but the value space value of the argument string is always well-defined and unique and must not change during the conversion. Of course, going from YANG to YIN and back to YANG may not yield exactly the same module text that we start with, but they should be equivalent. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Feb 25 09:30: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 EC30628C15D for ; Wed, 25 Feb 2009 09:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.126, 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 OcFJ9yVYWdi1 for ; Wed, 25 Feb 2009 09:30:36 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2EDF23A6ABA for ; Wed, 25 Feb 2009 09:30:36 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A8A5E76C225; Wed, 25 Feb 2009 18:30:55 +0100 (CET) Date: Wed, 25 Feb 2009 18:30:55 +0100 (CET) Message-Id: <20090225.183055.78292291.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A562CE.4080309@netconfcentral.com> References: <49A559CC.3030307@netconfcentral.com> <1235574574.6385.56.camel@missotis> <49A562CE.4080309@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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 17:30:37 -0000 Andy Bierman wrote: > > It is not special at all: > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:ex="http://example.net/content/1.0" > > ex:user-id="fred"> > > > > > > > > Interesting example. > I actually send because the XSD says the attribute is defined > in a target namespace. But the agent accepts 'nc' or none > in every case because the RFC says to do it wrong. > I'm sure 4741-bis will fix it though. No this is not correct. The XSD has attributeFormDefault="unqualified" which means that locally declared atttributes MUST NOT be qualified with the namespace. So: is not valid according to the schema. /martin From mbj@tail-f.com Wed Feb 25 09:50: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 762BB3A68E4 for ; Wed, 25 Feb 2009 09:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.119, 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 WBoD37Qol41z for ; Wed, 25 Feb 2009 09:50:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 93BB43A684A for ; Wed, 25 Feb 2009 09:50:53 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 99E4976C225; Wed, 25 Feb 2009 18:51:13 +0100 (CET) Date: Wed, 25 Feb 2009 18:51:13 +0100 (CET) Message-Id: <20090225.185113.75438571.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A568C8.40005@netconfcentral.com> References: <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A568C8.40005@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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 17:50:54 -0000 Andy Bierman wrote: > I am still unclear on the text about the YIN XML namespace prefix > exactly matching the YANG module prefix. YANG module prefixes > are not unique. That's why the prefix can be specified in > the import-stmt (to give the data modeler the joy of > resolving all the prefix collisions manually ;-) > > So how does YIN deal with this problem? I don't understand the problem. All prefixes in a YANG module are unique. Each prefix maps to a module, which defines a namespace. Maybe you can provide an example which has this problem? > What about the XPath prefix issues? > How are all the prefixes within must/when path expressions > represented? What happens when they are missing? > Is this behavior different for elements vs. attributes? Note that YIN is just a different syntax. The mapping does not modify any string *values* (just on the syntax level, e.g. '>' must be quoted in XML). So if you believe we have any prefix issues in the interpretation of XPath in YIN, then we have them in YANG as well. > Why does YIN need to use attributes at all? > Why can't YANG and YIN be simplified by always using > elements in YIN? There are of course many ways an XML syntax of YANG could be specified. We chose one which we believe is correct (i.e. 1-1 mappable), readable, writable, and simple to implement. The reason some elements have attributes is for readability and writability. /martin From andy@netconfcentral.com Wed Feb 25 10:03:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB053A68CB for ; Wed, 25 Feb 2009 10:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.130, 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 4renexsGzYrB for ; Wed, 25 Feb 2009 10:03:05 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 03DF73A687A for ; Wed, 25 Feb 2009 10:03:05 -0800 (PST) Received: (qmail 11543 invoked from network); 25 Feb 2009 18:03:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 18:03:25 -0000 X-YMail-OSG: I19EdL4VM1kMVcgKV9dsg5ZNQtL8BtqCJEFJxgxSbeV5RDukzAdJjXtf89oOe2nt8QL2SETK15_3AQx5HT6Z.UKNrgEPUc6oLvVFpMFg0oB0FEcaz8LYcCPip3cN5N1lml_hwuksp0zA2JVwEv1kkdRsfkg9hO3n2VQmJzibqcjdy.zWXJMxqnuT634. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A587EB.7020108@netconfcentral.com> Date: Wed, 25 Feb 2009 10:03:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A559CC.3030307@netconfcentral.com> <1235574574.6385.56.camel@missotis> <49A562CE.4080309@netconfcentral.com> <20090225.183055.78292291.mbj@tail-f.com> In-Reply-To: <20090225.183055.78292291.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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 18:03:05 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>> It is not special at all: >>> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >>> xmlns:ex="http://example.net/content/1.0" >>> ex:user-id="fred"> >>> >>> >>> >> Interesting example. >> I actually send > because the XSD says the attribute is defined >> in a target namespace. But the agent accepts 'nc' or none >> in every case because the RFC says to do it wrong. >> I'm sure 4741-bis will fix it though. > > No this is not correct. The XSD has > > attributeFormDefault="unqualified" > > which means that locally declared atttributes MUST NOT be qualified > with the namespace. So: > > > > is not valid according to the schema. > > But we always show a prefix on the 'operation' attribute in examples. (pg 15, 38, 39) If a prefix is not allowed on 'message-id' than it is not allowed on 'operation' either. Neither attribute declaration has the 'form' option, so the attributeFormDefault of 'unqualified' is used. IMO, the attributeFormDefault=unqualified is a bug. The WG intended that the operation attribute is in the netconf namespace and all the attributes in the element are mirrored back exactly, regardless of form. In fact, the mandatory 'message-id' is considered a bug. It should not exist at all, and the error for a missing message-id should be removed. It is not used anywhere for anything. Just a Big CLR. We had limited XSD expertise at the time (as demonstrated by some other bugs found so far). BTW, the YANG attributes MUST have a prefix and be in the YANG namespace. IMO this is all a bit confusing. > /martin > > Andy From mbj@tail-f.com Wed Feb 25 10:29: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 7A26B3A68DA for ; Wed, 25 Feb 2009 10:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.114, 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 bfYdCsvwUksv for ; Wed, 25 Feb 2009 10:29:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A060B3A68C6 for ; Wed, 25 Feb 2009 10:29:21 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 53F4176C225; Wed, 25 Feb 2009 19:29:41 +0100 (CET) Date: Wed, 25 Feb 2009 19:29:40 +0100 (CET) Message-Id: <20090225.192940.158063359.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A587EB.7020108@netconfcentral.com> References: <49A562CE.4080309@netconfcentral.com> <20090225.183055.78292291.mbj@tail-f.com> <49A587EB.7020108@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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 18:29:22 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>> It is not special at all: > >>> >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > >>> xmlns:ex="http://example.net/content/1.0" > >>> ex:user-id="fred"> > >>> > >>> > >>> > >> Interesting example. > >> I actually send >> because the XSD says the attribute is defined > >> in a target namespace. But the agent accepts 'nc' or none > >> in every case because the RFC says to do it wrong. > >> I'm sure 4741-bis will fix it though. > > No this is not correct. The XSD has attributeFormDefault="unqualified" > > which means that locally declared atttributes MUST NOT be qualified > > with the namespace. So: > > > > is not valid according to the schema. > > > > But we always show a prefix on the 'operation' attribute > in examples. (pg 15, 38, 39) The 'operation' attribute is globally declared. Globally declared attributes always need the namespace. > The WG intended that the operation attribute is in > the netconf namespace and all the attributes in the > element are mirrored back exactly, regardless of form. Sure. > In fact, the mandatory 'message-id' is considered a bug. > It should not exist at all, and the error for a missing > message-id should be removed. It is not used anywhere > for anything. Just a Big CLR. I agree. /martin From andy@netconfcentral.com Wed Feb 25 11:08: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 3C31E28C199 for ; Wed, 25 Feb 2009 11:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiDmQ7qJlFJN for ; Wed, 25 Feb 2009 11:08:09 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id A30FB3A6B8A for ; Wed, 25 Feb 2009 11:07:54 -0800 (PST) Received: (qmail 88576 invoked from network); 25 Feb 2009 19:08:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 25 Feb 2009 19:08:14 -0000 X-YMail-OSG: QyzLUxkVM1k3M4AVr4vmCJqOwqrzCTP.u6VIz8TBTyvRLpsg349gVwRK6aAKsNIa2oqPJAblpHJ_Rcela2BAT5MAYwbkpTD7atcv4St4KIREJnz_fCeQpxLXGVubT_QGtS7KVfOv3fPc1fVsyEhWTcBL4nDNzvp8gxUprpOYYA32w4LwoYz1OzmcHV5n X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A5971D.7010708@netconfcentral.com> Date: Wed, 25 Feb 2009 11:08:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A562CE.4080309@netconfcentral.com> <20090225.183055.78292291.mbj@tail-f.com> <49A587EB.7020108@netconfcentral.com> <20090225.192940.158063359.mbj@tail-f.com> In-Reply-To: <20090225.192940.158063359.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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Feb 2009 19:08:11 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>>> It is not special at all: >>>>> >>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >>>>> xmlns:ex="http://example.net/content/1.0" >>>>> ex:user-id="fred"> >>>>> >>>>> >>>>> >>>> Interesting example. >>>> I actually send >>> because the XSD says the attribute is defined >>>> in a target namespace. But the agent accepts 'nc' or none >>>> in every case because the RFC says to do it wrong. >>>> I'm sure 4741-bis will fix it though. >>> No this is not correct. The XSD has attributeFormDefault="unqualified" >>> which means that locally declared atttributes MUST NOT be qualified >>> with the namespace. So: >>> >>> is not valid according to the schema. >>> >> But we always show a prefix on the 'operation' attribute >> in examples. (pg 15, 38, 39) > > The 'operation' attribute is globally declared. Globally declared > attributes always need the namespace. > OK. Got it. The definition for 'operation' is a global definition so it must always be qualified. The definitions for 'message-id', 'type', and 'select' are inside elements and so the attributeFormDefault is applied to them. Therefore they must never have a prefix. >> The WG intended that the operation attribute is in >> the netconf namespace and all the attributes in the >> element are mirrored back exactly, regardless of form. > > Sure. > >> In fact, the mandatory 'message-id' is considered a bug. >> It should not exist at all, and the error for a missing >> message-id should be removed. It is not used anywhere >> for anything. Just a Big CLR. > > I agree. > Is anybody enforcing this error or not? Phil already explained to everybody why the message-id is already covered by the 'mirror-all-attributes' rule. > > /martin > > Andy From Washam.Fan@huaweisymantec.com Wed Feb 25 22:46: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 06AFB3A6AF1 for ; Wed, 25 Feb 2009 22:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 ntf7lT-FEezO for ; Wed, 25 Feb 2009 22:46:40 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 1F6A93A67DA for ; Wed, 25 Feb 2009 22:46:40 -0800 (PST) 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-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KFN00CJ0UU8QC50@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 26 Feb 2009 14:46:58 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KFN003FWUU69300@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 26 Feb 2009 14:46:56 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 26 Feb 2009 14:46:54 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 26 Feb 2009 14:46:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49A51DF8.7030000@netconfcentral.com> References: <49A51DF8.7030000@netconfcentral.com> Cc: NETMOD Working Group Subject: Re: [netmod] instance-identifier ABNF broken X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 06:46:41 -0000 > Hi, > > The instance-identifier syntax does not allow for > positional entries (/foo[3]). This is needed for > lists without any keys. The only way to specify > such a node is by its relative position. How come lists without any keys? Look at para2, sec 7.8: "A list entry is uniquely identified by the values of the list's keys." Am I missing something? washam From mbj@tail-f.com Thu Feb 26 00:00: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 7C6C628C2C6 for ; Thu, 26 Feb 2009 00:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.174, 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 qiWpPqhRAIvp for ; Thu, 26 Feb 2009 00:00:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AE07C28C2AB for ; Thu, 26 Feb 2009 00:00:30 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 81E0C76C4D7; Thu, 26 Feb 2009 09:00:50 +0100 (CET) Date: Thu, 26 Feb 2009 09:00:50 +0100 (CET) Message-Id: <20090226.090050.66057020.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <49A51DF8.7030000@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] instance-identifier ABNF broken X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 08:00:31 -0000 WashamFan wrote: > > Hi, > > > > The instance-identifier syntax does not allow for > > positional entries (/foo[3]). This is needed for > > lists without any keys. The only way to specify > > such a node is by its relative position. > > > How come lists without any keys? > Look at para2, sec 7.8: > > "A list entry is uniquely identified by the values of > the list's keys." > > Am I missing something? YANG allows you to define lists without keys, see 7.8 The "key" statement, which MUST be present if the list represents configuration, and MAY be present otherwise, But I'm not sure if the modification Andy proposed should be added, esp. not in the light of the ordering / positional mail thread. Maybe it is ok to limit this type to instances that *can* be identified by name? (All config instances can be identified by name). /martin From andy@netconfcentral.com Thu Feb 26 02: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 EBB073A696D for ; Thu, 26 Feb 2009 02:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 sZTIZvsXgjr1 for ; Thu, 26 Feb 2009 02:49:36 -0800 (PST) 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 1DEEF3A67C1 for ; Thu, 26 Feb 2009 02:49:36 -0800 (PST) Received: (qmail 37731 invoked from network); 26 Feb 2009 10:49:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.195 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Feb 2009 10:49:56 -0000 X-YMail-OSG: 0mqAkcgVM1m3liXLcYeRMS3D.6IkYx7EbyUGm0aNj7NQyN9fzuCoMZwWQgAi6VOuOy8T1J0zfhs_d6RD2cxdldvp2W.QU308C7RgqV.38_GEorh.kzUKgyYhOGN0t6cKXnm3OELCMGSe8uvT0gxT.SG8sU2Z5.3.nEGGl4Cmoyg_q0TdvQxk2hqymcvWTNVIhGdq8A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A673D2.4050504@netconfcentral.com> Date: Thu, 26 Feb 2009 02:49:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A51DF8.7030000@netconfcentral.com> <20090226.090050.66057020.mbj@tail-f.com> In-Reply-To: <20090226.090050.66057020.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] instance-identifier ABNF broken X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 10:49:37 -0000 Martin Bjorklund wrote: > WashamFan wrote: >>> Hi, >>> >>> The instance-identifier syntax does not allow for >>> positional entries (/foo[3]). This is needed for >>> lists without any keys. The only way to specify >>> such a node is by its relative position. >> >> How come lists without any keys? >> Look at para2, sec 7.8: >> >> "A list entry is uniquely identified by the values of >> the list's keys." >> >> Am I missing something? > > YANG allows you to define lists without keys, see 7.8 > > The "key" statement, which MUST be present if the list represents > configuration, and MAY be present otherwise, > > But I'm not sure if the modification Andy proposed should be added, > esp. not in the light of the ordering / positional mail thread. Maybe > it is ok to limit this type to instances that *can* be identified by > name? (All config instances can be identified by name). > Every single node in a NETCONF PDU or a NETCONF database needs to be identified for select, error-path, and must/when expressions. The only way to tell 2 list entries apart (if they do not have keys) is by their relative position. There is no danger in the agent generating relative expressions for error-path (for example). The netconf-state DM has a read-only list without a key. E.g., /netconf/configurations/configuration[1]/name is the only way to specify the 'name' field in an instance-identifier. > > /martin > > Andy From mbj@tail-f.com Thu Feb 26 03:40: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 C50413A69BC for ; Thu, 26 Feb 2009 03:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.161, 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 j5pSv6TsXJ6V for ; Thu, 26 Feb 2009 03:40:04 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DE2E03A65A5 for ; Thu, 26 Feb 2009 03:40:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E77EA76C341; Thu, 26 Feb 2009 12:40:23 +0100 (CET) Date: Thu, 26 Feb 2009 12:40:23 +0100 (CET) Message-Id: <20090226.124023.139048977.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A673D2.4050504@netconfcentral.com> References: <20090226.090050.66057020.mbj@tail-f.com> <49A673D2.4050504@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] instance-identifier ABNF broken X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 11:40:04 -0000 Andy Bierman wrote: > Every single node in a NETCONF PDU or a NETCONF database > needs to be identified for select, error-path, and must/when > expressions. The only way to tell 2 list entries apart > (if they do not have keys) is by their relative position. > > There is no danger in the agent generating relative expressions > for error-path (for example). The netconf-state DM has a > read-only list without a key. > E.g., /netconf/configurations/configuration[1]/name is > the only way to specify the 'name' field in an instance-identifier. You're right. I think think this will work: instance-identifier = 1*("/" (node-identifier *predicate)) predicate = "[" *WSP (predicate-expr / pos) *WSP "]" predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) pos = non-negative-decimal-value) /martin From balazs.lengyel@ericsson.com Thu Feb 26 08:34: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 206A33A6BD9 for ; Thu, 26 Feb 2009 08:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.291, 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 j0tDzD24tAwZ for ; Thu, 26 Feb 2009 08:34:24 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 549293A6BD3 for ; Thu, 26 Feb 2009 08:34:24 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1B03E212D8 for ; Thu, 26 Feb 2009 17:34:40 +0100 (CET) X-AuditID: c1b4fb3e-ac0bbbb000001315-7f-49a6c4818a1e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D216921135 for ; Thu, 26 Feb 2009 17:34:09 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 17:34:08 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 17:34:07 +0100 Message-ID: <49A6C47F.2000301@ericsson.com> Date: Thu, 26 Feb 2009 17:34:07 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2009 16:34:07.0901 (UTC) FILETIME=[0BB4A4D0:01C99830] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Separate namespace per YAM? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 16:34:25 -0000 Hello, In chapter 5.3 it is written that "All YANG definitions are specified within a module that is bound to a particular XML Namespace [XML-NAMES], which is a globally unique URI [RFC3986]. " According to my English knowledge this does not mean that two different modules can not use the same namespace; the namespace is unique even if it is used by multiple YAMs. Do we allow different modules to use the same namespace? If not, I propose to change this to: "All YANG definitions are specified within a module that is bound to -- its own unique --- XML Namespace [XML-NAMES], which is a globally unique URI [RFC3986]. " Balazs From balazs.lengyel@ericsson.com Thu Feb 26 08:46: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 6234428C2F1 for ; Thu, 26 Feb 2009 08:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.268, 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 VaO+zBk2JWpq for ; Thu, 26 Feb 2009 08:46:15 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A998628C2F0 for ; Thu, 26 Feb 2009 08:46:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31BA72180E for ; Thu, 26 Feb 2009 17:46:35 +0100 (CET) X-AuditID: c1b4fb3e-ac0bbbb000001315-ee-49a6c76bd940 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 179E220FCB for ; Thu, 26 Feb 2009 17:46:35 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 17:46:34 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 17:46:34 +0100 Message-ID: <49A6C76A.8030002@ericsson.com> Date: Thu, 26 Feb 2009 17:46:34 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2009 16:46:34.0282 (UTC) FILETIME=[C89558A0:01C99831] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Multi step derivation and strings with patterns X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 16:46:16 -0000 Hello, I am missing from chapter 9.4.6 The pattern Statement the following: If a pattern restriction is applied to an already pattern restricted type, then values for that type must conform to both the current pattern and any pattern restriction valid for the base type(s). Or was the decision the opposite? Anyway state it please. Balazs From andy@netconfcentral.com Thu Feb 26 08:59:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8034B28C2BA for ; Thu, 26 Feb 2009 08:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.105, 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 iil0dHIxyhiE for ; Thu, 26 Feb 2009 08:59:02 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 00F603A6BF1 for ; Thu, 26 Feb 2009 08:59:01 -0800 (PST) Received: (qmail 76419 invoked from network); 26 Feb 2009 16:59:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.116 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 26 Feb 2009 16:59:22 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6CA69.6080300@netconfcentral.com> Date: Thu, 26 Feb 2009 08:59:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A568C8.40005@netconfcentral.com> <20090225.185113.75438571.mbj@tail-f.com> In-Reply-To: <20090225.185113.75438571.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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 16:59:05 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I am still unclear on the text about the YIN XML namespace prefix >> exactly matching the YANG module prefix. YANG module prefixes >> are not unique. That's why the prefix can be specified in >> the import-stmt (to give the data modeler the joy of >> resolving all the prefix collisions manually ;-) >> >> So how does YIN deal with this problem? > > I don't understand the problem. All prefixes in a YANG module are > unique. Each prefix maps to a module, which defines a namespace. > Maybe you can provide an example which has this problem? > My concern is 11.2, para 3, sentence 2, and para 4, sentence 2: Elements which represent keywords that are imported extensions from other modules MUST be properly namespace qualified, where the namespace is the namespace of the imported module. The XML prefix for such extensions MUST be the same as the prefix defined in the module's "import" statement. Elements which represent keywords that are included extensions from other submodules MUST be properly namespace qualified, where the namespace is the namespace of the module that the submodule belongs to. The XML prefix for such extensions MUST be the same as the local prefix, i.e. for a module it is as defined in the "prefix" statement, and for a submodule, as defined in the submodule's "belongs-to" statement. There is no reason for this CLR about the XML prefix matching the module prefix. Sentence 1 in each paragraph is enough. Sentence 2 is just a CLR. Here is the only example of YIN in the draft (plus an extension): extension value The MTU of the interface. module X { namespace "acme-module-namespace"; prefix X; extension foo { description ""; argument bar { yin-element true; } } } According to the draft, the example above is an error because the arbitrary value I used for my XML prefix is 'acme', not 'X'. IMO, it is wrong to force XML tools to use YANG hack values instead of the allowing the freedom they expect from the XML standard. But this hack is needed, because the import-stmt specifies the module prefix (e.g., X). The tool does not know where to find the module that has namespace-stmt = 'acme-module-namespace'. I seriously doubt any off-the-shelf XML tools are going to be clever enough to add semantics to the arbitrary values used in XML prefixes, match them up with the particular XML subtrees for the import-stmts, then go find the module X to make sure it has an extension 'foo', and check its argument-stmt to see if 'bar' is OK. All this, above and beyond the plain schema validation normally done? > >> What about the XPath prefix issues? >> How are all the prefixes within must/when path expressions >> represented? What happens when they are missing? >> Is this behavior different for elements vs. attributes? > > Note that YIN is just a different syntax. The mapping does not modify > any string *values* (just on the syntax level, e.g. '>' must be > quoted in XML). So if you believe we have any prefix issues in the > interpretation of XPath in YIN, then we have them in YANG as well. > >> Why does YIN need to use attributes at all? >> Why can't YANG and YIN be simplified by always using >> elements in YIN? > > There are of course many ways an XML syntax of YANG could be > specified. We chose one which we believe is correct (i.e. 1-1 > mappable), readable, writable, and simple to implement. The reason > some elements have attributes is for readability and writability. > Fine. Since YANG does not support XML attributes at all because they are inferior to elements, it seems odd that YIN makes such heavy use of them. But I'm sure people who write YIN will eventually memorize the 2 page table in sec. 11.2, so it doesn't matter. > > /martin > > Andy From andy@netconfcentral.com Thu Feb 26 09:06: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 53E6A28C293 for ; Thu, 26 Feb 2009 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 STNj79Dn6zW4 for ; Thu, 26 Feb 2009 09:06:20 -0800 (PST) Received: from n9.bullet.mail.mud.yahoo.com (n9.bullet.mail.mud.yahoo.com [209.191.86.157]) by core3.amsl.com (Postfix) with SMTP id 71E6A28C2BA for ; Thu, 26 Feb 2009 09:06:20 -0800 (PST) Received: from [68.142.194.243] by n9.bullet.mail.mud.yahoo.com with NNFMP; 26 Feb 2009 17:06:42 -0000 Received: from [68.142.201.245] by t1.bullet.mud.yahoo.com with NNFMP; 26 Feb 2009 17:06:42 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 26 Feb 2009 17:06:42 -0000 X-Yahoo-Newman-Id: 10954.8558.bm@omp406.mail.mud.yahoo.com Received: (qmail 44717 invoked from network); 26 Feb 2009 17:06:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.116 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 26 Feb 2009 17:06:40 -0000 X-YMail-OSG: u..rdo0VM1nlPA5DX_ld3s9HV4rRXREd6eVD4WZSnaFamW4HFRUhs.2D_ETHhJikZmOQcHrEy18cUocLfzokqc10d.vr8hKmqJER2wVDlxW8RoywEDc6x9NT5ixgcjsUrPBfA3Ssb9FPWZ8BhDIYXwD4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6CC17.2010306@netconfcentral.com> Date: Thu, 26 Feb 2009 09:06:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <49A6C47F.2000301@ericsson.com> In-Reply-To: <49A6C47F.2000301@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Separate namespace per YAM? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 17:06:21 -0000 Balazs Lengyel wrote: > Hello, > In chapter 5.3 it is written that > "All YANG definitions are specified within a module that is bound to a > particular XML Namespace [XML-NAMES], which is a globally unique URI > [RFC3986]. " > > According to my English knowledge this does not mean that two different > modules can not use the same namespace; the namespace is unique even if > it is used by multiple YAMs. > > Do we allow different modules to use the same namespace? If not, I > propose to change this to: > > "All YANG definitions are specified within a module that is bound to -- > its own unique --- XML Namespace [XML-NAMES], which is a globally unique > URI [RFC3986]. " > The current text seems fine. 'A particular' means 'one', and 'globally unique' is plain enough. One XML namespace per module is the rule. > Balazs Andy From lhotka@cesnet.cz Thu Feb 26 09:29: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 18CFC3A693A for ; Thu, 26 Feb 2009 09:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_53=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 NCLikYwhw6XK for ; Thu, 26 Feb 2009 09:29:24 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E66043A6932 for ; Thu, 26 Feb 2009 09:29:23 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A5A03D800D1; Thu, 26 Feb 2009 18:29:44 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49A6CA69.6080300@netconfcentral.com> References: <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A568C8.40005@netconfcentral.com> <20090225.185113.75438571.mbj@tail-f.com> <49A6CA69.6080300@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 26 Feb 2009 18:29:45 +0100 Message-Id: <1235669385.6396.90.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 17:29:25 -0000 Andy Bierman píše v Čt 26. 02. 2009 v 08:59 -0800: > Elements which represent keywords that are imported extensions from > other modules MUST be properly namespace qualified, where the > namespace is the namespace of the imported module. The XML prefix > for such extensions MUST be the same as the prefix defined in the > module's "import" statement. > > Elements which represent keywords that are included extensions from > other submodules MUST be properly namespace qualified, where the > namespace is the namespace of the module that the submodule belongs > to. The XML prefix for such extensions MUST be the same as the local > prefix, i.e. for a module it is as defined in the "prefix" statement, > and for a submodule, as defined in the submodule's "belongs-to" > statement. > > > There is no reason for this CLR about the XML prefix matching > the module prefix. Sentence 1 in each paragraph is enough. > Sentence 2 is just a CLR. +1 > > Here is the only example of YIN in the draft (plus an extension): > > > > extension value > > > > The MTU of the interface. > > > > > module X { > namespace "acme-module-namespace"; > prefix X; > > extension foo { > description ""; > argument bar { > yin-element true; > } > } > } > > > According to the draft, the example above is an error > because the arbitrary value I used for my XML prefix > is 'acme', not 'X'. IMO, it is wrong to force XML tools > to use YANG hack values instead of the allowing the > freedom they expect from the XML standard. Schema languages typically use other mechanisms than xmlns:xxx attributes for declaring the namespace for their target vocabulary, so this is not really special. The only difference is that the extensions in YANG add new elements to the schema language itself that are in the same namespace as the vocabulary being defined by the module - i.e., the vocabulary is mixed with meta-vocabulary. I think this is a wrong language design - the extensions should actually be specified to extend the ABNF for YANG or XML schema for YIN and should have a different namespace than any YANG module defining data models. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Feb 26 10:24: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 2DE9D28C11A for ; Thu, 26 Feb 2009 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_53=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 Lp386x9uT03o for ; Thu, 26 Feb 2009 10:24:50 -0800 (PST) Received: from n27.bullet.mail.mud.yahoo.com (n27.bullet.mail.mud.yahoo.com [68.142.206.222]) by core3.amsl.com (Postfix) with SMTP id 3C93128C0EE for ; Thu, 26 Feb 2009 10:24:50 -0800 (PST) Received: from [209.191.108.97] by n27.bullet.mail.mud.yahoo.com with NNFMP; 26 Feb 2009 18:25:11 -0000 Received: from [68.142.201.254] by t4.bullet.mud.yahoo.com with NNFMP; 26 Feb 2009 18:25:11 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 26 Feb 2009 18:25:11 -0000 X-Yahoo-Newman-Id: 858570.21921.bm@omp415.mail.mud.yahoo.com Received: (qmail 93180 invoked from network); 26 Feb 2009 18:25:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.116 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 26 Feb 2009 18:25:04 -0000 X-YMail-OSG: _aBcP9sVM1nxVnnLXxeeu839OP7ip5a6583Xd1SVt7915qqg_AQDA5Xtbuts25d7mMDeIBMBoSrIx28KHt5Bpz1u49uSPfbGdgt6rghwObj6FzNV75ncUnOa0P49Qy7FWSk0KvwTCm.2naTDupHyP2L8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6DE76.5040407@netconfcentral.com> Date: Thu, 26 Feb 2009 10:24:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <49A559CC.3030307@netconfcentral.com> <20090225.160748.200259580.mbj@tail-f.com> <49A568C8.40005@netconfcentral.com> <20090225.185113.75438571.mbj@tail-f.com> <49A6CA69.6080300@netconfcentral.com> <1235669385.6396.90.camel@missotis> In-Reply-To: <1235669385.6396.90.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 18:24:51 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Čt 26. 02. 2009 v 08:59 -0800: >> Elements which represent keywords that are imported extensions from >> other modules MUST be properly namespace qualified, where the >> namespace is the namespace of the imported module. The XML prefix >> for such extensions MUST be the same as the prefix defined in the >> module's "import" statement. >> >> Elements which represent keywords that are included extensions from >> other submodules MUST be properly namespace qualified, where the >> namespace is the namespace of the module that the submodule belongs >> to. The XML prefix for such extensions MUST be the same as the local >> prefix, i.e. for a module it is as defined in the "prefix" statement, >> and for a submodule, as defined in the submodule's "belongs-to" >> statement. >> >> >> There is no reason for this CLR about the XML prefix matching >> the module prefix. Sentence 1 in each paragraph is enough. >> Sentence 2 is just a CLR. > > +1 > This is one of those emails that, by the time I got to the end, I realized what Martin was talking about, and I understand why the hack is needed. The YIN parser needs to find all the appropriate schema files in some manner -- normal XML stuff. Here is where YIN translation based on pure XML breaks. The namespace-stmt value in module X is not required to change every time a new revision is published. (IMO, it MUST NOT change). So ignoring the import-stmt doesn't always work. This is different than parsing XPath in PDUs. The agent has all the modules pre-loaded and the PDU must match what it knows. The YANG or YIN compiler starts with [sub]module X and does not know which versions of which imports are needed in advance. The import revision date cannot be ignored if it is present. The module name is obviously needed as well, in order to use the revision date (instead of the XML namespace that matched, but the module name cannot be derived from that URI). >> Here is the only example of YIN in the draft (plus an extension): >> >> >> >> extension value >> >> >> >> The MTU of the interface. >> >> >> >> >> module X { >> namespace "acme-module-namespace"; >> prefix X; >> >> extension foo { >> description ""; >> argument bar { >> yin-element true; >> } >> } >> } >> >> >> According to the draft, the example above is an error >> because the arbitrary value I used for my XML prefix >> is 'acme', not 'X'. IMO, it is wrong to force XML tools >> to use YANG hack values instead of the allowing the >> freedom they expect from the XML standard. > > Schema languages typically use other mechanisms than xmlns:xxx > attributes for declaring the namespace for their target vocabulary, so > this is not really special. The only difference is that the extensions > in YANG add new elements to the schema language itself that are in the > same namespace as the vocabulary being defined by the module - i.e., the > vocabulary is mixed with meta-vocabulary. I think this is a wrong > language design - the extensions should actually be specified to extend > the ABNF for YANG or XML schema for YIN and should have a different > namespace than any YANG module defining data models. The extensions are required to use a prefix, and must be some other namespace than the one for YIN. They are not mixed in YANG at all. They must always use a prefix there as well. > > Lada > Andy From andy@netconfcentral.com Thu Feb 26 10:51: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 86CB43A6847 for ; Thu, 26 Feb 2009 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.099, 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 NfTm6Kw4hQ0a for ; Thu, 26 Feb 2009 10:51:07 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id DC24B3A6818 for ; Thu, 26 Feb 2009 10:51:07 -0800 (PST) Received: (qmail 85921 invoked from network); 26 Feb 2009 18:51:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.116 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 26 Feb 2009 18:51:29 -0000 X-YMail-OSG: KMLhuy0VM1kgq8q8GWmID17UacqckjGgNajFAz28jngheQjPTqyln0kBrxSjkPjwS4eMl7lRUpSJJYUZoJH3ekQ2GINfZeC8kfjBghH2OFPQ0_LuYS3yC0Yn8rgWcxP6ubuSoEhRaBeDFDjLgoDt6KCC X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6E4AF.2050606@netconfcentral.com> Date: Thu, 26 Feb 2009 10:51:27 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] YAM terminology X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 18:51:08 -0000 Hi, I think Dave raised valid issues with NETCONF/NETMOD usage of the YAM acronym (which is really isn't in this case). I think the more verbose terminology already in place is good enough: YANG or YIN module --> module YANG or YIN submodule --> submodule YANG or YIN module or submodule --> [sub]module SMIv2 module --> MIB module Andy From mbj@tail-f.com Thu Feb 26 11:32:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14773A695C for ; Thu, 26 Feb 2009 11:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.104, 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 FDt3+35Ubzmc for ; Thu, 26 Feb 2009 11:32:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C3C173A680E for ; Thu, 26 Feb 2009 11:32:30 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 69DBA76C54A; Thu, 26 Feb 2009 20:32:51 +0100 (CET) Date: Thu, 26 Feb 2009 20:32:50 +0100 (CET) Message-Id: <20090226.203250.266284461.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1235669385.6396.90.camel@missotis> References: <20090225.185113.75438571.mbj@tail-f.com> <49A6CA69.6080300@netconfcentral.com> <1235669385.6396.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=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 19:32:31 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IMSMdCAyNi4gMDIuIDIwMDkgdiAwODo1OSAtMDgwMDoNCj4gPiAgICAgRWxlbWVu dHMgd2hpY2ggcmVwcmVzZW50IGtleXdvcmRzIHRoYXQgYXJlIGltcG9ydGVkIGV4dGVuc2lvbnMg ZnJvbQ0KPiA+ICAgICBvdGhlciBtb2R1bGVzIE1VU1QgYmUgcHJvcGVybHkgbmFtZXNwYWNlIHF1 YWxpZmllZCwgd2hlcmUgdGhlDQo+ID4gICAgIG5hbWVzcGFjZSBpcyB0aGUgbmFtZXNwYWNlIG9m IHRoZSBpbXBvcnRlZCBtb2R1bGUuICBUaGUgWE1MIHByZWZpeA0KPiA+ICAgICBmb3Igc3VjaCBl eHRlbnNpb25zIE1VU1QgYmUgdGhlIHNhbWUgYXMgdGhlIHByZWZpeCBkZWZpbmVkIGluIHRoZQ0K PiA+ICAgICBtb2R1bGUncyAiaW1wb3J0IiBzdGF0ZW1lbnQuDQo+ID4gDQo+ID4gICAgIEVsZW1l bnRzIHdoaWNoIHJlcHJlc2VudCBrZXl3b3JkcyB0aGF0IGFyZSBpbmNsdWRlZCBleHRlbnNpb25z IGZyb20NCj4gPiAgICAgb3RoZXIgc3VibW9kdWxlcyBNVVNUIGJlIHByb3Blcmx5IG5hbWVzcGFj ZSBxdWFsaWZpZWQsIHdoZXJlIHRoZQ0KPiA+ICAgICBuYW1lc3BhY2UgaXMgdGhlIG5hbWVzcGFj ZSBvZiB0aGUgbW9kdWxlIHRoYXQgdGhlIHN1Ym1vZHVsZSBiZWxvbmdzDQo+ID4gICAgIHRvLiAg VGhlIFhNTCBwcmVmaXggZm9yIHN1Y2ggZXh0ZW5zaW9ucyBNVVNUIGJlIHRoZSBzYW1lIGFzIHRo ZSBsb2NhbA0KPiA+ICAgICBwcmVmaXgsIGkuZS4gZm9yIGEgbW9kdWxlIGl0IGlzIGFzIGRlZmlu ZWQgaW4gdGhlICJwcmVmaXgiIHN0YXRlbWVudCwNCj4gPiAgICAgYW5kIGZvciBhIHN1Ym1vZHVs ZSwgYXMgZGVmaW5lZCBpbiB0aGUgc3VibW9kdWxlJ3MgImJlbG9uZ3MtdG8iDQo+ID4gICAgIHN0 YXRlbWVudC4NCj4gPiANCj4gPiANCj4gPiBUaGVyZSBpcyBubyByZWFzb24gZm9yIHRoaXMgQ0xS IGFib3V0IHRoZSBYTUwgcHJlZml4IG1hdGNoaW5nDQo+ID4gdGhlIG1vZHVsZSBwcmVmaXguICBT ZW50ZW5jZSAxIGluIGVhY2ggcGFyYWdyYXBoIGlzIGVub3VnaC4NCj4gPiBTZW50ZW5jZSAyIGlz IGp1c3QgYSBDTFIuDQo+IA0KPiArMQ0KDQpZZXMsIEkgYWdyZWUuICBJbiBmYWN0LCB0aGUgeWlu IHBhcnNlciBpbiBweWFuZyBhbHJlYWR5IGFjY2VwdHMgYW55DQpYTUwgcHJlZml4IGZvciB0aGlz IGNhc2UuICBJIHdpbGwgcmVtb3ZlIHRoaXMgQ0xSLg0KDQoNCi9tYXJ0aW4NCg== From andy@netconfcentral.com Thu Feb 26 11:42: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 70EA728C296 for ; Thu, 26 Feb 2009 11:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRxSxoGjFYWR for ; Thu, 26 Feb 2009 11:42:24 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 2CE0B28C258 for ; Thu, 26 Feb 2009 11:42:24 -0800 (PST) Received: (qmail 53209 invoked from network); 26 Feb 2009 19:42:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.116 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 26 Feb 2009 19:42:45 -0000 X-YMail-OSG: egZHCqsVM1lJha7.eZczXelmiVHLHdNFmqSGiLTddinLgjnvgp2qyLpdNkhlf9bNpkpahiwHGX_XCkUcHEYKBdEHJSsMBQ0P__mQNzXhJW4T5kdbGWTl6e8QGfpDDdIz2URMt4vhQt.q5JCys3ogn_VSawYsSeV5x3GYNTiz_uigKMqNra4OOcBOC7FpSzFbETeGEKyKzc.v X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6F0B4.5040401@netconfcentral.com> Date: Thu, 26 Feb 2009 11:42:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090225.185113.75438571.mbj@tail-f.com> <49A6CA69.6080300@netconfcentral.com> <1235669385.6396.90.camel@missotis> <20090226.203250.266284461.mbj@tail-f.com> In-Reply-To: <20090226.203250.266284461.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 19:42:25 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Andy Bierman píše v Čt 26. 02. 2009 v 08:59 -0800: >>> Elements which represent keywords that are imported extensions from >>> other modules MUST be properly namespace qualified, where the >>> namespace is the namespace of the imported module. The XML prefix >>> for such extensions MUST be the same as the prefix defined in the >>> module's "import" statement. >>> >>> Elements which represent keywords that are included extensions from >>> other submodules MUST be properly namespace qualified, where the >>> namespace is the namespace of the module that the submodule belongs >>> to. The XML prefix for such extensions MUST be the same as the local >>> prefix, i.e. for a module it is as defined in the "prefix" statement, >>> and for a submodule, as defined in the submodule's "belongs-to" >>> statement. >>> >>> >>> There is no reason for this CLR about the XML prefix matching >>> the module prefix. Sentence 1 in each paragraph is enough. >>> Sentence 2 is just a CLR. >> +1 > > Yes, I agree. In fact, the yin parser in pyang already accepts any > XML prefix for this case. I will remove this CLR. > Do you make sure the module you pick matches an import-stmt? > > /martin Andy From mbj@tail-f.com Thu Feb 26 12:31: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 B1E3B28C227 for ; Thu, 26 Feb 2009 12:31:09 -0800 (PST) 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 3g+0GY8QmZYM for ; Thu, 26 Feb 2009 12:31:08 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 152273A6A39 for ; Thu, 26 Feb 2009 12:31:07 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D2CFB76C341; Thu, 26 Feb 2009 21:23:50 +0100 (CET) Date: Thu, 26 Feb 2009 21:23:50 +0100 (CET) Message-Id: <20090226.212350.209477039.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A6F0B4.5040401@netconfcentral.com> References: <1235669385.6396.90.camel@missotis> <20090226.203250.266284461.mbj@tail-f.com> <49A6F0B4.5040401@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=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 20:31:09 -0000 QW5keSBCaWVybWFuIDxhbmR5QG5ldGNvbmZjZW50cmFsLmNvbT4gd3JvdGU6DQo+IE1hcnRpbiBC am9ya2x1bmQgd3JvdGU6DQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3 cm90ZToNCj4gPj4gQW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAyNi4gMDIuIDIwMDkgdiAwODo1 OSAtMDgwMDoNCj4gPj4+ICAgICBFbGVtZW50cyB3aGljaCByZXByZXNlbnQga2V5d29yZHMgdGhh dCBhcmUgaW1wb3J0ZWQgZXh0ZW5zaW9ucyBmcm9tDQo+ID4+PiAgICAgb3RoZXIgbW9kdWxlcyBN VVNUIGJlIHByb3Blcmx5IG5hbWVzcGFjZSBxdWFsaWZpZWQsIHdoZXJlIHRoZQ0KPiA+Pj4gICAg IG5hbWVzcGFjZSBpcyB0aGUgbmFtZXNwYWNlIG9mIHRoZSBpbXBvcnRlZCBtb2R1bGUuICBUaGUg WE1MIHByZWZpeA0KPiA+Pj4gICAgIGZvciBzdWNoIGV4dGVuc2lvbnMgTVVTVCBiZSB0aGUgc2Ft ZSBhcyB0aGUgcHJlZml4IGRlZmluZWQgaW4gdGhlDQo+ID4+PiAgICAgbW9kdWxlJ3MgImltcG9y dCIgc3RhdGVtZW50Lg0KPiA+Pj4NCj4gPj4+ICAgICBFbGVtZW50cyB3aGljaCByZXByZXNlbnQg a2V5d29yZHMgdGhhdCBhcmUgaW5jbHVkZWQgZXh0ZW5zaW9ucyBmcm9tDQo+ID4+PiAgICAgb3Ro ZXIgc3VibW9kdWxlcyBNVVNUIGJlIHByb3Blcmx5IG5hbWVzcGFjZSBxdWFsaWZpZWQsIHdoZXJl IHRoZQ0KPiA+Pj4gICAgIG5hbWVzcGFjZSBpcyB0aGUgbmFtZXNwYWNlIG9mIHRoZSBtb2R1bGUg dGhhdCB0aGUgc3VibW9kdWxlIGJlbG9uZ3MNCj4gPj4+ICAgICB0by4gIFRoZSBYTUwgcHJlZml4 IGZvciBzdWNoIGV4dGVuc2lvbnMgTVVTVCBiZSB0aGUgc2FtZSBhcyB0aGUgbG9jYWwNCj4gPj4+ ICAgICBwcmVmaXgsIGkuZS4gZm9yIGEgbW9kdWxlIGl0IGlzIGFzIGRlZmluZWQgaW4gdGhlICJw cmVmaXgiIHN0YXRlbWVudCwNCj4gPj4+ICAgICBhbmQgZm9yIGEgc3VibW9kdWxlLCBhcyBkZWZp bmVkIGluIHRoZSBzdWJtb2R1bGUncyAiYmVsb25ncy10byINCj4gPj4+ICAgICBzdGF0ZW1lbnQu DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZXJlIGlzIG5vIHJlYXNvbiBmb3IgdGhpcyBDTFIgYWJv dXQgdGhlIFhNTCBwcmVmaXggbWF0Y2hpbmcNCj4gPj4+IHRoZSBtb2R1bGUgcHJlZml4LiAgU2Vu dGVuY2UgMSBpbiBlYWNoIHBhcmFncmFwaCBpcyBlbm91Z2guDQo+ID4+PiBTZW50ZW5jZSAyIGlz IGp1c3QgYSBDTFIuDQo+ID4+ICsxDQo+ID4gWWVzLCBJIGFncmVlLiAgSW4gZmFjdCwgdGhlIHlp biBwYXJzZXIgaW4gcHlhbmcgYWxyZWFkeSBhY2NlcHRzIGFueQ0KPiA+IFhNTCBwcmVmaXggZm9y IHRoaXMgY2FzZS4gIEkgd2lsbCByZW1vdmUgdGhpcyBDTFIuDQo+ID4gDQo+IA0KPiBEbyB5b3Ug bWFrZSBzdXJlIHRoZSBtb2R1bGUgeW91IHBpY2sgbWF0Y2hlcyBhbiBpbXBvcnQtc3RtdD8NCg0K WWVzLiAgVGhlIFhNTCBwcmVmaXggbWFwcyB0byBhIFVSSSwgYW5kIGZyb20gdGhlIGltcG9ydHMg SSBjcmVhdGUgYQ0KdGFibGUgd2hpY2ggbWFwcyBVUkkgdG8gbW9kdWxlLiAgU28gZ2l2ZW4gdGhl IFhNTCBwcmVmaXggaXRzIGVhc3kgdG8NCmxvY2F0ZSB0aGUgbW9kdWxlLiAgSWYgdGhlIG1vZHVs ZSBpcyBub3QgaW1wb3J0ZWQsIGl0cyBVUkkgd2lsbCBub3QgYmUNCmluIHRoZSB0YWJsZSwgYW5k IGFuIGVycm9yIGlzIGdlbmVyYXRlZC4NCg0KDQovbWFydGluDQo= From andy@netconfcentral.com Thu Feb 26 13:38: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 081333A6C0C for ; Thu, 26 Feb 2009 13:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89QxiKj-2Pbd for ; Thu, 26 Feb 2009 13:38:00 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id C97B33A6C0A for ; Thu, 26 Feb 2009 13:38:00 -0800 (PST) Received: (qmail 74191 invoked from network); 26 Feb 2009 21:38:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.116 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Feb 2009 21:38:22 -0000 X-YMail-OSG: zQDssSYVM1mfci61g8FZejqEG.OJGMt780Zl10QQQ7g0y4HsC7tbtSPzPS0e9CPsKGXsCXMk0nnJlJCOE_9M1VZfAMjfZ8Y8ACNhtyvY1CsGHKHVZ7bJA33qq.fQIc9Xdv.U3tBLfdedvenkoovHbw0km7P8aYaajieDjHEo45PWjUlhXF46GR5T.u2X9adO0tjoSn7YmMP9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A70BCD.9090207@netconfcentral.com> Date: Thu, 26 Feb 2009 13:38:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <1235669385.6396.90.camel@missotis> <20090226.203250.266284461.mbj@tail-f.com> <49A6F0B4.5040401@netconfcentral.com> <20090226.212350.209477039.mbj@tail-f.com> In-Reply-To: <20090226.212350.209477039.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 21:38:02 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> Andy Bierman píše v Čt 26. 02. 2009 v 08:59 -0800: >>>>> Elements which represent keywords that are imported extensions from >>>>> other modules MUST be properly namespace qualified, where the >>>>> namespace is the namespace of the imported module. The XML prefix >>>>> for such extensions MUST be the same as the prefix defined in the >>>>> module's "import" statement. >>>>> >>>>> Elements which represent keywords that are included extensions from >>>>> other submodules MUST be properly namespace qualified, where the >>>>> namespace is the namespace of the module that the submodule belongs >>>>> to. The XML prefix for such extensions MUST be the same as the local >>>>> prefix, i.e. for a module it is as defined in the "prefix" statement, >>>>> and for a submodule, as defined in the submodule's "belongs-to" >>>>> statement. >>>>> >>>>> >>>>> There is no reason for this CLR about the XML prefix matching >>>>> the module prefix. Sentence 1 in each paragraph is enough. >>>>> Sentence 2 is just a CLR. >>>> +1 >>> Yes, I agree. In fact, the yin parser in pyang already accepts any >>> XML prefix for this case. I will remove this CLR. >>> >> Do you make sure the module you pick matches an import-stmt? > > Yes. The XML prefix maps to a URI, and from the imports I create a > table which maps URI to module. So given the XML prefix its easy to > locate the module. If the module is not imported, its URI will not be > in the table, and an error is generated. > OK, remove the CLR then. It works the same way as for parsing YANG, like you were saying all along. In YANG, it helps to defer validation of extensions in case they appear before the import-stmt that defines them. I guess the same applies in YIN as well. > > /martin Andy From mbj@tail-f.com Thu Feb 26 14:32:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA5628C32B for ; Thu, 26 Feb 2009 14:32:10 -0800 (PST) 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=[AWL=0.096, 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 s01-8bC-HMMg for ; Thu, 26 Feb 2009 14:32:09 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 746FA28C33A for ; Thu, 26 Feb 2009 14:32:09 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A682A76C341; Thu, 26 Feb 2009 23:32:29 +0100 (CET) Date: Thu, 26 Feb 2009 23:32:29 +0100 (CET) Message-Id: <20090226.233229.93109353.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200902111134.38359.david.partain@ericsson.com> References: <498B8EB9.1060201@netconfcentral.com> <20090209.214608.218111424.mbj@tail-f.com> <200902111134.38359.david.partain@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] require-instance error-app-tag X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 22:32:10 -0000 David Partain wrote: > Hi, > > On Monday 09 February 2009 21.46.08 Martin Bjorklund wrote: > > Andy Bierman wrote: > > > Hi, > > > > > > There doesn't seem to be any good error codes for a > > > require-instance = true violation for a leafref or instance-identifier. > > > Perhaps a new error-app-tag and sub-section of 13.x should be > > > added to make that stand out, especially since the default > > > is true. > > > > I agree. 'missing-instance' is already used. How about > > 'instance-required'? > > Seems fine to me. > > > What should the error-tag be? > > 'operation-failed', or could 'data-missing' be used? > > data-missing makes good sense. Ok. I have added: ** Error Message for Data that Violates a require-instance statement: If a NETCONF operation would result in configuration data where an instance reference marked with require-instance "true" refers to a non-existing instance, the following error is returned: Tag: data-missing Error-app-tag: instance-required There's also no good error code for the case when a mandatory choice does not exist. I propose the following text: ** Error Message for Data that Violates a mandatory choice statement: If a NETCONF operation would result in configuration data where no nodes exists in a mandatory choice, the following error is returned: Tag: data-missing Error-app-tag: missing-choice Error-path: Path to the element with the missing choice. Error-info: : Contains the name of the missing mandatory choice. The element is in the YANG namespace ("urn:ietf:params:xml:ns:yang:1" [XXX IANA]). /martin From mbj@tail-f.com Thu Feb 26 15:11: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 967683A6972 for ; Thu, 26 Feb 2009 15:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.092, 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 rlv222DDjdVJ for ; Thu, 26 Feb 2009 15:11:07 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C53D43A6867 for ; Thu, 26 Feb 2009 15:11:07 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id F0D5E76C341; Fri, 27 Feb 2009 00:04:29 +0100 (CET) Date: Fri, 27 Feb 2009 00:04:29 +0100 (CET) Message-Id: <20090227.000429.106472320.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <49A6C76A.8030002@ericsson.com> References: <49A6C76A.8030002@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Multi step derivation and strings with patterns X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 23:11:08 -0000 Balazs Lengyel wrote: > Hello, > I am missing from chapter 9.4.6 The pattern Statement the following: > > If a pattern restriction is applied to an already pattern restricted type, then > values for that type must conform to both the current pattern and any pattern > restriction valid for the base type(s). Ok. I will add this. /martin From david.kessens@nsn.com Thu Feb 26 15:45: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 A2DA93A68C8 for ; Thu, 26 Feb 2009 15:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VfdWs3FqyyP for ; Thu, 26 Feb 2009 15:45:39 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6CFBC3A6767 for ; Thu, 26 Feb 2009 15:45:39 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1QNjus4019858 for ; Fri, 27 Feb 2009 01:45:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 01:45:57 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 01:45:56 +0200 Received: from localhost.localdomain ([10.241.59.1]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 01:45:55 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n1QNjNeR008855 for ; Thu, 26 Feb 2009 15:45:23 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n1QNjNUG008854 for netmod@ietf.org; Thu, 26 Feb 2009 15:45:23 -0800 Date: Thu, 26 Feb 2009 15:45:23 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20090226234523.GD23662@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 26 Feb 2009 23:45:56.0288 (UTC) FILETIME=[5E4EC400:01C9986C] X-Nokia-AV: Clean Subject: [netmod] [amorris@amsl.com: Initial Version I-D Submission Deadline Extended to March 4, 2009] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Feb 2009 23:45:40 -0000 For your information: ----- Forwarded message from Alexa Morris ----- Date: Thu, 26 Feb 2009 11:27:35 -0800 From: Alexa Morris To: ietf-announce@ietf.org, ietf@ietf.org, wgchairs@ietf.org Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 The IESG has extended the deadline for initial version (00) submissions of Internet Drafts by 2 days (48 hours). The new deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) and the extension is for IETF 74 only. The deadline has been extended due to the copyright legend text alternative being recently finalized, approved and implemented. Please note that the date for updated I-D versions has NOT been extended, and is still March 9, 2009. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- From mbj@tail-f.com Fri Feb 27 00: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 54AFE3A69FC for ; Fri, 27 Feb 2009 00:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-wKIz-f6JZx for ; Fri, 27 Feb 2009 00:15:36 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 875F83A688E for ; Fri, 27 Feb 2009 00:15:36 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2322076C225 for ; Fri, 27 Feb 2009 09:15:57 +0100 (CET) Date: Fri, 27 Feb 2009 09:15:56 +0100 (CET) Message-Id: <20090227.091556.134897733.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20090131.210512.120353109.mbj@tail-f.com> References: <49849EA9.5090908@netconfcentral.com> <20090131.210512.120353109.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 Subject: Re: [netmod] yang-03, import/include by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Feb 2009 08:15:37 -0000 Hi, Revisiting an old thread. Martin Bjorklund wrote: > Andy Bierman wrote: > > Issue 7) Why is the full revision-stmt needed in the import-stmt > > and include-stmt? If the description-stmt is really so > > important here (IMO no) then it should be a sub-statement > > of 'import' or 'include' directly, not a sub-stmt of 'revision'. > > I prefer this ABNF instead (without a description-stmt): > > > > import-stmt = import-keyword sep identifier-arg-str optsep > > "{" stmtsep > > prefix-stmt stmtsep > > [revision-keyword sep date-arg-str stmtsep] > > "}" > > I agree. This was a bug. The 'revision' statement is defined to allow a description substatement. Since we don't want to introduce a context sensitive grammar (by saying that depending on where it is used 'revision' sometimes has a 'description' substatement, and sometimes not), Andy suggested (in an off-line discussion) that we use the following instead: import X { prefix x; revision-date 2009-01-01; } I think this makes sense, and will use it to solve this issue unless people disagree. /martin From mbj@tail-f.com Sat Feb 28 06:40: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 EEFB73A69CD for ; Sat, 28 Feb 2009 06:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=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 K6ihoPKqTA1q for ; Sat, 28 Feb 2009 06:40:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D27303A68C3 for ; Sat, 28 Feb 2009 06:40:02 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 82FEE76C340; Sat, 28 Feb 2009 15:40:25 +0100 (CET) Date: Sat, 28 Feb 2009 15:40:25 +0100 (CET) Message-Id: <20090228.154025.141346957.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A70BCD.9090207@netconfcentral.com> References: <49A6F0B4.5040401@netconfcentral.com> <20090226.212350.209477039.mbj@tail-f.com> <49A70BCD.9090207@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] namespaces in YIN X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Feb 2009 14:40:04 -0000 Hi, Ladislav suggested that we change the way YIN is described to a declarative style, rather than the imperative style we have today. He proposed the following text (thank you Lada!), which I think is better than the current one. This text would replace sections 11.1, 11.2, and 11.3. 11.1. Formal YIN Definition There is a one-to-one correspondence between YANG keywords and YIN elements. The local name of a YIN element is identical to the corresponding YANG keyword. This means in particular that the document element (root) of a YIN document is always or . YIN elements corresponding to the core YANG keywords belong to the namespace whose associated URI is "urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA]. YIN elements corresponding to extension keywords belong to the namespace of the YANG module where the extension keyword is declared via the "extension" statement. The names of all YIN elements MUST be properly qualified with their namespaces specified above using the standard mechanisms of [XML- NAMES], i.e. xmlns and xmlns:xxx attributes. The argument of a YANG statement is encoded in YIN either as an XML attribute or a subelement of the keyword element. Table 1 defines the encoding for the set of core YANG keywords. For extensions, the argument encoding is specified within the "extension" statement (see Section 7.17). The following rules hold for arguments of both core and extension statements: o If the argument is encoded as an attribute, this attribute has no namespace. o If the argument is encoded as an element, it is placed to the same namespace as its parent keyword element. o If the argument is encoded as an element, it MUST be the first child of the keyword element. Substatements of a YANG statement are encoded as (additional) children of the keyword element and their relative order MUST be the same as the order of substatements in YANG. Comments in YANG MAY be mapped to XML comments. Comments? /martin From andy@netconfcentral.com Sat Feb 28 17:30: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 981323A6846 for ; Sat, 28 Feb 2009 17:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 gZ7tPDTlOnJj for ; Sat, 28 Feb 2009 17:30:17 -0800 (PST) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id B38D13A6993 for ; Sat, 28 Feb 2009 17:30:17 -0800 (PST) Received: from [209.191.108.97] by n15.bullet.mail.mud.yahoo.com with NNFMP; 01 Mar 2009 01:30:41 -0000 Received: from [68.142.201.246] by t4.bullet.mud.yahoo.com with NNFMP; 01 Mar 2009 01:30:41 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 01 Mar 2009 01:30:41 -0000 X-Yahoo-Newman-Id: 829728.63971.bm@omp407.mail.mud.yahoo.com Received: (qmail 85703 invoked from network); 1 Mar 2009 01:30:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.129.49 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 1 Mar 2009 01:30:40 -0000 X-YMail-OSG: 87cres4VM1m6P76Cc1AMCKbeVwchP912.OxXVIXoIGNt1dNc0FJkLBTzTL64suqcWV5KuFk_zkOCPk9jmYHeTFiklTAcMClCzPBIqVN0jj90D4zfTwASOCHePIwKCzZ8VLyuIpUnE_UO7ml1YqwJXn9YlRjf_MzpYfzrowqrJXKvH5EDhD2AAqkvVzqs2g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A9E53F.3020405@netconfcentral.com> Date: Sat, 28 Feb 2009 17:30:39 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <498B8EB9.1060201@netconfcentral.com> <20090209.214608.218111424.mbj@tail-f.com> <200902111134.38359.david.partain@ericsson.com> <20090226.233229.93109353.mbj@tail-f.com> In-Reply-To: <20090226.233229.93109353.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] require-instance error-app-tag X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 01:30:18 -0000 Martin Bjorklund wrote: > David Partain wrote: >> Hi, >> >> On Monday 09 February 2009 21.46.08 Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> There doesn't seem to be any good error codes for a >>>> require-instance = true violation for a leafref or instance-identifier. >>>> Perhaps a new error-app-tag and sub-section of 13.x should be >>>> added to make that stand out, especially since the default >>>> is true. >>> I agree. 'missing-instance' is already used. How about >>> 'instance-required'? >> Seems fine to me. >> >>> What should the error-tag be? >>> 'operation-failed', or could 'data-missing' be used? >> data-missing makes good sense. > > Ok. I have added: > > ** Error Message for Data that Violates a require-instance statement: > > If a NETCONF operation would result in configuration data where an > instance reference marked with require-instance "true" refers to a > non-existing instance, the following error is returned: > > Tag: data-missing > Error-app-tag: instance-required > Add: Error-path: Path to the element with the require-instance statement > > There's also no good error code for the case when a mandatory choice > does not exist. I propose the following text: > > ** Error Message for Data that Violates a mandatory choice statement: > > If a NETCONF operation would result in configuration data where no > nodes exists in a mandatory choice, the following error is returned: > > Tag: data-missing > Error-app-tag: missing-choice > Error-path: Path to the element with the missing choice. > Error-info: : Contains the name of the missing > mandatory choice. > > The element is in the YANG > namespace ("urn:ietf:params:xml:ns:yang:1" > [XXX IANA]). > The element should be a QName not an NCName because another module could augment the node with a choice with the same local name (but in a different namespace). > > /martin Andy