From mbj@tail-f.com Sun Mar 1 03:38: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 B50493A6A35 for ; Sun, 1 Mar 2009 03:38:29 -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 0D0QHkknzoNK for ; Sun, 1 Mar 2009 03:38: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 B2E9D3A6AFB for ; Sun, 1 Mar 2009 03:38: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 6152276C4ED; Sun, 1 Mar 2009 12:38:52 +0100 (CET) Date: Sun, 01 Mar 2009 12:38:51 +0100 (CET) Message-Id: <20090301.123851.163622489.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A9E53F.3020405@netconfcentral.com> References: <200902111134.38359.david.partain@ericsson.com> <20090226.233229.93109353.mbj@tail-f.com> <49A9E53F.3020405@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: Sun, 01 Mar 2009 11:38:29 -0000 Andy Bierman wrote: > 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 Ok. > > 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). Ok. But even if it was a NCName, it would be clear which choice the error referred to, since it's only the local choice that can be mandatory. You cannot add a mandatory choice through augmentation. But a QName is not wrong, and maybe it will cause less confusion. /martin From andy@netconfcentral.com Sun Mar 1 07: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 2F86828C12D for ; Sun, 1 Mar 2009 07:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iKjUzjBlZD5 for ; Sun, 1 Mar 2009 07:56:51 -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 645F828C131 for ; Sun, 1 Mar 2009 07:56:51 -0800 (PST) Received: (qmail 24058 invoked from network); 1 Mar 2009 15:57:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.129.49 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 1 Mar 2009 15:57:15 -0000 X-YMail-OSG: 5Ldik4cVM1miquRjzLAU5gRu_w4ozxSt9MQBME1H.cTg1NPg62ucYZYIDINMFsV56XMaOcdLN9O_AHM.MyIFK6sAWBjm0R5cObbt4zzYB00uy.ipl0n55lQrBQp6gjNBMeRttChfy.UKq5Xf0nDFopIEZCAMFJQCp1bsGS1NSxZFwLb0EMzNIDdSOJaeUw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AAB05A.4050008@netconfcentral.com> Date: Sun, 01 Mar 2009 07:57:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <200902111134.38359.david.partain@ericsson.com> <20090226.233229.93109353.mbj@tail-f.com> <49A9E53F.3020405@netconfcentral.com> <20090301.123851.163622489.mbj@tail-f.com> In-Reply-To: <20090301.123851.163622489.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 15:56:52 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> 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 > > Ok. > >>> 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). > > Ok. But even if it was a NCName, it would be clear which choice the > error referred to, since it's only the local choice that can be > mandatory. You cannot add a mandatory choice through augmentation. > > But a QName is not wrong, and maybe it will cause less confusion. > NCName is OK. I forget that there can only be one of them in this case. > > /martin > > > Andy From david.partain@ericsson.com Mon Mar 2 04:20:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C132A3A6A26 for ; Mon, 2 Mar 2009 04:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=-5.264, BAYES_00=-2.599, FB_NO_MORE_MAIL=10.529, 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 zouOe2+cEap8 for ; Mon, 2 Mar 2009 04:20:20 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F3C623A68D1 for ; Mon, 2 Mar 2009 04:20:19 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 747A4214F5; Mon, 2 Mar 2009 13:20:44 +0100 (CET) X-AuditID: c1b4fb3e-b00a2bb0000023da-cd-49abcf1cb1c5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5C80C21499; Mon, 2 Mar 2009 13:20:44 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:20:43 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:20:43 +0100 From: David Partain Organization: Ericsson AB To: j.schoenwaelder@jacobs-university.de Date: Mon, 2 Mar 2009 13:20:42 +0100 User-Agent: KMail/1.9.10 References: <4984C6A6.6030904@netconfcentral.com> <200902111321.54894.david.partain@ericsson.com> <20090211125717.GB7552@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090211125717.GB7552@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903021320.42424.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Mar 2009 12:20:43.0865 (UTC) FILETIME=[4F0BDC90:01C99B31] X-Brightmail-Tracker: AAAAAA== 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: Mon, 02 Mar 2009 12:20:20 -0000 On Wednesday 11 February 2009 13.57.17 Juergen Schoenwaelder wrote: > 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. Hi, No more mail on this topic, so I assume people agree that putting xpath into yang-types is good and we'll not proceed with qname. Cheers, David From david.partain@ericsson.com Mon Mar 2 04:36: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 035453A6AC3 for ; Mon, 2 Mar 2009 04:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=2.632, 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 8FUxHOjcY4dj for ; Mon, 2 Mar 2009 04:36:41 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E289B3A6991 for ; Mon, 2 Mar 2009 04:36:40 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8AAD820FF4; Mon, 2 Mar 2009 13:37:05 +0100 (CET) X-AuditID: c1b4fb3c-aa804bb000001b43-c8-49abd2f161e3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 729DA20FDE; Mon, 2 Mar 2009 13:37:05 +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, 2 Mar 2009 13:37:03 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:37:03 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 2 Mar 2009 13:37:03 +0100 User-Agent: KMail/1.9.10 References: <49849EA9.5090908@netconfcentral.com> <20090131.210512.120353109.mbj@tail-f.com> <20090227.091556.134897733.mbj@tail-f.com> In-Reply-To: <20090227.091556.134897733.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: <200903021337.03199.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Mar 2009 12:37:03.0810 (UTC) FILETIME=[97239A20:01C99B33] X-Brightmail-Tracker: AAAAAA== 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: Mon, 02 Mar 2009 12:36:42 -0000 On Friday 27 February 2009 09.15.56 Martin Bjorklund wrote: > 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. Looks good to me. David From david.partain@ericsson.com Mon Mar 2 04:53:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DC43A68AF for ; Mon, 2 Mar 2009 04:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[AWL=1.755, 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 HNskdsC6jF-F for ; Mon, 2 Mar 2009 04:53:00 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 851EA3A67A7 for ; Mon, 2 Mar 2009 04:52:55 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3B0FE21541 for ; Mon, 2 Mar 2009 13:52:29 +0100 (CET) X-AuditID: c1b4fb3e-ae89fbb0000023da-38-49abd68d47d0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2642E20582 for ; Mon, 2 Mar 2009 13:52:29 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:52:28 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:52:27 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 2 Mar 2009 13:52:26 +0100 User-Agent: KMail/1.9.10 References: <200902121814.n1CIEitQ072382@idle.juniper.net> <20090212.205100.62765552.mbj@tail-f.com> <4994841A.2020007@netconfcentral.com> In-Reply-To: <4994841A.2020007@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903021352.26715.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Mar 2009 12:52:27.0894 (UTC) FILETIME=[BDEFA160:01C99B35] X-Brightmail-Tracker: AAAAAA== 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: Mon, 02 Mar 2009 12:53:00 -0000 On Thursday 12 February 2009 21.18.34 Andy Bierman wrote: > 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. Hi, After reading through this thread (again), it appears to me that the protagonists in the discussion are happy (or at least silent). Seems to me we can put this one to bed. David From mbj@tail-f.com Mon Mar 2 05:09: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 BCF543A6BA1 for ; Mon, 2 Mar 2009 05:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.131, 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 ars5mUrB+Qr4 for ; Mon, 2 Mar 2009 05:09: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 B959E3A6879 for ; Mon, 2 Mar 2009 05:09:19 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9070A76C50A; Mon, 2 Mar 2009 14:09:44 +0100 (CET) Date: Mon, 02 Mar 2009 14:09:44 +0100 (CET) Message-Id: <20090302.140944.170537152.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200903021352.26715.david.partain@ericsson.com> References: <20090212.205100.62765552.mbj@tail-f.com> <4994841A.2020007@netconfcentral.com> <200903021352.26715.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] 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: Mon, 02 Mar 2009 13:09:20 -0000 David Partain wrote: > On Thursday 12 February 2009 21.18.34 Andy Bierman wrote: > > 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. > > Hi, > > After reading through this thread (again), it appears to me that the > protagonists in the discussion are happy (or at least silent). Seems to me > we can put this one to bed. I have rewritten this list according to what I proposed, and what Andy said was fine, and noone objected to. I hope that was what you meant? /martin From david.partain@ericsson.com Mon Mar 2 05:38:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD58B3A6908 for ; Mon, 2 Mar 2009 05:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.933 X-Spam-Level: X-Spam-Status: No, score=-4.933 tagged_above=-999 required=5 tests=[AWL=1.316, 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 P6-QPT2n+ZnV for ; Mon, 2 Mar 2009 05:38:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D6AB53A682A for ; Mon, 2 Mar 2009 05:38:52 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D85202032F; Mon, 2 Mar 2009 14:39:04 +0100 (CET) X-AuditID: c1b4fb3e-ad09cbb0000023da-b4-49abe1789176 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BAA0320244; Mon, 2 Mar 2009 14:39:04 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 14:39:03 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 14:39:03 +0100 From: David Partain Organization: Ericsson AB To: Martin Bjorklund Date: Mon, 2 Mar 2009 14:39:02 +0100 User-Agent: KMail/1.9.10 References: <20090212.205100.62765552.mbj@tail-f.com> <200903021352.26715.david.partain@ericsson.com> <20090302.140944.170537152.mbj@tail-f.com> In-Reply-To: <20090302.140944.170537152.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: <200903021439.02920.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Mar 2009 13:39:03.0073 (UTC) FILETIME=[3FFE1910:01C99B3C] X-Brightmail-Tracker: AAAAAA== 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: Mon, 02 Mar 2009 13:38:53 -0000 Hi, > > After reading through this thread (again), it appears to me that the > > protagonists in the discussion are happy (or at least silent). Seems to > > me we can put this one to bed. > > I have rewritten this list according to what I proposed, and what Andy > said was fine, and noone objected to. I hope that was what you meant? Yep, that's what I meant. There was other discussion (particularly between Phil and Andy) that didn't result in textual changes and I simply wanted to make sure that weren't any expected changes _other_ than what you put in http://www.ietf.org/mail-archive/web/netmod/current/msg02098.html Cheers, David From david.partain@ericsson.com Mon Mar 2 06:01: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 5EFC13A69AA for ; Mon, 2 Mar 2009 06:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.596 X-Spam-Level: X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 tGm4NEUzUJhZ for ; Mon, 2 Mar 2009 06:01:35 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4B3A23A6905 for ; Mon, 2 Mar 2009 06:01:35 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1F6F721573; Mon, 2 Mar 2009 15:02:00 +0100 (CET) X-AuditID: c1b4fb3e-ae09ebb0000023da-a3-49abe6d8a78e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 020E82156B; Mon, 2 Mar 2009 15:02:00 +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, 2 Mar 2009 15:01:59 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 15:01:59 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 2 Mar 2009 15:01:58 +0100 User-Agent: KMail/1.9.10 References: <20081218161352.GC6703@elstar.local> <20090205221331.GD3320@elstar.iuhb02.iu-bremen.de> <498B6764.9010305@tail-f.com> In-Reply-To: <498B6764.9010305@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903021501.59022.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Mar 2009 14:01:59.0513 (UTC) FILETIME=[746A2C90:01C99B3F] X-Brightmail-Tracker: AAAAAA== 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: Mon, 02 Mar 2009 14:01:36 -0000 On Thursday 05 February 2009 23.25.40 Per Hedeland wrote: > 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 =3D> 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 !=3D -1 && best.len < 2) > > best.base =3D -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: [deleted] So... to close this out...=20 J=FCrgen, you haven't gotten a win32 datapoint, but do you have enough data= to=20 make a suggestion about what the right text should be? =20 David From j.schoenwaelder@jacobs-university.de Mon Mar 2 06:29: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 879EF3A689C for ; Mon, 2 Mar 2009 06:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UFA0A7O0zf7n for ; Mon, 2 Mar 2009 06:29:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3D4653A6A66 for ; Mon, 2 Mar 2009 06:29:26 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBF80C0013; Mon, 2 Mar 2009 15:29:51 +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 JidCyeklh2Wh; Mon, 2 Mar 2009 15:29:45 +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 9C35DC0020; Mon, 2 Mar 2009 15:29:45 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 90DE29D2D21; Mon, 2 Mar 2009 15:29:44 +0100 (CET) Date: Mon, 2 Mar 2009 15:29:44 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20090302142944.GA29695@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Partain , netmod@ietf.org, Per Hedeland References: <20081218161352.GC6703@elstar.local> <20090205221331.GD3320@elstar.iuhb02.iu-bremen.de> <498B6764.9010305@tail-f.com> <200903021501.59022.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903021501.59022.david.partain@ericsson.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: Mon, 02 Mar 2009 14:29:43 -0000 On Mon, Mar 02, 2009 at 03:01:58PM +0100, David Partain wrote: > J?rgen, you haven't gotten a win32 datapoint, but do you have enough > data to make a suggestion about what the right text should be? There have been split opinions and it is hard to read concensus. The options: a) Use the preferred form defined in 1. in section 2.2 or RFC 4291, (with supression of leading zeros), which means no compression of 16-bit zeros. Since a Draft Standard RFC says this is the preferred format, there is a strong argument in place for choosing this option. b) Use the popular CLI form with compressed zeros. Since existing inet_ntop() implementations obviously do slightly different things on different systems, we have to make up rules and since implementors can't rely on inet_ntop() always doing the right thing, you have to support your own function if your goal is portable code. I personally meanwhile lean towards option a) since this is an easy to defend format, it is easy to document, and it does not take more effort to implement than option b). Unless I hear objections, I will put this solution into the next revision of the ID. /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 Mar 2 15:23: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 0569A28C2AB for ; Mon, 2 Mar 2009 15:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUnsKwyhKSSA for ; Mon, 2 Mar 2009 15:23:13 -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 51A1028C24C for ; Mon, 2 Mar 2009 15:23:13 -0800 (PST) Received: (qmail 97890 invoked from network); 2 Mar 2009 23:23:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 23:23:39 -0000 X-YMail-OSG: QqBAtNkVM1keXUGhn7MgDzghadNXHuE9p5vcXUkadT3od2jjJtZK.NW8Unz3x0MM0.4N4xXJyw.Q0mxmhm1PJF26leJapufakMlQFLb3SeI0kjz7zOXV.9A4t1Mp1Cj_7Fh2RAaQTHRYf5Id73oIvfC4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC6A79.4040201@netconfcentral.com> Date: Mon, 02 Mar 2009 15:23:37 -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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 23:23:14 -0000 Hi, The draft does not seem to contain any CLR prohibiting multiple deviation statements from referencing the same target. Good. This is not easy to enforce, since the statements can be in any module (like an augment). Also, it is OK (e.g.) for 1 deviations module to add a default-stmt, and another to change the mandatory-stmt in the same object. Unlike an augment protected by separate namespaces, there is just one target object. So it is clearly an error if any of the deviate-stmts step on each other (e.g., 1 removes the default, 1 replaces the default). All the deviate-stmts need to be gathered from all the deviation-stmts with the same target and validated as a group (except the compiler won't know about deviations from modules not imported). The draft should mention something about this. It only contains the requirements for one deviation statement applied to one object. Andy From david.kessens@nsn.com Mon Mar 2 16:24: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 D619528C205 for ; Mon, 2 Mar 2009 16:24:14 -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 amvMR-au60Or for ; Mon, 2 Mar 2009 16:24:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AE75028C207 for ; Mon, 2 Mar 2009 16:23:07 -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 n230NTCf005817 for ; Mon, 2 Mar 2009 18:23:32 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 02:23:28 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 02:23:28 +0200 Received: from localhost.localdomain ([10.241.59.166]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 02:23:26 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n230NNfb000424 for ; Mon, 2 Mar 2009 16:23:23 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n230NNIZ000423 for netmod@ietf.org; Mon, 2 Mar 2009 16:23:23 -0800 Date: Mon, 2 Mar 2009 16:23:23 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20090303002323.GD8729@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: 03 Mar 2009 00:23:27.0758 (UTC) FILETIME=[45F0D2E0:01C99B96] X-Nokia-AV: Clean Subject: [netmod] Call for agenda topics San Francisco 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: Tue, 03 Mar 2009 00:24:15 -0000 We have started working on an agenda for the San Francisco IETF netmod working group sessions. It is now the right time to suggest agenda topics as we would like to get a draft agenda out as soon as possible. For your information, we are currently tentatively scheduled for: MONDAY, March 23, 2009, 1740-1940, Breakout 4 & WEDNESDAY, March 25, 2009, 0900-1015, Breakout 4 However, we would like to emphasize that the agenda schedule is still subject to change. David Kessens & David Partain --- From david.partain@ericsson.com Tue Mar 3 01:03: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 893093A6A7B for ; Tue, 3 Mar 2009 01:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.972 X-Spam-Level: X-Spam-Status: No, score=-4.972 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 P92uHBFRX6eG for ; Tue, 3 Mar 2009 01:03:14 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6891A3A68A1 for ; Tue, 3 Mar 2009 01:03:14 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE11A209F9 for ; Tue, 3 Mar 2009 10:03:39 +0100 (CET) X-AuditID: c1b4fb3c-ab005bb000001b43-55-49acf26b2960 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C5BAB204A1 for ; Tue, 3 Mar 2009 10:03:39 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 10:03:29 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 10:03:29 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 3 Mar 2009 10:03:28 +0100 User-Agent: KMail/1.9.10 References: <20081218161352.GC6703@elstar.local> <200903021501.59022.david.partain@ericsson.com> <20090302142944.GA29695@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090302142944.GA29695@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903031003.28739.david.partain@ericsson.com> X-OriginalArrivalTime: 03 Mar 2009 09:03:29.0242 (UTC) FILETIME=[EB7973A0:01C99BDE] X-Brightmail-Tracker: AAAAAA== 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: Tue, 03 Mar 2009 09:03:15 -0000 On Monday 02 March 2009 15.29.44 Juergen Schoenwaelder wrote: > On Mon, Mar 02, 2009 at 03:01:58PM +0100, David Partain wrote: > > J?rgen, you haven't gotten a win32 datapoint, but do you have enough > > data to make a suggestion about what the right text should be? > > There have been split opinions and it is hard to read concensus. The > options: > > a) Use the preferred form defined in 1. in section 2.2 or RFC 4291, > (with supression of leading zeros), which means no compression of > 16-bit zeros. Since a Draft Standard RFC says this is the preferred > format, there is a strong argument in place for choosing this > option. > > b) Use the popular CLI form with compressed zeros. Since existing > inet_ntop() implementations obviously do slightly different things > on different systems, we have to make up rules and since > implementors can't rely on inet_ntop() always doing the right > thing, you have to support your own function if your goal is > portable code. > > I personally meanwhile lean towards option a) since this is an easy to > defend format, it is easy to document, and it does not take more > effort to implement than option b). > > Unless I hear objections, I will put this solution into the next > revision of the ID. Hi, I think that option a makes good sense, especially given "it does not take more effort to implement than option b)". I would, though, like others to chime in on this way forward. Cheers, David From lhotka@cesnet.cz Tue Mar 3 01:09: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 D477D3A6930 for ; Tue, 3 Mar 2009 01:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 nmBSKazogL0C for ; Tue, 3 Mar 2009 01:09:08 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D5B763A6985 for ; Tue, 3 Mar 2009 01:08:39 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6CC1DD800F1 for ; Tue, 3 Mar 2009 10:09:06 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200903031003.28739.david.partain@ericsson.com> References: <20081218161352.GC6703@elstar.local> <200903021501.59022.david.partain@ericsson.com> <20090302142944.GA29695@elstar.iuhb02.iu-bremen.de> <200903031003.28739.david.partain@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 03 Mar 2009 10:09:06 +0100 Message-Id: <1236071346.7081.1.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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: Tue, 03 Mar 2009 09:09:08 -0000 Hi David, I support a) too, but you said "Unless I hear objections ...". :-) Lada David Partain píše v Út 03. 03. 2009 v 10:03 +0100: > On Monday 02 March 2009 15.29.44 Juergen Schoenwaelder wrote: > > On Mon, Mar 02, 2009 at 03:01:58PM +0100, David Partain wrote: > > > J?rgen, you haven't gotten a win32 datapoint, but do you have enough > > > data to make a suggestion about what the right text should be? > > > > There have been split opinions and it is hard to read concensus. The > > options: > > > > a) Use the preferred form defined in 1. in section 2.2 or RFC 4291, > > (with supression of leading zeros), which means no compression of > > 16-bit zeros. Since a Draft Standard RFC says this is the preferred > > format, there is a strong argument in place for choosing this > > option. > > > > b) Use the popular CLI form with compressed zeros. Since existing > > inet_ntop() implementations obviously do slightly different things > > on different systems, we have to make up rules and since > > implementors can't rely on inet_ntop() always doing the right > > thing, you have to support your own function if your goal is > > portable code. > > > > I personally meanwhile lean towards option a) since this is an easy to > > defend format, it is easy to document, and it does not take more > > effort to implement than option b). > > > > Unless I hear objections, I will put this solution into the next > > revision of the ID. > > Hi, > > I think that option a makes good sense, especially given "it does not take > more effort to implement than option b)". I would, though, like others to > chime in on this way forward. > > Cheers, > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Mar 3 02:52:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69F428C0F2 for ; Tue, 3 Mar 2009 02:52:12 -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 2eU7qoLROz7x for ; Tue, 3 Mar 2009 02:52:12 -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 0EF2A3A6856 for ; Tue, 3 Mar 2009 02:52:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C1A676C4ED; Tue, 3 Mar 2009 11:52:37 +0100 (CET) Date: Tue, 03 Mar 2009 11:52:37 +0100 (CET) Message-Id: <20090303.115237.175208768.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AC6A79.4040201@netconfcentral.com> References: <49AC6A79.4040201@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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:52:12 -0000 Andy Bierman wrote: > Hi, > > The draft does not seem to contain any CLR prohibiting > multiple deviation statements from referencing the > same target. Good. This is not easy to enforce, since the > statements can be in any module (like an augment). > Also, it is OK (e.g.) for 1 deviations module to add a default-stmt, > and another to change the mandatory-stmt in the same object. > > Unlike an augment protected by separate namespaces, > there is just one target object. So it is clearly an error > if any of the deviate-stmts step on each other (e.g., > 1 removes the default, 1 replaces the default). Is it an error if two deviate-stmts both replace the default? If not, which one wins? If this is an error, the implementation has to collect and analyze all deviation statement as one group (that's probably what you just wrote...) If this is what we want, I can add to "The deviation Statement": A target node may be deviated by multiple deviation statements, possibly defined in multiple modules. and to "The deviate Statement": It is an error if the same property of a particular target node is deviated in more than one "deviate" statement in all modules supported by a device. /martin From andy@netconfcentral.com Tue Mar 3 04:34:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2975728C297 for ; Tue, 3 Mar 2009 04:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.017, 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 geD6SfgIvB77 for ; Tue, 3 Mar 2009 04:34:49 -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 6B95E28C263 for ; Tue, 3 Mar 2009 04:34:49 -0800 (PST) Received: (qmail 9236 invoked from network); 3 Mar 2009 12:35:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 12:35:16 -0000 X-YMail-OSG: 3dEYC.0VM1kLHbAYNLmK7I71isNEoFE3iHAWjTzcYQ0UnMR__mEpo_EfoQUt1Y3Icq2vVqd3lpVW7MGBRPp._uIysCKkpVFRozaLnMa2NqJOuAR8NkDHTWFbzPbSEuqFaXAdzB3DxjU1Psq1OT.b0KbtojaQeLQ7O9_MqWP4kWKw4viXBJ_D_8cBlguz1Fm_zv5FFqxRid.AFezhm5ApRA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD2402.2010508@netconfcentral.com> Date: Tue, 03 Mar 2009 04:35:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49AC6A79.4040201@netconfcentral.com> <20090303.115237.175208768.mbj@tail-f.com> In-Reply-To: <20090303.115237.175208768.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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 12:34:50 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The draft does not seem to contain any CLR prohibiting >> multiple deviation statements from referencing the >> same target. Good. This is not easy to enforce, since the >> statements can be in any module (like an augment). >> Also, it is OK (e.g.) for 1 deviations module to add a default-stmt, >> and another to change the mandatory-stmt in the same object. >> >> Unlike an augment protected by separate namespaces, >> there is just one target object. So it is clearly an error >> if any of the deviate-stmts step on each other (e.g., >> 1 removes the default, 1 replaces the default). > > Is it an error if two deviate-stmts both replace the default? If not, > which one wins? If this is an error, the implementation has to collect > and analyze all deviation statement as one group (that's probably what > you just wrote...) > > If this is what we want, I can add to "The deviation Statement": > > A target node may be deviated by multiple deviation statements, > possibly defined in multiple modules. > > and to "The deviate Statement": > > It is an error if the same property of a particular target node is > deviated in more than one "deviate" statement in all modules > supported by a device. > I have run into problems when 1 deviate-stmt replaces the type-stmt and another one (possibly in another deviation-stmt) replaces the default-stmt. Do you validate the old default-stmt against the new type? Do you validate the new default-stmt against the old type? Or just the new default-stmt against the new type, assuming you can find both of them at once? Maybe the 1 deviation-stmt per target rule is a simpler CLR. > > /martin > > Andy From lhotka@cesnet.cz Tue Mar 3 05:23: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 A59F83A6A31 for ; Tue, 3 Mar 2009 05:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIUMicFuv+Tq for ; Tue, 3 Mar 2009 05:23:11 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DBB273A69BF for ; Tue, 3 Mar 2009 05:23:10 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 20FE9D800F5 for ; Tue, 3 Mar 2009 14:23:37 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Tue, 03 Mar 2009 14:23:37 +0100 Message-Id: <1236086617.7081.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] choice/config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 13:23:11 -0000 Hi, section 7.19.1 doesn't address the case when "config" is a substatement of choice. This could be added as a second paragraph in this section: As a substatement of "choice", the "config" statement applies to all data nodes in all cases of the "choice" statement. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Tue Mar 3 09:30:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EC0573A6BAF; Tue, 3 Mar 2009 09:30: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: <20090303173001.EC0573A6BAF@core3.amsl.com> Date: Tue, 3 Mar 2009 09:30:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-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: Tue, 03 Mar 2009 17:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : An Architecture for Network Management Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-00.txt Pages : 21 Date : 2009-03-03 NETCONF and YANG are pieces of an ambitious plan to improve network management. NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content trafficked via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network services providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-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-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-03091919.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Tue Mar 3 13: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 079C83A6996 for ; Tue, 3 Mar 2009 13:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.101, 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 N1cLQT7rgpMc for ; Tue, 3 Mar 2009 13:38: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 1CEC03A680E for ; Tue, 3 Mar 2009 13:38:14 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4983276C4D7; Tue, 3 Mar 2009 22:38:41 +0100 (CET) Date: Tue, 03 Mar 2009 22:38:40 +0100 (CET) Message-Id: <20090303.223840.84553442.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AD2402.2010508@netconfcentral.com> References: <49AC6A79.4040201@netconfcentral.com> <20090303.115237.175208768.mbj@tail-f.com> <49AD2402.2010508@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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 21:38:16 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> The draft does not seem to contain any CLR prohibiting > >> multiple deviation statements from referencing the > >> same target. Good. This is not easy to enforce, since the > >> statements can be in any module (like an augment). > >> Also, it is OK (e.g.) for 1 deviations module to add a default-stmt, > >> and another to change the mandatory-stmt in the same object. > >> > >> Unlike an augment protected by separate namespaces, > >> there is just one target object. So it is clearly an error > >> if any of the deviate-stmts step on each other (e.g., > >> 1 removes the default, 1 replaces the default). > > Is it an error if two deviate-stmts both replace the default? If not, > > which one wins? If this is an error, the implementation has to collect > > and analyze all deviation statement as one group (that's probably what > > you just wrote...) > > If this is what we want, I can add to "The deviation Statement": > > A target node may be deviated by multiple deviation statements, > > possibly defined in multiple modules. > > and to "The deviate Statement": > > It is an error if the same property of a particular target node is > > deviated in more than one "deviate" statement in all modules > > supported by a device. > > > > I have run into problems when 1 deviate-stmt replaces the type-stmt > and another one (possibly in another deviation-stmt) > replaces the default-stmt. > > Do you validate the old default-stmt against the new type? > Do you validate the new default-stmt against the old type? > Or just the new default-stmt against the new type, assuming you can > find both of them at once? > > Maybe the 1 deviation-stmt per target rule is a simpler CLR. Yes, I think it is. Is this text ok for the CLR: It is an error if a target node is deviated by more than "deviation" statement in all modules supported by a device. /martin From lhotka@cesnet.cz Tue Mar 3 13:55: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 6682228C15F for ; Tue, 3 Mar 2009 13:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8eFkiS2Bjtl for ; Tue, 3 Mar 2009 13:55:57 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AE81528C158 for ; Tue, 3 Mar 2009 13:55:57 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id EA5C4D800C5 for ; Tue, 3 Mar 2009 22:56:24 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Tue, 03 Mar 2009 22:56:26 +0100 Message-Id: <1236117386.7081.59.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] prefixed keys? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 21:55:58 -0000 Hi, "key" and "unique" are quite similar but differ in that the keys cannot have the local module prefix while "unique" argumenst can. How about allowing prefixes for keys as well? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Mar 3 18:32: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 3E4793A6B42 for ; Tue, 3 Mar 2009 18:32:15 -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.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4x+Ytx+4QRX for ; Tue, 3 Mar 2009 18:32:14 -0800 (PST) Received: from n13a.bullet.mail.mud.yahoo.com (n13a.bullet.mail.mud.yahoo.com [68.142.207.51]) by core3.amsl.com (Postfix) with SMTP id 4F7823A6AB7 for ; Tue, 3 Mar 2009 18:32:14 -0800 (PST) Received: from [68.142.194.244] by n13.bullet.mail.mud.yahoo.com with NNFMP; 04 Mar 2009 02:32:42 -0000 Received: from [68.142.201.67] by t2.bullet.mud.yahoo.com with NNFMP; 04 Mar 2009 02:32:42 -0000 Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 04 Mar 2009 02:32:42 -0000 X-Yahoo-Newman-Id: 64846.86136.bm@omp419.mail.mud.yahoo.com Received: (qmail 23626 invoked from network); 4 Mar 2009 02:32:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.82.123 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 4 Mar 2009 02:32:40 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49ADE846.407@netconfcentral.com> Date: Tue, 03 Mar 2009 18:32:38 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49AC6A79.4040201@netconfcentral.com> <20090303.115237.175208768.mbj@tail-f.com> <49AD2402.2010508@netconfcentral.com> In-Reply-To: <49AD2402.2010508@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 02:32:15 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> The draft does not seem to contain any CLR prohibiting >>> multiple deviation statements from referencing the >>> same target. Good. This is not easy to enforce, since the >>> statements can be in any module (like an augment). >>> Also, it is OK (e.g.) for 1 deviations module to add a default-stmt, >>> and another to change the mandatory-stmt in the same object. >>> >>> Unlike an augment protected by separate namespaces, >>> there is just one target object. So it is clearly an error >>> if any of the deviate-stmts step on each other (e.g., >>> 1 removes the default, 1 replaces the default). >> >> Is it an error if two deviate-stmts both replace the default? If not, >> which one wins? If this is an error, the implementation has to collect >> and analyze all deviation statement as one group (that's probably what >> you just wrote...) >> >> If this is what we want, I can add to "The deviation Statement": >> >> A target node may be deviated by multiple deviation statements, >> possibly defined in multiple modules. >> >> and to "The deviate Statement": >> >> It is an error if the same property of a particular target node is >> deviated in more than one "deviate" statement in all modules >> supported by a device. >> > > I have run into problems when 1 deviate-stmt replaces the type-stmt > and another one (possibly in another deviation-stmt) > replaces the default-stmt. > > Do you validate the old default-stmt against the new type? > Do you validate the new default-stmt against the old type? > Or just the new default-stmt against the new type, assuming you can > find both of them at once? > > Maybe the 1 deviation-stmt per target rule is a simpler CLR. > I don't think this CLR is really needed. The important factor is that the validation tool must be aware of all the deviation statements for a particular object. That is done in an implementation-specific manner (similar to constructing the module capability URI). My only hypothetical use-case is a vendor that has an existing application for generating deviations, but only for some things, like changing the default-stmts. If any platform engineer needs to tweak a different sub-clause for any object that the 'defaults' app already altered, then this CLR will prevent them from doing that. (BTW, this platform engineer does not have ownership of the defaults app, so changing that code is not an option.) >> >> /martin >> >> > > Andy > Andy From lhotka@cesnet.cz Tue Mar 3 23:49:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930AE28C313 for ; Tue, 3 Mar 2009 23:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=-0.447, 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 4CrBPWK+60rp for ; Tue, 3 Mar 2009 23:49:16 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B31F428C274 for ; Tue, 3 Mar 2009 23:49:16 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 26678D800C0 for ; Wed, 4 Mar 2009 08:49:44 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Wed, 04 Mar 2009 08:49:43 +0100 Message-Id: <1236152983.6437.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 07:49:17 -0000 Hi, what happens if a leaf which is included in "unique" statement is optional and has no default? Two interesting cases: 1. The leaf is not present in two or more list items. 2. It is present in one item and absent in another For the purpose of uniqueness check, in 1 the (missing) leafs should be considered equal and in 2 distinct. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Mar 4 00:33: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 033A33A6B96 for ; Wed, 4 Mar 2009 00:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.123, 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 u+HeKhfdO-CS for ; Wed, 4 Mar 2009 00:33:11 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2E99B3A6B8B for ; Wed, 4 Mar 2009 00:33:11 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0EB5376C4E6; Wed, 4 Mar 2009 09:33:38 +0100 (CET) Date: Wed, 04 Mar 2009 09:33:37 +0100 (CET) Message-Id: <20090304.093337.125935841.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1236152983.6437.13.camel@missotis> References: <1236152983.6437.13.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] unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 08:33:13 -0000 Ladislav Lhotka wrote: > Hi, > > what happens if a leaf which is included in "unique" statement is > optional and has no default? Two interesting cases: > > 1. The leaf is not present in two or more list items. > 2. It is present in one item and absent in another > > For the purpose of uniqueness check, in 1 the (missing) leafs should be > considered equal and in 2 distinct. See the thread 'unique-stmt', from a couple of weeks ago. The idea is that instances that are missing some optional leafs are not checked for uniqueness. I will add text according to the discussion in that thread to -04 (which will be submitted this week). /martin From mbj@tail-f.com Wed Mar 4 00:39:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23783A6AF3 for ; Wed, 4 Mar 2009 00:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.116, 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 e5FmA-paNyQs for ; Wed, 4 Mar 2009 00:39:26 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EC9B63A6A48 for ; Wed, 4 Mar 2009 00:39:25 -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 8B0AC76C4E6; Wed, 4 Mar 2009 09:39:53 +0100 (CET) Date: Wed, 04 Mar 2009 09:39:53 +0100 (CET) Message-Id: <20090304.093953.05473739.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49ADE846.407@netconfcentral.com> References: <20090303.115237.175208768.mbj@tail-f.com> <49AD2402.2010508@netconfcentral.com> <49ADE846.407@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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 08:39:26 -0000 Andy Bierman wrote: > I don't think this CLR is really needed. Just to be clear - do you think that the current text is fine, or do we need to add anything? /martin From lhotka@cesnet.cz Wed Mar 4 01:05: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 916AC28C360 for ; Wed, 4 Mar 2009 01:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=0.313, 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 RijQZNG0hEPY for ; Wed, 4 Mar 2009 01:05:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9387128C355 for ; Wed, 4 Mar 2009 01:05:15 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 711CFD800C5; Wed, 4 Mar 2009 10:05:43 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090304.093337.125935841.mbj@tail-f.com> References: <1236152983.6437.13.camel@missotis> <20090304.093337.125935841.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 04 Mar 2009 10:05:42 +0100 Message-Id: <1236157543.6437.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 09:05:16 -0000 Martin Bjorklund píše v St 04. 03. 2009 v 09:33 +0100: > Ladislav Lhotka wrote: > > Hi, > > > > what happens if a leaf which is included in "unique" statement is > > optional and has no default? Two interesting cases: > > > > 1. The leaf is not present in two or more list items. > > 2. It is present in one item and absent in another > > > > For the purpose of uniqueness check, in 1 the (missing) leafs should be > > considered equal and in 2 distinct. > > See the thread 'unique-stmt', from a couple of weeks ago. Sorry, I forgot about that. > > The idea is that instances that are missing some optional leafs are > not checked for uniqueness. Does it mean that (1) the "unique" statement is entirely ignored or that (2) only those list entries that have the full tuple are taken into account? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Mar 4 01:06: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 F04D728C355 for ; Wed, 4 Mar 2009 01:06:54 -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 WLe8JfI8hefG for ; Wed, 4 Mar 2009 01:06:54 -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 32FA628C340 for ; Wed, 4 Mar 2009 01:06:54 -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 CC7CB76C4E6; Wed, 4 Mar 2009 10:07:21 +0100 (CET) Date: Wed, 04 Mar 2009 10:07:21 +0100 (CET) Message-Id: <20090304.100721.104280637.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1236157543.6437.21.camel@missotis> References: <1236152983.6437.13.camel@missotis> <20090304.093337.125935841.mbj@tail-f.com> <1236157543.6437.21.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] unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 09:06:55 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAwNC4gMDMuIDIwMDkgdiAwOTozMyArMDEwMDoNCj4gPiBUaGUgaWRl YSBpcyB0aGF0IGluc3RhbmNlcyB0aGF0IGFyZSBtaXNzaW5nIHNvbWUgb3B0aW9uYWwgbGVhZnMg YXJlDQo+ID4gbm90IGNoZWNrZWQgZm9yIHVuaXF1ZW5lc3MuDQo+IA0KPiBEb2VzIGl0IG1lYW4g dGhhdCAoMSkgdGhlICJ1bmlxdWUiIHN0YXRlbWVudCBpcyBlbnRpcmVseSBpZ25vcmVkIG9yIHRo YXQNCj4gKDIpIG9ubHkgdGhvc2UgbGlzdCBlbnRyaWVzIHRoYXQgaGF2ZSB0aGUgZnVsbCB0dXBs ZSBhcmUgdGFrZW4gaW50bw0KPiBhY2NvdW50Pw0KDQpJdCBtZWFucyAoMikuDQoNCg0KL21hcnRp bg0K From andy@netconfcentral.com Wed Mar 4 06:50: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 03E2D28C36F for ; Wed, 4 Mar 2009 06:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 a0AtYjgonI1v for ; Wed, 4 Mar 2009 06:50:08 -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 BC21128C34F for ; Wed, 4 Mar 2009 06:50:07 -0800 (PST) Received: from [209.191.108.97] by n27.bullet.mail.mud.yahoo.com with NNFMP; 04 Mar 2009 14:50:36 -0000 Received: from [68.142.201.242] by t4.bullet.mud.yahoo.com with NNFMP; 04 Mar 2009 14:50:36 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 04 Mar 2009 14:50:35 -0000 X-Yahoo-Newman-Id: 984236.69620.bm@omp403.mail.mud.yahoo.com Received: (qmail 13907 invoked from network); 4 Mar 2009 14:50:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.82.123 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 4 Mar 2009 14:50:35 -0000 X-YMail-OSG: _CdTDKAVM1ktATdmLQxQWQkMCT67m3JrYdpZDbXTYhCykItd.CzKJKuWN_d27ZY7dlZoJTzaLhawiFfgSOGK4bLbZQlP9Ba2APoCeKsmYhtjttQx36i79u_e9Qcj0gNqNr1SQdodfKQ_bfqPcUdlMhI16L8vWz9echvnxj7nDi_sN82g9sT0SIw5_yLJSr5I_VMFSRXffF55rdU8grazvQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AE9539.3070606@netconfcentral.com> Date: Wed, 04 Mar 2009 06:50:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090303.115237.175208768.mbj@tail-f.com> <49AD2402.2010508@netconfcentral.com> <49ADE846.407@netconfcentral.com> <20090304.093953.05473739.mbj@tail-f.com> In-Reply-To: <20090304.093953.05473739.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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:50:09 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I don't think this CLR is really needed. > > Just to be clear - do you think that the current text is fine, or do > we need to add anything? > I can't think of any normative text for this issue. Here are some CLRs that fall out of the syntax: - a key leaf cannot be changed to 'not-supported' - a key leaf cannot be changed from config true to false - a leaf within the default case for a choice cannot be changed from mandatory false to true - the text says an exact match is needed for the boolean clauses (e.g., mandatory) but this is useless because the property is probably derived from its parent instead of with an explicit clause. You need to ignore that text to implementation deviations correctly. - exact match on unique and must statements are error-prone because they include whitespace (too bad) It does no good to validate individual deviate-stmts against the target object since other deviate-stmts may be required to make the altered object valid YANG. (e.g, many pairs like type/default, mandatory/default, min-elements/max-elements). It is not clear if an implementation is allowed to reject deviations because (when processed serially) the composite object is invalid (e.g, add mandatory true and remove default 7; this is an error in this order, but OK in the reverse order.) I do not see much upside in checking for all the corner cases. There are dozens of them to worry about. I am much more inclined to force the data modeler to construct the deviation-stmts in the correct order, and apply the deviate-stmts in the order they were entered in the YANG file. Open Issue: Is there a standard processing model for validating and applying deviations, or should the current approach remain, which is that implementations can do whatever they want? > > /martin > > Andy From andy@netconfcentral.com Wed Mar 4 08:48: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 B991F3A69A7 for ; Wed, 4 Mar 2009 08:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 Aom0mU4oxUVR for ; Wed, 4 Mar 2009 08:48:44 -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 72B8A28C330 for ; Wed, 4 Mar 2009 08:48:08 -0800 (PST) Received: (qmail 94791 invoked from network); 4 Mar 2009 16:48:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.82.123 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 4 Mar 2009 16:48:36 -0000 X-YMail-OSG: QdKCOwUVM1muKdiHU2VIVu4nCMji4kDpVKPLAQ1Du8raL57fwO5A_gd3q0GpyBrAN5nAUvA6mXKfSg9m2i2w01c59VFwSmqb2K6inbbwe0EeYVckLc6iZAE6saFjYcJXGux4QkfjtyI2DeFv.yWZT.3i X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AEB0E3.6030809@netconfcentral.com> Date: Wed, 04 Mar 2009 08:48:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1236117386.7081.59.camel@missotis> In-Reply-To: <1236117386.7081.59.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] prefixed keys? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:48:44 -0000 Ladislav Lhotka wrote: > Hi, > > "key" and "unique" are quite similar but differ in that the keys cannot > have the local module prefix while "unique" argumenst can. How about > allowing prefixes for keys as well? > this is OK with me. It is confusing to users if the local prefix is not allowed here, even though there are no other possible namespaces except the local module to use. > Lada > Andy From mbj@tail-f.com Wed Mar 4 09: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 049D73A693D for ; Wed, 4 Mar 2009 09:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.098, 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 4ODCJ5U1fv2D for ; Wed, 4 Mar 2009 09:08: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 2F4A23A6916 for ; Wed, 4 Mar 2009 09:08:10 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 471AB76C4E6; Wed, 4 Mar 2009 18:08:37 +0100 (CET) Date: Wed, 04 Mar 2009 18:08:37 +0100 (CET) Message-Id: <20090304.180837.183665397.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AEB0E3.6030809@netconfcentral.com> References: <1236117386.7081.59.camel@missotis> <49AEB0E3.6030809@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] prefixed keys? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 17:08:11 -0000 Andy Bierman wrote: > Ladislav Lhotka wrote: > > Hi, > > "key" and "unique" are quite similar but differ in that the keys > > cannot > > have the local module prefix while "unique" argumenst can. How about > > allowing prefixes for keys as well? > > > > this is OK with me. > It is confusing to users if the local prefix is > not allowed here, even though there are no other > possible namespaces except the local module to use. I agree. /martin From mbj@tail-f.com Wed Mar 4 12:27: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 BDFF728C106 for ; Wed, 4 Mar 2009 12:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.091, 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 HjgUyFmLZP+c for ; Wed, 4 Mar 2009 12:27:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F36293A6844 for ; Wed, 4 Mar 2009 12:27: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 3033F76C4E6; Wed, 4 Mar 2009 21:27:53 +0100 (CET) Date: Wed, 04 Mar 2009 21:27:52 +0100 (CET) Message-Id: <20090304.212752.227100901.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1236086617.7081.7.camel@missotis> References: <1236086617.7081.7.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice/config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:27:25 -0000 Ladislav Lhotka wrote: > Hi, > > section 7.19.1 doesn't address the case when "config" is a substatement > of choice. This could be added as a second paragraph in this section: > > As a substatement of "choice", the "config" statement applies to all > data nodes in all cases of the "choice" statement. I assume that you think choice is not covered because a 'case' cannot have a config statement? The text says If "config" is not specified, the default is the same as the parent node's (in the data model) "config" value. which implies that in: choice a { config false; case b { leaf c { ... } } ... } node c's config value would be that of node b, but since node b is a case node, which doesn't have a config property, thus we don't know c's config value. Another solution could be to state that a case node always inherits its parent choice's config property. /martin From mbj@tail-f.com Wed Mar 4 12:47:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8181E3A699E for ; Wed, 4 Mar 2009 12:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.089, 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 cePTgme5l-wN for ; Wed, 4 Mar 2009 12:47:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9C8D33A68B0 for ; Wed, 4 Mar 2009 12:47:00 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CC6B776C4E6; Wed, 4 Mar 2009 21:47:28 +0100 (CET) Date: Wed, 04 Mar 2009 21:47:28 +0100 (CET) Message-Id: <20090304.214728.80048810.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AE9539.3070606@netconfcentral.com> References: <49ADE846.407@netconfcentral.com> <20090304.093953.05473739.mbj@tail-f.com> <49AE9539.3070606@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] multiple deviation-stmts for 1 target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 20:47:01 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I don't think this CLR is really needed. > > Just to be clear - do you think that the current text is fine, or do > > we need to add anything? > > > > I can't think of any normative text for this issue. How about saying that the data model after applying all deviations MUST still be valid? Maybe even say that is MUST be valid after applying them in *any* order? > Here are some CLRs that fall out of the syntax: > > - a key leaf cannot be changed to 'not-supported' > - a key leaf cannot be changed from config true to false > - a leaf within the default case for a choice cannot > be changed from mandatory false to true > - the text says an exact match is needed for > the boolean clauses (e.g., mandatory) but this is useless > because the property is probably derived from its parent > instead of with an explicit clause. You need to ignore that text > to implementation deviations correctly. This only affects 'delete'. So if you want to "delete" the inherited "config true" property, you can instead add "config false". > - exact match on unique and must statements are error-prone > because they include whitespace (too bad) Yes, this might be error prone, but this is a corner case, and at least the tools will complain if you enter an incorrect string. /martin From lhotka@cesnet.cz Wed Mar 4 23:09: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 2FD7A3A67E5 for ; Wed, 4 Mar 2009 23:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=0.303, 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 Cs1zHp8aOeZd for ; Wed, 4 Mar 2009 23:09:28 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C91E43A67DB for ; Wed, 4 Mar 2009 23:09:27 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5FA05D800CC; Thu, 5 Mar 2009 08:09:56 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090304.212752.227100901.mbj@tail-f.com> References: <1236086617.7081.7.camel@missotis> <20090304.212752.227100901.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 05 Mar 2009 08:09:55 +0100 Message-Id: <1236236995.6736.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice/config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 07:09:29 -0000 Martin Bjorklund píše v St 04. 03. 2009 v 21:27 +0100: > Ladislav Lhotka wrote: > > Hi, > > > > section 7.19.1 doesn't address the case when "config" is a substatement > > of choice. This could be added as a second paragraph in this section: > > > > As a substatement of "choice", the "config" statement applies to all > > data nodes in all cases of the "choice" statement. > > I assume that you think choice is not covered because a 'case' cannot > have a config statement? The text says > > If "config" is not specified, the default is the same as the parent > node's (in the data model) "config" value. > Shouldn't "data model" actually be "data tree"? If so, I don't think 'choice' belongs to the data tree. Also, the formulation in sec. 7.19.1 clearly doesn't apply to 'choice': If "config" is "true", the definition represents configuration, and will be part of the reply to a request, and may be sent in a or request. If "config" is "false", it represents state data, and will be part of the reply to a , but not to a request. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Mar 4 23:36: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 1E2B53A6B99 for ; Wed, 4 Mar 2009 23:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.105, 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 EGjusFs9fydw for ; Wed, 4 Mar 2009 23:36:54 -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 3AC263A6A9B for ; Wed, 4 Mar 2009 23:36:54 -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 C378276C4D7; Thu, 5 Mar 2009 08:37:21 +0100 (CET) Date: Thu, 05 Mar 2009 08:37:21 +0100 (CET) Message-Id: <20090305.083721.201875458.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1236236995.6736.12.camel@missotis> References: <1236086617.7081.7.camel@missotis> <20090304.212752.227100901.mbj@tail-f.com> <1236236995.6736.12.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] choice/config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 07:36:55 -0000 Ladislav Lhotka wrote: > Shouldn't "data model" actually be "data tree"? If so, I don't think > 'choice' belongs to the data tree. Also, the formulation in sec. 7.19.1 > clearly doesn't apply to 'choice': > > If "config" is "true", the definition represents configuration, and will > be part of the reply to a request, and may be sent in a > or request. If "config" is "false", it > represents state data, and will be part of the reply to a , but not > to a request. How about this: The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration will be part of the reply to a request, and can be sent in a or request. If "config" is "false", the definition represents state data. Data nodes representing state data will be part of the reply to a , but not to a request. If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node. If the top node does not specify a "config" statement, the default is "true". If a node has "config" "false", no node underneath it can have "config" set to "true". /martin From lhotka@cesnet.cz Wed Mar 4 23:49: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 8F5D628C106 for ; Wed, 4 Mar 2009 23:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=0.293, 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 1ERhy+nox6SO for ; Wed, 4 Mar 2009 23:49:21 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B02F93A67DB for ; Wed, 4 Mar 2009 23:49:21 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8513AD800BD; Thu, 5 Mar 2009 08:49:50 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090305.083721.201875458.mbj@tail-f.com> References: <1236086617.7081.7.camel@missotis> <20090304.212752.227100901.mbj@tail-f.com> <1236236995.6736.12.camel@missotis> <20090305.083721.201875458.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 05 Mar 2009 08:49:49 +0100 Message-Id: <1236239389.6736.33.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice/config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 07:49:22 -0000 Martin Bjorklund píše v Čt 05. 03. 2009 v 08:37 +0100: > Ladislav Lhotka wrote: > > Shouldn't "data model" actually be "data tree"? If so, I don't think > > 'choice' belongs to the data tree. Also, the formulation in sec. 7.19.1 > > clearly doesn't apply to 'choice': > > > > If "config" is "true", the definition represents configuration, and will > > be part of the reply to a request, and may be sent in a > > or request. If "config" is "false", it > > represents state data, and will be part of the reply to a , but not > > to a request. > > How about this: Yes, this is much better, the previous text also implies that the definition itself will be part of PDUs, which is a nonsense. It could be made even easier if 'config' was also allowed with 'case'. Would it be a problem? Lada > > > The "config" statement takes as an argument the string "true" or > "false". If "config" is "true", the definition represents > configuration. Data nodes representing configuration will be part of > the reply to a request, and can be sent in a > or request. > > If "config" is "false", the definition represents state data. Data > nodes representing state data will be part of the reply to a , > but not to a request. > > If "config" is not specified, the default is the same as the parent > schema node's "config" value. If the parent node is a "case" node, > the value is the same as the "case" node's parent "choice" node. > > If the top node does not specify a "config" statement, the default is > "true". > > If a node has "config" "false", no node underneath it can have > "config" set to "true". > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Mar 5 13:16:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3AE3A6BE2 for ; Thu, 5 Mar 2009 13:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEkJ-JeT1lqq for ; Thu, 5 Mar 2009 13:16: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 35A593A6BD5 for ; Thu, 5 Mar 2009 13:16:44 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D2AAE61600C; Thu, 5 Mar 2009 22:17:07 +0100 (CET) Date: Thu, 05 Mar 2009 22:17:07 +0100 (CET) Message-Id: <20090305.221707.101886592.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20090226.124023.139048977.mbj@tail-f.com> References: <20090226.090050.66057020.mbj@tail-f.com> <49A673D2.4050504@netconfcentral.com> <20090226.124023.139048977.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] 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, 05 Mar 2009 21:16:45 -0000 Hi, Martin Bjorklund wrote: > 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) Suppose I have an instance-identifier in my configuration data model, and it points to some other configuration object. Is an implementation required to accept the positional version of an instance identifier? I hope not. How will this be specified? Do we need two types? (ugh). Do we really need to add this positional version? Maybe another solution could be to use the new 'yang:xpath' derived type in the use case you brought up? /martin From andy@netconfcentral.com Thu Mar 5 14:21: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 86CC23A6902 for ; Thu, 5 Mar 2009 14:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 xv2uyNcDzcLq for ; Thu, 5 Mar 2009 14:21:05 -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 7E2913A68BA for ; Thu, 5 Mar 2009 14:21:05 -0800 (PST) Received: from [209.191.108.96] by n7.bullet.mud.yahoo.com with NNFMP; 05 Mar 2009 22:21:35 -0000 Received: from [68.142.201.253] by t3.bullet.mud.yahoo.com with NNFMP; 05 Mar 2009 22:21:35 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 05 Mar 2009 22:21:35 -0000 X-Yahoo-Newman-Id: 163059.1713.bm@omp414.mail.mud.yahoo.com Received: (qmail 16656 invoked from network); 5 Mar 2009 22:21:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.225.83 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 5 Mar 2009 22:21:34 -0000 X-YMail-OSG: d2aX.YUVM1nxaypt2bx7ZAaIne0LAyu.McJn4hffPj6YgtN2U8MtWa9o9QuAypVVMJjZ0fu0MBftLLyIsVtnK7a4HAuvqjk48dhMYfStJS6KXOTVDdY62JaqHBko4nU094.dGFywjQr3bmnkx8_08vVUwg8DjoCit4RU6IbeVEc6crtM5FfP0KVpyS3UCu1M9bq2mEjZO_TaKyy0ThB3mQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B0506C.103@netconfcentral.com> Date: Thu, 05 Mar 2009 14:21:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090226.090050.66057020.mbj@tail-f.com> <49A673D2.4050504@netconfcentral.com> <20090226.124023.139048977.mbj@tail-f.com> <20090305.221707.101886592.mbj@tail-f.com> In-Reply-To: <20090305.221707.101886592.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, 05 Mar 2009 22:21:06 -0000 Martin Bjorklund wrote: > Hi, > > Martin Bjorklund wrote: >> 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) > > Suppose I have an instance-identifier in my configuration data model, > and it points to some other configuration object. Is an > implementation required to accept the positional version of an > instance identifier? I hope not. How will this be specified? Do we > need two types? (ugh). Do we really need to add this positional > version? Maybe another solution could be to use the new 'yang:xpath' > derived type in the use case you brought up? > The positional form must only be used if there are no keys available. It doesn't matter why -- when the error-path is getting generated, there may be missing keys (hence the error) The code is basically: for each node: 1) is 'foo' a list? are there any keys available to use? 2) no --> count up all the instances of 'foo' 2a) if more than 1 instance (including 'foo') then use the position in the instance ID (e.g., foo[2]). Never generate 'foo[1]' unless there are more than one of them (just 'foo' instead) So a manager can never specify 'foo[2]' in an instance-identifier if the YANG definition has any keys defined for list 'foo'. > > /martin > > Andy From root@core3.amsl.com Fri Mar 6 13:45: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 625EF3A685D; Fri, 6 Mar 2009 13:45:00 -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: <20090306214501.625EF3A685D@core3.amsl.com> Date: Fri, 6 Mar 2009 13:45:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-04.txt Pages : 171 Date : 2009-03-06 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06133234.I-D@ietf.org> --NextPart-- From lhotka@cesnet.cz Sun Mar 8 04:44: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 843863A67AC for ; Sun, 8 Mar 2009 04:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=0.283, 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 uIs2sLMKaTvh for ; Sun, 8 Mar 2009 04:44:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id ABB2C3A68E1 for ; Sun, 8 Mar 2009 04:44:28 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B66A4D800C5 for ; Sun, 8 Mar 2009 12:45:00 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 08 Mar 2009 12:44:59 +0100 Message-Id: <1236512699.7230.0.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-01] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Mar 2009 11:44:29 -0000 -------- 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-01 Datum: Sun, 8 Mar 2009 04:42:54 -0700 (PDT) A new version of I-D, draft-ietf-netmod-dsdl-map-01.txt has been successfuly submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-ietf-netmod-dsdl-map Revision: 01 Title: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Creation_date: 2009-03-08 WG ID: netmod Number_of_pages: 95 Abstract: This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL) and outlines the procedure for validating various types of NETCONF protocol data units using these schemas. The IETF Secretariat. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Sun Mar 8 04:45: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 EA2013A6B54; Sun, 8 Mar 2009 04:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090308114501.EA2013A6B54@core3.amsl.com> Date: Sun, 8 Mar 2009 04:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-01.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: Sun, 08 Mar 2009 11:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-01.txt Pages : 95 Date : 2009-03-08 This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL) and outlines the procedure for validating various types of NETCONF protocol data units using these schemas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-08044254.I-D@ietf.org> --NextPart-- From andy@netconfcentral.com Sun Mar 8 13:59: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 8A7863A68DB for ; Sun, 8 Mar 2009 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.976, 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 U8z1OvADivTa for ; Sun, 8 Mar 2009 13:59:37 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B42AF3A68DA for ; Sun, 8 Mar 2009 13:59:37 -0700 (PDT) Received: (qmail 41077 invoked from network); 8 Mar 2009 21:00:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.75 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 8 Mar 2009 21:00:10 -0000 X-YMail-OSG: SHFM7PEVM1nKCEEgP.Kw0xkF1KjOC83jNEYxP9q99F4tukIgxVwdNjQcg._SLI.rjVvMlxPU937Jhr_Xa9A78m2o_5kMXD_NQIeYumCU8qTkfLsgddYMsrHZWe9atinjeCm8VbmqFW0pS4cPoR_tDLQk X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B431D8.6050002@netconfcentral.com> Date: Sun, 08 Mar 2009 14:00:08 -0700 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] when-stmt processing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Mar 2009 20:59:41 -0000 Hi, There seems to be a chicken-and-egg evaluation problem with the when-stmt. The agent needs to skip any nodes that are currently 'not really present' because of false when-stmts (also false if-feature, but that is static, out-of-band, and easy). list foo { key A; leaf A { type string; } leaf B { mandatory true; when ". = 'fred'"; type string; } container C { when "D = 'fred'"; leaf D { type string; } } } Seems difficult to check whether B or D should exist if any 'descendant-or-self' nodes are involved in the XPath expression. Let's say /foo[A='bar'] exists, but not the child node 'B'. How can B be used as the context node for XPath evaluation if it doesn't exist? This is needed to prevent a false error for a missing mandatory leaf B. Andy From andy@netconfcentral.com Sun Mar 8 14:27: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 8B32A3A6882 for ; Sun, 8 Mar 2009 14:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=-0.918, 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 7EC9jDcoCxIp for ; Sun, 8 Mar 2009 14:27:01 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id D6FCD3A68F9 for ; Sun, 8 Mar 2009 14:27:01 -0700 (PDT) Received: (qmail 40440 invoked from network); 8 Mar 2009 21:27:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.81.75 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 8 Mar 2009 21:27:34 -0000 X-YMail-OSG: A8_zNocVM1lkbSTDSO0kheqhS7t.I_2hPYQ3jAwIpVXuki7KCGfLRmgc0llMl.l5T5IeQIWq4CZbJgq6d9AO1gDLQREI8jH11b5tQv1CjxMKC_YakXl4Kz_Vjsxc9SiuCIRBTnlka_DK_pxH0Y7fuMmP X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B43845.9060303@netconfcentral.com> Date: Sun, 08 Mar 2009 14:27:33 -0700 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] more fun with when-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: Sun, 08 Mar 2009 21:27:02 -0000 Hi, What about this one? list split { min-elements 2; when "B = 'fred'; key A; leaf A { type string; } leaf B { type string; mandatory true; } } here fred not-here barney Does the when-stmt refer to the existence of the object (split) or instances of the object? The draft seems to say the former. It is not clear to mean what the proper outcome should be for agent processing. If instances, not objects: Does the 'min-elements 2' get enforced or not? Is the when-stmt test in 'split' conducted before or after the min-elements test in 'config'? If before, no error, if after (2nd entry deleted), then it is an error. Will a CLR saying that "a when-stmt XPath expression MUST NOT include any references to child, descendant, or descendant-or-self nodes of the context node" fix this problem? Andy From bertietf@bwijnen.net Mon Mar 9 03:43: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 169343A6C1B; Mon, 9 Mar 2009 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, 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 KHlh3lKONiVm; Mon, 9 Mar 2009 03:43:39 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 8A2CB3A6C05; Mon, 9 Mar 2009 03:43:37 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Lgcxu-0006zy-IA; Mon, 09 Mar 2009 11:44:10 +0100 Message-ID: <6DA3019ECC07434BB9D95CE17C11123F@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Mon, 9 Mar 2009 11:43:40 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B1_01C9A0AC.4A8355B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: NETMOD Working Group Subject: [netmod] NETCONF/YANG Interoperability Test Summit X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 10:43:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03B1_01C9A0AC.4A8355B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We do not want to use the mailing lists to promote any products. However, when I read in the IWL newsletter =20 http://www.iwl.com/spring-2009-newsletter.html that there are prelimenary plans for some interoperability testing: NETCONF & YANG Interoperability Test Summit InterWorking Labs is in the preliminary stages of planning a=20 NETCONF & YANG Interoperability Test Summit. It is tentatively scheduled for July 20-24, 2009.=20 We would like you to pencil in those dates if you can attend. More information will be available at the end of May 2009 I figured it would be good to make sure that all NETCONF and NETMOD participants are aware of this. I remember that the IWL interoperability = Test Summits for SNMP (all versions) helped us (implementers) a lot=20 in making sure we had good (and debugged) implementations that=20 worked well together.=20 Bert Wijnen ------=_NextPart_000_03B1_01C9A0AC.4A8355B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We do not want to use the mailing = lists to=20 promote any products.
 
However, when I read in the IWL=20 newsletter 
      = http://www.iwl.com/spring-2009-newsletter.html
that there are prelimenary plans = for some=20 interoperability testing:
 
    NETCONF & = YANG=20 Interoperability Test Summit
    InterWorking Labs = is in the=20 preliminary stages of planning a
    NETCONF & YANG=20 Interoperability Test Summit.
    It is tentatively = scheduled=20 for July 20-24, 2009. 
    We would like you = to pencil in=20 those dates if you can attend.
    More information = will be=20 available at the end of May 2009
 
I figured it would be good to make sure that all = NETCONF and=20 NETMOD
participants are aware of this. I remember that the = IWL=20 interoperability
Test Summits for SNMP (all versions) helped us=20 (implementers) a lot
in making sure we had good = (and debugged)=20 implementations that
worked well together. =
 
Bert Wijnen
------=_NextPart_000_03B1_01C9A0AC.4A8355B0-- From root@core3.amsl.com Mon Mar 9 10:30:02 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F336F3A6CF7; Mon, 9 Mar 2009 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309173001.F336F3A6CF7@core3.amsl.com> Date: Mon, 9 Mar 2009 10:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-types-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-yang-types-02.txt Pages : 64 Date : 2009-03-09 This document introduces a collection of common data types to be used with the YANG data modeling language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-types-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09101526.I-D@ietf.org> --NextPart-- From david.kessens@nsn.com Tue Mar 10 21:25: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 B93343A696E for ; Tue, 10 Mar 2009 21:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCEn6xznseS6 for ; Tue, 10 Mar 2009 21:25:40 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 780113A698D for ; Tue, 10 Mar 2009 21:25:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2B4PhUS014266 for ; Tue, 10 Mar 2009 23:26:15 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 06:24:45 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 06:24:45 +0200 Received: from localhost.localdomain ([10.162.252.29]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 06:24:43 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n2B4OLgI012989 for ; Tue, 10 Mar 2009 21:24:21 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n2B4OKhg012988 for netmod@ietf.org; Tue, 10 Mar 2009 21:24:20 -0700 Date: Tue, 10 Mar 2009 21:24:20 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20090311042420.GB14278@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: 11 Mar 2009 04:24:44.0302 (UTC) FILETIME=[4DF022E0:01C9A201] X-Nokia-AV: Clean Subject: [netmod] First version of netmod wg agenda (v1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 04:25:41 -0000 Please see below for the first version of our agenda. Note that we have not filled in all details yet like the precise scheduling. We will complete that later when we have a better idea on how much time we need to spend on each topic. Please contact us if we missed anything or whether there are other agenda topics that need attention as well. David Kessens & David Partain --- Agenda: NETMOD WG (v1) Meeting: IETF 74 Location: Hilton San Francisco, San Francisco, CA, USA WG Chairs: David Kessens (david.kessens@nsn.com) David Partain (david.partain@ericsson.com) Jabber: xmpp:netmod@jabber.ietf.org WG URL: http://tools.ietf.org/wg/netmod/ MONDAY, March 23, 2009, 1740-1940, Franciscan A & WEDNESDAY, March 25, 2009, 0900-1130, Continental 1&2 1) Administrivia [chairs][ 5 min ] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min ] - How we're doing against the charter 3) Active Drafts For each draft: current status, delta from previous draft, open issues, and discussion. 3.1 NETMOD Architecture Phil Shafer http://tools.ietf.org/html/draft-shafer-netmod-arch-00 3.2 Common YANG Data Types M. Bjorklund or Juergen Schoenwaelder (5 min) http://tools.ietf.org/html/draft-ietf-netmod-yang-types-02 3.3 YANG - A data modeling language for NETCONF M. Bjorklund (40 min) http://tools.ietf.org/html/draft-ietf-netmod-yang-04 4.4 Mapping of YANG to DSDL Ladislav Lhotka (15 min) http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-01 4) Other (non WG) Internet-Drafts [chairs] 4.1 draft-bierman-netmod-netconf-module-00 draft-schoenw-netmod-smi-yang-00 4.2 YANG Usage Guidelines Andy Bierman (10 min) draft-bierman-netmod-yang-usage-00 5) I/O with other WGs (netconf?) [chairs] 6) Plans post IETF74 Are we ready for WGLC on YANG / YANG Data Types? Should we target an XSD mapping? 7) A.O.B. and open mike [N.N.][10 min] {please identify issues in advance} ---- From mbj@tail-f.com Wed Mar 11 15:29: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 0D6373A6957 for ; Wed, 11 Mar 2009 15:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.134 X-Spam-Level: *** X-Spam-Status: No, score=3.134 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 oFdzmqbfI-uW for ; Wed, 11 Mar 2009 15:29:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3890E3A6950 for ; Wed, 11 Mar 2009 15:29:20 -0700 (PDT) Received: from localhost (host-217-213-101-212.mobileonline.telia.com [217.213.101.212]) by mail.tail-f.com (Postfix) with ESMTPSA id 9D1C0616001 for ; Wed, 11 Mar 2009 23:29:54 +0100 (CET) Date: Wed, 11 Mar 2009 23:29:48 +0100 (CET) Message-Id: <20090311.232948.101713012.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:29:21 -0000 Hi, Here's a proposal for solving our float problem, which is one of the few remaining open issues in the YANG document. I suggest we remove the float types, and instead replace them with a fix point decimal type, much like xs:decimal. This is probably what most people is looking for when they use floats in configuration data models. This could be done in many ways, but here's a simple (?) proposal. We would add one new type 'decimal64', which has a mandatory substatement 'fraction-digits'. The value space would be the set of decimal numbers which fit into a 64 bit (signed) integer, scaled with the fraction part. For example: leaf foo { type decimal64 { fraction-digits 3; } } would allow all decimal values with three fraction digits between: -9223372036854775.808 .. 9223372036854775.807 Ranges can be used: leaf bar { type decimal64 { fraction-digits 2; range "0..100"; } } this would allow values 0, 0.01, 0.02 .. 99.99, 100 In the canonical form, leading and trailing zeros are not printed, except that 0.xx is printed with the leading 0. In XPath evaluations, a decimal number will always be interpreted as a 64 bit floating point value (this is not the case with some textual forms of floats). This has the known rounding problems of course. Drawback: We loose the ability to model really large or really small numbers, e.g. 1E234. Comments? /martin From per@tail-f.com Thu Mar 12 06:16: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 6E8BF3A697E for ; Thu, 12 Mar 2009 06:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.266 X-Spam-Level: X-Spam-Status: No, score=0.266 tagged_above=-999 required=5 tests=[AWL=-2.312, BAYES_20=-0.74, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 WzbBPZhkAjDk for ; Thu, 12 Mar 2009 06:16:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1BD2A3A692A for ; Thu, 12 Mar 2009 06:16:28 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0348E76C4D7; Thu, 12 Mar 2009 14:17:04 +0100 (CET) Message-ID: <49B90B4F.2080401@tail-f.com> Date: Thu, 12 Mar 2009 14:17:03 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> In-Reply-To: <20090311.232948.101713012.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:16:30 -0000 On 2009-03-11 23:29, Martin Bjorklund wrote: > > Here's a proposal for solving our float problem, which is one of the > few remaining open issues in the YANG document. > > I suggest we remove the float types, and instead replace them with a > fix point decimal type, much like xs:decimal. This is probably what > most people is looking for when they use floats in configuration data > models. I guess I'm biased, but I think this is a very good proposal - in my experience, the use of floats in data models for network devices ranges from "don't care" to "serious problem" (the latter because HW and/or SW may be unable to handle them) - but better-than-integer "resolution" is often desirable. Minor issues: > This could be done in many ways, but here's a simple (?) proposal. We > would add one new type 'decimal64', which has a mandatory substatement > 'fraction-digits'. Should probably require that fraction-digits > 0. > In the canonical form, leading and trailing zeros are not printed, > except that 0.xx is printed with the leading 0. I think the canonical form defined for xs:decimal may be more in line with common expectations, i.e. decimal point and at least one digit before and after is required => xx is printed as "xx.0". --Per Hedeland From phil@juniper.net Thu Mar 12 06:59: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 566443A6A21 for ; Thu, 12 Mar 2009 06:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnSyZjr7CijB for ; Thu, 12 Mar 2009 06:59:43 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 97DCC3A6A58 for ; Thu, 12 Mar 2009 06:59:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSbkVc6Y/i/L5aZX1bRIhPal7GVl/aBk8@postini.com; Thu, 12 Mar 2009 07:00:21 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Mar 2009 06:58:23 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 06:58:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 06:58:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 06:58:22 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2CDwLM99301; Thu, 12 Mar 2009 06:58:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2CDpVkY020200; Thu, 12 Mar 2009 13:51:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903121351.n2CDpVkY020200@idle.juniper.net> To: Per Hedeland In-Reply-To: <49B90B4F.2080401@tail-f.com> Date: Thu, 12 Mar 2009 09:51:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Mar 2009 13:58:22.0369 (UTC) FILETIME=[9B1E2110:01C9A31A] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:59:44 -0000 Per Hedeland writes: >I guess I'm biased, but I think this is a very good proposal - in my >experience, the use of floats in data models for network devices ranges >from "don't care" to "serious problem" (the latter because HW and/or SW >may be unable to handle them) - but better-than-integer "resolution" is >often desirable. Minor issues: +1 here also. I just did an inventory of our use of floats and found: 6 percents (fractional-digits 2) 2 power ratings (POE) (fractional-digits 1) 3 routing metrics (fractional-digits 8) 2 billing rates (fractional-digits 2 (assumably)) 1 ntp clock drift (unknown, but probably 4) This proposal will satisfy all these. Anyone want to check MIBs? Thanks, Phil From andy@netconfcentral.com Thu Mar 12 09:18: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 D13AE28C207 for ; Thu, 12 Mar 2009 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_27=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 gHGOm1uSJo92 for ; Thu, 12 Mar 2009 09:18:04 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 71A6328C1E4 for ; Thu, 12 Mar 2009 09:18:04 -0700 (PDT) Received: from [209.191.108.97] by n10.bullet.mail.mud.yahoo.com with NNFMP; 12 Mar 2009 16:18:41 -0000 Received: from [68.142.201.66] by t4.bullet.mud.yahoo.com with NNFMP; 12 Mar 2009 16:18:41 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 12 Mar 2009 16:18:41 -0000 X-Yahoo-Newman-Id: 873841.23911.bm@omp418.mail.mud.yahoo.com Received: (qmail 9460 invoked from network); 12 Mar 2009 16:18:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 12 Mar 2009 16:18:40 -0000 X-YMail-OSG: S8M88BMVM1m6CQ2tc5bFVM3NIZLx9VujEQTZQEfO3y.ErXLIPg7DVpXuhQCGqOPZzv2JlvcEUre8Aj5VuAO4huuOmT4UgG4kR64b519l2OX9fMM5ABzMshQ6s_Z0v8kM4NlecCIi1HjC5pzceLSMWPXG X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B935DF.3040408@netconfcentral.com> Date: Thu, 12 Mar 2009 09:18:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> In-Reply-To: <20090311.232948.101713012.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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:18:09 -0000 Martin Bjorklund wrote: > Hi, > > Here's a proposal for solving our float problem, which is one of the > few remaining open issues in the YANG document. > > I suggest we remove the float types, and instead replace them with a > fix point decimal type, much like xs:decimal. This is probably what > most people is looking for when they use floats in configuration data > models. > > This could be done in many ways, but here's a simple (?) proposal. We > would add one new type 'decimal64', which has a mandatory substatement > 'fraction-digits'. The value space would be the set of decimal > numbers which fit into a 64 bit (signed) integer, scaled with the > fraction part. For example: > > leaf foo { > type decimal64 { > fraction-digits 3; > } > } > > would allow all decimal values with three fraction digits between: > > -9223372036854775.808 .. 9223372036854775.807 > > Ranges can be used: > > leaf bar { > type decimal64 { > fraction-digits 2; > range "0..100"; > } > } > what are the lower and upper bounds for fraction-digits? Is it 1..63? If so, then I approve of removing float32 and float64, and adding decimal64 instead. > this would allow values 0, 0.01, 0.02 .. 99.99, 100 > > In the canonical form, leading and trailing zeros are not printed, > except that 0.xx is printed with the leading 0. > > In XPath evaluations, a decimal number will always be interpreted as a > 64 bit floating point value (this is not the case with some textual > forms of floats). This has the known rounding problems of course. > > Drawback: We loose the ability to model really large or really small > numbers, e.g. 1E234. > > Comments? > > > /martin > _ Andy From balazs.lengyel@ericsson.com Thu Mar 12 09:25: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 233F73A680B for ; Thu, 12 Mar 2009 09:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SE=0.35, J_CHICKENPOX_27=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 UVfrc5DRuyaQ for ; Thu, 12 Mar 2009 09:25:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 355B83A6BD8 for ; Thu, 12 Mar 2009 09:25:18 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 11EAF225B5; Thu, 12 Mar 2009 17:24:55 +0100 (CET) X-AuditID: c1b4fb3e-ad09cbb0000023da-01-49b937564d57 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E1B61225B3; Thu, 12 Mar 2009 17:24:54 +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, 12 Mar 2009 17:24:53 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 17:24:53 +0100 Message-ID: <49B93754.4070901@ericsson.com> Date: Thu, 12 Mar 2009 17:24:52 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> In-Reply-To: <20090311.232948.101713012.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2009 16:24:53.0501 (UTC) FILETIME=[130A6AD0:01C9A32F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:25:31 -0000 +1 Balazs Martin Bjorklund wrote: > Hi, > > Here's a proposal for solving our float problem, which is one of the > few remaining open issues in the YANG document. > > I suggest we remove the float types, and instead replace them with a > fix point decimal type, much like xs:decimal. This is probably what > most people is looking for when they use floats in configuration data > models. > > This could be done in many ways, but here's a simple (?) proposal. We > would add one new type 'decimal64', which has a mandatory substatement > 'fraction-digits'. BALAZS: I would not make it mandatory. Rather say that if it is absent it means fraction-digits 2; I think 2 is the most common, see Phil's examples. (Not really important) The value space would be the set of decimal > numbers which fit into a 64 bit (signed) integer, scaled with the > fraction part. For example: > > leaf foo { > type decimal64 { > fraction-digits 3; > } > } > > would allow all decimal values with three fraction digits between: > > -9223372036854775.808 .. 9223372036854775.807 > > Ranges can be used: > > leaf bar { > type decimal64 { > fraction-digits 2; > range "0..100"; > } > } > > this would allow values 0, 0.01, 0.02 .. 99.99, 100 > > In the canonical form, leading and trailing zeros are not printed, > except that 0.xx is printed with the leading 0. > > In XPath evaluations, a decimal number will always be interpreted as a > 64 bit floating point value (this is not the case with some textual > forms of floats). This has the known rounding problems of course. > > Drawback: We loose the ability to model really large or really small > numbers, e.g. 1E234. > > Comments? > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From j.schoenwaelder@jacobs-university.de Thu Mar 12 09:54: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 54B823A69BD for ; Thu, 12 Mar 2009 09:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 ak60Ue5RSDgn for ; Thu, 12 Mar 2009 09:54:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D167D3A6AD2 for ; Thu, 12 Mar 2009 09:54:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD249C0051; Thu, 12 Mar 2009 17:55:00 +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 bRQf47FZZUyt; Thu, 12 Mar 2009 17:54:59 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52791C0028; Thu, 12 Mar 2009 17:54:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 91051A04AD4; Thu, 12 Mar 2009 17:54:46 +0100 (CET) Date: Thu, 12 Mar 2009 17:54:46 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090312165446.GA3897@elstar.local> Mail-Followup-To: Phil Shafer , Per Hedeland , "netmod@ietf.org" References: <49B90B4F.2080401@tail-f.com> <200903121351.n2CDpVkY020200@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903121351.n2CDpVkY020200@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:54:25 -0000 On Thu, Mar 12, 2009 at 02:51:31PM +0100, Phil Shafer wrote: > This proposal will satisfy all these. Anyone want to check MIBs? There are no native floats in the SMIv2 so there are no native floats in MIBs - if there are floats, then they are either shipped in Opaque or hacked OCTET STRINGS or simply as character string. There are a few IETF MIBs dealing with floats, e.g. the TeLinkBandwidth TC defined in the TE-LINK-STD-MIB represents a float. The TC reprensents link bandwidth in bps - I actually do not know why this should be float; a 64 bit scaled unsigned value should be pretty much sufficient. That said, let me note that via the DISPLAY-HINT mechanism, the SMIv2 has kind of a "decimal32" type since you can insert a decimal point in the rendering of integers, actually the SMIv2 has a signed and an unsigned "decimal32". (Is the proposed decimals64 always signed or should we also have udecimal64, or short dec64 and udec64?) For conversion of MIB modules, decimal64 will work very nicely. /js PS: If we do decimal64, we do get some obvious asymmetry since we have [u]int8|16|32|64 base types but then only [u?]decimal64. So if we were to open up the base types, we might as well do only int, uint, dec, and udec and all would be 64 bits. ietf-yang-types.yang can then define the [u]int8|16|32|64 variants for common usage and the spec actually gets shorter. (And smart implementations can in general pay attention to range restrictions when they generate storage allocations.) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Thu Mar 12 10:38: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 BC81628C202 for ; Thu, 12 Mar 2009 10:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kQNLU2ziRrN for ; Thu, 12 Mar 2009 10:38:41 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id EF8083A67EC for ; Thu, 12 Mar 2009 10:38:41 -0700 (PDT) Received: (qmail 38515 invoked from network); 12 Mar 2009 17:39:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 12 Mar 2009 17:39:19 -0000 X-YMail-OSG: v1SZBD8VM1lLq6XV_S0lhtBWwKeUxFEzyid7pt03F4xVSxcVm3H0aNx98w5rOTQIhLF2uwFfT34kfJiNEL2Bbo9tdedfRUP0.QZTlY9ZnIIcUSA1J87D1KOPqK01rHNdSVGfLDWEjsm4DiNSL_PIh9bW X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B948C6.7020101@netconfcentral.com> Date: Thu, 12 Mar 2009 10:39:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "netmod@ietf.org" References: <49B90B4F.2080401@tail-f.com> <200903121351.n2CDpVkY020200@idle.juniper.net> <20090312165446.GA3897@elstar.local> In-Reply-To: <20090312165446.GA3897@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:38:43 -0000 Juergen Schoenwaelder wrote: > On Thu, Mar 12, 2009 at 02:51:31PM +0100, Phil Shafer wrote: > >> This proposal will satisfy all these. Anyone want to check MIBs? > > There are no native floats in the SMIv2 so there are no native floats > in MIBs - if there are floats, then they are either shipped in Opaque > or hacked OCTET STRINGS or simply as character string. There are a few > IETF MIBs dealing with floats, e.g. the TeLinkBandwidth TC defined in > the TE-LINK-STD-MIB represents a float. The TC reprensents link > bandwidth in bps - I actually do not know why this should be float; a > 64 bit scaled unsigned value should be pretty much sufficient. > > That said, let me note that via the DISPLAY-HINT mechanism, the SMIv2 > has kind of a "decimal32" type since you can insert a decimal point in > the rendering of integers, actually the SMIv2 has a signed and an > unsigned "decimal32". (Is the proposed decimals64 always signed or > should we also have udecimal64, or short dec64 and udec64?) For > conversion of MIB modules, decimal64 will work very nicely. > > /js > > PS: If we do decimal64, we do get some obvious asymmetry since we have > [u]int8|16|32|64 base types but then only [u?]decimal64. So if we > were to open up the base types, we might as well do only int, > uint, dec, and udec and all would be 64 bits. ietf-yang-types.yang > can then define the [u]int8|16|32|64 variants for common usage and > the spec actually gets shorter. (And smart implementations can in > general pay attention to range restrictions when they generate > storage allocations.) > What about 32 and 64 bit, instead of just 64 bit? I would prefer less numeric types, with the extras moved to ietf-yang-types.yang. IMO, we only need 6 built-in numeric types: int32: 32-bit signed integer uint32: 32-bit unsigned integer int64: 64-bit signed integer uint64: 64-bit unsigned integer dec64: 64-bit signed decimal udec64: 64-bit unsigned decimal This matches SMIv2 and other common usage. But it is not a big deal to have the other 4 types. Either way, signed and unsigned decimal types should be added, not just unsigned. Andy From mbj@tail-f.com Thu Mar 12 12:30: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 0AE613A6B6A for ; Thu, 12 Mar 2009 12:30:08 -0700 (PDT) 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=1.207, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 wpJ8puQ47hQA for ; Thu, 12 Mar 2009 12:30:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6E64D3A6A62 for ; Thu, 12 Mar 2009 12:30:06 -0700 (PDT) Received: from localhost (host-217-213-177-190.mobileonline.telia.com [217.213.177.190]) by mail.tail-f.com (Postfix) with ESMTPSA id 91E37616014; Thu, 12 Mar 2009 20:30:40 +0100 (CET) Date: Thu, 12 Mar 2009 20:30:32 +0100 (CET) Message-Id: <20090312.203032.251524704.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49B935DF.3040408@netconfcentral.com> References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 19:30:08 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > Here's a proposal for solving our float problem, which is one of the > > few remaining open issues in the YANG document. > > I suggest we remove the float types, and instead replace them with a > > fix point decimal type, much like xs:decimal. This is probably what > > most people is looking for when they use floats in configuration data > > models. > > This could be done in many ways, but here's a simple (?) proposal. We > > would add one new type 'decimal64', which has a mandatory substatement > > 'fraction-digits'. The value space would be the set of decimal > > numbers which fit into a 64 bit (signed) integer, scaled with the > > fraction part. For example: > > leaf foo { > > type decimal64 { > > fraction-digits 3; > > } > > } > > would allow all decimal values with three fraction digits between: > > -9223372036854775.808 .. 9223372036854775.807 > > Ranges can be used: > > leaf bar { > > type decimal64 { > > fraction-digits 2; > > range "0..100"; > > } > > } > > > > what are the lower and upper bounds for fraction-digits? > Is it 1..63? If so, then I approve of removing float32 > and float64, and adding decimal64 instead. 1..19. Note that this is a *decimal* fix point, not a binary. There are 19 decimal digits in 9223372036854775807, thus the maximum is 19. More details: if a derived type is constructed from a decmial64, the fraction digits can be lowered, thus restricting the base type. For example: typedef foo { type decimal64 { fraction-digits 3; } } would allow all decimal values with three fraction digits between: -9223372036854775.808 .. 9223372036854775.807 and typedef bar { type foo { fraction-digits 1; } } would restrict the range to -9223372036854775.9 .. 9223372036854775.8 /martin From per@tail-f.com Thu Mar 12 12:56:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78FE3A6B1C for ; Thu, 12 Mar 2009 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 87-Bb+Fs2lQr for ; Thu, 12 Mar 2009 12:56:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E8CA83A6962 for ; Thu, 12 Mar 2009 12:56:52 -0700 (PDT) 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 0EE5F616014; Thu, 12 Mar 2009 20:57:30 +0100 (CET) Message-ID: <49B96929.6060905@tail-f.com> Date: Thu, 12 Mar 2009 20:57:29 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> In-Reply-To: <20090312.203032.251524704.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 19:56:54 -0000 On 2009-03-12 20:30, Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> Here's a proposal for solving our float problem, which is one of the >>> few remaining open issues in the YANG document. >>> I suggest we remove the float types, and instead replace them with a >>> fix point decimal type, much like xs:decimal. This is probably what >>> most people is looking for when they use floats in configuration data >>> models. >>> This could be done in many ways, but here's a simple (?) proposal. We >>> would add one new type 'decimal64', which has a mandatory substatement >>> 'fraction-digits'. The value space would be the set of decimal >>> numbers which fit into a 64 bit (signed) integer, scaled with the >>> fraction part. For example: >>> leaf foo { >>> type decimal64 { >>> fraction-digits 3; >>> } >>> } >>> would allow all decimal values with three fraction digits between: >>> -9223372036854775.808 .. 9223372036854775.807 >>> Ranges can be used: >>> leaf bar { >>> type decimal64 { >>> fraction-digits 2; >>> range "0..100"; >>> } >>> } >>> >> what are the lower and upper bounds for fraction-digits? >> Is it 1..63? If so, then I approve of removing float32 >> and float64, and adding decimal64 instead. > > 1..19. Note that this is a *decimal* fix point, not a binary. There > are 19 decimal digits in 9223372036854775807, thus the maximum is 19. Hm, is there an obvious problem with higher values? E.g. 21 would mean that you can represent -0.009223372036854775808 .. 0.009223372036854775807 - that should be OK per se I think? Or at least just as OK as 19: -0.9223372036854775808 .. 0.9223372036854775807 If we want 'fraction-digits N' to imply that the full range of values that can be expressed with N decimals should be covered - could make sense I guess - the maximum would be 18. --Per From andy@netconfcentral.com Thu Mar 12 13:10: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 7AC993A6A4D for ; Thu, 12 Mar 2009 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.716 X-Spam-Level: X-Spam-Status: No, score=-0.716 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=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 FNPk20vfRpzo for ; Thu, 12 Mar 2009 13:10:56 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 7B9233A6A4A for ; Thu, 12 Mar 2009 13:10:56 -0700 (PDT) Received: (qmail 7749 invoked from network); 12 Mar 2009 20:11:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 12 Mar 2009 20:11:33 -0000 X-YMail-OSG: 8hqPQQMVM1nI88uqkajlra_2wSQONVyTqjFGo0F7wkQa6rvswZuJeZOwmSKH3vVlUAIIb.9jKCAoLYy17AFc.i5fcVL9gWmcPV.LCXYa.xnJvsjUOvh9HTuU2yVgzNEL0uuNaWs2dr7aFjIpA_i_qLHSFfM64S_HXItnBqhX4ETo3ZIy60hnQnhSMGlvsCrFdWQUU11wRJVS8j8rCKOfyQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B96C74.1000004@netconfcentral.com> Date: Thu, 12 Mar 2009 13:11:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Per Hedeland References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> <49B96929.6060905@tail-f.com> In-Reply-To: <49B96929.6060905@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 20:10:57 -0000 Per Hedeland wrote: > On 2009-03-12 20:30, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Martin Bjorklund wrote: >>>> Hi, >>>> Here's a proposal for solving our float problem, which is one of the >>>> few remaining open issues in the YANG document. >>>> I suggest we remove the float types, and instead replace them with a >>>> fix point decimal type, much like xs:decimal. This is probably what >>>> most people is looking for when they use floats in configuration data >>>> models. >>>> This could be done in many ways, but here's a simple (?) proposal. We >>>> would add one new type 'decimal64', which has a mandatory substatement >>>> 'fraction-digits'. The value space would be the set of decimal >>>> numbers which fit into a 64 bit (signed) integer, scaled with the >>>> fraction part. For example: >>>> leaf foo { >>>> type decimal64 { >>>> fraction-digits 3; >>>> } >>>> } >>>> would allow all decimal values with three fraction digits between: >>>> -9223372036854775.808 .. 9223372036854775.807 >>>> Ranges can be used: >>>> leaf bar { >>>> type decimal64 { >>>> fraction-digits 2; >>>> range "0..100"; >>>> } >>>> } >>>> >>> what are the lower and upper bounds for fraction-digits? >>> Is it 1..63? If so, then I approve of removing float32 >>> and float64, and adding decimal64 instead. >> 1..19. Note that this is a *decimal* fix point, not a binary. There >> are 19 decimal digits in 9223372036854775807, thus the maximum is 19. > > Hm, is there an obvious problem with higher values? E.g. 21 would mean > that you can represent > > -0.009223372036854775808 .. 0.009223372036854775807 > > - that should be OK per se I think? Or at least just as OK as 19: > > -0.9223372036854775808 .. 0.9223372036854775807 > > If we want 'fraction-digits N' to imply that the full range of values > that can be expressed with N decimals should be covered - could make > sense I guess - the maximum would be 18. > I am concerned this simple change is getting more complicated by the minute. Maybe we should see a complete proposal first. So there is no need for unsigned decimal? OK. Let's not make the same mistake as SMIv2 in reverse. (Counter64 only, then a hack for Unsigned64, and still no Integer64.) This is probably OK (signed but no unsigned). At least a 'history table delta object' is still possible (unlike SMIv2). > --Per Andy From balazs.lengyel@ericsson.com Fri Mar 13 03:55: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 542CD3A6B1C for ; Fri, 13 Mar 2009 03:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.305, 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 2TH-Lkh2dE80 for ; Fri, 13 Mar 2009 03:55:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 760BB3A6A60 for ; Fri, 13 Mar 2009 03:55:17 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CC0522480; Fri, 13 Mar 2009 11:53:46 +0100 (CET) X-AuditID: c1b4fb3c-ad009bb000001b43-8b-49ba3ad812d4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38360221A9; Fri, 13 Mar 2009 11:52:08 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 11:52:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 11:52:06 +0100 Message-ID: <49BA3AD6.6000203@ericsson.com> Date: Fri, 13 Mar 2009 11:52:06 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Per Hedeland References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> <49B96929.6060905@tail-f.com> In-Reply-To: <49B96929.6060905@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 10:52:06.0760 (UTC) FILETIME=[C0594680:01C9A3C9] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 10:55:33 -0000 Per Hedeland wrote: >>> what are the lower and upper bounds for fraction-digits? >>> Is it 1..63? If so, then I approve of removing float32 >>> and float64, and adding decimal64 instead. >> 1..19. Note that this is a *decimal* fix point, not a binary. There >> are 19 decimal digits in 9223372036854775807, thus the maximum is 19. > > Hm, is there an obvious problem with higher values? E.g. 21 would mean > that you can represent > > -0.009223372036854775808 .. 0.009223372036854775807 > > - that should be OK per se I think? Or at least just as OK as 19: > > -0.9223372036854775808 .. 0.9223372036854775807 > > If we want 'fraction-digits N' to imply that the full range of values > that can be expressed with N decimals should be covered - could make > sense I guess - the maximum would be 18. I think this rather complicates the original idea, and I don't see the use case for 23 digits precision. Do you ? 1..19 is fine or maybe 0..19 Balazs From balazs.lengyel@ericsson.com Fri Mar 13 03:57: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 A38BD3A694C for ; Fri, 13 Mar 2009 03:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.287, 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 KoEeYG20+8vp for ; Fri, 13 Mar 2009 03:57:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F02463A6A32 for ; Fri, 13 Mar 2009 03:57:02 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DEF8222170; Fri, 13 Mar 2009 11:57:05 +0100 (CET) X-AuditID: c1b4fb3c-ac808bb000001b43-e2-49ba3be67cda Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2A88F21102; Fri, 13 Mar 2009 11:56:38 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 11:56:26 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 11:56:25 +0100 Message-ID: <49BA3BD9.9010606@ericsson.com> Date: Fri, 13 Mar 2009 11:56:25 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> In-Reply-To: <20090312.203032.251524704.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 10:56:25.0624 (UTC) FILETIME=[5AA4C980:01C9A3CA] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 10:57:12 -0000 Martin Bjorklund wrote: > More details: if a derived type is constructed from a decmial64, the > fraction digits can be lowered, thus restricting the base type. For > example: > > typedef foo { > type decimal64 { > fraction-digits 3; > } > } > > would allow all decimal values with three fraction digits between: > -9223372036854775.808 .. 9223372036854775.807 > > and > > typedef bar { > type foo { > fraction-digits 1; > } > } > > would restrict the range to > > -9223372036854775.9 .. 9223372036854775.8 > If you allow this change you will need some little rules to ensure that the value space is not increased. (Although you have bits available in the 64 bit int used you are not allowed to use them because that would increase the value space. I propose, fraction-digits must remain unchanged. Balazs From j.schoenwaelder@jacobs-university.de Fri Mar 13 04:21: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 6A7933A6B11 for ; Fri, 13 Mar 2009 04:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, 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 Y5a2jXVrkyed for ; Fri, 13 Mar 2009 04:21:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F32893A6A32 for ; Fri, 13 Mar 2009 04:21:50 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2976C000C; Fri, 13 Mar 2009 12:22:28 +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 SeoDXCFkP-gB; Fri, 13 Mar 2009 12:22:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03EFDC0006; Fri, 13 Mar 2009 12:22:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2BEEFA0590A; Fri, 13 Mar 2009 12:22:11 +0100 (CET) Date: Fri, 13 Mar 2009 12:22:11 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090313112211.GA5072@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20090311.232948.101713012.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090311.232948.101713012.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 11:21:59 -0000 On Wed, Mar 11, 2009 at 11:29:48PM +0100, Martin Bjorklund wrote: > [...] For example: > > leaf foo { > type decimal64 { > fraction-digits 3; > } > } > > would allow all decimal values with three fraction digits between: > > -9223372036854775.808 .. 9223372036854775.807 > > Ranges can be used: > > leaf bar { > type decimal64 { > fraction-digits 2; > range "0..100"; > } > } > > this would allow values 0, 0.01, 0.02 .. 99.99, 100 So which of the following subtyping examples are legal and what is the resulting value space? typedef A { type dec64 { fraction-digits 2; range "0..100"; } } typedef B { type A { fraction-digits 1; } } typedef C { type A { fraction-digits 3; } } typedef D { type A { range "10.0..110.0"; } } typedef E { type A { fraction-digits 1; range "10.0..110.0"; } } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From per@tail-f.com Fri Mar 13 04:59: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 C54403A69D4 for ; Fri, 13 Mar 2009 04:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=0.771, 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 nIGvS4+Qtk7g for ; Fri, 13 Mar 2009 04:58:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EA8EA3A6A11 for ; Fri, 13 Mar 2009 04:58:57 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D04176C4D7; Fri, 13 Mar 2009 12:59:35 +0100 (CET) Message-ID: <49BA4AA3.2000508@tail-f.com> Date: Fri, 13 Mar 2009 12:59:31 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Balazs Lengyel References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> <49B96929.6060905@tail-f.com> <49BA3AD6.6000203@ericsson.com> In-Reply-To: <49BA3AD6.6000203@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 11:59:04 -0000 On 2009-03-13 11:52, Balazs Lengyel wrote: > > > Per Hedeland wrote: >>>> what are the lower and upper bounds for fraction-digits? >>>> Is it 1..63? If so, then I approve of removing float32 >>>> and float64, and adding decimal64 instead. >>> 1..19. Note that this is a *decimal* fix point, not a binary. There >>> are 19 decimal digits in 9223372036854775807, thus the maximum is 19. >> >> Hm, is there an obvious problem with higher values? E.g. 21 would mean >> that you can represent >> >> -0.009223372036854775808 .. 0.009223372036854775807 >> >> - that should be OK per se I think? Or at least just as OK as 19: >> >> -0.9223372036854775808 .. 0.9223372036854775807 >> >> If we want 'fraction-digits N' to imply that the full range of values >> that can be expressed with N decimals should be covered - could make >> sense I guess - the maximum would be 18. > > I think this rather complicates the original idea, and I don't see the > use case for 23 digits precision. Do you ? No, I agree, it's just confusing - among other things since the precision *wouldn't* be 23 digits. > 1..19 is fine or maybe 0..19 Don't agree. What I tried to say above is that 19 is no more special than 20 or 21 - the special number is 18, which is the max number where you can represent all values. E.g. you can't represent 0.9876543210987654321 even though that is 19 decimals. And I think 0 should be disallowed because it's pointless (and possibly confusing) - don't use the decimal type if you don't want any decimals, use an integer. I.e. my suggestion is: 1..18 --Per From phil@juniper.net Fri Mar 13 05:04: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 CC2733A69B4 for ; Fri, 13 Mar 2009 05:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FNtT7mQV4We for ; Fri, 13 Mar 2009 05:04:50 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id D884B3A6B5B for ; Fri, 13 Mar 2009 05:04:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSbpL/GGizN72Tcp8MqGzsdRz+fUJqHKM@postini.com; Fri, 13 Mar 2009 05:05:19 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 13 Mar 2009 05:03:27 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 05:03:27 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 05:03:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 05:03:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2DC3QM42589; Fri, 13 Mar 2009 05:03:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2DBuZrH048598; Fri, 13 Mar 2009 11:56:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903131156.n2DBuZrH048598@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090312.203032.251524704.mbj@tail-f.com> Date: Fri, 13 Mar 2009 07:56:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Mar 2009 12:03:26.0978 (UTC) FILETIME=[B78EB620:01C9A3D3] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 12:04:56 -0000 Martin Bjorklund writes: >More details: if a derived type is constructed from a decmial64, the >fraction digits can be lowered, thus restricting the base type. For >example: > > typedef foo { > type decimal64 { > fraction-digits 3; > } > } > > would allow all decimal values with three fraction digits between: > -9223372036854775.808 .. 9223372036854775.807 > >and > > typedef bar { > type foo { > fraction-digits 1; > } > } > >would restrict the range to > > -9223372036854775.9 .. 9223372036854775.8 This example is fine, but I'd also want to be able to raise the number of decimal digits for this scenario: typedef percent { type decimal64 { fractional-digits 1; } } typedef really-accurate-percentage { type percent { fractional-digits 5; } } Not a huge sticking point, though.... More of a sticky issue is the 64/32/16/8. I'm no type guru, but would we be better off with "integer" and "decimal" as the builtin types and then derive all the [u]int[64,32,16,8] in yang-types? I know we considered and discarded this earlier, but with decimal, the issue becomes twice as ugly. Thanks, Phil From phil@juniper.net Fri Mar 13 05:12: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 884173A6B6F for ; Fri, 13 Mar 2009 05:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K71SVXTsR2yd for ; Fri, 13 Mar 2009 05:12:01 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id AD2BE3A6BBA for ; Fri, 13 Mar 2009 05:11:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSbpNsnYrIFJLVbdHkTJFpf66Ps3YlIGo@postini.com; Fri, 13 Mar 2009 05:12:38 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 13 Mar 2009 05:10:47 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 05:10:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 05:10:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 05:10:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2DCAgM46494; Fri, 13 Mar 2009 05:10:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2DC3pZb048640; Fri, 13 Mar 2009 12:03:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903131203.n2DC3pZb048640@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090313112211.GA5072@elstar.local> Date: Fri, 13 Mar 2009 08:03:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Mar 2009 12:10:45.0847 (UTC) FILETIME=[BD24CE70:01C9A3D4] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 12:12:07 -0000 Juergen Schoenwaelder writes: >So which of the following subtyping examples are legal and what is the >resulting value space? And what does this do? typedef zee { type decimal64 { fractional-digits 3; range 0.001..0.010; } } typedef why { type zee { fractional-digits 1; } } ;^) Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Mar 13 06:31: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 9001428C0DE for ; Fri, 13 Mar 2009 06:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 Ih2wL1-H1M2U for ; Fri, 13 Mar 2009 06:31:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9B19628C0E4 for ; Fri, 13 Mar 2009 06:31:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00825C0006; Fri, 13 Mar 2009 14:32:25 +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 jGeCTpmAlWD1; Fri, 13 Mar 2009 14:32:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 836B8C0025; Fri, 13 Mar 2009 14:32:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 67F24A05C41; Fri, 13 Mar 2009 14:32:11 +0100 (CET) Date: Fri, 13 Mar 2009 14:32:11 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090313133211.GC5286@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , "netmod@ietf.org" References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903131156.n2DBuZrH048598@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 13:31:55 -0000 On Fri, Mar 13, 2009 at 12:56:34PM +0100, Phil Shafer wrote: > More of a sticky issue is the 64/32/16/8. I'm no type guru, but > would we be better off with "integer" and "decimal" as the builtin > types and then derive all the [u]int[64,32,16,8] in yang-types? I > know we considered and discarded this earlier, but with decimal, > the issue becomes twice as ugly. An unlimited "integer" or "decimal" means that you better never use this base type directly since implementations will likely not support arbitrary precision integers and thus likely pick a random boundary. This is bad if you ask me. So I am big fan of base types that have well defined precision. Now, how many of those you need is a different discussion. For smart implementations that understand range restrictions, there is hardly a difference, except that you save some imports and qualified type names (yang:uint8 vs. uint8) when types with common precision are builtin. /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 Fri Mar 13 07:29: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 A3BA93A6804 for ; Fri, 13 Mar 2009 07:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 HOk9EyO284Rp for ; Fri, 13 Mar 2009 07:28:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A97993A680E for ; Fri, 13 Mar 2009 07:28:54 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 73F9776C4D7 for ; Fri, 13 Mar 2009 15:29:32 +0100 (CET) Message-ID: <49BA6DCC.7010601@tail-f.com> Date: Fri, 13 Mar 2009 15:29:32 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: "netmod@ietf.org" References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> In-Reply-To: <20090313133211.GC5286@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:29:03 -0000 On 2009-03-13 14:32, Juergen Schoenwaelder wrote: > On Fri, Mar 13, 2009 at 12:56:34PM +0100, Phil Shafer wrote: > >> More of a sticky issue is the 64/32/16/8. I'm no type guru, but >> would we be better off with "integer" and "decimal" as the builtin >> types and then derive all the [u]int[64,32,16,8] in yang-types? I >> know we considered and discarded this earlier, but with decimal, >> the issue becomes twice as ugly. > > An unlimited "integer" or "decimal" means that you better never use > this base type directly since implementations will likely not support > arbitrary precision integers and thus likely pick a random boundary. > This is bad if you ask me. So I am big fan of base types that have > well defined precision. Now, how many of those you need is a different > discussion. For smart implementations that understand range > restrictions, there is hardly a difference, except that you save some > imports and qualified type names (yang:uint8 vs. uint8) when types > with common precision are builtin. Also, if there should be variants, I don't see why they should follow the pattern of the integer types. This is not another integer type, in fact as the proposal is specifically to replace floats, those would be a more obvious parallel. No-one asks for signed vs unsigned, 16-bit, or 8-bit versions of floats, and even the case for a 32-bit float type is probably pretty weak. And FWIW, XML Schema defines a boatload of integer types (13 to be precise, 5 more than yang), but there is only one xs:decimal - it is signed, and requires 64 bits of storage in the unrestricted form. It seems to me that having only a signed decimal64 is adequate, but possibly an additional signed decimal32 could be motivated - the latter alternative would be a pretty good match for the float types currently defined in yang. --Per From balazs.lengyel@ericsson.com Fri Mar 13 09:02: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 B41F628C1D6 for ; Fri, 13 Mar 2009 09:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.271, 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 GKwpbPS8Q5Xa for ; Fri, 13 Mar 2009 09:02:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3A3A528C1F8 for ; Fri, 13 Mar 2009 09:01:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E2830218AB; Fri, 13 Mar 2009 17:02:30 +0100 (CET) X-AuditID: c1b4fb3e-af8a1bb0000023da-63-49ba8396ce6c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CD470211C5; Fri, 13 Mar 2009 17:02:30 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:02:30 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:02:30 +0100 Message-ID: <49BA8396.8050204@ericsson.com> Date: Fri, 13 Mar 2009 17:02:30 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Per Hedeland References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> <49B96929.6060905@tail-f.com> <49BA3AD6.6000203@ericsson.com> <49BA4AA3.2000508@tail-f.com> In-Reply-To: <49BA4AA3.2000508@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 16:02:30.0432 (UTC) FILETIME=[1CEC1A00:01C9A3F5] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:02:28 -0000 Per Hedeland wrote: >> 1..19 is fine or maybe 0..19 > > Don't agree. What I tried to say above is that 19 is no more special > than 20 or 21 - the special number is 18, which is the max number where > you can represent all values. E.g. you can't represent > > 0.9876543210987654321 > > even though that is 19 decimals. And I think 0 should be disallowed > because it's pointless (and possibly confusing) - don't use the decimal > type if you don't want any decimals, use an integer. I.e. my suggestion > is: 1..18 > > --Per > Fully agree I vote for 1..18 fractional-digits and no change in derived types to fractional-digits. Balazs From lhotka@cesnet.cz Fri Mar 13 09:05: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 0757128C10C for ; Fri, 13 Mar 2009 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_27=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 WpWeml7Asv-E for ; Fri, 13 Mar 2009 09:05:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BE74028C1BC for ; Fri, 13 Mar 2009 09:04:55 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 470AAD800C7 for ; Fri, 13 Mar 2009 17:05:34 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49BA6DCC.7010601@tail-f.com> References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 13 Mar 2009 17:05:34 +0100 Message-Id: <1236960335.6391.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:05:15 -0000 Per Hedeland píše v Pá 13. 03. 2009 v 15:29 +0100: > And FWIW, XML Schema defines a boatload of integer types (13 to be > precise, 5 more than yang), but there is only one xs:decimal - it is > signed, and requires 64 bits of storage in the unrestricted form. If I read the XSD spec correctly, this is only the minimum requirement (actually defined as 18 decimal digits), but in general the decimal numbers can be arbitrarily long. > > It seems to me that having only a signed decimal64 is adequate, but > possibly an additional signed decimal32 could be motivated - the latter > alternative would be a pretty good match for the float types currently > defined in yang. How about XPath expressions? Will floats be allowed there? Lada > > --Per > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Mar 13 09:08: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 EB6C33A6927 for ; Fri, 13 Mar 2009 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTPisIq2UqXL for ; Fri, 13 Mar 2009 09:08:28 -0700 (PDT) Received: from n11.bullet.mail.mud.yahoo.com (n11.bullet.mail.mud.yahoo.com [209.191.125.210]) by core3.amsl.com (Postfix) with SMTP id 9C1553A68F9 for ; Fri, 13 Mar 2009 09:07:56 -0700 (PDT) Received: from [68.142.194.244] by n11.bullet.mail.mud.yahoo.com with NNFMP; 13 Mar 2009 16:08:35 -0000 Received: from [68.142.201.240] by t2.bullet.mud.yahoo.com with NNFMP; 13 Mar 2009 16:08:35 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 13 Mar 2009 16:08:35 -0000 X-Yahoo-Newman-Id: 330483.53964.bm@omp401.mail.mud.yahoo.com Received: (qmail 57663 invoked from network); 13 Mar 2009 16:08:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 16:08:33 -0000 X-YMail-OSG: Avg_2eAVM1nFCLO7FuYxiXGOvxpDkZSNEGdycLKWuzmVDRwDabGuaL4abS9ZmOkwdPQa66FYEtN_bmkSEx4AOJYvZUM.H5euo41er44b6PF46zG3Oh4Z3v7p1oRt9j7vAotDzoSxMc_B05ujM_Jfolea X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BA8500.3060802@netconfcentral.com> Date: Fri, 13 Mar 2009 09:08:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <20090311.232948.101713012.mbj@tail-f.com> <49B935DF.3040408@netconfcentral.com> <20090312.203032.251524704.mbj@tail-f.com> <49B96929.6060905@tail-f.com> <49BA3AD6.6000203@ericsson.com> <49BA4AA3.2000508@tail-f.com> <49BA8396.8050204@ericsson.com> In-Reply-To: <49BA8396.8050204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:08:35 -0000 Balazs Lengyel wrote: > > > Per Hedeland wrote: >>> 1..19 is fine or maybe 0..19 >> >> Don't agree. What I tried to say above is that 19 is no more special >> than 20 or 21 - the special number is 18, which is the max number where >> you can represent all values. E.g. you can't represent >> >> 0.9876543210987654321 >> >> even though that is 19 decimals. And I think 0 should be disallowed >> because it's pointless (and possibly confusing) - don't use the decimal >> type if you don't want any decimals, use an integer. I.e. my suggestion >> is: 1..18 >> >> --Per >> > Fully agree I vote for 1..18 fractional-digits and no change in derived > types to fractional-digits. +1 > Balazs Andy From andy@netconfcentral.com Fri Mar 13 09:14: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 404D43A6A01 for ; Fri, 13 Mar 2009 09:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=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 xlLYRBCphnP4 for ; Fri, 13 Mar 2009 09:14:00 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id C312E3A68F9 for ; Fri, 13 Mar 2009 09:13:02 -0700 (PDT) Received: (qmail 29564 invoked from network); 13 Mar 2009 16:13:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 16:13:41 -0000 X-YMail-OSG: LVVYdY4VM1mxJ_CDJnrNVVzXYYjpBiZDGaxVw_IEIJA9amubg_FnzhPZHC4Z6l9fKmPCtx2.FCPccV.ogmHHgUAxpa1GNMN0EF6h6qPfVi4l.n2xDepH.3KhnSvvmuPYvEbi4hrmH8UldhGGbTYVpU9. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BA8633.6030407@netconfcentral.com> Date: Fri, 13 Mar 2009 09:13:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> <1236960335.6391.65.camel@missotis> In-Reply-To: <1236960335.6391.65.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:14:01 -0000 Ladislav Lhotka wrote: > Per Hedeland píše v Pá 13. 03. 2009 v 15:29 +0100: >> And FWIW, XML Schema defines a boatload of integer types (13 to be >> precise, 5 more than yang), but there is only one xs:decimal - it is >> signed, and requires 64 bits of storage in the unrestricted form. > > If I read the XSD spec correctly, this is only the minimum requirement > (actually defined as 18 decimal digits), but in general the decimal > numbers can be arbitrarily long. > The 'arbitrarily long' part is why it is not implementable. >> It seems to me that having only a signed decimal64 is adequate, but >> possibly an additional signed decimal32 could be motivated - the latter >> alternative would be a pretty good match for the float types currently >> defined in yang. > > How about XPath expressions? Will floats be allowed there? > All XPath numbers are IEEE 754 numbers. There are no YANG numbers in XPath. You have to convert the YANG number to 'double' to use it in must/when/select. > Lada > >> --Per Andy From lhotka@cesnet.cz Fri Mar 13 09:23: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 78D9D3A6A01 for ; Fri, 13 Mar 2009 09:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7eKldNKjwud for ; Fri, 13 Mar 2009 09:23:45 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BB5573A68F9 for ; Fri, 13 Mar 2009 09:23:45 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1F43BD800C7; Fri, 13 Mar 2009 17:24:24 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49BA8633.6030407@netconfcentral.com> References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> <1236960335.6391.65.camel@missotis> <49BA8633.6030407@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 13 Mar 2009 17:24:25 +0100 Message-Id: <1236961465.6391.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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:23:46 -0000 Andy Bierman píše v Pá 13. 03. 2009 v 09:13 -0700: > All XPath numbers are IEEE 754 numbers. > There are no YANG numbers in XPath. > You have to convert the YANG number to 'double' to > use it in must/when/select. Also literals such as 1e3 must be allowed there. Lada > > > Lada > > > >> --Per > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Mar 13 09:42: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 740F33A65A5 for ; Fri, 13 Mar 2009 09:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.195, 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 jCOj-HxelnQx for ; Fri, 13 Mar 2009 09:42:57 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 7EF3C3A69E0 for ; Fri, 13 Mar 2009 09:42:47 -0700 (PDT) Received: (qmail 45702 invoked from network); 13 Mar 2009 16:43:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 16:43:25 -0000 X-YMail-OSG: Yb2d.jUVM1nezwzLqOvwgrEg28jSYzNDxk8e1hH5XS2M22FCPlIbhtH.6VUg7TcrlD7HJxv9_TkPzSaTE4BK5SupI24AVKBJCnZmdIUkts74cVSkZepMUfXSSg1PqVkGPCkKUruePoU7oFE.CdWw3j3Y X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BA8D2C.90206@netconfcentral.com> Date: Fri, 13 Mar 2009 09:43:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> <1236960335.6391.65.camel@missotis> <49BA8633.6030407@netconfcentral.com> <1236961465.6391.70.camel@missotis> In-Reply-To: <1236961465.6391.70.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:42:58 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Pá 13. 03. 2009 v 09:13 -0700: > >> All XPath numbers are IEEE 754 numbers. >> There are no YANG numbers in XPath. >> You have to convert the YANG number to 'double' to >> use it in must/when/select. > > Also literals such as 1e3 must be allowed there. > I think literals must be quoted in XPath 1.0, e.g., '1e3'. 1e3 is an invalid number. Only the 11, or 11., or 11.111 forms are allowed, plus inv, -inv, and nan. > Lada > Andy From lhotka@cesnet.cz Fri Mar 13 09:54: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 EDC4928C20A for ; Fri, 13 Mar 2009 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.266 X-Spam-Level: X-Spam-Status: No, score=0.266 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRhi8HZP4VB0 for ; Fri, 13 Mar 2009 09:54:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DA0E628C1FF for ; Fri, 13 Mar 2009 09:54:46 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7E493D800CE; Fri, 13 Mar 2009 17:55:25 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49BA8D2C.90206@netconfcentral.com> References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> <1236960335.6391.65.camel@missotis> <49BA8633.6030407@netconfcentral.com> <1236961465.6391.70.camel@missotis> <49BA8D2C.90206@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 13 Mar 2009 17:55:26 +0100 Message-Id: <1236963326.6391.95.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:54:48 -0000 Andy Bierman píše v Pá 13. 03. 2009 v 09:43 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Pá 13. 03. 2009 v 09:13 -0700: > > > >> All XPath numbers are IEEE 754 numbers. > >> There are no YANG numbers in XPath. > >> You have to convert the YANG number to 'double' to > >> use it in must/when/select. > > > > Also literals such as 1e3 must be allowed there. > > > > I think literals must be quoted in XPath 1.0, e.g., '1e3'. > 1e3 is an invalid number. Only the 11, or 11., or 11.111 > forms are allowed, plus inv, -inv, and nan. No, "foo:bar=1e3" works (just tried it). Lada > > > Lada > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Mar 13 10:00: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 5D2F028C228 for ; Fri, 13 Mar 2009 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.189, 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 8UmwbpeX95Fg for ; Fri, 13 Mar 2009 10:00:47 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id AB34528C1F8 for ; Fri, 13 Mar 2009 10:00:47 -0700 (PDT) Received: (qmail 42901 invoked from network); 13 Mar 2009 17:01:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 17:01:26 -0000 X-YMail-OSG: 1OayaokVM1mxs0e9aRXLTwBaX7q9mw3pNDoNbhYcA_VlYgCPLMOM0hW6e9MUMWjEsSLbM9g7WN5S75578KKGinkf4EXbs9luUfAEPGX_L4yMXLtJCgVVqCtBpVEkuhkM23aQp7DpQtMtEUQd.SWNJ1gy X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BA9164.70103@netconfcentral.com> Date: Fri, 13 Mar 2009 10:01:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> <1236960335.6391.65.camel@missotis> <49BA8633.6030407@netconfcentral.com> <1236961465.6391.70.camel@missotis> <49BA8D2C.90206@netconfcentral.com> <1236963326.6391.95.camel@missotis> In-Reply-To: <1236963326.6391.95.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 17:00:48 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Pá 13. 03. 2009 v 09:43 -0700: >> Ladislav Lhotka wrote: >>> Andy Bierman píše v Pá 13. 03. 2009 v 09:13 -0700: >>> >>>> All XPath numbers are IEEE 754 numbers. >>>> There are no YANG numbers in XPath. >>>> You have to convert the YANG number to 'double' to >>>> use it in must/when/select. >>> Also literals such as 1e3 must be allowed there. >>> >> I think literals must be quoted in XPath 1.0, e.g., '1e3'. >> 1e3 is an invalid number. Only the 11, or 11., or 11.111 >> forms are allowed, plus inv, -inv, and nan. > > No, "foo:bar=1e3" works (just tried it). > From the XPath 1.0 spec: [29] Literal ::= '"' [^"]* '"' | "'" [^']* "'" [30] Number ::= Digits ('.' Digits?)? | '.' Digits [31] Digits ::= [0-9]+ Where in the EBNF is this form of number supported? > Lada > Andy From per@tail-f.com Fri Mar 13 11:21: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 5D3B428C119 for ; Fri, 13 Mar 2009 11:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 oWvmoKQa1Hvd for ; Fri, 13 Mar 2009 11:21:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9B05128C114 for ; Fri, 13 Mar 2009 11:21:15 -0700 (PDT) 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 6AD7276C4D7; Fri, 13 Mar 2009 19:21:53 +0100 (CET) Message-ID: <49BAA43C.9070704@tail-f.com> Date: Fri, 13 Mar 2009 19:21:48 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090312.203032.251524704.mbj@tail-f.com> <200903131156.n2DBuZrH048598@idle.juniper.net> <20090313133211.GC5286@elstar.local> <49BA6DCC.7010601@tail-f.com> <1236960335.6391.65.camel@missotis> In-Reply-To: <1236960335.6391.65.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 18:21:16 -0000 On 2009-03-13 17:05, Ladislav Lhotka wrote: > Per Hedeland píae v Pá 13. 03. 2009 v 15:29 +0100: >> And FWIW, XML Schema defines a boatload of integer types (13 to be >> precise, 5 more than yang), but there is only one xs:decimal - it is >> signed, and requires 64 bits of storage in the unrestricted form. > > If I read the XSD spec correctly, this is only the minimum requirement > (actually defined as 18 decimal digits), but in general the decimal > numbers can be arbitrarily long. Absolutely, that's what I meant by "requires". I.e. a minimum of 18 decimal digits, which translates to a minimum of 64 bits as long as your storage is in integral numbers of octets - the 18 was obviously not picked at random. The point was that they didn't see a need for a decimal type with a lower storage requirement, like they did with all the integer types. --Per From mbj@tail-f.com Fri Mar 13 12:55: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 3D1453A6909 for ; Fri, 13 Mar 2009 12:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=1.986, 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 Zs+U9T1BqQXW for ; Fri, 13 Mar 2009 12:55:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 756873A68CC for ; Fri, 13 Mar 2009 12:55:19 -0700 (PDT) Received: from localhost (host-217-213-99-41.mobileonline.telia.com [217.213.99.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 2A56776C4D7; Fri, 13 Mar 2009 20:55:54 +0100 (CET) Date: Fri, 13 Mar 2009 20:55:46 +0100 (CET) Message-Id: <20090313.205546.240156791.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090313112211.GA5072@elstar.local> References: <20090311.232948.101713012.mbj@tail-f.com> <20090313112211.GA5072@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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 19:55:20 -0000 Hi, Juergen Schoenwaelder wrote: > So which of the following subtyping examples are legal and what is the > resulting value space? Well, Balazs and Andy think that fraction-digits cannot be changed, but if we allow lowering this number, you'll get: > typedef A { > type dec64 { fraction-digits 2; range "0..100"; } > } 0 0.01 0.02 .. 99.99 100 > typedef B { > type A { fraction-digits 1; } > } 0 0.1 0.2 .. 99.9 100 > typedef C { > type A { fraction-digits 3; } > } not allowed - you cannot raise the number of fraction-digits. > typedef D { > type A { range "10.0..110.0"; } > } not allowed - high range too big. > typedef E { > type A { fraction-digits 1; range "10.0..110.0"; } > } not allowed - high range too big. /martin From andy@netconfcentral.com Fri Mar 13 13:53: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 0C46E3A6B20 for ; Fri, 13 Mar 2009 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 OYWBgjU089Fe for ; Fri, 13 Mar 2009 13:53:00 -0700 (PDT) Received: from n24.bullet.mail.mud.yahoo.com (n24.bullet.mail.mud.yahoo.com [68.142.206.163]) by core3.amsl.com (Postfix) with SMTP id 25CCA3A6AA3 for ; Fri, 13 Mar 2009 13:53:00 -0700 (PDT) Received: from [209.191.108.96] by n24.bullet.mail.mud.yahoo.com with NNFMP; 13 Mar 2009 20:53:39 -0000 Received: from [68.142.201.241] by t3.bullet.mud.yahoo.com with NNFMP; 13 Mar 2009 20:53:39 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 13 Mar 2009 20:53:39 -0000 X-Yahoo-Newman-Id: 10120.45786.bm@omp402.mail.mud.yahoo.com Received: (qmail 83006 invoked from network); 13 Mar 2009 20:53:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 20:53:38 -0000 X-YMail-OSG: Qh46NKQVM1lQ2rBpTbpZLG19Qx7Nj1CIZQfcBHOVN8XclEX5iKRbBF8yPnDB_Gp2ki_YeDyX9mpL5LIW4itI1pGML.VudZpO_GrXMTM1n0OzSe1cvbD5yvPm3H57lq3FRE2RyYKYMA9R11cvCkkbb5WHRLM95ZCmL7FkR7CyOjfLMEJnjtw6KpDW X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BAC7D0.1090601@netconfcentral.com> Date: Fri, 13 Mar 2009 13:53:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> <20090313112211.GA5072@elstar.local> <20090313.205546.240156791.mbj@tail-f.com> In-Reply-To: <20090313.205546.240156791.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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 20:53:01 -0000 Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: >> So which of the following subtyping examples are legal and what is the >> resulting value space? > > Well, Balazs and Andy think that fraction-digits cannot be changed, > but if we allow lowering this number, you'll get: > >> typedef A { >> type dec64 { fraction-digits 2; range "0..100"; } >> } > I do not like this extra complexity. What if there are a chain of typedefs so various properties are derived from different typedefs? typedef A { type dec64 { fraction-digits 2; range "0..99.99"; } } typedef B { type A { default 49.01; } } typedef C { type B { fraction-digits 1; range "1.1 .. max"; } } typedef D { type C { default 19.1; } } See how changing the precision (fraction-digits) breaks range and default? It is much better if decimal allows the same restrictions as any other number. No CLRs. No confusion. Typedef doesn't have the fraction-digits you need? Make a new typedef. You can make all the changes you want ;-) Andy > 0 0.01 0.02 .. 99.99 100 > >> typedef B { >> type A { fraction-digits 1; } >> } > > 0 0.1 0.2 .. 99.9 100 > >> typedef C { >> type A { fraction-digits 3; } >> } > > not allowed - you cannot raise the number of fraction-digits. > >> typedef D { >> type A { range "10.0..110.0"; } >> } > > not allowed - high range too big. > >> typedef E { >> type A { fraction-digits 1; range "10.0..110.0"; } >> } > > not allowed - high range too big. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From andy@netconfcentral.com Fri Mar 13 14:01: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 E196D3A680A for ; Fri, 13 Mar 2009 14:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.162, 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 ehYKkMYTLclA for ; Fri, 13 Mar 2009 14:01:04 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id B3F463A6AA3 for ; Fri, 13 Mar 2009 14:01:04 -0700 (PDT) Received: (qmail 49757 invoked from network); 13 Mar 2009 21:01:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 21:01:43 -0000 X-YMail-OSG: avyXphoVM1nKs8wUSRwRW5Qm5GoZRB.5oEWHcD9_nw5zLC.MbSu1S1s3RvYhxrBaWKAA0Tt5Je2wAC5WMPRcDjr_GEet4zWzMEG3KWNSsHKUpL8HJ75tStet_Ei59uM2AN.UhF5sXU6x1rrfjIeI8.0xcT86YrIa9rMTbls9M3jqPdj9ZI.aX7vH X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BAC9B5.8050809@netconfcentral.com> Date: Fri, 13 Mar 2009 14:01:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090311.232948.101713012.mbj@tail-f.com> <20090313112211.GA5072@elstar.local> <20090313.205546.240156791.mbj@tail-f.com> <49BAC7D0.1090601@netconfcentral.com> In-Reply-To: <49BAC7D0.1090601@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:01:06 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: >> Hi, >> >> Juergen Schoenwaelder wrote: >>> So which of the following subtyping examples are legal and what is the >>> resulting value space? >> >> Well, Balazs and Andy think that fraction-digits cannot be changed, >> but if we allow lowering this number, you'll get: >> >>> typedef A { >>> type dec64 { fraction-digits 2; range "0..100"; } >>> } >> > > I do not like this extra complexity. > What if there are a chain of typedefs > so various properties are derived from > different typedefs? > > > typedef A { > type dec64 { > fraction-digits 2; > range "0..99.99"; > } > } > > typedef B { > type A { > default 49.01; > } > } > > typedef C { > type B { > fraction-digits 1; > range "1.1 .. max"; > } > } > > typedef D { > type C { > default 19.1; > } > } > I got the syntax wrong (!) typedef A { type dec64 { fraction-digits 2; range "0..99.99"; } } typedef B { type A; default 49.01; } typedef C { type B { fraction-digits 1; range "1.1 .. max"; } } typedef D { type C; default 19.1; } Andy > > See how changing the precision (fraction-digits) > breaks range and default? It is much better > if decimal allows the same restrictions as > any other number. No CLRs. No confusion. > > Typedef doesn't have the fraction-digits you need? > Make a new typedef. > You can make all the changes you want ;-) > > > > Andy > > >> 0 0.01 0.02 .. 99.99 100 >> >>> typedef B { >>> type A { fraction-digits 1; } >>> } >> >> 0 0.1 0.2 .. 99.9 100 >> >>> typedef C { >>> type A { fraction-digits 3; } >>> } >> >> not allowed - you cannot raise the number of fraction-digits. >> >>> typedef D { >>> type A { range "10.0..110.0"; } >>> } >> >> not allowed - high range too big. >> >>> typedef E { >>> type A { fraction-digits 1; range "10.0..110.0"; } >>> } >> >> not allowed - high range too big. >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From mbj@tail-f.com Fri Mar 13 14:19: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 32CF23A6B4C for ; Fri, 13 Mar 2009 14:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=1.324, 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 LQ66lwloGLUz for ; Fri, 13 Mar 2009 14:19:26 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6D5CB3A6902 for ; Fri, 13 Mar 2009 14:19:26 -0700 (PDT) Received: from localhost (host-217-213-114-202.mobileonline.telia.com [217.213.114.202]) by mail.tail-f.com (Postfix) with ESMTPSA id A512E76C4D7; Fri, 13 Mar 2009 22:20:01 +0100 (CET) Date: Fri, 13 Mar 2009 22:19:56 +0100 (CET) Message-Id: <20090313.221956.210343928.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49BAC7D0.1090601@netconfcentral.com> References: <20090313112211.GA5072@elstar.local> <20090313.205546.240156791.mbj@tail-f.com> <49BAC7D0.1090601@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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:19:27 -0000 Andy Bierman wrote: > I do not like this extra complexity. > What if there are a chain of typedefs > so various properties are derived from > different typedefs? [...] > See how changing the precision (fraction-digits) > breaks range and default? Ok. But the same thing can happen with integers: typedef A { type int32; default 1; } typedef B { type A; range "2..max"; } However, the range issue convinced me. I agree that it's best to not allow fraction-digits to be changed. /martin From balazs.lengyel@ericsson.com Tue Mar 17 03:59: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 71DA03A692C for ; Tue, 17 Mar 2009 03:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 yZKIWtKqsKuq for ; Tue, 17 Mar 2009 03:59:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A0F013A67DA for ; Tue, 17 Mar 2009 03:59:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B26F227406 for ; Tue, 17 Mar 2009 11:59:55 +0100 (CET) X-AuditID: c1b4fb3e-ae89fbb0000023da-83-49bf74931494 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 317A121219 for ; Tue, 17 Mar 2009 10:59:47 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 10:59:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 10:59:07 +0100 Message-ID: <49BF746B.4060907@ericsson.com> Date: Tue, 17 Mar 2009 10:59: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: 17 Mar 2009 09:59:07.0978 (UTC) FILETIME=[034CA2A0:01C9A6E7] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] no augment in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 10:59:15 -0000 7.9.2 The choice's case Statement "Within a "case" statement, the "anyxml", "container", "leaf", "list", "leaf-list", "uses", and "augment" statements can be used to define child nodes to the case node." augment can not be the child of case, so please remove it from the sentence. Balazs From mbj@tail-f.com Tue Mar 17 04:01: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 31FBE3A6B2D for ; Tue, 17 Mar 2009 04:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaRTXAb3axof for ; Tue, 17 Mar 2009 04:01:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6230F3A6A94 for ; Tue, 17 Mar 2009 04:01:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B1C276C4FB; Tue, 17 Mar 2009 12:02:28 +0100 (CET) Date: Tue, 17 Mar 2009 12:02:28 +0100 (CET) Message-Id: <20090317.120228.142649305.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <49BF746B.4060907@ericsson.com> References: <49BF746B.4060907@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] no augment in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 11:01:47 -0000 Balazs Lengyel wrote: > 7.9.2 The choice's case Statement > "Within a "case" statement, the "anyxml", "container", "leaf", "list", > "leaf-list", "uses", and "augment" statements can be used to define child nodes > to the case node." > > augment can not be the child of case, so please remove it from the sentence. Done. /martin From reid@snmp.com Wed Mar 18 06:15: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 E212A3A6A64 for ; Wed, 18 Mar 2009 06:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIFWOi8VLmEH for ; Wed, 18 Mar 2009 06:15:27 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id F1B503A6AF3 for ; Wed, 18 Mar 2009 06:15:26 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA19515 for ; Wed, 18 Mar 2009 09:16:08 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA14467 for ; Wed, 18 Mar 2009 09:16:08 -0400 (EDT) Message-Id: <200903181316.JAA14467@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Fri, 14 Nov 2008 16:06:39 -0500. Date: Wed, 18 Mar 2009 09:16:07 -0400 Sender: reid@snmp.com Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:15:28 -0000 I don't think the issue discussed in this thread has been addressed in the current document. Or maybe it was addressed in a different way and I'm just missing it. -David Reid -------- Original Thread: David> If I have 2 different augments in the same module, do the leaf David> identifiers have to be unique? Below is an example, where ChannelNumber David> is used twice. I don't think that is legal, but I'm not sure what David> rule tells me it is not. David> David> module if { David> namespace "http://example.com/schema/interfaces" David> prefix "if"; David> David> container interfaces { David> list ifEntry { David> key "ifIndex"; David> David> leaf ifIndex { type uint32; } David> leaf ifDescr { type string; } David> leaf ifType { type iana:IfType; } David> leaf ifMtu { type int32; } David> } David> } David> David> augment "/if:interfaces/if:ifEntry" { David> when "if:ifType='ds0'"; David> leaf ChannelNumber { David> type ChannelNumber; David> } David> } David> David> augment "/if:interfaces/if:ifEntry" { David> when "if:ifDescr='xyz'"; David> leaf ChannelNumber { David> type ChannelNumber; David> } David> } David> } David> David> -David Reid Andy> good question. Andy> It applies to any usage of thew 'when' statement, not just augment. Andy> IMO, no -- otherwise you can end up with an invalid schema Andy> based on the value of arbitrary leaf value. All QName siblings Andy> need to be unique, regardless of when and if-feature values. Andy> Andy> Andy Martin> You're right that it is not supposed to be legal and also that some Martin> text is missing. I think we need a new rule in 6.2.1. From andy@netconfcentral.com Wed Mar 18 06:39: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 4E0E128C1B7 for ; Wed, 18 Mar 2009 06:39:27 -0700 (PDT) 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 iV9iIenwTF83 for ; Wed, 18 Mar 2009 06:39:26 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 8ABAD28C168 for ; Wed, 18 Mar 2009 06:39:26 -0700 (PDT) Received: (qmail 20827 invoked from network); 18 Mar 2009 13:40:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.36 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 18 Mar 2009 13:40:10 -0000 X-YMail-OSG: FMXryiYVM1nFSopwOsz6uptB69OAvYCH_oIHqZcHhqS7u6OXxPOBvXOZhptZ954tx2kaAwR7SqiGOa4mrqo8Gwme4B0NdQBALKk_6yH4RCLHCh4flOcYiMLS.lNIzjEbWd9.Rb7B4NcMnKPEbbj_BjlzfUdF.5r9lrpq95XMoChkDIHxVMh0vDGrywUT X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C0F9B8.40706@netconfcentral.com> Date: Wed, 18 Mar 2009 06:40:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Reid References: <200903181316.JAA14467@adminfs.snmp.com> In-Reply-To: <200903181316.JAA14467@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 13:39:27 -0000 David Reid wrote: > I don't think the issue discussed in this thread has been addressed in the > current document. Or maybe it was addressed in a different way and I'm just > missing it. This is not legal. At YANG-compile-time, all the sibling nodes in the same namespace must be unique. The when-stmt is evaluated at agent-run-time. You can have as many augment-stmts pointing at the same target as you want. Just use different names. (e.g., leaf ChannelNumber is declared twice). > > -David Reid Andy > > > -------- Original Thread: > > David> If I have 2 different augments in the same module, do the leaf > David> identifiers have to be unique? Below is an example, where ChannelNumber > David> is used twice. I don't think that is legal, but I'm not sure what > David> rule tells me it is not. > David> > David> module if { > David> namespace "http://example.com/schema/interfaces" > David> prefix "if"; > David> > David> container interfaces { > David> list ifEntry { > David> key "ifIndex"; > David> > David> leaf ifIndex { type uint32; } > David> leaf ifDescr { type string; } > David> leaf ifType { type iana:IfType; } > David> leaf ifMtu { type int32; } > David> } > David> } > David> > David> augment "/if:interfaces/if:ifEntry" { > David> when "if:ifType='ds0'"; > David> leaf ChannelNumber { > David> type ChannelNumber; > David> } > David> } > David> > David> augment "/if:interfaces/if:ifEntry" { > David> when "if:ifDescr='xyz'"; > David> leaf ChannelNumber { > David> type ChannelNumber; > David> } > David> } > David> } > David> > David> -David Reid > > > Andy> good question. > Andy> It applies to any usage of thew 'when' statement, not just augment. > Andy> IMO, no -- otherwise you can end up with an invalid schema > Andy> based on the value of arbitrary leaf value. All QName siblings > Andy> need to be unique, regardless of when and if-feature values. > Andy> > Andy> Andy > > > Martin> You're right that it is not supposed to be legal and also that some > Martin> text is missing. I think we need a new rule in 6.2.1. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From reid@snmp.com Wed Mar 18 06: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 9EECE3A6B60 for ; Wed, 18 Mar 2009 06:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqWzq6bG1zq4 for ; Wed, 18 Mar 2009 06:56:51 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 77FAC3A6B70 for ; Wed, 18 Mar 2009 06:56:50 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA23562; Wed, 18 Mar 2009 09:57:34 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA15225; Wed, 18 Mar 2009 09:57:33 -0400 (EDT) Message-Id: <200903181357.JAA15225@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 06:40:08 -0700. <49C0F9B8.40706@netconfcentral.com> Date: Wed, 18 Mar 2009 09:57:33 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:56:52 -0000 > This is not legal. > At YANG-compile-time, all the sibling nodes in > the same namespace must be unique. I agree that this should not be legal, I just can't find the text in the document that tells me it is not legal. From section 6.2.1, it looks like my 2 leafs named ChannelNumber are in different namespaces, therefore legal. My yang compiler does not report this as an error (which I think is wrong). -David Reid > > -------- Original Thread: > > > > David> If I have 2 different augments in the same module, do the leaf > > David> identifiers have to be unique? Below is an example, where ChannelNumber > > David> is used twice. I don't think that is legal, but I'm not sure what > > David> rule tells me it is not. > > David> > > David> module if { > > David> namespace "http://example.com/schema/interfaces" > > David> prefix "if"; > > David> > > David> container interfaces { > > David> list ifEntry { > > David> key "ifIndex"; > > David> > > David> leaf ifIndex { type uint32; } > > David> leaf ifDescr { type string; } > > David> leaf ifType { type iana:IfType; } > > David> leaf ifMtu { type int32; } > > David> } > > David> } > > David> > > David> augment "/if:interfaces/if:ifEntry" { > > David> when "if:ifType='ds0'"; > > David> leaf ChannelNumber { > > David> type ChannelNumber; > > David> } > > David> } > > David> > > David> augment "/if:interfaces/if:ifEntry" { > > David> when "if:ifDescr='xyz'"; > > David> leaf ChannelNumber { > > David> type ChannelNumber; > > David> } > > David> } > > David> } > > David> > > David> -David Reid > > > > > > Andy> good question. > > Andy> It applies to any usage of thew 'when' statement, not just augment. > > Andy> IMO, no -- otherwise you can end up with an invalid schema > > Andy> based on the value of arbitrary leaf value. All QName siblings > > Andy> need to be unique, regardless of when and if-feature values. > > Andy> > > Andy> Andy > > > > > > Martin> You're right that it is not supposed to be legal and also that some > > Martin> text is missing. I think we need a new rule in 6.2.1. > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > From andy@netconfcentral.com Wed Mar 18 07:12: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 BE0A528C17E for ; Wed, 18 Mar 2009 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khO7k2-wzmVa for ; Wed, 18 Mar 2009 07:12:44 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id EB7BE3A687C for ; Wed, 18 Mar 2009 07:12:41 -0700 (PDT) Received: (qmail 38131 invoked from network); 18 Mar 2009 14:13:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.36 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 18 Mar 2009 14:13:26 -0000 X-YMail-OSG: Mw2EU9gVM1l_PpYMdVbsNP7u6RgOB.kb2VywGbS..xjrcFJFIHRTgob26Hd.wJxUt8egGIYdBqQMWMt_2rLViEDZ0Wetm.V0YAf50aKNHS5B15okHezkuG7TEJlxkHAt0CcpHccgOWo3P7PqgMWba6zP9uFjuITFsLhWvhE.zzKJ1KGsBiy9u4rlUH2W X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C10184.9010108@netconfcentral.com> Date: Wed, 18 Mar 2009 07:13:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Reid References: <200903181357.JAA15225@adminfs.snmp.com> In-Reply-To: <200903181357.JAA15225@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 14:12:44 -0000 David Reid wrote: >> This is not legal. >> At YANG-compile-time, all the sibling nodes in >> the same namespace must be unique. > > I agree that this should not be legal, I just can't find the text in the > document that tells me it is not legal. From section 6.2.1, it looks like > my 2 leafs named ChannelNumber are in different namespaces, therefore legal. > which bullet in 6.2.1 makes you think these leafs are in different namespaces. Both augment-stmts are in the same namespace. > My yang compiler does not report this as an error (which I think is wrong). > which compiler? which version of YANG? Both augment-stmts are in the same module, and they both have the same target. > -David Reid Andy > > > >>> -------- Original Thread: >>> >>> David> If I have 2 different augments in the same module, do the leaf >>> David> identifiers have to be unique? Below is an example, where ChannelNumber >>> David> is used twice. I don't think that is legal, but I'm not sure what >>> David> rule tells me it is not. >>> David> >>> David> module if { >>> David> namespace "http://example.com/schema/interfaces" >>> David> prefix "if"; >>> David> >>> David> container interfaces { >>> David> list ifEntry { >>> David> key "ifIndex"; >>> David> >>> David> leaf ifIndex { type uint32; } >>> David> leaf ifDescr { type string; } >>> David> leaf ifType { type iana:IfType; } >>> David> leaf ifMtu { type int32; } >>> David> } >>> David> } >>> David> >>> David> augment "/if:interfaces/if:ifEntry" { >>> David> when "if:ifType='ds0'"; >>> David> leaf ChannelNumber { >>> David> type ChannelNumber; >>> David> } >>> David> } >>> David> >>> David> augment "/if:interfaces/if:ifEntry" { >>> David> when "if:ifDescr='xyz'"; >>> David> leaf ChannelNumber { >>> David> type ChannelNumber; >>> David> } >>> David> } >>> David> } >>> David> >>> David> -David Reid >>> >>> >>> Andy> good question. >>> Andy> It applies to any usage of thew 'when' statement, not just augment. >>> Andy> IMO, no -- otherwise you can end up with an invalid schema >>> Andy> based on the value of arbitrary leaf value. All QName siblings >>> Andy> need to be unique, regardless of when and if-feature values. >>> Andy> >>> Andy> Andy >>> >>> >>> Martin> You're right that it is not supposed to be legal and also that some >>> Martin> text is missing. I think we need a new rule in 6.2.1. >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> > > From lhotka@cesnet.cz Wed Mar 18 07:25: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 201593A6B72 for ; Wed, 18 Mar 2009 07:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=0.324, 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 1vcfS6vspecW for ; Wed, 18 Mar 2009 07:25:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EF5C43A6B69 for ; Wed, 18 Mar 2009 07:25:08 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4DD03D800BD; Wed, 18 Mar 2009 15:25:52 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49C0F9B8.40706@netconfcentral.com> References: <200903181316.JAA14467@adminfs.snmp.com> <49C0F9B8.40706@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 15:25:53 +0100 Message-Id: <1237386353.7368.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 14:25:13 -0000 Andy Bierman píše v St 18. 03. 2009 v 06:40 -0700: > David Reid wrote: > > I don't think the issue discussed in this thread has been addressed in the > > current document. Or maybe it was addressed in a different way and I'm just > > missing it. > > This is not legal. > At YANG-compile-time, all the sibling nodes in > the same namespace must be unique. The when-stmt > is evaluated at agent-run-time. You can have > as many augment-stmts pointing at the same target > as you want. Just use different names. > (e.g., leaf ChannelNumber is declared twice). I agree, except that such intra-module augments are not allowed anymore. Sec. 7.15: The "augment" statement allows a module or submodule to add to the schema tree defined in another module or submodule, and to add to the nodes from a grouping in a "uses" statement. The intended effect can be achieved simply this way: container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } leaf ChannelNumber { when "../if:ifType='ds0' or ../if:ifDescr='xyz'"; type ChannelNumber; } } } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From reid@snmp.com Wed Mar 18 07:31: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 8B5A33A6AA9 for ; Wed, 18 Mar 2009 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHDwbGiEExvy for ; Wed, 18 Mar 2009 07:31:31 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 85BB33A68DE for ; Wed, 18 Mar 2009 07:31:31 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA26519; Wed, 18 Mar 2009 10:32:14 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA15506; Wed, 18 Mar 2009 10:32:14 -0400 (EDT) Message-Id: <200903181432.KAA15506@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 07:13:24 -0700. <49C10184.9010108@netconfcentral.com> Date: Wed, 18 Mar 2009 10:32:14 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 14:31:32 -0000 > which bullet in 6.2.1 makes you think these leafs are in > different namespaces. Both augment-stmts are in the > same namespace. o All leafs, leaf-lists, lists, containers, choices, rpcs, and notifications defined within a parent node or at the top-level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the parent node of the case node's parent choice node. >From the statement above, I though that my 2 ChannelNumber leafs had different parents, therefore different namespaces. I think you are telling me that since they augment the same list, they really have the same parent and therefore share a namespace. Did I understand that correctly? > > > My yang compiler does not report this as an error (which I think is wrong). > > > > which compiler? > which version of YANG? It is the compiler I am developing, which is not yet complete. It was originally written for draft-ietf-netmod-yang-01.txt, and has been updated some since then. The reason I'm asking the question is that I don't think my compiler is doing the right thing, but I'm not seeing a rule in the spec that tells me why. -David Reid From andy@netconfcentral.com Wed Mar 18 07:47:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAE128C205 for ; Wed, 18 Mar 2009 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CSLEdd4UHs8 for ; Wed, 18 Mar 2009 07:47:35 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id D7BA028C1A0 for ; Wed, 18 Mar 2009 07:47:34 -0700 (PDT) Received: from [68.142.200.226] by n21.bullet.mail.mud.yahoo.com with NNFMP; 18 Mar 2009 14:48:19 -0000 Received: from [68.142.201.64] by t7.bullet.mud.yahoo.com with NNFMP; 18 Mar 2009 14:48:19 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 18 Mar 2009 14:48:19 -0000 X-Yahoo-Newman-Id: 218067.89312.bm@omp416.mail.mud.yahoo.com Received: (qmail 9911 invoked from network); 18 Mar 2009 14:48:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.36 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 18 Mar 2009 14:48:17 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C109B0.3010907@netconfcentral.com> Date: Wed, 18 Mar 2009 07:48:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Reid References: <200903181432.KAA15506@adminfs.snmp.com> In-Reply-To: <200903181432.KAA15506@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 14:47:35 -0000 David Reid wrote: >> which bullet in 6.2.1 makes you think these leafs are in >> different namespaces. Both augment-stmts are in the >> same namespace. > > o All leafs, leaf-lists, lists, containers, choices, rpcs, and > notifications defined within a parent node or at the top-level of > the module or its submodules share the same identifier namespace. > This namespace is scoped to the parent node or module, unless the > parent node is a case node. In that case, the namespace is scoped > to the parent node of the case node's parent choice node. > >>From the statement above, I though that my 2 ChannelNumber leafs had different > parents, therefore different namespaces. I think you are telling me that since > they augment the same list, they really have the same parent and therefore > share a namespace. Did I understand that correctly? > yes. what matters is the conceptual 'composite' object tree that is built from all the uses/refine/augment/deviations details. This applies to any sibling nodes (could be top-level). >>> My yang compiler does not report this as an error (which I think is wrong). >>> >> which compiler? >> which version of YANG? > > It is the compiler I am developing, which is not yet complete. It was > originally written for draft-ietf-netmod-yang-01.txt, and has been updated > some since then. The reason I'm asking the question is that I don't think > my compiler is doing the right thing, but I'm not seeing a rule in the spec > that tells me why. > Wow! Where can I get one of those spec-reading-code-writing machines? :-) (yang-01 is so ancient... One hopes that YANG will eventually stabilize. It is mostly pointless to implement tools now.) > -David Reid > > Andy From reid@snmp.com Wed Mar 18 07:54:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1444B28C0E6 for ; Wed, 18 Mar 2009 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSm2-RwMg-ZQ for ; Wed, 18 Mar 2009 07:54:49 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 36A533A679C for ; Wed, 18 Mar 2009 07:54:49 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA28512; Wed, 18 Mar 2009 10:55:33 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA15703; Wed, 18 Mar 2009 10:55:32 -0400 (EDT) Message-Id: <200903181455.KAA15703@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 15:25:53 +0100. <1237386353.7368.38.camel@missotis> Date: Wed, 18 Mar 2009 10:55:32 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 14:54:50 -0000 > I agree, except that such intra-module augments are not allowed anymore. Good point. I missed that. > > Sec. 7.15: > The "augment" statement allows a module or submodule to add to the > schema tree defined in another module or submodule, and to add to the > nodes from a grouping in a "uses" statement. > This causes me another problem. I'm trying to make SNMP MIB data available over netconf with yang. If I can't augment a list in the same module, I'm not sure what to do with SNMP MIBs that augment tables in the same module. For example, in IF-MIB, ifXEntry augments ifEntry. -David Reid From reid@snmp.com Wed Mar 18 08:29: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 360903A6AA7 for ; Wed, 18 Mar 2009 08:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7M2sn1mB3JA for ; Wed, 18 Mar 2009 08:29:23 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 435203A679C for ; Wed, 18 Mar 2009 08:29:23 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA01146; Wed, 18 Mar 2009 11:30:06 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA17073; Wed, 18 Mar 2009 11:30:06 -0400 (EDT) Message-Id: <200903181530.LAA17073@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 15:25:53 +0100. <1237386353.7368.38.camel@missotis> Date: Wed, 18 Mar 2009 11:30:06 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 15:29:24 -0000 > I agree, except that such intra-module augments are not allowed anymore. Let me change my example slightly and put the augments in different submodules. Now I don't have an intra-module augments. If I understand Andy correctly, my compiler should still flag this as an error because I can know at compile time that ifEntry would end up with 2 leafs named ChannelNumber. Is that right? module if { namespace "http://example.com/schema/interfaces"; prefix "if"; include A; include B; container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } } submodule A { belongs-to if { prefix if; } augment "/if:interfaces/if:ifEntry" { when "if:ifType='ds0'"; leaf ChannelNumber { type int32; } } } submodule B { belongs-to if { prefix if; } augment "/if:interfaces/if:ifEntry" { when "if:Descr='xyz'"; leaf ChannelNumber { type int32; } } } -David Reid From lhotka@cesnet.cz Wed Mar 18 08:43: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 0EFD53A6808 for ; Wed, 18 Mar 2009 08:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.316, 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 Ax77XwIW1Mm1 for ; Wed, 18 Mar 2009 08:43:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3D3143A6403 for ; Wed, 18 Mar 2009 08:43:11 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2EE41D800C8; Wed, 18 Mar 2009 16:43:55 +0100 (CET) From: Ladislav Lhotka To: David Reid In-Reply-To: <200903181530.LAA17073@adminfs.snmp.com> References: <200903181530.LAA17073@adminfs.snmp.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 16:43:55 +0100 Message-Id: <1237391036.7368.75.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 15:43:12 -0000 David Reid píše v St 18. 03. 2009 v 11:30 -0400: > > I agree, except that such intra-module augments are not allowed anymore. > > Let me change my example slightly and put the augments in different submodules. > Now I don't have an intra-module augments. If I understand Andy correctly, my > compiler should still flag this as an error because I can know at compile time > that ifEntry would end up with 2 leafs named ChannelNumber. Is that right? I think so, and also if the augments were in stand-alone modules, but probably only if all three modules were compiled together - I assume an import statement by itself doesn't apply the augment from the imported module. Lada > > module if { > namespace "http://example.com/schema/interfaces"; > prefix "if"; > include A; > include B; > > container interfaces { > list ifEntry { > key "ifIndex"; > > leaf ifIndex { type uint32; } > leaf ifDescr { type string; } > leaf ifType { type iana:IfType; } > leaf ifMtu { type int32; } > } > } > } > > submodule A { > belongs-to if { prefix if; } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='ds0'"; > leaf ChannelNumber { > type int32; > } > } > } > > submodule B { > belongs-to if { prefix if; } > > augment "/if:interfaces/if:ifEntry" { > when "if:Descr='xyz'"; > leaf ChannelNumber { > type int32; > } > } > } > > -David Reid -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Mar 18 09:00: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 E40A33A68B4 for ; Wed, 18 Mar 2009 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=0.308, 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 Qkb+HSfDPkGm for ; Wed, 18 Mar 2009 09:00:25 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2A5243A6928 for ; Wed, 18 Mar 2009 09:00:25 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 82920D800C8 for ; Wed, 18 Mar 2009 17:01:09 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <200903181455.KAA15703@adminfs.snmp.com> References: <200903181455.KAA15703@adminfs.snmp.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 17:01:10 +0100 Message-Id: <1237392070.7368.80.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:00:26 -0000 David Reid píše v St 18. 03. 2009 v 10:55 -0400: > > This causes me another problem. I'm trying to make SNMP MIB data available over > netconf with yang. If I can't augment a list in the same module, I'm not sure > what to do with SNMP MIBs that augment tables in the same module. For example, > in IF-MIB, ifXEntry augments ifEntry. One option is to rewrite the original table definition and another to put the list in a grouping and then augment it inside "uses". Lada > > -David Reid -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From reid@snmp.com Wed Mar 18 09:03: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 2DA3D3A6856 for ; Wed, 18 Mar 2009 09:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlTxwQSr3B0j for ; Wed, 18 Mar 2009 09:03:30 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 3EB3B3A6839 for ; Wed, 18 Mar 2009 09:03:30 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA03069; Wed, 18 Mar 2009 12:04:14 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA18089; Wed, 18 Mar 2009 12:04:13 -0400 (EDT) Message-Id: <200903181604.MAA18089@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 16:43:55 +0100. <1237391036.7368.75.camel@missotis> Date: Wed, 18 Mar 2009 12:04:13 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 16:03:31 -0000 > I think so, and also if the augments were in stand-alone modules, but > probably only if all three modules were compiled together - I assume an > import statement by itself doesn't apply the augment from the imported > module. Let me change the example one more time and put the 2 augments in stand-alone modules. I think this example is legal and should not generate a compile error. module if { namespace "http://example.com/schema/interfaces"; prefix "if"; include A; include B; container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } } module A { namespace "http://example.com/schema/A"; import if { prefix if; } augment "/if:interfaces/if:ifEntry" { when "if:ifType='ds0'"; leaf ChannelNumber { type int32; } } } module B { namespace "http://example.com/schema/B"; import if { prefix if; } augment "/if:interfaces/if:ifEntry" { when "if:Descr='xyz'"; leaf ChannelNumber { type int32; } } } -David Reid From balazs.lengyel@ericsson.com Wed Mar 18 09:15: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 51ACB3A6839 for ; Wed, 18 Mar 2009 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.180, 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 zY1XHh2JhuGB for ; Wed, 18 Mar 2009 09:15:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 430DC3A67FC for ; Wed, 18 Mar 2009 09:15:58 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A749920452; Wed, 18 Mar 2009 17:16:39 +0100 (CET) X-AuditID: c1b4fb3c-a7459bb000003f3f-33-49c11e672bcf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 84E4C20413; Wed, 18 Mar 2009 17:16:39 +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, 18 Mar 2009 17:16:34 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 17:16:34 +0100 Message-ID: <49C11E62.8080209@ericsson.com> Date: Wed, 18 Mar 2009 17:16:34 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Reid References: <200903181604.MAA18089@adminfs.snmp.com> In-Reply-To: <200903181604.MAA18089@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2009 16:16:34.0600 (UTC) FILETIME=[E826AA80:01C9A7E4] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:15:59 -0000 You can't include a module, only a submodule, so it should be import. After that is should be legal. Balazs David Reid wrote: >> I think so, and also if the augments were in stand-alone modules, but >> probably only if all three modules were compiled together - I assume an >> import statement by itself doesn't apply the augment from the imported >> module. > > Let me change the example one more time and put the 2 augments in stand-alone > modules. I think this example is legal and should not generate a compile > error. > > module if { > namespace "http://example.com/schema/interfaces"; > prefix "if"; > include A; > include B; > > container interfaces { > list ifEntry { > key "ifIndex"; > > leaf ifIndex { type uint32; } > leaf ifDescr { type string; } > leaf ifType { type iana:IfType; } > leaf ifMtu { type int32; } > } > } > } > > module A { > namespace "http://example.com/schema/A"; > import if { prefix if; } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='ds0'"; > leaf ChannelNumber { > type int32; > } > } > } > > module B { > namespace "http://example.com/schema/B"; > import if { prefix if; } > > augment "/if:interfaces/if:ifEntry" { > when "if:Descr='xyz'"; > leaf ChannelNumber { > type int32; > } > } > } > > -David Reid > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From lhotka@cesnet.cz Wed Mar 18 09:23: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 707463A6A10 for ; Wed, 18 Mar 2009 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=0.301, 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 BtO+XFdUiQeM for ; Wed, 18 Mar 2009 09:23:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 695E33A69D3 for ; Wed, 18 Mar 2009 09:23:32 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D9D38D800C8; Wed, 18 Mar 2009 17:24:15 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <49C11E62.8080209@ericsson.com> References: <200903181604.MAA18089@adminfs.snmp.com> <49C11E62.8080209@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 17:24:16 +0100 Message-Id: <1237393456.7368.85.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:23:33 -0000 Balazs Lengyel píše v St 18. 03. 2009 v 17:16 +0100: > You can't include a module, only a submodule, so it should be import. After that is should be > legal. Hmm, I probably don't understand what "compile" precisely means, but if an agent advertised all three modules in , then it looks like a problem. Lada > Balazs > > David Reid wrote: > >> I think so, and also if the augments were in stand-alone modules, but > >> probably only if all three modules were compiled together - I assume an > >> import statement by itself doesn't apply the augment from the imported > >> module. > > > > Let me change the example one more time and put the 2 augments in stand-alone > > modules. I think this example is legal and should not generate a compile > > error. > > > > module if { > > namespace "http://example.com/schema/interfaces"; > > prefix "if"; > > include A; > > include B; > > > > container interfaces { > > list ifEntry { > > key "ifIndex"; > > > > leaf ifIndex { type uint32; } > > leaf ifDescr { type string; } > > leaf ifType { type iana:IfType; } > > leaf ifMtu { type int32; } > > } > > } > > } > > > > module A { > > namespace "http://example.com/schema/A"; > > import if { prefix if; } > > > > augment "/if:interfaces/if:ifEntry" { > > when "if:ifType='ds0'"; > > leaf ChannelNumber { > > type int32; > > } > > } > > } > > > > module B { > > namespace "http://example.com/schema/B"; > > import if { prefix if; } > > > > augment "/if:interfaces/if:ifEntry" { > > when "if:Descr='xyz'"; > > leaf ChannelNumber { > > type int32; > > } > > } > > } > > > > -David Reid > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Mar 18 09:26: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 E66A23A6941 for ; Wed, 18 Mar 2009 09:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2ezSc1YGy6z for ; Wed, 18 Mar 2009 09:26:52 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 422083A6806 for ; Wed, 18 Mar 2009 09:26:52 -0700 (PDT) Received: (qmail 37076 invoked from network); 18 Mar 2009 16:27:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.36 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 18 Mar 2009 16:27:36 -0000 X-YMail-OSG: KonaXHkVM1n6F6uL9B9oNNzhfPTU1MBXJyYguVgdYYi3pQCosLX1QRQkw0IH.2iPWx.D8yQfPaezH6AsB5wye.Wk2j5LdUUC.He8qcj686bUrqmc_Ab0TCFysUPLbqzQygv_PadCmldUmfPdJ5fACn2dxaqopTaJtJbhv6k0w1pXATl.oG6t11BUNMuj X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C120F6.30802@netconfcentral.com> Date: Wed, 18 Mar 2009 09:27:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <200903181604.MAA18089@adminfs.snmp.com> <49C11E62.8080209@ericsson.com> In-Reply-To: <49C11E62.8080209@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:26:53 -0000 Balazs Lengyel wrote: > You can't include a module, only a submodule, so it should be import. > After that is should be legal. I disagree. One of the 2 submodules (A or B) is going to go first, and add leaf channelNumber. Then the other submodule (which does not know about the first one) will also try to add a leaf named channelNumber. But this time there will already be one present. It is no different than if channelNumber were part of the original ifEntry list. The correct solution is the one Lada suggested. > Balazs Andy > > David Reid wrote: >>> I think so, and also if the augments were in stand-alone modules, but >>> probably only if all three modules were compiled together - I assume an >>> import statement by itself doesn't apply the augment from the imported >>> module. >> >> Let me change the example one more time and put the 2 augments in >> stand-alone >> modules. I think this example is legal and should not generate a compile >> error. >> module if { >> namespace "http://example.com/schema/interfaces"; >> prefix "if"; >> include A; >> include B; >> >> container interfaces { >> list ifEntry { >> key "ifIndex"; >> >> leaf ifIndex { type uint32; } >> leaf ifDescr { type string; } >> leaf ifType { type iana:IfType; } >> leaf ifMtu { type int32; } >> } >> } >> } >> >> module A { >> namespace "http://example.com/schema/A"; >> import if { prefix if; } >> >> augment "/if:interfaces/if:ifEntry" { >> when "if:ifType='ds0'"; >> leaf ChannelNumber { >> type int32; >> } >> } >> } >> >> module B { >> namespace "http://example.com/schema/B"; >> import if { prefix if; } >> >> augment "/if:interfaces/if:ifEntry" { >> when "if:Descr='xyz'"; >> leaf ChannelNumber { >> type int32; >> } >> } >> } >> >> -David Reid >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From reid@snmp.com Wed Mar 18 10:11: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 7A53728C1D6 for ; Wed, 18 Mar 2009 10:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUFqQ8ZeGHO0 for ; Wed, 18 Mar 2009 10:11:57 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7078528C1D5 for ; Wed, 18 Mar 2009 10:11:57 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA07955; Wed, 18 Mar 2009 13:12:32 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA18807; Wed, 18 Mar 2009 13:12:32 -0400 (EDT) Message-Id: <200903181712.NAA18807@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 09:27:34 -0700. <49C120F6.30802@netconfcentral.com> Date: Wed, 18 Mar 2009 13:12:32 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:11:58 -0000 > I disagree. > One of the 2 submodules (A or B) is going > to go first, and add leaf channelNumber. > Then the other submodule (which does not know about > the first one) will also try to add a leaf > named channelNumber. But this time there will > already be one present. It is no different > than if channelNumber were part of the original > ifEntry list. In the case where the augments are in different yang modules, the 2 ChannelNumbers will be in different XML namespaces, which is why I thought it would be legal. > > The correct solution is the one Lada suggested. I agree that my example is a bit contrived. My goal is to make sure that the spec is clear and that my implementation is correct. -David Reid > > > > David Reid wrote: > >>> I think so, and also if the augments were in stand-alone modules, but > >>> probably only if all three modules were compiled together - I assume an > >>> import statement by itself doesn't apply the augment from the imported > >>> module. > >> > >> Let me change the example one more time and put the 2 augments in > >> stand-alone > >> modules. I think this example is legal and should not generate a compile > >> error. > >> module if { > >> namespace "http://example.com/schema/interfaces"; > >> prefix "if"; > >> include A; > >> include B; > >> > >> container interfaces { > >> list ifEntry { > >> key "ifIndex"; > >> > >> leaf ifIndex { type uint32; } > >> leaf ifDescr { type string; } > >> leaf ifType { type iana:IfType; } > >> leaf ifMtu { type int32; } > >> } > >> } > >> } > >> > >> module A { > >> namespace "http://example.com/schema/A"; > >> import if { prefix if; } > >> > >> augment "/if:interfaces/if:ifEntry" { > >> when "if:ifType='ds0'"; > >> leaf ChannelNumber { > >> type int32; > >> } > >> } > >> } > >> > >> module B { > >> namespace "http://example.com/schema/B"; > >> import if { prefix if; } > >> > >> augment "/if:interfaces/if:ifEntry" { > >> when "if:Descr='xyz'"; > >> leaf ChannelNumber { > >> type int32; > >> } > >> } > >> } > >> > >> -David Reid > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > From reid@snmp.com Wed Mar 18 10:48: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 CAFA93A6B69 for ; Wed, 18 Mar 2009 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17uc+YKmz9u6 for ; Wed, 18 Mar 2009 10:48:18 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id CB7223A6979 for ; Wed, 18 Mar 2009 10:48:17 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA10682 for ; Wed, 18 Mar 2009 13:48:59 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA19229 for ; Wed, 18 Mar 2009 13:48:54 -0400 (EDT) Message-Id: <200903181748.NAA19229@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 18 Mar 2009 13:48:54 -0400 From: David Reid Subject: [netmod] intra-module augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 17:48:18 -0000 >From a discussion on a different thread, Lada said: > I agree, except that such intra-module augments are not allowed anymore. > > Sec. 7.15: > The "augment" statement allows a module or submodule to add to the > schema tree defined in another module or submodule, and to add to the > nodes from a grouping in a "uses" statement. Why are intra-module augments not allowed? If a submodule can augment a list in the module it belongs to, I don't see any reason an augment statement in a module can't augment a list in the same module. -David Reid From reid@snmp.com Wed Mar 18 10:53: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 195593A6826 for ; Wed, 18 Mar 2009 10:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWg9rgxHMkWC for ; Wed, 18 Mar 2009 10:53:56 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 0C6953A6B10 for ; Wed, 18 Mar 2009 10:53:55 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA11264; Wed, 18 Mar 2009 13:54:39 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA19701; Wed, 18 Mar 2009 13:54:39 -0400 (EDT) Message-Id: <200903181754.NAA19701@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 17:24:16 +0100. <1237393456.7368.85.camel@missotis> Date: Wed, 18 Mar 2009 13:54:39 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:53:57 -0000 Why would it be a problem to advertise all three? -David Reid > Balazs Lengyel: > > You can't include a module, only a submodule, so it should be import. After that is should be > > legal. > > Hmm, I probably don't understand what "compile" precisely means, but if > an agent advertised all three modules in , then it looks like a > problem. > > Lada > > > Balazs > > > > David Reid wrote: > > >> I think so, and also if the augments were in stand-alone modules, but > > >> probably only if all three modules were compiled together - I assume an > > >> import statement by itself doesn't apply the augment from the imported > > >> module. > > > > > > Let me change the example one more time and put the 2 augments in stand-alone > > > modules. I think this example is legal and should not generate a compile > > > error. > > > > > > module if { > > > namespace "http://example.com/schema/interfaces"; > > > prefix "if"; > > > include A; > > > include B; > > > > > > container interfaces { > > > list ifEntry { > > > key "ifIndex"; > > > > > > leaf ifIndex { type uint32; } > > > leaf ifDescr { type string; } > > > leaf ifType { type iana:IfType; } > > > leaf ifMtu { type int32; } > > > } > > > } > > > } > > > > > > module A { > > > namespace "http://example.com/schema/A"; > > > import if { prefix if; } > > > > > > augment "/if:interfaces/if:ifEntry" { > > > when "if:ifType='ds0'"; > > > leaf ChannelNumber { > > > type int32; > > > } > > > } > > > } > > > > > > module B { > > > namespace "http://example.com/schema/B"; > > > import if { prefix if; } > > > > > > augment "/if:interfaces/if:ifEntry" { > > > when "if:Descr='xyz'"; > > > leaf ChannelNumber { > > > type int32; > > > } > > > } > > > } > > > > > > -David Reid > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Mar 18 12:48:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20533A6A34 for ; Wed, 18 Mar 2009 12:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.083, 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 jJ0YDnlzn1iN for ; Wed, 18 Mar 2009 12:48:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D8BF23A6960 for ; Wed, 18 Mar 2009 12:48:10 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D27176C557; Wed, 18 Mar 2009 20:48:54 +0100 (CET) Date: Wed, 18 Mar 2009 20:48:53 +0100 (CET) Message-Id: <20090318.204853.148876471.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200903181748.NAA19229@adminfs.snmp.com> References: <200903181748.NAA19229@adminfs.snmp.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] intra-module augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 19:48:11 -0000 David Reid wrote: > From a discussion on a different thread, Lada said: > > > I agree, except that such intra-module augments are not allowed anymore. > > > > Sec. 7.15: > > The "augment" statement allows a module or submodule to add to the > > schema tree defined in another module or submodule, and to add to the > > nodes from a grouping in a "uses" statement. > > Why are intra-module augments not allowed? "Whoops". This was not the intention. It seems this text has been there from -00. Compare with the text in 4.2.8: 4.2.8. Extending Data Models (augment) YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) or an external module. 7.15 should use the same words. > If a submodule can augment a list in the module it belongs to, I don't see > any reason an augment statement in a module can't augment a list in the > same module. Exactly. Thanks for spotting this! /martin From lhotka@cesnet.cz Wed Mar 18 13:02: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 D83673A6B9B for ; Wed, 18 Mar 2009 13:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=0.294, 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 L7M2HyDl17c7 for ; Wed, 18 Mar 2009 13:02:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C99953A6B98 for ; Wed, 18 Mar 2009 13:02:14 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9E097D800BD; Wed, 18 Mar 2009 21:02:58 +0100 (CET) From: Ladislav Lhotka To: David Reid In-Reply-To: <200903181754.NAA19701@adminfs.snmp.com> References: <200903181754.NAA19701@adminfs.snmp.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 21:02:57 +0100 Message-Id: <1237406577.6392.0.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:02:15 -0000 David Reid píše v St 18. 03. 2009 v 13:54 -0400: > Why would it be a problem to advertise all three? Oh yes, I forgot about the difference in namespaces, sorry for the confusion. Lada > > -David Reid > > > > Balazs Lengyel: > > > You can't include a module, only a submodule, so it should be import. After that is should be > > > legal. > > > > Hmm, I probably don't understand what "compile" precisely means, but if > > an agent advertised all three modules in , then it looks like a > > problem. > > > > Lada > > > > > Balazs > > > > > > David Reid wrote: > > > >> I think so, and also if the augments were in stand-alone modules, but > > > >> probably only if all three modules were compiled together - I assume an > > > >> import statement by itself doesn't apply the augment from the imported > > > >> module. > > > > > > > > Let me change the example one more time and put the 2 augments in stand-alone > > > > modules. I think this example is legal and should not generate a compile > > > > error. > > > > > > > > module if { > > > > namespace "http://example.com/schema/interfaces"; > > > > prefix "if"; > > > > include A; > > > > include B; > > > > > > > > container interfaces { > > > > list ifEntry { > > > > key "ifIndex"; > > > > > > > > leaf ifIndex { type uint32; } > > > > leaf ifDescr { type string; } > > > > leaf ifType { type iana:IfType; } > > > > leaf ifMtu { type int32; } > > > > } > > > > } > > > > } > > > > > > > > module A { > > > > namespace "http://example.com/schema/A"; > > > > import if { prefix if; } > > > > > > > > augment "/if:interfaces/if:ifEntry" { > > > > when "if:ifType='ds0'"; > > > > leaf ChannelNumber { > > > > type int32; > > > > } > > > > } > > > > } > > > > > > > > module B { > > > > namespace "http://example.com/schema/B"; > > > > import if { prefix if; } > > > > > > > > augment "/if:interfaces/if:ifEntry" { > > > > when "if:Descr='xyz'"; > > > > leaf ChannelNumber { > > > > type int32; > > > > } > > > > } > > > > } > > > > > > > > -David Reid > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Mar 18 13:03: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 747C43A6809 for ; Wed, 18 Mar 2009 13:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 60+5bJ0qi3vg for ; Wed, 18 Mar 2009 13:03:45 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 6FD8E3A6835 for ; Wed, 18 Mar 2009 13:03:45 -0700 (PDT) Received: (qmail 71974 invoked from network); 18 Mar 2009 20:04:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.36 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 18 Mar 2009 20:04:29 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C153CB.5020108@netconfcentral.com> Date: Wed, 18 Mar 2009 13:04:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Reid References: <200903181712.NAA18807@adminfs.snmp.com> In-Reply-To: <200903181712.NAA18807@adminfs.snmp.com> Content-Type: multipart/mixed; boundary="------------040009040502030809030901" Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:03:46 -0000 This is a multi-part message in MIME format. --------------040009040502030809030901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Reid wrote: >> I disagree. >> One of the 2 submodules (A or B) is going >> to go first, and add leaf channelNumber. >> Then the other submodule (which does not know about >> the first one) will also try to add a leaf >> named channelNumber. But this time there will >> already be one present. It is no different >> than if channelNumber were part of the original >> ifEntry list. > > In the case where the augments are in different yang modules, the 2 > ChannelNumbers will be in different XML namespaces, which is why I thought > it would be legal. > >> The correct solution is the one Lada suggested. > > I agree that my example is a bit contrived. My goal is to make sure that > the spec is clear and that my implementation is correct. > I tested your files with a new version of yangdump to see what would happen. I attached the (really short) files: if.yang == top level module A.yang == submodule A B.yang == submodule B C.orig.yang == guts of if.yang moved to a submodule, with 'iana' bug (A submodule cannot access stuff in the main module.) C.yang == guts of if.yang moved to a submodule, with 'iana' bug logfile_AB == yangdump results with C.orig.yang, with include A before include B logfile_BA == yangdump results with C.orig.yang, with include B before include A logfile_AB2 == yangdump results with C.yang, with include A before include B logfile_BA2 == yangdump results with C.yang, with include B before include A Notes: 1) logfile_AB, logfile_BA: the Xpath 'when' target 'if:ifType' is not found in yangdump because the 'ifType' leaf had an invalid data type, and was not added to 'ifEntry' for further error reporting 2) logfile_AB2: since 'include A' is first, its 'channelNumber' gets added to ifEntry just fine. No when-stmt bug in this one. The channelNumber in submodule 'B' does not get checked further, after the duplicate is found. 3) logfile_BA2: since 'include B' is first, its version of channelNumber is used, and its when-stmt is tested, and the 'if:Descr' error is reported > -David Reid Andy --------------040009040502030809030901 Content-Type: text/plain; name="if.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if.yang" module if { namespace "http://example.com/schema/interfaces"; prefix "if"; include A; include B; } --------------040009040502030809030901 Content-Type: text/plain; name="A.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="A.yang" submodule A { belongs-to if { prefix if; } include C; augment "/if:interfaces/if:ifEntry" { when "if:ifType='ds0'"; leaf ChannelNumber { type int32; } } } --------------040009040502030809030901 Content-Type: text/plain; name="B.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="B.yang" submodule B { belongs-to if { prefix if; } include C; augment "/if:interfaces/if:ifEntry" { when "if:Descr='xyz'"; leaf ChannelNumber { type int32; } } } --------------040009040502030809030901 Content-Type: text/plain; name="C.orig.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="C.orig.yang" submodule C { belongs-to if { prefix if; } container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } } --------------040009040502030809030901 Content-Type: text/plain; name="C.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="C.yang" submodule C { belongs-to if { prefix if; } container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type string; } leaf ifMtu { type int32; } } } } --------------040009040502030809030901 Content-Type: text/plain; name="logfile_AB" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="logfile_AB" *** Generated by yangdump 0.9.4 at 2009-03-18T11:48:06.000-07:00 Warning: no revision statements for submodule 'C' Error: import for prefix 'iana' not found C.yang:10.36: error(331): undefined prefix Warning: no revision statements for submodule 'A' Warning: no revision statements for submodule 'B' Error: object 'ChannelNumber' already defined in submodule 'A' at line 7 B.yang:8.13: error(224): duplicate entry Warning: no revision statements for module 'if' Warning: no child nodes found in XPath expr 'if:ifType='ds0'' C.yang:6.33: warning(432): no child node available *** if.yang: 2 Errors, 5 Warnings --------------040009040502030809030901 Content-Type: text/plain; name="logfile_BA" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="logfile_BA" *** Generated by yangdump 0.9.4 at 2009-03-18T11:48:35.000-07:00 Warning: no revision statements for submodule 'C' Error: import for prefix 'iana' not found C.yang:10.36: error(331): undefined prefix Warning: no revision statements for submodule 'B' Warning: no revision statements for submodule 'A' Error: object 'ChannelNumber' already defined in submodule 'B' at line 8 A.yang:7.13: error(224): duplicate entry Warning: no revision statements for module 'if' Warning: no child nodes found in XPath expr 'if:Descr='xyz'' C.yang:7.32: warning(432): no child node available *** if.yang: 2 Errors, 5 Warnings --------------040009040502030809030901 Content-Type: text/plain; name="logfile_AB2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="logfile_AB2" *** Generated by yangdump 0.9.4 at 2009-03-18T12:42:12.000-07:00 Warning: no revision statements for submodule 'C' Warning: no revision statements for submodule 'A' Warning: no revision statements for submodule 'B' Error: object 'ChannelNumber' already defined in submodule 'A' at line 7 B.yang:8.13: error(224): duplicate entry Warning: no revision statements for module 'if' *** if.yang: 1 Errors, 4 Warnings --------------040009040502030809030901 Content-Type: text/plain; name="logfile_BA2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="logfile_BA2" *** Generated by yangdump 0.9.4 at 2009-03-18T12:41:47.000-07:00 Warning: no revision statements for submodule 'C' Warning: no revision statements for submodule 'B' Warning: no revision statements for submodule 'A' Error: object 'ChannelNumber' already defined in submodule 'B' at line 8 A.yang:7.13: error(224): duplicate entry Warning: no revision statements for module 'if' Warning: no child nodes found in XPath expr 'if:Descr='xyz'' C.yang:7.32: warning(432): no child node available *** if.yang: 1 Errors, 5 Warnings --------------040009040502030809030901-- From lhotka@cesnet.cz Wed Mar 18 13:23: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 2CAA83A6B89 for ; Wed, 18 Mar 2009 13:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.287, 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 5NvGHgtjxfKd for ; Wed, 18 Mar 2009 13:23:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7030E3A6962 for ; Wed, 18 Mar 2009 13:23:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AD940D800C8; Wed, 18 Mar 2009 21:24:41 +0100 (CET) From: Ladislav Lhotka To: David Reid In-Reply-To: <200903181748.NAA19229@adminfs.snmp.com> References: <200903181748.NAA19229@adminfs.snmp.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 21:24:41 +0100 Message-Id: <1237407881.6392.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] intra-module augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:23:58 -0000 David Reid píše v St 18. 03. 2009 v 13:48 -0400: > From a discussion on a different thread, Lada said: > > > I agree, except that such intra-module augments are not allowed anymore. > > > > Sec. 7.15: > > The "augment" statement allows a module or submodule to add to the > > schema tree defined in another module or submodule, and to add to the > > nodes from a grouping in a "uses" statement. > > Why are intra-module augments not allowed? I think they are not needed, you can add the nodes directly to the place where they belong, if you are already changing the text of the same module. > > If a submodule can augment a list in the module it belongs to, I don't see > any reason an augment statement in a module can't augment a list in the > same module. I think an augment in a submodule is a way to add nodes to non-root locations of the main module. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Mar 18 13:27: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 1B57B28C1F1 for ; Wed, 18 Mar 2009 13:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=0.280, 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 drsCMrDCk3IN for ; Wed, 18 Mar 2009 13:27:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4F98A28C129 for ; Wed, 18 Mar 2009 13:27:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9AB30D800C8 for ; Wed, 18 Mar 2009 21:28:07 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090318.204853.148876471.mbj@tail-f.com> References: <200903181748.NAA19229@adminfs.snmp.com> <20090318.204853.148876471.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 18 Mar 2009 21:28:07 +0100 Message-Id: <1237408087.6392.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] intra-module augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:27:24 -0000 Martin Bjorklund píše v St 18. 03. 2009 v 20:48 +0100: > > "Whoops". This was not the intention. It seems this text has been > there from -00. Compare with the text in 4.2.8: > > 4.2.8. Extending Data Models (augment) > > YANG allows a module to insert additional nodes into data models, > including both the current module (and its submodules) or an external > module. > > 7.15 should use the same words. I'd actually prefer the 7.15 version. :-) Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From reid@snmp.com Wed Mar 18 13:27: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 72BD828C22A for ; Wed, 18 Mar 2009 13:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLTc63Qv+oDo for ; Wed, 18 Mar 2009 13:27:27 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 5DE5328C129 for ; Wed, 18 Mar 2009 13:27:27 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA23875; Wed, 18 Mar 2009 16:28:11 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA24642; Wed, 18 Mar 2009 16:28:11 -0400 (EDT) Message-Id: <200903182028.QAA24642@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Wed, 18 Mar 2009 21:24:41 +0100. <1237407881.6392.13.camel@missotis> Date: Wed, 18 Mar 2009 16:28:10 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] intra-module augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 20:27:28 -0000 > > > > Why are intra-module augments not allowed? > > I think they are not needed, you can add the nodes directly to the place > where they belong, if you are already changing the text of the same > module. The only reason I care is for mapping SNMP MIBs which sometimes do this. Otherwise, I agree with you that it is not necessary when writing a new yang module. But I don't see any reason to forbid it. -David Reid From mbj@tail-f.com Wed Mar 18 13:32: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 1E4A428C232 for ; Wed, 18 Mar 2009 13:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.081, 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 4fccZRCEn33S for ; Wed, 18 Mar 2009 13:32:02 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 57D4428C230 for ; Wed, 18 Mar 2009 13:32:02 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 933B476C557; Wed, 18 Mar 2009 21:32:46 +0100 (CET) Date: Wed, 18 Mar 2009 21:32:46 +0100 (CET) Message-Id: <20090318.213246.234134821.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200903182028.QAA24642@adminfs.snmp.com> References: <1237407881.6392.13.camel@missotis> <200903182028.QAA24642@adminfs.snmp.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] intra-module augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:32:03 -0000 David Reid wrote: > > > > > > Why are intra-module augments not allowed? > > > > I think they are not needed, you can add the nodes directly to the place > > where they belong, if you are already changing the text of the same > > module. > > The only reason I care is for mapping SNMP MIBs which sometimes do this. > Otherwise, I agree with you that it is not necessary when writing a new > yang module. But I don't see any reason to forbid it. I agree. Since it is technically the same as doing the augmentation from a submodule, it would be a classic CLR to not allow it from the main module. /martin From j.schoenwaelder@jacobs-university.de Thu Mar 19 14:48: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 299993A6969 for ; Thu, 19 Mar 2009 14:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 1A5Mcffc3wPA for ; Thu, 19 Mar 2009 14:48:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1A8383A6A0A for ; Thu, 19 Mar 2009 14:48:45 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41DADC000E for ; Thu, 19 Mar 2009 22:49:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wrzr3rrLD3hm; Thu, 19 Mar 2009 22:49:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E19ABC0005; Thu, 19 Mar 2009 22:49:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 74B5FA27379; Thu, 19 Mar 2009 22:49:16 +0100 (CET) Date: Thu, 19 Mar 2009 22:49:16 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090319214916.GB18653@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 21:48:46 -0000 Hi, below is the open issues list of . Some of them require to get the right subject matter expert involved to review definitions. Others require help of the WG. Please take a look and see whether you can help (and if so, please start a new thread on this list). /js * xpath typedef (ietf-yang-types) Q: Shall the name of this typedef be changed to xpath1 or xpath1-0 to accomodate definitions of other xpath versions in the future? Q: What is the canonical format of an xpath expression? * IPv6 address pattern (ietf-inet-types) Q: We need a "reasonable" pattern for IPv6 addresses. It seems the AND connection of multiple pattern does not help too much here. Do we really have to use a very verbose pattern like the one used in pyang? * IPv6 address prefix pattern (ietf-inet-types) Q: Do we have support all IPv6 address writing styles or can be go ahead with say just the canonical IPv6 address format? * DNS restrictions on labels (ietf-inet-types) C: DNS expert advice is needed so that we get the restrictions on DNS labels right and future proof. * URI regex from RFC 3986 (ietf-inet-types) C: URI expert advice is needed to answer the question whether it is safe to use the URI regular expression found in Appendix B of RFC 3986. * ieee portlist (ietf-ieee-types) Q: It was suggested to add a port-list typedef but no concrete suggestion has been made how it could look like. C: One option is to represent port lists as a comma seperated list of port ranges where a port range is either a port number or a port number followed by a hyphen and a port number, e.g. 1-5,8,10-22 Ranges may not overlap and they may not be consecutive and they must be in ascending order to achieve a canonic representation. * other vlan related types (ietf-ieee-types) Q: It was suggested to add more VLAN related types but no concrete suggestions have been made so far. C: Poll for concrete suggestions until and drop this if no concrete suggestions are being made. From mbj@tail-f.com Fri Mar 20 07:16: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 6D7853A67E7 for ; Fri, 20 Mar 2009 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.095, 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 gZAovYHP7yeB for ; Fri, 20 Mar 2009 07:16:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 956063A6767 for ; Fri, 20 Mar 2009 07:16:30 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2246A76C5A6 for ; Fri, 20 Mar 2009 15:17:16 +0100 (CET) Date: Fri, 20 Mar 2009 15:17:15 +0100 (CET) Message-Id: <20090320.151715.162360428.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20090313.221956.210343928.mbj@tail-f.com> References: <20090313.205546.240156791.mbj@tail-f.com> <49BAC7D0.1090601@netconfcentral.com> <20090313.221956.210343928.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] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 14:16:31 -0000 Hi, Here is proposed text for a decimal64 type. This is supposed to simply be a replacement for the float32 and float64 types. ** The decimal64 Built-in Type The decimal64 type represents a subset of the real numbers, which can be represented by decimal numerals. The value space of decimal64 is the set of numbers that can be obtained by multiplying a 64 bit signed integer by a negative power of ten, i.e. expressible as i x 10^-n where i is an integer64 and n is an integer between 1 and 18, inclusively. *** Lexicographic Representation A decimal64 value is lexicographically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, optionally followed by a period ('.') as a decmial indicator and a sequence of decimal digits. If no sign is specified, "+" is assumed. *** Canonical Form The canonical form of a positive decimal64 does not include the sign "+". The decimal point is required. Leading and trailing zeros are prohibited, subject to the rule that there MUST be at least one digit before and after the decimal point. The value zero is represented as "0.0". *** Restrictions A decmial64 type can be restricted with the "range" statement (^range^). *** The fraction-digits Statement @fraction-digits@ The "fraction-digits" statement, which is a substatement to the "type" statement, MUST be present if the type is "decimal64". It takes as an argument an integer between 1 and 18, inclusively. It controls the size of the minimum difference between values of a decimal64 type, by restricting the value space to numbers that are expressible as i x 10^-n where n is the fraction-digits argument. *** Usage Example type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } /martin From lhotka@cesnet.cz Fri Mar 20 08:24: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 D36D828C1CF for ; Fri, 20 Mar 2009 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.471, 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 CSK-K9x6ZZx4 for ; Fri, 20 Mar 2009 08:24:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 094F528C162 for ; Fri, 20 Mar 2009 08:24:09 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id BDF78D800BD; Fri, 20 Mar 2009 16:24:54 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090319214916.GB18653@elstar.local> References: <20090319214916.GB18653@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 20 Mar 2009 16:24:55 +0100 Message-Id: <1237562695.7267.31.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Mar 2009 15:24:09 -0000 Juergen Schoenwaelder píše v Čt 19. 03. 2009 v 22:49 +0100: > * IPv6 address pattern (ietf-inet-types) > > Q: We need a "reasonable" pattern for IPv6 addresses. It seems the > AND connection of multiple pattern does not help too much > here. Do we really have to use a very verbose pattern like the > one used in pyang? > The one used in pyang comes from RFC 3986 and doesn't use AND. I have expressions that are considerably simpler, hopefully correct and utilize multiple ANDed paterns. I will try to enhance them to take into account the special formats with embedded IPv4 and we'll see whether it could be more acceptable. Another option is to define IPv4 and IPv6 addresses as built-in types. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Mar 20 09:06: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 AD5F93A69A2 for ; Fri, 20 Mar 2009 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 6qaidFQAavLn for ; Fri, 20 Mar 2009 09:06:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9173A3A6991 for ; Fri, 20 Mar 2009 09:06:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9ACA5C000A; Fri, 20 Mar 2009 17:07:36 +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 Ug-eSRohLYvJ; Fri, 20 Mar 2009 17:07:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8D3AC0005; Fri, 20 Mar 2009 17:07:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 91140A286B1; Fri, 20 Mar 2009 17:07:23 +0100 (CET) Date: Fri, 20 Mar 2009 17:07:23 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090320160723.GA20543@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20090319214916.GB18653@elstar.local> <1237562695.7267.31.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237562695.7267.31.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:06:51 -0000 On Fri, Mar 20, 2009 at 04:24:55PM +0100, Ladislav Lhotka wrote: > Another option is to define IPv4 and IPv6 addresses as built-in types. Nope. Adressing formats come and go (well, they never go). The other option is IMHO to be happy with a regular expression that does not attempt to catch all corner cases. There is still a description clause - which is as good as the text in the Yang specification defining buit-in types. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Mar 20 09:47: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 483FF3A6767 for ; Fri, 20 Mar 2009 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+iRsjx85y9U for ; Fri, 20 Mar 2009 09:47:06 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 788BC3A6C6B for ; Fri, 20 Mar 2009 09:47:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKScPItsV3fRrK5Akd9BR3aSEOEo7jAR6i@postini.com; Fri, 20 Mar 2009 09:47:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 20 Mar 2009 09:47:28 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 09:47:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 09:47:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 09:47:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2KGlQM73408; Fri, 20 Mar 2009 09:47:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2KGeSba010364; Fri, 20 Mar 2009 16:40:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903201640.n2KGeSba010364@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090320.151715.162360428.mbj@tail-f.com> Date: Fri, 20 Mar 2009 12:40:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Mar 2009 16:47:27.0415 (UTC) FILETIME=[8D574C70:01C9A97B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:47:07 -0000 Martin Bjorklund writes: >*** Canonical Form >The canonical form of a positive decimal64 does not include the sign >"+". The decimal point is required. Leading and trailing zeros are >prohibited, subject to the rule that there MUST be at least one digit >before and after the decimal point. The value zero is represented as >"0.0". Can we make the decimal optional if the fractional part is zero, so we get "0" not "0.0"? Thanks, Phil From lhotka@cesnet.cz Sun Mar 22 09:57: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 066383A6A60 for ; Sun, 22 Mar 2009 09:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkPgzRXvfo+u for ; Sun, 22 Mar 2009 09:57:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 30C3F3A6AD0 for ; Sun, 22 Mar 2009 09:57:23 -0700 (PDT) Received: from [130.129.69.216] (dhcp-45d8.meeting.ietf.org [130.129.69.216]) by office2.cesnet.cz (Postfix) with ESMTP id A7D76D800C5; Sun, 22 Mar 2009 17:58:10 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090320160723.GA20543@elstar.local> References: <20090319214916.GB18653@elstar.local> <1237562695.7267.31.camel@missotis> <20090320160723.GA20543@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 22 Mar 2009 09:58:07 -0700 Message-Id: <1237741087.7087.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:57:24 -0000 Juergen Schoenwaelder píše v Pá 20. 03. 2009 v 17:07 +0100: > On Fri, Mar 20, 2009 at 04:24:55PM +0100, Ladislav Lhotka wrote: > > > Another option is to define IPv4 and IPv6 addresses as built-in types. > > Nope. Adressing formats come and go (well, they never go). The other Well, any change in the address format would induce so many changes almost everywhere and YANG built-in type would be a very minor issue. > option is IMHO to be happy with a regular expression that does not > attempt to catch all corner cases. There is still a description clause > - which is as good as the text in the Yang specification defining > buit-in types. Anyway, here is the ipv6-address typedef, it covers the full, shortened and mixed format, following (hopefully) exactly RFC 4291: typedef ipv6-address { type string { pattern "([0-9a-fA-F]{0,4}:){0,6}" + "((([0-9a-fA-F]{0,4}:)?[0-9a-fA-F]{0,4})|" + "(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\\.){3}" + "(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))"; pattern "(([0-9a-fA-F]+:){6}(([0-9a-fA-F]+:[0-9a-fA-F]+)|[\\.0-9]+)|" + "(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::" + "((([0-9a-fA-F]+:)*[0-9a-fA-F]+)?|[\\.0-9]+))"; } } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sun Mar 22 10:45: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 AF5C63A6A96 for ; Sun, 22 Mar 2009 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, 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 ZJYWWfTG4gUp for ; Sun, 22 Mar 2009 10:45:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9A1FB3A6A37 for ; Sun, 22 Mar 2009 10:45:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BACDC0011; Sun, 22 Mar 2009 18:46:20 +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 NGXvuLFcb+2a; Sun, 22 Mar 2009 18:46:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47D1BC000F; Sun, 22 Mar 2009 18:46:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CCBB2A2F3F5; Sun, 22 Mar 2009 18:46:06 +0100 (CET) Date: Sun, 22 Mar 2009 18:46:06 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090322174606.GA12869@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20090319214916.GB18653@elstar.local> <1237562695.7267.31.camel@missotis> <20090320160723.GA20543@elstar.local> <1237741087.7087.6.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237741087.7087.6.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:45:34 -0000 On Sun, Mar 22, 2009 at 05:58:07PM +0100, Ladislav Lhotka wrote: > Anyway, here is the ipv6-address typedef, it covers the full, shortened > and mixed format, following (hopefully) exactly RFC 4291: > > typedef ipv6-address { > type string { > pattern > "([0-9a-fA-F]{0,4}:){0,6}" > + "((([0-9a-fA-F]{0,4}:)?[0-9a-fA-F]{0,4})|" > + "(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\\.){3}" > + "(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))"; > pattern > "(([0-9a-fA-F]+:){6}(([0-9a-fA-F]+:[0-9a-fA-F]+)|[\\.0-9]+)|" > + "(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::" > + "((([0-9a-fA-F]+:)*[0-9a-fA-F]+)?|[\\.0-9]+))"; > } > } This pattern does not seem to accept ::FFFF:129.144.52.38 as an IPv6 address. Can you fix this? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Mar 22 15:22: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 764843A68BC for ; Sun, 22 Mar 2009 15:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-hsSYn7iECv for ; Sun, 22 Mar 2009 15:22:03 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B67673A68AC for ; Sun, 22 Mar 2009 15:22:03 -0700 (PDT) Received: from localhost (dhcp-44e2.meeting.ietf.org [130.129.68.226]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F1DB76C552; Sun, 22 Mar 2009 23:22:46 +0100 (CET) Date: Sun, 22 Mar 2009 15:22:43 -0700 (PDT) Message-Id: <20090322.152243.49305927.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49B43845.9060303@netconfcentral.com> References: <49B43845.9060303@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] more fun with when-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: Sun, 22 Mar 2009 22:22:04 -0000 Hi, Andy Bierman wrote: > Hi, > > What about this one? > > list split { > min-elements 2; > when "B = 'fred'; > key A; > leaf A { type string; } > leaf B { > type string; > mandatory true; > } > } > > > > here > fred > > > not-here > barney > > > > Does the when-stmt refer to the existence of the > object (split) or instances of the object? > The draft seems to say the former. I'm not sure where it indicates the former; the idea is that works on instances. Section 7.9.15 defines this, using the term "data tree" which is the tree of instances. > It is not clear to mean what the proper outcome > should be for agent processing. > > If instances, not objects: > Does the 'min-elements 2' get enforced or not? > > Is the when-stmt test in 'split' conducted > before or after the min-elements test in 'config'? > If before, no error, if after (2nd entry deleted), > then it is an error. > > Will a CLR saying that "a when-stmt XPath expression MUST NOT > include any references to child, descendant, or descendant-or-self > nodes of the context node" fix this problem? I think so, yes. Unless anyone else has any other comments, I will add this. /martin From lhotka@cesnet.cz Sun Mar 22 18:58: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 BD0EB3A6909 for ; Sun, 22 Mar 2009 18:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjC9AGQZiYnD for ; Sun, 22 Mar 2009 18:58:14 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F2E633A67A4 for ; Sun, 22 Mar 2009 18:58:13 -0700 (PDT) Received: from [130.129.69.216] (dhcp-45d8.meeting.ietf.org [130.129.69.216]) by office2.cesnet.cz (Postfix) with ESMTP id 4312AD800C5 for ; Mon, 23 Mar 2009 02:59:02 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20090322174606.GA12869@elstar.local> References: <20090319214916.GB18653@elstar.local> <1237562695.7267.31.camel@missotis> <20090320160723.GA20543@elstar.local> <1237741087.7087.6.camel@missotis> <20090322174606.GA12869@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 22 Mar 2009 18:58:57 -0700 Message-Id: <1237773537.6466.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Mar 2009 01:58:14 -0000 Juergen Schoenwaelder píše v Ne 22. 03. 2009 v 18:46 +0100: > > This pattern does not seem to accept ::FFFF:129.144.52.38 as an IPv6 > address. Can you fix this? > Thanks, fixed. Also it didn't allow 1:2:3:4:5:6:7:: and ::1:2:3:4:5:6:7. This version should be better: typedef ipv6-address { type string { pattern "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}" + "((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|" + "(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\\.){3}" + "(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))"; pattern "(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|" + "((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)"; } } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Mar 23 01: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 393B23A6784 for ; Mon, 23 Mar 2009 01:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.293 X-Spam-Level: X-Spam-Status: No, score=0.293 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=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 Smf+JXlOWww9 for ; Mon, 23 Mar 2009 01:09:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 70EE23A6A19 for ; Mon, 23 Mar 2009 01:09:14 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C021F76C55F; Mon, 23 Mar 2009 09:10:00 +0100 (CET) Message-ID: <49C743D8.1020009@tail-f.com> Date: Mon, 23 Mar 2009 09:10:00 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200903201640.n2KGeSba010364@idle.juniper.net> In-Reply-To: <200903201640.n2KGeSba010364@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] float vs. decimal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 08:09:15 -0000 On 03/20/09 17:40, Phil Shafer wrote: > Martin Bjorklund writes: >> *** Canonical Form >> The canonical form of a positive decimal64 does not include the sign >> "+". The decimal point is required. Leading and trailing zeros are >> prohibited, subject to the rule that there MUST be at least one digit >> before and after the decimal point. The value zero is represented as >> "0.0". > > Can we make the decimal optional if the fractional part is zero, > so we get "0" not "0.0"? That was in Martin's original proposal, I suggested that it would be more "in line with expectations" or somesuch for decimal(s) to always be present in the canonical form. I guess those expectations (i.e. mine) may be due to the analogy with floats - you normally print decimal(s) even if a float value happens to be integral (%g doesn't, though) - and to the fact that the canonical form for xs:decimal requires this. Not exactly strong technical arguments - do you have some for the opposite viewpoint? --Per From j.schoenwaelder@jacobs-university.de Mon Mar 23 04:05:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773583A6B5B for ; Mon, 23 Mar 2009 04:05:00 -0700 (PDT) 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 gFlijLw9ww-2 for ; Mon, 23 Mar 2009 04:04:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 194FC3A6B48 for ; Mon, 23 Mar 2009 04:04:58 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A2A4C001F; Mon, 23 Mar 2009 12:05:47 +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 Gg31m8tcnXzj; Mon, 23 Mar 2009 12:05:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF617C001E; Mon, 23 Mar 2009 12:05:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3803BA3044F; Mon, 23 Mar 2009 12:05:34 +0100 (CET) Date: Mon, 23 Mar 2009 12:05:34 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090323110534.GA14182@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20090319214916.GB18653@elstar.local> <1237562695.7267.31.camel@missotis> <20090320160723.GA20543@elstar.local> <1237741087.7087.6.camel@missotis> <20090322174606.GA12869@elstar.local> <1237773537.6466.7.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237773537.6466.7.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 11:05:00 -0000 On Mon, Mar 23, 2009 at 02:58:57AM +0100, Ladislav Lhotka wrote: > This version should be better: > > typedef ipv6-address { > type string { > pattern > "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}" > + "((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|" > + "(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\\.){3}" > + "(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))"; > pattern > "(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|" > + "((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)"; > } > } This passes my test cases (whatever that means). Can you now add an optional zone index? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Mar 23 11:23: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 F21233A6AAD for ; Mon, 23 Mar 2009 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=0.650, 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 hAA-zZyh1qZf for ; Mon, 23 Mar 2009 11:23:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3189D3A682D for ; Mon, 23 Mar 2009 11:23:43 -0700 (PDT) Received: from [130.129.23.115] (dhcp-1773.meeting.ietf.org [130.129.23.115]) by office2.cesnet.cz (Postfix) with ESMTP id B525DD800BD; Mon, 23 Mar 2009 19:24:31 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090323110534.GA14182@elstar.local> References: <20090319214916.GB18653@elstar.local> <1237562695.7267.31.camel@missotis> <20090320160723.GA20543@elstar.local> <1237741087.7087.6.camel@missotis> <20090322174606.GA12869@elstar.local> <1237773537.6466.7.camel@missotis> <20090323110534.GA14182@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 23 Mar 2009 11:24:28 -0700 Message-Id: <1237832668.6559.2.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yang types open issues summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Mar 2009 18:23:44 -0000 Juergen Schoenwaelder píše v Po 23. 03. 2009 v 12:05 +0100: > This passes my test cases (whatever that means). Can you now add an > optional zone index? Here it is (I also chenged double quotes to single): typedef ipv6-address { type string { pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + '(%[\p{N}\p{L}]+)?'; pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + '(%.+)?'; } } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Mar 23 11:25: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 500F23A69D2 for ; Mon, 23 Mar 2009 11:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwQyb5ZVaihL for ; Mon, 23 Mar 2009 11:25:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8429A3A6C77 for ; Mon, 23 Mar 2009 11:25:24 -0700 (PDT) Received: from localhost (dhcp-44e2.meeting.ietf.org [130.129.68.226]) by mail.tail-f.com (Postfix) with ESMTPSA id 2325B61600D; Mon, 23 Mar 2009 19:26:11 +0100 (CET) Date: Mon, 23 Mar 2009 11:26:09 -0700 (PDT) Message-Id: <20090323.112609.217716142.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20090322.152243.49305927.mbj@tail-f.com> References: <49B43845.9060303@netconfcentral.com> <20090322.152243.49305927.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] more fun with when-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: Mon, 23 Mar 2009 18:25:29 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > > Will a CLR saying that "a when-stmt XPath expression MUST NOT > > include any references to child, descendant, or descendant-or-self > > nodes of the context node" fix this problem? > > I think so, yes. Unless anyone else has any other comments, I will > add this. I think we have to mention self as well, and self is also part of ancestor-or-self. How about this instead: The XPath expression MUST NOT include any references to the context node or any descendants of the context node. /martin From mbj@tail-f.com Mon Mar 23 11:31: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 56D3B3A6BA9 for ; Mon, 23 Mar 2009 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE5d9XX+bZhE for ; Mon, 23 Mar 2009 11:31:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9B5813A6C72 for ; Mon, 23 Mar 2009 11:31:31 -0700 (PDT) Received: from localhost (dhcp-44e2.meeting.ietf.org [130.129.68.226]) by mail.tail-f.com (Postfix) with ESMTPSA id DB52D61600D; Mon, 23 Mar 2009 19:32:20 +0100 (CET) Date: Mon, 23 Mar 2009 11:32:18 -0700 (PDT) Message-Id: <20090323.113218.217744247.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200903181316.JAA14467@adminfs.snmp.com> References: <200903181316.JAA14467@adminfs.snmp.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] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Mar 2009 18:31:32 -0000 David Reid wrote: > I don't think the issue discussed in this thread has been addressed in > the > current document. How about adding this to the section "7.15 The augment statement": The augment statement MUST NOT add multiple nodes with the same name from the same module to the target node. /martin From j.schoenwaelder@jacobs-university.de Tue Mar 24 00:28:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439FA3A6847 for ; Tue, 24 Mar 2009 00:28:21 -0700 (PDT) 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.139, 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 6bOVTEaZ1pF9 for ; Tue, 24 Mar 2009 00:28:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E9A563A67DB for ; Tue, 24 Mar 2009 00:28:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AA1EC002A for ; Tue, 24 Mar 2009 08:29:10 +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 FWVy3Ea8S5ev; Tue, 24 Mar 2009 08:29:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 172ACC0025; Tue, 24 Mar 2009 08:29:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1CEB9A3D31E; Tue, 24 Mar 2009 08:28:55 +0100 (CET) Date: Tue, 24 Mar 2009 08:28:55 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090324072855.GA8139@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] getting rid of ietf-ieee-types.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:28:21 -0000 Hi, during the WG meeting yesterday, there was concensus to not define an IEEE port-list typedef or further VLAN related typedefs at this point in time and to leave this to future work. Part of the reasoning was that we need to have IEEE experts involved in this work since IEEE 802 briding standards have evolved and one concrete comment made by Dan Romascanu was that things like the VLAN number space are changing. Looking at the ietf-ieee-types.yang module, I see that it defines vlanid (consistent with the VlanId textual convention) which is going to be affected by an enlarged VLAN number space as well. Furthermore, ietf-ieee-types.yang defines bridgeid, which had some controversies in the past concerning the textual representation and again it would require direct IEEE involvement to get this right. By applying yesterday's logic, I propose that we do _not_ define these types at this point in time. This leaves us with a single definition in the ietf-ieee-types.yang module: mac-address. While the 48-bit mac address format seems to be less controversial, I checked MIB modules and the SMIv2 MacAddress is only used in layer two related MIB modules. Since having a YANG module for just one definition seems odd, my proposal is to drop the whole ietf-ieee-types.yang module for now. Note that I am not saying these typedefs are not needed. I believe they are actually very crucial to have. However, we should establish contact to the IEEE via whatever liason and ideally have them involved in creating appropriate definitions with expert review from YANG experts. This will be a better solution for getting good definitions of core IEEE related typedef and this approach allows us to concentrate on those typedefs where the IETF has the relevant expertise and move forward with the YANG data types according to our charter schedule. Chairs, please consider discussing this proposal during the next NETMOD meeting. /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 Tue Mar 24 07:32: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 054AF28C2D2 for ; Tue, 24 Mar 2009 07:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT6xkAZXPeHl for ; Tue, 24 Mar 2009 07:32:07 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0673B28C2CD for ; Tue, 24 Mar 2009 07:32:07 -0700 (PDT) Received: from localhost (dhcp-44e2.meeting.ietf.org [130.129.68.226]) by mail.tail-f.com (Postfix) with ESMTPSA id AEF0861600F for ; Tue, 24 Mar 2009 15:32:56 +0100 (CET) Date: Tue, 24 Mar 2009 07:32:54 -0700 (PDT) Message-Id: <20090324.073254.160883980.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] canonical xpath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:32:08 -0000 Hi, Searching for canonical xpath, it seems that this term is used as in "canonical xpath for a given node in a document". There are of course many ways to construct an XPath expression that returns a node set which contains just a given node, so they have defined a "canonical xpath" for this. See e.g. http://www.w3.org/TR/2001/WD-xforms-20010608/slice6.html#expr-canonical. This is not what we were looking for. We are using the term 'instance-identifer' for this. A better match is this: The short-form of XPATH (and what most of us usually see) is actually the "abbreviated syntax" (http://www.w3.org/TR/xpath#path-abbrev) for a location path. Some applications call these "canonical" XPath expressions. (http://lists.oasis-open.org/archives/provision/200502/msg00020.html) But it is not really the same thing, they use it to differentiate it from "full xpath". And it doesn't handle the prefix problem. /martin From reid@snmp.com Tue Mar 24 08:45: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 F108528C103 for ; Tue, 24 Mar 2009 08:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4KpUlzlvDOx for ; Tue, 24 Mar 2009 08:45:22 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 06BC328C0DC for ; Tue, 24 Mar 2009 08:45:21 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA20703; Tue, 24 Mar 2009 11:46:12 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA19113; Tue, 24 Mar 2009 11:46:11 -0400 (EDT) Message-Id: <200903241546.LAA19113@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Mon, 23 Mar 2009 11:32:18 -0700. <20090323.113218.217744247.mbj@tail-f.com> Date: Tue, 24 Mar 2009 11:46:11 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:45:23 -0000 > David Reid wrote: > > I don't think the issue discussed in this thread has been addressed in > > the > > current document. > > How about adding this to the section "7.15 The augment statement": > > The augment statement MUST NOT add multiple nodes with the same name > from the same module to the target node. > Yes, that solves the problem. -David Reid From andy@netconfcentral.com Wed Mar 25 23:25: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 B76CB3A67D4 for ; Wed, 25 Mar 2009 23:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GWiLAwQdtZs for ; Wed, 25 Mar 2009 23:25:33 -0700 (PDT) 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 C453C3A6765 for ; Wed, 25 Mar 2009 23:25:33 -0700 (PDT) Received: from [68.142.200.221] by n27.bullet.mail.mud.yahoo.com with NNFMP; 26 Mar 2009 06:26:26 -0000 Received: from [68.142.201.68] by t9.bullet.mud.yahoo.com with NNFMP; 26 Mar 2009 06:26:26 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 26 Mar 2009 06:26:26 -0000 X-Yahoo-Newman-Id: 725191.20493.bm@omp420.mail.mud.yahoo.com Received: (qmail 17619 invoked from network); 26 Mar 2009 06:26:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2009 06:26:25 -0000 X-YMail-OSG: GyWwN3wVM1mpiNk2RXxKWyVxGxNuGg_aoa0_J9yOd0RP74x2kqjkq9FtGl0zqQPcSUTE2zCvt2TB7Jh8M1mu_6CrzNdlhtqNgeLwur898l.ZxOqD1yiQr3iMasYqIIvbhNCID38UVBAm7j8Xo4DCrdnxCUTo0VyDD9eEhjBom3Kt2Mo87vslF61Y0gPTM3StEtp61HM9oGha0IYTiSD81g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CB200F.6080403@netconfcentral.com> Date: Wed, 25 Mar 2009 23:26:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49B43845.9060303@netconfcentral.com> <20090322.152243.49305927.mbj@tail-f.com> <20090323.112609.217716142.mbj@tail-f.com> In-Reply-To: <20090323.112609.217716142.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] more fun with when-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: Thu, 26 Mar 2009 06:25:34 -0000 Martin Bjorklund wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Will a CLR saying that "a when-stmt XPath expression MUST NOT >>> include any references to child, descendant, or descendant-or-self >>> nodes of the context node" fix this problem? >> I think so, yes. Unless anyone else has any other comments, I will >> add this. > > I think we have to mention self as well, and self is also part of > ancestor-or-self. How about this instead: > > The XPath expression MUST NOT include any references to the context > node or any descendants of the context node. > > much better > /martin > > > Andy From j.schoenwaelder@jacobs-university.de Thu Mar 26 02:32: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 BC4C53A6A90 for ; Thu, 26 Mar 2009 02:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_20=-0.74, 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 WROX3V95j7X9 for ; Thu, 26 Mar 2009 02:32:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EBD793A681C for ; Thu, 26 Mar 2009 02:32:14 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D22CEC0009 for ; Thu, 26 Mar 2009 10:33:06 +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 ARZYmQ39zFP8; Thu, 26 Mar 2009 10:33:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B10EC0005; Thu, 26 Mar 2009 10:33:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B698A3FF22; Thu, 26 Mar 2009 10:32:48 +0100 (CET) Date: Thu, 26 Mar 2009 10:32:48 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090326093248.GB13386@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 09:32:15 -0000 Hi, I just saw this document: http://www.ietf.org/internet-drafts/draft-kawamura-ipv6-text-representation-00.txt While this document is not perfect and the suggestion to use inet_ntop() does not work since we know this function is not fully defined and different implementations produce different results, I believe the authors do have a point in spelling out that multiple different representations are operationally not really a feature. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Thu Mar 26 13:02: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 DCB123A69F7 for ; Thu, 26 Mar 2009 13:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.657, 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 E7wdB-ypehuO for ; Thu, 26 Mar 2009 13:02:27 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 5039F3A6C0D for ; Thu, 26 Mar 2009 13:02:27 -0700 (PDT) Received: (qmail 71046 invoked from network); 26 Mar 2009 20:03:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2009 20:03:20 -0000 X-YMail-OSG: XXQJT.oVM1mbpYaCzewT05Ll3LxBAFYUvkdRUC5OSAUatn5BLZbRyX1dVC5FOJeuSUejtlNya4hVA8BFqWEEWPgWLIE8k0.pAIE7.pTH06GJqWkTIxN50m_xDyqRHvUCxZ4XLUn0slImzDuHIESovWFy X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CBDF87.20405@netconfcentral.com> Date: Thu, 26 Mar 2009 13:03:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 20:02:27 -0000 Hi, Re the identifier length issue raised in the NETMOD WG meeting yesterday: yang-04, sec 6.2, para 1, sentence 3: OLD: Implementations MUST support identifiers up to 63 characters in length. NEW: Identifiers MUST be between 1 and 63 characters in length. Andy From phil@juniper.net Fri Mar 27 06:17: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 9314B3A6C54 for ; Fri, 27 Mar 2009 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 IHHQE5bN8WKd for ; Fri, 27 Mar 2009 06:17:57 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id E31EB3A6C58 for ; Fri, 27 Mar 2009 06:17:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSczSNrZtcQinRmIZeQzVjAZwRysbtJc3@postini.com; Fri, 27 Mar 2009 06:18:52 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 27 Mar 2009 06:13:35 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 06:13:35 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 06:13:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 06:13:34 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2RDDXM46111; Fri, 27 Mar 2009 06:13:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2RD6SZP063621; Fri, 27 Mar 2009 13:06:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903271306.n2RD6SZP063621@idle.juniper.net> To: Andy Bierman In-Reply-To: <49CBDF87.20405@netconfcentral.com> Date: Fri, 27 Mar 2009 09:06:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Mar 2009 13:13:34.0127 (UTC) FILETIME=[D4FF33F0:01C9AEDD] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 13:17:58 -0000 Andy Bierman writes: >OLD: > Implementations MUST support identifiers up to 63 characters in > length. >NEW: > Identifiers MUST be between 1 and 63 characters in length. I see no value in this restriction, given that: (a) xml does not limit element names to 63 characters (b) "characters" in a utf world are distorted (for example, multiple ways to make the same utf-8 content) (c) memory impacts are minimal; current memory debates are over MBs, not Bs (d) identifier lengths are self-regulating; a module with 128 byte element names will not be accepted by any sane community of users (e) even 63 is mostly unreadable; a module with names that eat more than, say, half your screen width will be unacceptable (f) YANG identifiers are scoped by their parents, so you don't need to encode the path in names like "ospfNbrAddressLessIndex"; this removes them motivation/need to make butt-ugly long names (g) if one really really needs 64 characters, having to use an abbreviation because of a YANG CLR would be irritating, especially if you are using the vocabulary from another standard. We should avoid making people use identifiers in yang modules that are different from the terms used in such standards. (h) no one likes CLRs Long names aren't a problem for YANG. Limiting them is unnecessary. I would propose complete removal of the 63 character limit. It lets us avoid this issue and other related ones (like "what does 'characters' mean? Is 63 before or after utf-8 encoding? Does the style of encoding (combine .vs. non-combine) impact this? Do we have enough utf-8 expertise to say?"). IMHO it's an issue that's not worth fretting over. It will be self-clocking, since no one will like using modules with long names. Drop the limit completely. Or make it an authoring guideline: "Be aware that no one likes modules with long identifiers. Or prefixes. Or ones that are overly deep. Or ...." FWIW: The longest (by far) identifier in JUNOS is 45: maximum-initial-router-advertisement-interval Thanks, Phil (who never made an identifier longer that 20 characters) From andy@netconfcentral.com Fri Mar 27 07:52: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 E25823A6BB4 for ; Fri, 27 Mar 2009 07:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.107, 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 YlH0X2ovxnnW for ; Fri, 27 Mar 2009 07:52:28 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 2C6FB3A6AA1 for ; Fri, 27 Mar 2009 07:52:28 -0700 (PDT) Received: (qmail 67195 invoked from network); 27 Mar 2009 14:53:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 27 Mar 2009 14:53:22 -0000 X-YMail-OSG: ZflJRMYVM1mgDIFecR7cWlX.4Ixx3sZxfJT4T84RRUehetlDM5xNrGcbCL1R_b8PVWZCHy2.ToQDaDb84ZD5HzYZG1HENxIjCvtZelsdDFmvS1jOtBRKjAlgCMved8R6kPIKJ6dPsLvkvWt3AnBSsURS X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CCE860.2080801@netconfcentral.com> Date: Fri, 27 Mar 2009 07:53:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200903271306.n2RD6SZP063621@idle.juniper.net> In-Reply-To: <200903271306.n2RD6SZP063621@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 14:52:29 -0000 Phil Shafer wrote: > Andy Bierman writes: >> OLD: >> Implementations MUST support identifiers up to 63 characters in >> length. >> NEW: >> Identifiers MUST be between 1 and 63 characters in length. > > I see no value in this restriction, given that: > > (a) xml does not limit element names to 63 characters > (b) "characters" in a utf world are distorted (for example, multiple > ways to make the same utf-8 content) > (c) memory impacts are minimal; current memory debates are over MBs, not Bs > (d) identifier lengths are self-regulating; a module with 128 byte element > names will not be accepted by any sane community of users > (e) even 63 is mostly unreadable; a module with names that eat more than, say, > half your screen width will be unacceptable > (f) YANG identifiers are scoped by their parents, so you don't > need to encode the path in names like "ospfNbrAddressLessIndex"; > this removes them motivation/need to make butt-ugly long names > (g) if one really really needs 64 characters, having to use an abbreviation > because of a YANG CLR would be irritating, especially if you are > using the vocabulary from another standard. We should avoid making > people use identifiers in yang modules that are different from the terms > used in such standards. > (h) no one likes CLRs > > Long names aren't a problem for YANG. Limiting them is unnecessary. I do not understand your inconsistent application of this argument whenever it suites your implementation preference. When it comes to forcing every single YANG modeler to use shallow keys instead of deep keys, and force every NETCONF tool to reorder the list keys so they are first -- just so your implementation does not have to buffer any of the incoming PDU -- then saving a few bytes of memory in the agent is critical. But when it comes to identifiers, the agent is expected to handle infinitely long strings, and just 'make sure' they are unique in the first 63 chars? That does not work. Please find another IETF standard protocol in which something as fundamental as the identifier length is left undefined. I don't think you can, because this is extremely important to tool interoperability. > I would propose complete removal of the 63 character limit. It > lets us avoid this issue and other related ones (like "what does > 'characters' mean? Is 63 before or after utf-8 encoding? Does the > style of encoding (combine .vs. non-combine) impact this? Do we > have enough utf-8 expertise to say?"). IMHO it's an issue that's > not worth fretting over. It will be self-clocking, since no one > will like using modules with long names. Drop the limit completely. > Or make it an authoring guideline: "Be aware that no one likes > modules with long identifiers. Or prefixes. Or ones that are > overly deep. Or ...." > > FWIW: The longest (by far) identifier in JUNOS is 45: > > maximum-initial-router-advertisement-interval > We have no operational need whatsoever for identifiers over 63 UTF-8 characters long. That much is obvious. > Thanks, > Phil (who never made an identifier longer that 20 characters) > > Andy From j.schoenwaelder@jacobs-university.de Fri Mar 27 08:22: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 5ED0F3A68F5 for ; Fri, 27 Mar 2009 08:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_05=-1.11, 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 ycMzLzS2YfXX for ; Fri, 27 Mar 2009 08:22:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 733DC3A6898 for ; Fri, 27 Mar 2009 08:22:20 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAFDDC003A; Fri, 27 Mar 2009 16:23:11 +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 ZDUcicVHt2A9; Fri, 27 Mar 2009 16:23:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F866C0016; Fri, 27 Mar 2009 16:23:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F004AA42A5B; Fri, 27 Mar 2009 16:22:52 +0100 (CET) Date: Fri, 27 Mar 2009 16:22:52 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090327152252.GB24836@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200903271306.n2RD6SZP063621@idle.juniper.net> <49CCE860.2080801@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CCE860.2080801@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:22:21 -0000 On Fri, Mar 27, 2009 at 03:53:20PM +0100, Andy Bierman wrote: > But when it comes to identifiers, the agent is expected > to handle infinitely long strings, and just 'make sure' > they are unique in the first 63 chars? That does not work. The agent already has to buffer the 2G attribute I am sending in the element so that it can be echoed back. Now, that is a NETCONF issue and not a NETMOD issue but still if we talk about consistency... /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 Mar 27 08:43: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 4276E3A6A17 for ; Fri, 27 Mar 2009 08:43:03 -0700 (PDT) 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 AXyPQnI82p+J for ; Fri, 27 Mar 2009 08:43:02 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 94E3D3A68AD for ; Fri, 27 Mar 2009 08:43:02 -0700 (PDT) Received: (qmail 87630 invoked from network); 27 Mar 2009 15:43:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 27 Mar 2009 15:43:56 -0000 X-YMail-OSG: z6zbpSQVM1lPOZKVI0shBjpvJyi4f32i2GWCaroVKaapc_9jYK76zLLlTAb7fT.ABEyp_.PMIxfiOeL5oGZlz61W5S9ItLPX2xTKoW3bsY5d.dcQ_WujCVkUwrlsh0p7Er3gKH9hp7dt5Rz3Dh7isET4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CCF43A.7080004@netconfcentral.com> Date: Fri, 27 Mar 2009 08:43:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200903271306.n2RD6SZP063621@idle.juniper.net> <49CCE860.2080801@netconfcentral.com> <20090327152252.GB24836@elstar.local> In-Reply-To: <20090327152252.GB24836@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 15:43:03 -0000 Juergen Schoenwaelder wrote: > On Fri, Mar 27, 2009 at 03:53:20PM +0100, Andy Bierman wrote: > >> But when it comes to identifiers, the agent is expected >> to handle infinitely long strings, and just 'make sure' >> they are unique in the first 63 chars? That does not work. > > The agent already has to buffer the 2G attribute I am sending in the > element so that it can be echoed back. Now, that is a NETCONF > issue and not a NETMOD issue but still if we talk about consistency... > YANG does not support XML attributes. This issue has to do with interoperability of YANG module definitions, not NETCONF PDU content. This issue started because Phil said in the meeting that a usage guideline for the IETF wrt/ YANG module identifier length needed to be defined in the YANG spec itself. Now the claim is that no identifier length is needed. I agree with you. I withdraw the change request. The current text says that any tool that rejects any YANG identifier over 63 characters long is fully compliant with the standard. That is fine. If you think it is a good idea to write modules that are are allowed to be rejected with a fatal error by any YANG tool, then good luck with that. I plan to change the CLR in the usage guidelines draft so it says that every IETF standards-track YANG module identifier MUST be compatible with any compliant YANG tool. > /js > Andy From phil@juniper.net Fri Mar 27 09:14: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 D3B9D3A6C85 for ; Fri, 27 Mar 2009 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eObnZIIWGy2 for ; Fri, 27 Mar 2009 09:14:56 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id E97243A6824 for ; Fri, 27 Mar 2009 09:14:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKScz7sIuLwsK+tzZVZmD+0LNoFvyzh9a3@postini.com; Fri, 27 Mar 2009 09:15:50 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 27 Mar 2009 09:14:59 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 09:14:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 09:14:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 09:14:58 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2RGEvM21758; Fri, 27 Mar 2009 09:14:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2RG7qSW065088; Fri, 27 Mar 2009 16:07:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903271607.n2RG7qSW065088@idle.juniper.net> To: Andy Bierman In-Reply-To: <49CCF43A.7080004@netconfcentral.com> Date: Fri, 27 Mar 2009 12:07:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Mar 2009 16:14:58.0087 (UTC) FILETIME=[2C57B370:01C9AEF7] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 16:14:56 -0000 Andy Bierman writes: >This issue started because Phil said in the meeting that >a usage guideline for the IETF wrt/ YANG module identifier >length needed to be defined in the YANG spec itself. >Now the claim is that no identifier length is needed. My comment was that either this is an interoperability issue for YANG that needs fixed in YANG, or it's a CLR that isn't needed in either that YANG spec or the IETF guidelines. Thanks, Phil From randy_presuhn@mindspring.com Fri Mar 27 11:02: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 8212028C1B7 for ; Fri, 27 Mar 2009 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4RkUvIr-ncF for ; Fri, 27 Mar 2009 11:02:08 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id B991F3A6CC4 for ; Fri, 27 Mar 2009 11:02:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d8wlnGicRBgx4Z0NDTkz2DWiRmWYJz+DzwKgMHLnt6m6zU3HZ/DCWxtQ3N3NfRjN; 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 [69.3.146.179] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LnGOU-0000P3-4C for netmod@ietf.org; Fri, 27 Mar 2009 14:03:03 -0400 Message-ID: <003c01c9af06$7b104c20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200903271306.n2RD6SZP063621@idle.juniper.net> Date: Fri, 27 Mar 2009 11:04:31 -0700 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1730af879dddc5b43eb4b3127bf00b68011350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.179 Subject: Re: [netmod] identifier length X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 Mar 2009 18:02:09 -0000 Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: "NETMOD Working Group" > Sent: Friday, March 27, 2009 6:06 AM > Subject: Re: [netmod] identifier length ... > (b) "characters" in a utf world are distorted (for example, multiple > ways to make the same utf-8 content) I do hope the specification calls out the specific normalization form to be used. A stringprep profile would probably make sense. Randy From andy@netconfcentral.com Sat Mar 28 18:25: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 E4F043A6984 for ; Sat, 28 Mar 2009 18:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=-1.105, 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 VXHqrJ9Ud-2J for ; Sat, 28 Mar 2009 18:25:03 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 1BF4E3A6359 for ; Sat, 28 Mar 2009 18:25:02 -0700 (PDT) Received: (qmail 4035 invoked from network); 29 Mar 2009 01:25:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 29 Mar 2009 01:25:58 -0000 X-YMail-OSG: rFl7G4QVM1noPcnmMEoeY4QSrgS60EywWe_z8PQmo7aJpbHhbUiNY6Rsrdmj6SzRRVVd9yqcd9hDMBBRrsvO68M.Y61CHToZOc5h5519vcmLKxjUSBbrDX5FJnPKeIqtFcWkEt0fU4ZvWVkaaV7hiMqr X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CECE25.5000603@netconfcentral.com> Date: Sat, 28 Mar 2009 18:25:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 01:25:04 -0000 Hi, There seems to be 3 options wrt/ identifier length in the YANG language: 1) 1 .. infinity (no rule at all) 2) 1 .. N (MUST for every module: "identifiers MUST be 1 to N chars long") 3) 1 .. N (MUST only for standard modules: current text: "tools MUST accept 1 to N chars") Which do you prefer and why? If the result is (2) or (3), then the WG needs to pick a value for N, which will hopefully be 63. Andy From j.schoenwaelder@jacobs-university.de Sat Mar 28 23:07: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 5461D3A6886 for ; Sat, 28 Mar 2009 23:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_101=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 67KzWnZiU2P8 for ; Sat, 28 Mar 2009 23:07:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5B27F3A67A7 for ; Sat, 28 Mar 2009 23:07:49 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E12BC0017; Sun, 29 Mar 2009 08:08:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A9ilEyHHBsSp; Sun, 29 Mar 2009 08:08:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 674F8C0007; Sun, 29 Mar 2009 08:08:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C2869A447DA; Sun, 29 Mar 2009 08:08:27 +0200 (CEST) Date: Sun, 29 Mar 2009 08:08:27 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090329060827.GB26902@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <49CECE25.5000603@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CECE25.5000603@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 06:07:51 -0000 On Sun, Mar 29, 2009 at 03:25:57AM +0200, Andy Bierman wrote: > There seems to be 3 options wrt/ identifier length > in the YANG language: > > > 1) 1 .. infinity (no rule at all) > 2) 1 .. N (MUST for every module: > "identifiers MUST be 1 to N chars long") > 3) 1 .. N (MUST only for standard modules: > current text: "tools MUST accept 1 to N chars") 3) is actually "1..infinity but at least N must be supported" For me, 2) means an identifier>N is a hard error while 3) means an implementation can support longer identifiers but will generate a warning if they are used. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Sat Mar 28 23:22: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 6796B3A6CA0 for ; Sat, 28 Mar 2009 23:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.332 X-Spam-Level: * X-Spam-Status: No, score=1.332 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_40=-0.185, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17iRE8kIJzUx for ; Sat, 28 Mar 2009 23:22:36 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 4313F3A6886 for ; Sat, 28 Mar 2009 23:22:36 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LnoQc-00056X-RQ; Sun, 29 Mar 2009 08:23:31 +0200 Message-ID: <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "NETMOD Working Group" References: <49CECE25.5000603@netconfcentral.com> In-Reply-To: <49CECE25.5000603@netconfcentral.com> Date: Sat, 28 Mar 2009 23:22:46 -0700 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FD_01C9AFFC.1A3ACB90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 06:22:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01FD_01C9AFFC.1A3ACB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In SNMP, we specified that there could be no more than 128 OID subids. In the SMI, I don;t think we set a limit. But the fact that the base protocol defined alimit; that fact has caused = us to have to deal with things like InetAddress as an INDEX ... becaus = etheroretically that can be more than 128. Whatever we do, I would hope that we do not "hardcode" any limit into = the base protocol/spec. Rather, if we do limits, I would make them as current = "rules" or some such that we ould (if needed) relax in the future. With MIB descriptors, we have no SMI defined limit. We did have = originally a limit of 32 for IETF std track MIB modules. We later extended that to 64. And if = needed we can extend it to more. I think I would prefer a similar approach in YANG. Bert ----- Original Message -----=20 From: Andy Bierman=20 To: NETMOD Working Group=20 Sent: Saturday, March 28, 2009 6:25 PM Subject: [netmod] identifier length survey Hi, There seems to be 3 options wrt/ identifier length in the YANG language: 1) 1 .. infinity (no rule at all) 2) 1 .. N (MUST for every module: "identifiers MUST be 1 to N chars long") 3) 1 .. N (MUST only for standard modules: current text: "tools MUST accept 1 to N chars") Which do you prefer and why? If the result is (2) or (3), then the WG needs to pick a value for N, which will hopefully be 63. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_01FD_01C9AFFC.1A3ACB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In SNMP, we specified that there could be no more = than 128 OID=20 subids.
In the SMI, I don;t think we set a = limit.
But the fact that the base protocol defined alimit; = that fact=20 has caused us to have
to deal with things like InetAddress as an INDEX ... = becaus=20 etheroretically that can
be more than 128.
 
Whatever we do, I would hope that we do not = "hardcode" any=20 limit into the base
protocol/spec. Rather, if we do limits, I would make = them as=20 current "rules" or some
such that we ould (if needed) relax in the=20 future.
 
With MIB descriptors, we have no SMI defined limit. = We did=20 have originally a limit of 32
for IETF std track MIB modules. We later extended = that to 64.=20 And if needed we can
extend it to more.
 
I think I would prefer a similar approach in=20 YANG.
 
Bert
----- Original Message -----
From:=20 Andy=20 Bierman
Sent: Saturday, March 28, 2009 = 6:25=20 PM
Subject: [netmod] identifier = length=20 survey

Hi,

There seems to be 3 options wrt/ identifier=20 length
in the YANG language:


   1) 1 .. = infinity =20 (no rule at all)
   2) 1 ..=20 N         (MUST for every=20 = module:
          &n= bsp;          =20 "identifiers MUST be 1 to N chars long")
   3) 1 ..=20 N         (MUST only for = standard=20 = modules:
          &= nbsp;          =20 current text: "tools MUST accept 1 to N chars")

Which do you = prefer and=20 why?

If the result is (2) or (3), then the WG needs to pick a = value for=20 N,
which will hopefully be=20 = 63.



Andy


______________________________________= _________
netmod=20 mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod
------=_NextPart_000_01FD_01C9AFFC.1A3ACB90-- From phil@juniper.net Sun Mar 29 07:07: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 558A13A659B for ; Sun, 29 Mar 2009 07:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aJ8-80mAZMj for ; Sun, 29 Mar 2009 07:07:17 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 3A0403A68E6 for ; Sun, 29 Mar 2009 07:07:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSc+Ayr17N/2Xy2s9Qo287PAJh/i71B0n@postini.com; Sun, 29 Mar 2009 07:08:14 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 29 Mar 2009 07:06:37 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Mar 2009 07:06:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Mar 2009 07:06:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Mar 2009 07:06:35 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2TE6ZM22602; Sun, 29 Mar 2009 07:06:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2TDxS4O080527; Sun, 29 Mar 2009 13:59:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903291359.n2TDxS4O080527@idle.juniper.net> To: Andy Bierman In-Reply-To: <49CECE25.5000603@netconfcentral.com> Date: Sun, 29 Mar 2009 09:59:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Mar 2009 14:06:35.0932 (UTC) FILETIME=[92539DC0:01C9B077] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 14:07:18 -0000 Andy Bierman writes: >There seems to be 3 options wrt/ identifier length >in the YANG language: > 1) 1 .. infinity (no rule at all) > 2) 1 .. N (MUST for every module: > "identifiers MUST be 1 to N chars long") > 3) 1 .. N (MUST only for standard modules: > current text: "tools MUST accept 1 to N chars") >Which do you prefer and why? I prefer (1) since it does not impose an artificial limit. This option follows the path of XML, which has no limit on the length of XML element names, XML Namespace strings, etc. Thanks, Phil From j.schoenwaelder@jacobs-university.de Sun Mar 29 07:11:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A788A3A6829 for ; Sun, 29 Mar 2009 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS2jEf4PrKlJ for ; Sun, 29 Mar 2009 07:11:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 588573A67F7 for ; Sun, 29 Mar 2009 07:11:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C54E0C0020; Sun, 29 Mar 2009 16:12:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OG+BY6wE1f8s; Sun, 29 Mar 2009 16:12:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE892C001B; Sun, 29 Mar 2009 16:12:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 09ACAA44A5F; Sun, 29 Mar 2009 16:11:54 +0200 (CEST) Date: Sun, 29 Mar 2009 16:11:54 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090329141154.GA27087@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Andy Bierman , NETMOD Working Group References: <49CECE25.5000603@netconfcentral.com> <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 14:11:17 -0000 On Sun, Mar 29, 2009 at 08:22:46AM +0200, Bert Wijnen (IETF) wrote: > In SNMP, we specified that there could be no more than 128 OID > subids. In the SMI, I don;t think we set a limit. But the fact > that the base protocol defined alimit; that fact has caused us to > have to deal with things like InetAddress as an INDEX ... becaus > etheroretically that can be more than 128. The OID limit is not comparable to YANG identifiers; if at all, a sub-identifier would be comparable to a YANG identifier. And YANG/NETCONF does not require to encode key values into the name. > Whatever we do, I would hope that we do not "hardcode" any limit > into the base protocol/spec. Rather, if we do limits, I would make > them as current "rules" or some such that we ould (if needed) relax > in the future. > > With MIB descriptors, we have no SMI defined limit. We did have > originally a limit of 32 for IETF std track MIB modules. We later > extended that to 64. And if needed we can extend it to more. RFC 2578: For all descriptors appearing in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. (However, descriptors longer than 32 characters are not recommended.) I think we do have an SMI defined limit and I am not sure how easy it is to extend (an RFC overwriting this part part of RFC 2578 would be needed I think). There are notable differences between YANG and the SMI here. YANG identifiers show up as XML elements names while SMI descriptors have no impact on the wire. In both cases, identifiers / descriptors are translated to source code and there are usually restrictions (in C99 for example, only 63 characters are significant - this is where the 63 comes from). Of course, compilers that translate to other formats may have to do some name mangling if the target identifier length is shorter than some N. /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 Sun Mar 29 08:41: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 5AA953A6ABA for ; Sun, 29 Mar 2009 08:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G34FNgQcKPQy for ; Sun, 29 Mar 2009 08:41:45 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 780883A659B for ; Sun, 29 Mar 2009 08:41:45 -0700 (PDT) Received: from [68.142.194.244] by n10.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2009 15:42:42 -0000 Received: from [68.142.201.70] by t2.bullet.mud.yahoo.com with NNFMP; 29 Mar 2009 15:42:42 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 29 Mar 2009 15:42:42 -0000 X-Yahoo-Newman-Id: 349946.44926.bm@omp422.mail.mud.yahoo.com Received: (qmail 82449 invoked from network); 29 Mar 2009 15:42:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 29 Mar 2009 15:42:41 -0000 X-YMail-OSG: LQ8ntywVM1lPpUnLLw5lZyetIPqxizP3v3R.s_LhQ6GHNjNBok5tCsLXUmyEQ2VMnSJeoTS.PQn1fS9w9Bbm3Q23rcoXoN4qJHSpDrbMhAdPo.PhevQ2Q2uEu21w3btLrKxRl6ex2F7dY_QHR7RQ7iZJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CF96EF.80902@netconfcentral.com> Date: Sun, 29 Mar 2009 08:42:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Andy Bierman , NETMOD Working Group References: <49CECE25.5000603@netconfcentral.com> <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> <20090329141154.GA27087@elstar.local> In-Reply-To: <20090329141154.GA27087@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 15:41:46 -0000 Juergen Schoenwaelder wrote: > On Sun, Mar 29, 2009 at 08:22:46AM +0200, Bert Wijnen (IETF) wrote: > >> In SNMP, we specified that there could be no more than 128 OID >> subids. In the SMI, I don;t think we set a limit. But the fact >> that the base protocol defined alimit; that fact has caused us to >> have to deal with things like InetAddress as an INDEX ... becaus >> etheroretically that can be more than 128. > > The OID limit is not comparable to YANG identifiers; if at all, a > sub-identifier would be comparable to a YANG identifier. And > YANG/NETCONF does not require to encode key values into the name. > >> Whatever we do, I would hope that we do not "hardcode" any limit >> into the base protocol/spec. Rather, if we do limits, I would make >> them as current "rules" or some such that we ould (if needed) relax >> in the future. >> >> With MIB descriptors, we have no SMI defined limit. We did have >> originally a limit of 32 for IETF std track MIB modules. We later >> extended that to 64. And if needed we can extend it to more. > > RFC 2578: > > For all descriptors appearing in an information module, the > descriptor shall be unique and mnemonic, and shall not exceed 64 > characters in length. (However, descriptors longer than 32 > characters are not recommended.) > > I think we do have an SMI defined limit and I am not sure how easy it > is to extend (an RFC overwriting this part part of RFC 2578 would be > needed I think). > > There are notable differences between YANG and the SMI here. YANG > identifiers show up as XML elements names while SMI descriptors have > no impact on the wire. In both cases, identifiers / descriptors are > translated to source code and there are usually restrictions (in C99 > for example, only 63 characters are significant - this is where the 63 > comes from). Of course, compilers that translate to other formats may > have to do some name mangling if the target identifier length is > shorter than some N. > I still do not understand why 63 characters is not long enough. In 21 years and 100,000s of MIB objects, not one person has ever wanted an SMIv2 object descriptor that even reached 63 characters long. Now some people think YANG needs to support infinite length descriptors? What is the use-case? Here's another real limit for IETF MIBs: 72. Identifiers cannot be quoted, and only quoted strings can be split across multiple lines, and an RFC line cannot exceed 72 characters. > /js > Andy From bertietf@bwijnen.net Sun Mar 29 09:06:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9FC3A6814 for ; Sun, 29 Mar 2009 09:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9MYBzeFZXhi for ; Sun, 29 Mar 2009 09:06:49 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 690E23A659B for ; Sun, 29 Mar 2009 09:06:47 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LnxXu-0003AW-LC; Sun, 29 Mar 2009 18:07:40 +0200 Message-ID: <3775529FA60248D1905B4600221F07BB@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Juergen Schoenwaelder" References: <49CECE25.5000603@netconfcentral.com> <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> <20090329141154.GA27087@elstar.local> In-Reply-To: <20090329141154.GA27087@elstar.local> Date: Sun, 29 Mar 2009 09:07:31 -0700 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CB_01C9B04D.CA6F4530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 16:06:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02CB_01C9B04D.CA6F4530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know OIDs are not relevant. I was trying to get across that I prefer to leave the formal spec = flexible (so 1..infinity) and then define guidances (aka: no longer than 63 is recommended). Bert ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Bert Wijnen (IETF)=20 Cc: Andy Bierman ; NETMOD Working Group=20 Sent: Sunday, March 29, 2009 7:11 AM Subject: Re: [netmod] identifier length survey On Sun, Mar 29, 2009 at 08:22:46AM +0200, Bert Wijnen (IETF) wrote: > In SNMP, we specified that there could be no more than 128 OID > subids. In the SMI, I don;t think we set a limit. But the fact > that the base protocol defined alimit; that fact has caused us to > have to deal with things like InetAddress as an INDEX ... becaus > etheroretically that can be more than 128. The OID limit is not comparable to YANG identifiers; if at all, a sub-identifier would be comparable to a YANG identifier. And YANG/NETCONF does not require to encode key values into the name. > Whatever we do, I would hope that we do not "hardcode" any limit > into the base protocol/spec. Rather, if we do limits, I would make > them as current "rules" or some such that we ould (if needed) relax > in the future. > > With MIB descriptors, we have no SMI defined limit. We did have > originally a limit of 32 for IETF std track MIB modules. We later > extended that to 64. And if needed we can extend it to more. RFC 2578: For all descriptors appearing in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. (However, descriptors longer than 32 characters are not recommended.) I think we do have an SMI defined limit and I am not sure how easy it is to extend (an RFC overwriting this part part of RFC 2578 would be needed I think). There are notable differences between YANG and the SMI here. YANG identifiers show up as XML elements names while SMI descriptors have no impact on the wire. In both cases, identifiers / descriptors are translated to source code and there are usually restrictions (in C99 for example, only 63 characters are significant - this is where the 63 comes from). Of course, compilers that translate to other formats may have to do some name mangling if the target identifier length is shorter than some N. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 ------=_NextPart_000_02CB_01C9B04D.CA6F4530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I know OIDs are not relevant.
I was trying to get across that I prefer to leave = the formal=20 spec flexible
(so 1..infinity) and then define guidances (aka: no = longer=20 than 63 is
recommended).
 
Bert
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Cc: Andy Bierman ; NETMOD Working = Group=20
Sent: Sunday, March 29, 2009 = 7:11=20 AM
Subject: Re: [netmod] = identifier length=20 survey

On Sun, Mar 29, 2009 at 08:22:46AM +0200, Bert Wijnen = (IETF)=20 wrote:

> In SNMP, we specified that there could be no more = than 128=20 OID
> subids.  In the SMI, I don;t think we set a = limit.  But=20 the fact
> that the base protocol defined alimit; that fact has = caused=20 us to
> have to deal with things like InetAddress as an INDEX = ...=20 becaus
> etheroretically that can be more than 128.

The = OID limit=20 is not comparable to YANG identifiers; if at all, a
sub-identifier = would be=20 comparable to a YANG identifier. And
YANG/NETCONF does not require = to=20 encode key values into the name.

> Whatever we do, I would = hope that=20 we do not "hardcode" any limit
> into the base protocol/spec. = Rather, if=20 we do limits, I would make
> them as current "rules" or some = such that=20 we ould (if needed) relax
> in the future.
>
> With = MIB=20 descriptors, we have no SMI defined limit. We did have
> = originally a=20 limit of 32 for IETF std track MIB modules. We later
> extended = that to=20 64. And if needed we can extend it to more.

RFC=20 2578:

   For all descriptors appearing in an = information=20 module, the
   descriptor shall be unique and mnemonic, = and shall=20 not exceed 64
   characters in length.  (However,=20 descriptors longer than 32
   characters are not=20 recommended.)

I think we do have an SMI defined limit and I am = not sure=20 how easy it
is to extend (an RFC overwriting this part part of RFC = 2578=20 would be
needed I think).

There are notable differences = between YANG=20 and the SMI here. YANG
identifiers show up as XML elements names = while SMI=20 descriptors have
no impact on the wire. In both cases, identifiers = /=20 descriptors are
translated to source code and there are usually=20 restrictions (in C99
for example, only 63 characters are = significant - this=20 is where the 63
comes from). Of course, compilers that translate to = other=20 formats may
have to do some name mangling if the target identifier = length=20 is
shorter than some N.

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
------=_NextPart_000_02CB_01C9B04D.CA6F4530-- From andy@netconfcentral.com Sun Mar 29 09:16: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 800673A6AA0 for ; Sun, 29 Mar 2009 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.618, 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 DO+BcrN1wvpr for ; Sun, 29 Mar 2009 09:16:42 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id E118A3A6814 for ; Sun, 29 Mar 2009 09:16:42 -0700 (PDT) Received: (qmail 5294 invoked from network); 29 Mar 2009 16:17:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Mar 2009 16:17:39 -0000 X-YMail-OSG: KLVYUb0VM1mn1HySDQUznxAuuky6fhjQkE8mKQRw8LqRKdx5CI5HfPFEYcvpY7ikKgSFG3ui45yOyWFz35jajB59ishfo04DJXXtxQeaCkaGqV.NMlkIh3oFFv40yj7AOld81TN7RSi6mEfgk0Q4YbY9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CF9F22.3010005@netconfcentral.com> Date: Sun, 29 Mar 2009 09:17:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <49CECE25.5000603@netconfcentral.com> <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> <20090329141154.GA27087@elstar.local> <3775529FA60248D1905B4600221F07BB@BertLaptop> In-Reply-To: <3775529FA60248D1905B4600221F07BB@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 16:16:43 -0000 Bert Wijnen (IETF) wrote: > I know OIDs are not relevant. > I was trying to get across that I prefer to leave the formal spec flexible > (so 1..infinity) and then define guidances (aka: no longer than 63 is > recommended). > Are you suggesting a change to the current text? Is anybody? If not, then this tar-pit is played out, right? > Bert Andy From andy@netconfcentral.com Sun Mar 29 09:23: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 56CD73A6A47 for ; Sun, 29 Mar 2009 09:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, J_CHICKENPOX_101=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 y-T0FaeTPOcj for ; Sun, 29 Mar 2009 09:23:06 -0700 (PDT) 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 985863A6963 for ; Sun, 29 Mar 2009 09:23:06 -0700 (PDT) Received: from [68.142.200.221] by n27.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2009 16:24:03 -0000 Received: from [68.142.201.240] by t9.bullet.mud.yahoo.com with NNFMP; 29 Mar 2009 16:24:03 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 29 Mar 2009 16:24:03 -0000 X-Yahoo-Newman-Id: 679167.16250.bm@omp401.mail.mud.yahoo.com Received: (qmail 8969 invoked from network); 29 Mar 2009 16:24:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 29 Mar 2009 16:24:02 -0000 X-YMail-OSG: mdElVasVM1lHgJPTk5FMCf.dSa24giUw8vok16Q07hdj3C2ZdSBLPsFjbwinvkFenIByA1F1zyYPYM5FVqMDQKS_ikLmkuo2ZBNs.nJrlRZ0VaPDsIjhePUN3_9AyFte7.AO0sWgW.UmkIqXHFrSorhe X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CFA0A1.1020208@netconfcentral.com> Date: Sun, 29 Mar 2009 09:24:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <49CECE25.5000603@netconfcentral.com> <20090329060827.GB26902@elstar.local> In-Reply-To: <20090329060827.GB26902@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 16:23:07 -0000 Juergen Schoenwaelder wrote: > On Sun, Mar 29, 2009 at 03:25:57AM +0200, Andy Bierman wrote: > >> There seems to be 3 options wrt/ identifier length >> in the YANG language: >> >> >> 1) 1 .. infinity (no rule at all) >> 2) 1 .. N (MUST for every module: >> "identifiers MUST be 1 to N chars long") >> 3) 1 .. N (MUST only for standard modules: >> current text: "tools MUST accept 1 to N chars") > > 3) is actually "1..infinity but at least N must be supported" > > For me, 2) means an identifier>N is a hard error while 3) means an > implementation can support longer identifiers but will generate a > warning if they are used. > For me, the problem with (3) is that it is a rule written in terms of what a tool MUST accept, but every other rule in the YANG spec is specified in terms of what a YANG author MUST write. That is why I wanted to change it in the first place. If the rule was formulated the proper way, it would be much easier to understand. > /js > Andy From mbj@tail-f.com Sun Mar 29 09:36: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 117273A6B44 for ; Sun, 29 Mar 2009 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCilGAMLYXm9 for ; Sun, 29 Mar 2009 09:36:57 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4E2A93A6B40 for ; Sun, 29 Mar 2009 09:36:57 -0700 (PDT) Received: from localhost (unknown [66.172.119.115]) by mail.tail-f.com (Postfix) with ESMTPSA id 99BDA76C4FF; Sun, 29 Mar 2009 18:37:52 +0200 (CEST) Date: Sun, 29 Mar 2009 09:37:50 -0700 (PDT) Message-Id: <20090329.093750.23044516.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49CF96EF.80902@netconfcentral.com> References: <6F3016B2F6A24BBD9470D45D3A93BAF0@BertLaptop> <20090329141154.GA27087@elstar.local> <49CF96EF.80902@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] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 16:36:58 -0000 Andy Bierman wrote: > Identifiers cannot be quoted, and only quoted strings > can be split across multiple lines, and an RFC line cannot > exceed 72 characters. I just want to point out that identifiers can be quoted. YANG keywords cannot be quoted, by any argument to a keyword can be quoted. YANG has a very simple syntax: statement = keyword [argument] (";" / "{" *statement "}") So this is legal: leaf 'sys' + 'Name' { ... } /martin From phil@juniper.net Sun Mar 29 12:37: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 5EF0C3A6C0F for ; Sun, 29 Mar 2009 12:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw8ewAC-ewCS for ; Sun, 29 Mar 2009 12:37:48 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 715073A6BD4 for ; Sun, 29 Mar 2009 12:37:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSc/OPtrxTG0yTdnEgsJvkfZjOxahhSu8@postini.com; Sun, 29 Mar 2009 12:38:46 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 29 Mar 2009 12:35:34 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Mar 2009 12:35:34 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Mar 2009 12:35:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Mar 2009 12:35:33 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2TJZWM24306; Sun, 29 Mar 2009 12:35:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2TJSOja081769; Sun, 29 Mar 2009 19:28:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903291928.n2TJSOja081769@idle.juniper.net> To: Andy Bierman In-Reply-To: <49CF9F22.3010005@netconfcentral.com> Date: Sun, 29 Mar 2009 15:28:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Mar 2009 19:35:33.0373 (UTC) FILETIME=[86C21AD0:01C9B0A5] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 19:37:49 -0000 Andy Bierman writes: >Are you suggesting a change to the current text? >Is anybody? If not, then this tar-pit is played out, right? You raised this as an interoperability issue at the WG meeting. I agree with you. The current text should be changed, since it allows one to write YANG modules that compiler with one valid tool set, but can fail (years later) with another perfectly valid tool set. This is a serious (though minor) issue and should be resolved. The question is: do we need to limit identifier length? If you have a convincing argument, please share it. My opinion is that there's no purpose served by a limit, and no having one matches what XML does. While there are many components of XML that YANG avoids, we have a convincing reason for avoiding them. Lacking a justification, a limit is just a CLR. Thanks, Phil From j.schoenwaelder@jacobs-university.de Sun Mar 29 13:04: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 94A0F3A6AB3 for ; Sun, 29 Mar 2009 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.180, 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 HmmJm04-Wbb9 for ; Sun, 29 Mar 2009 13:04:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B0D083A685C for ; Sun, 29 Mar 2009 13:04:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95BF2C0020; Sun, 29 Mar 2009 22:05:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FkGuxX6jFdIn; Sun, 29 Mar 2009 22:05:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DA24C0004; Sun, 29 Mar 2009 22:05:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7F511A44D07; Sun, 29 Mar 2009 22:04:51 +0200 (CEST) Date: Sun, 29 Mar 2009 22:04:51 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090329200451.GA27432@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , NETMOD Working Group References: <49CF9F22.3010005@netconfcentral.com> <200903291928.n2TJSOja081769@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903291928.n2TJSOja081769@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 20:04:14 -0000 On Sun, Mar 29, 2009 at 09:28:24PM +0200, Phil Shafer wrote: > The current text should be changed, since it allows one to write > YANG modules that compiler with one valid tool set, but can fail > (years later) with another perfectly valid tool set. Here is the text: Implementations MUST support identifiers up to 63 characters in length. I do not understand how you reach the conclusion quoted above from this sentence. /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 Sun Mar 29 15:17: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 325683A6955 for ; Sun, 29 Mar 2009 15:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.139, 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 GC-LbAVEC59m for ; Sun, 29 Mar 2009 15:17:28 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 69B6C3A6903 for ; Sun, 29 Mar 2009 15:17:28 -0700 (PDT) Received: (qmail 81838 invoked from network); 29 Mar 2009 22:18:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 29 Mar 2009 22:18:25 -0000 X-YMail-OSG: 3U4P_fcVM1lm6PMcmRUFsN0XT._tvfzwi9jl7oG4vs5EWFQNfBu9NUt63uju423RtmEvRY9XUIowv7o1P75XDbj5i8DEr12th2nZVIOVjI9_qCk9KlhawKIMS9VcczTvTssvJ9fkTm9nrcH3.41bKnsD X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CFF3AF.3080305@netconfcentral.com> Date: Sun, 29 Mar 2009 15:18:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer , NETMOD Working Group References: <49CF9F22.3010005@netconfcentral.com> <200903291928.n2TJSOja081769@idle.juniper.net> <20090329200451.GA27432@elstar.local> In-Reply-To: <20090329200451.GA27432@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 22:17:29 -0000 Juergen Schoenwaelder wrote: > On Sun, Mar 29, 2009 at 09:28:24PM +0200, Phil Shafer wrote: > >> The current text should be changed, since it allows one to write >> YANG modules that compiler with one valid tool set, but can fail >> (years later) with another perfectly valid tool set. > > Here is the text: > > Implementations MUST support identifiers up to 63 characters in > length. > > I do not understand how you reach the conclusion quoted above from > this sentence. > I agree with you. But there is no sentence that says: Implementations MAY support identifiers longer than 63 characters in length. Perhaps that is what Phil means. I am not sure what adding that sentence would mean to the standard. I am fine with the current text, as-is. I agree with the comment that Wes made at the meeting, which is that tool makers need to know how what size an identifier can be, in order to create a conforming implementation. For many practical reasons, the number needs to be a lot closer to 63 than infinity. I cannot think of a sentence any more clear than the one Juergen wrote to accomplish that. It means that if you use an identifier in a YANG module that is 63 characters or less, and your tool does not accept it, your tool is broken. > /js > Andy From andy@netconfcentral.com Sun Mar 29 15:52: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 843823A68B2 for ; Sun, 29 Mar 2009 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.136, 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 sluEQ1fCYaNi for ; Sun, 29 Mar 2009 15:52:43 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id D1B1B3A67E7 for ; Sun, 29 Mar 2009 15:52:43 -0700 (PDT) Received: (qmail 4750 invoked from network); 29 Mar 2009 22:53:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 29 Mar 2009 22:53:40 -0000 X-YMail-OSG: jQByRK4VM1lLcmSRwIwomCzaXj0XEM0B6ZDb3etmFu7mvTul8XT1lMW.F6QsdH7indiErf7exYWE4CIXWy2GpG9qJf8RsnbhM.QYHuBUAypsYaLE.EhHy6rCQREacinwbuiJ5ikthKg3VqC181M5MvXA X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CFFBF3.5090303@netconfcentral.com> Date: Sun, 29 Mar 2009 15:53:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200903291928.n2TJSOja081769@idle.juniper.net> In-Reply-To: <200903291928.n2TJSOja081769@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Mar 2009 22:52:44 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Are you suggesting a change to the current text? >> Is anybody? If not, then this tar-pit is played out, right? > > You raised this as an interoperability issue at the WG meeting. I > agree with you. The current text should be changed, since it allows > one to write YANG modules that compiler with one valid tool set, > but can fail (years later) with another perfectly valid tool set. > This is a serious (though minor) issue and should be resolved. > > The question is: do we need to limit identifier length? If you > have a convincing argument, please share it. My opinion is that > there's no purpose served by a limit, and no having one matches > what XML does. While there are many components of XML that YANG > avoids, we have a convincing reason for avoiding them. Lacking a > justification, a limit is just a CLR. > It is not just a CLR. Saying that implementations MUST support infinite length identifiers is a non-starter. Saying that implementations can pick whatever identifier length they want and YANG module writers will have no idea what to expect across tool-vendors is a non-starter. There are no OIDs in NETCONF. The descriptors are stored in the agent, and show up in lots of PDUs. Code is generated using these descriptors. The memory impact from these descriptors is already non-trivial at 63 chars. For these 3 reasons alone, there needs to be a finite limit specified. > Thanks, > Phil > > Andy From lhotka@cesnet.cz Sun Mar 29 23:15:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98EB43A6CC6 for ; Sun, 29 Mar 2009 23:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1iS7wbL65TH for ; Sun, 29 Mar 2009 23:15:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CDDF33A69E4 for ; Sun, 29 Mar 2009 23:15:52 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BD455D800BD for ; Mon, 30 Mar 2009 08:16:49 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49CECE25.5000603@netconfcentral.com> References: <49CECE25.5000603@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 30 Mar 2009 08:16:49 +0200 Message-Id: <1238393809.6561.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 06:15:53 -0000 Andy Bierman píše v So 28. 03. 2009 v 18:25 -0700: > Hi, > > There seems to be 3 options wrt/ identifier length > in the YANG language: > > > 1) 1 .. infinity (no rule at all) > 2) 1 .. N (MUST for every module: > "identifiers MUST be 1 to N chars long") > 3) 1 .. N (MUST only for standard modules: > current text: "tools MUST accept 1 to N chars") > > Which do you prefer and why? I don't have a strong opinion and tend to support 1), but I am also fine with the existing formulation - I believe no sane module designer would ever try to exceed the 63 char limit, and it can be also stressed in the guidelines document. Lada > > If the result is (2) or (3), then the WG needs to pick a value for N, > which will hopefully be 63. > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Mar 30 06:03:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15843A688A for ; Mon, 30 Mar 2009 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFGjbXKcbztb for ; Mon, 30 Mar 2009 06:03:16 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 71F943A686A for ; Mon, 30 Mar 2009 06:03:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSdDDSj31IXpcCxqbfJdaeZ5tfvEhl7g5@postini.com; Mon, 30 Mar 2009 06:04:15 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Mar 2009 06:01:49 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 06:01:50 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 06:01:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 06:01:48 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2UD1mM38819; Mon, 30 Mar 2009 06:01:48 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2UCsdQu086882; Mon, 30 Mar 2009 12:54:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903301254.n2UCsdQu086882@idle.juniper.net> To: Andy Bierman In-Reply-To: <49CFFBF3.5090303@netconfcentral.com> Date: Mon, 30 Mar 2009 08:54:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Mar 2009 13:01:48.0981 (UTC) FILETIME=[AFEFB650:01C9B137] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 13:03:17 -0000 Andy Bierman writes: >Saying that implementations MUST support infinite length >identifiers is a non-starter. This is the part I don't follow you on. Many technologies are able to use XML without limit the length of the elements they use. XSLT, for example, does not say that one can only write stylesheets for XML documents where the element names do not exceed 63 characters. XSD editors don't fail when editing schemas for languages that use element names longer than 63 characters. XML parsers are perfectly happy when handling these long element names. The developers of all those tools would certainly question the mental abilities of someone that makes a 2048 character long identifier, but they don't stop working when faced with one. Similarly, I can't see why one would, but I can't see why we can't handle it. In general, identifier length will be self regulating. If you see someone publish a YANG module with a 2048 character long identifier, you will question their sanity and perhaps decide not to implement such a module. You may decide to work with the author to make a module that's sane. But you shouldn't need to go to the author and say that you love their module but can't use it because your toolset only supports 63 character identifiers. If there's no strong reasoning behind the rule, it's a CLR. >There are no OIDs in NETCONF. Completely agree ;^) >The descriptors are stored in the agent, >and show up in lots of PDUs. True, but not speed over the wire is not the goal of XML-based protocols. >Code is generated using these descriptors. These are code generators for XML schema, etc. >The memory impact from these descriptors is already >non-trivial at 63 chars. 63 characters is pretty trivial as far as memory footprint. More importantly, only those who implement modules with obnoxiously long identifiers pay the price. If a device implements only sane modules, there's no price to be paid. Thanks, Phil From andy@netconfcentral.com Mon Mar 30 07:06: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 5472B3A6D1C for ; Mon, 30 Mar 2009 07:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH7hyMYcUXKG for ; Mon, 30 Mar 2009 07:06:44 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 818B53A6D17 for ; Mon, 30 Mar 2009 07:06:44 -0700 (PDT) Received: (qmail 38561 invoked from network); 30 Mar 2009 14:07:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 30 Mar 2009 14:07:40 -0000 X-YMail-OSG: 7xKhTPcVM1mEFHFVFShnZZzIz_9LzxJdKHslCHQoaRSZNMsfUx.y0ywkZYBqKIwrIcCS8MMUTOoDaTWiC2kqvbx5QHg5hurrTKWbwEX_xkkZzbwbj.gMbRuek0qzIz.ZmSVz3e9DQBT7EN9fHwjrQu.. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D0D229.8070405@netconfcentral.com> Date: Mon, 30 Mar 2009 07:07:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200903301254.n2UCsdQu086882@idle.juniper.net> In-Reply-To: <200903301254.n2UCsdQu086882@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:06:45 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Saying that implementations MUST support infinite length >> identifiers is a non-starter. > I don't know how to implement infinite length identifiers. Do you? How is it that memory resources of no concern in this case, but they are super-critical when it comes to making sure the list keys are first? It's just memory. Deal with it. So every implementation is going to pick a limit, but every one will be different. Great standard. > This is the part I don't follow you on. Many technologies are able > to use XML without limit the length of the elements they use. XSLT, > for example, does not say that one can only write stylesheets for > XML documents where the element names do not exceed 63 characters. > XSD editors don't fail when editing schemas for languages that use > element names longer than 63 characters. XML parsers are perfectly > happy when handling these long element names. The developers of > all those tools would certainly question the mental abilities of > someone that makes a 2048 character long identifier, but they don't > stop working when faced with one. Similarly, I can't see why one > would, but I can't see why we can't handle it. > > In general, identifier length will be self regulating. If you see > someone publish a YANG module with a 2048 character long identifier, > you will question their sanity and perhaps decide not to implement > such a module. You may decide to work with the author to make a > module that's sane. But you shouldn't need to go to the author and > say that you love their module but can't use it because your toolset > only supports 63 character identifiers. > Self-regulating does not work in standards. We cannot have the standard say that an implementation is conforming if it support 1 byte identifiers. That's what you want by removing the rule entirely. > If there's no strong reasoning behind the rule, it's a CLR. > Huh? The reason is to protect the YANG writers! They need to know if it is safe to use a particular identifier value. The standard currently says "You are safe if you use 63 chars or less." That is far from a CLR. It is critical to interoperability and deployment. >> There are no OIDs in NETCONF. > > Completely agree ;^) > >> The descriptors are stored in the agent, >> and show up in lots of PDUs. > > True, but not speed over the wire is not the goal of XML-based > protocols. > >> Code is generated using these descriptors. > > These are code generators for XML schema, etc. > >> The memory impact from these descriptors is already >> non-trivial at 63 chars. > > 63 characters is pretty trivial as far as memory footprint. > times 10,000 objects it is not trivial... > More importantly, only those who implement modules with obnoxiously > long identifiers pay the price. If a device implements only sane > modules, there's no price to be paid. > > Thanks, > Phil > > Andy From phil@juniper.net Mon Mar 30 07:08: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 7501028C0EF for ; Mon, 30 Mar 2009 07:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 bDgAjjziy0xr for ; Mon, 30 Mar 2009 07:08:03 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 8E6E93A6D17 for ; Mon, 30 Mar 2009 07:07:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSdDSdrlpo7TKotu/d7BIV+YhuO493ovY@postini.com; Mon, 30 Mar 2009 07:09:01 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Mar 2009 07:07:51 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:07:51 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:07:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:07:50 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2UE7oM67795; Mon, 30 Mar 2009 07:07:50 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2UE0gcL087442; Mon, 30 Mar 2009 14:00:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903301400.n2UE0gcL087442@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090329200451.GA27432@elstar.local> Date: Mon, 30 Mar 2009 10:00:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Mar 2009 14:07:50.0620 (UTC) FILETIME=[E941D9C0:01C9B140] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:08:08 -0000 Juergen Schoenwaelder writes: >On Sun, Mar 29, 2009 at 09:28:24PM +0200, Phil Shafer wrote: >> The current text should be changed, since it allows one to write >> YANG modules that compiler with one valid tool set, but can fail >> (years later) with another perfectly valid tool set. >Here is the text: > Implementations MUST support identifiers up to 63 characters in > length. >I do not understand how you reach the conclusion quoted above from >this sentence. If toolsets are allowed to support differing identifier lengths, some tools will happily eat long idenfitiers and others will not. Modules written for one toolset will not compile on another, even though both toolsets are following the spec. Consider the following real world scenario: I have a module with a 64 character leaf name. I publish it. The entire world rallies behind this standard, and life is good. Then you need to run my module on your device. But when you compile the module, it fails with a ">63" error. The rest of the world is running the open source YANG libraries that don't give an error or warning for my leaf, but you've bought a toolset that won't compile it. You send me email, but I tell you (a) use the open source tools, and (b) the module is published and working, so I'm not about to change it. I tap my finger tips on my helmet while whispering to my teammates "Fetchez le vache!". If I can't count on tools supporting long identifiers, then I can't use long identifiers and the 63 minimum maximum becomes the defacto maximum. If that's the case, we should say this in the draft, fixing the max at 63 characters. I don't see a strong reason for this, so I'd prefer to remove the limit completely. Thanks, Phil From lhotka@cesnet.cz Mon Mar 30 07:13: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 6AC6B3A691E for ; Mon, 30 Mar 2009 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEO3f+Y8PEIr for ; Mon, 30 Mar 2009 07:13:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A06F33A688A for ; Mon, 30 Mar 2009 07:13:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 200A0D800C0 for ; Mon, 30 Mar 2009 16:14:26 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49D0D229.8070405@netconfcentral.com> References: <200903301254.n2UCsdQu086882@idle.juniper.net> <49D0D229.8070405@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 30 Mar 2009 16:14:26 +0200 Message-Id: <1238422466.6561.74.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:13:29 -0000 Andy Bierman píše v Po 30. 03. 2009 v 07:07 -0700: > Phil Shafer wrote: > > Andy Bierman writes: > >> Saying that implementations MUST support infinite length > >> identifiers is a non-starter. > > > > I don't know how to implement infinite length identifiers. Do you? > How is it that memory resources of no concern in this case, > but they are super-critical when it comes to making sure > the list keys are first? It's just memory. Deal with it. > > So every implementation is going to pick a limit, > but every one will be different. Great standard. Not necessarily, the memory for the identifier strings can be allocated dynamically without setting any arbitrary limit on their length. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Mar 30 07:26:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E4D3A6D0F for ; Mon, 30 Mar 2009 07:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnFqcd2iKLrM for ; Mon, 30 Mar 2009 07:26:27 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9AD4E3A6D13 for ; Mon, 30 Mar 2009 07:26:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSdDWyWWgSL8khcfShNduPn482hcCrzXj@postini.com; Mon, 30 Mar 2009 07:27:26 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Mar 2009 07:27:02 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:27:02 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:27:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:27:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2UER0M76120; Mon, 30 Mar 2009 07:27:00 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2UEJqi2087629; Mon, 30 Mar 2009 14:19:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903301419.n2UEJqi2087629@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D0D229.8070405@netconfcentral.com> Date: Mon, 30 Mar 2009 10:19:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Mar 2009 14:27:01.0404 (UTC) FILETIME=[972D8DC0:01C9B143] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:26:31 -0000 Andy Bierman writes: >I don't know how to implement infinite length identifiers. Do you? Read in the identifier, malloc sufficient space for it, add it to your dictionary. >How is it that memory resources of no concern in this case, >but they are super-critical when it comes to making sure >the list keys are first? It's just memory. Deal with it. Assuming you are comparing this to buffering an entire netconf database, the difference is that the length of an element name is likely to be small but the size of a database is known to be large. I have customers with 100MB configuration files, and don't want to buffer this amount of data. If someone goes to me with a module that has a 100MB identifier, I can refuse to consider their module. >We cannot have the standard say that an implementation >is conforming if it support 1 byte identifiers. >That's what you want by removing the rule entirely. Nonsense. My comment was we should have unlimited identifiers and that tools should support this. People who write modules with long identifiers are self regulating, in that people will ignore them and/or call them names. Imagine finding a C library where every variable has an insanely long name. You'll assume the author is an idiot and move on. This is regardless of the ability of your compiler to compile that function, but from a desire not to have code that looks like: if (my_really_long_function_name_that_is_silly( my_really_long_enum_name_that_is_silly, my_other_really_long_enum_name_that_is_silly) == my_really_long_error_code_name_that_is_silly) { ... } No one will adopt such code, so the use of long identifiers is self regulating. >The reason is to protect the YANG writers! >They need to know if it is safe to use a particular >identifier value. The standard currently says >"You are safe if you use 63 chars or less." >That is far from a CLR. It is critical to interoperability >and deployment. If the length has no limit, writers are also protected. >> 63 characters is pretty trivial as far as memory footprint. >times 10,000 objects it is not trivial... Why would you have 10,000 copies of a string? Put it in a dictionary and refer to that one entry. Take a look at libxml2 for an example. They do this for namespaces as well, IIRC, so that namespace comparisons aren't strcmp() calls, but simple pointer equality tests. String ops are expensive; avoid them where possible. Thanks, Phil From andy@netconfcentral.com Mon Mar 30 07:29: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 2DCCB28C100 for ; Mon, 30 Mar 2009 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.131, 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 iUOvGZRdZl3A for ; Mon, 30 Mar 2009 07:29:30 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 8618928C0D9 for ; Mon, 30 Mar 2009 07:29:30 -0700 (PDT) Received: (qmail 15923 invoked from network); 30 Mar 2009 14:30:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 30 Mar 2009 14:30:28 -0000 X-YMail-OSG: qOhHdecVM1lIXdSiIL_hWSL2cb0zf9UZ2RMN25ePppv4rnry9Vn8FzZ8g2NJ2l1CskynSKLLK1SVeNXC4vLrkz1FvqsuH.nsIdlPW7KyhtsulRFz33i673AWaEKLxxuuOjtJRfHgtXn3RWUGzRbpTmG5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D0D782.3030803@netconfcentral.com> Date: Mon, 30 Mar 2009 07:30:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <200903301254.n2UCsdQu086882@idle.juniper.net> <49D0D229.8070405@netconfcentral.com> <1238422466.6561.74.camel@missotis> In-Reply-To: <1238422466.6561.74.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:29:31 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 30. 03. 2009 v 07:07 -0700: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Saying that implementations MUST support infinite length >>>> identifiers is a non-starter. >> I don't know how to implement infinite length identifiers. Do you? >> How is it that memory resources of no concern in this case, >> but they are super-critical when it comes to making sure >> the list keys are first? It's just memory. Deal with it. >> >> So every implementation is going to pick a limit, >> but every one will be different. Great standard. > > Not necessarily, the memory for the identifier strings can be allocated > dynamically without setting any arbitrary limit on their length. > Well, I need to use malloc(), which will fail if the requested amount is big enough. I don't have a magic malloc() function like you. But the standard allows this just fine. You can support any identifier length you want, >= 63. Since 64 length identifiers have been around for awhile in SMIv2, the YANG limit of 63 is actually lowering the implementation burden by 1 byte. Since nobody has a use case for identifiers over 64 chars right now, the only logical motivation one could have for removing this rule is if they wanted to support a limit lower than 63 in their implementation. Not good. I vote for leaving the text as-is, and not removing the 63 limit from YANG. Are you in favor of keeping or removing it? > Lada > Andy From andy@netconfcentral.com Mon Mar 30 07:31: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 44A613A6D2E for ; Mon, 30 Mar 2009 07:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.128, 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 aICTJYgXN5SF for ; Mon, 30 Mar 2009 07:31:29 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id A7AA83A6BE1 for ; Mon, 30 Mar 2009 07:31:29 -0700 (PDT) Received: (qmail 3656 invoked from network); 30 Mar 2009 14:32:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 30 Mar 2009 14:32:25 -0000 X-YMail-OSG: G7pit2YVM1lSM8kvWLmIvUj8Ek.OSgX349LGmlxsnlh9mNod.VtD2jWVE3xlgX0sEq_Yd_b4Me51jTcEHkqk1O5M2hDHh8Lm5m1gTzzuhMYuRPtI5fo6EDc3EGV9sEjJTYJtCS1qgtdtwxCwhQG.qIxy X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D0D7F8.7010405@netconfcentral.com> Date: Mon, 30 Mar 2009 07:32:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200903301419.n2UEJqi2087629@idle.juniper.net> In-Reply-To: <200903301419.n2UEJqi2087629@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:31:30 -0000 .... >> The reason is to protect the YANG writers! >> They need to know if it is safe to use a particular >> identifier value. The standard currently says >> "You are safe if you use 63 chars or less." >> That is far from a CLR. It is critical to interoperability >> and deployment. > > If the length has no limit, writers are also protected. > This is the critical reason the rule needs to stay in the draft. Please explain how writers are better protected by removing it. > Thanks, > Phil > > Andy From phil@juniper.net Mon Mar 30 07:58: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 EFFF53A6C43 for ; Mon, 30 Mar 2009 07:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7URlyiDClVk for ; Mon, 30 Mar 2009 07:58:44 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 040DD3A6C58 for ; Mon, 30 Mar 2009 07:58:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSdDeWvQoXtZi+m5LqjlGu4KQqbcVQ9mc@postini.com; Mon, 30 Mar 2009 07:59:42 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Mar 2009 07:58:04 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:58:04 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:58:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 07:58:03 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2UEw3M90223; Mon, 30 Mar 2009 07:58:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2UEosG8087950; Mon, 30 Mar 2009 14:50:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903301450.n2UEosG8087950@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D0D7F8.7010405@netconfcentral.com> Date: Mon, 30 Mar 2009 10:50:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Mar 2009 14:58:03.0862 (UTC) FILETIME=[ED4A1760:01C9B147] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 14:58:45 -0000 Andy Bierman writes: >> If the length has no limit, writers are also protected. >This is the critical reason the rule needs to stay in the draft. >Please explain how writers are better protected by removing it. If identifiers are not limited to a small number by a CLR, tools have to support any length. Your tools that support any length will support the same length as my tools that support any length. Writers need not worry that a module which compiles fine with one tool set will fail with another tool set. Thanks, Phil From phil@juniper.net Mon Mar 30 08:09:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BDC28C0F9 for ; Mon, 30 Mar 2009 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3sqAC8F7jYng for ; Mon, 30 Mar 2009 08:09:49 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 93B693A6D11 for ; Mon, 30 Mar 2009 08:09:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSdDg7188WGo39rrTGlxPniyj0Rhms4ju@postini.com; Mon, 30 Mar 2009 08:10:47 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Mar 2009 08:08:07 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 08:08:07 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 08:08:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 08:08:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2UF86M95701; Mon, 30 Mar 2009 08:08:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2UF0vVA088091; Mon, 30 Mar 2009 15:00:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903301500.n2UF0vVA088091@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D0D782.3030803@netconfcentral.com> Date: Mon, 30 Mar 2009 11:00:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Mar 2009 15:08:06.0888 (UTC) FILETIME=[54B88E80:01C9B149] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 15:09:50 -0000 Andy Bierman writes: >Well, I need to use malloc(), which will fail if >the requested amount is big enough. I don't >have a magic malloc() function like you. If is we limit the identifier size to the limit at which malloc will fail, would that be suitable? This limit is on the order of megas, right? What about 1m? Or 4m? Too large still? 64K? 16K? 1K? Is there something magic about 63? Does your non-magic malloc only return that amount? ;^) We also carry namespaces in our content; should we limit them to 63 characters? >Since nobody has a use case for identifiers over 64 chars >right now, the only logical motivation one could have for >removing this rule is if they wanted to support >a limit lower than 63 in their implementation. Not good. I don't think anyone has suggesting lowing the limit. We've been getting rid of CLRs by saying "why not allow this?", and this is one more spot where there's no real reason to keep an ancient SNMP restriction, dating from the dark ages when 63 bytes was huge. Thanks, Phil From andy@netconfcentral.com Mon Mar 30 08:13: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 AF36828C0FC for ; Mon, 30 Mar 2009 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.126, 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 RxqKWgyzbT0m for ; Mon, 30 Mar 2009 08:13:59 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 0EDBB28C0F9 for ; Mon, 30 Mar 2009 08:13:58 -0700 (PDT) Received: (qmail 46242 invoked from network); 30 Mar 2009 15:14:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 30 Mar 2009 15:14:56 -0000 X-YMail-OSG: tGXmtUIVM1naJCPPeMulEjCWeq_.2ScUbZExf.dxNpzXOczHBH84lrzmcwihc6YNNUUrFyXXvgcuPQuPuokalattZsHmjzpZRReeL20AMN2Qr3Wqvj9KUDAcdLJS8MtKaLQsEhbvRfJMqfscum946Vwp X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D0E1EF.8050308@netconfcentral.com> Date: Mon, 30 Mar 2009 08:14:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200903301450.n2UEosG8087950@idle.juniper.net> In-Reply-To: <200903301450.n2UEosG8087950@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 15:13:59 -0000 Phil Shafer wrote: > Andy Bierman writes: >>> If the length has no limit, writers are also protected. >> This is the critical reason the rule needs to stay in the draft. >> Please explain how writers are better protected by removing it. > > If identifiers are not limited to a small number by a CLR, tools > have to support any length. Your tools that support any length > will support the same length as my tools that support any length. > Writers need not worry that a module which compiles fine with one > tool set will fail with another tool set. > I strongly disagree with this argument. I do not believe any implementations of NETCONF will ever handle arbitrarily long identifiers. I will write a test case to see if yous will handle a '4 billion trillion byte string' :-) Nobody has provided a single use-case demonstrating why setting the bar set at 63 is too low. There is a huge difference between a mere encoding standard like XML which does not specify anything to do with the content, and one like NETCONF/YANG, which relies on common content handling capabilities for its value. YANG writers need to know where the bar is set. Infinite length identifiers in YANG are not possible, so every NETCONF/YANG implementation will pick some limit. That is fine, as long as the number is >= 63. I see no reason to change that semantics in the draft. > Thanks, > Phil > > Andy From balazs.lengyel@ericsson.com Mon Mar 30 08:53: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 F22683A69FD for ; Mon, 30 Mar 2009 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=0.157, 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 yhBlsmnyKz-9 for ; Mon, 30 Mar 2009 08:53:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 252A13A67D2 for ; Mon, 30 Mar 2009 08:53:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EAE6F22CF5 for ; Mon, 30 Mar 2009 17:53:07 +0200 (CEST) X-AuditID: c1b4fb3c-aff63bb000003f6e-ed-49d0dd203204 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4A09122B22 for ; Mon, 30 Mar 2009 16:54:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 16:54:20 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 16:54:20 +0200 Message-ID: <49D0DD1B.2090201@ericsson.com> Date: Mon, 30 Mar 2009 16:54:19 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group References: <49CECE25.5000603@netconfcentral.com> <20090329060827.GB26902@elstar.local> In-Reply-To: <20090329060827.GB26902@elstar.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 14:54:20.0565 (UTC) FILETIME=[6831AC50:01C9B147] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 15:53:51 -0000 Hello, IMHO the current text is OK. It tells you must support 63 (it is mandatory to support that). I think that is enough to guarantee interoperability. Mandating or assuming you can use unlimited long identifiers is risky. It will decrease the chances of interoperability, as in practice, some implementations may not support it. And yes, a warning from YANG tools for longer identifiers would be nice. Balazs From phil@juniper.net Mon Mar 30 08:55: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 C0F2F3A69FD for ; Mon, 30 Mar 2009 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp+Akt8W8Ogg for ; Mon, 30 Mar 2009 08:55:41 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id C27853A67D2 for ; Mon, 30 Mar 2009 08:55:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSdDrrz//8omDvZxniR+f3mCLifUNgtSt@postini.com; Mon, 30 Mar 2009 08:56:39 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Mar 2009 08:55:16 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 08:55:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 08:55:16 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 08:55:15 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2UFtFM17860; Mon, 30 Mar 2009 08:55:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2UFm6fO088577; Mon, 30 Mar 2009 15:48:07 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903301548.n2UFm6fO088577@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D0E1EF.8050308@netconfcentral.com> Date: Mon, 30 Mar 2009 11:48:06 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Mar 2009 15:55:15.0755 (UTC) FILETIME=[EADB67B0:01C9B14F] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 15:55:41 -0000 Andy Bierman writes: >I will write a test case to see if yous will >handle a '4 billion trillion byte string' :-) All implementations are limited by available memory, but we don't make max-elements mandatory for all lists. Will you write a test case for a billion trillion list members? C compilers are limited by memory, but there's no limit on the size of C files. Editors are limited by memory but there's not fixes limit on editor files. My inbox is limited by memory, but there's no limit (or rate limit) on incoming email. >Nobody has provided a single use-case demonstrating >why setting the bar set at 63 is too low. Try the other side: Why limit this? I know you have a scheme in your implementation for encoding your stuff in a database that tops out at something like 900 bytes, and I know that's why this issue is dear to you, but I don't see that as a convincing driver for a spec. 900/63 == 14, so does it follow that we limit depth of YANG modules to 14 levels? In any case, you and I have debated this issue enough. I'm going to step back and see what the rest of the WG says. Thanks, Phil From andy@netconfcentral.com Mon Mar 30 09:05:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C523A6898 for ; Mon, 30 Mar 2009 09:05:17 -0700 (PDT) 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 6br6GpocrfQc for ; Mon, 30 Mar 2009 09:05:16 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 8DFCB3A696D for ; Mon, 30 Mar 2009 09:05:16 -0700 (PDT) Received: (qmail 67381 invoked from network); 30 Mar 2009 16:06:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 30 Mar 2009 16:06:14 -0000 X-YMail-OSG: vWaRv30VM1niiZAHnifLsWT7kLIRbLWEv1WRr9dM_.jQdv6YtazyZ678dC494xz9F77a0ncX4TWcYIbQ70gKyfLl7RY8_Y3SvMfriBdvWzwfePlwFNp2h.MX1o5j35w6vp1r0ziZq5T5Oe9_PUqhM9Sr X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D0EDF4.4070300@netconfcentral.com> Date: Mon, 30 Mar 2009 09:06:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200903301548.n2UFm6fO088577@idle.juniper.net> In-Reply-To: <200903301548.n2UFm6fO088577@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Mar 2009 16:05:17 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I will write a test case to see if yous will >> handle a '4 billion trillion byte string' :-) > > All implementations are limited by available memory, but we don't > make max-elements mandatory for all lists. Will you write a test > case for a billion trillion list members? > This is different. We are defining a data modeling language. In NETCONF, the agent simply sends 'resource-denied' when it runs out of memory. If anything, the correct analogy here is min-elements, not max. > C compilers are limited by memory, but there's no limit on the size > of C files. Editors are limited by memory but there's not fixes > limit on editor files. My inbox is limited by memory, but there's > no limit (or rate limit) on incoming email. > >> Nobody has provided a single use-case demonstrating >> why setting the bar set at 63 is too low. > > Try the other side: Why limit this? > > I know you have a scheme in your implementation for encoding your > stuff in a database that tops out at something like 900 bytes, and > I know that's why this issue is dear to you, but I don't see that > as a convincing driver for a spec. 900/63 == 14, so does it follow > that we limit depth of YANG modules to 14 levels? > I am quite happy with 63 as the minimum everybody must support. This limit of 14 levels is only for the pre-loaded SQL database supporting the online netconf central WEB pages. It has nothing to do with the standard. > In any case, you and I have debated this issue enough. I'm going > to step back and see what the rest of the WG says. > > Thanks, > Phil > > Andy From kawamucho@mesh.ad.jp Mon Mar 30 19:21: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 3FD873A6930 for ; Mon, 30 Mar 2009 19:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.391 X-Spam-Level: ** X-Spam-Status: No, score=2.391 tagged_above=-999 required=5 tests=[AWL=1.881, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_55=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 mFwHhXHABoyD for ; Mon, 30 Mar 2009 19:21:02 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 2B32C3A6845 for ; Mon, 30 Mar 2009 19:21:01 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.162]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n2V2Lx5J029091 for ; Tue, 31 Mar 2009 11:21:59 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n2V2Lxp12204 for netmod@ietf.org; Tue, 31 Mar 2009 11:21:59 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id n2V2LwlE018020 for ; Tue, 31 Mar 2009 11:21:58 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n2V2LwX0026481 for ; Tue, 31 Mar 2009 11:21:58 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n2V2LwqZ007276 for ; Tue, 31 Mar 2009 11:21:58 +0900 Received: from [127.0.0.1] (bdonet119.sys.biglobe.nec.co.jp [10.19.136.119]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n2V2LwUD017661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Mar 2009 11:21:58 +0900 Message-ID: <49D17E45.7010907@mesh.ad.jp> Date: Tue, 31 Mar 2009 11:21:57 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: netmod@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Mar 2009 02:21:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Juergen, thanks for introducing the draft to the working group and also for the many helpful comments. Just a quick example of how multiple representations are painful. If there was some trouble on the network, a traceroute would be done to detect where the packet was being dropped. Your favorite operating system(Windows, BSD) will return an address like 2001:db8:1::10 and we operators will copy that address from the terminal and seach for it on whatever systems that we use to managage IP addresses, router configurations, SNMP data, etc. Depending on the flavors of those systems, a search (or grep) might return a no match just because it has 2001:db8:1:0:0:0:0:10. Think if network diagrams were written on Excel(which I see very often) and try seaching for an address there. - From what I've experienced, the "preferred way" noted in RFC4291 sec 2.2 item 1 is rarely used. BTW, I'm a network operator at an ISP/Data Center. Thanks Seiichi Kawamura NEC BIGLOBE, Ltd. ================================= Hi, I just saw this document: http://www.ietf.org/internet-drafts/draft-kawamura-ipv6-text-representation-00.txt While this document is not perfect and the suggestion to use inet_ntop() does not work since we know this function is not fully defined and different implementations produce different results, I believe the authors do have a point in spelling out that multiple different representations are operationally not really a feature. /js - -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFJ0X5FcrhTYfxyMkIRAsPWAJ0cFwxcf9uPtkE6IMlmrPnRlRXfHgCfXWbi bexQaKBSuBoPH66tnvcg4Ro= =1k+a -----END PGP SIGNATURE----- From j.schoenwaelder@jacobs-university.de Mon Mar 30 22:59:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDB03A688B for ; Mon, 30 Mar 2009 22:59:43 -0700 (PDT) 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.170, 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 mHNFSaf3bsxM for ; Mon, 30 Mar 2009 22:59:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 52F1D3A6CB8 for ; Mon, 30 Mar 2009 22:59:41 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E47AC000C; Tue, 31 Mar 2009 08:00:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W+MTq0goI+aD; Tue, 31 Mar 2009 08:00:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88E8AC0008; Tue, 31 Mar 2009 08:00:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B261CA46FFE; Tue, 31 Mar 2009 08:00:20 +0200 (CEST) Date: Tue, 31 Mar 2009 08:00:20 +0200 From: Juergen Schoenwaelder To: Seiichi Kawamura Message-ID: <20090331060020.GB13951@elstar.local> Mail-Followup-To: Seiichi Kawamura , "netmod@ietf.org" References: <49D17E45.7010907@mesh.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D17E45.7010907@mesh.ad.jp> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 05:59:43 -0000 On Tue, Mar 31, 2009 at 04:21:57AM +0200, Seiichi Kawamura wrote: [...] > - From what I've experienced, the "preferred way" noted in RFC4291 > sec 2.2 item 1 is rarely used. BTW, I'm a network operator at an > ISP/Data Center. So what is your suggestion? Note that the format produced by inet_ntop() implementations seems to differ slightly on some platforms: http://www.ietf.org/mail-archive/web/netmod/current/msg02047.html Note that the list is pretty incomplete yet and we felt is it not our task to define how inet_ntop() should behave. What do you plan to do with your document? Has it been discussed somewhere at the last IETF? If your plan is to write down how an interoperable compressed format is constructed and you plan to push this through one of the IPv6 WGs, I guess we would be happy to pick up the compressed format. But note that we like to wrap up our work soon and so this would have to move relatively fast. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.kessens@nsn.com Tue Mar 31 11:56: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 504A43A684F for ; Tue, 31 Mar 2009 11:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4uGdGIhOkhwe for ; Tue, 31 Mar 2009 11:56:58 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4180D3A6817 for ; Tue, 31 Mar 2009 11:56:58 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2VIvqYF004531 for ; Tue, 31 Mar 2009 21:57:53 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 21:57:46 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 21:57:46 +0300 Received: from localhost.localdomain ([10.241.58.214]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 21:57:44 +0300 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2) with ESMTP id n2VIvgau013474 for ; Tue, 31 Mar 2009 11:57:42 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.2/8.14.1/Submit) id n2VIvgOn013473 for netmod@ietf.org; Tue, 31 Mar 2009 11:57:42 -0700 Date: Tue, 31 Mar 2009 11:57:42 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20090331185741.GB12756@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: 31 Mar 2009 18:57:45.0651 (UTC) FILETIME=[93EAB030:01C9B232] X-Nokia-AV: Clean Subject: [netmod] Acceptance of YANG Usage Guidelines document as a working group document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Mar 2009 18:56:59 -0000 During our working group session last week, there was strong consensus to accept: http://tools.ietf.org/id/draft-bierman-netmod-yang-usage-00.txt as a working group deliverable to be published as an Informational RFC. The chairs discussed with the Area Directors and agreed on the text at the bottom of this mail to be added to the wg charter. Please let us know by Mon Apr 6 if you have objections. David Kessens & David Partain --- Apr 2009 Initial YANG Usage Guidelines document available as a working group document Sep 2009 Submit YANG Usage Guidelines to the IESG for publication as an Informational RFC. --- From j.schoenwaelder@jacobs-university.de Tue Mar 31 12:38: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 1E6283A68B0 for ; Tue, 31 Mar 2009 12:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, 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 axlc5iwXPlph for ; Tue, 31 Mar 2009 12:38:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B89E13A6817 for ; Tue, 31 Mar 2009 12:38:01 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F7B9C003A for ; Tue, 31 Mar 2009 21:39:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tYQsX5n5r8DO; Tue, 31 Mar 2009 21:38:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60F2EC0040; Tue, 31 Mar 2009 21:38:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 694CBA475D1; Tue, 31 Mar 2009 21:38:42 +0200 (CEST) Date: Tue, 31 Mar 2009 21:38:42 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090331193842.GA14501@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] revised domain-name typedef X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 19:38:03 -0000 Hi, we received valuable feedback on the domain-name typedef and the current definition is attached below. This is still being reviewed by the DNS directory but I think we are close in getting this right. typedef domain-name { type string { pattern '(([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?'; length "1..253"; } description "The domain-name type represents a DNS domain name. The name SHOULD be fully qualified whenever possible. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a syntax (modified in section 2.1 of RFC 1123). The pattern above is intended to allow for current practise in domain name use, and some possible future expansion. It is designed to hold various types of domain names, including names used for A or AAAA records (host names) and other records, such as SRV records. Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations in RFCs 1034 and 1123, and that systems that want to store host names in objects using the domain-name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. The description clause of objects using the domain-name type MUST describe how (and when) these names are resolved to IP addresses. Note that the resolution of a domain-name value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. The canonical format for domain-name values uses the US-ASCII encoding and case-insensitive characters are set to lowercase."; reference "RFC 1034: Domain Names - Concepts and Facilities RFC 1123: Requirements for Internet Hosts -- Application and Support RFC 3490: Internationalizing Domain Names in Applications (IDNA)"; } /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 Tue Mar 31 23:00: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 57BD03A67AA for ; Tue, 31 Mar 2009 23:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.091, 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 OgBm6CfK0nB5 for ; Tue, 31 Mar 2009 23:00:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7AD9F3A672F for ; Tue, 31 Mar 2009 23:00:31 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 67BF076C50C; Wed, 1 Apr 2009 08:01:29 +0200 (CEST) Date: Wed, 01 Apr 2009 08:01:28 +0200 (CEST) Message-Id: <20090401.080128.11777848.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49CECE25.5000603@netconfcentral.com> References: <49CECE25.5000603@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] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 06:00:32 -0000 Andy Bierman wrote: > Hi, > > There seems to be 3 options wrt/ identifier length > in the YANG language: > > > 1) 1 .. infinity (no rule at all) > 2) 1 .. N (MUST for every module: > "identifiers MUST be 1 to N chars long") > 3) 1 .. N (MUST only for standard modules: > current text: "tools MUST accept 1 to N chars") > > Which do you prefer and why? I think Phil had a good explanation why (3) leads to interoperability issues. The current text implies that if you want to write an interoperable module, you better use less than 63 characters. The question is why we want the standard to allow for non-interoperability? Regarding a limit as in (2), IMO this is pretty arbitrary. Why do we have a limit on this particular thing, but not on namespace uri length; not on the 'contact', 'description' clause data; not on the number of leafs in a container; not on the number of features; not on the nested levels in the hierarchy; not on anything else! What makes the identifier special? The one explanation we have seen is from Juergen, and that is that we want to support code generators that use the YANG identifiers as identifiers in code. While I agree with this idea, I think that such a code generator (like ours) will have to handle some special cases anyway, e.g. an identifier in C cannot have a '-' character in it, and identifiers longer than 63 characters will sure be a corner case. So, my order of preference would be (1), (2), (3). /martin From andy@netconfcentral.com Tue Mar 31 23:17:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839B13A6B53 for ; Tue, 31 Mar 2009 23:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.122, 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 SMaJF2fxBPf5 for ; Tue, 31 Mar 2009 23:17:49 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id CAE793A693D for ; Tue, 31 Mar 2009 23:17:49 -0700 (PDT) Received: (qmail 48394 invoked from network); 1 Apr 2009 06:18:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 06:18:49 -0000 X-YMail-OSG: Vt6CkPEVM1lJ50uHtv6iAjXa7Sd6IpG60CPLSigoqK28xpycZ9usixaUtrIPXCbffrqVs5zdlsdDv0ziiXnkrDuJ6A68xqrUF6rAgyQMU0yNPHgRWuhGqeoof9YF_3ZYNI7a_oSj29KHlwxqV4bD2gbOsuMbYSj7NpNYOZIDJZjOFIvyGfe42seGidWYgNVXmxN0R9bg9yRqvW.GA55A6JbPQPiQHqHzuJYU4oWkDdjZIRu_udJt7V7EALqSGj982kI826BZXugml9wAESBUFFptZ_7G5rnwZqVgfCUKz3QTe3DCvrfbAMv8vw0bsfnsq5wek6P0SNvE5g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D30747.9010609@netconfcentral.com> Date: Tue, 31 Mar 2009 23:18:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49CECE25.5000603@netconfcentral.com> <20090401.080128.11777848.mbj@tail-f.com> In-Reply-To: <20090401.080128.11777848.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] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 06:17:50 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> There seems to be 3 options wrt/ identifier length >> in the YANG language: >> >> >> 1) 1 .. infinity (no rule at all) >> 2) 1 .. N (MUST for every module: >> "identifiers MUST be 1 to N chars long") >> 3) 1 .. N (MUST only for standard modules: >> current text: "tools MUST accept 1 to N chars") >> >> Which do you prefer and why? > > I think Phil had a good explanation why (3) leads to interoperability > issues. The current text implies that if you want to write an > interoperable module, you better use less than 63 characters. The > question is why we want the standard to allow for > non-interoperability? > > Regarding a limit as in (2), IMO this is pretty arbitrary. Why do we > have a limit on this particular thing, but not on namespace uri > length; not on the 'contact', 'description' clause data; not on the > number of leafs in a container; not on the number of features; not on > the nested levels in the hierarchy; not on anything else! What makes > the identifier special? > > The one explanation we have seen is from Juergen, and that is that we > want to support code generators that use the YANG identifiers as > identifiers in code. While I agree with this idea, I think that such > a code generator (like ours) will have to handle some special cases > anyway, e.g. an identifier in C cannot have a '-' character in it, and > identifiers longer than 63 characters will sure be a corner case. > > So, my order of preference would be (1), (2), (3). I strongly object to (1), and prefer to leave the text as-is. 1) YANG writers MUST know the minimum safe length value that can be used on all YANG tools 2) no YANG/NETCONF implementation can possibly support infinite length identifiers, and letting implementors pick any arbitrary limit is not inter-operable 3) No use-case has ever been presented for why the length of 63 (or 64 established by SNMP 20 years ago) is causing any problems whatsoever that need to be solved. The limit of 63/64 is not arbitrary. It is time-proven to be necessary and sufficient for efficient tools interoperability 4) The current rule does not prevent anyone from supporting infinite length identifiers if they want. The IETF does not need them. > > > /martin > > Andy From mbj@tail-f.com Tue Mar 31 23:28: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 402AA3A6B53 for ; Tue, 31 Mar 2009 23:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV9sO2QAMN-j for ; Tue, 31 Mar 2009 23:28:39 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 70D6D3A6ACF for ; Tue, 31 Mar 2009 23:28:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0927876C5B9; Wed, 1 Apr 2009 08:29:39 +0200 (CEST) Date: Wed, 01 Apr 2009 08:29:33 +0200 (CEST) Message-Id: <20090401.082933.83225477.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D30747.9010609@netconfcentral.com> References: <49CECE25.5000603@netconfcentral.com> <20090401.080128.11777848.mbj@tail-f.com> <49D30747.9010609@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] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 06:28:40 -0000 Andy Bierman wrote: > 1) YANG writers MUST know the minimum safe length value that > can be used on all YANG tools > 2) no YANG/NETCONF implementation can possibly support infinite > length identifiers, and letting implementors pick any arbitrary limit > is not inter-operable Why don't you think the same rule is important for the other constructs I mentioned? What makes the identifier special? /martin From andy@netconfcentral.com Tue Mar 31 23:43:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95AD28C13E for ; Tue, 31 Mar 2009 23:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 J+-36646UdeZ for ; Tue, 31 Mar 2009 23:43:49 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 25E8C3A6BF9 for ; Tue, 31 Mar 2009 23:43:07 -0700 (PDT) Received: from [68.142.194.244] by n14.bullet.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 06:44:07 -0000 Received: from [68.142.201.246] by t2.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 06:44:07 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 06:44:07 -0000 X-Yahoo-Newman-Id: 150323.21359.bm@omp407.mail.mud.yahoo.com Received: (qmail 55335 invoked from network); 1 Apr 2009 06:44:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 06:44:06 -0000 X-YMail-OSG: knzgwAoVM1kSf8881vz9ghke1B3jF514qLGbP5sKctVc04jQUW4iCABEj3VoftzfD25hhiuTLpUglHWxahpM3UiYYBtxqIvZnC4L76uFAnNhVa0XpZeti58fL3VUzzsREt35m0wMAygZy05StuUJIFyiEq53lE.BCS4YLIpUySJQvsLBTgrzqacRxR8TYoSCk.6egspdSB3stwP5XHDPFkpcPwN4GdZXoie9VpaG3bm87jK9MBooW0WXm6L3QYue.EJ.aKRAQjM07IOO X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D30D34.7040709@netconfcentral.com> Date: Tue, 31 Mar 2009 23:44:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49CECE25.5000603@netconfcentral.com> <20090401.080128.11777848.mbj@tail-f.com> <49D30747.9010609@netconfcentral.com> In-Reply-To: <49D30747.9010609@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 06:43:50 -0000 >> Regarding a limit as in (2), IMO this is pretty arbitrary. Why do we >> have a limit on this particular thing, but not on namespace uri >> length; not on the 'contact', 'description' clause data; not on the >> number of leafs in a container; not on the number of features; not on >> the nested levels in the hierarchy; not on anything else! What makes >> the identifier special? The difference is between data stored in the agent and data that is not. Good catch on the namespace-URI. We need a similar rule for that (for the agent) Implementations MUST support namespace URIs at least 1023 characters in length. The other clauses are not stored in the agent so they do not matter. It is simply not inter-operable to let YANG compilers accept YANG identifiers based on whether malloc() worked or not for that particular instance. YANG writers need to know that any agent that cannot handle 63 character names is broken. >> >> The one explanation we have seen is from Juergen, and that is that we >> want to support code generators that use the YANG identifiers as >> identifiers in code. While I agree with this idea, I think that such >> a code generator (like ours) will have to handle some special cases >> anyway, e.g. an identifier in C cannot have a '-' character in it, and >> identifiers longer than 63 characters will sure be a corner case. This is not the point. Your mangled names are irrelevant. What matters is that all tools accept 63 char names, and any IETF YANG module can have identifiers up to that limit. >> >> So, my order of preference would be (1), (2), (3). > > > I strongly object to (1), and prefer to leave the text as-is. > > 1) YANG writers MUST know the minimum safe length value that > can be used on all YANG tools > 2) no YANG/NETCONF implementation can possibly support infinite > length identifiers, and letting implementors pick any arbitrary limit > is not inter-operable > 3) No use-case has ever been presented for why the length of 63 > (or 64 established by SNMP 20 years ago) is causing any problems > whatsoever that need to be solved. The limit of 63/64 is not > arbitrary. It is time-proven to be necessary and sufficient > for efficient tools interoperability > 4) The current rule does not prevent anyone from supporting infinite > length identifiers if they want. The IETF does not need them. > >> >> >> /martin >> >> > > Andy Andy