From david.partain@ericsson.com Fri Oct 2 01:35: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 7222B3A68BB; Fri, 2 Oct 2009 01:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=0.811, 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 CfkZsIyilLfb; Fri, 2 Oct 2009 01:35:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C8C273A67F2; Fri, 2 Oct 2009 01:35:39 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-7e-4ac5bbb16d25 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1F.2C.15624.1BBB5CA4; Fri, 2 Oct 2009 10:37:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 From: David Partain Organization: Ericsson AB To: "netconf@ietf.org" , NETMOD Working Group Date: Fri, 2 Oct 2009 10:36:19 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910021036.19330.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Oct 2009 08:36:20.0063 (UTC) FILETIME=[6A6536F0:01CA433B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Information from chair phone call on 24 September X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2009 08:35:41 -0000 Hi, This mail summarizes the conversation that the 4 co-chairs of NETCONF/NETMOD had with interested parties on default issue. This mail is NOT intended to re-open the question about default handling but to confirm that what we believe is a reasonable way forward is a decision that the working groups can live with. Silence will be considered consent! 1. There were a number of comments during the call that indicated that we need text that says that defaults are taken into consideration in validation. 2. The defaults question: No fundamental changes to the model are needed. That is, a server MAY choose not to send back values that are the default as defined in the YANG model. Instead, we are going to try to address some things that will tighten up potential inconsistencies (to "SHOULD level", not "MUST level") in dealing with defaults. There are cases where you don't necessarily know what a non-answer about an object with a default clause means. In particular, this means looking at upgrade rules, dealing with leafrefs and instance-identifiers. We should try to address the most common cases without trying to cover all possible corner cases. We need specific text, which Andy and Martin have been asked to address. Again, we are not re-opening this discussion by sending this mail: we wish to confirm that this is the right way forward. Some expressed a wish that there be a simple, short explanation of how defaults are handled in general so that one doesn't need to be privy of the entire YANG history to understand why things are the way they are. If you believe that this is useful, please offer text or, at a minimum, point out where you think text is missing. 3. The NETCONF WG to check consensus on whether 'with-defaults:' should be a SHOULD to implement. 4. In conjunction with the 'with-defaults:' work, the NETCONF WG can consider adding an XML attribute in a report-all response that tags default data as such to help NETCONF applications. (This discussion is already underway.) 5. Juergen agreed to help with some examples of XPath expressions refering to config / non-config / garbage data. (I think I got this right.) If others believe that other examples are needed, please suggest that on the mailing list. 6. We need to start thinking about (and writing about) the issue of config vs. statistics vs. operational data. This is something that needs to be given serious thought and energy. This will be done separately (and after) the YANG work is complete. 7. We will try to put text in the architecture draft as a sort of "placeholder" with respect to #5. Text has been suggested on the mailing list before and that should be put into the draft. Thanks. David From dromasca@avaya.com Fri Oct 2 03:31: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 23F0728B23E; Fri, 2 Oct 2009 03:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 khkkMGcGyhqb; Fri, 2 Oct 2009 03:31:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7316428C0D8; Fri, 2 Oct 2009 03:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="158655251" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Oct 2009 06:32:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" Subject: [netmod] FW: Need for WebEx at IETF 76 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2009 10:31:01 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=20 From mbj@tail-f.com Wed Oct 7 04:26: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 BE5CC28C1C7 for ; Wed, 7 Oct 2009 04:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YHNJuEusaJo for ; Wed, 7 Oct 2009 04:26:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EBF8B28C1BE for ; Wed, 7 Oct 2009 04:26:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F7F961601E; Wed, 7 Oct 2009 13:28:02 +0200 (CEST) Date: Wed, 07 Oct 2009 13:28:02 +0200 (CEST) Message-Id: <20091007.132802.125031137.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ABCF502.6010002@netconfcentral.com> References: <4ABCF502.6010002@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults wrap-up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Oct 2009 11:26:24 -0000 Andy Bierman wrote: > It seemed like we were close to consensus on the > module capability advertisement text. I would like > the text to say the server MUST advertise all the YANG > modules/revisions it is using. It should be obvious that > multiple revisions within a single server is most relevant > to typedefs, not objects. Most server developers will > choose to support only the latest revision of an accessible > object, rpc, or notification, not multiple revisions. > > Therefore, the only way multiple capabilities for > the same module will occur is through the import/include > by-revision ripple effect. When import by revision is used, it is clear to the client which version of the imported the server is using, so it doesn't have to be advertised. But if import by revision is NOT used, the only way for the client to learn which version of the imported module the server is using is if it is advertised. So I agree that in this case, even a typedef/grouping only module needs to be advertised. To make life simpler, I also agree that we should require a server to advertise all revisions of all modules it implements (MUST advertise). /martin From mbj@tail-f.com Wed Oct 7 07:14: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 A619C28C0F1 for ; Wed, 7 Oct 2009 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=-1.537, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=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 cvNkpEQSODvN for ; Wed, 7 Oct 2009 07:14: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 CA8223A6A94 for ; Wed, 7 Oct 2009 07:13:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6AB2561A2CF for ; Wed, 7 Oct 2009 16:15:25 +0200 (CEST) Date: Wed, 07 Oct 2009 16:15:25 +0200 (CEST) Message-Id: <20091007.161525.65111160.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] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 14:14:15 -0000 Hi, Section 7.17 on extensions allow an extension to have a core YANG statement as substatement: The substatements of an extension are defined by the extension, using some mechanism outside the scope of this specification. Syntactically, the substatements MUST be core YANG statements, or also defined using "extension" statements. Core YANG statements in extensions MUST follow the syntactical rules in Section 12. But the ABNF grammar does not allow this: unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statement "}") For example, the following legal YANG is not allowed by the rule above: foo:action my-action { input { list { ... } } } I suggest we fix this by doing: unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statements "}") unknown-statement2 = [prefix ":"] identifier [sep string] optsep (";" / "{" *unknown-statement2 "}") /martin From andy@netconfcentral.com Wed Oct 7 09:06: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 6B2203A69E0 for ; Wed, 7 Oct 2009 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_36=0.6, UNPARSEABLE_RELAY=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 GHQjydeL6L-W for ; Wed, 7 Oct 2009 09:06:57 -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 B3ECC3A69DB for ; Wed, 7 Oct 2009 09:06:57 -0700 (PDT) Received: (qmail 22224 invoked from network); 7 Oct 2009 16:08:34 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 07 Oct 2009 09:08:34 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 1sd6kvQVM1nngKV.vaRRE7faeSmxEasrbc8Z_GW7L0.UhhXrJf919JFs.MdvQ6usfK2Dlw4n_71comlUsFFpWOusknLCp7gO8XUu9F05iZO.LY3HzApzevwMvl4MT46reW2GpUsau1Sz4pCz5xK2v5rj8VLftFOmqXMPtJM4ad8T57vdEoGKvz5HIFl6JKCr7wPkIJNGJlxZF9vbrIX5sqSGyzfXZncoB_Vb5B1cIovtMacnNXmb.ds8YCCKHpCL X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACCBCF4.5050308@netconfcentral.com> Date: Wed, 07 Oct 2009 09:08:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091007.161525.65111160.mbj@tail-f.com> In-Reply-To: <20091007.161525.65111160.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:06:58 -0000 Martin Bjorklund wrote: > Hi, > > Section 7.17 on extensions allow an extension to have a core YANG > statement as substatement: > > The substatements of an > extension are defined by the extension, using some mechanism outside > the scope of this specification. Syntactically, the substatements > MUST be core YANG statements, or also defined using "extension" > statements. Core YANG statements in extensions MUST follow the > syntactical rules in Section 12. > I strongly object to this usage of extensions. I do not think language extensions should be able to use the YANG language itself to define constructs outside the language. Is there some semantics to go along with the extension statement, or just pure syntax? Can I rewrite the leaf-stmt if I don't like it, and use that inside my extensions? Why not? Why can't I mix-and-match, or reinvent all the YANG statements within my extensions? Are you going to add a section to the draft containing all the rules for constructs outside the language? IMO, requiring the YANG compiler to look for valid YANG constructs inside extensions is a big change from the original requirements for parsing extensions -- the parser just has to skip extensions it doesn't support. What is the use-case for all this complexity? What is the standards-value of having such a complicated mechanism for defining vendor extensions to the language? Extensions must use a prefix, so if the YANG compiler encounters what could be a keyword without a prefix, then the local module prefix rule applies, right? Or is this yet another special case where prefix usage is defined by the esoteric context in which it is used? > But the ABNF grammar does not allow this: > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statement "}") > > > For example, the following legal YANG is not allowed by the rule > above: > > foo:action my-action { > input { > list { ... } > } > } > > > I suggest we fix this by doing: > > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statements "}") > > unknown-statement2 = [prefix ":"] identifier [sep string] optsep > (";" / "{" *unknown-statement2 "}") > > What standards problem does this solve? > > /martin Andy From andy@netconfcentral.com Wed Oct 7 09:21:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB49928C1A9 for ; Wed, 7 Oct 2009 09:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_40=-0.185, J_CHICKENPOX_36=0.6, UNPARSEABLE_RELAY=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 zUaZIRQ7bAyD for ; Wed, 7 Oct 2009 09:21:29 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 94FF43A68EA for ; Wed, 7 Oct 2009 09:21:29 -0700 (PDT) Received: from [68.142.194.243] by n17.bullet.mail.mud.yahoo.com with NNFMP; 07 Oct 2009 16:23:08 -0000 Received: from [68.142.201.69] by t1.bullet.mud.yahoo.com with NNFMP; 07 Oct 2009 16:23:08 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 07 Oct 2009 16:23:08 -0000 X-Yahoo-Newman-Id: 141204.45564.bm@omp421.mail.mud.yahoo.com Received: (qmail 34163 invoked from network); 7 Oct 2009 16:23:07 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 07 Oct 2009 09:23:07 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 9R2XYAsVM1mXxFnqP3DDDWXESoh4j.yR.Af6d3QfLIvqjfdzOFmDwETHqInlFOCKpVUwBUVClZ8bwHIfPwE9055.0yg0tweCGQwXNxm1fS_ojYDT7zfNXDG0xRNXfkaLWn0W9TTA8T1Ah.8FDoaAyS7UJP7vjOLPn9F9b48B.9tGQTjxAqG4ilrDWtALKoiH18UQEa7cCDraH69wqK8ysHisoC2pSkSErxMoTCAPUB27GRvMpucDd_fyuwdZNTeb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACCC05D.1030302@netconfcentral.com> Date: Wed, 07 Oct 2009 09:22:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091007.161525.65111160.mbj@tail-f.com> In-Reply-To: <20091007.161525.65111160.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:21:30 -0000 Martin Bjorklund wrote: > Hi, > > Section 7.17 on extensions allow an extension to have a core YANG > statement as substatement: > > The substatements of an > extension are defined by the extension, using some mechanism outside > the scope of this specification. Syntactically, the substatements > MUST be core YANG statements, or also defined using "extension" > statements. Core YANG statements in extensions MUST follow the > syntactical rules in Section 12. > > But the ABNF grammar does not allow this: > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statement "}") > > > For example, the following legal YANG is not allowed by the rule > above: > > foo:action my-action { > input { > list { ... } > } > } > > > I suggest we fix this by doing: > > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statements "}") > > unknown-statement2 = [prefix ":"] identifier [sep string] optsep > (";" / "{" *unknown-statement2 "}") > > This is not deterministic, and has no standards value whatsoever. The YANG syntax is not random. There is a top-level construction and every possible legal YANG statement has a place within this 'syntax tree'. In your example, the parser is not looking for the 'input' statement unless the current context is the rpc-stmt. Randomly inserting sub-statements into extensions is not supported by any programming language or any data modeling language -- because it is nonsense. > > /martin Andy From phil@juniper.net Wed Oct 7 10:59: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 4E1713A68A8 for ; Wed, 7 Oct 2009 10:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_43=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 tEUdDu40YONe for ; Wed, 7 Oct 2009 10:59:20 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 49D6F3A6872 for ; Wed, 7 Oct 2009 10:59:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSszXWYwfXgEwPlmH4vLXjFhCUw8o3xtr@postini.com; Wed, 07 Oct 2009 11:01: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.375.2; Wed, 7 Oct 2009 10:50:19 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 10:50:19 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 10:50:19 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 10:50:18 -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 n97HoIj24402; Wed, 7 Oct 2009 10:50:18 -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 n97HbaHf026838; Wed, 7 Oct 2009 17:37:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910071737.n97HbaHf026838@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ACCBCF4.5050308@netconfcentral.com> Date: Wed, 7 Oct 2009 13:37:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Oct 2009 17:50:18.0477 (UTC) FILETIME=[A21971D0:01CA4776] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:59:21 -0000 Andy Bierman writes: >I strongly object to this usage of extensions. >I do not think language extensions should be >able to use the YANG language itself to >define constructs outside the language. When the extension mechanism was being designed, we determined that many YANG statements were useful and simple enough to use inside an extension. If the parser does not understand the extension, then the contents of the extension can be easily skipped. There is no win in re-inventing an "acme:description" and "acme:reference" to go inside the acme:foo extension. >IMO, requiring the YANG compiler to look >for valid YANG constructs inside extensions is >a big change from the original requirements >for parsing extensions -- the parser just has to >skip extensions it doesn't support. The parser can skip the contents of extensions it doesn't support. It will never notice that there's a "reference" statement inside the acme:foo statement. >What is the use-case for all this complexity? The use case is reusing existing statements instead of making new ones. There is no complexity in the current solution. Thanks, Phil From andy@netconfcentral.com Wed Oct 7 12:45: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 A87B828C1D7 for ; Wed, 7 Oct 2009 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_43=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 lv4bQKoRTPSz for ; Wed, 7 Oct 2009 12:45:54 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id DA22828C1F1 for ; Wed, 7 Oct 2009 12:45:54 -0700 (PDT) Received: (qmail 69368 invoked from network); 7 Oct 2009 19:47:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 7 Oct 2009 19:47:33 -0000 X-YMail-OSG: yO0oaLcVM1miBh0.kScHinmvuqTbu0MKoTGEH0qwus2PExSbQvX8hWSzNiDvT0T2_ZTwrRHfuXysdrTlqTsntYIO.rD1qaTvEKwg2yStvjD168nR15C0T8sxSRMAhP.HK56EVz6JHv9036RAT7PXS.Oiuz9apOrlge5lJXnPaXQHGhYQ9O8tAOCPVNnroW7DLXIjNq7pZ07.E4HaWstuhMnWlOOWPMcDrDMTKSEWfUDOe3rgT8HPuG17rZWqjkZA6W7lLP120sJ2dG82hjEqojpw4K13jmhCvHcKmh42CNltVOeoi7XEzO9WGF7MNQh7Mw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACCF046.7060400@netconfcentral.com> Date: Wed, 07 Oct 2009 12:47:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910071737.n97HbaHf026838@idle.juniper.net> In-Reply-To: <200910071737.n97HbaHf026838@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 19:45:55 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I strongly object to this usage of extensions. >> I do not think language extensions should be >> able to use the YANG language itself to >> define constructs outside the language. > > When the extension mechanism was being designed, we determined that > many YANG statements were useful and simple enough to use inside > an extension. If the parser does not understand the extension, > then the contents of the extension can be easily skipped. There > is no win in re-inventing an "acme:description" and "acme:reference" > to go inside the acme:foo extension. > >> IMO, requiring the YANG compiler to look >> for valid YANG constructs inside extensions is >> a big change from the original requirements >> for parsing extensions -- the parser just has to >> skip extensions it doesn't support. > > The parser can skip the contents of extensions it doesn't support. > It will never notice that there's a "reference" statement inside > the acme:foo statement. > This is true if the contents of the extension use prefixed keywords. The current ABNF is correct. A prefix MUST be used for any keyword used outside the language. >> What is the use-case for all this complexity? > > The use case is reusing existing statements instead of making > new ones. There is no complexity in the current solution. > Except they are not reused at all. There is nothing at all in the spec that would lead to the conclusion that the string 'input' within an extension is somehow related to the input-stmt, which is a sub-statement of the rpc-stmt. There are no syntax rules to follow since the construction 'input-stmt' is not specified anywhere, as a sub-statement of the extension. > Thanks, > Phil > Andy From mbj@tail-f.com Thu Oct 8 00:22: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 89D893A68A0 for ; Thu, 8 Oct 2009 00:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+bA9qMbRA-m for ; Thu, 8 Oct 2009 00:22: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 68F7F3A680A for ; Thu, 8 Oct 2009 00:22:07 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E641876C6C0; Thu, 8 Oct 2009 09:23:47 +0200 (CEST) Date: Thu, 08 Oct 2009 09:23:47 +0200 (CEST) Message-Id: <20091008.092347.89363097.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ACCF046.7060400@netconfcentral.com> References: <200910071737.n97HbaHf026838@idle.juniper.net> <4ACCF046.7060400@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 07:22:08 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> I strongly object to this usage of extensions. > >> I do not think language extensions should be > >> able to use the YANG language itself to > >> define constructs outside the language. > > > > When the extension mechanism was being designed, we determined that > > many YANG statements were useful and simple enough to use inside > > an extension. If the parser does not understand the extension, > > then the contents of the extension can be easily skipped. There > > is no win in re-inventing an "acme:description" and "acme:reference" > > to go inside the acme:foo extension. > > > >> IMO, requiring the YANG compiler to look > >> for valid YANG constructs inside extensions is > >> a big change from the original requirements > >> for parsing extensions -- the parser just has to > >> skip extensions it doesn't support. > > > > The parser can skip the contents of extensions it doesn't support. > > It will never notice that there's a "reference" statement inside > > the acme:foo statement. > > > > This is true if the contents of the extension use > prefixed keywords. If the parser does not understand the extension, it can simply skip any substatements, prefixed or not. This is what the new ABNF rule says. > A prefix MUST be used for any keyword > used outside the language. Sure, we don't want to change that. The idea is that an extension should be able to reuse existing YANG statements. Here are two examples: Some people have talked about "inline rpc" or "action". The WG said "not now" and encouraged them to write a draft with a proposal. Since YANG is extensible, such a draft would specify a YANG extension: extension action { argument name; description "..."; } Now, an action will take some parameters, and return a result. A parameter can be a leaf, list, choice, container... And leafs need types. If such an extension cannot reuse existing statements, it would end up duplicating almost all core YANG statements. Another example is the "complex-type", defined in draft-linowski-netmod-yang-abstract. It should be defined as an extension: extension complex-type { argument name; ... } But in a complex-type, you need leafs, lists, choices, ... and again, if you cannot reuse core YANG statements, we would have a *third* copy of almost all core YANG statements in this draft. NOTE: we do not propose any additions to the extension statement -- which core YANG keywords that are allowed within an extension must be defined by some mechanism outside of YANG. An implementation that do not understand such an extension will still just skip it. > >> What is the use-case for all this complexity? > > > > The use case is reusing existing statements instead of making > > new ones. There is no complexity in the current solution. > > > > Except they are not reused at all. See above. If we don't allow reuse of core YANG statements, we will get more complexity b/c every new extension need to copy & paste core statements. /martin From j.schoenwaelder@jacobs-university.de Thu Oct 8 00:28: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 6A96F3A6A63 for ; Thu, 8 Oct 2009 00:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_50=0.001, 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 8mkwuGCIwnoR for ; Thu, 8 Oct 2009 00:28:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6EBFD3A6A42 for ; Thu, 8 Oct 2009 00:28:21 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9329FC0030; Thu, 8 Oct 2009 09:30:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VyMl6MnQqrG5; Thu, 8 Oct 2009 09:30:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3EFAC000F; Thu, 8 Oct 2009 09:30:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 178B7D148E8; Thu, 8 Oct 2009 09:30:01 +0200 (CEST) Date: Thu, 8 Oct 2009 09:30:01 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091008073001.GA10342@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20091007.161525.65111160.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091007.161525.65111160.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang grammar bug 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, 08 Oct 2009 07:28:22 -0000 On Wed, Oct 07, 2009 at 04:15:25PM +0200, Martin Bjorklund wrote: > I suggest we fix this by doing: > > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statements "}") > > unknown-statement2 = [prefix ":"] identifier [sep string] optsep > (";" / "{" *unknown-statement2 "}") I support an ABNF change allowing us to reuse the 'descrition' statement etc. in extensions. /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 Oct 8 00:52: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 3A81A28C22B for ; Thu, 8 Oct 2009 00:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_43=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 T1EBcDZuvGUK for ; Thu, 8 Oct 2009 00:52:20 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 5A8E228C229 for ; Thu, 8 Oct 2009 00:52:20 -0700 (PDT) Received: (qmail 66597 invoked from network); 8 Oct 2009 07:53:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 8 Oct 2009 07:53:59 -0000 X-YMail-OSG: wBhY4zYVM1n7bALxiazF1IYGoxTYJxwYNK3CIXcvyuFdOWaxy1YFI3pj2motIAs4tjwTSUd.IlXAwDP9AJowuP1Sj_fcQT5bszUYT24AFo5HMavdLE0SeD5lCGdTfaPlxHjXuZl0DHitAI4snVH02RZJCggzJOEMKB_YiwtXXY5MbE.q41mvW4w8WvDStJjrrzdDgVUYTyZY5y2H7ujPpzeIkRnxlV8Wwk6cig_SBFvd8MltSH.ce77fvfaK0x0w8gtleCxHobdERhXQk3kpP._s7Fzz81uDtPrVYh_f9qPmmuDoRPMAHs6UGIHCnB3S_4_MO.CyVNDbFWILaRDGBU9TwFsEm9hqJfpJXf0TO5mQMIg_.IoylMjDYjfl2w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACD9A87.9080106@netconfcentral.com> Date: Thu, 08 Oct 2009 00:53:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200910071737.n97HbaHf026838@idle.juniper.net> <4ACCF046.7060400@netconfcentral.com> <20091008.092347.89363097.mbj@tail-f.com> In-Reply-To: <20091008.092347.89363097.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 07:52:21 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> I strongly object to this usage of extensions. >>>> I do not think language extensions should be >>>> able to use the YANG language itself to >>>> define constructs outside the language. >>> When the extension mechanism was being designed, we determined that >>> many YANG statements were useful and simple enough to use inside >>> an extension. If the parser does not understand the extension, >>> then the contents of the extension can be easily skipped. There >>> is no win in re-inventing an "acme:description" and "acme:reference" >>> to go inside the acme:foo extension. >>> >>>> IMO, requiring the YANG compiler to look >>>> for valid YANG constructs inside extensions is >>>> a big change from the original requirements >>>> for parsing extensions -- the parser just has to >>>> skip extensions it doesn't support. >>> The parser can skip the contents of extensions it doesn't support. >>> It will never notice that there's a "reference" statement inside >>> the acme:foo statement. >>> >> This is true if the contents of the extension use >> prefixed keywords. > > If the parser does not understand the extension, it can simply skip > any substatements, prefixed or not. This is what the new ABNF rule > says. > >> A prefix MUST be used for any keyword >> used outside the language. > > Sure, we don't want to change that. The idea is that an extension > should be able to reuse existing YANG statements. Here are two > examples: > > Some people have talked about "inline rpc" or "action". The WG said > "not now" and encouraged them to write a draft with a proposal. Since > YANG is extensible, such a draft would specify a YANG extension: > > extension action { > argument name; > description "..."; > } > > Now, an action will take some parameters, and return a result. A > parameter can be a leaf, list, choice, container... And leafs need > types. If such an extension cannot reuse existing statements, it > would end up duplicating almost all core YANG statements. > > Another example is the "complex-type", defined in > draft-linowski-netmod-yang-abstract. It should be defined as an > extension: > > extension complex-type { > argument name; > ... > } > > But in a complex-type, you need leafs, lists, choices, ... and again, > if you cannot reuse core YANG statements, we would have a *third* copy > of almost all core YANG statements in this draft. > The YANG statements do not exist in some buffet-style random mix-and-match mode. They are specific constructions at specific points in a regular grammar. > NOTE: we do not propose any additions to the extension statement -- > which core YANG keywords that are allowed within an extension must be > defined by some mechanism outside of YANG. An implementation that do > not understand such an extension will still just skip it. > >>>> What is the use-case for all this complexity? >>> The use case is reusing existing statements instead of making >>> new ones. There is no complexity in the current solution. >>> >> Except they are not reused at all. > > See above. If we don't allow reuse of core YANG statements, we will > get more complexity b/c every new extension need to copy & paste core > statements. > > I don't want vendor extensions to the language. IMO, it is not helpful to readers of YANG data models if the YANG statements are used in uncontrolled, undocumented, non-standard ways. This allows every vendor to create their own version of the YANG language, and that harms interoperability. By using a prefix, it is clear that the vendor extension is not part of YANG. > /martin > Andy From andy@netconfcentral.com Thu Oct 8 11:14: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 A6CA83A692D for ; Thu, 8 Oct 2009 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 vEBXVH3bzwmT for ; Thu, 8 Oct 2009 11:14:48 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id D04E13A6831 for ; Thu, 8 Oct 2009 11:14:48 -0700 (PDT) Received: (qmail 15457 invoked from network); 8 Oct 2009 18:16:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 8 Oct 2009 18:16:29 -0000 X-YMail-OSG: _w9nTkwVM1n6uzJg5pJzfEuhTJJhI0qnLjuGp5V8hHyUoI7zeqhZSMUaklGHr8Nf3Ypuh3obL7pmcG4Y7JD1W.NgqcZc6G3Vel3fmQNfYkkLwN_8fwjUpL5hlFss6AXNVsxVdXdcMn9b7lIX_1aerMSnpHRat0VXGDsDZZXEmM7vfE92hbEc_OlNsAX5f2p3LyjW9BjcUNnSsQGup6kfPC2iVgdg4f24DX3lDs8UVEYBP65kXgJhkqnv4ltwz5QKi6F2bY.c1tb9UGbtxegh36GQpGRxC02DQtlKTvt4PNyeYSdcpqnWsp1beoMUjjCz X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACE2C6C.2010106@netconfcentral.com> Date: Thu, 08 Oct 2009 11:16:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <20091007.161525.65111160.mbj@tail-f.com> <20091008073001.GA10342@elstar.local> In-Reply-To: <20091008073001.GA10342@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 18:14:49 -0000 Juergen Schoenwaelder wrote: > On Wed, Oct 07, 2009 at 04:15:25PM +0200, Martin Bjorklund wrote: > >> I suggest we fix this by doing: >> >> >> unknown-statement = prefix ":" identifier [sep string] optsep >> (";" / "{" *unknown-statements "}") >> >> unknown-statement2 = [prefix ":"] identifier [sep string] optsep >> (";" / "{" *unknown-statement2 "}") > > I support an ABNF change allowing us to reuse the 'descrition' > statement etc. in extensions. > Sec. 6.3.1 clearly specifies that all statements which are not part of the production 'module-stmt' are language extensions and they MUST have prefixes on all the keywords. I think there is also text in the draft that says every unknown keyword needs a corresponding extension-stmt, or an error will occur. unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statement "}") stmtend = ";" / "{" *unknown-statement "}" These 'unknown-statement' syntax constructions, which are not defined within YANG, have no semantic coupling to the YANG syntax. There is no standards value in letting every vendor define their own dialect of YANG, picking any combination of sub-statements they want, redefining whatever they want, etc. The NETMOD WG decided NOT to use an 'action' or 'method' construct instead of an 'rpc'. If a vendor wants that, they can redefine the 'input-stmt' using some extensions. Too bad if it takes 1 data model writer some time. Use rpc-stmt if you want to use the YANG standard. Does an input-stmt for an 'action' have the exact same semantics as it does for rpc-stmt? If so, what is the point of having 'action'? If not, then it only serves to confuse YANG readers who think they know what input-stmt means. > /js > Andy From mbj@tail-f.com Thu Oct 8 12:18: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 105C63A683A for ; Thu, 8 Oct 2009 12:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frzWDf9JIBV1 for ; Thu, 8 Oct 2009 12:18:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6D25B3A696C for ; Thu, 8 Oct 2009 12:18:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 506DE61A30D; Thu, 8 Oct 2009 21:20:21 +0200 (CEST) Date: Thu, 08 Oct 2009 21:20:21 +0200 (CEST) Message-Id: <20091008.212021.134039334.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ACE2C6C.2010106@netconfcentral.com> References: <20091007.161525.65111160.mbj@tail-f.com> <20091008073001.GA10342@elstar.local> <4ACE2C6C.2010106@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:18:42 -0000 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Wed, Oct 07, 2009 at 04:15:25PM +0200, Martin Bjorklund wrote: > > > >> I suggest we fix this by doing: > >> > >> > >> unknown-statement = prefix ":" identifier [sep string] optsep > >> (";" / "{" *unknown-statements "}") > >> > >> unknown-statement2 = [prefix ":"] identifier [sep string] optsep > >> (";" / "{" *unknown-statement2 "}") > > > > I support an ABNF change allowing us to reuse the 'descrition' > > statement etc. in extensions. > > > > Sec. 6.3.1 clearly specifies that all statements which are not > part of the production 'module-stmt' are language extensions > and they MUST have prefixes on all the keywords. Again, no-one wants to change that. > I think there is also text in the draft that says every unknown > keyword needs a corresponding extension-stmt, or an error will occur. Again, no-one wants to change that. > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statement "}") > > > stmtend = ";" / "{" *unknown-statement "}" > > > These 'unknown-statement' syntax constructions, > which are not defined within YANG, have no semantic > coupling to the YANG syntax. > > There is no standards value in letting every vendor define their own > dialect of YANG, picking any combination of sub-statements > they want, redefining whatever they want, etc. This is a straw man. We simply want to keep the possibility to reuse existing statement in standard or vendor-specific extensions. > The NETMOD WG decided NOT to use an 'action' or 'method' construct > instead of an 'rpc'. If a vendor wants that, they can redefine > the 'input-stmt' using some extensions. Too bad if it takes 1 data > model writer some time. You miss the point. If this WG or someone else wants to define some new YANG construct, it can be done without updating YANG itself, by using extensions. By allowing those extensions access to the core statements, we can keep the overall complexity down. 'action' and 'complex-type' were just two examples that have been discussed within this WG. /martin From andy@netconfcentral.com Thu Oct 8 12:50: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 B15863A689B for ; Thu, 8 Oct 2009 12:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 14VB8vO6gIt5 for ; Thu, 8 Oct 2009 12:50:06 -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 D29103A68FA for ; Thu, 8 Oct 2009 12:50:06 -0700 (PDT) Received: (qmail 16885 invoked from network); 8 Oct 2009 19:51:48 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 08 Oct 2009 12:51:47 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Z4a8S6EVM1nxLt6nYzyKxtxnE7UGy7E.pq9KLUrx3qTFe9P04zelQiBXG0fMbNYYgB8AQIspM78acbVn5pSvlNDTt.pz69fkP9M7X0fqKkVXbhQvTnMkhS5f_n1zDEmiSxAWYGyCsCuoMUel5h8dxeVJ0.LmoSPoVW3IvWaJuOULFw.NgRo161.2G66HWMoUEb0bDsBCEAPJ_hF9NnYScgGnle5sPGZVUty5fGVtIZVVZaPHRYbQpS1ZOnIubZ1l1gvol.zI9haMQhsKW1iG9ktqQrbiQGXjOCl5_4XO7scwVWFWxC2tsL41KmTpMg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACE4249.40907@netconfcentral.com> Date: Thu, 08 Oct 2009 12:49:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091007.161525.65111160.mbj@tail-f.com> <20091008073001.GA10342@elstar.local> <4ACE2C6C.2010106@netconfcentral.com> <20091008.212021.134039334.mbj@tail-f.com> In-Reply-To: <20091008.212021.134039334.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:50:07 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Wed, Oct 07, 2009 at 04:15:25PM +0200, Martin Bjorklund wrote: >>> >>>> I suggest we fix this by doing: >>>> >>>> >>>> unknown-statement = prefix ":" identifier [sep string] optsep >>>> (";" / "{" *unknown-statements "}") >>>> >>>> unknown-statement2 = [prefix ":"] identifier [sep string] optsep >>>> (";" / "{" *unknown-statement2 "}") >>> I support an ABNF change allowing us to reuse the 'descrition' >>> statement etc. in extensions. >>> >> Sec. 6.3.1 clearly specifies that all statements which are not >> part of the production 'module-stmt' are language extensions >> and they MUST have prefixes on all the keywords. > > Again, no-one wants to change that. > >> I think there is also text in the draft that says every unknown >> keyword needs a corresponding extension-stmt, or an error will occur. > > Again, no-one wants to change that. > >> unknown-statement = prefix ":" identifier [sep string] optsep >> (";" / "{" *unknown-statement "}") >> >> >> stmtend = ";" / "{" *unknown-statement "}" >> >> >> These 'unknown-statement' syntax constructions, >> which are not defined within YANG, have no semantic >> coupling to the YANG syntax. >> >> There is no standards value in letting every vendor define their own >> dialect of YANG, picking any combination of sub-statements >> they want, redefining whatever they want, etc. > > This is a straw man. We simply want to keep the possibility to reuse > existing statement in standard or vendor-specific extensions. > I disagree that this is simple or good for the standard. I think it is much cleaner to use YANG keywords only within the module-stmt production. Every 'unknown-statement' is completely outside the YANG language and standard. >> The NETMOD WG decided NOT to use an 'action' or 'method' construct >> instead of an 'rpc'. If a vendor wants that, they can redefine >> the 'input-stmt' using some extensions. Too bad if it takes 1 data >> model writer some time. > > You miss the point. If this WG or someone else wants to define some > new YANG construct, it can be done without updating YANG itself, by > using extensions. By allowing those extensions access to the core > statements, we can keep the overall complexity down. 'action' and > 'complex-type' were just two examples that have been discussed within > this WG. > > I disagree that it is good for the standard to allow vendors to use bits and pieces of the YANG syntax in their extensions. The reason MIBs have standards value is precisely because every MIB reader has to know just 1 version of SMIv2, in order to read and understand any MIB module ever written. I think this aspect of standards usage and interoperability applies to YANG just as much as it does to SMIv2. > > /martin > Andy From mbj@tail-f.com Thu Oct 8 13:06: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 2AEB63A686B for ; Thu, 8 Oct 2009 13:06:25 -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 zfQ1om9i6aem for ; Thu, 8 Oct 2009 13:06:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5DD673A69EA for ; Thu, 8 Oct 2009 13:06:24 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AD84C616024; Thu, 8 Oct 2009 22:08:06 +0200 (CEST) Date: Thu, 08 Oct 2009 22:08:06 +0200 (CEST) Message-Id: <20091008.220806.140033554.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ACE4249.40907@netconfcentral.com> References: <4ACE2C6C.2010106@netconfcentral.com> <20091008.212021.134039334.mbj@tail-f.com> <4ACE4249.40907@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:06:25 -0000 Andy Bierman wrote: > I disagree that it is good for the standard to allow vendors > to use bits and pieces of the YANG syntax in their extensions. > The reason MIBs have standards value is precisely because > every MIB reader has to know just 1 version of SMIv2, > in order to read and understand any MIB module ever written. > > I think this aspect of standards usage and > interoperability applies to YANG just as much > as it does to SMIv2. But it still applies (in the same way it applies to SMIv2). If you don't understand an extension, skip it and all its contents. /martin From andy@netconfcentral.com Thu Oct 8 14:09: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 95A7D3A6833 for ; Thu, 8 Oct 2009 14:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 5be4M80bT9ao for ; Thu, 8 Oct 2009 14:09:35 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id BE0B43A672E for ; Thu, 8 Oct 2009 14:09:35 -0700 (PDT) Received: (qmail 27093 invoked from network); 8 Oct 2009 21:11:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 8 Oct 2009 21:11:16 -0000 X-YMail-OSG: ya_b7zkVM1l8wj3Y_Xd2VzmAXA5qj3tnUf6M9CH3NI4rfKFTpT.jIlE70ozG2dzTSDiceK5_U2k1n_4h0n6RCdDQVZMYiBGuiabW7ZRVQgSmqHztEAEh5BXyq3_EYTbf5EUyXZiBDAajLs9m_sZNi7w.HSGx3iCwvnCGpk0HO.L3Q.qFZs9Mmyaa2Mbo2xH4k3FM2Gq5vcrw4_vco7u3ymp9L.iR9ZQ8zPJ4BFwBz_8IMt3j9cyPkP5kX9Tyb2c_NZDqRRONDkUa5be44MYvutMUWXPbieb0uUbwRz1vF6SylmjChzwSscCd4hdnsiQQc4db8q.tN1gy5y7GxEnriDBAivT8kJTIt4PGHKaE6OGK9Wh6vmb.Ww38HB4JhRo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACE54E4.1030900@netconfcentral.com> Date: Thu, 08 Oct 2009 14:08:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4ACE2C6C.2010106@netconfcentral.com> <20091008.212021.134039334.mbj@tail-f.com> <4ACE4249.40907@netconfcentral.com> <20091008.220806.140033554.mbj@tail-f.com> In-Reply-To: <20091008.220806.140033554.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 21:09:36 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I disagree that it is good for the standard to allow vendors >> to use bits and pieces of the YANG syntax in their extensions. >> The reason MIBs have standards value is precisely because >> every MIB reader has to know just 1 version of SMIv2, >> in order to read and understand any MIB module ever written. >> >> I think this aspect of standards usage and >> interoperability applies to YANG just as much >> as it does to SMIv2. > > But it still applies (in the same way it applies to SMIv2). If you > don't understand an extension, skip it and all its contents. > IMO, this is not helpful for interoperability. By skipping your 'action' extension and just reading the standard YANG, a reader would not understand how to use the conceptual API and its inherent contract, represented by the standard YANG statements alone. Since there are no rules whatsoever for 'unknown-statement', the YANG reader is not going to have any idea from vendor to vendor, or platform to platform, of how to fully understand a YANG module, if some semi-random YANG statements have been adapted in various ways to apply to ad-hoc, undocumented, vendor-specific data modeling features. The YANG reader is the highest priority when it comes to design choices. IMO, expecting readers to learn a different dialect of YANG for potentially every NETCONF product they use is not a what most people expect from a standard data-modeling language. > > /martin > Andy From mbj@tail-f.com Thu Oct 8 14:19: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 7A3F43A681A for ; Thu, 8 Oct 2009 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc1eEJuZeCi9 for ; Thu, 8 Oct 2009 14:19: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 DEAAB3A68FF for ; Thu, 8 Oct 2009 14:18:55 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 70C5E76C151; Thu, 8 Oct 2009 23:20:37 +0200 (CEST) Date: Thu, 08 Oct 2009 23:20:35 +0200 (CEST) Message-Id: <20091008.232035.220544456.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ACE54E4.1030900@netconfcentral.com> References: <4ACE4249.40907@netconfcentral.com> <20091008.220806.140033554.mbj@tail-f.com> <4ACE54E4.1030900@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 21:19:15 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I disagree that it is good for the standard to allow vendors > >> to use bits and pieces of the YANG syntax in their extensions. > >> The reason MIBs have standards value is precisely because > >> every MIB reader has to know just 1 version of SMIv2, > >> in order to read and understand any MIB module ever written. > >> > >> I think this aspect of standards usage and > >> interoperability applies to YANG just as much > >> as it does to SMIv2. > > > > But it still applies (in the same way it applies to SMIv2). If you > > don't understand an extension, skip it and all its contents. > > > > IMO, this is not helpful for interoperability. > By skipping your 'action' extension and > just reading the standard YANG, a reader would > not understand how to use the conceptual API > and its inherent contract, represented by the > standard YANG statements alone. The reader skips the 'action' extension, and all its contents. Left is pure standard YANG which the reader understands. > Since there are no rules whatsoever for 'unknown-statement', There are rules for unknown-statement. Wait. I had a typo in my proposal :( This is what I wanted to say: unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statement2 "}") unknown-statement2 = [prefix ":"] identifier [sep string] optsep (";" / "{" *unknown-statement2 "}") So an unknown-statement can occur as before, but *inside* the unknown-statement, other unknowns, or core YANG statements can occur. I am very sorry if this typo is the source of the confusion. /martin From andy@netconfcentral.com Thu Oct 8 14:53: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 0334D3A69FB for ; Thu, 8 Oct 2009 14:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_05=-1.11, UNPARSEABLE_RELAY=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 D78RI245r4Ne for ; Thu, 8 Oct 2009 14:53:12 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id 361E33A6835 for ; Thu, 8 Oct 2009 14:53:12 -0700 (PDT) Received: from [216.252.122.218] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 08 Oct 2009 21:54:53 -0000 Received: from [68.142.194.243] by t3.bullet.sp1.yahoo.com with NNFMP; 08 Oct 2009 21:54:53 -0000 Received: from [68.142.201.70] by t1.bullet.mud.yahoo.com with NNFMP; 08 Oct 2009 21:54:53 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 08 Oct 2009 21:54:53 -0000 X-Yahoo-Newman-Id: 641372.54790.bm@omp422.mail.mud.yahoo.com Received: (qmail 10640 invoked from network); 8 Oct 2009 21:54:53 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 08 Oct 2009 14:54:53 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: KM_NJYUVM1m_mraJihkXok1Xg32aiJWnqSJpj9GOEGFHAZaZI0_u.lMkE6vnxD4baK3TRrz_jjWH_BNd1zUgDCO3hKynYabXG27TFirC643JP_eObHpebY1YLBIXo_yKQhw8C3neee4hU1ZDlLeSvYEYBYndnWiYcydet813jOeAhWGlb3PcRd9NVnzPApWjyrb249rg8wTRMvK3cu_B8MsMg5OyXVoUewtS82YecwS3XbKCK5fYyW_rOxDBz71OBFkjSGZffzdntUSA9pvywydsBMkJkBRezQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACE5F20.9040009@netconfcentral.com> Date: Thu, 08 Oct 2009 14:52:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4ACE4249.40907@netconfcentral.com> <20091008.220806.140033554.mbj@tail-f.com> <4ACE54E4.1030900@netconfcentral.com> <20091008.232035.220544456.mbj@tail-f.com> In-Reply-To: <20091008.232035.220544456.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 21:53:13 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> I disagree that it is good for the standard to allow vendors >>>> to use bits and pieces of the YANG syntax in their extensions. >>>> The reason MIBs have standards value is precisely because >>>> every MIB reader has to know just 1 version of SMIv2, >>>> in order to read and understand any MIB module ever written. >>>> >>>> I think this aspect of standards usage and >>>> interoperability applies to YANG just as much >>>> as it does to SMIv2. >>> But it still applies (in the same way it applies to SMIv2). If you >>> don't understand an extension, skip it and all its contents. >>> >> IMO, this is not helpful for interoperability. >> By skipping your 'action' extension and >> just reading the standard YANG, a reader would >> not understand how to use the conceptual API >> and its inherent contract, represented by the >> standard YANG statements alone. > > The reader skips the 'action' extension, and all its contents. Left > is pure standard YANG which the reader understands. > That is not good enough for a standard. The 'action' is used instead of an rpc-stmt. The standard YANG and NETCONF mechanisms are not being extended, they are being replaced. When extension-stmt was added to YANG, we were assured that it would not be mixed with YANG, and the WG agreed all unknown statements needed to use a prefix. >> Since there are no rules whatsoever for 'unknown-statement', > > There are rules for unknown-statement. > > Wait. I had a typo in my proposal :( > > This is what I wanted to say: > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statement2 "}") > > unknown-statement2 = [prefix ":"] identifier [sep string] optsep > (";" / "{" *unknown-statement2 "}") > > So an unknown-statement can occur as before, but *inside* the > unknown-statement, other unknowns, or core YANG statements can occur. > > I am very sorry if this typo is the source of the confusion. > > > /martin > Andy From phil@juniper.net Thu Oct 8 19:04: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 179B93A67EE for ; Thu, 8 Oct 2009 19:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 e0y0w11zMXZX for ; Thu, 8 Oct 2009 19:04:20 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 40D8F3A63EB for ; Thu, 8 Oct 2009 19:04:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSs6aiO8fngckdleO8ppD06tDOCAdDVAL@postini.com; Thu, 08 Oct 2009 19:06:04 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 8 Oct 2009 19:04: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); Thu, 8 Oct 2009 19:04:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 19:04:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 19:04:46 -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 n9924jj09958; Thu, 8 Oct 2009 19:04:45 -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 n991q08A051391; Fri, 9 Oct 2009 01:52:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910090152.n991q08A051391@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ACE5F20.9040009@netconfcentral.com> Date: Thu, 8 Oct 2009 21:52:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Oct 2009 02:04:46.0553 (UTC) FILETIME=[E0105490:01CA4884] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 02:04:21 -0000 Andy Bierman writes: >When extension-stmt was added to YANG, we were assured that >it would not be mixed with YANG, and the WG agreed >all unknown statements needed to use a prefix. The WG also agreed that reuse of existing statements inside extension statements made sense, since their use is common and natural. Forcing extensions to define extension-specific versions of standard YANG statements is not going to increase readability. Thanks, Phil From andy@netconfcentral.com Fri Oct 9 00:26: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 1575528C1C0 for ; Fri, 9 Oct 2009 00:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 qqjUa3Q+4n00 for ; Fri, 9 Oct 2009 00:26:57 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 28A543A68A5 for ; Fri, 9 Oct 2009 00:26:56 -0700 (PDT) Received: from [68.142.200.221] by n17.bullet.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 07:28:38 -0000 Received: from [68.142.201.70] by t9.bullet.mud.yahoo.com with NNFMP; 09 Oct 2009 07:28:38 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 07:28:38 -0000 X-Yahoo-Newman-Id: 862641.80698.bm@omp422.mail.mud.yahoo.com Received: (qmail 3061 invoked from network); 9 Oct 2009 07:28:38 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 09 Oct 2009 00:28:38 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: cIMyfhsVM1nsgh00TgILDwaLD8eqTwEo82suLQBnpSGu7SLmLy.IwbHBcrw6jLFeDiqy2p5Ai.wtx7w5_2Ils9Fjondi0qpFZsBIHcU5zog1nmxs8JEW6mqNA1E6K880ySQR_3OSJAnLwCUs1u3Qxj6PYTZifXzyC.2gMp1VaKF1uTBmgCL9U03YrIvox8JMtxVyFJaiN3IMq4ToOMPd8HFt361ywaWFSOV3ThOodd4e5.XlC0SdS9TdqablBuGW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACEE625.80909@netconfcentral.com> Date: Fri, 09 Oct 2009 00:28:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910090152.n991q08A051391@idle.juniper.net> In-Reply-To: <200910090152.n991q08A051391@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 07:26:58 -0000 Phil Shafer wrote: > Andy Bierman writes: >> When extension-stmt was added to YANG, we were assured that >> it would not be mixed with YANG, and the WG agreed >> all unknown statements needed to use a prefix. > > The WG also agreed that reuse of existing statements inside extension > statements made sense, since their use is common and natural. > Forcing extensions to define extension-specific versions of standard > YANG statements is not going to increase readability. > Wow, I've been looking at this standards thing all wrong. This extension thing is a great idea. I don't like the way YANG containers and leafs work, so I can define my own 'xcontainer', which allows mandatory-stmt, disallows presence-stmt; and my own 'xleaf', which allows default and mandatory together, default and mandatory only work the way I want them to work, and throws in a few sub-clauses that leaf should have had, but the WG decided against them. The YANG reader can just skip over the xcontainers and xleafs and just read the rest of the module. Any you can rewrite the parts of YANG you don't like, and so can everybody else. Seems like a great plan. > Thanks, > Phil > Andy From phil@juniper.net Fri Oct 9 00:57: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 9548828C167 for ; Fri, 9 Oct 2009 00:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 SlObvpAdFV2F for ; Fri, 9 Oct 2009 00:57:21 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id DA5CC28C0E0 for ; Fri, 9 Oct 2009 00:57:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSs7tRSDAV/mYy6IVhk0xdTovd9UnWpLj@postini.com; Fri, 09 Oct 2009 00:59:05 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 9 Oct 2009 00:54:35 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 00:54:35 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 00:54:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 00:54: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 n997sYj51660; Fri, 9 Oct 2009 00:54:34 -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 n997fpui053292; Fri, 9 Oct 2009 07:41:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910090741.n997fpui053292@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ACEE625.80909@netconfcentral.com> Date: Fri, 9 Oct 2009 03:41:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Oct 2009 07:54:34.0595 (UTC) FILETIME=[BDE96330:01CA48B5] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 07:57:21 -0000 Andy Bierman writes: >Wow, I've been looking at this standards thing all wrong. True. >This extension thing is a great idea. True. >I don't like the >way YANG containers and leafs work, so I can define my >own ... Yup, you can roll your own and go your own way, and if no one follows you, then your models will not be used. But if there's a real need for something new, someone clueful can publish a draft detailing this new thing, people will implement it, and models that use it will be created and used. The extension thing is a great idea because it allows the language to grow and change over time. Yes, we're sure to see lots of silly ideas that no one adopts, and we're sure to see odd statements that cover odd cases (imagine adding system-creatable as an extension) that can be ignored by clients and servers that don't care about these odd cases. In the end, the community will decide what works and what doesn't. Thanks, Phil From andy@netconfcentral.com Fri Oct 9 07:16: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 DEEE73A6806 for ; Fri, 9 Oct 2009 07:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 O0o3eMlrIZdh for ; Fri, 9 Oct 2009 07:16:33 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id EF1003A67A4 for ; Fri, 9 Oct 2009 07:16:32 -0700 (PDT) Received: (qmail 68191 invoked from network); 9 Oct 2009 14:18:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 9 Oct 2009 14:18:15 -0000 X-YMail-OSG: m9zHAVYVM1nWQ1_SgxiZ72SpOusfqqiNoHWt3wd7xC3gi41eTCSqf0WpN_GgPpwM9gg3Y6rMQ9kdQKT6QqM9LW06GnSVgEpvVXTrVaT_Iq_TgBjKevWCwO3t7k.X3sD9GvpDurH9eO9HinluKiijOe.4l_KGnDWul.OAMo6dQ8IJH2xQyzDitQjJg0J0iGkc9IeYWx0gX8lbzxRsLlxCKzIr3rf1NtLF71lhFQWsxfAXWnvtFwBlq_IWVAFK8uHDxOVJ0m.jGjFtr1mtN.GJ.mv8yaI.8kV9b39ui3IdUAlXQLf2T.FkSBjvrd.3ZDOR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACF45AF.3040407@netconfcentral.com> Date: Fri, 09 Oct 2009 07:16:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910090741.n997fpui053292@idle.juniper.net> In-Reply-To: <200910090741.n997fpui053292@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 14:16:34 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Wow, I've been looking at this standards thing all wrong. > > True. > >> This extension thing is a great idea. > > True. > >> I don't like the >> way YANG containers and leafs work, so I can define my >> own ... > > Yup, you can roll your own and go your own way, and if no one follows > you, then your models will not be used. > > But if there's a real need for something new, someone clueful can > publish a draft detailing this new thing, people will implement it, > and models that use it will be created and used. > > The extension thing is a great idea because it allows the language > to grow and change over time. > yeah -- and you don't even need time. Vendors can just start off right off the bat, creating their own DML with YANG, while still claiming that it is a 'standard'. > Yes, we're sure to see lots of silly ideas that no one adopts, and > we're sure to see odd statements that cover odd cases (imagine > adding system-creatable as an extension) that can be ignored by > clients and servers that don't care about these odd cases. > > In the end, the community will decide what works and what doesn't. > True, and since we are years away from any standard configuration data models, a vendor can claim conformance to NETCONF/YANG for many years without actually implementing anything from the standard. Awesome! People who want standards with 'plain old standards value' should stick to SNMP and SMIv2, but they probably can't appreciate all this 'vendor innovation' anyway. > Thanks, > Phil > Andy From phil@juniper.net Fri Oct 9 07:25: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 18F203A6A2E for ; Fri, 9 Oct 2009 07:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 6pkPkb+QFCOL for ; Fri, 9 Oct 2009 07:25:20 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 649AD3A6A45 for ; Fri, 9 Oct 2009 07:25:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSs9INbcQCnEk2FSMCmtWCRE1vgg6THxN@postini.com; Fri, 09 Oct 2009 07:27:05 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 9 Oct 2009 07:21:48 -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, 9 Oct 2009 07:21:49 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 07:21:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 07:21: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 n99ELlj27415; Fri, 9 Oct 2009 07:21:47 -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 n99E941j055291; Fri, 9 Oct 2009 14:09:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910091409.n99E941j055291@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ACF45AF.3040407@netconfcentral.com> Date: Fri, 9 Oct 2009 10:09:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Oct 2009 14:21:48.0008 (UTC) FILETIME=[D61ADE80:01CA48EB] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 14:25:21 -0000 Andy Bierman writes: >People who want standards with 'plain old standards value' should >stick to SNMP and SMIv2, but they probably can't appreciate >all this 'vendor innovation' anyway. I'm not sure you are appreciating the extension work in progress that Martin already mentioned. Innovation is not a dirty word. Thanks, Phil From andy@netconfcentral.com Fri Oct 9 08:02: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 C00FF3A68E9 for ; Fri, 9 Oct 2009 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_20=-0.74, UNPARSEABLE_RELAY=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 yfRv8nsHc2Vf for ; Fri, 9 Oct 2009 08:02:37 -0700 (PDT) Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id 0903C3A6886 for ; Fri, 9 Oct 2009 08:02:36 -0700 (PDT) Received: from [209.191.108.97] by n11.bullet.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 15:04:20 -0000 Received: from [68.142.201.252] by t4.bullet.mud.yahoo.com with NNFMP; 09 Oct 2009 15:04:20 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 15:04:20 -0000 X-Yahoo-Newman-Id: 188541.10138.bm@omp413.mail.mud.yahoo.com Received: (qmail 33812 invoked from network); 9 Oct 2009 15:04:19 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 09 Oct 2009 08:04:19 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: JvpTvFUVM1loN7RnS3C3f3_.n6gZrWKiYJWuYMDbsgf8JScS0hoCVj.poydA.JmGd4cLL2lgpjBvhgAqCTcrVjvGLxbflf4PhaWHwlabg1mvEXPFLmGxFyVvj3l57QoqtIfsT7A9lUuBoDvoBFhIllU9vKVLV57sN3POcll26EWt3NdWiftQzKWtdZN9Y.4o3zKU7O1JC1VT7U54x5CJiOY4wisngL.vlzonWNS84LYZR8eITjayEn84.5yQyoYO X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACF50F4.9040703@netconfcentral.com> Date: Fri, 09 Oct 2009 08:04:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910091409.n99E941j055291@idle.juniper.net> In-Reply-To: <200910091409.n99E941j055291@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 15:02:37 -0000 Phil Shafer wrote: > Andy Bierman writes: >> People who want standards with 'plain old standards value' should >> stick to SNMP and SMIv2, but they probably can't appreciate >> all this 'vendor innovation' anyway. > > I'm not sure you are appreciating the extension work in progress > that Martin already mentioned. Innovation is not a dirty word. > No, interoperability seems to be the dirty word. We started this sandbox because there could not possibly be any standard NETCONF content with every vendor using their own DML and their own interpretation of the conceptual NETCONF content layer. So the solution is to end up with N+1 DMLs and conceptual models to learn instead of N. The only advantage is that the standard content (ietf-*.yang) is forced to use 'IETF YANG'. The IETF is just another vendor with their own solution in this equation. Operators only need to learn the dialects of YANG for the vendors they use, of course, and only take a huge training and re-tooling hit if they want to change vendors. This seems rather similar to the situation we have now with proprietary CLI. > Thanks, > Phil > Andy From andy@netconfcentral.com Fri Oct 9 08:46: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 0965228C12E for ; Fri, 9 Oct 2009 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR0ppKFIN9sJ for ; Fri, 9 Oct 2009 08:46:55 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 3B8F428C11E for ; Fri, 9 Oct 2009 08:46:55 -0700 (PDT) Received: (qmail 90317 invoked from network); 9 Oct 2009 15:48:37 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 9 Oct 2009 15:48:37 -0000 X-YMail-OSG: .F..87gVM1kseM2HOsbgyqHpL_epjKx9_Utwg20XFeH9pxZB8PLsjts0QFnLwrjcChctDiHQg6KMAnftb6fY8YIJt4K36PaDvhN2wuwZqGJvVqoc8BWAccDmyrAYcb1OS7X6NdmbyYfqXBUsKW4peucRFYUKLKffXV0MG2GQA9eDeK2.PIa3dt6DUEiNDCQsLtB8dxdgMB6KDhmgCCQ_Wz1LP3ewmEqQlrPoySdE0lw12GXJudIYkroZguyFiKm.zUwxtmNIMpaocmPlTCd4sNYRF_8kQaHA.N.ZZh45lsazj16iswIiI_8.jHkvuept X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACF5B56.1010600@netconfcentral.com> Date: Fri, 09 Oct 2009 08:48:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910091409.n99E941j055291@idle.juniper.net> In-Reply-To: <200910091409.n99E941j055291@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 15:46:56 -0000 Phil Shafer wrote: > Andy Bierman writes: >> People who want standards with 'plain old standards value' should >> stick to SNMP and SMIv2, but they probably can't appreciate >> all this 'vendor innovation' anyway. > > I'm not sure you are appreciating the extension work in progress > that Martin already mentioned. Innovation is not a dirty word. > The 'action' extension could easily be a simple tag in the rpc-stmt instead of a hack replacement for an inline rpc-stmt: rpc foo { acme:action; acme:calling-point "../some/path"; input { ... } } But rpc-stmt is a top-level body-stmt, not a data-def-stmt. The WG decided not to support rpc-stmt within the data-def-stmt, so tail-f 'action' is just a way to ignore that WG decision. Seems like a really weak standard to me, but it's no better and no worse than the current 100% proprietary solution-space. As Martin pointed out, within an unknown-statement, YANG statements do not exist. There are just some identifiers without prefixes. There is only the generic YANG syntax: [prefix ':'] identifier [string] stmtend I want this text added to sec. 6.3.1: If the YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement, the entire unknown-statement MAY be ignored by the compiler. > Thanks, > Phil > Andy From randy_presuhn@mindspring.com Fri Oct 9 09:58:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679483A69CB for ; Fri, 9 Oct 2009 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjdvplMHPSTh for ; Fri, 9 Oct 2009 09:58:34 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 3F0943A697A for ; Fri, 9 Oct 2009 09:58:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lsJe0waKxh8NoLUXyApQ4x4IcEvQ1H8X0v94K3rN/5c7S085OC6PTapbvN4C6xFc; 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 [99.35.224.155] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MwIp9-000729-UL for netmod@ietf.org; Fri, 09 Oct 2009 13:00:12 -0400 Message-ID: <000c01ca4902$202d91a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910090741.n997fpui053292@idle.juniper.net> Date: Fri, 9 Oct 2009 10:01:18 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9e2659727a6dc2f95105a878019fa53ca350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.224.155 Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 16:58:39 -0000 Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: > Sent: Friday, October 09, 2009 12:41 AM > Subject: Re: [netmod] yang grammar bug ... > But if there's a real need for something new, someone clueful can > publish a draft detailing this new thing, people will implement it, > and models that use it will be created and used. > > The extension thing is a great idea because it allows the language > to grow and change over time. > > Yes, we're sure to see lots of silly ideas that no one adopts, and > we're sure to see odd statements that cover odd cases (imagine > adding system-creatable as an extension) that can be ignored by > clients and servers that don't care about these odd cases. > > In the end, the community will decide what works and what doesn't. An excellent argument for classifying this stuff as "Experimental" rather than standards track. :-( Randy From andy@netconfcentral.com Fri Oct 9 10:35: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 B2F8E28C18C for ; Fri, 9 Oct 2009 10:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 GvNC9CGYU0Zd for ; Fri, 9 Oct 2009 10:35:36 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id E4ADC28C183 for ; Fri, 9 Oct 2009 10:35:35 -0700 (PDT) Received: (qmail 89655 invoked from network); 9 Oct 2009 17:37:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 9 Oct 2009 17:37:17 -0000 X-YMail-OSG: jyGzrIQVM1k.yCnnbeWQCrFiCjAOCCbalOPAcGObdrx2jo8N43nxLpPp.tU.tSDY.ep06eAb0ZsY6c4odS3fmhGg27v8r.Bn2kfHXVh501iS.3HZUFxCSfxnICaXipggYgs6aDPiUsUOcyNHrolprPS61MDbzjJU_5kTjFw1wMWR.oqJwilFX3OH9r0DOYsuMYhdbU9FYycC4FJeSIrnSKBtvJgGa8aJ4n9BlUOp6aRCkDUQ_MeJ_o2mtWy_Hy_rz6kzySMbh.wb_oXNqdkkg0c65jz9BDYR3X5QRhn.ymZAHkSnH_cNeRm.P1gxoMPPvDU1_EEbHlyGhJ7W6E8czVfbzDyPxIgPANaNMux3ENkRl8jqFiwS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACF7453.4030407@netconfcentral.com> Date: Fri, 09 Oct 2009 10:35:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <200910090741.n997fpui053292@idle.juniper.net> <000c01ca4902$202d91a0$6801a8c0@oemcomputer> In-Reply-To: <000c01ca4902$202d91a0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 17:35:36 -0000 Randy Presuhn wrote: > Hi - > >> From: "Phil Shafer" >> To: "Andy Bierman" >> Cc: >> Sent: Friday, October 09, 2009 12:41 AM >> Subject: Re: [netmod] yang grammar bug > ... >> But if there's a real need for something new, someone clueful can >> publish a draft detailing this new thing, people will implement it, >> and models that use it will be created and used. >> >> The extension thing is a great idea because it allows the language >> to grow and change over time. >> >> Yes, we're sure to see lots of silly ideas that no one adopts, and >> we're sure to see odd statements that cover odd cases (imagine >> adding system-creatable as an extension) that can be ignored by >> clients and servers that don't care about these odd cases. >> >> In the end, the community will decide what works and what doesn't. > > An excellent argument for classifying this stuff as "Experimental" > rather than standards track. :-( > I was thinking the same thing. It seems like the 'IETF version of NETCONF/YANG' will be the official experiment, which will compete amongst the vendor experiments for market share and interoperability. Maybe Phil is right. Nothing the IETF has done in 25 years has produced any meaningful interoperability for NM configuration, so maybe an Experimental approach will eventually produce a workable standard. > Randy Andy From reid@snmp.com Fri Oct 9 10:40: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 8134428C1DB for ; Fri, 9 Oct 2009 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MqXEC2g63Y8 for ; Fri, 9 Oct 2009 10:40:36 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 5EA3228C183 for ; Fri, 9 Oct 2009 10:40:36 -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 NAA10666 for ; Fri, 9 Oct 2009 13:42:21 -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 NAA07741 for ; Fri, 9 Oct 2009 13:42:20 -0400 (EDT) Message-Id: <200910091742.NAA07741@adminfs.snmp.com> To: netmod@ietf.org Date: Fri, 09 Oct 2009 13:42:20 -0400 From: David Reid Subject: [netmod] hello msg namespace X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2009 17:40:37 -0000 Xiang Li pointed out on the netconf mailing list that the example message in rfc 4742 was missing the namespace. The same problem exists in the yang document in sections 5.6.4.1, 5.6.4.2, and 5.6.4.3. -David Reid From phil@juniper.net Fri Oct 9 11:54: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 7B9DC3A6841 for ; Fri, 9 Oct 2009 11:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 E3ynBNSMLx0c for ; Fri, 9 Oct 2009 11:54:45 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 885A43A681B for ; Fri, 9 Oct 2009 11:54:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSs+HXRm5E6Hf2Kw8vA4ugobAcFIGjSwS@postini.com; Fri, 09 Oct 2009 11:56:31 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 9 Oct 2009 11:54:00 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:54:00 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:53:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:53: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 n99Irvj47242; Fri, 9 Oct 2009 11:53:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n99IfCOV057149; Fri, 9 Oct 2009 18:41:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910091841.n99IfCOV057149@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <000c01ca4902$202d91a0$6801a8c0@oemcomputer> Date: Fri, 9 Oct 2009 14:41:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Oct 2009 18:53:58.0167 (UTC) FILETIME=[DBA36270:01CA4911] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 18:54:46 -0000 "Randy Presuhn" writes: >An excellent argument for classifying this stuff as "Experimental" >rather than standards track. :-( An excellent argument for classifying specific extensions as "Experimental", which I think is natural. Thanks, Phil From mbj@tail-f.com Fri Oct 9 12:37: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 8C53A3A6929 for ; Fri, 9 Oct 2009 12:37:15 -0700 (PDT) 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 9W+nG5E8VfeV for ; Fri, 9 Oct 2009 12:37: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 979BE3A68CC for ; Fri, 9 Oct 2009 12:37:14 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BDBCF616002; Fri, 9 Oct 2009 21:38:58 +0200 (CEST) Date: Fri, 09 Oct 2009 21:38:58 +0200 (CEST) Message-Id: <20091009.213858.176064931.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ACF5B56.1010600@netconfcentral.com> References: <200910091409.n99E941j055291@idle.juniper.net> <4ACF5B56.1010600@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:37:15 -0000 Andy Bierman wrote: > I want this text added to sec. 6.3.1: > > If the YANG compiler does not support a particular extension, > which appears in a YANG module as an unknown-statement, > the entire unknown-statement MAY be ignored by the compiler. Fine with me. I will add it unless someone objects. /martin From mbj@tail-f.com Fri Oct 9 12:37: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 360663A68CC for ; Fri, 9 Oct 2009 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.088, 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 vVhJgSwCFJqD for ; Fri, 9 Oct 2009 12:37: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 72C953A6839 for ; Fri, 9 Oct 2009 12:37:30 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B904616002; Fri, 9 Oct 2009 21:39:15 +0200 (CEST) Date: Fri, 09 Oct 2009 21:39:15 +0200 (CEST) Message-Id: <20091009.213915.119876145.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200910091742.NAA07741@adminfs.snmp.com> References: <200910091742.NAA07741@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] hello msg namespace X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2009 19:37:31 -0000 David Reid wrote: > Xiang Li pointed out on the netconf mailing list that the example > message in rfc 4742 was missing the namespace. The same problem exists > in the yang document in sections 5.6.4.1, 5.6.4.2, and 5.6.4.3. Thanks, fixed. /martin From andy@netconfcentral.com Fri Oct 9 12:40:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB013A6962 for ; Fri, 9 Oct 2009 12:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 PDZNNMHV42t8 for ; Fri, 9 Oct 2009 12:40:39 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 63B343A68A8 for ; Fri, 9 Oct 2009 12:40:39 -0700 (PDT) Received: (qmail 56527 invoked from network); 9 Oct 2009 19:42:23 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 9 Oct 2009 19:42:22 -0000 X-YMail-OSG: XlHX.9EVM1m16GIXJE9yh4xsh7oKg3TOnrLuGm4lhIWVLAWH6KrVNiZA_4rrrP1p_G7RHovgLoRBunkH6bO4vR1R3Q9Qtb0dko2R8dPLJqef5R2OosUyRIMCtSp5LalrFe9049rL99Owov2MvMsSlFhtRTHJv0V7h_glnD_6nyAL1wpgMlNp32o8iygG68aC..gbVOqXt.mOVk4SGQZRX2IDIyR52fWTP78IDdxIlB4FyWrI6JKsmSrABtpaKSCdHaKKrIz8kDRYqppv.LeqIjQdbWEowvLahNRc24Iu5Dfz8lxSpqN3BYfjRj0mT8tP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACF921F.4010806@netconfcentral.com> Date: Fri, 09 Oct 2009 12:42:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910091841.n99IfCOV057149@idle.juniper.net> In-Reply-To: <200910091841.n99IfCOV057149@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang grammar bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:40:40 -0000 Phil Shafer wrote: > "Randy Presuhn" writes: >> An excellent argument for classifying this stuff as "Experimental" >> rather than standards track. :-( > > An excellent argument for classifying specific extensions as > "Experimental", which I think is natural. > You are right. I called IETF N/Y the 'official experiment'. One could argue that describes every Proposed Standard RFC. > Thanks, > Phil Andy From mbj@tail-f.com Mon Oct 12 09:33: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 392BA28C259 for ; Mon, 12 Oct 2009 09:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFhn49r5lu5l for ; Mon, 12 Oct 2009 09:33:48 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id ECD2328C256 for ; Mon, 12 Oct 2009 09:33:47 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D6E35616012 for ; Mon, 12 Oct 2009 18:33:46 +0200 (CEST) Date: Mon, 12 Oct 2009 18:33:46 +0200 (CEST) Message-Id: <20091012.183346.123577726.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 16:33:49 -0000 Hi, Here is proposed text for a new statement "system-creatable" (a.k.a. "assigned-by system"). 7.6.6. The leaf's system-creatable Statement The "system-creatable" statement, which is optional, specifies whether the server is permitted to create instances of a leaf. Such leafs are used when the device needs to record persistent values that cannot be known until the device validates the configuration. The argument is one of the strings "true" or "false". If not specified, the default is "false". If "system-creatable" is "true", the server MAY create an instance of the leaf in the data tree, if it doesn't exist, in the following cases. The behavior depends on the leaf's closest ancestor node in the schema tree which is not a non-presence container: o If no such ancestor exists in the schema tree, the server MAY create an instance of the leaf if it doesn't exist. o Otherwise, if this ancestor is a case node, the server MAY create an instance of the leaf in the data tree if any node from the case exists in the data tree, or if the case node is the choice's default case, and no nodes from any other case exist in the data tree. o Otherwise, the server MAY create an instance of the leaf in the data tree if the ancestor node exists in the data tree. The server MUST NOT create the leaf if the leaf already exists or if "system-creatable" is "false". A system-creatable leaf is created by the server after validation (see Section 8.3.3), if the validation succeeds. Since the leaf creation occurs after validation, constraints (see ^constraints) will not be able to access the new leaf value. If "system-creatable" is "true", the leaf MUST NOT be mandatory, and it MUST NOT have a default value. This statement is ignored if the leaf represents state data, RPC input or output parameters, or notification content. And our favorite use-case added as an example to 7.6.9: The following example illustrates how "system-creatable" can be used: list users { key "name"; leaf name { type string; } leaf uid { type uint32; system-creatable true; } } With the following , the server assigns an appropriate value for the "uid" leaf for the new user: barney And some FAQ entries: {{ faq: Why is system-creatable leaf creation after validation? The constraints defined in the YANG module are meant to be useful in both the client and server contexts, allowing clients to check the configuration they are about to send to a server. If the constraints were allowed to see system-creatable leafs, only the server could enforce constraints. }} {{ faq: Why can't a system-creatable leaf have a default value? A default value tells the client and server what value will be used if the value does not exist in the configuration. If the client sends data with no default value, then the client knows the server will use this default value, and the only value the server can assign such a leaf would be the default value. Since both sides already know the value, having the system create a leaf with a fixed value has no benefit, and so is not permitted. }} {{ faq: Why can't a system-creatable leaf be mandatory? The constraints defined in the YANG module are meant to be useful in both the client and server contexts, allowing clients to check the configuration they are about to send to a server. If the a leaf could be marked mandatory but the system creates it, then the client cannot validate the configuration before sending it to the server. }} /martin From jmh@joelhalpern.com Mon Oct 12 09:47: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 7809F3A63C9 for ; Mon, 12 Oct 2009 09:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8j0H3f1gz+W for ; Mon, 12 Oct 2009 09:47:11 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 75A5B3A686A for ; Mon, 12 Oct 2009 09:47:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 07E7232317B3; Mon, 12 Oct 2009 09:47:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 7164632317A9; Mon, 12 Oct 2009 09:47:06 -0700 (PDT) Message-ID: <4AD35D85.1080205@joelhalpern.com> Date: Mon, 12 Oct 2009 12:47:01 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <20091012.183346.123577726.mbj@tail-f.com> In-Reply-To: <20091012.183346.123577726.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 16:47:12 -0000 Thank you. That looks good and useful to me. Joel Martin Bjorklund wrote: > Hi, > > Here is proposed text for a new statement "system-creatable" > (a.k.a. "assigned-by system"). > > > 7.6.6. The leaf's system-creatable Statement > > The "system-creatable" statement, which is optional, specifies > whether the server is permitted to create instances of a leaf. Such > leafs are used when the device needs to record persistent values that > cannot be known until the device validates the configuration. The > argument is one of the strings "true" or "false". If not specified, > the default is "false". > > If "system-creatable" is "true", the server MAY create an instance of > the leaf in the data tree, if it doesn't exist, in the following > cases. The behavior depends on the leaf's closest ancestor node in > the schema tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the server MAY > create an instance of the leaf if it doesn't exist. > > o Otherwise, if this ancestor is a case node, the server MAY create > an instance of the leaf in the data tree if any node from the case > exists in the data tree, or if the case node is the choice's > default case, and no nodes from any other case exist in the data > tree. > > o Otherwise, the server MAY create an instance of the leaf in the > data tree if the ancestor node exists in the data tree. > > The server MUST NOT create the leaf if the leaf already exists or if > "system-creatable" is "false". > > A system-creatable leaf is created by the server after validation > (see Section 8.3.3), if the validation succeeds. Since the leaf > creation occurs after validation, constraints (see ^constraints) will > not be able to access the new leaf value. > > If "system-creatable" is "true", the leaf MUST NOT be mandatory, and > it MUST NOT have a default value. > > This statement is ignored if the leaf represents state data, RPC > input or output parameters, or notification content. > > And our favorite use-case added as an example to 7.6.9: > > The following example illustrates how "system-creatable" can be used: > > list users { > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > With the following , the server assigns an appropriate > value for the "uid" leaf for the new user: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > barney > > > > > > > > > And some FAQ entries: > > {{ faq: Why is system-creatable leaf creation after validation? > The constraints defined in the YANG module are meant to be > useful in both the client and server contexts, allowing clients > to check the configuration they are about to send to a server. > If the constraints were allowed to see system-creatable leafs, > only the server could enforce constraints. > }} > > {{ faq: Why can't a system-creatable leaf have a default value? > A default value tells the client and server what value will be > used if the value does not exist in the configuration. If the > client sends data with no default value, then the client knows > the server will use this default value, and the only value the > server can assign such a leaf would be the default value. > Since both sides already know the value, having the system > create a leaf with a fixed value has no benefit, and so is > not permitted. > }} > > {{ faq: Why can't a system-creatable leaf be mandatory? > The constraints defined in the YANG module are meant to be > useful in both the client and server contexts, allowing clients > to check the configuration they are about to send to a server. > If the a leaf could be marked mandatory but the system creates > it, then the client cannot validate the configuration before > sending it to the server. > }} > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From phil@juniper.net Mon Oct 12 10:08: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 7740D28C20C for ; Mon, 12 Oct 2009 10:08:53 -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 XY3LyR4D0z0d for ; Mon, 12 Oct 2009 10:08:52 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 4F3C83A685E for ; Mon, 12 Oct 2009 10:08:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKStNioSfwGtc9uWHhqPoNzMP7/G0P1+y0@postini.com; Mon, 12 Oct 2009 10:08:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 12 Oct 2009 10:08:07 -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, 12 Oct 2009 10:08:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:08:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10: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 n9CH86j37847; Mon, 12 Oct 2009 10: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 n9CGtJA5072200; Mon, 12 Oct 2009 16:55:20 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910121655.n9CGtJA5072200@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20091012.183346.123577726.mbj@tail-f.com> Date: Mon, 12 Oct 2009 12:55:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Oct 2009 17:08:06.0445 (UTC) FILETIME=[90F4C5D0:01CA4B5E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 17:08:53 -0000 Very nice..... Thanks, Phil Martin Bjorklund writes: >Hi, > >Here is proposed text for a new statement "system-creatable" >(a.k.a. "assigned-by system"). > > >7.6.6. The leaf's system-creatable Statement > > The "system-creatable" statement, which is optional, specifies > whether the server is permitted to create instances of a leaf. Such > leafs are used when the device needs to record persistent values that > cannot be known until the device validates the configuration. The > argument is one of the strings "true" or "false". If not specified, > the default is "false". > > If "system-creatable" is "true", the server MAY create an instance of > the leaf in the data tree, if it doesn't exist, in the following > cases. The behavior depends on the leaf's closest ancestor node in > the schema tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the server MAY > create an instance of the leaf if it doesn't exist. > > o Otherwise, if this ancestor is a case node, the server MAY create > an instance of the leaf in the data tree if any node from the case > exists in the data tree, or if the case node is the choice's > default case, and no nodes from any other case exist in the data > tree. > > o Otherwise, the server MAY create an instance of the leaf in the > data tree if the ancestor node exists in the data tree. > > The server MUST NOT create the leaf if the leaf already exists or if > "system-creatable" is "false". > > A system-creatable leaf is created by the server after validation > (see Section 8.3.3), if the validation succeeds. Since the leaf > creation occurs after validation, constraints (see ^constraints) will > not be able to access the new leaf value. > > If "system-creatable" is "true", the leaf MUST NOT be mandatory, and > it MUST NOT have a default value. > > This statement is ignored if the leaf represents state data, RPC > input or output parameters, or notification content. > >And our favorite use-case added as an example to 7.6.9: > > The following example illustrates how "system-creatable" can be used: > > list users { > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > With the following , the server assigns an appropriate > value for the "uid" leaf for the new user: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > barney > > > > > > > > >And some FAQ entries: > >{{ faq: Why is system-creatable leaf creation after validation? >The constraints defined in the YANG module are meant to be >useful in both the client and server contexts, allowing clients >to check the configuration they are about to send to a server. >If the constraints were allowed to see system-creatable leafs, >only the server could enforce constraints. >}} > >{{ faq: Why can't a system-creatable leaf have a default value? >A default value tells the client and server what value will be >used if the value does not exist in the configuration. If the >client sends data with no default value, then the client knows >the server will use this default value, and the only value the >server can assign such a leaf would be the default value. >Since both sides already know the value, having the system >create a leaf with a fixed value has no benefit, and so is >not permitted. >}} > >{{ faq: Why can't a system-creatable leaf be mandatory? >The constraints defined in the YANG module are meant to be >useful in both the client and server contexts, allowing clients >to check the configuration they are about to send to a server. >If the a leaf could be marked mandatory but the system creates >it, then the client cannot validate the configuration before >sending it to the server. >}} > > > >/martin >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Mon Oct 12 10:18: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 3E39528C236 for ; Mon, 12 Oct 2009 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 7WNY0zDqxZIF for ; Mon, 12 Oct 2009 10:18:10 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 332C43A67A6 for ; Mon, 12 Oct 2009 10:18:10 -0700 (PDT) Received: (qmail 33693 invoked from network); 12 Oct 2009 17:18:08 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 12 Oct 2009 10:18:07 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: L1YJpEoVM1kq777ISfMFBBqHoVqVjb6InyALu712VKFtcAK0xxRq3lUH4xbtjXX_UBZvINmoN56Jcb3S2tf8e5xDLO6AuJeEokPSFHbkPLKFZ1G8LGg4Ls5ERcoKRGF.kRbIUoXY2jVPa3KlnMnrnsKaivur_LScg7gzPNz1Nn2dbFaVvsA.DGO09ImAbHAY9N6ClNNjQ..aNlDnlM2RpC.jmEFsKImcEX3nYiRbVxsdTxuZxiBIYdl7AEwz2xxhiDA.4SK8t2_m5Wr7rbXZThXa2hqtYAnqtcwkONqwh_wnApPuJI4a9Nmqfr4hqZjy7RzowFPhTVIplRqSZAO90YfBm_yKABlAMdhJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD364DD.9070704@netconfcentral.com> Date: Mon, 12 Oct 2009 10:18:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091012.183346.123577726.mbj@tail-f.com> In-Reply-To: <20091012.183346.123577726.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 17:18:11 -0000 Martin Bjorklund wrote: > Hi, > > Here is proposed text for a new statement "system-creatable" > (a.k.a. "assigned-by system"). > > > 7.6.6. The leaf's system-creatable Statement > > The "system-creatable" statement, which is optional, specifies > whether the server is permitted to create instances of a leaf. Such > leafs are used when the device needs to record persistent values that > cannot be known until the device validates the configuration. The > argument is one of the strings "true" or "false". If not specified, > the default is "false". > > If "system-creatable" is "true", the server MAY create an instance of > the leaf in the data tree, if it doesn't exist, in the following > cases. The behavior depends on the leaf's closest ancestor node in > the schema tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the server MAY > create an instance of the leaf if it doesn't exist. > > o Otherwise, if this ancestor is a case node, the server MAY create > an instance of the leaf in the data tree if any node from the case > exists in the data tree, or if the case node is the choice's > default case, and no nodes from any other case exist in the data > tree. > > o Otherwise, the server MAY create an instance of the leaf in the > data tree if the ancestor node exists in the data tree. > > The server MUST NOT create the leaf if the leaf already exists or if > "system-creatable" is "false". > > A system-creatable leaf is created by the server after validation > (see Section 8.3.3), if the validation succeeds. Since the leaf > creation occurs after validation, constraints (see ^constraints) will > not be able to access the new leaf value. > I do not agree with this CLR or the interpretation in the FAQ below. This changes the meaning of a 'valid database'. All the YANG constraints and all the semantics defined in description-stmts refer to the validity of the running configuration, which is post-system-create. The 'pre-system-create' is just another incomplete candidate database, of no real interest since it is an implementation detail. > If "system-creatable" is "true", the leaf MUST NOT be mandatory, and > it MUST NOT have a default value. > I don't get these CLRs either. Mandatory true means the server must pick some value. It turns the MAY into a MUST. That is useful. Default and system-creatable do not really help, but don't hurt either. This could happen via refine or deviations, and it should be OK. It just means the system will create a leaf with the specified default. The system-creatable property is redundant, not an error. Mandatory and default are not allowed together, but otherwise these are OK for system-creatable. > This statement is ignored if the leaf represents state data, RPC > input or output parameters, or notification content. > > And our favorite use-case added as an example to 7.6.9: > > The following example illustrates how "system-creatable" can be used: > > list users { > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > With the following , the server assigns an appropriate > value for the "uid" leaf for the new user: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > barney > > > > > > > > > And some FAQ entries: > > {{ faq: Why is system-creatable leaf creation after validation? > The constraints defined in the YANG module are meant to be > useful in both the client and server contexts, allowing clients > to check the configuration they are about to send to a server. > If the constraints were allowed to see system-creatable leafs, > only the server could enforce constraints. > }} > > {{ faq: Why can't a system-creatable leaf have a default value? > A default value tells the client and server what value will be > used if the value does not exist in the configuration. If the > client sends data with no default value, then the client knows > the server will use this default value, and the only value the > server can assign such a leaf would be the default value. > Since both sides already know the value, having the system > create a leaf with a fixed value has no benefit, and so is > not permitted. > }} > > {{ faq: Why can't a system-creatable leaf be mandatory? > The constraints defined in the YANG module are meant to be > useful in both the client and server contexts, allowing clients > to check the configuration they are about to send to a server. > If the a leaf could be marked mandatory but the system creates > it, then the client cannot validate the configuration before > sending it to the server. > }} > > > > /martin Andy From phil@juniper.net Mon Oct 12 10:44: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 F324D3A682E for ; Mon, 12 Oct 2009 10:44:05 -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 djhjnfIq4HKW for ; Mon, 12 Oct 2009 10:44:02 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id B900D3A68EC for ; Mon, 12 Oct 2009 10:43:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKStNq2INyCsu2IN7S2t2LrqZ5aBgsj+MR@postini.com; Mon, 12 Oct 2009 10:43:57 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 12 Oct 2009 10:42:24 -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, 12 Oct 2009 10:42:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:42:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:42: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 n9CHgMj55977; Mon, 12 Oct 2009 10:42:22 -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 n9CHTZM3072644; Mon, 12 Oct 2009 17:29:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910121729.n9CHTZM3072644@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD364DD.9070704@netconfcentral.com> Date: Mon, 12 Oct 2009 13:29:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Oct 2009 17:42:22.0348 (UTC) FILETIME=[5A5EACC0:01CA4B63] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 17:44:06 -0000 Andy Bierman writes: >Default and system-creatable do not really help, >but don't hurt either. This could happen via refine >or deviations, and it should be OK. It just means >the system will create a leaf with the specified default. Why is this useful? Having the system assign a fixed default is not interesting, and forces us toward the "report-all" extra noisy mode. >Mandatory and default are not allowed together, but otherwise >these are OK for system-creatable. For the same reasons we don't allow mandatory and default (having to set it to a value when the value is coded in the YANG module), we don't allow SC and either. It makes no sense and adds nothing to the model. The big issue here is that we don't want to make constraints that are not enforcable in the client context, and we don't want to make two classes of constraints, some for the server, some for the client. A client should know that the config it is sending is valid, to the extent possible. Thanks, Phil From andy@netconfcentral.com Mon Oct 12 11:21:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D579328C1DD for ; Mon, 12 Oct 2009 11:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, UNPARSEABLE_RELAY=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 kh7D8Cy9q3pJ for ; Mon, 12 Oct 2009 11:21:30 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id E575628C24C for ; Mon, 12 Oct 2009 11:21:29 -0700 (PDT) Received: from [68.142.200.225] by n17.bullet.mail.mud.yahoo.com with NNFMP; 12 Oct 2009 18:21:28 -0000 Received: from [68.142.201.243] by t6.bullet.mud.yahoo.com with NNFMP; 12 Oct 2009 18:21:28 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 12 Oct 2009 18:21:28 -0000 X-Yahoo-Newman-Id: 574803.62857.bm@omp404.mail.mud.yahoo.com Received: (qmail 68475 invoked from network); 12 Oct 2009 18:21:28 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 12 Oct 2009 11:21:28 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: JMgw6_wVM1mx3xUj2KgtH1CCGaCHjwXqljMc59cp.2yXw5z_RuD4t6jBJuQUw5TbdxnksF5BntM7qx9oN_Jh.eNPDyfBLYZG9GCMZD7tiXoqV55bqii.COZJOPyp3m_ZiRQoneoQsn95g3rbKdUgbA2IWH4nHsHcHbVFDxr88CiYVCdp5W6QeDEpptr71Tv8kqh2ayZKhpeUjHohqm3EJ2o0aXj9Tnl24DKzBT71C7puuLcA69RO06vaR7hiXME_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD373B6.4030506@netconfcentral.com> Date: Mon, 12 Oct 2009 11:21:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910121729.n9CHTZM3072644@idle.juniper.net> In-Reply-To: <200910121729.n9CHTZM3072644@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 18:21:30 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Default and system-creatable do not really help, >> but don't hurt either. This could happen via refine >> or deviations, and it should be OK. It just means >> the system will create a leaf with the specified default. > > Why is this useful? Having the system assign a fixed default > is not interesting, and forces us toward the "report-all" > extra noisy mode. > I do not see the connection to the optional report-all mode, which is a retrieval operation, not an edit operation. >> Mandatory and default are not allowed together, but otherwise >> these are OK for system-creatable. > > For the same reasons we don't allow mandatory and default (having > to set it to a value when the value is coded in the YANG module), > we don't allow SC and either. It makes no sense and adds nothing > to the model. A fatal error for a no-op condition is rather extreme. There are so many little CLRs in YANG on Day One, I can't imagine how many there will be in 5 years. > > The big issue here is that we don't want to make constraints that > are not enforcable in the client context, and we don't want to make > two classes of constraints, some for the server, some for the client. > A client should know that the config it is sending is valid, to the > extent possible. > Who is 'we'? IMO, the constraints apply to the operational state which YANG completely ignores. leaf minimum-mtu { system-creatable true; type uint32; } leaf big-packet-feature { type boolean; when "/minimum-mtu >= 9000"; } Do you really think the YANG data modeler intends for the big-packet-feature to only be available if the client sets /minimum-mtu? IMO, the data modeler intends the feature to be available any time the minimum MTU is >= 9000, even if the system sets the MTU. I think having the constraints resolve to 'false' any time the server creates a leaf referenced in any validation statements (instead of the client) is a huge bug, not a feature at all. It goes against the agreement reached on the conference call that all YANG validation refers to all config, plus server created nodes. > Thanks, > Phil > Andy From lhotka@cesnet.cz Mon Oct 12 11:29: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 6C2483A6950 for ; Mon, 12 Oct 2009 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1uei0hkxzDB for ; Mon, 12 Oct 2009 11:29:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 412383A68C9 for ; Mon, 12 Oct 2009 11:29: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 27821D800BD; Mon, 12 Oct 2009 20:29:11 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091012.183346.123577726.mbj@tail-f.com> References: <20091012.183346.123577726.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 12 Oct 2009 20:29:09 +0200 Message-Id: <1255372149.7813.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 18:29:12 -0000 Martin Bjorklund píše v Po 12. 10. 2009 v 18:33 +0200: > Hi, > > Here is proposed text for a new statement "system-creatable" > (a.k.a. "assigned-by system"). Didn't the WG agree on feature freeze in Stockholm? Also, I thought the conference call was intended to close up the issues around mandatory, default etc. but this has the potential to open the can of worms again. So I don't agree with this addition. Lada > > > 7.6.6. The leaf's system-creatable Statement > > The "system-creatable" statement, which is optional, specifies > whether the server is permitted to create instances of a leaf. Such > leafs are used when the device needs to record persistent values that > cannot be known until the device validates the configuration. The > argument is one of the strings "true" or "false". If not specified, > the default is "false". > > If "system-creatable" is "true", the server MAY create an instance of > the leaf in the data tree, if it doesn't exist, in the following > cases. The behavior depends on the leaf's closest ancestor node in > the schema tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the server MAY > create an instance of the leaf if it doesn't exist. > > o Otherwise, if this ancestor is a case node, the server MAY create > an instance of the leaf in the data tree if any node from the case > exists in the data tree, or if the case node is the choice's > default case, and no nodes from any other case exist in the data > tree. > > o Otherwise, the server MAY create an instance of the leaf in the > data tree if the ancestor node exists in the data tree. > > The server MUST NOT create the leaf if the leaf already exists or if > "system-creatable" is "false". > > A system-creatable leaf is created by the server after validation > (see Section 8.3.3), if the validation succeeds. Since the leaf > creation occurs after validation, constraints (see ^constraints) will > not be able to access the new leaf value. > > If "system-creatable" is "true", the leaf MUST NOT be mandatory, and > it MUST NOT have a default value. > > This statement is ignored if the leaf represents state data, RPC > input or output parameters, or notification content. > > And our favorite use-case added as an example to 7.6.9: > > The following example illustrates how "system-creatable" can be used: > > list users { > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > With the following , the server assigns an appropriate > value for the "uid" leaf for the new user: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > barney > > > > > > > > > And some FAQ entries: > > {{ faq: Why is system-creatable leaf creation after validation? > The constraints defined in the YANG module are meant to be > useful in both the client and server contexts, allowing clients > to check the configuration they are about to send to a server. > If the constraints were allowed to see system-creatable leafs, > only the server could enforce constraints. > }} > > {{ faq: Why can't a system-creatable leaf have a default value? > A default value tells the client and server what value will be > used if the value does not exist in the configuration. If the > client sends data with no default value, then the client knows > the server will use this default value, and the only value the > server can assign such a leaf would be the default value. > Since both sides already know the value, having the system > create a leaf with a fixed value has no benefit, and so is > not permitted. > }} > > {{ faq: Why can't a system-creatable leaf be mandatory? > The constraints defined in the YANG module are meant to be > useful in both the client and server contexts, allowing clients > to check the configuration they are about to send to a server. > If the a leaf could be marked mandatory but the system creates > it, then the client cannot validate the configuration before > sending it to the server. > }} > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Oct 12 11:32:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3EE3A6860 for ; Mon, 12 Oct 2009 11:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 PjiLAacrPUlh for ; Mon, 12 Oct 2009 11:32:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 57D333A6963 for ; Mon, 12 Oct 2009 11:32:18 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EAE2C0014; Mon, 12 Oct 2009 20:32:18 +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 id91ZfwJokOp; Mon, 12 Oct 2009 20:32:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43029C0018; Mon, 12 Oct 2009 20:32:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A3ADED1ADBA; Mon, 12 Oct 2009 20:32:16 +0200 (CEST) Date: Mon, 12 Oct 2009 20:32:16 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091012183216.GA18631@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1255372149.7813.58.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable 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, 12 Oct 2009 18:32:19 -0000 On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: > Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: > > Hi, > > > > Here is proposed text for a new statement "system-creatable" > > (a.k.a. "assigned-by system"). > > Didn't the WG agree on feature freeze in Stockholm? Also, I thought the > conference call was intended to close up the issues around mandatory, > default etc. but this has the potential to open the can of worms again. > So I don't agree with this addition. So can you please tell us how to close the issue without any addition or change? Make a concrete proposal please. Thanks, /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 Oct 12 11:40: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 27C2B28C2B5 for ; Mon, 12 Oct 2009 11:40:56 -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_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 C5h0IDRgAaww for ; Mon, 12 Oct 2009 11:40:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 203E028C2AF for ; Mon, 12 Oct 2009 11:40: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 9EF40D800C5; Mon, 12 Oct 2009 20:40:55 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091012183216.GA18631@elstar.local> References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 12 Oct 2009 20:40:53 +0200 Message-Id: <1255372853.7813.66.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 18:40:56 -0000 Juergen Schoenwaelder píše v Po 12. 10. 2009 v 20:32 +0200: > On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: > > Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: > > > Hi, > > > > > > Here is proposed text for a new statement "system-creatable" > > > (a.k.a. "assigned-by system"). > > > > Didn't the WG agree on feature freeze in Stockholm? Also, I thought the > > conference call was intended to close up the issues around mandatory, > > default etc. but this has the potential to open the can of worms again. > > So I don't agree with this addition. > > So can you please tell us how to close the issue without any addition > or change? Make a concrete proposal please. I thought the issue was closed by the conclusions of the conf call and my understanding was that nothing essential would change except certain clarifications. Is this new feature so badly needed for YANG 1.0? Lada > > Thanks, > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Oct 12 11:45:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E1E3A696E for ; Mon, 12 Oct 2009 11:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 8iqek1IcrNhH for ; Mon, 12 Oct 2009 11:45:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A392E3A687C for ; Mon, 12 Oct 2009 11:45:36 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15EE9C0014; Mon, 12 Oct 2009 20:45:37 +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 HyxQdmsTIXJG; Mon, 12 Oct 2009 20:45:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D72BBC0017; Mon, 12 Oct 2009 20:45:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4829CD1AEDA; Mon, 12 Oct 2009 20:45:35 +0200 (CEST) Date: Mon, 12 Oct 2009 20:45:35 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20091012184535.GA18744@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1255372853.7813.66.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable 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, 12 Oct 2009 18:45:38 -0000 On Mon, Oct 12, 2009 at 08:40:53PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 12. 10. 2009 v 20:32 +0200: > > On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: > > > Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: > > > > Hi, > > > > > > > > Here is proposed text for a new statement "system-creatable" > > > > (a.k.a. "assigned-by system"). > > > > > > Didn't the WG agree on feature freeze in Stockholm? Also, I thought the > > > conference call was intended to close up the issues around mandatory, > > > default etc. but this has the potential to open the can of worms again. > > > So I don't agree with this addition. > > > > So can you please tell us how to close the issue without any addition > > or change? Make a concrete proposal please. > > I thought the issue was closed by the conclusions of the conf call and > my understanding was that nothing essential would change except certain > clarifications. Is this new feature so badly needed for YANG 1.0? I think it is part of the resolution of an issue that kept us from moving forward for quite a while. Again, if you know some other solution, please tell us what it is. Concrete text appreciated. /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 Mon Oct 12 12:15: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 B855928C2C4 for ; Mon, 12 Oct 2009 12:15:05 -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 GJReUxLAeEWy for ; Mon, 12 Oct 2009 12:15:05 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 073BC28C2BB for ; Mon, 12 Oct 2009 12:15:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKStOANhXlFHocnvqFayQZHNvUoaZPsTXK@postini.com; Mon, 12 Oct 2009 12:15:05 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 12 Oct 2009 12:13:11 -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, 12 Oct 2009 12:13:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 12:13:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 12:13:10 -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 n9CJD9j01081; Mon, 12 Oct 2009 12:13:10 -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 n9CJ0Nk4073698; Mon, 12 Oct 2009 19:00:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910121900.n9CJ0Nk4073698@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD373B6.4030506@netconfcentral.com> Date: Mon, 12 Oct 2009 15:00:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Oct 2009 19:13:10.0127 (UTC) FILETIME=[097FC7F0:01CA4B70] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 19:15:05 -0000 Andy Bierman writes: >> The big issue here is that we don't want to make constraints that >> are not enforcable in the client context, and we don't want to make >> two classes of constraints, some for the server, some for the client. >> A client should know that the config it is sending is valid, to the >> extent possible. > >Who is 'we'? Apologies, I should only speak for myself. I do not want to make constraints that are not enforcable in the client context. And I do not want to make two classes of constraints, some which the client can enforce, and some which it cannot. >IMO, the constraints apply to the operational state which YANG >completely ignores. NETCONF (and YANG) are definitely more concerned with configuration than operational data, but I don't see where this applies to "system-creatable", which is fully configuration. Martin, Can you please add a line about SC being "config true" only? > leaf minimum-mtu { > system-creatable true; > type uint32; > } > > > leaf big-packet-feature { > type boolean; > when "/minimum-mtu >= 9000"; > } > >Do you really think the YANG data modeler intends for the >big-packet-feature to only be available if the client sets >/minimum-mtu? IMO, the data modeler intends the >feature to be available any time the minimum MTU is >= 9000, >even if the system sets the MTU. IMHO this is a bad constraint, since the client cannot hope to enforce it. It will never know if the config that it sends is going to work, even if you fix the leading slash. Thanks, Phil From mbj@tail-f.com Mon Oct 12 13:08: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 48CAF3A67F0 for ; Mon, 12 Oct 2009 13:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=1.300, 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 0fXqcV-eahu4 for ; Mon, 12 Oct 2009 13:08: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 7981C3A63EC for ; Mon, 12 Oct 2009 13:08:11 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2A99A616014; Mon, 12 Oct 2009 22:08:11 +0200 (CEST) Date: Mon, 12 Oct 2009 22:08:10 +0200 (CEST) Message-Id: <20091012.220810.174653917.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200910121900.n9CJ0Nk4073698@idle.juniper.net> References: <4AD373B6.4030506@netconfcentral.com> <200910121900.n9CJ0Nk4073698@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 20:08:12 -0000 Phil Shafer wrote: > Martin, > Can you please add a line about SC being "config true" only? The proposed text says: This statement is ignored if the leaf represents state data, RPC input or output parameters, or notification content. /martin From lhotka@cesnet.cz Mon Oct 12 13:21: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 5FE8A3A6958 for ; Mon, 12 Oct 2009 13:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.33 X-Spam-Level: X-Spam-Status: No, score=0.33 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 wNd3mXlrzzMb for ; Mon, 12 Oct 2009 13:21:14 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8FBAA3A6821 for ; Mon, 12 Oct 2009 13:21: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 C98BAD800BD; Mon, 12 Oct 2009 22:21:14 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091012184535.GA18744@elstar.local> References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 12 Oct 2009 22:21:13 +0200 Message-Id: <1255378873.7813.152.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 20:21:15 -0000 Juergen Schoenwaelder píše v Po 12. 10. 2009 v 20:45 +0200: > On Mon, Oct 12, 2009 at 08:40:53PM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v Po 12. 10. 2009 v 20:32 +0200: > > > On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: > > > > Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: > > > > > Hi, > > > > > > > > > > Here is proposed text for a new statement "system-creatable" > > > > > (a.k.a. "assigned-by system"). > > > > > > > > Didn't the WG agree on feature freeze in Stockholm? Also, I thought the > > > > conference call was intended to close up the issues around mandatory, > > > > default etc. but this has the potential to open the can of worms again. > > > > So I don't agree with this addition. > > > > > > So can you please tell us how to close the issue without any addition > > > or change? Make a concrete proposal please. > > > > I thought the issue was closed by the conclusions of the conf call and > > my understanding was that nothing essential would change except certain > > clarifications. Is this new feature so badly needed for YANG 1.0? > > I think it is part of the resolution of an issue that kept us from > moving forward for quite a while. Again, if you know some other > solution, please tell us what it is. Concrete text appreciated. Solution to exactly what? I don't know what the pressing issue is. On the other hand, Andy is right that this system-creatable introduces a new phase of configuration life cycle (pre- and post-system-create) and new way of fiddling with the configuration infoset besides defaults. This shouldn't be taken so lightly, especially two weeks before I-D submission deadline and past WG deadline. Lada Lada > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Mon Oct 12 13:30: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 A68E528C122 for ; Mon, 12 Oct 2009 13:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 V-b8HZedvFq1 for ; Mon, 12 Oct 2009 13:30:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A7BD028C121 for ; Mon, 12 Oct 2009 13:30:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 9E24532317B0; Mon, 12 Oct 2009 13:30:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id BB6FE32317AB; Mon, 12 Oct 2009 13:30:24 -0700 (PDT) Message-ID: <4AD391DB.5030707@joelhalpern.com> Date: Mon, 12 Oct 2009 16:30:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> In-Reply-To: <1255378873.7813.152.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 20:30:25 -0000 Actually, rather than introducing a new phase, I think the definition of System createable makes clear certain things that were otherwise quite muddy. To focus on the question of the interaction with MUST, by marking things system-creatable, and defining the rules for interaction with MUST statements in the model, we avoid problems. Without this definition, you can have MUST statements in the model such that a client can not determine whether a config is valid, and therefore will have no clue what is wrong when he tries to commit it, and it fails. Having "MUSTs" depend upon optional things is fine, as long as the MUST is written to allow for the case of non-existence. But if the system may fill in the value, then the MUST may well fail, even though there is no defined default, and the user has not specified an illegal value. And under our current setup, when the config fails, the "system defined" values would still not be in the non-committed config, so the user would have no clue as to what is wrong. With system-creatable, and the rules as Martin wrote them, we get predictable and comprehensible behavior. That seems a significant improvement. This also gets us out of the confusion about whether the system is allowed to unilaterally over-ride the "default" value from a default clause. It isn't. But up until now we have had smart people read the documents and conclude that such a behavior is allowed. While other smart people have thought it was prohibited. Clarifying the what behavior is allowed is important. Yours, Joel Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Po 12. 10. 2009 v 20:45 +0200: >> On Mon, Oct 12, 2009 at 08:40:53PM +0200, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder p????e v Po 12. 10. 2009 v 20:32 +0200: >>>> On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: >>>>> Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: >>>>>> Hi, >>>>>> >>>>>> Here is proposed text for a new statement "system-creatable" >>>>>> (a.k.a. "assigned-by system"). >>>>> Didn't the WG agree on feature freeze in Stockholm? Also, I thought the >>>>> conference call was intended to close up the issues around mandatory, >>>>> default etc. but this has the potential to open the can of worms again. >>>>> So I don't agree with this addition. >>>> So can you please tell us how to close the issue without any addition >>>> or change? Make a concrete proposal please. >>> I thought the issue was closed by the conclusions of the conf call and >>> my understanding was that nothing essential would change except certain >>> clarifications. Is this new feature so badly needed for YANG 1.0? >> I think it is part of the resolution of an issue that kept us from >> moving forward for quite a while. Again, if you know some other >> solution, please tell us what it is. Concrete text appreciated. > > Solution to exactly what? I don't know what the pressing issue is. > > On the other hand, Andy is right that this system-creatable introduces a > new phase of configuration life cycle (pre- and post-system-create) and > new way of fiddling with the configuration infoset besides defaults. > This shouldn't be taken so lightly, especially two weeks before I-D > submission deadline and past WG deadline. > > Lada > > > Lada > >> /js >> From lhotka@cesnet.cz Mon Oct 12 14:02: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 2743428C1DE for ; Mon, 12 Oct 2009 14:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=0.743, 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 YrbWVEt28f0M for ; Mon, 12 Oct 2009 14:02:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 051FE28C1C8 for ; Mon, 12 Oct 2009 14:02:04 -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 63C01D800BD; Mon, 12 Oct 2009 23:02:04 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4AD391DB.5030707@joelhalpern.com> References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 12 Oct 2009 23:02:02 +0200 Message-Id: <1255381322.7813.180.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 21:02:05 -0000 Joel M. Halpern píše v Po 12. 10. 2009 v 16:30 -0400: > Actually, rather than introducing a new phase, I think the definition of > System createable makes clear certain things that were otherwise quite > muddy. > > To focus on the question of the interaction with MUST, by marking things > system-creatable, and defining the rules for interaction with MUST > statements in the model, we avoid problems. I am not happy with these rules, if I understand them correctly. Extending Martin's example: list users { --> unique uid; key "name"; leaf name { type string; } leaf uid { type uint32; system-creatable true; } } Is there any guarantee for uniqueness of "uid" (or possibly 'must' constraints involving "uid") if the text says that "Since the leaf creation occurs after validation, constraints (see ^constraints) will not be able to access the new leaf value."? > > Without this definition, you can have MUST statements in the model such > that a client can not determine whether a config is valid, and therefore I don't see how this could happen, provided that I know what "config" exactly is - and system-creatable makes this notion even more fuzzy. Lada > will have no clue what is wrong when he tries to commit it, and it > fails. Having "MUSTs" depend upon optional things is fine, as long as > the MUST is written to allow for the case of non-existence. But if the > system may fill in the value, then the MUST may well fail, even though > there is no defined default, and the user has not specified an illegal > value. > And under our current setup, when the config fails, the "system defined" > values would still not be in the non-committed config, so the user would > have no clue as to what is wrong. > > With system-creatable, and the rules as Martin wrote them, we get > predictable and comprehensible behavior. That seems a significant > improvement. > > This also gets us out of the confusion about whether the system is > allowed to unilaterally over-ride the "default" value from a default > clause. It isn't. But up until now we have had smart people read the > documents and conclude that such a behavior is allowed. While other > smart people have thought it was prohibited. Clarifying the what > behavior is allowed is important. > > Yours, > Joel > > Ladislav Lhotka wrote: > > Juergen Schoenwaelder píše v Po 12. 10. 2009 v 20:45 +0200: > >> On Mon, Oct 12, 2009 at 08:40:53PM +0200, Ladislav Lhotka wrote: > >>> Juergen Schoenwaelder p????e v Po 12. 10. 2009 v 20:32 +0200: > >>>> On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: > >>>>> Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: > >>>>>> Hi, > >>>>>> > >>>>>> Here is proposed text for a new statement "system-creatable" > >>>>>> (a.k.a. "assigned-by system"). > >>>>> Didn't the WG agree on feature freeze in Stockholm? Also, I thought the > >>>>> conference call was intended to close up the issues around mandatory, > >>>>> default etc. but this has the potential to open the can of worms again. > >>>>> So I don't agree with this addition. > >>>> So can you please tell us how to close the issue without any addition > >>>> or change? Make a concrete proposal please. > >>> I thought the issue was closed by the conclusions of the conf call and > >>> my understanding was that nothing essential would change except certain > >>> clarifications. Is this new feature so badly needed for YANG 1.0? > >> I think it is part of the resolution of an issue that kept us from > >> moving forward for quite a while. Again, if you know some other > >> solution, please tell us what it is. Concrete text appreciated. > > > > Solution to exactly what? I don't know what the pressing issue is. > > > > On the other hand, Andy is right that this system-creatable introduces a > > new phase of configuration life cycle (pre- and post-system-create) and > > new way of fiddling with the configuration infoset besides defaults. > > This shouldn't be taken so lightly, especially two weeks before I-D > > submission deadline and past WG deadline. > > > > Lada > > > > > > Lada > > > >> /js > >> -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Oct 12 15:23: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 0CEBF28C1E6 for ; Mon, 12 Oct 2009 15:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 iQ9W6dsiPI3Z for ; Mon, 12 Oct 2009 15:23:33 -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 ED0A63A69D3 for ; Mon, 12 Oct 2009 15:23:32 -0700 (PDT) Received: from [68.142.200.224] by n10.bullet.mail.mud.yahoo.com with NNFMP; 12 Oct 2009 22:23:32 -0000 Received: from [68.142.201.253] by t5.bullet.mud.yahoo.com with NNFMP; 12 Oct 2009 22:23:32 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 12 Oct 2009 22:23:32 -0000 X-Yahoo-Newman-Id: 177826.86613.bm@omp414.mail.mud.yahoo.com Received: (qmail 54417 invoked from network); 12 Oct 2009 22:23:31 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 12 Oct 2009 15:23:31 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Fs5W7y8VM1nkQXi_P1dVUDA3DLSbonxWhc_w6qf9mYshSoCeL6IhTX5eBioFrHDYacHKjbK_bcBnGBv7wUMt87I8fi_wO3.JrjWBxipB3a8ylSTGd.A8X7JmLj4VKFds5t4pLIFAKQNbqjBHXIr7afXlGpllRA9LLognCqvKKuhuO3BGfbs8fICof1FDH54QK.uDEiCnsVtUxNS5bkN0HD511GcKTK6rQop1ugyIOBt1iNNfIZXDvqyYxubggDx3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3AC71.1080601@netconfcentral.com> Date: Mon, 12 Oct 2009 15:23:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> In-Reply-To: <1255381322.7813.180.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 22:23:34 -0000 Ladislav Lhotka wrote: > Joel M. Halpern píše v Po 12. 10. 2009 v 16:30 -0400: >> Actually, rather than introducing a new phase, I think the definition of >> System createable makes clear certain things that were otherwise quite >> muddy. >> >> To focus on the question of the interaction with MUST, by marking things >> system-creatable, and defining the rules for interaction with MUST >> statements in the model, we avoid problems. > > I am not happy with these rules, if I understand them correctly. > Extending Martin's example: > > list users { > --> unique uid; > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > Is there any guarantee for uniqueness of "uid" (or possibly 'must' > constraints involving "uid") if the text says that > "Since the leaf creation occurs after validation, constraints (see > ^constraints) will not be able to access the new leaf value."? > > >> Without this definition, you can have MUST statements in the model such >> that a client can not determine whether a config is valid, and therefore > > I don't see how this could happen, provided that I know what "config" > exactly is - and system-creatable makes this notion even more fuzzy. > I agree with you. The 'unique' constraint in your example, and the 'when' constraint in my example, show that the data modeler wants to write validation rules which are independent of client/server origin status. Whether you call that operational state or configuration, it still ends up meaning the constraint applies to the running system, not to the client-provided configuration data. > Lada > Andy >> will have no clue what is wrong when he tries to commit it, and it >> fails. Having "MUSTs" depend upon optional things is fine, as long as >> the MUST is written to allow for the case of non-existence. But if the >> system may fill in the value, then the MUST may well fail, even though >> there is no defined default, and the user has not specified an illegal >> value. >> And under our current setup, when the config fails, the "system defined" >> values would still not be in the non-committed config, so the user would >> have no clue as to what is wrong. >> >> With system-creatable, and the rules as Martin wrote them, we get >> predictable and comprehensible behavior. That seems a significant >> improvement. >> >> This also gets us out of the confusion about whether the system is >> allowed to unilaterally over-ride the "default" value from a default >> clause. It isn't. But up until now we have had smart people read the >> documents and conclude that such a behavior is allowed. While other >> smart people have thought it was prohibited. Clarifying the what >> behavior is allowed is important. >> >> Yours, >> Joel >> >> Ladislav Lhotka wrote: >>> Juergen Schoenwaelder píše v Po 12. 10. 2009 v 20:45 +0200: >>>> On Mon, Oct 12, 2009 at 08:40:53PM +0200, Ladislav Lhotka wrote: >>>>> Juergen Schoenwaelder p????e v Po 12. 10. 2009 v 20:32 +0200: >>>>>> On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: >>>>>>> Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is proposed text for a new statement "system-creatable" >>>>>>>> (a.k.a. "assigned-by system"). >>>>>>> Didn't the WG agree on feature freeze in Stockholm? Also, I thought the >>>>>>> conference call was intended to close up the issues around mandatory, >>>>>>> default etc. but this has the potential to open the can of worms again. >>>>>>> So I don't agree with this addition. >>>>>> So can you please tell us how to close the issue without any addition >>>>>> or change? Make a concrete proposal please. >>>>> I thought the issue was closed by the conclusions of the conf call and >>>>> my understanding was that nothing essential would change except certain >>>>> clarifications. Is this new feature so badly needed for YANG 1.0? >>>> I think it is part of the resolution of an issue that kept us from >>>> moving forward for quite a while. Again, if you know some other >>>> solution, please tell us what it is. Concrete text appreciated. >>> Solution to exactly what? I don't know what the pressing issue is. >>> >>> On the other hand, Andy is right that this system-creatable introduces a >>> new phase of configuration life cycle (pre- and post-system-create) and >>> new way of fiddling with the configuration infoset besides defaults. >>> This shouldn't be taken so lightly, especially two weeks before I-D >>> submission deadline and past WG deadline. >>> >>> Lada >>> >>> >>> Lada >>> >>>> /js >>>> From jmh@joelhalpern.com Mon Oct 12 15:51: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 A976A28C21C for ; Mon, 12 Oct 2009 15:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 PXc8IDKToyyG for ; Mon, 12 Oct 2009 15:51:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B966C28C1B0 for ; Mon, 12 Oct 2009 15:51:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id DCD4432317AE; Mon, 12 Oct 2009 15:51:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id D54A73231776; Mon, 12 Oct 2009 15:51:58 -0700 (PDT) Message-ID: <4AD3B309.9050505@joelhalpern.com> Date: Mon, 12 Oct 2009 18:51:53 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> In-Reply-To: <4AD3AC71.1080601@netconfcentral.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 22:51:59 -0000 Let us suppose that we allow such rules. What is the poor user of netconf / netmod supposed to do when he gets an error? The value producing the error does not even appear in his configuration. For the unique uid case, one can argue that the system is misbehaving. But for the mtu example, the user gets an error because the mtu is too small, but there is no mtu in the configuration. And, if we allow arbitrary MUST statements referencing system-creatable objects, then the set of possible confusions is, I think, much larger than the set of "valuable items" that may be enabled. At least, if we decide to allow this, the use of the system-createable tag provides a hint as to where to look for the problem. Although how one would look for it is beyond me. Yours, Joel Andy Bierman wrote: > Ladislav Lhotka wrote: >> Joel M. Halpern píše v Po 12. 10. 2009 v 16:30 -0400: >>> Actually, rather than introducing a new phase, I think the definition of >>> System createable makes clear certain things that were otherwise quite >>> muddy. >>> >>> To focus on the question of the interaction with MUST, by marking things >>> system-creatable, and defining the rules for interaction with MUST >>> statements in the model, we avoid problems. >> I am not happy with these rules, if I understand them correctly. >> Extending Martin's example: >> >> list users { >> --> unique uid; >> key "name"; >> leaf name { >> type string; >> } >> leaf uid { >> type uint32; >> system-creatable true; >> } >> } >> >> Is there any guarantee for uniqueness of "uid" (or possibly 'must' >> constraints involving "uid") if the text says that >> "Since the leaf creation occurs after validation, constraints (see >> ^constraints) will not be able to access the new leaf value."? >> >> >>> Without this definition, you can have MUST statements in the model such >>> that a client can not determine whether a config is valid, and therefore >> I don't see how this could happen, provided that I know what "config" >> exactly is - and system-creatable makes this notion even more fuzzy. >> > > > I agree with you. > The 'unique' constraint in your example, and the 'when' constraint > in my example, show that the data modeler wants to write validation > rules which are independent of client/server origin status. > Whether you call that operational state or configuration, it > still ends up meaning the constraint applies to the running > system, not to the client-provided configuration data. > > >> Lada >> > > Andy > > >>> will have no clue what is wrong when he tries to commit it, and it >>> fails. Having "MUSTs" depend upon optional things is fine, as long as >>> the MUST is written to allow for the case of non-existence. But if the >>> system may fill in the value, then the MUST may well fail, even though >>> there is no defined default, and the user has not specified an illegal >>> value. >>> And under our current setup, when the config fails, the "system defined" >>> values would still not be in the non-committed config, so the user would >>> have no clue as to what is wrong. >>> >>> With system-creatable, and the rules as Martin wrote them, we get >>> predictable and comprehensible behavior. That seems a significant >>> improvement. >>> >>> This also gets us out of the confusion about whether the system is >>> allowed to unilaterally over-ride the "default" value from a default >>> clause. It isn't. But up until now we have had smart people read the >>> documents and conclude that such a behavior is allowed. While other >>> smart people have thought it was prohibited. Clarifying the what >>> behavior is allowed is important. >>> >>> Yours, >>> Joel >>> >>> Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder píše v Po 12. 10. 2009 v 20:45 +0200: >>>>> On Mon, Oct 12, 2009 at 08:40:53PM +0200, Ladislav Lhotka wrote: >>>>>> Juergen Schoenwaelder p????e v Po 12. 10. 2009 v 20:32 +0200: >>>>>>> On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: >>>>>>>> Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Here is proposed text for a new statement "system-creatable" >>>>>>>>> (a.k.a. "assigned-by system"). >>>>>>>> Didn't the WG agree on feature freeze in Stockholm? Also, I thought the >>>>>>>> conference call was intended to close up the issues around mandatory, >>>>>>>> default etc. but this has the potential to open the can of worms again. >>>>>>>> So I don't agree with this addition. >>>>>>> So can you please tell us how to close the issue without any addition >>>>>>> or change? Make a concrete proposal please. >>>>>> I thought the issue was closed by the conclusions of the conf call and >>>>>> my understanding was that nothing essential would change except certain >>>>>> clarifications. Is this new feature so badly needed for YANG 1.0? >>>>> I think it is part of the resolution of an issue that kept us from >>>>> moving forward for quite a while. Again, if you know some other >>>>> solution, please tell us what it is. Concrete text appreciated. >>>> Solution to exactly what? I don't know what the pressing issue is. >>>> >>>> On the other hand, Andy is right that this system-creatable introduces a >>>> new phase of configuration life cycle (pre- and post-system-create) and >>>> new way of fiddling with the configuration infoset besides defaults. >>>> This shouldn't be taken so lightly, especially two weeks before I-D >>>> submission deadline and past WG deadline. >>>> >>>> Lada >>>> >>>> >>>> Lada >>>> >>>>> /js >>>>> > > > From andy@netconfcentral.com Mon Oct 12 16:21: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 8A80C3A6918 for ; Mon, 12 Oct 2009 16:21: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=[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 ibcgRjSZULQw for ; Mon, 12 Oct 2009 16:21:30 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id BF8ED3A677E for ; Mon, 12 Oct 2009 16:21:30 -0700 (PDT) Received: (qmail 59839 invoked from network); 12 Oct 2009 23:21:30 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 12 Oct 2009 23:21:29 -0000 X-YMail-OSG: 6waLE2wVM1lXFot_GJ9zHh1_suivB1srqebfK8N4YX4VAwsHjSSlCmMipRmRXEFBUG9lNJaBi25M.jTB752PhXj0b9rIFvVUYcNixwYg6oXUqPeuOd8lk40OCCzot51Pnl_22bNkX_yyyT38sKb5k3lYQv1ZLgcOn4FenayY14VZJrCvEoAD.PH1zdWfOQPRmb1annADEnivburG48RjiUxK.e9Yts4cKsAZ3klKfqYuHOuYDSqaa2Qm1tNkk8qzvY0VSOFeBb7JmytNexsksny.6YJ1pGubKyLMc9sZfkv6A2_.awf9_Tzs6U2Xy0Iw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3BA08.9070608@netconfcentral.com> Date: Mon, 12 Oct 2009 16:21:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> In-Reply-To: <4AD3B309.9050505@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 23:21:31 -0000 Joel M. Halpern wrote: > Let us suppose that we allow such rules. > What is the poor user of netconf / netmod supposed to do when he gets an > error? The value producing the error does not even appear in his > configuration. > This is incorrect. If the YANG config-stmt value is 'true', then the node appears in the configuration. > For the unique uid case, one can argue that the system is misbehaving. > But for the mtu example, the user gets an error because the mtu is too > small, but there is no mtu in the configuration. > And, if we allow arbitrary MUST statements referencing system-creatable > objects, then the set of possible confusions is, I think, much larger > than the set of "valuable items" that may be enabled. > > At least, if we decide to allow this, the use of the system-createable > tag provides a hint as to where to look for the problem. Although how > one would look for it is beyond me. > I would not object to this new construct if it worked in an implementation-neutral manner, and did not bring back the server-decides-what-validate-means problems. But this proposal specifies when the system-assigned nodes are created, (but not default nodes for some reason) and that is an implementation issue, not a standards-issue. I prefer to allow the SNMP create-and-wait model for all nodes. The client creates an entry with createAndWait RowStatus and the server will fill in all the defaults. The client can then edit, destroy, or activate the entry. The YANG proposal is that the server MUST NOT let the client know what values it will use for server-assigned nodes. I do not think this is helpful to operators or applications. Note that Lada's addition to the example below is critical. Unix systems usually require a unique UID, and it does not matter if you provided an explicit UID to /usr/sbin/useradd or just took the next available UID. The 'unique' constraint applies to all values, not just explicitly selected values. A validation model that treats server-created nodes as if they do not exist is not useful, or representative of real use-cases. > Yours, > Joel Andy From jmh@joelhalpern.com Mon Oct 12 16:45:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501F83A69B9 for ; Mon, 12 Oct 2009 16:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 vMPNyK9Hsxfs for ; Mon, 12 Oct 2009 16:45:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7A02A3A67A8 for ; Mon, 12 Oct 2009 16:45:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A11E3322C2F9; Mon, 12 Oct 2009 16:45:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id A89CD322C2F4; Mon, 12 Oct 2009 16:45:55 -0700 (PDT) Message-ID: <4AD3BFAE.7030004@joelhalpern.com> Date: Mon, 12 Oct 2009 19:45:50 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@netconfcentral.com> In-Reply-To: <4AD3BA08.9070608@netconfcentral.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2009 23:45:56 -0000 The question is when they (server created nodes) come into existence. Clearly, when the user is doing a put to a non-running config, until they do a commit, they better not see anything except what the config started with, and what they wrote to it. It seems to me that the system should not be dynamically modifying things at that point in the process. So, at that point, the user can not see what values the system will assign to system-creatable nodes. Heck, the system probably does not know until the whole config is there, and you try to commit it. (There is no argument that if one looks in running after the commit, the config true nodes, including the system-creatable ones, have to be there.) Now, the user does a commit. The system has to perform two operations. It must create any system-createable nodes it is going to create, and it must validate the configuration. You seem to be suggesting that if the commit fails, and if the system created any nodes, those system created nodes must now be in the candidate configuration that the user was editing. That seems fairly radical, and an implementation constraint all its own. But those created nodes can not be in running, because the commit failed, so there better be no change to running. So where is the information that the user can look at to tell him about the error? Given that the information appears to be absent, the only conclusion I can come to is that the non-present information MUST NOT cause an error. Hence, there can not be "MUST" statements pointing at it. It may be possible to define things so that one can point must statements at system-createable nodes, but the evaluation can only consider nodes that exist in the candidate configuration, and will exclude any nodes that the system is going to create. But that does not solve the problem you raise, and it is very messy. So I would prefer not to go there. Yours, Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> Let us suppose that we allow such rules. >> What is the poor user of netconf / netmod supposed to do when he gets an >> error? The value producing the error does not even appear in his >> configuration. >> > > This is incorrect. > If the YANG config-stmt value is 'true', > then the node appears in the configuration. > > >> For the unique uid case, one can argue that the system is misbehaving. >> But for the mtu example, the user gets an error because the mtu is too >> small, but there is no mtu in the configuration. >> And, if we allow arbitrary MUST statements referencing system-creatable >> objects, then the set of possible confusions is, I think, much larger >> than the set of "valuable items" that may be enabled. >> >> At least, if we decide to allow this, the use of the system-createable >> tag provides a hint as to where to look for the problem. Although how >> one would look for it is beyond me. >> > > I would not object to this new construct if > it worked in an implementation-neutral manner, and > did not bring back the server-decides-what-validate-means > problems. > > But this proposal specifies when the system-assigned nodes are created, > (but not default nodes for some reason) and that is an implementation issue, > not a standards-issue. > > I prefer to allow the SNMP create-and-wait model for all nodes. > The client creates an entry with createAndWait RowStatus and the server > will fill in all the defaults. The client can then edit, destroy, > or activate the entry. > > The YANG proposal is that the server MUST NOT let the client > know what values it will use for server-assigned nodes. > I do not think this is helpful to operators or applications. > > Note that Lada's addition to the example below is critical. > Unix systems usually require a unique UID, > and it does not matter if you provided an explicit UID > to /usr/sbin/useradd or just took the next available UID. > The 'unique' constraint applies to all values, not just > explicitly selected values. > > A validation model that treats server-created nodes > as if they do not exist is not useful, or representative > of real use-cases. > >> Yours, >> Joel > > Andy > From andy@netconfcentral.com Mon Oct 12 17:06: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 F31E53A689F for ; Mon, 12 Oct 2009 17:06:42 -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 nponXiq0kZzs for ; Mon, 12 Oct 2009 17:06:42 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id E37EC3A67A8 for ; Mon, 12 Oct 2009 17:06:41 -0700 (PDT) Received: (qmail 74183 invoked from network); 13 Oct 2009 00:06:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 13 Oct 2009 00:06:39 -0000 X-YMail-OSG: KOEx1x0VM1mcdS9o7DvxAQ5WhJsgmlH_3QzkIkfji8RJSljYDYQ7ECBn7FvnX7nSd1TTH6RTvpjXXaO5RcoBIbT.Xq0j1aQ5CyNbyQh6tM1kQnTolnOhSlwf0X8VzlQmJHw4229D2gYz4rDvppnZgsNqrlI5AG_JUf6EWSA3ysZoJ41BplunDwO05oyI1AVAXHEOshv.R2PsvTV_3IqHZ4oL7sek7Sct4YED_V4x4h304EArRJPYCAGKgRllDqy_VrnoX4wP8lInAj3y3OkcNKaz04gAvRrKID6weGbsfaDK2_962kIucEk_vmmgDJFzuA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3C49E.1080707@netconfcentral.com> Date: Mon, 12 Oct 2009 17:06:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@netconfcentral.com> <4AD3BFAE.7030004@joelhalpern.com> In-Reply-To: <4AD3BFAE.7030004@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 00:06:43 -0000 Joel M. Halpern wrote: > The question is when they (server created nodes) come into existence. > The current proposal breaks a fundamental property of NETCONF: The operation should work the same whether applied to the candidate database or the running database. The point of the operation is to find out in advance whether a will work or not. If and work on different conceptual databases, then is useless. Andy > Clearly, when the user is doing a put to a non-running config, until > they do a commit, they better not see anything except what the config > started with, and what they wrote to it. It seems to me that the system > should not be dynamically modifying things at that point in the process. > > So, at that point, the user can not see what values the system will > assign to system-creatable nodes. Heck, the system probably does not > know until the whole config is there, and you try to commit it. > > (There is no argument that if one looks in running after the commit, the > config true nodes, including the system-creatable ones, have to be there.) > > Now, the user does a commit. > The system has to perform two operations. It must create any > system-createable nodes it is going to create, and it must validate the > configuration. > You seem to be suggesting that if the commit fails, and if the system > created any nodes, those system created nodes must now be in the > candidate configuration that the user was editing. That seems fairly > radical, and an implementation constraint all its own. > But those created nodes can not be in running, because the commit > failed, so there better be no change to running. > > So where is the information that the user can look at to tell him about > the error? Given that the information appears to be absent, the only > conclusion I can come to is that the non-present information MUST NOT > cause an error. Hence, there can not be "MUST" statements pointing at it. > > It may be possible to define things so that one can point must > statements at system-createable nodes, but the evaluation can only > consider nodes that exist in the candidate configuration, and will > exclude any nodes that the system is going to create. But that does not > solve the problem you raise, and it is very messy. So I would prefer > not to go there. > > Yours, > Joel > > > Andy Bierman wrote: >> Joel M. Halpern wrote: >>> Let us suppose that we allow such rules. >>> What is the poor user of netconf / netmod supposed to do when he gets an >>> error? The value producing the error does not even appear in his >>> configuration. >>> >> >> This is incorrect. >> If the YANG config-stmt value is 'true', >> then the node appears in the configuration. >> >> >>> For the unique uid case, one can argue that the system is misbehaving. >>> But for the mtu example, the user gets an error because the mtu is too >>> small, but there is no mtu in the configuration. >>> And, if we allow arbitrary MUST statements referencing system-creatable >>> objects, then the set of possible confusions is, I think, much larger >>> than the set of "valuable items" that may be enabled. >>> >>> At least, if we decide to allow this, the use of the system-createable >>> tag provides a hint as to where to look for the problem. Although how >>> one would look for it is beyond me. >>> >> >> I would not object to this new construct if >> it worked in an implementation-neutral manner, and >> did not bring back the server-decides-what-validate-means >> problems. >> >> But this proposal specifies when the system-assigned nodes are created, >> (but not default nodes for some reason) and that is an implementation >> issue, >> not a standards-issue. >> >> I prefer to allow the SNMP create-and-wait model for all nodes. >> The client creates an entry with createAndWait RowStatus and the server >> will fill in all the defaults. The client can then edit, destroy, >> or activate the entry. >> >> The YANG proposal is that the server MUST NOT let the client >> know what values it will use for server-assigned nodes. >> I do not think this is helpful to operators or applications. >> >> Note that Lada's addition to the example below is critical. >> Unix systems usually require a unique UID, >> and it does not matter if you provided an explicit UID >> to /usr/sbin/useradd or just took the next available UID. >> The 'unique' constraint applies to all values, not just >> explicitly selected values. >> >> A validation model that treats server-created nodes >> as if they do not exist is not useful, or representative >> of real use-cases. >> >>> Yours, >>> Joel >> >> Andy >> > From jmh@joelhalpern.com Mon Oct 12 18:30: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 47F9D3A67FB for ; Mon, 12 Oct 2009 18:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.372, 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 HLHSyqHj-V3V for ; Mon, 12 Oct 2009 18:30:19 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 14F183A67F3 for ; Mon, 12 Oct 2009 18:30:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2A2C332317A7; Mon, 12 Oct 2009 18:30:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 20FA73228088; Mon, 12 Oct 2009 18:30:19 -0700 (PDT) Message-ID: <4AD3D826.3010800@joelhalpern.com> Date: Mon, 12 Oct 2009 21:30:14 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@netconfcentral.com> <4AD3BFAE.7030004@joelhalpern.com> <4AD3C49E.1080707@netconfcentral.com> In-Reply-To: <4AD3C49E.1080707@netconfcentral.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 01:30:20 -0000 Actually, as far as I cna tell, the current proposal preserves that exact property. If instead we insist that system-created nodes have to get instantiated before validation during a commit, then will give different answers than . There are alternatives. We can pretend that there are no system-createable nodes. That is counter-factual, but we could try it. We could insist that and both must cause all system-creatable nodes to be created in the candidate. This has multiple negative consequences. THe simplest problem is that those nodes are now present, so if the user adjusts other values that would change the system created values, those changes will not have their proper side-effects, since the system has created the createables already. We can ignore the issue and pretend that what we had before was consist and met your stated rule, when it didn't. Or we can stick with the rule that actually meets your statement, which is the one that Martin wrote. Yours, Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> The question is when they (server created nodes) come into existence. >> > > The current proposal breaks a fundamental property of NETCONF: > > The operation should work the same > whether applied to the candidate database or the running database. > > The point of the operation is to find out in > advance whether a will work or not. If > and work on different conceptual databases, then > is useless. > > > Andy > > > > >> Clearly, when the user is doing a put to a non-running config, until >> they do a commit, they better not see anything except what the config >> started with, and what they wrote to it. It seems to me that the system >> should not be dynamically modifying things at that point in the process. >> >> So, at that point, the user can not see what values the system will >> assign to system-creatable nodes. Heck, the system probably does not >> know until the whole config is there, and you try to commit it. >> >> (There is no argument that if one looks in running after the commit, the >> config true nodes, including the system-creatable ones, have to be there.) >> >> Now, the user does a commit. >> The system has to perform two operations. It must create any >> system-createable nodes it is going to create, and it must validate the >> configuration. >> You seem to be suggesting that if the commit fails, and if the system >> created any nodes, those system created nodes must now be in the >> candidate configuration that the user was editing. That seems fairly >> radical, and an implementation constraint all its own. >> But those created nodes can not be in running, because the commit >> failed, so there better be no change to running. >> >> So where is the information that the user can look at to tell him about >> the error? Given that the information appears to be absent, the only >> conclusion I can come to is that the non-present information MUST NOT >> cause an error. Hence, there can not be "MUST" statements pointing at it. >> >> It may be possible to define things so that one can point must >> statements at system-createable nodes, but the evaluation can only >> consider nodes that exist in the candidate configuration, and will >> exclude any nodes that the system is going to create. But that does not >> solve the problem you raise, and it is very messy. So I would prefer >> not to go there. >> >> Yours, >> Joel >> >> >> Andy Bierman wrote: >>> Joel M. Halpern wrote: >>>> Let us suppose that we allow such rules. >>>> What is the poor user of netconf / netmod supposed to do when he gets an >>>> error? The value producing the error does not even appear in his >>>> configuration. >>>> >>> This is incorrect. >>> If the YANG config-stmt value is 'true', >>> then the node appears in the configuration. >>> >>> >>>> For the unique uid case, one can argue that the system is misbehaving. >>>> But for the mtu example, the user gets an error because the mtu is too >>>> small, but there is no mtu in the configuration. >>>> And, if we allow arbitrary MUST statements referencing system-creatable >>>> objects, then the set of possible confusions is, I think, much larger >>>> than the set of "valuable items" that may be enabled. >>>> >>>> At least, if we decide to allow this, the use of the system-createable >>>> tag provides a hint as to where to look for the problem. Although how >>>> one would look for it is beyond me. >>>> >>> I would not object to this new construct if >>> it worked in an implementation-neutral manner, and >>> did not bring back the server-decides-what-validate-means >>> problems. >>> >>> But this proposal specifies when the system-assigned nodes are created, >>> (but not default nodes for some reason) and that is an implementation >>> issue, >>> not a standards-issue. >>> >>> I prefer to allow the SNMP create-and-wait model for all nodes. >>> The client creates an entry with createAndWait RowStatus and the server >>> will fill in all the defaults. The client can then edit, destroy, >>> or activate the entry. >>> >>> The YANG proposal is that the server MUST NOT let the client >>> know what values it will use for server-assigned nodes. >>> I do not think this is helpful to operators or applications. >>> >>> Note that Lada's addition to the example below is critical. >>> Unix systems usually require a unique UID, >>> and it does not matter if you provided an explicit UID >>> to /usr/sbin/useradd or just took the next available UID. >>> The 'unique' constraint applies to all values, not just >>> explicitly selected values. >>> >>> A validation model that treats server-created nodes >>> as if they do not exist is not useful, or representative >>> of real use-cases. >>> >>>> Yours, >>>> Joel >>> Andy >>> > > From andy@netconfcentral.com Mon Oct 12 19:35: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 6823B3A68BA for ; Mon, 12 Oct 2009 19:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 I1zSsv7iKRhn for ; Mon, 12 Oct 2009 19:35:03 -0700 (PDT) Received: from n15b.bullet.mail.mud.yahoo.com (n15b.bullet.mail.mud.yahoo.com [68.142.207.236]) by core3.amsl.com (Postfix) with SMTP id 2409A3A6836 for ; Mon, 12 Oct 2009 19:35:03 -0700 (PDT) Received: from [68.142.200.221] by n15.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 02:35:02 -0000 Received: from [68.142.201.247] by t9.bullet.mud.yahoo.com with NNFMP; 13 Oct 2009 02:35:02 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 02:35:02 -0000 X-Yahoo-Newman-Id: 404754.91581.bm@omp408.mail.mud.yahoo.com Received: (qmail 52106 invoked from network); 13 Oct 2009 02:35:02 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 12 Oct 2009 19:35:01 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8KaXSjwVM1keLvldyEtPCWMxt8bpLXs_JRsbHg5MIfUgFXdHytId3jaiAsWC7k6T__A0bmL4tkET06MtPc8uVXqaJJuEleA5rzDA2hOs_X9tSBwk4JAqCmqHF34SR33WffW1Ul7RX_X.6sCn7HmNhq3yziKWmEdI35ZnvkHwX.FokKkTAwDPVILj4AtQJLLUmgY7h1GMh5sQk334hCEIhh2nYW1wj.7hFl4DZ7Kj3nv8MWuzU6gNsmnqC0by5arH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3E6EB.1080302@netconfcentral.com> Date: Mon, 12 Oct 2009 19:33:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@netconfcentral.com> <4AD3BFAE.7030004@joelhalpern.com> <4AD3C49E.1080707@netconfcentral.com> <4AD3D826.3010800@joelhalpern.com> In-Reply-To: <4AD3D826.3010800@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 02:35:04 -0000 Joel M. Halpern wrote: > Actually, as far as I cna tell, the current proposal preserves that > exact property. > If instead we insist that system-created nodes have to get instantiated > before validation during a commit, then will give different > answers than . > MUST NOT give different answers than , except for resource-denied or in-use type of errors. Certainly not different schema validation errors. > There are alternatives. > We can pretend that there are no system-createable nodes. That is > counter-factual, but we could try it. > We could insist that and both must cause all > system-creatable nodes to be created in the candidate. This has > multiple negative consequences. THe simplest problem is that those > nodes are now present, so if the user adjusts other values that would > change the system created values, those changes will not have their > proper side-effects, since the system has created the createables already. > We can ignore the issue and pretend that what we had before was consist > and met your stated rule, when it didn't. > Or we can stick with the rule that actually meets your statement, which > is the one that Martin wrote. > I don't understand 'meets your statement' What Martin wrote does not even allow the client to know what server-created values are going to be used, prior to the commit. The constraints in a YANG module are useless if they only apply to client-provided values. In the conf-call, we agreed the constraints applied to the entire conceptual database. In the YANG document, it clearly states that server-created nodes (which are not the YANG default value) are part of the database. If not, then IMO YANG constraints are useless. They force the operator to set every conceivable leaf manually that may ever be used in a validation rule somehow. IMO that is worthless, and we are better off not standardizing this aspect of a NETCONF database at all. Just like 'with-defaults' capability, we can eventually identify different validation models with a new capability, and let the server declare which one they use. I agree with Lada that this new 'system-creatable' should not be added. IMO, there is no consensus on one implementation strategy, or one concept of validation, mandatory, default, or when/if a data node instance even exists. > Yours, > Joel > Andy > > Andy Bierman wrote: >> Joel M. Halpern wrote: >>> The question is when they (server created nodes) come into existence. >>> >> >> The current proposal breaks a fundamental property of NETCONF: >> >> The operation should work the same >> whether applied to the candidate database or the running database. >> >> The point of the operation is to find out in >> advance whether a will work or not. If >> and work on different conceptual databases, then >> is useless. >> >> >> Andy >> >> >> >> >>> Clearly, when the user is doing a put to a non-running config, until >>> they do a commit, they better not see anything except what the config >>> started with, and what they wrote to it. It seems to me that the system >>> should not be dynamically modifying things at that point in the process. >>> >>> So, at that point, the user can not see what values the system will >>> assign to system-creatable nodes. Heck, the system probably does not >>> know until the whole config is there, and you try to commit it. >>> >>> (There is no argument that if one looks in running after the commit, the >>> config true nodes, including the system-creatable ones, have to be >>> there.) >>> >>> Now, the user does a commit. >>> The system has to perform two operations. It must create any >>> system-createable nodes it is going to create, and it must validate the >>> configuration. >>> You seem to be suggesting that if the commit fails, and if the system >>> created any nodes, those system created nodes must now be in the >>> candidate configuration that the user was editing. That seems fairly >>> radical, and an implementation constraint all its own. >>> But those created nodes can not be in running, because the commit >>> failed, so there better be no change to running. >>> >>> So where is the information that the user can look at to tell him about >>> the error? Given that the information appears to be absent, the only >>> conclusion I can come to is that the non-present information MUST NOT >>> cause an error. Hence, there can not be "MUST" statements pointing >>> at it. >>> >>> It may be possible to define things so that one can point must >>> statements at system-createable nodes, but the evaluation can only >>> consider nodes that exist in the candidate configuration, and will >>> exclude any nodes that the system is going to create. But that does not >>> solve the problem you raise, and it is very messy. So I would prefer >>> not to go there. >>> >>> Yours, >>> Joel >>> >>> >>> Andy Bierman wrote: >>>> Joel M. Halpern wrote: >>>>> Let us suppose that we allow such rules. >>>>> What is the poor user of netconf / netmod supposed to do when he >>>>> gets an >>>>> error? The value producing the error does not even appear in his >>>>> configuration. >>>>> >>>> This is incorrect. >>>> If the YANG config-stmt value is 'true', >>>> then the node appears in the configuration. >>>> >>>> >>>>> For the unique uid case, one can argue that the system is misbehaving. >>>>> But for the mtu example, the user gets an error because the mtu is too >>>>> small, but there is no mtu in the configuration. >>>>> And, if we allow arbitrary MUST statements referencing >>>>> system-creatable >>>>> objects, then the set of possible confusions is, I think, much larger >>>>> than the set of "valuable items" that may be enabled. >>>>> >>>>> At least, if we decide to allow this, the use of the system-createable >>>>> tag provides a hint as to where to look for the problem. Although how >>>>> one would look for it is beyond me. >>>>> >>>> I would not object to this new construct if >>>> it worked in an implementation-neutral manner, and >>>> did not bring back the server-decides-what-validate-means >>>> problems. >>>> >>>> But this proposal specifies when the system-assigned nodes are created, >>>> (but not default nodes for some reason) and that is an implementation >>>> issue, >>>> not a standards-issue. >>>> >>>> I prefer to allow the SNMP create-and-wait model for all nodes. >>>> The client creates an entry with createAndWait RowStatus and the server >>>> will fill in all the defaults. The client can then edit, destroy, >>>> or activate the entry. >>>> >>>> The YANG proposal is that the server MUST NOT let the client >>>> know what values it will use for server-assigned nodes. >>>> I do not think this is helpful to operators or applications. >>>> >>>> Note that Lada's addition to the example below is critical. >>>> Unix systems usually require a unique UID, >>>> and it does not matter if you provided an explicit UID >>>> to /usr/sbin/useradd or just took the next available UID. >>>> The 'unique' constraint applies to all values, not just >>>> explicitly selected values. >>>> >>>> A validation model that treats server-created nodes >>>> as if they do not exist is not useful, or representative >>>> of real use-cases. >>>> >>>>> Yours, >>>>> Joel >>>> Andy >>>> >> >> > From jmh@joelhalpern.com Mon Oct 12 19:48: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 0EB5E28C129 for ; Mon, 12 Oct 2009 19:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 s7oRBs0r4Qoz for ; Mon, 12 Oct 2009 19:48:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CBE3028C107 for ; Mon, 12 Oct 2009 19:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 22FD33231747; Mon, 12 Oct 2009 19:48:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id CC06C32280EC; Mon, 12 Oct 2009 19:48:53 -0700 (PDT) Message-ID: <4AD3EA90.8050502@joelhalpern.com> Date: Mon, 12 Oct 2009 22:48:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <1255372853.7813.66.camel@missotis> <20091012184535.GA18744@elstar.local> <1255378873.7813.152.camel@missotis> <4AD391DB.5030707@joelhalpern.com> <1255381322.7813.180.camel@missotis> <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@netconfcentral.com> <4AD3BFAE.7030004@joelhalpern.com> <4AD3C49E.1080707@netconfcentral.com> <4AD3D826.3010800@joelhalpern.com> <4AD3E6EB.1080302@netconfcentral.com> In-Reply-To: <4AD3E6EB.1080302@netconfcentral.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 02:48:55 -0000 So, assume that we don't do system-createable. Assume that we allow, as that would leave us, must expression pointing at optional nodes that the system may decide to fill in. Yes, those filled in nodes will appear in running, if the commit succeeds. Yes, the values to be used are part of the conceptual database, which the must expressions can reference, given that we currently allow that. But that does not mean that those nodes are created in candidate. In fact, in the case of a failing commit it may not be possible to create all of the nodes. The problem may well evince itself as the inability to determine what some node should be set to (since even if the must expressions are consistent across teh configured values, it is still perfectly possible that the combination of musts, configured values, and system created values, creates an inconsistency for a must. It oughtn't but I can not tell a modeller how to write things to guarantee it can not happen.) And the current document certainly does not specify that system create values that would be created during commit need to be back-filled into candidate. So how, under the current setup, would a user diagnose a problem caused by a must inconsistency between his configured values and a system-created value? The system-created statement did not create the problem. I agree with you about what the constraints ought to be. But to meet those constraints requires either outlawing system creation, or making sure that must statements do not reference system-created values. Yours, Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> Actually, as far as I cna tell, the current proposal preserves that >> exact property. >> If instead we insist that system-created nodes have to get instantiated >> before validation during a commit, then will give different >> answers than . >> > > MUST NOT give different answers than , > except for resource-denied or in-use type of errors. > Certainly not different schema validation errors. > > >> There are alternatives. >> We can pretend that there are no system-createable nodes. That is >> counter-factual, but we could try it. >> We could insist that and both must cause all >> system-creatable nodes to be created in the candidate. This has >> multiple negative consequences. THe simplest problem is that those >> nodes are now present, so if the user adjusts other values that would >> change the system created values, those changes will not have their >> proper side-effects, since the system has created the createables already. >> We can ignore the issue and pretend that what we had before was consist >> and met your stated rule, when it didn't. >> Or we can stick with the rule that actually meets your statement, which >> is the one that Martin wrote. >> > > I don't understand 'meets your statement' > > What Martin wrote does not even allow the client to know > what server-created values are going to be used, prior to > the commit. > > The constraints in a YANG module are useless if they only > apply to client-provided values. In the conf-call, we agreed > the constraints applied to the entire conceptual database. > In the YANG document, it clearly states that server-created > nodes (which are not the YANG default value) are part of the database. > > If not, then IMO YANG constraints are useless. > They force the operator to set every conceivable leaf > manually that may ever be used in a validation rule somehow. > IMO that is worthless, and we are better off not standardizing > this aspect of a NETCONF database at all. > > Just like 'with-defaults' capability, we can eventually identify different > validation models with a new capability, and let the server declare > which one they use. > > I agree with Lada that this new 'system-creatable' should not > be added. IMO, there is no consensus on one implementation strategy, > or one concept of validation, mandatory, default, or when/if > a data node instance even exists. > > >> Yours, >> Joel >> > > Andy > >> Andy Bierman wrote: >>> Joel M. Halpern wrote: >>>> The question is when they (server created nodes) come into existence. >>>> >>> The current proposal breaks a fundamental property of NETCONF: >>> >>> The operation should work the same >>> whether applied to the candidate database or the running database. >>> >>> The point of the operation is to find out in >>> advance whether a will work or not. If >>> and work on different conceptual databases, then >>> is useless. >>> >>> >>> Andy >>> >>> >>> >>> >>>> Clearly, when the user is doing a put to a non-running config, until >>>> they do a commit, they better not see anything except what the config >>>> started with, and what they wrote to it. It seems to me that the system >>>> should not be dynamically modifying things at that point in the process. >>>> >>>> So, at that point, the user can not see what values the system will >>>> assign to system-creatable nodes. Heck, the system probably does not >>>> know until the whole config is there, and you try to commit it. >>>> >>>> (There is no argument that if one looks in running after the commit, the >>>> config true nodes, including the system-creatable ones, have to be >>>> there.) >>>> >>>> Now, the user does a commit. >>>> The system has to perform two operations. It must create any >>>> system-createable nodes it is going to create, and it must validate the >>>> configuration. >>>> You seem to be suggesting that if the commit fails, and if the system >>>> created any nodes, those system created nodes must now be in the >>>> candidate configuration that the user was editing. That seems fairly >>>> radical, and an implementation constraint all its own. >>>> But those created nodes can not be in running, because the commit >>>> failed, so there better be no change to running. >>>> >>>> So where is the information that the user can look at to tell him about >>>> the error? Given that the information appears to be absent, the only >>>> conclusion I can come to is that the non-present information MUST NOT >>>> cause an error. Hence, there can not be "MUST" statements pointing >>>> at it. >>>> >>>> It may be possible to define things so that one can point must >>>> statements at system-createable nodes, but the evaluation can only >>>> consider nodes that exist in the candidate configuration, and will >>>> exclude any nodes that the system is going to create. But that does not >>>> solve the problem you raise, and it is very messy. So I would prefer >>>> not to go there. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> Andy Bierman wrote: >>>>> Joel M. Halpern wrote: >>>>>> Let us suppose that we allow such rules. >>>>>> What is the poor user of netconf / netmod supposed to do when he >>>>>> gets an >>>>>> error? The value producing the error does not even appear in his >>>>>> configuration. >>>>>> >>>>> This is incorrect. >>>>> If the YANG config-stmt value is 'true', >>>>> then the node appears in the configuration. >>>>> >>>>> >>>>>> For the unique uid case, one can argue that the system is misbehaving. >>>>>> But for the mtu example, the user gets an error because the mtu is too >>>>>> small, but there is no mtu in the configuration. >>>>>> And, if we allow arbitrary MUST statements referencing >>>>>> system-creatable >>>>>> objects, then the set of possible confusions is, I think, much larger >>>>>> than the set of "valuable items" that may be enabled. >>>>>> >>>>>> At least, if we decide to allow this, the use of the system-createable >>>>>> tag provides a hint as to where to look for the problem. Although how >>>>>> one would look for it is beyond me. >>>>>> >>>>> I would not object to this new construct if >>>>> it worked in an implementation-neutral manner, and >>>>> did not bring back the server-decides-what-validate-means >>>>> problems. >>>>> >>>>> But this proposal specifies when the system-assigned nodes are created, >>>>> (but not default nodes for some reason) and that is an implementation >>>>> issue, >>>>> not a standards-issue. >>>>> >>>>> I prefer to allow the SNMP create-and-wait model for all nodes. >>>>> The client creates an entry with createAndWait RowStatus and the server >>>>> will fill in all the defaults. The client can then edit, destroy, >>>>> or activate the entry. >>>>> >>>>> The YANG proposal is that the server MUST NOT let the client >>>>> know what values it will use for server-assigned nodes. >>>>> I do not think this is helpful to operators or applications. >>>>> >>>>> Note that Lada's addition to the example below is critical. >>>>> Unix systems usually require a unique UID, >>>>> and it does not matter if you provided an explicit UID >>>>> to /usr/sbin/useradd or just took the next available UID. >>>>> The 'unique' constraint applies to all values, not just >>>>> explicitly selected values. >>>>> >>>>> A validation model that treats server-created nodes >>>>> as if they do not exist is not useful, or representative >>>>> of real use-cases. >>>>> >>>>>> Yours, >>>>>> Joel >>>>> Andy >>>>> >>> > > > From andy@netconfcentral.com Mon Oct 12 19: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 68FDA3A698B for ; Mon, 12 Oct 2009 19:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 OEddZCqLxKfN for ; Mon, 12 Oct 2009 19:56:52 -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 B130D3A68D1 for ; Mon, 12 Oct 2009 19:56:52 -0700 (PDT) Received: (qmail 6181 invoked from network); 13 Oct 2009 02:56:51 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 12 Oct 2009 19:56:51 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ffsVFdkVM1lLDUp.DpHdOxyBDpgt4Lt.Ooxk4C9kM7xi3xcLaTwdGx2YjNxIkM0xcenGgUvm62Y5KIMFawtxiCE0y81VbyydCDr.BRd97Lxv2oeUotHcRJdHnbX2U12MqbP3c.9HxzXG7xeNw8awykobdpkupW4yBifgM6JqU2DGuCf8uIqr1IJDxLvUSr6ZR_FVUO.cWyJ6hUpQitOdMyB2Vld.I1o89idiW9LEkNZdxsvN3MSFQpqRTIqYPL8Z X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3EC82.9010109@netconfcentral.com> Date: Mon, 12 Oct 2009 19:57:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> In-Reply-To: <20091012183216.GA18631@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 02:56:53 -0000 Juergen Schoenwaelder wrote: > On Mon, Oct 12, 2009 at 08:29:09PM +0200, Ladislav Lhotka wrote: >> Martin Bjorklund p????e v Po 12. 10. 2009 v 18:33 +0200: >>> Hi, >>> >>> Here is proposed text for a new statement "system-creatable" >>> (a.k.a. "assigned-by system"). >> Didn't the WG agree on feature freeze in Stockholm? Also, I thought the >> conference call was intended to close up the issues around mandatory, >> default etc. but this has the potential to open the can of worms again. >> So I don't agree with this addition. > > So can you please tell us how to close the issue without any addition > or change? Make a concrete proposal please. > Using our favorite example, the unix users table: the authoritative source for validation is /etc/passwd, which is really operational data, ince it is rarely edited directly by humans. The UID field does not record whether it was auto-selected or sysadmin-selected. That is irrelevant to the uniqueness test. I do not think there is consensus on 1 implementation approach, and this work is too new and experimental to assume that the WG knows for sure. It is possible for an implementation to make all the server-created nodes visible in the candidate and running config, and still remember that they were server-created. That is just an implementation detail. IMO it is useful to know what the server-created values are going to be, by examining the candidate. One should not be forbidden by the standard from implementing this feature. There is no rule or text in YANG that says how a server applies nodes from candidate to running, or how they are saved in NV-storage. Hopefully the server skips all non-changes, but maybe not. Again, this is just an implementation detail. I agree with Lada that we were better off with the ambiguous mandatory-stmt, rather than the changes to the validation model that are being proposed. > Thanks, > > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Oct 12 22:25: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 09FCC3A68A2 for ; Mon, 12 Oct 2009 22:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 cJ72A+8Zw66C for ; Mon, 12 Oct 2009 22:25:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 05A533A6890 for ; Mon, 12 Oct 2009 22:25:49 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1D7BC0016; Tue, 13 Oct 2009 07:25:49 +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 dLvqNrCJocIC; Tue, 13 Oct 2009 07:25:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EA84C0014; Tue, 13 Oct 2009 07:25:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E8B58D1BF09; Tue, 13 Oct 2009 07:25:47 +0200 (CEST) Date: Tue, 13 Oct 2009 07:25:47 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091013052547.GA19453@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <4AD3EC82.9010109@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD3EC82.9010109@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable 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, 13 Oct 2009 05:25:50 -0000 On Tue, Oct 13, 2009 at 04:57:06AM +0200, Andy Bierman wrote: > Using our favorite example, the unix users table: > the authoritative source for validation is /etc/passwd, > which is really operational data, ince it is rarely > edited directly by humans. Is this an attempt to come up with a new definition of operational state data? If yes, I disagree with it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Oct 13 00:26: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 98FF73A68B8 for ; Tue, 13 Oct 2009 00:26:05 -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 bkLZ0cy8cncM for ; Tue, 13 Oct 2009 00:26:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B89983A687A for ; Tue, 13 Oct 2009 00:26:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 01BEC61602B; Tue, 13 Oct 2009 09:26:04 +0200 (CEST) Date: Tue, 13 Oct 2009 09:26:04 +0200 (CEST) Message-Id: <20091013.092604.204471625.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AD3BA08.9070608@netconfcentral.com> References: <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 07:26:05 -0000 Andy Bierman wrote: > I would not object to this new construct if > it worked in an implementation-neutral manner, and > did not bring back the server-decides-what-validate-means > problems. > > But this proposal specifies when the system-assigned nodes are created, Yes it does, otherwise it cannot be implementation-neutral, which you also want it to be. If we don't specify when and under which circumstances s-c nodes are created by the server, different implementations will behave differently. And this was the problem with the old text, without s-c. We agreed that adding a s-c statement would make it clear that the server cannot spontaneously create nodes as it wants to. With this statement, the client knows what to expect from a server. /martin From andy@netconfcentral.com Tue Oct 13 01:41: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 A761B28C14A for ; Tue, 13 Oct 2009 01:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 2NNiJhHWdyPM for ; Tue, 13 Oct 2009 01:41:46 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id D61153A68BF for ; Tue, 13 Oct 2009 01:41:45 -0700 (PDT) Received: from [209.191.108.97] by n19.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 08:41:45 -0000 Received: from [68.142.201.72] by t4.bullet.mud.yahoo.com with NNFMP; 13 Oct 2009 08:41:45 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 08:41:45 -0000 X-Yahoo-Newman-Id: 45946.10407.bm@omp424.mail.mud.yahoo.com Received: (qmail 9829 invoked from network); 13 Oct 2009 08:41:44 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 13 Oct 2009 01:41:44 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: S5sgfI8VM1n6hlw9JGkSFSVyXvCC5TC.CEfHqaYFou47BipFpvpkuOX4hWIAHdhAKJvdmhHPh46VBUTDjuVdfqiB0R_c1x6745lRfMUzQiaoF91HIX0bAGh1SiKeT7s9i_QQI.4hgYcB9xPBHRJhHsiRmEMesEmn7aQdPeEqCadquh2P3HAKJTNBABW3yGPBrmeHfe1qXo3rRsAPdYVjBHyuP0TqpNZkIkTuEztnmrOcYZdCiTC8eVi.gT8X1fDGRhou04Xp5PgHmXG9S3ZS3K7Z0CpNlseTj40X5rNXQBSdK7lO5xl_iwOkNWPJPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD43D59.2010609@netconfcentral.com> Date: Tue, 13 Oct 2009 01:42:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AD3AC71.1080601@netconfcentral.com> <4AD3B309.9050505@joelhalpern.com> <4AD3BA08.9070608@netconfcentral.com> <20091013.092604.204471625.mbj@tail-f.com> In-Reply-To: <20091013.092604.204471625.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 08:41:48 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I would not object to this new construct if >> it worked in an implementation-neutral manner, and >> did not bring back the server-decides-what-validate-means >> problems. >> >> But this proposal specifies when the system-assigned nodes are created, > > Yes it does, otherwise it cannot be implementation-neutral, which you > also want it to be. If we don't specify when and under which > circumstances s-c nodes are created by the server, different > implementations will behave differently. And this was the problem > with the old text, without s-c. We agreed that adding a s-c statement > would make it clear that the server cannot spontaneously create nodes > as it wants to. With this statement, the client knows what to expect > from a server. > The validation model you propose does not support very many use cases. You are trying to claim that a system-creatable MUST be unknown until commit-time, and that is simply false. The server created value may be algorithmic, and not a dynamic default based on config-time state data at all. That is 1 possibility out of many. A server implementation may have callback code that allows instrumentation several chances to instantiate a config=true node. There is no value in forcing the server to wait as long as possible before revealing that choice (if any). At the end of the day, you are trying to claim that if the server sets the node it is not config, but if the client sets it, it is config. I don't agree with that. The current YANG spec does not agree with that. If config=true, then it is config, whether you like it or not. A server-created config=true node that the client is not allowed to see, and is outside the validation model, is broken. It should not be part of the standard. > > /martin > Andy From mbj@tail-f.com Tue Oct 13 02:05: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 37C4D3A681C for ; Tue, 13 Oct 2009 02:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=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 h0AtBJI1UMMG for ; Tue, 13 Oct 2009 02:05: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 20DFB3A67F1 for ; Tue, 13 Oct 2009 02:05: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 58A3061602E; Tue, 13 Oct 2009 11:05:39 +0200 (CEST) Date: Tue, 13 Oct 2009 11:05:38 +0200 (CEST) Message-Id: <20091013.110538.229555144.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AD43D59.2010609@netconfcentral.com> References: <4AD3BA08.9070608@netconfcentral.com> <20091013.092604.204471625.mbj@tail-f.com> <4AD43D59.2010609@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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 09:05:40 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I would not object to this new construct if > >> it worked in an implementation-neutral manner, and > >> did not bring back the server-decides-what-validate-means > >> problems. > >> > >> But this proposal specifies when the system-assigned nodes are created, > > > > Yes it does, otherwise it cannot be implementation-neutral, which you > > also want it to be. If we don't specify when and under which > > circumstances s-c nodes are created by the server, different > > implementations will behave differently. And this was the problem > > with the old text, without s-c. We agreed that adding a s-c statement > > would make it clear that the server cannot spontaneously create nodes > > as it wants to. With this statement, the client knows what to expect > > from a server. > > > > The validation model you propose does not support > very many use cases. > > You are trying to claim that a system-creatable MUST be > unknown until commit-time, and that is simply false. No, I'm not claiming that. > The server created value may be algorithmic, and > not a dynamic default based on config-time state data at all. Of course. I don't care how or when the server decides *what* to put in a s-c leaf. I do care that it is clear *when* it puts it there. > That is 1 possibility out of many. Yes, but I don't think we should over-specify this statement. We don't need 10 flavors of system-createable. I think we agreed that it will be used in rare occasions. The most important problem this statement solves is that it becomes clear when a server is allowed to create config nodes. > A server implementation may have callback code that allows > instrumentation several chances to instantiate a config=true > node. There is no value in forcing the server to wait > as long as possible before revealing that choice (if any). As Joel explained, there is value in this - the client can do off-line validation before it sends data to the server. If it needs server-created data to do its validation, it can never validate it before sending it. Yes, this statement limits what a server is allowed to do, but that was the whole purpose of adding it! With the current text, interoperability would suffer precisely because it was not clear if/when/how servers could create config data. > At the end of the day, you are trying to claim that if > the server sets the node it is not config, but if the > client sets it, it is config. Absolutely not!! I have never said or stated that. /martin From lhotka@cesnet.cz Tue Oct 13 02:48: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 ECDD63A6774 for ; Tue, 13 Oct 2009 02:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.237 X-Spam-Level: X-Spam-Status: No, score=0.237 tagged_above=-999 required=5 tests=[AWL=-0.372, 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 Cy2T2wMrb9D8 for ; Tue, 13 Oct 2009 02:48:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4194628C140 for ; Tue, 13 Oct 2009 02:48:01 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A4024D800C1; Tue, 13 Oct 2009 11:47:57 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4AD3EC82.9010109@netconfcentral.com> References: <20091012.183346.123577726.mbj@tail-f.com> <1255372149.7813.58.camel@missotis> <20091012183216.GA18631@elstar.local> <4AD3EC82.9010109@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 13 Oct 2009 11:47:55 +0200 Message-Id: <1255427275.7488.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 09:48:29 -0000 Andy Bierman píše v Po 12. 10. 2009 v 19:57 -0700: > I agree with Lada that we were better off > with the ambiguous mandatory-stmt, rather > than the changes to the validation model that > are being proposed. > Actually, the important information that the "uid" leaf is mandatory (meaning that the system needs it for proper operation) is lost in leaf uid { type uint32; system-creatable true; } If "uid" is not provided by the client when a new user is being created, the server MAY create the instance - or MAY NOT, which results in an error. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Oct 13 03:42: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 328553A682D for ; Tue, 13 Oct 2009 03:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_20=-0.74, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 0AiA2b-NfAk6 for ; Tue, 13 Oct 2009 03:42:27 -0700 (PDT) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id 2050E3A67E6 for ; Tue, 13 Oct 2009 03:42:27 -0700 (PDT) Received: from [68.142.200.225] by n13.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 10:42:26 -0000 Received: from [68.142.201.245] by t6.bullet.mud.yahoo.com with NNFMP; 13 Oct 2009 10:42:26 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 10:42:26 -0000 X-Yahoo-Newman-Id: 340924.10646.bm@omp406.mail.mud.yahoo.com Received: (qmail 73445 invoked from network); 13 Oct 2009 10:42:25 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 13 Oct 2009 03:42:25 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: TULcpR4VM1nhTPCBQ3pJNtd2mIl2YAfT_prVHr9_pT3BrpnplOgp4QavBUAIog.nS4ZF8TZ.cjp9jNFDlIIga8J_9J.f.OZ7c2duYU_ASpG5exC58bLt5xW2JglAww5vHassAwClgwa40DBMQObcYwKZm0pdpvzeZ9aSv4H6CesSBWG9P2mxCcunJ.gXVFHqtkM2GJE_j6A3ShH.JfDS0J4YJ0LhWpsaf8HEjeHgtF1RbUGxLviX5Dm87DoCBNZesNtr2Zi_LrbvKMxk_cL_N3a3Q4JVFLMpIg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD459A2.5030503@netconfcentral.com> Date: Tue, 13 Oct 2009 03:42:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AD3BA08.9070608@netconfcentral.com> <20091013.092604.204471625.mbj@tail-f.com> <4AD43D59.2010609@netconfcentral.com> <20091013.110538.229555144.mbj@tail-f.com> In-Reply-To: <20091013.110538.229555144.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 10:42:28 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> I would not object to this new construct if >>>> it worked in an implementation-neutral manner, and >>>> did not bring back the server-decides-what-validate-means >>>> problems. >>>> >>>> But this proposal specifies when the system-assigned nodes are created, >>> Yes it does, otherwise it cannot be implementation-neutral, which you >>> also want it to be. If we don't specify when and under which >>> circumstances s-c nodes are created by the server, different >>> implementations will behave differently. And this was the problem >>> with the old text, without s-c. We agreed that adding a s-c statement >>> would make it clear that the server cannot spontaneously create nodes >>> as it wants to. With this statement, the client knows what to expect >>> from a server. >>> >> The validation model you propose does not support >> very many use cases. >> >> You are trying to claim that a system-creatable MUST be >> unknown until commit-time, and that is simply false. > > No, I'm not claiming that. > >> The server created value may be algorithmic, and >> not a dynamic default based on config-time state data at all. > > Of course. > > I don't care how or when the server decides *what* to put in a s-c > leaf. I do care that it is clear *when* it puts it there. > >> That is 1 possibility out of many. > > Yes, but I don't think we should over-specify this statement. We > don't need 10 flavors of system-createable. I think we agreed that it > will be used in rare occasions. The most important problem this > statement solves is that it becomes clear when a server is allowed to > create config nodes. > >> A server implementation may have callback code that allows >> instrumentation several chances to instantiate a config=true >> node. There is no value in forcing the server to wait >> as long as possible before revealing that choice (if any). > > As Joel explained, there is value in this - the client can do off-line > validation before it sends data to the server. If it needs > server-created data to do its validation, it can never validate it > before sending it. > This is flawed logic. The client validation is incomplete and will always be incomplete for dynamic defaults that must be calculated at commit time. This corner-case should not break algorithmic or static (but platform-specific) defaults. These far outnumber the commit-time state data type of defaults anyway. If YANG cannot model the user ID problem correctly, then it should not be part of the standard. Leave it up to vendors to solve this problem over time, and standardize it when a solution that actually works is available. > Yes, this statement limits what a server is allowed to do, but that > was the whole purpose of adding it! With the current text, > interoperability would suffer precisely because it was not clear > if/when/how servers could create config data. > >> At the end of the day, you are trying to claim that if >> the server sets the node it is not config, but if the >> client sets it, it is config. > > Absolutely not!! I have never said or stated that. > The text states that a server-created node is not part of the validation checks, but if the client set the node to the exact same value as the server, then it would be part of the validation checks. That is broken. Your proposal doesn't even work for your favorite use-case -- the user id field. The unique constraint clearly applies to all values in the real world, yet the model doesn't work that way at all. As Lada pointed out, the server MAY create a node, which is not the correct model for this example either. > > /martin > Andy From mbj@tail-f.com Tue Oct 13 03:44: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 C8AE83A6951 for ; Tue, 13 Oct 2009 03:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uduvAz-fy-2F for ; Tue, 13 Oct 2009 03:44:05 -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 0C39C3A6945 for ; Tue, 13 Oct 2009 03:44:05 -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 4657C616029; Tue, 13 Oct 2009 12:38:58 +0200 (CEST) Date: Tue, 13 Oct 2009 12:38:57 +0200 (CEST) Message-Id: <20091013.123857.191014621.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255427275.7488.25.camel@missotis> References: <20091012183216.GA18631@elstar.local> <4AD3EC82.9010109@netconfcentral.com> <1255427275.7488.25.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 10:44:05 -0000 Ladislav Lhotka wrote: > Actually, the important information that the "uid" leaf is mandatory > (meaning that the system needs it for proper operation) is lost in > > leaf uid { > type uint32; > system-creatable true; > } True, but again I don't think we should over-specify this. You can always specify behavior in the description clause. > If "uid" is not provided by the client when a new user is being created, > the server MAY create the instance - or MAY NOT, which results in an > error. If the server didn't create an instance, it probably won't signal an error either :) /martin From lhotka@cesnet.cz Tue Oct 13 04:04: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 B81C23A6923 for ; Tue, 13 Oct 2009 04:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=0.632, 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 QdH6QpjiedM5 for ; Tue, 13 Oct 2009 04:04:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F0C3E3A6A02 for ; Tue, 13 Oct 2009 04:04:26 -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 E119CD80096; Tue, 13 Oct 2009 13:04:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091013.123857.191014621.mbj@tail-f.com> References: <20091012183216.GA18631@elstar.local> <4AD3EC82.9010109@netconfcentral.com> <1255427275.7488.25.camel@missotis> <20091013.123857.191014621.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 13 Oct 2009 13:04:26 +0200 Message-Id: <1255431866.7488.45.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 11:04:27 -0000 Martin Bjorklund píše v Út 13. 10. 2009 v 12:38 +0200: > Ladislav Lhotka wrote: > > Actually, the important information that the "uid" leaf is mandatory > > (meaning that the system needs it for proper operation) is lost in > > > > leaf uid { > > type uint32; > > system-creatable true; > > } > > True, but again I don't think we should over-specify this. You can > always specify behavior in the description clause. Over-specify? Occurrence constraints are essential in all XML schema languages. I could argue in the same way - system-creatable could be specified in the description clause. > > > If "uid" is not provided by the client when a new user is being created, > > the server MAY create the instance - or MAY NOT, which results in an > > error. > > If the server didn't create an instance, it probably won't signal an > error either :) This system-creatable statement adds some new semantics but breaks the existing one. Currently I am able to validate an entire configuration against quite a strict schema and this won't be possible anymore. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Oct 13 04:19: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 4CCD828C13F for ; Tue, 13 Oct 2009 04:19:13 -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 tQeze1a3bpOi for ; Tue, 13 Oct 2009 04:19:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5336F28C12D for ; Tue, 13 Oct 2009 04:19:12 -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 158B661A009; Tue, 13 Oct 2009 13:19:13 +0200 (CEST) Date: Tue, 13 Oct 2009 13:19:12 +0200 (CEST) Message-Id: <20091013.131912.68453972.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255431866.7488.45.camel@missotis> References: <1255427275.7488.25.camel@missotis> <20091013.123857.191014621.mbj@tail-f.com> <1255431866.7488.45.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 11:19:13 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMTMuIDEwLiAyMDA5IHYgMTI6MzggKzAyMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IEFjdHVhbGx5LCB0aGUg aW1wb3J0YW50IGluZm9ybWF0aW9uIHRoYXQgdGhlICJ1aWQiIGxlYWYgaXMgbWFuZGF0b3J5DQo+ ID4gPiAobWVhbmluZyB0aGF0IHRoZSBzeXN0ZW0gbmVlZHMgaXQgZm9yIHByb3BlciBvcGVyYXRp b24pIGlzIGxvc3QgaW4NCj4gPiA+IA0KPiA+ID4gICAgICAgICAgbGVhZiB1aWQgew0KPiA+ID4g ICAgICAgICAgICAgIHR5cGUgdWludDMyOw0KPiA+ID4gICAgICAgICAgICAgIHN5c3RlbS1jcmVh dGFibGUgdHJ1ZTsNCj4gPiA+ICAgICAgICAgIH0NCj4gPiANCj4gPiBUcnVlLCBidXQgYWdhaW4g SSBkb24ndCB0aGluayB3ZSBzaG91bGQgb3Zlci1zcGVjaWZ5IHRoaXMuICBZb3UgY2FuDQo+ID4g YWx3YXlzIHNwZWNpZnkgYmVoYXZpb3IgaW4gdGhlIGRlc2NyaXB0aW9uIGNsYXVzZS4NCj4gDQo+ IE92ZXItc3BlY2lmeT8gT2NjdXJyZW5jZSBjb25zdHJhaW50cyBhcmUgZXNzZW50aWFsIGluIGFs bCBYTUwgc2NoZW1hDQo+IGxhbmd1YWdlcy4gSSBjb3VsZCBhcmd1ZSBpbiB0aGUgc2FtZSB3YXkg LSBzeXN0ZW0tY3JlYXRhYmxlIGNvdWxkIGJlDQo+IHNwZWNpZmllZCBpbiB0aGUgZGVzY3JpcHRp b24gY2xhdXNlLg0KDQpUaGF0J3Mgd2hhdCBJIGFyZ3VlZCBmb3IhICBCdXQgYWZ0ZXIgdGhlIGVu ZGxlc3MgY29uZnVzaW9uIG9uIHRoZQ0KbGlzdCwgdGhlIFdHIGRlY2lkZWQgdGhhdCBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gY2xhcmlmeSB0aGUgaW50ZW5kZWQNCmJlaGF2aW9yIG9mIHNlcnZlciBj cmVhdGVkIG5vZGVzIHdpdGggYSBuZXcgc3RhdGVtZW50IChhbmQgSSBhZ3JlZQ0Kd2l0aCB0aGF0 IGRlY2lzaW9uKS4NCg0KPiA+ID4gSWYgInVpZCIgaXMgbm90IHByb3ZpZGVkIGJ5IHRoZSBjbGll bnQgd2hlbiBhIG5ldyB1c2VyIGlzIGJlaW5nIGNyZWF0ZWQsDQo+ID4gPiB0aGUgc2VydmVyIE1B WSBjcmVhdGUgdGhlIGluc3RhbmNlIC0gb3IgTUFZIE5PVCwgd2hpY2ggcmVzdWx0cyBpbiBhbg0K PiA+ID4gZXJyb3IuDQo+ID4gDQo+ID4gSWYgdGhlIHNlcnZlciBkaWRuJ3QgY3JlYXRlIGFuIGlu c3RhbmNlLCBpdCBwcm9iYWJseSB3b24ndCBzaWduYWwgYW4NCj4gPiBlcnJvciBlaXRoZXIgOikN Cj4gDQo+IFRoaXMgc3lzdGVtLWNyZWF0YWJsZSBzdGF0ZW1lbnQgYWRkcyBzb21lIG5ldyBzZW1h bnRpY3MgYnV0IGJyZWFrcyB0aGUNCj4gZXhpc3Rpbmcgb25lLiBDdXJyZW50bHkgSSBhbSBhYmxl IHRvIHZhbGlkYXRlIGFuIGVudGlyZSBjb25maWd1cmF0aW9uDQo+IGFnYWluc3QgcXVpdGUgYSBz dHJpY3Qgc2NoZW1hIGFuZCB0aGlzIHdvbid0IGJlIHBvc3NpYmxlIGFueW1vcmUuDQoNCkkgZGlz YWdyZWUuICBXaXRoIHRoZSBuZXcgc3RhdGVtZW50LCBhIGNsaWVudCBjYW4gdmFsaWRhdGUgYW4g ZW50aXJlDQpjb25maWd1cmF0aW9uIGJlZm9yZSBzZW5kaW5nIGl0IHRvIHRoZSBzZXJ2ZXIuDQoN Cg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Tue Oct 13 04:53:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8B63A684C for ; Tue, 13 Oct 2009 04:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 Ind39lqXqv57 for ; Tue, 13 Oct 2009 04:53:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4DA983A6999 for ; Tue, 13 Oct 2009 04:53:18 -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 44BA0D800F1; Tue, 13 Oct 2009 13:53:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091013.131912.68453972.mbj@tail-f.com> References: <1255427275.7488.25.camel@missotis> <20091013.123857.191014621.mbj@tail-f.com> <1255431866.7488.45.camel@missotis> <20091013.131912.68453972.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 13 Oct 2009 13:53:17 +0200 Message-Id: <1255434797.7488.73.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 11:53:19 -0000 Martin Bjorklund píše v Út 13. 10. 2009 v 13:19 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 13. 10. 2009 v 12:38 +0200: > > > Ladislav Lhotka wrote: > > > > Actually, the important information that the "uid" leaf is mandatory > > > > (meaning that the system needs it for proper operation) is lost in > > > > > > > > leaf uid { > > > > type uint32; > > > > system-creatable true; > > > > } > > > > > > True, but again I don't think we should over-specify this. You can > > > always specify behavior in the description clause. > > > > Over-specify? Occurrence constraints are essential in all XML schema > > languages. I could argue in the same way - system-creatable could be > > specified in the description clause. > > That's what I argued for! But after the endless confusion on the > list, the WG decided that it would be better to clarify the intended > behavior of server created nodes with a new statement (and I agree > with that decision). Where is this WG decision documented? I know this issue popped up within the huge thread on defaults, but I have always assumed it would be addressed together with the config-statistics-operational data issues, and in any case after YANG 1.0. If I am not wrong, four people (Andy, Tom, Washam and myself) have expressed the opinion that it is not critically important to know whether a given leaf value was (or can be) created by the client(s) or server. > > > > > If "uid" is not provided by the client when a new user is being created, > > > > the server MAY create the instance - or MAY NOT, which results in an > > > > error. > > > > > > If the server didn't create an instance, it probably won't signal an > > > error either :) > > > > This system-creatable statement adds some new semantics but breaks the > > existing one. Currently I am able to validate an entire configuration > > against quite a strict schema and this won't be possible anymore. > > I disagree. With the new statement, a client can validate an entire > configuration before sending it to the server. I am talking about server-side validation, e.g. at commit time where the server makes sure that all required configuration data are present and satisfy all datatype and other constraints. In your example, a configuration where the "uid" is not present for some items will be found valid - currently it won't if the "uid" leaf is declared as mandatory. So it is a step back in my view. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Oct 13 06:19: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 6228C3A6893 for ; Tue, 13 Oct 2009 06:19:21 -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 eCl-GygfZvYh for ; Tue, 13 Oct 2009 06:19:20 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id C8D953A67D1 for ; Tue, 13 Oct 2009 06:19:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob65.postini.com ([64.18.6.12]) with SMTP ID DSNKStR+V/WwiRhm5+yUxuZhW6gw+ld30vjQ@postini.com; Tue, 13 Oct 2009 06:19:22 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 13 Oct 2009 06:11:59 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:11:59 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:11:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:11:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9DDBvj58107; Tue, 13 Oct 2009 06:11: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 n9DCx97M080514; Tue, 13 Oct 2009 12:59:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910131259.n9DCx97M080514@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD3E6EB.1080302@netconfcentral.com> Date: Tue, 13 Oct 2009 08:59:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Oct 2009 13:11:57.0849 (UTC) FILETIME=[BE3A5890:01CA4C06] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:19:21 -0000 Andy Bierman writes: >The constraints in a YANG module are useless if they only >apply to client-provided values. So we need to add a sentence that say "When the system creates a value for a leaf, the value MUST NOT break any constraints in the YANG module.". Seems fairly simple. Instead of our past pattern of rat holing and debating without listening, can we try to make productive progress by proposing concrete solutions? Thanks, Phil From lhotka@cesnet.cz Tue Oct 13 06: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 9ED773A67D1 for ; Tue, 13 Oct 2009 06:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=0.558, 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 t4n--98YuFmb for ; Tue, 13 Oct 2009 06:23:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C3FAC3A67BE for ; Tue, 13 Oct 2009 06:23:06 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8837BD800BD for ; Tue, 13 Oct 2009 15:23:07 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200910131259.n9DCx97M080514@idle.juniper.net> References: <200910131259.n9DCx97M080514@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 13 Oct 2009 15:23:06 +0200 Message-Id: <1255440186.20301.1.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:23:07 -0000 Phil Shafer píše v Út 13. 10. 2009 v 08:59 -0400: > Andy Bierman writes: > >The constraints in a YANG module are useless if they only > >apply to client-provided values. > > So we need to add a sentence that say "When the system creates > a value for a leaf, the value MUST NOT break any constraints > in the YANG module.". Seems fairly simple. > > Instead of our past pattern of rat holing and debating without > listening, can we try to make productive progress by proposing > concrete solutions? Sure: postpone this after YANG 1.0. Lada > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Oct 13 06:34: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 835D028C1A9 for ; Tue, 13 Oct 2009 06:34:47 -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 P0jEvGwNRspP for ; Tue, 13 Oct 2009 06:34:46 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id 92EA528C1A4 for ; Tue, 13 Oct 2009 06:34:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKStSB9LDbfX9kBZoe14RcftYJ0m2Sk0Yi@postini.com; Tue, 13 Oct 2009 06:34:48 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 13 Oct 2009 06:23:28 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:23:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:23:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:23: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 n9DDNOj63187; Tue, 13 Oct 2009 06:23:25 -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 n9DDAbem080567; Tue, 13 Oct 2009 13:10:38 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910131310.n9DDAbem080567@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1255431866.7488.45.camel@missotis> Date: Tue, 13 Oct 2009 09:10:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Oct 2009 13:23:27.0658 (UTC) FILETIME=[5962D8A0:01CA4C08] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:34:47 -0000 Ladislav Lhotka writes: >Over-specify? Occurrence constraints are essential in all XML schema >languages. I could argue in the same way - system-creatable could be >specified in the description clause. The occurance for "uid" is 0..1, since a valid config does not need it. The server MAY support a value and the description may detail that the server SHOULD supply a value, but the important parts are: (a) the client knows that it doesn't need to supply a value, and (b) the client knows that if it doesn't supply a value, it needs to re-fetch the config to accurate know the value the system created. The fact was the system will always assign a uid does not change (a) or (b). Thanks, Phil From phil@juniper.net Tue Oct 13 06:38: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 EE9AD28C189 for ; Tue, 13 Oct 2009 06:38: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=[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 oIho7qX41kQQ for ; Tue, 13 Oct 2009 06:38:49 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 09B713A68BF for ; Tue, 13 Oct 2009 06:38:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob58.postini.com ([64.18.6.12]) with SMTP ID DSNKStSC4m+uDZuQOFfoZV0wMpjdIYtu3HSq@postini.com; Tue, 13 Oct 2009 06:38: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.375.2; Tue, 13 Oct 2009 06:27:36 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:27:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:27:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:27: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 n9DDRYj65023; Tue, 13 Oct 2009 06:27: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 n9DDEl0K080616; Tue, 13 Oct 2009 13:14:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910131314.n9DDEl0K080616@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD459A2.5030503@netconfcentral.com> Date: Tue, 13 Oct 2009 09:14:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Oct 2009 13:27:35.0531 (UTC) FILETIME=[ED2143B0:01CA4C08] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:38:50 -0000 Andy Bierman writes: >The client validation is incomplete and will >always be incomplete for dynamic defaults that must >be calculated at commit time. I disagree. If your config validation depends on unknowns that can only be calculated at commit time, then you have no faith that the config that committed last time will be able to commit this time. Validation cannot depend on state data, dynamic defaults, installed FRUs, or other items that can change from one commit to the next. Thanks, Phil From phil@juniper.net Tue Oct 13 06:42: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 A25D728C19D for ; Tue, 13 Oct 2009 06:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=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 GNbWs2zPAIx7 for ; Tue, 13 Oct 2009 06:42:40 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id DAFFA28C189 for ; Tue, 13 Oct 2009 06:42:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob65.postini.com ([64.18.6.12]) with SMTP ID DSNKStSDz0XAmFZGUK1MnODLLV+832vxFfLm@postini.com; Tue, 13 Oct 2009 06:42:42 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 13 Oct 2009 06:31:15 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:31:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:31:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:31:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9DDVDj66875; Tue, 13 Oct 2009 06:31:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9DDIQbh080635; Tue, 13 Oct 2009 13:18:26 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910131318.n9DDIQbh080635@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD43D59.2010609@netconfcentral.com> Date: Tue, 13 Oct 2009 09:18:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Oct 2009 13:31:14.0326 (UTC) FILETIME=[6F8ABB60:01CA4C09] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:42:42 -0000 Andy Bierman writes: >A server-created config=true node that the client is not allowed >to see, and is outside the validation model, is broken. I don't understand where you read that "client is not allowed to see" s-c leafs. The client can only see them after they are created, but after that they are part of the configuration and will persist with the configuration. Are you saying we need a sentence that specifies that s-c leafs are created in the candidate before the commit operation copies it over to running? This I can agree with. s-c leaf should persist in the candidate so they are consistent between commits. Thanks, Phil From phil@juniper.net Tue Oct 13 06:49: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 AFD2B28C2CB for ; Tue, 13 Oct 2009 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_66=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 B5znZYfdGiiE for ; Tue, 13 Oct 2009 06:49:01 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id 9EDE528C1F1 for ; Tue, 13 Oct 2009 06:49:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob65.postini.com ([64.18.6.12]) with SMTP ID DSNKStSFSg+wwHTprBZn0lCkImBozpA+Ytn/@postini.com; Tue, 13 Oct 2009 06:49:02 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 13 Oct 2009 06:38:02 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:38:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:38:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 06:38: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 n9DDc0j69391; Tue, 13 Oct 2009 06:38: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 n9DDPCFO080743; Tue, 13 Oct 2009 13:25:13 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910131325.n9DDPCFO080743@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD3EC82.9010109@netconfcentral.com> Date: Tue, 13 Oct 2009 09:25:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Oct 2009 13:38:01.0293 (UTC) FILETIME=[621CF7D0:01CA4C0A] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:49:01 -0000 Andy Bierman writes: >Using our favorite example, the unix users table: >the authoritative source for validation is /etc/passwd, >which is really operational data, ince it is rarely >edited directly by humans. On modern unix systems, /etc/passwd is read-only data (never edited directly by humans) generated from /etc/master.passwd (which is edited directly by humans via "vipw"). But if you are running your user database from your NETCONF-based configuration data, then the NETCONF database is the authoritative source for this config data. You could have your NETCONF server proxy for /etc/master.passwd, using that file as the database, in which case edit-configs to running will add records to master.passwd, in which case the NETCONF database is master.passwd and is still the authoritative source for this config data. But I don't follow how this is "really operational data", since one way of another, the config data isn't operational data. Or are you arguing for "config maybe;"? ;^) Thanks, Phil From jmh@joelhalpern.com Tue Oct 13 06:51: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 B78FF28C2FD for ; Tue, 13 Oct 2009 06:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, J_CHICKENPOX_64=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 5ZF2Wm8wC9Lm for ; Tue, 13 Oct 2009 06:51:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 2089728C2FC for ; Tue, 13 Oct 2009 06:51:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CF78D32317B0; Tue, 13 Oct 2009 06:51:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 2A85632317A9; Tue, 13 Oct 2009 06:51:58 -0700 (PDT) Message-ID: <4AD485FD.6020006@joelhalpern.com> Date: Tue, 13 Oct 2009 09:51:57 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200910131318.n9DDIQbh080635@idle.juniper.net> In-Reply-To: <200910131318.n9DDIQbh080635@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 13:51:57 -0000 If we want the s-c leaves created in the candidate, when a commit succeeds, then we better say that. I think this is actually a good idea. One can make it more complicated by demanding that such nodes be marked as "system-created and subject to recalculation", but frankly I think we are better of not trying to cover that case. Where I get into difficulty is if we try to mandate that system created nodes are created even if a commit or verify fails. Without a valid config, those nodes do not seem to have meaningful values. Yours, Joel Phil Shafer wrote: > Andy Bierman writes: >> A server-created config=true node that the client is not allowed >> to see, and is outside the validation model, is broken. > > I don't understand where you read that "client is not allowed > to see" s-c leafs. The client can only see them after they > are created, but after that they are part of the configuration > and will persist with the configuration. > > Are you saying we need a sentence that specifies that s-c leafs > are created in the candidate before the commit operation copies > it over to running? This I can agree with. s-c leaf should > persist in the candidate so they are consistent between commits. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Tue Oct 13 07: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 E35FC28C305 for ; Tue, 13 Oct 2009 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndHNnZSo8Ymx for ; Tue, 13 Oct 2009 07:01:36 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2AF1F28C304 for ; Tue, 13 Oct 2009 07:01:36 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C1D6461A009; Tue, 13 Oct 2009 16:01:36 +0200 (CEST) Date: Tue, 13 Oct 2009 16:01:36 +0200 (CEST) Message-Id: <20091013.160136.142485245.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200910131259.n9DCx97M080514@idle.juniper.net> References: <4AD3E6EB.1080302@netconfcentral.com> <200910131259.n9DCx97M080514@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 14:01:37 -0000 Phil Shafer wrote: > Andy Bierman writes: > >The constraints in a YANG module are useless if they only > >apply to client-provided values. > > So we need to add a sentence that say "When the system creates > a value for a leaf, the value MUST NOT break any constraints > in the YANG module.". Seems fairly simple. I think this would be a good addition. So Ladislav's example: list users { --> unique uid; key "name"; leaf name { type string; } leaf uid { type uint32; system-creatable true; } } would be valid, and any uid created by the server MUST be unique. /martin From andy@netconfcentral.com Tue Oct 13 08:13: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 CE5D83A67DB for ; Tue, 13 Oct 2009 08:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 4y1yIqKONpEX for ; Tue, 13 Oct 2009 08:13:42 -0700 (PDT) Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id 277313A67AA for ; Tue, 13 Oct 2009 08:13:42 -0700 (PDT) Received: from [68.142.200.226] by n11.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 15:13:42 -0000 Received: from [68.142.201.246] by t7.bullet.mud.yahoo.com with NNFMP; 13 Oct 2009 15:13:42 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 15:13:42 -0000 X-Yahoo-Newman-Id: 91792.40866.bm@omp407.mail.mud.yahoo.com Received: (qmail 73187 invoked from network); 13 Oct 2009 15:13:41 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 13 Oct 2009 08:13:41 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: TCg5IIMVM1ldq6lPdgtAs.NfqLW51U2r3vGpo8TH3SVx3K6OPIUr6oMA.yp_Kn5.GgTIhE1U.49DqeM.hbTal4OqJlm0ANNZ4ZVDKkBLMaz.5dqAiLC4xowCm9wjoDhh8td..W6kjc47eq7KmR7hB_.8ITgALQ6jmnLGDopo8szwVeRz.4vL9n_FMH0WfPmn0RbvxkElgJTzqOde7dVEj5Ppsn8Kqvnnxz_E1RTOf2L35ZSRippbYkTMgdtnZGk9xqQqjbh7OvIkgQKW9IjEPrqZaZ8._OuEAy.R X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD498BD.3010506@netconfcentral.com> Date: Tue, 13 Oct 2009 08:11:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AD3E6EB.1080302@netconfcentral.com> <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> In-Reply-To: <20091013.160136.142485245.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 15:13:42 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> The constraints in a YANG module are useless if they only >>> apply to client-provided values. >> So we need to add a sentence that say "When the system creates >> a value for a leaf, the value MUST NOT break any constraints >> in the YANG module.". Seems fairly simple. > > I think this would be a good addition. > > So Ladislav's example: > > list users { > --> unique uid; > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > would be valid, and any uid created by the server MUST be unique. > Any users entry created by anyone MUST have a unique uid field. That is why all config=true nodes need to appear in the candidate. If the server created uid=502, but doesn't make that visible, then the client adds a new entry and explicits sets '502', that is a commit-time error. If the client cannot use + inspection, or to make a decision about what uid value to provide, then the system-creatable leaf is not manageable by the client. > > > /martin > Andy From jmh@joelhalpern.com Tue Oct 13 08:20: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 D0DD228C327 for ; Tue, 13 Oct 2009 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_64=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 C7Kn7QIQGGcj for ; Tue, 13 Oct 2009 08:20:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 191AE28C2F3 for ; Tue, 13 Oct 2009 08:20:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D9BA932317CA; Tue, 13 Oct 2009 08:20:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 1FEB132317C6; Tue, 13 Oct 2009 08:20:25 -0700 (PDT) Message-ID: <4AD49AB8.8060707@joelhalpern.com> Date: Tue, 13 Oct 2009 11:20:24 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4AD3E6EB.1080302@netconfcentral.com> <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> <4AD498BD.3010506@netconfcentral.com> In-Reply-To: <4AD498BD.3010506@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 15:20:24 -0000 But when do they appear? Although we did not say it, requiring that system-created nodes appear in candidate configs after a commit seems to follow from basic principles. But should they appear in candidate after a successful validate? I think folks would find that surprising. And even more surprising would be if they appeared after an unsuccessful commit or unsuccessful validate, since there is a good chance that they would be wrong, but would then be set to those wrong values and not updated by the system as the rest of the config is corrected. -- But herein is the problem. As currently written, these non-instantiated nodes can affect the validity of the configuration. Just to complete the list, they certainly can not appear before a commit or validate, since there is simply not enough information to create them. Yours, Joel Andy Bierman wrote: > Martin Bjorklund wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> The constraints in a YANG module are useless if they only >>>> apply to client-provided values. >>> So we need to add a sentence that say "When the system creates >>> a value for a leaf, the value MUST NOT break any constraints >>> in the YANG module.". Seems fairly simple. >> I think this would be a good addition. >> >> So Ladislav's example: >> >> list users { >> --> unique uid; >> key "name"; >> leaf name { >> type string; >> } >> leaf uid { >> type uint32; >> system-creatable true; >> } >> } >> >> would be valid, and any uid created by the server MUST be unique. >> > > Any users entry created by anyone MUST have a unique uid > field. That is why all config=true nodes need to appear in > the candidate. If the server created uid=502, but doesn't > make that visible, then the client adds a new entry > and explicits sets '502', that is a commit-time error. > > If the client cannot use + inspection, or > to make a decision about what uid value to > provide, then the system-creatable leaf is not manageable > by the client. > > >> >> /martin >> > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Tue Oct 13 08:59: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 EA1E128C20A for ; Tue, 13 Oct 2009 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=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 Z3U6f0nRN0cX for ; Tue, 13 Oct 2009 08:59:21 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 15D0728C17F for ; Tue, 13 Oct 2009 08:59:17 -0700 (PDT) Received: from [209.191.108.96] by n19.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 15:59:17 -0000 Received: from [68.142.201.70] by t3.bullet.mud.yahoo.com with NNFMP; 13 Oct 2009 15:59:17 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 13 Oct 2009 15:59:17 -0000 X-Yahoo-Newman-Id: 442014.21778.bm@omp422.mail.mud.yahoo.com Received: (qmail 32476 invoked from network); 13 Oct 2009 15:59:14 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 13 Oct 2009 08:59:13 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: zqdtCAEVM1nJKKKTnhYFp_RK8H82Hzis2RPNtqmtGcxEmcS7OOttk2ajAzFzfSxHHQqE1sGWcLXKh9o6oqnQar8jYvB1uC3OizpaFmCWCjzCbjsSumu5heQ5gR9OWRI7jMB8xnqpEUYV2aO9MHSH1kdtXfLTprMJlwGS_VIdFeoB8mqiZGzmqvYjhq9H2qW41kE1_jjFV_tb9d_gEZnXJl91a43wtefSUjcJtXWbmrR9xgpKtye7g9Ge1l1MBPYp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD4A3E4.1050901@netconfcentral.com> Date: Tue, 13 Oct 2009 08:59:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4AD3E6EB.1080302@netconfcentral.com> <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> <4AD498BD.3010506@netconfcentral.com> <4AD49AB8.8060707@joelhalpern.com> In-Reply-To: <4AD49AB8.8060707@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 15:59:22 -0000 Joel M. Halpern wrote: > But when do they appear? > Although we did not say it, requiring that system-created nodes appear > in candidate configs after a commit seems to follow from basic principles. > The commit is the transfer of the candidate to running, so maybe you mean the edit-config that creates the parent and/or sibling nodes (NP container, choice) that would cause a system-creatable leaf to be created? When to create the system node is data-model and implementation dependent. IMO, this corner-case used to set all the rules in the proposal does not even follow the current rules. A config=true constraint is prevented by CLRs from referencing config=false nodes. So a server leaf that cannot pick a valid value until commit-time is using criteria based on state data, not other config=true nodes. This is broken. It should not be allowed in YANG. Therefore, a server should be capable of picking some value for each leaf, at edit-config time. The value may change, if other config=true nodes change before the commit operation, but that is OK. IMO, this would fix system-creatable. Also, mandatory=true is still valid with s-c=true, because the server MAY (not MUST) create a node. So mandatory=true means that the commit-time constraint is still valid. The server does not have to provide a value (as I said before). Instead, the commit will fail because the client did not make sure a value exists. > But should they appear in candidate after a successful validate? I > think folks would find that surprising. > > And even more surprising would be if they appeared after an unsuccessful > commit or unsuccessful validate, since there is a good chance that they > would be wrong, but would then be set to those wrong values and not > updated by the system as the rest of the config is corrected. > -- But herein is the problem. As currently written, these > non-instantiated nodes can affect the validity of the configuration. > > Just to complete the list, they certainly can not appear before a > commit or validate, since there is simply not enough information to > create them. > Why wouldn't there be enough information to create them? There is the same data available to the client, and the client is expected to pick a value. Why can't the server do the same thing? > Yours, > Joel Andy From phil@juniper.net Tue Oct 13 11:46: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 87C0E28C209 for ; Tue, 13 Oct 2009 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckoSF2MZ0HSv for ; Tue, 13 Oct 2009 11:46:47 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 6DD6D3A657C for ; Tue, 13 Oct 2009 11:46:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKStTLF7D8n9bHRqGbGr5A6/NrRCgSJBhf@postini.com; Tue, 13 Oct 2009 11:46:49 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 13 Oct 2009 11:08:19 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 11:08:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 11:08:19 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 11:08:18 -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 n9DI8Dj01437; Tue, 13 Oct 2009 11:08:17 -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 n9DHtPdl090591; Tue, 13 Oct 2009 17:55:26 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910131755.n9DHtPdl090591@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4AD485FD.6020006@joelhalpern.com> Date: Tue, 13 Oct 2009 13:55:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Oct 2009 18:08:18.0855 (UTC) FILETIME=[24888B70:01CA4C30] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 18:46:48 -0000 "Joel M. Halpern" writes: >Where I get into difficulty is if we try to mandate that system created >nodes are created even if a commit or verify fails. Without a valid >config, those nodes do not seem to have meaningful values. Yup, this is a touchy case. Discarding these s-c leafs if commit fails seems good on the surface, but I'll admit that I do not do this in my code. Once the commit progresses to the point that an s-c leaf is created, it persists. Perhaps not ideal, but certainly simple. Thanks, Phil From andy@netconfcentral.com Tue Oct 13 12:11:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A9F28C1EE for ; Tue, 13 Oct 2009 12:11: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 yko-F3GE9mmf for ; Tue, 13 Oct 2009 12:11:52 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 1BDC828C0DE for ; Tue, 13 Oct 2009 12:11:51 -0700 (PDT) Received: (qmail 44888 invoked from network); 13 Oct 2009 19:11:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 13 Oct 2009 19:11:51 -0000 X-YMail-OSG: lLpChMoVM1mIf1oB1988wtVKFuqjYo30VpJwjtQ6qmq2S00l5FqR5bBBb5ioEFp6eK6Adp0J2U1J66CxAiRwWSgCVN63WjkWEYIt_Dbuhvj0GHSD7NQvqV8WsiuqMgb3Np9FavlGL6Yd_FOWpQ5xcLtctYdagfv5XIkMpP8HoZpfp1T6zPNkn4jBep.z5lgwwOmrCQ2yEDaFerya5A.hf_TiuE1R0p4vvZkZPL0v_.CMyf8yMZYLYxU1a52JgzL8ftFjBoOzPtu7B_Z3DjwJMIZZUj9OcYrXwdjQlUIcrrpfjBlXwMdnwSA9F3Gh5IUq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD4D109.4010600@netconfcentral.com> Date: Tue, 13 Oct 2009 12:12:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910131755.n9DHtPdl090591@idle.juniper.net> In-Reply-To: <200910131755.n9DHtPdl090591@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2009 19:11:53 -0000 Phil Shafer wrote: > "Joel M. Halpern" writes: >> Where I get into difficulty is if we try to mandate that system created >> nodes are created even if a commit or verify fails. Without a valid >> config, those nodes do not seem to have meaningful values. > > Yup, this is a touchy case. Discarding these s-c leafs if commit > fails seems good on the surface, but I'll admit that I do not do > this in my code. Once the commit progresses to the point that an > s-c leaf is created, it persists. Perhaps not ideal, but certainly > simple. > I don't think anybody is proposing that. Originally I thought that might work, but it doesn't. However, mandatory=true means the same thing it meant before, The node must exist in a valid configuration, and if not, the commit will fail. It is fine with me if the server MAY create a system-creatable node (in candidate) any time from the edit-config to the commit, so it allows all implementation strategies. That means that if the server is last to add nodes, then they must not trigger any constraint violations, as Martin pointed out. In this case, the client will not see these new nodes until after the commit, as Joel pointed out. The text about the server MUST create s-c node at commit time is a CLR. Just as before, the client cannot count on the state of every candidate implementation to change the same way. YANG only describes a valid configuration -- the contents of the running config after the commit. > Thanks, > Phil > Andy From Washam.Fan@huaweisymantec.com Tue Oct 13 23:29: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 527E33A6961 for ; Tue, 13 Oct 2009 23:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ba4u9YXyJ+e for ; Tue, 13 Oct 2009 23:29:19 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id BBF6F3A6835 for ; Tue, 13 Oct 2009 23:29:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KRH00FXKRC64W70@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 14 Oct 2009 14:28:55 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KRH00LJTRC68K10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 14 Oct 2009 14:28:54 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 14 Oct 2009 14:28:54 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Wed, 14 Oct 2009 14:28:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <1255434797.7488.73.camel@missotis> References: <1255427275.7488.25.camel@missotis> <20091013.123857.191014621.mbj@tail-f.com> <1255431866.7488.45.camel@missotis> <20091013.131912.68453972.mbj@tail-f.com> <1255434797.7488.73.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 06:29:20 -0000 > Where is this WG decision documented? I know this issue popped up within > the huge thread on defaults, but I have always assumed it would be > addressed together with the config-statistics-operational data issues, > and in any case after YANG 1.0. If I am not wrong, four people (Andy, > Tom, Washam and myself) have expressed the opinion that it is not > critically important to know whether a given leaf value was (or can be) > created by the client(s) or server. My understanding of system-creatable behavior is, the server as a proxy creates s-c leafs on behalf of the client. there are two players manipulating the config datastore, the client and the server. So the validation by client side does not equal to validation by server side. validation by client side is to validate input by the client to the config datastore. validation by server side is to validate the config datastore that reflects inputs by the client and the server when s-c leaf created. The s-c leafs should be treated in the same way as other leafs when validating the config datastore. I agreed with Andy that s-c leafs should be reflected in candidate datastore before . the client should get all configs visible whether it provides itself, the server provides on behalf of it or defaults it can assume via documents. I am wondering how any netconf implementations handle uid case in reality. washam washam From lhotka@cesnet.cz Wed Oct 14 02:36:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA6628C183 for ; Wed, 14 Oct 2009 02:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9K6JS+iEL4Q for ; Wed, 14 Oct 2009 02:36:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CBC5B28C174 for ; Wed, 14 Oct 2009 02:36:51 -0700 (PDT) Received: from [10.0.0.13] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id 1AD2AD800C8; Wed, 14 Oct 2009 11:36:53 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091013.160136.142485245.mbj@tail-f.com> References: <4AD3E6EB.1080302@netconfcentral.com> <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 11:36:51 +0200 Message-Id: <1255513011.6653.81.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 09:36:52 -0000 Martin Bjorklund píše v Út 13. 10. 2009 v 16:01 +0200: > Phil Shafer wrote: > > Andy Bierman writes: > > >The constraints in a YANG module are useless if they only > > >apply to client-provided values. > > > > So we need to add a sentence that say "When the system creates > > a value for a leaf, the value MUST NOT break any constraints > > in the YANG module.". Seems fairly simple. > > I think this would be a good addition. So what about the sentences about validation in your original text? A system-creatable leaf is created by the server after validation (see Section 8.3.3), if the validation succeeds. Since the leaf creation occurs after validation, constraints (see ^constraints) will not be able to access the new leaf value. My reading is that s-c leafs are exempt from validation. Lada > > So Ladislav's example: > > list users { > --> unique uid; > key "name"; > leaf name { > type string; > } > leaf uid { > type uint32; > system-creatable true; > } > } > > would be valid, and any uid created by the server MUST be unique. > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Oct 14 03:08: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 AF4033A691C for ; Wed, 14 Oct 2009 03:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.650, 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 JlofWnAJCSym for ; Wed, 14 Oct 2009 03:08:32 -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 C96D13A6965 for ; Wed, 14 Oct 2009 03:08:28 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1190561602B; Wed, 14 Oct 2009 12:08:30 +0200 (CEST) Date: Wed, 14 Oct 2009 12:08:29 +0200 (CEST) Message-Id: <20091014.120829.233882773.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255513011.6653.81.camel@missotis> References: <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> <1255513011.6653.81.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 10:08:32 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMTMuIDEwLiAyMDA5IHYgMTY6MDEgKzAyMDA6DQo+ID4gUGhpbCBT aGFmZXIgPHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+ID4gQW5keSBCaWVybWFuIHdyaXRl czoNCj4gPiA+ID5UaGUgY29uc3RyYWludHMgaW4gYSBZQU5HIG1vZHVsZSBhcmUgdXNlbGVzcyBp ZiB0aGV5IG9ubHkNCj4gPiA+ID5hcHBseSB0byBjbGllbnQtcHJvdmlkZWQgdmFsdWVzLg0KPiA+ ID4gDQo+ID4gPiBTbyB3ZSBuZWVkIHRvIGFkZCBhIHNlbnRlbmNlIHRoYXQgc2F5ICJXaGVuIHRo ZSBzeXN0ZW0gY3JlYXRlcw0KPiA+ID4gYSB2YWx1ZSBmb3IgYSBsZWFmLCB0aGUgdmFsdWUgTVVT VCBOT1QgYnJlYWsgYW55IGNvbnN0cmFpbnRzDQo+ID4gPiBpbiB0aGUgWUFORyBtb2R1bGUuIi4g IFNlZW1zIGZhaXJseSBzaW1wbGUuDQo+ID4gDQo+ID4gSSB0aGluayB0aGlzIHdvdWxkIGJlIGEg Z29vZCBhZGRpdGlvbi4NCj4gDQo+IFNvIHdoYXQgYWJvdXQgdGhlIHNlbnRlbmNlcyBhYm91dCB2 YWxpZGF0aW9uIGluIHlvdXIgb3JpZ2luYWwgdGV4dD8NCj4gDQo+ICAgIEEgc3lzdGVtLWNyZWF0 YWJsZSBsZWFmIGlzIGNyZWF0ZWQgYnkgdGhlIHNlcnZlciBhZnRlciB2YWxpZGF0aW9uDQo+ICAg IChzZWUgU2VjdGlvbiA4LjMuMyksIGlmIHRoZSB2YWxpZGF0aW9uIHN1Y2NlZWRzLiAgU2luY2Ug dGhlIGxlYWYNCj4gICAgY3JlYXRpb24gb2NjdXJzIGFmdGVyIHZhbGlkYXRpb24sIGNvbnN0cmFp bnRzIChzZWUgXmNvbnN0cmFpbnRzKSB3aWxsDQo+ICAgIG5vdCBiZSBhYmxlIHRvIGFjY2VzcyB0 aGUgbmV3IGxlYWYgdmFsdWUuDQo+IA0KPiBNeSByZWFkaW5nIGlzIHRoYXQgcy1jIGxlYWZzIGFy ZSBleGVtcHQgZnJvbSB2YWxpZGF0aW9uLg0KDQpUaGV5IGFyZSBub3QgeWV0IGNyZWF0ZWQgd2hl biBhIHVzZXIgZG9lcyA8dmFsaWRhdGU+IG9yIGR1cmluZyB0aGUNCnZhbGlkYXRpb24gdGhhdCBv Y2N1cnMgZHVyaW5nIDxjb21taXQ+LCBzbyB0aGV5IGFyZSBub3QgdGhlcmUuICBUaGF0DQpkb2Vz bid0IG1lYW4gdGhhdCB0aGUgbGVhZiBpdHNlbGYgaW4gZ2VuZXJhbCBpcyBleGVtcHQgZnJvbQ0K dmFsaWRhdGlvbiAtIHRoZSBub3JtYWwgcnVsZXMgYXBwbHkgZm9yIHRoaXMgbGVhZiBqdXN0IGFz IGZvciBhbnkNCm90aGVyIGxlYWYgKGUuZy4gaWYgaXQgaGFzIGEgdmFsdWUsIGl0cyAibXVzdCIg ZXhwcmVzc2lvbnMgYXJlDQpldmFsdWF0ZWQpLg0KDQpUaGUgZXh0cmEgc2VudGVuY2Ugc3VnZ2Vz dGVkIGJ5IFBoaWwganVzdCBzYXlzIHRoYXQgdGhlIHNlcnZlciBNVVNUDQpOT1QgY3JlYXRlIGEg dmFsdWUgdGhhdCB3aWxsIG1ha2UgdGhlIGNvbmZpZyBpbnZhbGlkLg0KDQoNCi9tYXJ0aW4NCg== From andy@netconfcentral.com Wed Oct 14 04:11: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 B029428C18A for ; Wed, 14 Oct 2009 04:11:31 -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.455, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 zRRkXLMCYQyn for ; Wed, 14 Oct 2009 04:11:31 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id E506828C14B for ; Wed, 14 Oct 2009 04:11:30 -0700 (PDT) Received: (qmail 87879 invoked from network); 14 Oct 2009 11:11:30 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 04:11:30 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pz9xw6cVM1m3XQELuIEpfdOLq8ls.MQEYPGCwViqz2HHQ5GgK64CpdcEvk.8F.Bth2EKUXc1G9gMOrWfIb71NJwX1DtTMxzabtR4cI.i3PsHqEqPhv7mDsaaT_pK5hjdA_0bmqDR5BuQwKh.5CPpmNA.UNPXi05k31qElCrsd8OAvIN50TRF2DgNhBxtIZG38PqAGIQVi0AGq5vJkzeluDmnj16szuB1FmB553K6GwT0i3kuWRhQH3YugpJ1vw2Vx09Mn5xLoVWJVB1rmiqnis8.vmCOzbsB1tXeD4solmo5v_1xqX6Um9zroGuYD3johw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5B1F7.90204@netconfcentral.com> Date: Wed, 14 Oct 2009 04:11:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <1255427275.7488.25.camel@missotis> <20091013.123857.191014621.mbj@tail-f.com> <1255431866.7488.45.camel@missotis> <20091013.131912.68453972.mbj@tail-f.com> <1255434797.7488.73.camel@missotis> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 11:11:31 -0000 WashamFan wrote: >> Where is this WG decision documented? I know this issue popped up within >> the huge thread on defaults, but I have always assumed it would be >> addressed together with the config-statistics-operational data issues, >> and in any case after YANG 1.0. If I am not wrong, four people (Andy, >> Tom, Washam and myself) have expressed the opinion that it is not >> critically important to know whether a given leaf value was (or can be) >> created by the client(s) or server. > > My understanding of system-creatable behavior is, the server as a proxy > creates s-c leafs on behalf of the client. there are two players manipulating > the config datastore, the client and the server. So the validation by client > side does not equal to validation by server side. validation by client side is > to validate input by the client to the config datastore. validation by server > side is to validate the config datastore that reflects inputs by the client > and the server when s-c leaf created. The s-c leafs should be treated in > the same way as other leafs when validating the config datastore. > > I agreed with Andy that s-c leafs should be reflected in candidate datastore > before . the client should get all configs visible whether it provides itself, > the server provides on behalf of it or defaults it can assume via documents. > It is OK if the s-c leaf shows up during the edit-config or the commit. As long as the server does not trigger any constraint violations, then it can add leafs during the commit. > I am wondering how any netconf implementations handle uid case in reality. > In general, the central stack will never add s-c leafs because they are not derived from YANG files. But instrumentation callbacks can add leafs. > washam Andy From lhotka@cesnet.cz Wed Oct 14 04:17:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345443A69B7 for ; Wed, 14 Oct 2009 04:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTG-ZaSB2GFC for ; Wed, 14 Oct 2009 04:17:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5A5FD3A69B4 for ; Wed, 14 Oct 2009 04:17:38 -0700 (PDT) Received: from [10.0.0.38] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id E8947D800BD; Wed, 14 Oct 2009 13:17:37 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091014.120829.233882773.mbj@tail-f.com> References: <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> <1255513011.6653.81.camel@missotis> <20091014.120829.233882773.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 13:17:36 +0200 Message-Id: <1255519056.6653.87.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 11:17:39 -0000 Martin Bjorklund píše v St 14. 10. 2009 v 12:08 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 13. 10. 2009 v 16:01 +0200: > > > Phil Shafer wrote: > > > > Andy Bierman writes: > > > > >The constraints in a YANG module are useless if they only > > > > >apply to client-provided values. > > > > > > > > So we need to add a sentence that say "When the system creates > > > > a value for a leaf, the value MUST NOT break any constraints > > > > in the YANG module.". Seems fairly simple. > > > > > > I think this would be a good addition. > > > > So what about the sentences about validation in your original text? > > > > A system-creatable leaf is created by the server after validation > > (see Section 8.3.3), if the validation succeeds. Since the leaf > > creation occurs after validation, constraints (see ^constraints) will > > not be able to access the new leaf value. > > > > My reading is that s-c leafs are exempt from validation. > > They are not yet created when a user does or during the > validation that occurs during , so they are not there. That > doesn't mean that the leaf itself in general is exempt from > validation - the normal rules apply for this leaf just as for any > other leaf (e.g. if it has a value, its "must" expressions are > evaluated). Is there any reason for having these values NOT filled in at commit time? This means that commit-time schema-based validation is rendered impossible and thus decreases the utility of DSDL mapping. Lada > > The extra sentence suggested by Phil just says that the server MUST > NOT create a value that will make the config invalid. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Oct 14 04:22:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7073A69B4 for ; Wed, 14 Oct 2009 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.433, 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 26iuGFCe2gpx for ; Wed, 14 Oct 2009 04:22:13 -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 DA9373A6978 for ; Wed, 14 Oct 2009 04:22:12 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 48CE261A009; Wed, 14 Oct 2009 13:22:14 +0200 (CEST) Date: Wed, 14 Oct 2009 13:22:13 +0200 (CEST) Message-Id: <20091014.132213.184344928.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255519056.6653.87.camel@missotis> References: <1255513011.6653.81.camel@missotis> <20091014.120829.233882773.mbj@tail-f.com> <1255519056.6653.87.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 11:22:13 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBTdCAxNC4gMTAuIDIwMDkgdiAxMjowOCArMDIwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gTWFydGluIEJqb3JrbHVu ZCBww63FoWUgdiDDmnQgMTMuIDEwLiAyMDA5IHYgMTY6MDEgKzAyMDA6DQo+ID4gPiA+IFBoaWwg U2hhZmVyIDxwaGlsQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPiA+ID4gPiBBbmR5IEJpZXJtYW4g d3JpdGVzOg0KPiA+ID4gPiA+ID5UaGUgY29uc3RyYWludHMgaW4gYSBZQU5HIG1vZHVsZSBhcmUg dXNlbGVzcyBpZiB0aGV5IG9ubHkNCj4gPiA+ID4gPiA+YXBwbHkgdG8gY2xpZW50LXByb3ZpZGVk IHZhbHVlcy4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBTbyB3ZSBuZWVkIHRvIGFkZCBhIHNlbnRl bmNlIHRoYXQgc2F5ICJXaGVuIHRoZSBzeXN0ZW0gY3JlYXRlcw0KPiA+ID4gPiA+IGEgdmFsdWUg Zm9yIGEgbGVhZiwgdGhlIHZhbHVlIE1VU1QgTk9UIGJyZWFrIGFueSBjb25zdHJhaW50cw0KPiA+ ID4gPiA+IGluIHRoZSBZQU5HIG1vZHVsZS4iLiAgU2VlbXMgZmFpcmx5IHNpbXBsZS4NCj4gPiA+ ID4gDQo+ID4gPiA+IEkgdGhpbmsgdGhpcyB3b3VsZCBiZSBhIGdvb2QgYWRkaXRpb24uDQo+ID4g PiANCj4gPiA+IFNvIHdoYXQgYWJvdXQgdGhlIHNlbnRlbmNlcyBhYm91dCB2YWxpZGF0aW9uIGlu IHlvdXIgb3JpZ2luYWwgdGV4dD8NCj4gPiA+IA0KPiA+ID4gICAgQSBzeXN0ZW0tY3JlYXRhYmxl IGxlYWYgaXMgY3JlYXRlZCBieSB0aGUgc2VydmVyIGFmdGVyIHZhbGlkYXRpb24NCj4gPiA+ICAg IChzZWUgU2VjdGlvbiA4LjMuMyksIGlmIHRoZSB2YWxpZGF0aW9uIHN1Y2NlZWRzLiAgU2luY2Ug dGhlIGxlYWYNCj4gPiA+ICAgIGNyZWF0aW9uIG9jY3VycyBhZnRlciB2YWxpZGF0aW9uLCBjb25z dHJhaW50cyAoc2VlIF5jb25zdHJhaW50cykgd2lsbA0KPiA+ID4gICAgbm90IGJlIGFibGUgdG8g YWNjZXNzIHRoZSBuZXcgbGVhZiB2YWx1ZS4NCj4gPiA+IA0KPiA+ID4gTXkgcmVhZGluZyBpcyB0 aGF0IHMtYyBsZWFmcyBhcmUgZXhlbXB0IGZyb20gdmFsaWRhdGlvbi4NCj4gPiANCj4gPiBUaGV5 IGFyZSBub3QgeWV0IGNyZWF0ZWQgd2hlbiBhIHVzZXIgZG9lcyA8dmFsaWRhdGU+IG9yIGR1cmlu ZyB0aGUNCj4gPiB2YWxpZGF0aW9uIHRoYXQgb2NjdXJzIGR1cmluZyA8Y29tbWl0Piwgc28gdGhl eSBhcmUgbm90IHRoZXJlLiAgVGhhdA0KPiA+IGRvZXNuJ3QgbWVhbiB0aGF0IHRoZSBsZWFmIGl0 c2VsZiBpbiBnZW5lcmFsIGlzIGV4ZW1wdCBmcm9tDQo+ID4gdmFsaWRhdGlvbiAtIHRoZSBub3Jt YWwgcnVsZXMgYXBwbHkgZm9yIHRoaXMgbGVhZiBqdXN0IGFzIGZvciBhbnkNCj4gPiBvdGhlciBs ZWFmIChlLmcuIGlmIGl0IGhhcyBhIHZhbHVlLCBpdHMgIm11c3QiIGV4cHJlc3Npb25zIGFyZQ0K PiA+IGV2YWx1YXRlZCkuDQo+IA0KPiBJcyB0aGVyZSBhbnkgcmVhc29uIGZvciBoYXZpbmcgdGhl c2UgdmFsdWVzIE5PVCBmaWxsZWQgaW4gYXQgY29tbWl0DQo+IHRpbWU/IFRoaXMgbWVhbnMgdGhh dCBjb21taXQtdGltZSBzY2hlbWEtYmFzZWQgdmFsaWRhdGlvbiBpcyByZW5kZXJlZA0KPiBpbXBv c3NpYmxlIGFuZCB0aHVzIGRlY3JlYXNlcyB0aGUgdXRpbGl0eSBvZiBEU0RMIG1hcHBpbmcuDQoN CklmIHRoZXkgYXJlIGZpbGxlZCBpbiBmb3IgdmFsaWRhdGlvbiBhdCA8Y29tbWl0PiB0aGV5IGFs c28gaGF2ZSB0byBiZQ0KZmlsbGVkIGluIGF0IDx2YWxpZGF0ZT4uICBBbmQgaGF2aW5nIGNvbmZp ZyBkYXRhIGFwcGVhciBhcyBhIHNpZGUNCmVmZmVjdCBvZiA8dmFsaWRhdGU+IHNlZW1zIHdlaXJk LiAgQWxzbyBoYXZpbmcgY29uZmlnIGRhdGEgYXBwZWFyIGFzIGENCnNpZGUgZWZmZWN0IG9mIGEg ZmFpbGVkIDxjb21taXQ+IHNlZW1zIHdlaXJkLg0KDQoNCi9tYXJ0aW4NCg== From j.schoenwaelder@jacobs-university.de Wed Oct 14 05:11: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 9EBC73A6952 for ; Wed, 14 Oct 2009 05:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=1.269, 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 txQwKpoBwxdd for ; Wed, 14 Oct 2009 05:11: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 93FE23A68E2 for ; Wed, 14 Oct 2009 05:11:48 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D4D0C0019; Wed, 14 Oct 2009 14:11:50 +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 rs-ofsbz6wBE; Wed, 14 Oct 2009 14:11:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BECFC0018; Wed, 14 Oct 2009 14:11:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C52B6D1DAD2; Wed, 14 Oct 2009 14:11:48 +0200 (CEST) Date: Wed, 14 Oct 2009 14:11:48 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091014121148.GB20756@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> <1255513011.6653.81.camel@missotis> <20091014.120829.233882773.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091014.120829.233882773.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 12:11:49 -0000 On Wed, Oct 14, 2009 at 12:08:29PM +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund p????e v ??t 13. 10. 2009 v 16:01 +0200: > > > Phil Shafer wrote: > > > > Andy Bierman writes: > > > > >The constraints in a YANG module are useless if they only > > > > >apply to client-provided values. > > > > > > > > So we need to add a sentence that say "When the system creates > > > > a value for a leaf, the value MUST NOT break any constraints > > > > in the YANG module.". Seems fairly simple. > > > > > > I think this would be a good addition. > > > > So what about the sentences about validation in your original text? > > > > A system-creatable leaf is created by the server after validation > > (see Section 8.3.3), if the validation succeeds. Since the leaf > > creation occurs after validation, constraints (see ^constraints) will > > not be able to access the new leaf value. > > > > My reading is that s-c leafs are exempt from validation. > > They are not yet created when a user does or during the > validation that occurs during , so they are not there. That > doesn't mean that the leaf itself in general is exempt from > validation - the normal rules apply for this leaf just as for any > other leaf (e.g. if it has a value, its "must" expressions are > evaluated). > > The extra sentence suggested by Phil just says that the server MUST > NOT create a value that will make the config invalid. Let me try to see whether I understand what the text is saying: 1) Both, the config without the s-c leafs filled in as well as the config which has the s-c leafs filled, have to be valid when I do an edit-config on . (Or does this interact with the test-option parameter?) 2) The config without the s-c leafs filled in has to be valid when doing a validate on . 3) The config with the sc-leafs filled in has to be valid after doing a commit on . What about other operations, such as copy-config? It might help to have all the relevant cases clearly spelled out... /js PS: I better do not ask how this interacts with partial-locks, e.g. a partial lock on an s-c leaf. ;-) -- 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 Wed Oct 14 06:53: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 A7C853A67F5 for ; Wed, 14 Oct 2009 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktjMTqRXqZm0 for ; Wed, 14 Oct 2009 06:53:31 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 6B4183A69FE for ; Wed, 14 Oct 2009 06:53:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKStXX0uXMo1HlWqArXSCGxCfj+7apjPDi@postini.com; Wed, 14 Oct 2009 06:53:27 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 06:47:11 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 06:47:10 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 06:47:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 06:47:09 -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 n9EDl9j45553; Wed, 14 Oct 2009 06:47:09 -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 n9EDYKrg011332; Wed, 14 Oct 2009 13:34:21 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141334.n9EDYKrg011332@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091014121148.GB20756@elstar.local> Date: Wed, 14 Oct 2009 09:34:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 13:47:09.0790 (UTC) FILETIME=[D374B7E0:01CA4CD4] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 13:53:31 -0000 Juergen Schoenwaelder writes: >1) Both, the config without the s-c leafs filled in as well as the > config which has the s-c leafs filled, have to be valid when I do > an edit-config on . True. > (Or does this interact with the test-option parameter?) No. >2) The config without the s-c leafs filled in has to be valid when > doing a validate on . True. >3) The config with the sc-leafs filled in has to be valid after doing > a commit on . True. >What about other operations, such as copy-config? It might help to >have all the relevant cases clearly spelled out... Copy-config should not change data, so it should not create s-c leafs. >PS: I better do not ask how this interacts with partial-locks, e.g. > a partial lock on an s-c leaf. ;-) If an s-c leaf does not exist, it cannot be locked. If it exists, it's normal data. We do need to say something about creating locks when the parent is locked by the current session (that it is allowed, even though the "system" is creating it) and when the parent is locked by someone else (that it is not allowed). Thanks, Phil From andy@netconfcentral.com Wed Oct 14 06:58:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490383A635F for ; Wed, 14 Oct 2009 06:58:19 -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 pe7nG5YoDiIv for ; Wed, 14 Oct 2009 06:58:18 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id EB2913A685B for ; Wed, 14 Oct 2009 06:58:17 -0700 (PDT) Received: (qmail 15873 invoked from network); 14 Oct 2009 13:58:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 13:58:18 -0000 X-YMail-OSG: tlDYwfEVM1lwRHW9ISpkenRNgjQp3ZHn8rcBnHKh0sUrpnAM0xghBskNVeDuxQlTs5E9C_w0.1J4J6Lkkm3p9qYozVswSZhouPtWItc6PHhPS8fRr4TTo9a01mCNLZLFL_mX_5auWFdoYGw.Xptln._bceZtWD9ODaoc6_KPMaTzGAfvGfDynalD6TlOPtpyocjCCtOnm81.2FjNLo_HIlQ0Zrfuu8hugBsS.j4Db2._Jf36Gu76TYRWbx3EZXuzHqxzU4CoKOgBinI5_HOJ2ZPQEb6gCsrHcBvkBYNP8iIsLKHon8kwAoU8Wu.jp9H3SNRLOodyILZjLn3U_oAq1Fvajom4o3yxk00x X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5D90F.9060007@netconfcentral.com> Date: Wed, 14 Oct 2009 06:58:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <200910131259.n9DCx97M080514@idle.juniper.net> <20091013.160136.142485245.mbj@tail-f.com> <1255513011.6653.81.camel@missotis> <20091014.120829.233882773.mbj@tail-f.com> <20091014121148.GB20756@elstar.local> In-Reply-To: <20091014121148.GB20756@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 13:58:19 -0000 Juergen Schoenwaelder wrote: > On Wed, Oct 14, 2009 at 12:08:29PM +0200, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Martin Bjorklund p????e v ??t 13. 10. 2009 v 16:01 +0200: >>>> Phil Shafer wrote: >>>>> Andy Bierman writes: >>>>>> The constraints in a YANG module are useless if they only >>>>>> apply to client-provided values. >>>>> So we need to add a sentence that say "When the system creates >>>>> a value for a leaf, the value MUST NOT break any constraints >>>>> in the YANG module.". Seems fairly simple. >>>> I think this would be a good addition. >>> So what about the sentences about validation in your original text? >>> >>> A system-creatable leaf is created by the server after validation >>> (see Section 8.3.3), if the validation succeeds. Since the leaf >>> creation occurs after validation, constraints (see ^constraints) will >>> not be able to access the new leaf value. >>> >>> My reading is that s-c leafs are exempt from validation. >> They are not yet created when a user does or during the >> validation that occurs during , so they are not there. That >> doesn't mean that the leaf itself in general is exempt from >> validation - the normal rules apply for this leaf just as for any >> other leaf (e.g. if it has a value, its "must" expressions are >> evaluated). >> >> The extra sentence suggested by Phil just says that the server MUST >> NOT create a value that will make the config invalid. > > Let me try to see whether I understand what the text is saying: > > 1) Both, the config without the s-c leafs filled in as well as the > config which has the s-c leafs filled, have to be valid when I do > an edit-config on . > Yes -- every edit to running is supposed to leave the running config valid, but it is not a MUST. The edit-config continue-on-error mode makes this unclear. > (Or does this interact with the test-option parameter?) > Yes -- if test-then-set, the runing config should remain unchanged if there are going to be any problems. Again, it is not clear if resource-denied or in-use could occur after validation. > 2) The config without the s-c leafs filled in has to be valid when > doing a validate on . > Nothing ever has to be valid in candidate. It is an incremental scratchpad. It only needs to be valid at commit-time. > 3) The config with the sc-leafs filled in has to be valid after doing > a commit on . > yes A client should expect that the server MAY create leafs as a side-effect of the edit-config or the commit. This is data-model and implementation-specific. The server instrumentation may be written to fill in some leafs right away and some during the commit. For the uid example, it makes sense to wait until the commit to actually allocate a user ID, instead of a more complicated temp-reserve design. For a platform-specific static default (not YANG-documented as a deviation or a refinement), the instrumentation might just plug in the value right away. > What about other operations, such as copy-config? It might help to > have all the relevant cases clearly spelled out... > YANG just needs to describe the properties of a valid NETCONF database. The NETCONF server is expected to maintain a valid running config. Other than that, it is unclear what the standard needs to specify (e.g., url, startup structure). > /js > > PS: I better do not ask how this interacts with partial-locks, e.g. > a partial lock on an s-c leaf. ;-) > Excellent point. All XPath (YANG, select, partial-lock, proprietary RPCs) needs to operate on the same conceptual XML instance document. All nodes in use (client, default, s-c) exist in this conceptual document. Andy From phil@juniper.net Wed Oct 14 07:03: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 E26613A69F8 for ; Wed, 14 Oct 2009 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY2uIU5Dr06q for ; Wed, 14 Oct 2009 07:03:14 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 006D93A6A0C for ; Wed, 14 Oct 2009 07:03:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKStXaI+pIqdZjCpF2ZWwrg9FxgsPX3ZaT@postini.com; Wed, 14 Oct 2009 07:03:16 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 06:56:03 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 06:56:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 06:56:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 06:56:02 -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 n9EDu1j49266; Wed, 14 Oct 2009 06:56:02 -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 n9EDhDP3011451; Wed, 14 Oct 2009 13:43:13 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141343.n9EDhDP3011451@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD4D109.4010600@netconfcentral.com> Date: Wed, 14 Oct 2009 09:43:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 13:56:02.0929 (UTC) FILETIME=[113B4610:01CA4CD6] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 14:03:15 -0000 Andy Bierman writes: >It is fine with me if the server MAY create a system-creatable >node (in candidate) any time from the edit-config to the commit, so it >allows all implementation strategies. This would be ambiguous about the results. Consider: ... one two 2000 If the system starts numbering user uids at 2000 (as JUNOS does), then the results of generating uids could be an error if the user "one" is assigned uid 2000 when the tag is seen. A similar scenario exists for multiple s before a , but this is probably less interesting. How much do we care about this case? How worried are we over the interoperability differences caused by allowing the vendor to choose when s-c leafs are created? (Does it seem like we're on odd sides of this one?) >The text about the server MUST create s-c node at commit time is a CLR. >Just as before, the client cannot count on the state of >every candidate implementation to change the same way. >YANG only describes a valid configuration -- the contents >of the running config after the commit. I want the constraints in YANG to be applicable inside the client, so outgoing config can be validated. This gives s-c leaf creation a post-validation timeframe. Thanks, Phil From andy@netconfcentral.com Wed Oct 14 07:23: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 A9D3528C13F for ; Wed, 14 Oct 2009 07:23:45 -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 anzVb1H4we3w for ; Wed, 14 Oct 2009 07:23:44 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 711413A67B8 for ; Wed, 14 Oct 2009 07:23:44 -0700 (PDT) Received: (qmail 47074 invoked from network); 14 Oct 2009 14:23:45 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 14:23:44 -0000 X-YMail-OSG: A6xsAuQVM1m8Mey6sRTkPDcNyOFjqWeRZjkPfBpUG17v9Yj3o99kmYZRY3v_O35I6aBFxB_85yXccNqCoOK4srBL1Y35cd83_ixhYvgDnBT1Sc.Cq82f1Zue8CWWd4TZqgzoaiN1N_V1TT3jEDENzkRpUKthcq_AVwoseK0wUEE4L9MgcBHYV5mM1AyUQXBp2tSbW.s3HkG199EQY7j24J7860TDbnu1MoXnNF1sJZgcamTO1lzI_xPv7BRxWi_s4ZcXhKBUuMRD96L9nbVoOU3_go788oI_AZQdr0gFSaMS.GqQ4rOTesrRl0kaNeaa X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5DF06.6090806@netconfcentral.com> Date: Wed, 14 Oct 2009 07:24:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910141343.n9EDhDP3011451@idle.juniper.net> In-Reply-To: <200910141343.n9EDhDP3011451@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 14:23:45 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It is fine with me if the server MAY create a system-creatable >> node (in candidate) any time from the edit-config to the commit, so it >> allows all implementation strategies. > > This would be ambiguous about the results. Consider: > > > ... > > > one > > > two > 2000 > > > > > If the system starts numbering user uids at 2000 (as JUNOS does), > then the results of generating uids could be an error if the user > "one" is assigned uid 2000 when the tag is seen. A similar > scenario exists for multiple s before a , > but this is probably less interesting. > > How much do we care about this case? How worried are we over the > interoperability differences caused by allowing the vendor to choose > when s-c leafs are created? (Does it seem like we're on odd sides > of this one?) > This is data-model specific: leaf asset-tag { type string; system-creatable true; // the server will use its default service tag string // built into the hardware, if this leaf is not set } In this example, the server knows right away what value it will use, and if the instrumentation callback creates the asset-tag leaf during the commit, then so what? What problem does that cause? None. It is just an implementation choice, made for a specific leaf. >> The text about the server MUST create s-c node at commit time is a CLR. >> Just as before, the client cannot count on the state of >> every candidate implementation to change the same way. >> YANG only describes a valid configuration -- the contents >> of the running config after the commit. > > I want the constraints in YANG to be applicable inside the client, > so outgoing config can be validated. This gives s-c leaf creation > a post-validation timeframe. > leaf foo { must "../bar = 3"; type string; } leaf bar { type uint32; system-creatable true; } I want a validation model that is independent of how a data node is created. All validation breaks in your design. Even if the server sets 'bar' to 3, the 'foo' leaf will still be invalid because the must-expr will evaluate to false if the 'bar' leaf is not present. The model imposes a false requirement -- that the client set both 'foo' and 'bar' -- even though this is not the intent of the data modeler or required by the protocol. > Thanks, > Phil > Andy From j.schoenwaelder@jacobs-university.de Wed Oct 14 07:35: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 4DBCC3A6A0F for ; Wed, 14 Oct 2009 07:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=0.952, 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 Sr8sXvYp2LP7 for ; Wed, 14 Oct 2009 07:35:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7125A3A6A0D for ; Wed, 14 Oct 2009 07:35:08 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8343FC001A; Wed, 14 Oct 2009 16:35: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 1+DoKdW0+c-V; Wed, 14 Oct 2009 16:35: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 297DEC000F; Wed, 14 Oct 2009 16:35:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9575BD1DE8F; Wed, 14 Oct 2009 16:35:08 +0200 (CEST) Date: Wed, 14 Oct 2009 16:35:08 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091014143508.GA21182@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , "netmod@ietf.org" References: <20091014121148.GB20756@elstar.local> <200910141334.n9EDYKrg011332@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910141334.n9EDYKrg011332@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:35:09 -0000 On Wed, Oct 14, 2009 at 03:34:20PM +0200, Phil Shafer wrote: > >What about other operations, such as copy-config? It might help to > >have all the relevant cases clearly spelled out... > > Copy-config should not change data, so it should not create s-c leafs. Quoting RFC 4741: https://user@example.com:passphrase/cfg/new.txt Even if the URL points to a local file, the local file might not contain all s-c instances, e.g. leave the uid out. So you are saying such a copy will fail? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Oct 14 07:36: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 412003A6A1A for ; Wed, 14 Oct 2009 07:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_50=0.001, UNPARSEABLE_RELAY=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 an8pgGYwy4WG for ; Wed, 14 Oct 2009 07:36:10 -0700 (PDT) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by core3.amsl.com (Postfix) with SMTP id 6DECF3A6A1F for ; Wed, 14 Oct 2009 07:36:10 -0700 (PDT) Received: from [68.142.194.243] by n23.bullet.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 14:36:09 -0000 Received: from [68.142.201.242] by t1.bullet.mud.yahoo.com with NNFMP; 14 Oct 2009 14:36:09 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 14:36:09 -0000 X-Yahoo-Newman-Id: 586224.58436.bm@omp403.mail.mud.yahoo.com Received: (qmail 37468 invoked from network); 14 Oct 2009 14:36:09 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 07:36:09 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YQXKbqQVM1mVCHlK8BW9FrSXUYE6DA2Ih.bjYl.Hi8Fwc19OX3hA_90rTQbJWICsY9iDHivXxiEbRKQ48iIhq1gzylFdRCV3eH5gZQGYlPWNQeN_FKdz0rxVagWW2cNckVXfRllXrcKBHagEGhK1todomBi5JqHH5vOeHr0BBQf.ezL_3P8PKm9svXEIhpND44Ctw4z3hEXI5UjuF9qJvp.DxHPzDHz0Vq_m X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5E1EF.3060108@netconfcentral.com> Date: Wed, 14 Oct 2009 07:36:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] YANG validation model X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 14:36:11 -0000 Hi, I think we have a large disconnect between those who want YANG semantics to apply to the operator-provided static list of instructions, and those who want to apply the semantics to a conceptual running system. IMO, the config-file design is fatally flawed, because the subset of all configuration instructions provided by the operator is completely arbitrary. It is impossible to write referential integrity tests against an arbitrary subset of the conceptual system. The semantics of every YANG object and constraint are written such that they describe the behavior of the running system. They never describe the contents of the config file. This is how SMIv2 has worked for over 2 decades, and I see no reason for IETF data models written in YANG to be done differently. Andy From phil@juniper.net Wed Oct 14 07:41: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 968B13A6A09 for ; Wed, 14 Oct 2009 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 1NCe-g9qYzpQ for ; Wed, 14 Oct 2009 07:41:10 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id AE3AC3A6A10 for ; Wed, 14 Oct 2009 07:41:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKStXjB70uxCuz3gZT61W8xOBrre6R+voi@postini.com; Wed, 14 Oct 2009 07:41:13 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 07:34:47 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 07:34:47 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 07:34:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 07:34:46 -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 n9EEYjj67830; Wed, 14 Oct 2009 07:34:45 -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 n9EELvdx012099; Wed, 14 Oct 2009 14:21:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141421.n9EELvdx012099@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD5DF06.6090806@netconfcentral.com> Date: Wed, 14 Oct 2009 10:21:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 14:34:46.0495 (UTC) FILETIME=[7A2F4EF0:01CA4CDB] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 14:41:12 -0000 Andy Bierman writes: > leaf asset-tag { > type string; > system-creatable true; > // the server will use its default service tag string > // built into the hardware, if this leaf is not set > } How is a hardware-based asset-tag is configuration data? What happens when you swap the hardware? This is a bad use case. >Even if the server sets 'bar' to 3, >the 'foo' leaf will still be invalid >because the must-expr will evaluate to false >if the 'bar' leaf is not present. This would be a bad data model, since it's modeling a constraint that cannot be enforced. Thanks, Phil From phil@juniper.net Wed Oct 14 07:44: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 3EFEE3A6A09 for ; Wed, 14 Oct 2009 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ziZXnb928s7w for ; Wed, 14 Oct 2009 07:44:33 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id A940C3A6A25 for ; Wed, 14 Oct 2009 07:44:32 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKStXjzuzW5sihNyERpMLDNMj/PaDPopLq@postini.com; Wed, 14 Oct 2009 07:44:35 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 07:38:12 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 07:38:12 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 07:38:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 07:38:10 -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 n9EEc9j69123; Wed, 14 Oct 2009 07:38:09 -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 n9EEPKZK012283; Wed, 14 Oct 2009 14:25:21 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141425.n9EEPKZK012283@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091014143508.GA21182@elstar.local> Date: Wed, 14 Oct 2009 10:25:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 14:38:10.0926 (UTC) FILETIME=[F40900E0:01CA4CDB] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 14:44:34 -0000 Juergen Schoenwaelder writes: >Even if the URL points to a local file, the local file might not >contain all s-c instances, e.g. leave the uid out. So you are saying >such a copy will fail? Nope, my bad. I was thinking about candidate, not running. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Oct 14 07:47: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 ABD3528C13F for ; Wed, 14 Oct 2009 07:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=-0.168, 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 UJQoqSKP4pC3 for ; Wed, 14 Oct 2009 07:47:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AE2CB28C10F for ; Wed, 14 Oct 2009 07:47:51 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C86BBC0018; Wed, 14 Oct 2009 16:47:53 +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 kmxHQ8d2Ufmy; Wed, 14 Oct 2009 16:47:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9E7BC000F; Wed, 14 Oct 2009 16:47:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4DEA5D1DF45; Wed, 14 Oct 2009 16:47:52 +0200 (CEST) Date: Wed, 14 Oct 2009 16:47:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091014144752.GA21290@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4AD5E1EF.3060108@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD5E1EF.3060108@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YANG validation model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:47:52 -0000 On Wed, Oct 14, 2009 at 04:36:31PM +0200, Andy Bierman wrote: > The semantics of every YANG object and constraint > are written such that they describe the behavior > of the running system. They never describe the > contents of the config file. > > This is how SMIv2 has worked for over 2 decades, > and I see no reason for IETF data models written in YANG > to be done differently. Yes, there apparently is a disconnect. Configuration is not the same as operational state. SMIv2 messed this up, we are trying to fix it. It might take some time to get used to this distinction. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Oct 14 08:03: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 591A93A6916 for ; Wed, 14 Oct 2009 08:03:33 -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 z01oHKOUTsvc for ; Wed, 14 Oct 2009 08:03:32 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 2B2FB3A6A26 for ; Wed, 14 Oct 2009 08:03:28 -0700 (PDT) Received: (qmail 61766 invoked from network); 14 Oct 2009 15:03:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 15:03:27 -0000 X-YMail-OSG: QHjW43kVM1k4YLHbbnzZAwyzRJ51joD_ZHmN8sT408WnUkjKYoMxIAe1yIV1JuakWl37juBm8DTaqlUuZ2hhNy3vsmrenh4B.FXqYNONr8gknG4fRH59s_olb67kzvEJrJbVn5UQFySywoe_g2EbCMkh5LQUClg80gynlFQP.eg_1OzP9NJnhCrzJdJ8c0pD8ElsUW81nbImPlcGoa8qEwD.LNoHPQErbiHUuDkzpK14kwGDIgk16sjfk5FgnJFFUcqzhRYUZx5g7ItnrNFpFnpvkafw7BTCX2rcAbHIcSsDvShjRK5z4SwlT7pgAGK3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5E855.1060909@netconfcentral.com> Date: Wed, 14 Oct 2009 08:03:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <4AD5E1EF.3060108@netconfcentral.com> <20091014144752.GA21290@elstar.local> In-Reply-To: <20091014144752.GA21290@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG validation model X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 15:03:33 -0000 Juergen Schoenwaelder wrote: > On Wed, Oct 14, 2009 at 04:36:31PM +0200, Andy Bierman wrote: > >> The semantics of every YANG object and constraint >> are written such that they describe the behavior >> of the running system. They never describe the >> contents of the config file. >> >> This is how SMIv2 has worked for over 2 decades, >> and I see no reason for IETF data models written in YANG >> to be done differently. > > Yes, there apparently is a disconnect. Configuration is not the same > as operational state. SMIv2 messed this up, we are trying to fix it. > It might take some time to get used to this distinction. > I disagree. SNMP got it right. Your definition of configuration is an arbitrary subset of all the parameters that make up operational behavior. Good luck trying to force operators to explicitly set every single leaf that may ever show up in a must/when or other YANG constraint. Good luck converting any SMIv2 semantics to YANG semantics, and training every data modeler to write constraints that apply to the arbitrary set of explicit commands, instead of to the running system. In the big-feature-enabled example, the data modeler does not care who sets the interface MTU. The only thing that matters is the operational value in use on the system. The constraint does does mean 'only allow this feature if an operator has specifically requested a large MTU size'. If YANG cannot support this simple use-case, what can it do? > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Oct 14 08:06: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 2BAEB3A6919 for ; Wed, 14 Oct 2009 08:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 l8L9gDbY98Fg for ; Wed, 14 Oct 2009 08:06:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5626F3A6A1B for ; Wed, 14 Oct 2009 08:06:01 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 754A7C000F; Wed, 14 Oct 2009 17:06:03 +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 plw9wEneu2Wm; Wed, 14 Oct 2009 17:06:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C511C0018; Wed, 14 Oct 2009 17:06:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 238A0D1E192; Wed, 14 Oct 2009 17:06:02 +0200 (CEST) Date: Wed, 14 Oct 2009 17:06:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091014150602.GA21485@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4AD5E1EF.3060108@netconfcentral.com> <20091014144752.GA21290@elstar.local> <4AD5E855.1060909@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD5E855.1060909@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YANG validation model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 15:06:02 -0000 On Wed, Oct 14, 2009 at 05:03:49PM +0200, Andy Bierman wrote: > I disagree. > SNMP got it right. Fine, we disagree. Not for the first time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Oct 14 08:25: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 38C1728C160 for ; Wed, 14 Oct 2009 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 6XobKYRvE-fG for ; Wed, 14 Oct 2009 08:25:24 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 9C09528C15E for ; Wed, 14 Oct 2009 08:25:24 -0700 (PDT) Received: (qmail 18038 invoked from network); 14 Oct 2009 15:25:24 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 08:25:24 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: WHGBYQkVM1kau8tqbs1KdBEJcz6e54gi9POskR5O2cD82gQZCgmX6KyjYAkob3OYGu4vNh2W0VTs76grMuaaszNDJDUgkpqmSI7VaDIEl7ihIz7Cnt4SgZj_m49RAFx7sCQfGyxxYyjRazRUc8jdyo_YFKHi.D1.Uu8fHiBuE2Qieer0HpD2w1fwkFf.gFPLPgB0aFSob.cKvxQSxd6tWcIDqfgDNQdjA_ONBLXO1U46fWj6zVmkpnAXoAaGYgib X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5ED7A.4060702@netconfcentral.com> Date: Wed, 14 Oct 2009 08:25:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910141421.n9EELvdx012099@idle.juniper.net> In-Reply-To: <200910141421.n9EELvdx012099@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 15:25:25 -0000 Phil Shafer wrote: > Andy Bierman writes: >> leaf asset-tag { >> type string; >> system-creatable true; >> // the server will use its default service tag string >> // built into the hardware, if this leaf is not set >> } > > How is a hardware-based asset-tag is configuration data? What > happens when you swap the hardware? This is a bad use case. > The HW is soldered on the MB and cannot be replaced. What problems are caused by allowing the server to create a leaf in candidate? Perhaps the problem is that we 100% disagree on the validation model. There are plenty of people who do not want the validation rules to work if the client sets a value, and fail if the server sets a value. There is no way either camp is going to convince the other that they are right. >> Even if the server sets 'bar' to 3, >> the 'foo' leaf will still be invalid >> because the must-expr will evaluate to false >> if the 'bar' leaf is not present. > > This would be a bad data model, since it's modeling a constraint > that cannot be enforced. > In your implementation maybe. There is no way that operators are going to explicitly set every node that is part of a YANG constraint, or fail every commit if they don't. > Thanks, > Phil > Andy From andy@netconfcentral.com Wed Oct 14 08:42: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 EDF8E3A69AB for ; Wed, 14 Oct 2009 08:42:16 -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 JSRsYISNJNGT for ; Wed, 14 Oct 2009 08:42:16 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 41C413A68A6 for ; Wed, 14 Oct 2009 08:42:16 -0700 (PDT) Received: (qmail 31972 invoked from network); 14 Oct 2009 15:42:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 15:42:16 -0000 X-YMail-OSG: 37FZf2YVM1n3wNo78RcYSBdR4t1LT7Q1oPls3UCZGIt3O9ofU4MAwSOiI5fIiC5TW3B7twOXY0YRodkZr3GqLjpgcrMFeAfzPxhOkDqEARqDd18bvJll7T1UBEsVOFUZ.Dg26W5upK6scS3P61I0nwniazdh3l6ckyuK53EpSQWTV5Adec_yqPucnbEYSQJqLxXCncsl1AEHl4ARJ85AuTG_ecKSqbB4oWQNCKLzNSqwSX06nRPthvEorLFqjlpAlK_3lQppUp3kRo50jZmB9XNC1GBO3KgV0KhO_C08pb5I0xrS.ow6brCKeE5aXq0AIg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5F16F.1030008@netconfcentral.com> Date: Wed, 14 Oct 2009 08:42:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 15:42:17 -0000 Hi, IMO, there is no consensus on system-creatable nodes. Since the WG is already way behind schedule, I propose that the YANG spec be frozen at -07 and no standardization of s-c leafs be done at this time. Let's focus only on errors in the -07 text, so that a final WGLC can be held and the document set can be forwarded to the IESG this year. Andy From lhotka@cesnet.cz Wed Oct 14 08:44: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 1F5623A6830 for ; Wed, 14 Oct 2009 08:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3OmxIHrul9Y for ; Wed, 14 Oct 2009 08:44:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 62EAE3A69AB for ; Wed, 14 Oct 2009 08:44:43 -0700 (PDT) Received: from [10.0.0.47] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id 9E692D800BD; Wed, 14 Oct 2009 17:44:44 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4AD5ED7A.4060702@netconfcentral.com> References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 17:44:41 +0200 Message-Id: <1255535081.6653.104.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 15:44:44 -0000 Andy Bierman píše v St 14. 10. 2009 v 08:25 -0700: > Perhaps the problem is that we 100% disagree on the > validation model. There are plenty of people > who do not want the validation rules to work if > the client sets a value, and fail if the server sets a value. > My understanding is that both will succeed because the schema will be lax for such s-c leafs. Lada > _______________________________________________ > 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 Oct 14 09:20: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 7CB673A67DB for ; Wed, 14 Oct 2009 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.325, 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 fUIYdYF1hzqE for ; Wed, 14 Oct 2009 09:20: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 AD16528C141 for ; Wed, 14 Oct 2009 09:20:15 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D5ED61A009; Wed, 14 Oct 2009 18:20:17 +0200 (CEST) Date: Wed, 14 Oct 2009 18:20:16 +0200 (CEST) Message-Id: <20091014.182016.230836725.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AD5ED7A.4060702@netconfcentral.com> References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:20:16 -0000 Andy Bierman wrote: > Perhaps the problem is that we 100% disagree on the > validation model. There are plenty of people > who do not want the validation rules to work if > the client sets a value, and fail if the server sets a value. I have to ask. Who wants the opposite? Remember that Phil suggested: "When the system creates a value for a leaf, the value MUST NOT break any constraints in the YANG module.". which I agreed with. /martin From andy@netconfcentral.com Wed Oct 14 09:21: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 66CB43A6816 for ; Wed, 14 Oct 2009 09:21:00 -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 4I4pR4j5HoKn for ; Wed, 14 Oct 2009 09:20:59 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 9A7B83A67DB for ; Wed, 14 Oct 2009 09:20:59 -0700 (PDT) Received: (qmail 72265 invoked from network); 14 Oct 2009 16:21:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 16:21:00 -0000 X-YMail-OSG: vu2L1pQVM1kHO1hqDagYmMX8VQpd._AiLb_ePOs7fGyTSZ6W6fNkEWF6M3KnBx4WPhc.8GCjVMXlb3VRZYj8okuTqOH1bnI1Jwk3wPSmvYQLR.LTn14feR83zRjknIYBHV_if3aiQx9sqhqdOb4CIBMEU55c5IpFm0U_kdskkdxMDlRfdqskw4DJ_CgA6MR2qcaZU5RHnn5K6EXo_uNf1vr9fBbeOWldUiNiHZOHd0rD_1qiFnomlcCWc_xjBpgem9yOAsuTerIWJIZtqLSN795qWNhBRHsmBYhfZHOA4JAI2g0tT_b15fx2MghMxULtmw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5FA81.10105@netconfcentral.com> Date: Wed, 14 Oct 2009 09:21:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> <1255535081.6653.104.camel@missotis> In-Reply-To: <1255535081.6653.104.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:21:00 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 14. 10. 2009 v 08:25 -0700: > >> Perhaps the problem is that we 100% disagree on the >> validation model. There are plenty of people >> who do not want the validation rules to work if >> the client sets a value, and fail if the server sets a value. >> > > My understanding is that both will succeed because the schema will be > lax for such s-c leafs. > What does lax mean here? How are you going to enforce must "../foo = 3" or any XPath that references a s-c node? Evaluating ../foo --> null --> false will cause the commit to fail. Ignoring it it the DSDL schema is going to produce a model that does not represent the author's intentions. I don't understand the fascination with server-created vs. client-created, or default vs. non-default value. I don't understand why a server-created leaf exists for validation purposes if it contains the YANG default, but it doesn't exist if it contains a non-default value. I do not accept the problem statement that YANG and NETCONF should focus on the client-provided instructions instead of the desired state of the running system. > Lada Andy From jmh@joelhalpern.com Wed Oct 14 09:23:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BBF3A688B for ; Wed, 14 Oct 2009 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 WY10WNp03enM for ; Wed, 14 Oct 2009 09:23:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 023133A67DB for ; Wed, 14 Oct 2009 09:23:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B765A32317B4; Wed, 14 Oct 2009 09:23:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id DB0E53231776; Wed, 14 Oct 2009 09:23:40 -0700 (PDT) Message-ID: <4AD5FB0B.7090903@joelhalpern.com> Date: Wed, 14 Oct 2009 12:23:39 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <200910141343.n9EDhDP3011451@idle.juniper.net> <4AD5DF06.6090806@netconfcentral.com> In-Reply-To: <4AD5DF06.6090806@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:23:39 -0000 This highlights the risk I see with having s-c leaves appear in candidate when a commit fails. (Note for clarity, I can live with the consequences, and if it will get us off the dime, lets just write it all down and move forward. But we need to be aware of them.) Suppose instead of the backplane specific tag Andy was referring to, it was indeed a board specific tag. (Please excuse the improper and sloppy YANG. I think it still gets the point of this discussion across.) dontainer declaration of some kind { leaf board-select { description "which board" } leaf assignable-board-property { type string; system-creatable true; // if not set, will be set from the board hardware } leaf board-max-ports { type int; system-creatable true; // the maximum number of ports // that the config wants to use // the system will fill this in from the board // if not specified. // config will fail if the number exceeds the hardware limit } list of some kind { leaf port { type int; must expression that checks against part board-max-ports } leaf port-properties {...} } So the user does a set against candidate. The information provided by the user is a board-select, and a set of port setups. When the user does a commit, at some point the system fills in the assignable-board-property and board-max-ports. On the one hand, the suggested must check is impossible if we prohibit must expressions from pointing at system-createable (in this case system-created) fields. Now suppose that the commit fails. The user looks, and realizes that they pointed at the wrong board. So they do a further edit, just changing the board-select field. And do another commit. 1) If the system did set board-max-ports in the candidate, then it is still set. So the config will fail even though the new board has enough ports. 2) Suppose there was no board-max-ports and no MUST. The first config fails for some other reason. The assignable-board-property will still be sest to the property from the first board, even though it is clearly the second board property that the user intends. Note that tagging things system-createable makes it easier to discuss the problem, but is not actually the source of the difficulty. The same confusion about when things are created, with what values, existed before. Thank you, Joel Andy Bierman wrote: ... > This is data-model specific: > > leaf asset-tag { > type string; > system-creatable true; > // the server will use its default service tag string > // built into the hardware, if this leaf is not set > } > ... From jmh@joelhalpern.com Wed Oct 14 09:25: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 A36C83A6898 for ; Wed, 14 Oct 2009 09:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 FgVbN8CDVcwK for ; Wed, 14 Oct 2009 09:25:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0074C3A688B for ; Wed, 14 Oct 2009 09:25:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B683132317C7; Wed, 14 Oct 2009 09:25:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 06F3032317C6; Wed, 14 Oct 2009 09:25:51 -0700 (PDT) Message-ID: <4AD5FB8E.3060103@joelhalpern.com> Date: Wed, 14 Oct 2009 12:25:50 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4AD5F16F.1030008@netconfcentral.com> In-Reply-To: <4AD5F16F.1030008@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:25:50 -0000 Unfortunately, I believe that the problem, and the inconsistency in behavior, that are described in the discussion of system-createable are just as ambiguous (if not more so) if we do not define the statement. So I think we need to figure out how we want the system to work. Once we agree on that, I think we can then quickly decide what to do with the s-c statement. (For myself, the mere fact that it helps in elucidating the issues suggests that it is a very useful statement for the data modeler.) Yours, Joel Andy Bierman wrote: > Hi, > > IMO, there is no consensus on system-creatable nodes. > Since the WG is already way behind schedule, > I propose that the YANG spec be frozen at -07 > and no standardization of s-c leafs be done > at this time. > > Let's focus only on errors in the -07 text, > so that a final WGLC can be held > and the document set can be forwarded > to the IESG this year. > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From phil@juniper.net Wed Oct 14 09:27: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 134AF3A6899 for ; Wed, 14 Oct 2009 09:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 RW5EbNCZbZSV for ; Wed, 14 Oct 2009 09:27:40 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id B8E9C28C141 for ; Wed, 14 Oct 2009 09:27:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKStX798NuRVvqkzfH7KLxdfIqjvrQdB6o@postini.com; Wed, 14 Oct 2009 09:27:42 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 09:17:05 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:17:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:17:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:17:04 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9EGH3j18512; Wed, 14 Oct 2009 09:17: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 n9EG4E8v013186; Wed, 14 Oct 2009 16:04:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141604.n9EG4E8v013186@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD5ED7A.4060702@netconfcentral.com> Date: Wed, 14 Oct 2009 12:04:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 16:17:04.0096 (UTC) FILETIME=[C47AE600:01CA4CE9] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:27:41 -0000 Andy Bierman writes: >The HW is soldered on the MB and cannot be replaced. If you swap the MB, should restoring an archived config give the new MB the asset tag of the old MB? I'm assuming not, so this isn't config data. >There are plenty of people >who do not want the validation rules to work if >the client sets a value, and fail if the server sets a value. My guess is that the number of people who what validation rules to work on the client and fail on the server is zero. Another strawman? >There is no way that operators are going to >explicitly set every node that is part of >a YANG constraint, or fail every commit if they don't. The model's constraints will need to be written in a way that avoid scenarios like this. Your foo/bar model does not, so it's a bad data model. Thanks, Phil From phil@juniper.net Wed Oct 14 09:28: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 987093A6833 for ; Wed, 14 Oct 2009 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 l+mNKqsiL+eT for ; Wed, 14 Oct 2009 09:28:59 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id EE7E93A67C0 for ; Wed, 14 Oct 2009 09:28:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKStX8TC6kSoUEDeRruihOSgieDpXPvkEO@postini.com; Wed, 14 Oct 2009 09:29: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.375.2; Wed, 14 Oct 2009 09:18:24 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:18:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:18:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:18: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 n9EGILj19208; Wed, 14 Oct 2009 09:18: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 n9EG5WJm013205; Wed, 14 Oct 2009 16:05:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141605.n9EG5WJm013205@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD5F16F.1030008@netconfcentral.com> Date: Wed, 14 Oct 2009 12:05:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 16:18:22.0640 (UTC) FILETIME=[F34BC300:01CA4CE9] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:28:59 -0000 Andy Bierman writes: >IMO, there is no consensus on system-creatable nodes. Perhaps we should call for a concensus before declaring one. WG chairs, would this be possible? Thanks, Phil From lhotka@cesnet.cz Wed Oct 14 09:30: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 7806928C141 for ; Wed, 14 Oct 2009 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2W5zpMh0u6W for ; Wed, 14 Oct 2009 09:30:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 252093A694E for ; Wed, 14 Oct 2009 09:30:33 -0700 (PDT) Received: from [10.0.0.47] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id A8DB5D800C8; Wed, 14 Oct 2009 18:30:34 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4AD5FB8E.3060103@joelhalpern.com> References: <4AD5F16F.1030008@netconfcentral.com> <4AD5FB8E.3060103@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 18:30:32 +0200 Message-Id: <1255537832.6653.107.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:30:34 -0000 Joel M. Halpern píše v St 14. 10. 2009 v 12:25 -0400: > Unfortunately, I believe that the problem, and the inconsistency in > behavior, that are described in the discussion of system-createable are > just as ambiguous (if not more so) if we do not define the statement. > So I think we need to figure out how we want the system to work. > Once we agree on that, I think we can then quickly decide what to do > with the s-c statement. (For myself, the mere fact that it helps in > elucidating the issues suggests that it is a very useful statement for > the data modeler.) +1. Also, it would be quite useful to gain some practical experience with different implementation of YANG to see whether it is a real problem. Lada > > Yours, > Joel > > Andy Bierman wrote: > > Hi, > > > > IMO, there is no consensus on system-creatable nodes. > > Since the WG is already way behind schedule, > > I propose that the YANG spec be frozen at -07 > > and no standardization of s-c leafs be done > > at this time. > > > > Let's focus only on errors in the -07 text, > > so that a final WGLC can be held > > and the document set can be forwarded > > to the IESG this year. > > > > > > Andy > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Wed Oct 14 09:32: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 5945B28C141 for ; Wed, 14 Oct 2009 09:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 ky8BGVzPtiEE for ; Wed, 14 Oct 2009 09:32:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7308428C118 for ; Wed, 14 Oct 2009 09:32:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3AAEE32317BD; Wed, 14 Oct 2009 09:32:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 85B7932317AE; Wed, 14 Oct 2009 09:32:09 -0700 (PDT) Message-ID: <4AD5FD08.5040809@joelhalpern.com> Date: Wed, 14 Oct 2009 12:32:08 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> <20091014.182016.230836725.mbj@tail-f.com> In-Reply-To: <20091014.182016.230836725.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:32:09 -0000 Every time I read that statement, I stop and stare at it. I can not prove it, but I strongly suspect that the constraint as defined is unmeetable. That is, one can not define a data model that allows for real hardware constraints (i.e. it fails if you ask the hardware to do something impossible), that also requires all s-c nodes to meet all constraints. In the abstract, there can be an s-c node N that is defined by must expressions to have properties p1 relative to a node N1 and P2 relative to node N2, such that there are values V1 and V2 of nodes N1 and N2 that are mutually fine (no must expression is violated by setting N1 to V1 and N2 to V2), but there is no value V for N is ch that P1(V, V1) and P2(V, V2). If I try to write a specific example, I am sure one would say "don't do that". But I strongly suspect complex indirect examples are quite possible, and hard for the modeler to avoid. Yours, Joel Martin Bjorklund wrote: > Andy Bierman wrote: >> Perhaps the problem is that we 100% disagree on the >> validation model. There are plenty of people >> who do not want the validation rules to work if >> the client sets a value, and fail if the server sets a value. > > I have to ask. Who wants the opposite? > > Remember that Phil suggested: > > "When the system creates a value for a leaf, the value MUST NOT > break any constraints in the YANG module.". > > which I agreed with. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Wed Oct 14 09:32: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 3D22628C14E for ; Wed, 14 Oct 2009 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u18lg12csqL for ; Wed, 14 Oct 2009 09:32:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5B9E728C191 for ; Wed, 14 Oct 2009 09:32:39 -0700 (PDT) Received: from [10.0.0.47] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id 6DFCDD800C8; Wed, 14 Oct 2009 18:32:41 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4AD5FA81.10105@netconfcentral.com> References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> <1255535081.6653.104.camel@missotis> <4AD5FA81.10105@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 18:32:30 +0200 Message-Id: <1255537950.6653.109.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:32:40 -0000 Andy Bierman píše v St 14. 10. 2009 v 09:21 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v St 14. 10. 2009 v 08:25 -0700: > > > >> Perhaps the problem is that we 100% disagree on the > >> validation model. There are plenty of people > >> who do not want the validation rules to work if > >> the client sets a value, and fail if the server sets a value. > >> > > > > My understanding is that both will succeed because the schema will be > > lax for such s-c leafs. > > > > What does lax mean here? I mean that the leaf will be optional from the schema POV. Lada > How are you going to enforce must "../foo = 3" > or any XPath that references a s-c node? > Evaluating ../foo --> null --> false will > cause the commit to fail. Ignoring it > it the DSDL schema is going to produce > a model that does not represent the author's intentions. > > I don't understand the fascination with server-created > vs. client-created, or default vs. non-default value. > I don't understand why a server-created leaf exists > for validation purposes if it contains the YANG default, > but it doesn't exist if it contains a non-default value. > > I do not accept the problem statement that YANG and > NETCONF should focus on the client-provided instructions > instead of the desired state of the running system. > > > > Lada > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Oct 14 09:43:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562D928C13F for ; Wed, 14 Oct 2009 09:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fShebB81xlLf for ; Wed, 14 Oct 2009 09:43:58 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 70A2F3A67EF for ; Wed, 14 Oct 2009 09:43:58 -0700 (PDT) Received: (qmail 71511 invoked from network); 14 Oct 2009 16:44:01 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 14 Oct 2009 16:44:00 -0000 X-YMail-OSG: sWbBSUgVM1lWfxeBMNvw4smMMBkNkduqgyjOYZs8R4TvDaoXA3ETdJkvprhAJGkLa09jvNrTU2Md5x9VP5hCABkt32F9fDCM5EcwvoXY6dD2aFTUItooi5yJoPl1NT755tUZmQrKrppPAcJPeAzE6DHI9DH1B90tLawtIa0mv0KBfJzYS0gHyWAtTiGdtcJOJh_WAjNJ2sJaOQa4xGg.NTWVp4FNt5v0NdXLlW1rlnSNwVipFBxqLPPPZPjp80HT1Edzqx1yxUF5V2YXMKl2rRaeypsW5AgBztwBmBhzg4QIUvARogh4_mkkDCp6OZJGE0xTt462_wC4mV.a9WPHi6IftpSMw2N7Og-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD5FFE7.2050406@netconfcentral.com> Date: Wed, 14 Oct 2009 09:44:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4AD5F16F.1030008@netconfcentral.com> <4AD5FB8E.3060103@joelhalpern.com> In-Reply-To: <4AD5FB8E.3060103@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:43:59 -0000 Joel M. Halpern wrote: > Unfortunately, I believe that the problem, and the inconsistency in > behavior, that are described in the discussion of system-createable are > just as ambiguous (if not more so) if we do not define the statement. So > I think we need to figure out how we want the system to work. > Once we agree on that, I think we can then quickly decide what to do > with the s-c statement. (For myself, the mere fact that it helps in > elucidating the issues suggests that it is a very useful statement for > the data modeler.) > I am tired of being told that every legal YANG example I come up with is not config. According to YANG, it is config. What do you propose to do about YANG constraints that reference s-c nodes? Do you think the operator MUST provide a value for every leaf that is referenced in a YANG constraint? Lada seems to suggest the server should just ignore a constraint if any s-c leafs are involved. Do you think this is useful? Do you think the big-feature example is invalid? That it is illegal for a YANG constraint to refer to the operational value (i.e., don't care if server or client provided) or do you think the constraints refer to only client-provided values? If so, how is the YANG data modeler supposed to know which leafs the operator is going to want to set, and which ones it wants the dynamic defaults? Do you understand that offline validation is just as possible as before, if the server reports all leafs? That if the client validates a config based on explicit-filtered retrieval, this is altering the device data-set, so validation is broken before it starts? I don't see any consensus on the problem, the architecture, or the solution. So let's just leave it to the description-stmt to convey system-creatable details. > Yours, > Joel Andy > > Andy Bierman wrote: >> Hi, >> >> IMO, there is no consensus on system-creatable nodes. >> Since the WG is already way behind schedule, >> I propose that the YANG spec be frozen at -07 >> and no standardization of s-c leafs be done >> at this time. >> >> Let's focus only on errors in the -07 text, >> so that a final WGLC can be held >> and the document set can be forwarded >> to the IESG this year. >> >> >> Andy >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From andy@netconfcentral.com Wed Oct 14 09:48: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 2229228C1DB for ; Wed, 14 Oct 2009 09:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 tqyJyJeDsa-b for ; Wed, 14 Oct 2009 09:48:29 -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 F2AD728C1AC for ; Wed, 14 Oct 2009 09:48:20 -0700 (PDT) Received: (qmail 44830 invoked from network); 14 Oct 2009 16:48:21 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 09:48:21 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 3pXGvE4VM1mLxWz5D4umy14HcUsKp5t6lG33XjyT071NDzhaaGBHIHOl1soaFVO43TbpVaN8WY2NFG72qku0mjXb56.I0R2cs6YXUkJ7QEVwNLoro1GjRrlpYL8i9rGYyqvCH4Xl4l9G79DVkE1ZMIJpqFOzz5cBNaVBKYfvR4.Qirqm.pndho6lD9_f5Gy_2u9nCcW1izoTK6hjVxuQuL3gVW8vOuQ54f0Zvm10wkdL6bIviMxqo8t4dT3ESb6g X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD600EB.8040108@netconfcentral.com> Date: Wed, 14 Oct 2009 09:48:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> <1255535081.6653.104.camel@missotis> <4AD5FA81.10105@netconfcentral.com> <1255537950.6653.109.camel@missotis> In-Reply-To: <1255537950.6653.109.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:48:30 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 14. 10. 2009 v 09:21 -0700: >> Ladislav Lhotka wrote: >>> Andy Bierman píše v St 14. 10. 2009 v 08:25 -0700: >>> >>>> Perhaps the problem is that we 100% disagree on the >>>> validation model. There are plenty of people >>>> who do not want the validation rules to work if >>>> the client sets a value, and fail if the server sets a value. >>>> >>> My understanding is that both will succeed because the schema will be >>> lax for such s-c leafs. >>> >> What does lax mean here? > > I mean that the leaf will be optional from the schema POV. > Then your machine-generated implementation of the model will be incorrect. The author used a must statement. There is nothing optional about that. > Lada Andy From mbj@tail-f.com Wed Oct 14 09:52: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 56CC428C1D0 for ; Wed, 14 Oct 2009 09:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.260, 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 O6GnlyTUP6Ko for ; Wed, 14 Oct 2009 09:52:35 -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 729D728C1CF for ; Wed, 14 Oct 2009 09:52:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 846D361602A; Wed, 14 Oct 2009 18:52:37 +0200 (CEST) Date: Wed, 14 Oct 2009 18:52:37 +0200 (CEST) Message-Id: <20091014.185237.249057461.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4AD5FD08.5040809@joelhalpern.com> References: <4AD5ED7A.4060702@netconfcentral.com> <20091014.182016.230836725.mbj@tail-f.com> <4AD5FD08.5040809@joelhalpern.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 16:52:36 -0000 "Joel M. Halpern" wrote: > Every time I read that statement, I stop and stare at it. There are a couple of cases. 1. If there is a must expression on the s-c node itself, it will not be evaluated until the node exists, so when the server creates a value, it must pick a value that doesn't break the must expression (or not pick a value) 2. If there is a must expression that refers to a s-c node and requires the s-c leaf to exist, then it essentially makes the s-c mandatory instead (requiring the client to set it). 3. If there is a constraint (must or unique) that refers to the s-c node that can handle that the s-c node does not exist, the server must pick a value that doesn't break the constraint (or not pick a value). > I can not prove it, but I strongly suspect that the constraint as defined is > unmeetable. That is, one can not define a data model that allows for real > hardware constraints (i.e. it fails if you ask the hardware to do something > impossible), that also requires all s-c nodes to meet all constraints. > In the abstract, there can be an s-c node N that is defined by must expressions > to have properties p1 relative to a node N1 and P2 relative to node N2, such > that there are values V1 and V2 of nodes N1 and N2 that are mutually fine (no > must expression is violated by setting N1 to V1 and N2 to V2), but there is no > value V for N is ch that P1(V, V1) and P2(V, V2). > If I try to write a specific example, I am sure one would say "don't do that". > But I strongly suspect complex indirect examples are quite possible, and hard > for the modeler to avoid. But is this s-c specific? It seems the same thing can happen with a normal leaf. /martin From jmh@joelhalpern.com Wed Oct 14 10:02: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 27D073A68CC for ; Wed, 14 Oct 2009 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 H8sbPmTGoPpD for ; Wed, 14 Oct 2009 10:02:28 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7B1413A681D for ; Wed, 14 Oct 2009 10:02:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 44EA93231776; Wed, 14 Oct 2009 10:02:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 9116532317AA; Wed, 14 Oct 2009 10:02:30 -0700 (PDT) Message-ID: <4AD60425.6000201@joelhalpern.com> Date: Wed, 14 Oct 2009 13:02:29 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4AD5ED7A.4060702@netconfcentral.com> <20091014.182016.230836725.mbj@tail-f.com> <4AD5FD08.5040809@joelhalpern.com> <20091014.185237.249057461.mbj@tail-f.com> In-Reply-To: <20091014.185237.249057461.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 17:02:29 -0000 Below... Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> Every time I read that statement, I stop and stare at it. > ... description elided ... > > But is this s-c specific? It seems the same thing can happen with a > normal leaf. > > > /martin > The difference between the s-c case and the normal config case is that in the normal case, if the user produces an internally inconsistent config, then the user gets an error, and the user gets the task of figuring out how he wants to fix the problem. If the inconsistency is such that the system can not create a value for the node, and the system considers it needs the node (it can not be mandatory in the config, because that would mean the user had to create it), then the requirements have become unmeetable. It can be argued, and maybe should be argued, that this has nothing to do with tagging something system-createable. That we always allowed the system to create nodes, and that we therefore already had this constraint. The one difference with the statement is that up till now, it seemed to me the system was allowed to say "invalid config" when it could not create the node it needed with a sensible value. The statement from Phil about requiring s-c nodes to meet must constraints seems to say that the system will not do that. Yours, Joel From phil@juniper.net Wed Oct 14 10:07: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 49FD13A688B for ; Wed, 14 Oct 2009 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 nNMgb0ZaJy9n for ; Wed, 14 Oct 2009 10:07:42 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 3D46A3A67AB for ; Wed, 14 Oct 2009 10:07:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKStYFYMeAluwVn1RUBZX6V7gNDJ0P6dRs@postini.com; Wed, 14 Oct 2009 10:07:45 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 10:01: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); Wed, 14 Oct 2009 10:01:34 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 10:01:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 10:01: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 n9EH1Xj41910 for ; Wed, 14 Oct 2009 10:01: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 n9EGme4d013553 for ; Wed, 14 Oct 2009 16:48:40 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141648.n9EGme4d013553@idle.juniper.net> To: NETMOD Working Group Date: Wed, 14 Oct 2009 12:48:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 17:01:33.0807 (UTC) FILETIME=[FBC077F0:01CA4CEF] MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] What is 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, 14 Oct 2009 17:07:43 -0000 Andy Bierman writes: >According to YANG, it is config. Good point. What NETCONF and YANG lack is a good definition of what configuration is. I can point of the issues with making a leaf "config true" (like the save/restore issue) but lacking a real definition, we will be asking WG modelers to "know it when they see it", which will be difficult since many issues (like the save/restore one) aren't immediately obvious in their impact. So do we need (and can we) to agree on a definition of configuration data that is both straight forward enough to read and accurate enough to be useful? Thanks, Phil From andy@netconfcentral.com Wed Oct 14 10:08: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 C33543A67AB for ; Wed, 14 Oct 2009 10:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_05=-1.11, UNPARSEABLE_RELAY=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 oLZJlv460PQU for ; Wed, 14 Oct 2009 10:08:49 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id EC6D43A685A for ; Wed, 14 Oct 2009 10:08:48 -0700 (PDT) Received: from [68.142.200.226] by n20.bullet.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 17:08:49 -0000 Received: from [68.142.201.246] by t7.bullet.mud.yahoo.com with NNFMP; 14 Oct 2009 17:08:49 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 17:08:49 -0000 X-Yahoo-Newman-Id: 284972.71256.bm@omp407.mail.mud.yahoo.com Received: (qmail 35601 invoked from network); 14 Oct 2009 17:08:48 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 10:08:48 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: E7eQUQcVM1ky6_AUTK6zNdBWc3_9bCmH2WIH5PHpmf8nbX13lGtyhqVi9Gq34h7W.h5P_OZNjmLr4QlaFqrRh4hAlmRfaiGXnRqA_6ScgFr4rdedpJ5tu_2Zs7Fqxz3e2U_P2vyKh0KB.G3exn5.MyI.lVxqUtzTYqfe4N9wKx9P1wR1pb6CLhlL4dBJ7MuQqxL4cUIWbJK2KYWln6rZ9rklWd4r5pTUTA_wzyV0jEqC7Lk8Eu5JyQQohR2J4Px821QpsFbHfDQDNY03oaI3B8AzLOIFmXmWDBainEs7QkYYCrPqc4cK0Uyk X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD605B7.3040008@netconfcentral.com> Date: Wed, 14 Oct 2009 10:09:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4AD5ED7A.4060702@netconfcentral.com> <20091014.182016.230836725.mbj@tail-f.com> <4AD5FD08.5040809@joelhalpern.com> <20091014.185237.249057461.mbj@tail-f.com> <4AD60425.6000201@joelhalpern.com> In-Reply-To: <4AD60425.6000201@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 17:08:49 -0000 Joel M. Halpern wrote: > Below... > > Martin Bjorklund wrote: >> "Joel M. Halpern" wrote: >>> Every time I read that statement, I stop and stare at it. >> > ... description elided ... >> >> But is this s-c specific? It seems the same thing can happen with a >> normal leaf. >> leaf foo { must "../bar = 3"; type string; } leaf bar { type uint32; system-creatable true; } Is this legal YANG or not? Ignoring the must-expr sometimes is not an option. Either the s-c value (bar) exists for validation purposes, or this is a fatal error in the YANG compiler. >> >> /martin > > Yours, > Joel > Andy From phil@juniper.net Wed Oct 14 10:10: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 417363A685A for ; Wed, 14 Oct 2009 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Ngb+vIM97vxY for ; Wed, 14 Oct 2009 10:10:26 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 0D4D23A67AB for ; Wed, 14 Oct 2009 10:10:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKStYGAlFyvStkE5Ke/8UpLJ1jg4CpnpF7@postini.com; Wed, 14 Oct 2009 10:10:29 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 10:05: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); Wed, 14 Oct 2009 10:06:00 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 10:05:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 10:05: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 n9EH5wj43684; Wed, 14 Oct 2009 10:05:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9EGr9O3013648; Wed, 14 Oct 2009 16:53:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141653.n9EGr9O3013648@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4AD60425.6000201@joelhalpern.com> Date: Wed, 14 Oct 2009 12:53:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 17:05:58.0627 (UTC) FILETIME=[9998CB30:01CA4CF0] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 17:10:27 -0000 "Joel M. Halpern" writes: >If the inconsistency is such that the system can not create a value for >the node, and the system considers it needs the node (it can not be >mandatory in the config, because that would mean the user had to create >it), then the requirements have become unmeetable. Should we have the rule that must constraints cannot refer to s-c leafs? Also: we need a rule that says s-c leafs cannot be keys. Thanks, Phil From andy@netconfcentral.com Wed Oct 14 10:29: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 5FABB3A6A07 for ; Wed, 14 Oct 2009 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 TfdxSWjhj2dD for ; Wed, 14 Oct 2009 10:29:57 -0700 (PDT) Received: from n22.bullet.mail.mud.yahoo.com (n22.bullet.mail.mud.yahoo.com [68.142.206.161]) by core3.amsl.com (Postfix) with SMTP id 8958E3A69FC for ; Wed, 14 Oct 2009 10:29:57 -0700 (PDT) Received: from [68.142.200.221] by n22.bullet.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 17:29:57 -0000 Received: from [68.142.201.68] by t9.bullet.mud.yahoo.com with NNFMP; 14 Oct 2009 17:29:57 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 17:29:57 -0000 X-Yahoo-Newman-Id: 749660.98855.bm@omp420.mail.mud.yahoo.com Received: (qmail 40774 invoked from network); 14 Oct 2009 17:29:57 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 10:29:57 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: KRt_ei8VM1mgX0F66My3swUlXLTEF_RtMNQwPb13qx2JtTzMNt4LTk9RKLyvjlar0_qhUM2E7EaHUnZPjl_owjsnXHGcyXsaB49lUABzHxAYUbxt95_e539gL5..TCDM7RZ5cuCHvJ4cS3uFvw8kcsCSn6V5ejxBiDGJxUnXWfkc98PT6w0j10reVvNqBjuOfqHopnFe3._64idQqxnjnNJB7b4CJ9r4Gx_wf2EVgAHh1KkV0m7n9dk_uFuwWovp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD60AAB.9050800@netconfcentral.com> Date: Wed, 14 Oct 2009 10:30:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910141648.n9EGme4d013553@idle.juniper.net> In-Reply-To: <200910141648.n9EGme4d013553@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 14 Oct 2009 17:29:58 -0000 Phil Shafer wrote: > Andy Bierman writes: >> According to YANG, it is config. > > Good point. What NETCONF and YANG lack is a good definition of > what configuration is. I can point of the issues with making a > leaf "config true" (like the save/restore issue) but lacking a real > definition, we will be asking WG modelers to "know it when they see > it", which will be difficult since many issues (like the save/restore > one) aren't immediately obvious in their impact. > > So do we need (and can we) to agree on a definition of configuration > data that is both straight forward enough to read and accurate enough > to be useful? > Hmmm... Our problem is this dual-role leaf, that only becomes persistent in the NV-storage if the client requests it. We agree this is a useful implementation strategy and N/Y should support it. An s-c leaf can potentially change value at every reboot, so it is not persistent config. We agree on that. But the data-modeler writing YANG constraints has no way to guess which of the dual roles of this leaf to expect on an arbitrary server. Clearly, we do not want to force the operators to populate every leaf that is used in a constraint. I hope. Yet the must-ripple-effect in YANG is there -- it can change every leaf to mandatory=true that it references. Do we agree this doesn't work? Can it be fixed? The current definition of config=true for the scope of all XPath statements is useful and predicable. I don't think a validation model based only on the explicit commands is useful, and it certainly is not predictable. > Thanks, > Phil Andy From andy@netconfcentral.com Wed Oct 14 10:50: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 F28C128C172 for ; Wed, 14 Oct 2009 10:50: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.498, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 LkKXRvWDWdmP for ; Wed, 14 Oct 2009 10:50:51 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 1F5BD3A6814 for ; Wed, 14 Oct 2009 10:50:51 -0700 (PDT) Received: from [68.142.200.224] by n19.bullet.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 17:50:52 -0000 Received: from [68.142.201.68] by t5.bullet.mud.yahoo.com with NNFMP; 14 Oct 2009 17:50:52 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 17:50:52 -0000 X-Yahoo-Newman-Id: 15282.18593.bm@omp420.mail.mud.yahoo.com Received: (qmail 59621 invoked from network); 14 Oct 2009 17:50:51 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 10:50:51 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: t3NsXjEVM1myc.35Q60U98LCyruNrokErKVzR27vAUs3j_XXqG_pqcU1Jb8NmwCXQRgZej4AxRwkMRctxlwQ5i5e686uuNLJ2liuvZCUMMbBpq.2Rwi2MOpL.LP_dHDgb2kZlYJQZ5uAffSWb.B6i58fNwhmRVn4x1JuuWo1ZGioGF91DRae9gxMvnveK_lG2brrSUrlxOgoxu0.ZCuYTWGP87TQkRIqWfVE7t0ixhhEy8fYxIgTQgbv00WKoYIQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD60F91.4080206@netconfcentral.com> Date: Wed, 14 Oct 2009 10:51:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910141653.n9EGr9O3013648@idle.juniper.net> In-Reply-To: <200910141653.n9EGr9O3013648@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 17:50:52 -0000 Phil Shafer wrote: > "Joel M. Halpern" writes: >> If the inconsistency is such that the system can not create a value for >> the node, and the system considers it needs the node (it can not be >> mandatory in the config, because that would mean the user had to create >> it), then the requirements have become unmeetable. > > Should we have the rule that must constraints cannot refer to s-c leafs? > Yes. You realize this opens up the garbage-XML issue again. If the compiler can tell a node in an XPath expr references an s-c leaf, then it certainly knows whether the node is a real leaf or not. What about when-stmt, unique, min/max elements in a leaf-list? These are also illegal. > Also: we need a rule that says s-c leafs cannot be keys. > Yes -- this is all non-optimal, but at least predicable. It will make people think carefully about using s-c leafs. > Thanks, > Phil Andy From lhotka@cesnet.cz Wed Oct 14 11:30: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 3BF2C28C1E4 for ; Wed, 14 Oct 2009 11:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfnZ0L8kVacz for ; Wed, 14 Oct 2009 11:30:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6D5763A68ED for ; Wed, 14 Oct 2009 11:30:47 -0700 (PDT) Received: from [10.0.0.49] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id 12299D800BD; Wed, 14 Oct 2009 20:30:47 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4AD600EB.8040108@netconfcentral.com> References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> <1255535081.6653.104.camel@missotis> <4AD5FA81.10105@netconfcentral.com> <1255537950.6653.109.camel@missotis> <4AD600EB.8040108@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 20:30:42 +0200 Message-Id: <1255545042.6653.111.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 18:30:48 -0000 Andy Bierman píše v St 14. 10. 2009 v 09:48 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v St 14. 10. 2009 v 09:21 -0700: > >> Ladislav Lhotka wrote: > >>> Andy Bierman píše v St 14. 10. 2009 v 08:25 -0700: > >>> > >>>> Perhaps the problem is that we 100% disagree on the > >>>> validation model. There are plenty of people > >>>> who do not want the validation rules to work if > >>>> the client sets a value, and fail if the server sets a value. > >>>> > >>> My understanding is that both will succeed because the schema will be > >>> lax for such s-c leafs. > >>> > >> What does lax mean here? > > > > I mean that the leaf will be optional from the schema POV. > > > > Then your machine-generated implementation of the > model will be incorrect. The author used > a must statement. There is nothing optional > about that. Yes, this is true, so Schematron generated from such a YANG module would fail. Lada > > > > Lada > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Oct 14 11:44: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 01A8028C0CF for ; Wed, 14 Oct 2009 11:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 Am1VcRILJ2Oj for ; Wed, 14 Oct 2009 11:44:23 -0700 (PDT) Received: from n16b.bullet.mail.mud.yahoo.com (n16b.bullet.mail.mud.yahoo.com [68.142.207.237]) by core3.amsl.com (Postfix) with SMTP id 2EC9A3A68EC for ; Wed, 14 Oct 2009 11:44:23 -0700 (PDT) Received: from [209.191.108.96] by n16.bullet.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 18:44:24 -0000 Received: from [68.142.201.68] by t3.bullet.mud.yahoo.com with NNFMP; 14 Oct 2009 18:44:24 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 18:44:24 -0000 X-Yahoo-Newman-Id: 90120.32536.bm@omp420.mail.mud.yahoo.com Received: (qmail 80698 invoked from network); 14 Oct 2009 18:44:23 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 11:44:23 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 5pr2Z_EVM1mIykhT7P_RRzeJ5Y1jTTZExsljK64UfhROjyoDyxCnUvKu5QF9JuY6cQn7k_x_AB9cZUmiMQPrdFMVdY.IJwOrHbvxJZLuol6hIOu1qTrxoFfDyRXcMeK8WVx2Uw2Gj2EZFlgYQBRfhPo7Hq4Bb07vq8eoTJujMLgHt97l0otTp2r.oeOdYlNVfTxcxWwimWdOhfL5ml1N7WgicoXEDwMKx5aPUl6kFwIrAuVwKmucFIl0wl0oSCZj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD61BA4.9060002@netconfcentral.com> Date: Wed, 14 Oct 2009 11:42:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200910141421.n9EELvdx012099@idle.juniper.net> <4AD5ED7A.4060702@netconfcentral.com> <1255535081.6653.104.camel@missotis> <4AD5FA81.10105@netconfcentral.com> <1255537950.6653.109.camel@missotis> <4AD600EB.8040108@netconfcentral.com> <1255545042.6653.111.camel@missotis> In-Reply-To: <1255545042.6653.111.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 18:44:24 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 14. 10. 2009 v 09:48 -0700: >> Ladislav Lhotka wrote: >>> Andy Bierman píše v St 14. 10. 2009 v 09:21 -0700: >>>> Ladislav Lhotka wrote: >>>>> Andy Bierman píše v St 14. 10. 2009 v 08:25 -0700: >>>>> >>>>>> Perhaps the problem is that we 100% disagree on the >>>>>> validation model. There are plenty of people >>>>>> who do not want the validation rules to work if >>>>>> the client sets a value, and fail if the server sets a value. >>>>>> >>>>> My understanding is that both will succeed because the schema will be >>>>> lax for such s-c leafs. >>>>> >>>> What does lax mean here? >>> I mean that the leaf will be optional from the schema POV. >>> >> Then your machine-generated implementation of the >> model will be incorrect. The author used >> a must statement. There is nothing optional >> about that. > > Yes, this is true, so Schematron generated from such a YANG module would > fail. > So maybe a good compromise is to make s/c leafs outside the validation model, and it is a YANG syntax error if any validation constraint statements reference an s-c leaf. That way, if the client provides the s-c leaf, it doesn't change any validation constraints, because that s-c leaf couldn't be part of any constraints in the first place. > Lada > >> >>> Lada >> >> Andy Andy From phil@juniper.net Wed Oct 14 12: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 0767D3A6955 for ; Wed, 14 Oct 2009 12:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 dL4Oc5BspVVg for ; Wed, 14 Oct 2009 12:16:29 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 7C07B3A6405 for ; Wed, 14 Oct 2009 12:16:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKStYjjYMj33LjcenRDyMh/T3FR9mRlBFa@postini.com; Wed, 14 Oct 2009 12:16:32 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 12:11: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); Wed, 14 Oct 2009 12:11:16 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:11:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:11:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9EJBEj09034; Wed, 14 Oct 2009 12:11:14 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9EIwPjK014532; Wed, 14 Oct 2009 18:58:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141858.n9EIwPjK014532@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD60F91.4080206@netconfcentral.com> Date: Wed, 14 Oct 2009 14:58:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 19:11:14.0970 (UTC) FILETIME=[19AFB7A0:01CA4D02] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 19:16:30 -0000 Andy Bierman writes: >It will make people think carefully about using s-c leafs. Which is good, since s-c leafs should be one in a million. Thanks, Phil From phil@juniper.net Wed Oct 14 12:25:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D89F3A65A6 for ; Wed, 14 Oct 2009 12:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 SX1ozHgHrzSF for ; Wed, 14 Oct 2009 12:25:22 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 9255B3A657C for ; Wed, 14 Oct 2009 12:25:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKStYloxGjZDHQ6GgNAQTUyXDVAkiu3K3a@postini.com; Wed, 14 Oct 2009 12:25:25 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 12:20:12 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:20:12 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:20:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:20:10 -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 n9EJKAj13293; Wed, 14 Oct 2009 12:20:10 -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 n9EJ7H9q014661; Wed, 14 Oct 2009 19:07:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141907.n9EJ7H9q014661@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD60AAB.9050800@netconfcentral.com> Date: Wed, 14 Oct 2009 15:07:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 19:20:10.0813 (UTC) FILETIME=[5912DED0:01CA4D03] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 14 Oct 2009 19:25:23 -0000 Andy Bierman writes: >Our problem is this dual-role leaf, that only >becomes persistent in the NV-storage if the client >requests it. We agree this is a useful implementation >strategy and N/Y should support it. I disagree. We've discussion the "twin leaf" strategy, where one leaf is config true and one leaf is config false. One represents the user-requested behavior and one represents the real observed behavior. One leaf cannot be both config and operational content. >An s-c leaf can potentially change value at every reboot, >so it is not persistent config. We agree on that. I disagree. Once an s-c leaf is set, it is normal configuration data and will not change without express action. >Clearly, we do not want to force the operators >to populate every leaf that is used in a constraint. Agreed. The every leaf should not be forced to exist. >Yet the must-ripple-effect in YANG is there -- it >can change every leaf to mandatory=true that it references. >Do we agree this doesn't work? Can it be fixed? I suggested not allowing musts to reference s-c leafs. But you are hijacking the thread to return to the other discussion, where this thread was meant to investigate whether we could have a useful definition of configuration data. Thanks, Phil From andy@netconfcentral.com Wed Oct 14 12:29: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 C94563A687C for ; Wed, 14 Oct 2009 12:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 s3ZGGL9sqncS for ; Wed, 14 Oct 2009 12:29:47 -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 2769228C115 for ; Wed, 14 Oct 2009 12:29:47 -0700 (PDT) Received: (qmail 66062 invoked from network); 14 Oct 2009 19:29:47 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 12:29:47 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8OR2_6cVM1nx04wJ2H7ILKKq66m2GiVY_paqw3bayhQy2agBFa0RjkrYhlspVIQF4N5wXSknbd7RHT2mHZXYG529HFTF7dme_aCwLaCn4IFpdwnAayCdhs2qFmeSaCTd65nkakOQkPNqURj17lSkxsFYG0BQD3JcHPJa_eLxBWeFcGSQMxZEqc9oG56h76qKzX4msUGeYdOFiTLfFZOG40x0KqXWIVVavf2lpTUuyqKP43Zs5FkLUZAr1N12Wkte X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD6264A.909@netconfcentral.com> Date: Wed, 14 Oct 2009 12:28:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910141858.n9EIwPjK014532@idle.juniper.net> In-Reply-To: <200910141858.n9EIwPjK014532@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 19:29:47 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It will make people think carefully about using s-c leafs. > > Which is good, since s-c leafs should be one in a million. > What about dynamic defaults? I agree this is not saved in NV-store, as a different default may apply every time. This may be more than 1 in a million. > Thanks, > Phil > Andy From lhotka@cesnet.cz Wed Oct 14 12:30: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 1768A28C1F3 for ; Wed, 14 Oct 2009 12:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfW4k4BmrIuH for ; Wed, 14 Oct 2009 12:30:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D1C7228C1E7 for ; Wed, 14 Oct 2009 12:30:11 -0700 (PDT) Received: from [10.0.0.49] (5.199.broadband11.iol.cz [90.178.199.5]) by office2.cesnet.cz (Postfix) with ESMTP id C48BDD800CC; Wed, 14 Oct 2009 21:30:11 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200910141907.n9EJ7H9q014661@idle.juniper.net> References: <200910141907.n9EJ7H9q014661@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Oct 2009 21:30:10 +0200 Message-Id: <1255548610.6653.116.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 14 Oct 2009 19:30:14 -0000 Phil Shafer píše v St 14. 10. 2009 v 15:07 -0400: > Andy Bierman writes: > >Our problem is this dual-role leaf, that only > >becomes persistent in the NV-storage if the client > >requests it. We agree this is a useful implementation > >strategy and N/Y should support it. > > I disagree. We've discussion the "twin leaf" strategy, where one > leaf is config true and one leaf is config false. One represents > the user-requested behavior and one represents the real observed > behavior. One leaf cannot be both config and operational > content. This is matter of definition, which we don't have yet. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Oct 14 12:44: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 08E9F3A67D6 for ; Wed, 14 Oct 2009 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=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 SPGnsPaxpvPE for ; Wed, 14 Oct 2009 12:44:05 -0700 (PDT) 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 173833A67B6 for ; Wed, 14 Oct 2009 12:44:05 -0700 (PDT) Received: from [68.142.200.224] by n13.bullet.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 19:44:06 -0000 Received: from [68.142.201.251] by t5.bullet.mud.yahoo.com with NNFMP; 14 Oct 2009 19:44:05 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 14 Oct 2009 19:44:05 -0000 X-Yahoo-Newman-Id: 958246.83270.bm@omp412.mail.mud.yahoo.com Received: (qmail 91483 invoked from network); 14 Oct 2009 19:44:05 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 12:44:05 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: nkZiwSgVM1l940z4UakRsesrUAwaRxTLjwui1PofbbSKlW7espNi64WrgW_f3ISxHCUZZEjtQBLPPbFtJYT3rxKQzJsC8qcE11sWr4k2cIiaPJ6jhtuVnZsCfzg.Lu1CIWd0vEQ7MdJeRoKkd6_abs8jIRulx7eC8bthrnPQdnE4VwQ7MjewJy8MjAwccIMpw0aWPhEmr9M1udGiG7WXBBFHT.14rZ7u0ICS3U0UK8I7Mb_8MQHRtTYTqrdivjsr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD629A4.2020207@netconfcentral.com> Date: Wed, 14 Oct 2009 12:42:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910141907.n9EJ7H9q014661@idle.juniper.net> In-Reply-To: <200910141907.n9EJ7H9q014661@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 14 Oct 2009 19:44:06 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Our problem is this dual-role leaf, that only >> becomes persistent in the NV-storage if the client >> requests it. We agree this is a useful implementation >> strategy and N/Y should support it. > > I disagree. We've discussion the "twin leaf" strategy, where one > leaf is config true and one leaf is config false. One represents > the user-requested behavior and one represents the real observed > behavior. One leaf cannot be both config and operational > content. > I mean 1 leaf with 2 roles, not 2 leafs. >> An s-c leaf can potentially change value at every reboot, >> so it is not persistent config. We agree on that. > > I disagree. Once an s-c leaf is set, it is normal configuration > data and will not change without express action. > So is it treated as explicit config on the next reboot? Where does it say that in the text? Once the s-c leaf becomes part of running, then it is saved to NV-store like a regular leaf? Is it visible in a plain get-config reply? It doesn't seem like a normal config leaf to me. >> Clearly, we do not want to force the operators >> to populate every leaf that is used in a constraint. > > Agreed. The every leaf should not be forced to exist. > >> Yet the must-ripple-effect in YANG is there -- it >> can change every leaf to mandatory=true that it references. >> Do we agree this doesn't work? Can it be fixed? > > I suggested not allowing musts to reference s-c leafs. > > But you are hijacking the thread to return to the other discussion, > where this thread was meant to investigate whether we could have a > useful definition of configuration data. > Configuration is defined by the operations that the server supports for the data node. We have left config-stmt as a boolean, so we must think there are only 2 states for every possible data node. If config=false, the client can never alter it. Period. Config=true means the client and the server can alter the data node. If there is any middle ground, it is poorly described by system-creatable or any other YANG text. If it is important to clarify this middle ground, then the technology needs a lot more work, and then the specification needs to capture it. If Joel and Juergen think it is critical that we clarify this operational state in the standard, then I have to reluctantly agree with them. Is it clear to everybody exactly how each YANG constraint combo will behave for running or candidate, for every existing and every conceivable database operation? How do we even figure it all out? Where is the line between server implementation choices and standard behavior? If we don't know, how is anybody else going to know? > Thanks, > Phil > Andy From phil@juniper.net Wed Oct 14 12:53: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 882343A6835 for ; Wed, 14 Oct 2009 12:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 hy-foMfoiI6J for ; Wed, 14 Oct 2009 12:53:34 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 543BB3A67D6 for ; Wed, 14 Oct 2009 12:53:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKStYsPwg/xES5DMxI24M6tagQ+7yCUGGr@postini.com; Wed, 14 Oct 2009 12:53:37 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 12:48:47 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:48:48 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:48:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:48:44 -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 n9EJmhj26770; Wed, 14 Oct 2009 12:48: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 n9EJZsGZ015046; Wed, 14 Oct 2009 19:35:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141935.n9EJZsGZ015046@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD6264A.909@netconfcentral.com> Date: Wed, 14 Oct 2009 15:35:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 19:48:44.0805 (UTC) FILETIME=[56B14B50:01CA4D07] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 19:53:35 -0000 Andy Bierman writes: >What about dynamic defaults? >I agree this is not saved in NV-store, >as a different default may apply every time. >This may be more than 1 in a million. Sure, but they aren't config data. The dynamic default is really more for the operational "twin" leaf than the config "twin". In fact, I could claim that there were no dynamic defaults for config data, that these are just the dynamic value of the operational "twin" leaf. Not an important claim, but another way to look at the issue. Thanks, Phil From phil@juniper.net Wed Oct 14 12:54: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 E966F28C101 for ; Wed, 14 Oct 2009 12:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 n0NnV4fpZtJX for ; Wed, 14 Oct 2009 12:54:12 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 65A373A67AF for ; Wed, 14 Oct 2009 12:54:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKStYsZCRUhPtWv0ieWZjgX8RULFSz51uZ@postini.com; Wed, 14 Oct 2009 12:54: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.375.2; Wed, 14 Oct 2009 12:50:10 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:50:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:50:09 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:50:09 -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 n9EJo8j27354; Wed, 14 Oct 2009 12:50:08 -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 n9EJbJUR015093; Wed, 14 Oct 2009 19:37:19 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141937.n9EJbJUR015093@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1255548610.6653.116.camel@missotis> Date: Wed, 14 Oct 2009 15:37:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 19:50:09.0568 (UTC) FILETIME=[89371A00:01CA4D07] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 14 Oct 2009 19:54:13 -0000 Ladislav Lhotka writes: >This is matter of definition, which we don't have yet. This much we do have. A leaf is either "config true" or "config false", there is no "config part-time". A single leaf cannot represent both config and operational values. Thanks, Phil From mbj@tail-f.com Wed Oct 14 13:02: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 D1ECC3A6955 for ; Wed, 14 Oct 2009 13:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okwDI-KwcSB5 for ; Wed, 14 Oct 2009 13:02:34 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 163623A687C for ; Wed, 14 Oct 2009 13:02:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BD85261602A; Wed, 14 Oct 2009 22:02:35 +0200 (CEST) Date: Wed, 14 Oct 2009 22:02:35 +0200 (CEST) Message-Id: <20091014.220235.255551214.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AD629A4.2020207@netconfcentral.com> References: <200910141907.n9EJ7H9q014661@idle.juniper.net> <4AD629A4.2020207@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] What is 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, 14 Oct 2009 20:02:34 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> An s-c leaf can potentially change value at every reboot, > >> so it is not persistent config. We agree on that. > > > > I disagree. Once an s-c leaf is set, it is normal configuration > > data and will not change without express action. > > > > So is it treated as explicit config on the next reboot? Yes. > Where does it say that in the text? We can add something like: Once created by the server, the leaf is just like any other leaf in the data tree. > Once the s-c leaf becomes part of running, > then it is saved to NV-store like a regular leaf? Yes. > Is it visible in a plain get-config reply? Yes. > It doesn't seem like a normal config leaf to me. It is a normal leaf, its just that the server may create it if the client did not. > Configuration is defined by the operations that the > server supports for the data node. We have left config-stmt > as a boolean, so we must think there are only 2 states > for every possible data node. If config=false, the client > can never alter it. Period. Config=true means the client > and the server can alter the data node. Config=true means the client can alter it. If s-c is false, the server can never alter it. If s-c is true, the server may *create* it, but not modify it later. /martin From phil@juniper.net Wed Oct 14 13:04: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 2C5C23A6814 for ; Wed, 14 Oct 2009 13:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.97 X-Spam-Level: X-Spam-Status: No, score=-5.97 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 gGAQ3Ma95qB6 for ; Wed, 14 Oct 2009 13:04:29 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 6C8603A689D for ; Wed, 14 Oct 2009 13:04:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKStYuzeBSNb9djXKCf58D6wvc8CMq+ur7@postini.com; Wed, 14 Oct 2009 13:04:31 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 12:58:14 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:58:14 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:58:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:58:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9EJwCj30755; Wed, 14 Oct 2009 12:58:12 -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 n9EJjOE2015192; Wed, 14 Oct 2009 19:45:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910141945.n9EJjOE2015192@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AD629A4.2020207@netconfcentral.com> Date: Wed, 14 Oct 2009 15:45:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Oct 2009 19:58:13.0255 (UTC) FILETIME=[A983E170:01CA4D08] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 14 Oct 2009 20:04:30 -0000 Andy Bierman writes: >I mean 1 leaf with 2 roles, not 2 leafs. I understood and was disagreeing with you. A leaf is either "config true" or "config false", not both. >So is it treated as explicit config on the next reboot? Yup. >Where does it say that in the text? It says: The server MUST NOT create the leaf if the leaf already exists or if "system-creatable" is "false". Do we need to explicitly say that other that the given rules, it behaves just like every other leaf? It's config data because it's "config true". >Once the s-c leaf becomes part of running, >then it is saved to NV-store like a regular leaf? Yup. >Is it visible in a plain get-config reply? Yup. >It doesn't seem like a normal config leaf to me. It's a normal "config true" leaf, just one the system can create. >Configuration is defined by the operations that the >server supports for the data node. We have left config-stmt >as a boolean, so we must think there are only 2 states >for every possible data node. If config=false, the client >can never alter it. Period. Config=true means the client >and the server can alter the data node. If there is any middle ground, >it is poorly described by system-creatable or any other YANG text. There is no middle ground. Thanks, Phil From andy@netconfcentral.com Wed Oct 14 14:33:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534FC28C10C for ; Wed, 14 Oct 2009 14:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, UNPARSEABLE_RELAY=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 VPPmw2fHdSjM for ; Wed, 14 Oct 2009 14:33:18 -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 736D93A6885 for ; Wed, 14 Oct 2009 14:33:02 -0700 (PDT) Received: (qmail 95019 invoked from network); 14 Oct 2009 21:33:02 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 14:33:02 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: IfEdgukVM1ljMzo3Op.Jl8cu4J6Rl6B.Mtc.Mjjvoze0pHlOGTaQ98oJjEA19P8vvvnJ.Jo83wKrt80mUBhit_Mrrr78qvrQwgqvr0d9QF9fc4e3X6KZIQgkH7e0xxxTBA0jYTFJOICKL0eIU3Piq2DNP_eTflh8SPvdIPlmauGUwnPwNjWx7qs2EDKnRlGwJSgIWRdZcRlRR9s9CtHs80Kh5GUIZS_KvNG2b4KoQXhUZYdZWLNYLcaD_y8tS7XeREJg93l6nLbWfhqUc9_NmjuQy0rfKkTrdJOWyng3kV9UnOE0jGID6tXchhv7gg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD643A5.9070601@netconfcentral.com> Date: Wed, 14 Oct 2009 14:33:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200910141907.n9EJ7H9q014661@idle.juniper.net> <4AD629A4.2020207@netconfcentral.com> <20091014.220235.255551214.mbj@tail-f.com> In-Reply-To: <20091014.220235.255551214.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] What is 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, 14 Oct 2009 21:33:19 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> An s-c leaf can potentially change value at every reboot, >>>> so it is not persistent config. We agree on that. >>> I disagree. Once an s-c leaf is set, it is normal configuration >>> data and will not change without express action. >>> >> So is it treated as explicit config on the next reboot? > > Yes. > >> Where does it say that in the text? > > We can add something like: > > Once created by the server, the leaf is just like any other leaf in > the data tree. > choice fubar { case a { // or container a leaf X { system-creatable true; type int32; } leaf Y { type string; mandatory true; } } leaf case-b { type string; } } This has an odd effect on NP containers and choices. Once the s-c leaf exists in running, then it is possible that may trigger existence requirements for sibling nodes within a case or within an NP container. So what does the server do if a mandatory sibling leaf that is s-c=false needs to be created (Y)? It cannot create the leaf X in this case, because the running config would not be valid anymore. Andy >> Once the s-c leaf becomes part of running, >> then it is saved to NV-store like a regular leaf? > > Yes. > >> Is it visible in a plain get-config reply? > > Yes. > >> It doesn't seem like a normal config leaf to me. > > It is a normal leaf, its just that the server may create it if the > client did not. > >> Configuration is defined by the operations that the >> server supports for the data node. We have left config-stmt >> as a boolean, so we must think there are only 2 states >> for every possible data node. If config=false, the client >> can never alter it. Period. Config=true means the client >> and the server can alter the data node. > > Config=true means the client can alter it. > > If s-c is false, the server can never alter it. > > If s-c is true, the server may *create* it, but not modify it later. > > > > /martin > From kwatsen@juniper.net Wed Oct 14 14:34: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 7B8493A6811 for ; Wed, 14 Oct 2009 14:34:40 -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 yGGICfulUClm for ; Wed, 14 Oct 2009 14:34:39 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 700B13A683B for ; Wed, 14 Oct 2009 14:34:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKStZD8TQoWgYXTtZxO19sgYWuZJ7GqaRo@postini.com; Wed, 14 Oct 2009 14:34:42 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 14 Oct 2009 14:31:25 -0700 From: Kent Watsen To: Phil Shafer , Andy Bierman Date: Wed, 14 Oct 2009 14:31:25 -0700 Thread-Topic: [netmod] system-creatable Thread-Index: AcpNAtlSiHQhx8JRTxKvkLN6X2aWhwADBY1g Message-ID: <84600D05C20FF943918238042D7670FD36646BFB97@EMBX01-HQ.jnpr.net> References: <4AD60F91.4080206@netconfcentral.com> <200910141858.n9EIwPjK014532@idle.juniper.net> In-Reply-To: <200910141858.n9EIwPjK014532@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 21:34:40 -0000 Phil Shafer writes: >=20 > Which is good, since s-c leafs should be one in a million. True, and maybe this is the problem - the current s-c definition is very na= rrow, I wonder if there is a more useful/general construct... The current definition is limited to values that the server may fill in if = the user doesn't, but there are other cases when the server will create nod= es - for instance: - automatically creating an "encrypted-password" when user supplies "clear-text" password - automatically terminating firewall rules due to a policy that says all such rules should be terminal (like a commit script) - automatically populating entries in a list of signatures when a new signature-database is referenced via config (not an op cmd). Note: assume this can not be state data as it needs to be referenced by instance-identifiers And, of course, this shouldn't limit the server to just creations, but also= allow for modifications, and deletions. IMO, marking nodes as server-creatable isn't nearly as useful as having a g= eneral mechanism indicating for all server modifications. An easy way to i= mplement this is to enable // RPC replies= to include at least a something-got-modified flag or, better, list out all= modified xpaths. A more complicated solution is to also model these seman= tics in the YANG model, which cover most cases, but still allow the RPC Rep= ly to return xpaths for the few unmodelable cases (commit scripts) What do you think? - maybe this just nees to be looked at a differently? Applying this logic to the uid example, we have: list users { key "name"; unique "uid"; leaf name { type string; mandatory true; } leaf uid { type uint32; } } The uid leaf is optional and, when not specified by the user, MAY be filled= in by the server (or rejected) but, if it is filled in, it MUST be unique = and the RPC Reply will indicate that the leaf was modified. =20 - this looks perfect to me, but I'm with YANG describing the config model= , not the operational model, camp Thanks, Kent From mbj@tail-f.com Wed Oct 14 14:55:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672DB3A68D4 for ; Wed, 14 Oct 2009 14:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.271, 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 3pveHjW4j+jA for ; Wed, 14 Oct 2009 14:55:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0B5EC3A69C1 for ; Wed, 14 Oct 2009 14:55:22 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A3C19616027; Wed, 14 Oct 2009 23:55:23 +0200 (CEST) Date: Wed, 14 Oct 2009 23:55:18 +0200 (CEST) Message-Id: <20091014.235518.84570325.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AD643A5.9070601@netconfcentral.com> References: <4AD629A4.2020207@netconfcentral.com> <20091014.220235.255551214.mbj@tail-f.com> <4AD643A5.9070601@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] What is 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, 14 Oct 2009 21:55:23 -0000 Andy Bierman wrote: > choice fubar { > case a { // or container a > leaf X { > system-creatable true; > type int32; > } > leaf Y { > type string; > mandatory true; > } > } > leaf case-b { type string; } > } > > > This has an odd effect on NP containers and choices. > Once the s-c leaf exists in running, then > it is possible that may trigger existence requirements > for sibling nodes within a case or within an NP container. > > So what does the server do if a mandatory sibling leaf > that is s-c=false needs to be created (Y)? > It cannot create the leaf X in this case, because the > running config would not be valid anymore. Right. It must not create something that invalidates running. So unless Y exists, the server MUST NOT create X. /martin From david.kessens@nsn.com Wed Oct 14 16: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 D16623A6968 for ; Wed, 14 Oct 2009 16:27:02 -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 ga17kD45xVZ2 for ; Wed, 14 Oct 2009 16:27:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CA7743A694C for ; Wed, 14 Oct 2009 16:27:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9ENR21a010225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2009 01:27:02 +0200 Received: from localhost.localdomain ([10.138.49.90]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9ENQtjM007769; Thu, 15 Oct 2009 01:27:01 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id n9ENQtDF018447; Wed, 14 Oct 2009 16:26:55 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id n9ENQrkQ018445; Wed, 14 Oct 2009 16:26:53 -0700 Date: Wed, 14 Oct 2009 16:26:52 -0700 From: David Kessens To: Phil Shafer Message-ID: <20091014232652.GC16302@nsn.com> References: <4AD5F16F.1030008@netconfcentral.com> <200910141605.n9EG5WJm013205@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910141605.n9EG5WJm013205@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2009 23:27:02 -0000 Phil, Andy, On Wed, Oct 14, 2009 at 12:05:32PM -0400, Phil Shafer wrote: > Andy Bierman writes: > >IMO, there is no consensus on system-creatable nodes. > > Perhaps we should call for a concensus before declaring one. > > WG chairs, would this be possible? With all due respect, I don't see any basis for doing a consensus call when it is entirely obvious that there is at best an extremely rough consensus. We need to see a serious and genuine effort from *all* parties involved to find a solution. Making statements about a perceived existing or non-existing consensus is not a very constructive way to get to the point where we reach progress on this or other open issues. To say it in another way, do either of you have proposals for a solution ? David Kessens --- From andy@netconfcentral.com Wed Oct 14 17: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 97EE33A67AD for ; Wed, 14 Oct 2009 17:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 Gdk-EVMw0cui for ; Wed, 14 Oct 2009 17:25:02 -0700 (PDT) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by core3.amsl.com (Postfix) with SMTP id E2F853A6778 for ; Wed, 14 Oct 2009 17:25:02 -0700 (PDT) Received: from [69.147.84.144] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 15 Oct 2009 00:25:04 -0000 Received: from [68.142.194.243] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 15 Oct 2009 00:25:04 -0000 Received: from [68.142.201.254] by t1.bullet.mud.yahoo.com with NNFMP; 15 Oct 2009 00:25:04 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 15 Oct 2009 00:25:04 -0000 X-Yahoo-Newman-Id: 277468.55449.bm@omp415.mail.mud.yahoo.com Received: (qmail 30017 invoked from network); 15 Oct 2009 00:25:03 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 14 Oct 2009 17:25:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: F0l7GqsVM1l8VRuAYauyZPs3FtdG08K8iaHSaT0rGvo_Q70SEcBjBlJum4rJYRC9kpxh6yQDcYizyTfb0xTVu9UyFuffJ3uRJT_elHzt3nHV7Ovb187qFDMaQq_rTcZnhtep4t.GcQf4M2yRdh096RUL6i8uWwmtGUQndJT1SeCQ1OIXkYSxkX7AJGqpH3TpbMq4udFiPIfZ.3Tid18eQxDTakPnsydCrzPoGp1smMu8zynczuoM3.ueDdiwgKAo X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD66BF7.1020806@netconfcentral.com> Date: Wed, 14 Oct 2009 17:25:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Kessens References: <4AD5F16F.1030008@netconfcentral.com> <200910141605.n9EG5WJm013205@idle.juniper.net> <20091014232652.GC16302@nsn.com> In-Reply-To: <20091014232652.GC16302@nsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 00:25:03 -0000 David Kessens wrote: > Phil, Andy, > > On Wed, Oct 14, 2009 at 12:05:32PM -0400, Phil Shafer wrote: >> Andy Bierman writes: >>> IMO, there is no consensus on system-creatable nodes. >> Perhaps we should call for a concensus before declaring one. >> >> WG chairs, would this be possible? > > With all due respect, I don't see any basis for doing a consensus call > when it is entirely obvious that there is at best an extremely rough > consensus. > > We need to see a serious and genuine effort from *all* parties > involved to find a solution. Making statements about a perceived > existing or non-existing consensus is not a very constructive way to > get to the point where we reach progress on this or other open issues. > > To say it in another way, do either of you have proposals for a > solution ? > I think solution proposals have been suggested. One obvious solution -- stick with the description-stmt for these tiny 1-in-a-million corner-cases instead of wasting months or years trying to create machine-readable clauses for every conceivable detail. > David Kessens > --- > Andy From mbj@tail-f.com Wed Oct 14 23:38: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 B9D6D3A6890 for ; Wed, 14 Oct 2009 23:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 qCjGr9gYVUOp for ; Wed, 14 Oct 2009 23:38: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 65C1D3A67DA for ; Wed, 14 Oct 2009 23:38:56 -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 21C68616002; Thu, 15 Oct 2009 08:38:58 +0200 (CEST) Date: Thu, 15 Oct 2009 08:38:57 +0200 (CEST) Message-Id: <20091015.083857.143184160.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AD66BF7.1020806@netconfcentral.com> References: <200910141605.n9EG5WJm013205@idle.juniper.net> <20091014232652.GC16302@nsn.com> <4AD66BF7.1020806@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] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 06:38:57 -0000 Andy Bierman wrote: > David Kessens wrote: > > Phil, Andy, > > > > On Wed, Oct 14, 2009 at 12:05:32PM -0400, Phil Shafer wrote: > >> Andy Bierman writes: > >>> IMO, there is no consensus on system-creatable nodes. > >> Perhaps we should call for a concensus before declaring one. > >> > >> WG chairs, would this be possible? > > > > With all due respect, I don't see any basis for doing a consensus call > > when it is entirely obvious that there is at best an extremely rough > > consensus. > > > > We need to see a serious and genuine effort from *all* parties > > involved to find a solution. Making statements about a perceived > > existing or non-existing consensus is not a very constructive way to > > get to the point where we reach progress on this or other open issues. > > > > To say it in another way, do either of you have proposals for a > > solution ? > > > > I think solution proposals have been suggested. > One obvious solution -- stick with the description-stmt Several people have pointed out (several times) that not doing anything is what led to the major confusion about mandatory and if/when/how/why servers were allowed to create config data. > for these tiny 1-in-a-million corner-cases instead > of wasting months or years trying to create machine-readable > clauses for every conceivable detail. And, repeating myself, the biggest value of having s-c is *not* that we want machine-readable clauses for every conceivable detail, but that we sort out the confusion I refered to above. /martin From j.schoenwaelder@jacobs-university.de Wed Oct 14 23:42: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 29AA83A68F9 for ; Wed, 14 Oct 2009 23:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 lgl5eOXpLhHg for ; Wed, 14 Oct 2009 23:42:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 20B053A67DA for ; Wed, 14 Oct 2009 23:42:00 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6845C001A; Thu, 15 Oct 2009 08:42:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1Q3h8X3TjQz3; Thu, 15 Oct 2009 08:42:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A0E6C000C; Thu, 15 Oct 2009 08:42:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 01228D1EF6F; Thu, 15 Oct 2009 08:42:00 +0200 (CEST) Date: Thu, 15 Oct 2009 08:42:00 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091015064200.GA22071@elstar.local> Mail-Followup-To: Phil Shafer , NETMOD Working Group References: <200910141648.n9EGme4d013553@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910141648.n9EGme4d013553@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] What is config? 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, 15 Oct 2009 06:42:01 -0000 On Wed, Oct 14, 2009 at 06:48:40PM +0200, Phil Shafer wrote: > Good point. What NETCONF and YANG lack is a good definition of > what configuration is. I can point of the issues with making a > leaf "config true" (like the save/restore issue) but lacking a real > definition, we will be asking WG modelers to "know it when they see > it", which will be difficult since many issues (like the save/restore > one) aren't immediately obvious in their impact. > > So do we need (and can we) to agree on a definition of configuration > data that is both straight forward enough to read and accurate enough > to be useful? See the start of the thread "Configuration Data versus Operational State Data versus Statistics": http://www.ietf.org/mail-archive/web/netmod/current/msg03850.html /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 Thu Oct 15 05:26: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 2F9613A677E for ; Thu, 15 Oct 2009 05:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 a0pY-BqoxrKF for ; Thu, 15 Oct 2009 05:26:14 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 32F8D3A681C for ; Thu, 15 Oct 2009 05:26:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKStcU5gN3cMd3DGz+o7Z+GlEHqdWGBF9A@postini.com; Thu, 15 Oct 2009 05:26:17 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 15 Oct 2009 05:22:13 -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, 15 Oct 2009 05:22:13 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 05:22:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 05:22:12 -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 n9FCMBj53765; Thu, 15 Oct 2009 05:22:11 -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 n9FC9MCZ022703; Thu, 15 Oct 2009 12:09:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910151209.n9FC9MCZ022703@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20091015064200.GA22071@elstar.local> Date: Thu, 15 Oct 2009 08:09:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Oct 2009 12:22:12.0256 (UTC) FILETIME=[1F808200:01CA4D92] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 15 Oct 2009 12:26:15 -0000 Juergen Schoenwaelder writes: >See the start of the thread "Configuration Data versus Operational >State Data versus Statistics": > >http://www.ietf.org/mail-archive/web/netmod/current/msg03850.html Apologies, I missed this thread. Unless there are objections, I'll add this to the arch draft. Thanks, Phil From lhotka@cesnet.cz Thu Oct 15 07:30:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA7C3A6914 for ; Thu, 15 Oct 2009 07:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=0.488, 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 kpNsiSylv797 for ; Thu, 15 Oct 2009 07:30:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 765B83A6975 for ; Thu, 15 Oct 2009 07:30:11 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D2E6DD800C5; Thu, 15 Oct 2009 16:30:13 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091015.083857.143184160.mbj@tail-f.com> References: <200910141605.n9EG5WJm013205@idle.juniper.net> <20091014232652.GC16302@nsn.com> <4AD66BF7.1020806@netconfcentral.com> <20091015.083857.143184160.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 15 Oct 2009 16:30:11 +0200 Message-Id: <1255617011.4855.18.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 14:30:12 -0000 Martin Bjorklund píše v ÄŒt 15. 10. 2009 v 08:38 +0200: > Several people have pointed out (several times) that not doing > anything is what led to the major confusion about mandatory and > if/when/how/why servers were allowed to create config data. Personally, I can accept that the server implementations may make configuration changes on its own provided such changes are 1. not hidden from the client 2. subject to all contraints of the data model Actually, even if there are some rules like s-c constraining server behaviour, would they cover actions of an "embedded client" running on the server host? If not, the server rules would be pretty lame. As for "mandatory", I am happy with the current meaning: such a leaf must be present in every valid configuration. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Oct 15 08:08: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 2D4AC3A689C for ; Thu, 15 Oct 2009 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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+RPoNyqzHYK for ; Thu, 15 Oct 2009 08:08: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 4600028C119 for ; Thu, 15 Oct 2009 08:08:56 -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 AA91B616002; Thu, 15 Oct 2009 17:08:58 +0200 (CEST) Date: Thu, 15 Oct 2009 17:08:58 +0200 (CEST) Message-Id: <20091015.170858.137890597.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255617011.4855.18.camel@nomad> References: <4AD66BF7.1020806@netconfcentral.com> <20091015.083857.143184160.mbj@tail-f.com> <1255617011.4855.18.camel@nomad> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 15:08:57 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMTUuIDEwLiAyMDA5IHYgMDg6MzggKzAyMDA6DQo+IA0KPiA+IFNl dmVyYWwgcGVvcGxlIGhhdmUgcG9pbnRlZCBvdXQgKHNldmVyYWwgdGltZXMpIHRoYXQgbm90IGRv aW5nDQo+ID4gYW55dGhpbmcgaXMgd2hhdCBsZWQgdG8gdGhlIG1ham9yIGNvbmZ1c2lvbiBhYm91 dCBtYW5kYXRvcnkgYW5kDQo+ID4gaWYvd2hlbi9ob3cvd2h5IHNlcnZlcnMgd2VyZSBhbGxvd2Vk IHRvIGNyZWF0ZSBjb25maWcgZGF0YS4NCj4gDQo+IFBlcnNvbmFsbHksIEkgY2FuIGFjY2VwdCB0 aGF0IHRoZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIG1heSBtYWtlDQo+IGNvbmZpZ3VyYXRpb24g Y2hhbmdlcyBvbiBpdHMgb3duIHByb3ZpZGVkIHN1Y2ggY2hhbmdlcyBhcmUNCj4gMS4gbm90IGhp ZGRlbiBmcm9tIHRoZSBjbGllbnQNCj4gMi4gc3ViamVjdCB0byBhbGwgY29udHJhaW50cyBvZiB0 aGUgZGF0YSBtb2RlbA0KDQpJJ20gbm90IHN1cmUgd2hhdCAxLiBtZWFucy4NCg0KU28gYSBjbGll bnQgY2FuIG5ldmVyIGJlIHN1cmUgdGhhdCB3aGF0IGhlIGRpZCBhY3R1YWxseSBpcyB0aGVyZSBp bg0KdGhlIGRhdGEgc3RvcmUuICBBbGwgZWRpdC1jb25maWcgd2lsbCBoYXZlIHRvIGJlIGZvbGxv d2VkIGJ5IGENCmNvbXBsZXRlIGdldC1jb25maWcsIGV2ZW4gaWYgdGhlIGNsaWVudCBoYXMgYSBs b2NrLCBpZiB0aGUgY2xpZW50DQp3YW50cyB0byBiZSBzdXJlIHRoYXQgaXQgaXMgaW4gc3luY2g/ DQoNCj4gQWN0dWFsbHksIGV2ZW4gaWYgdGhlcmUgYXJlIHNvbWUgcnVsZXMgbGlrZSBzLWMgY29u c3RyYWluaW5nIHNlcnZlcg0KPiBiZWhhdmlvdXIsIHdvdWxkIHRoZXkgY292ZXIgYWN0aW9ucyBv ZiBhbiAiZW1iZWRkZWQgY2xpZW50IiBydW5uaW5nIG9uDQo+IHRoZSBzZXJ2ZXIgaG9zdD8NCg0K QW4gImVtYmVkZGVkIGNsaWVudCIgaXMgbm8gZGlmZmVyZW50IGZyb20gYSAicmVtb3RlIGNsaWVu dCIuICBJdA0KZm9sbG93cyB0aGUgc2FtZSBydWxlcyBhcyBvdGhlciBjbGllbnRzLg0KDQpXaGVu IHdlIHNheSB0aGF0IHRoZSBzZXJ2ZXIgbWF5IGNyZWF0ZSBkYXRhLCBpdCBkb2VzIHNvIGFzIHBh cnQgb2YgdGhlDQpwcm9jZXNzaW5nIG9mIGEgTkVUQ09ORiByZXF1ZXN0ICg8Y29tbWl0PiBvciA8 ZWRpdC1jb25maWc+KS4NCg0KDQovbWFydGluDQo= From andy@netconfcentral.com Thu Oct 15 09:31: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 882BA28C12E for ; Thu, 15 Oct 2009 09:31:41 -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 kzZWVoHuA0nn for ; Thu, 15 Oct 2009 09:31:40 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id ADF4B28C12C for ; Thu, 15 Oct 2009 09:31:40 -0700 (PDT) Received: (qmail 94668 invoked from network); 15 Oct 2009 16:31:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 15 Oct 2009 16:31:42 -0000 X-YMail-OSG: y2NEp4kVM1nyy714ZKruCH8UIbLzsm9Q8_QOQn3._ZEMM1xE6s7CAftz3_.Giizzyiov_CqFbIgdcDgdQIfKeSreCNACI.T5MQ_f_ETI9G6SYrObExlIjQivY7pR4wNGfvB8SFxjUZH5SnxfqrYkYWC9FXv7GIr2j9Q_RXr6TZh59isAXfcmxvx_Ek0L4MFye4u51zpLrLjleTjyO.8ByMoZD0Cw_lvowX3SCJKgWhkNejJ3Xa285xiWdCFYRu_4MO4lAFk99Xa5EaWjMd2N5i2MShpAqrX2nYnRmdWW4D7b4V8NT.oP3cJiqFWvF9vR3w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD74E88.3050909@netconfcentral.com> Date: Thu, 15 Oct 2009 09:32:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200910141605.n9EG5WJm013205@idle.juniper.net> <20091014232652.GC16302@nsn.com> <4AD66BF7.1020806@netconfcentral.com> <20091015.083857.143184160.mbj@tail-f.com> <1255617011.4855.18.camel@nomad> In-Reply-To: <1255617011.4855.18.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 16:31:41 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v ÄŒt 15. 10. 2009 v 08:38 +0200: > >> Several people have pointed out (several times) that not doing >> anything is what led to the major confusion about mandatory and >> if/when/how/why servers were allowed to create config data. > > Personally, I can accept that the server implementations may make > configuration changes on its own provided such changes are > 1. not hidden from the client > 2. subject to all contraints of the data model > I agree with Lada. I like the -07 spec better than the system-creatable solution proposal. The description-stmt can specify the 1-in-a-million uses of system-creatable=true. The s-c leaf is too fragile and different. It is invisible in the candidate the first time, and then it just shows up in running, and becomes a normal leaf after that (except that it cannot be part of any YANG constraint, so it is not normal at all). And Ken pointed out several machine-readable properties (some done now as extensions), all of which are way more more interesting than this system-creatable corner-case. I prefer to finish YANG 1.0 and leave some work for later. As it is, YANG will be at least a year late, and that is starting to become a concern. No programming or data modeling language ever written has been perfect or complete at version 1.0. You didn't think YANG would be the first exception, did you? A standard contains proven techniques that have WG consensus. I don't see either in this case. > Actually, even if there are some rules like s-c constraining server > behaviour, would they cover actions of an "embedded client" running on > the server host? If not, the server rules would be pretty lame. > > As for "mandatory", I am happy with the current meaning: such a leaf > must be present in every valid configuration. > > Lada > Andy From lhotka@cesnet.cz Thu Oct 15 10:18: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 513223A67C0 for ; Thu, 15 Oct 2009 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=0.434, 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 EuKto7qf21MM for ; Thu, 15 Oct 2009 10:18:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 75CE63A67A2 for ; Thu, 15 Oct 2009 10:18:24 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 36821D800BD; Thu, 15 Oct 2009 19:18:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091015.170858.137890597.mbj@tail-f.com> References: <4AD66BF7.1020806@netconfcentral.com> <20091015.083857.143184160.mbj@tail-f.com> <1255617011.4855.18.camel@nomad> <20091015.170858.137890597.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 15 Oct 2009 19:18:26 +0200 Message-Id: <1255627106.7160.27.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 17:18:25 -0000 Martin Bjorklund píše v ÄŒt 15. 10. 2009 v 17:08 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v ÄŒt 15. 10. 2009 v 08:38 +0200: > > > > > Several people have pointed out (several times) that not doing > > > anything is what led to the major confusion about mandatory and > > > if/when/how/why servers were allowed to create config data. > > > > Personally, I can accept that the server implementations may make > > configuration changes on its own provided such changes are > > 1. not hidden from the client > > 2. subject to all contraints of the data model > > I'm not sure what 1. means. That it appears in the affected configuration, i.e. isn't treated as another class of vendor-specific default by the device. > > So a client can never be sure that what he did actually is there in > the data store. All edit-config will have to be followed by a > complete get-config, even if the client has a lock, if the client > wants to be sure that it is in synch? For a human operator, such changes can happen in other ways, for instance in the manager software before it is sent to the device. It needn't always be bad thing - automatic uids, password encryption etc. An implementation tampering with configurations in non-intuitive ways will be hated by users and rejected. But IMO it's not a data modelling issue. Lada > > > Actually, even if there are some rules like s-c constraining server > > behaviour, would they cover actions of an "embedded client" running on > > the server host? > > An "embedded client" is no different from a "remote client". It > follows the same rules as other clients. > > When we say that the server may create data, it does so as part of the > processing of a NETCONF request ( or ). > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Thu Oct 15 11:15: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 8E07128C186 for ; Thu, 15 Oct 2009 11:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 NnaBs7WYcaoW for ; Thu, 15 Oct 2009 11:15:23 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 69ADD28C165 for ; Thu, 15 Oct 2009 11:15:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKStdmu9sdiRYXsW2E04otlOSMNeR+nrb1@postini.com; Thu, 15 Oct 2009 11:15:27 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 15 Oct 2009 11:10:41 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:10:41 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:10:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:10:40 -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 n9FIAej37148; Thu, 15 Oct 2009 11:10:40 -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 n9FHvoBi024868; Thu, 15 Oct 2009 17:57:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910151757.n9FHvoBi024868@idle.juniper.net> To: David Kessens In-Reply-To: <20091014232652.GC16302@nsn.com> Date: Thu, 15 Oct 2009 13:57:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Oct 2009 18:10:40.0893 (UTC) FILETIME=[CE0552D0:01CA4DC2] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 18:15:24 -0000 David Kessens writes: >To say it in another way, do either of you have proposals for a >solution ? There are two distinct proposals on the table: (a) add the text from Martin about s-c leafs (b) delay the issue until post-YANG 1.0 My request for a call comes from my inability to understand which side of the issue folks are on. On the conf call, there seems overwhelming support for adding s-c leafs. Does that support still exist? I see the case of s-c leafs as a real one, but a very rare one. I'm not sure it's worth including in the draft. One major concern is that an s-c leaf will technically break the semantics of locking, in that a lock held during a commit-config operation that triggers the creation of s-c leaf means that the database is changing while the session has it locked. But one can view this as an implicit change performed on behalf of the user holding the lock, so it may be viewed as _not_ a violation of locking. In any case, having this scenario documented in a first-class statement instead of in the description string seems like a Good Thing. But there's a long list of other Good Things we can add, and I'm not sure this one is a clear "must have". So I'd rate myself "+1/4" on s-c leafs. Where do others stand? If we don't add s-c, do we need to stay something in the draft (or the arch draft) about how/when/why the system can create leafs and what well-mannered devices need to do about it (refreshing config after edit-config)? Thanks, Phil From jmh@joelhalpern.com Thu Oct 15 11:22: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 9388D3A6784 for ; Thu, 15 Oct 2009 11:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 fq-+jgu9Lmpt for ; Thu, 15 Oct 2009 11:22:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C14E83A69AF for ; Thu, 15 Oct 2009 11:22:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7C91232317B3; Thu, 15 Oct 2009 11:22:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id BFBE932317AD; Thu, 15 Oct 2009 11:22:26 -0700 (PDT) Message-ID: <4AD76862.8020406@joelhalpern.com> Date: Thu, 15 Oct 2009 14:22:26 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200910151757.n9FHvoBi024868@idle.juniper.net> In-Reply-To: <200910151757.n9FHvoBi024868@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 18:22:24 -0000 I think the s-c is a good thing, and is helpful. Among other things, it is actually ahrd to describe the problem without s-c. And I think that the base protocol document has to talk clearly about the problem, and what is permitted or required. At the moment, different devices can behave differently, in ways that will prevent interoperability. And different people still seem to understand the words differently. Yours, Joel Phil Shafer wrote: > David Kessens writes: >> To say it in another way, do either of you have proposals for a >> solution ? > > There are two distinct proposals on the table: > > (a) add the text from Martin about s-c leafs > (b) delay the issue until post-YANG 1.0 > > My request for a call comes from my inability to understand which > side of the issue folks are on. On the conf call, there seems > overwhelming support for adding s-c leafs. Does that support still > exist? > > I see the case of s-c leafs as a real one, but a very rare one. > I'm not sure it's worth including in the draft. > > One major concern is that an s-c leaf will technically break the > semantics of locking, in that a lock held during a commit-config > operation that triggers the creation of s-c leaf means that the > database is changing while the session has it locked. But one can > view this as an implicit change performed on behalf of the user > holding the lock, so it may be viewed as _not_ a violation of > locking. > > In any case, having this scenario documented in a first-class > statement instead of in the description string seems like a Good > Thing. But there's a long list of other Good Things we can add, > and I'm not sure this one is a clear "must have". > > So I'd rate myself "+1/4" on s-c leafs. Where do others stand? > > If we don't add s-c, do we need to stay something in the draft (or > the arch draft) about how/when/why the system can create leafs and > what well-mannered devices need to do about it (refreshing config > after edit-config)? > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Thu Oct 15 11:47: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 DA2B23A6784 for ; Thu, 15 Oct 2009 11:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 yCC31ljiPvIR for ; Thu, 15 Oct 2009 11:47:48 -0700 (PDT) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by core3.amsl.com (Postfix) with SMTP id B8F843A659A for ; Thu, 15 Oct 2009 11:47:48 -0700 (PDT) Received: from [68.142.200.225] by n23.bullet.mail.mud.yahoo.com with NNFMP; 15 Oct 2009 18:47:48 -0000 Received: from [68.142.201.251] by t6.bullet.mud.yahoo.com with NNFMP; 15 Oct 2009 18:47:48 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 15 Oct 2009 18:47:48 -0000 X-Yahoo-Newman-Id: 848088.16908.bm@omp412.mail.mud.yahoo.com Received: (qmail 32009 invoked from network); 15 Oct 2009 18:47:48 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 15 Oct 2009 11:47:48 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: x.rGywUVM1kXCbNckggueByociBF5cFnScyve.rQKXOMUN3rWjUzqR2uzBgTQyFYXID3RtrixYsvB7Lq2.RB7.PH0D3qaUnqZUxQew2GWFWX43md8aTEgN_2jo5lWxpOoVkT.qdrzBBinCjjEj9PdVXLWYJj9muuioTt0KpIJeNAfyeFjpvGr3OYudRv74xZBlcgkSqWlRqZjbzUDIVjamZbJIJEd_z104KGL588s.tF0r8DcEgX2uhiX3toU1lCR0UyPyQHMUPdRT9WfoVzFo2d72e3tqm4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD76E6F.6020807@netconfcentral.com> Date: Thu, 15 Oct 2009 11:48:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200910151757.n9FHvoBi024868@idle.juniper.net> <4AD76862.8020406@joelhalpern.com> In-Reply-To: <4AD76862.8020406@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 18:47:49 -0000 Joel M. Halpern wrote: > I think the s-c is a good thing, and is helpful. > Among other things, it is actually ahrd to describe the problem without > s-c. > > And I think that the base protocol document has to talk clearly about > the problem, and what is permitted or required. At the moment, > different devices can behave differently, in ways that will prevent > interoperability. And different people still seem to understand the > words differently. > I do not see the value of a machine-readable statement to tell the client that the server is going to do a rare thing that doesn't actually affect the client at all, otherwise the client would have set that config explicitly. I think the behavior should be documented somewhere, so it is clear that a client MUST be able to deal with the server adding valid config nodes to running as candidate is being integrated via , or running is being altered via copy-config or edit-config. The only hole in mandatory=true I really cared about was already filled (/rpc/input). I can't think of a reason why I would care if the server picked a valid value for some leaf in the configuration database. The description-stmt can specify if, and how, system-created values are managed for that specific leaf. Mandatory=true means it is the client's responsibility to make sure the node is filled in. If the client doesn't provide an explicit value, the commit may fail. It is possible for the operator/client to read the description statements and make this decision on a per-data-model basis. > Yours, > Joel Andy > > Phil Shafer wrote: >> David Kessens writes: >>> To say it in another way, do either of you have proposals for a >>> solution ? >> >> There are two distinct proposals on the table: >> >> (a) add the text from Martin about s-c leafs >> (b) delay the issue until post-YANG 1.0 >> >> My request for a call comes from my inability to understand which >> side of the issue folks are on. On the conf call, there seems >> overwhelming support for adding s-c leafs. Does that support still >> exist? >> >> I see the case of s-c leafs as a real one, but a very rare one. >> I'm not sure it's worth including in the draft. >> >> One major concern is that an s-c leaf will technically break the >> semantics of locking, in that a lock held during a commit-config >> operation that triggers the creation of s-c leaf means that the >> database is changing while the session has it locked. But one can >> view this as an implicit change performed on behalf of the user >> holding the lock, so it may be viewed as _not_ a violation of >> locking. >> >> In any case, having this scenario documented in a first-class >> statement instead of in the description string seems like a Good >> Thing. But there's a long list of other Good Things we can add, >> and I'm not sure this one is a clear "must have". >> >> So I'd rate myself "+1/4" on s-c leafs. Where do others stand? >> >> If we don't add s-c, do we need to stay something in the draft (or >> the arch draft) about how/when/why the system can create leafs and >> what well-mannered devices need to do about it (refreshing config >> after edit-config)? >> >> Thanks, >> Phil >> _______________________________________________ >> 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 andy@netconfcentral.com Thu Oct 15 11:59: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 6E2B73A6904 for ; Thu, 15 Oct 2009 11:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 GvW5U8A5Vn8a for ; Thu, 15 Oct 2009 11:59:32 -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 C86A43A659A for ; Thu, 15 Oct 2009 11:59:32 -0700 (PDT) Received: (qmail 91435 invoked from network); 15 Oct 2009 18:59:33 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 15 Oct 2009 11:59:33 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: bdMZu5AVM1ncg5VVISFNrfcWuUq.dUmFHJ036z2AQlvlqC7LAn6YZUA8ikzpI7Y2I9qf5pFdU338TGXNPHYC3JO.8cQ_Sgl1wjg.UO27ijUQ.8yGN0.Wf9fm1rjm9Ql9MdO724z98_uXhV7y0vrGKD2u6vZjOmiVKZvUxhACaxPD8zo8fchg_bBkM3GMnklXSFIZeXW.4GiXzZSZJHi9cny2QbjWoNoUNI6le3tNzA_pTECYgleybY23qNt.bweY X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD77131.8020504@netconfcentral.com> Date: Thu, 15 Oct 2009 12:00:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200910151757.n9FHvoBi024868@idle.juniper.net> <4AD76862.8020406@joelhalpern.com> In-Reply-To: <4AD76862.8020406@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 18:59:33 -0000 Joel M. Halpern wrote: > I think the s-c is a good thing, and is helpful. > Among other things, it is actually ahrd to describe the problem without > s-c. > > And I think that the base protocol document has to talk clearly about > the problem, and what is permitted or required. At the moment, > different devices can behave differently, in ways that will prevent > interoperability. And different people still seem to understand the > words differently. > The thing that really changed my mind was looking at code, and thinking from the central stack POV. The stack would have to do a lot of annoying work to prevent an individual server instrumentation callback function from creating a leaf, either during the edit-config or commit PDU processing. The stack trusts that the instrumentation knows how to manage its own portion of the conceptual XML tree. The instrumentation has been written to a specification, which includes description-stmts. Martin also pointed out a long time ago: Why would you code your client to skip mandatory leafs? Of course you are going to write the code so that every mandatory leaf is attempted. I'm not convinced we have a real problem with mandatory at all. > Yours, > Joel Andy From jmh@joelhalpern.com Thu Oct 15 12:05: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 5BA553A6947 for ; Thu, 15 Oct 2009 12:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 lq0qYwNPDapw for ; Thu, 15 Oct 2009 12:05:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9A6333A6893 for ; Thu, 15 Oct 2009 12:05:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 37B9232317B3; Thu, 15 Oct 2009 12:05:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 8080932317B0; Thu, 15 Oct 2009 12:05:45 -0700 (PDT) Message-ID: <4AD77288.6020802@joelhalpern.com> Date: Thu, 15 Oct 2009 15:05:44 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <200910151757.n9FHvoBi024868@idle.juniper.net> <4AD76862.8020406@joelhalpern.com> <4AD77131.8020504@netconfcentral.com> In-Reply-To: <4AD77131.8020504@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 19:05:43 -0000 If I assume your requirements from your other message are documented, then I would agree that we don't have a problem. Unfortunately, that does not match what the current docs say. And your text about what mandatory means and Lada's word choice do not actually match, except in the presence of undocumented assumptions. Yours, Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> I think the s-c is a good thing, and is helpful. >> Among other things, it is actually ahrd to describe the problem without >> s-c. >> >> And I think that the base protocol document has to talk clearly about >> the problem, and what is permitted or required. At the moment, >> different devices can behave differently, in ways that will prevent >> interoperability. And different people still seem to understand the >> words differently. >> > > The thing that really changed my mind was looking at code, > and thinking from the central stack POV. > > The stack would have to do a lot of annoying work > to prevent an individual server instrumentation > callback function from creating a leaf, either > during the edit-config or commit PDU processing. > > The stack trusts that the instrumentation knows > how to manage its own portion of the conceptual XML tree. > The instrumentation has been written to a specification, > which includes description-stmts. > > Martin also pointed out a long time ago: > Why would you code your client to skip mandatory leafs? > Of course you are going to write the code so > that every mandatory leaf is attempted. > > I'm not convinced we have a real problem with mandatory at all. > > >> Yours, >> Joel > > > Andy > From lhotka@cesnet.cz Thu Oct 15 12:27: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 3E50728C13E for ; Thu, 15 Oct 2009 12:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=0.390, 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 Ru6HV37uhZxa for ; Thu, 15 Oct 2009 12:27:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 29BB328C102 for ; Thu, 15 Oct 2009 12:27:48 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C40E6D80096; Thu, 15 Oct 2009 21:27:50 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4AD77288.6020802@joelhalpern.com> References: <200910151757.n9FHvoBi024868@idle.juniper.net> <4AD76862.8020406@joelhalpern.com> <4AD77131.8020504@netconfcentral.com> <4AD77288.6020802@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 15 Oct 2009 21:27:49 +0200 Message-Id: <1255634869.13446.2.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 19:27:49 -0000 Joel M. Halpern píše v ÄŒt 15. 10. 2009 v 15:05 -0400: > If I assume your requirements from your other message are documented, > then I would agree that we don't have a problem. > Unfortunately, that does not match what the current docs say. > > And your text about what mandatory means and Lada's word choice do not > actually match, except in the presence of undocumented assumptions. To avoid any confusion, I support the formulation in Sec. 7.6.4 of -07 and don't see any problem with it. Lada > > Yours, > Joel > > Andy Bierman wrote: > > Joel M. Halpern wrote: > >> I think the s-c is a good thing, and is helpful. > >> Among other things, it is actually ahrd to describe the problem without > >> s-c. > >> > >> And I think that the base protocol document has to talk clearly about > >> the problem, and what is permitted or required. At the moment, > >> different devices can behave differently, in ways that will prevent > >> interoperability. And different people still seem to understand the > >> words differently. > >> > > > > The thing that really changed my mind was looking at code, > > and thinking from the central stack POV. > > > > The stack would have to do a lot of annoying work > > to prevent an individual server instrumentation > > callback function from creating a leaf, either > > during the edit-config or commit PDU processing. > > > > The stack trusts that the instrumentation knows > > how to manage its own portion of the conceptual XML tree. > > The instrumentation has been written to a specification, > > which includes description-stmts. > > > > Martin also pointed out a long time ago: > > Why would you code your client to skip mandatory leafs? > > Of course you are going to write the code so > > that every mandatory leaf is attempted. > > > > I'm not convinced we have a real problem with mandatory at all. > > > > > >> Yours, > >> Joel > > > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From kwatsen@juniper.net Thu Oct 15 12:29: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 CA9A93A6984 for ; Thu, 15 Oct 2009 12:29:55 -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 NWKlgmms6HLy for ; Thu, 15 Oct 2009 12:29:55 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id C6BBB3A6825 for ; Thu, 15 Oct 2009 12:29:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKStd4Mwaau3WtTskdLHEoLfvpFIoodrEe@postini.com; Thu, 15 Oct 2009 12:29:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 15 Oct 2009 12:29:52 -0700 From: Kent Watsen To: Phil Shafer , Juergen Schoenwaelder Date: Thu, 15 Oct 2009 12:29:51 -0700 Thread-Topic: [netmod] What is config? Thread-Index: AcpNkrQDeXk8cjtMSWGQIzC7BKA9jQAOuuEg Message-ID: <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> In-Reply-To: <200910151209.n9FC9MCZ022703@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] What is 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, 15 Oct 2009 19:29:55 -0000 It looks like a helpful addition to the arch draft, though I would leave ou= t the "Implications" section since it is speculative... Thanks, Kent > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Phil Shafer > Sent: Thursday, October 15, 2009 8:09 AM > To: Juergen Schoenwaelder > Cc: NETMOD Working Group > Subject: Re: [netmod] What is config? >=20 > Juergen Schoenwaelder writes: > >See the start of the thread "Configuration Data versus Operational > >State Data versus Statistics": > > > >http://www.ietf.org/mail-archive/web/netmod/current/msg03850.html >=20 > Apologies, I missed this thread. Unless there are objections, > I'll add this to the arch draft. >=20 > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu Oct 15 12:44: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 3A1143A6969 for ; Thu, 15 Oct 2009 12:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[AWL=0.071, 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 ESfmi4WkzDzX for ; Thu, 15 Oct 2009 12:44:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1045F3A68ED for ; Thu, 15 Oct 2009 12:44:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A761C000C; Thu, 15 Oct 2009 21:44:37 +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 mo0Imb7hV3p8; Thu, 15 Oct 2009 21:44:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A350AC0004; Thu, 15 Oct 2009 21:44:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 21DE4D4390D; Thu, 15 Oct 2009 21:44:35 +0200 (CEST) Date: Thu, 15 Oct 2009 21:44:35 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20091015194435.GB125@elstar.local> Mail-Followup-To: Phil Shafer , David Kessens , NETMOD Working Group References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910151757.n9FHvoBi024868@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] finish up 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, 15 Oct 2009 19:44:35 -0000 On Thu, Oct 15, 2009 at 07:57:49PM +0200, Phil Shafer wrote: > In any case, having this scenario documented in a first-class > statement instead of in the description string seems like a Good > Thing. But there's a long list of other Good Things we can add, > and I'm not sure this one is a clear "must have". > > So I'd rate myself "+1/4" on s-c leafs. Where do others stand? My recollection is that we did not agree what defaults are. And one _part_ of the discussion was around s-c leafs - so we came up with a proposal to formalize this. Now such a proposal is on the table and it seems not all people agree to it and it seems some people prefer to defer this issues post 1.0 so we don't have to work it out. Going back to the original discussion, does it mean we now agree what defaults are? Do we agree what config is? I am fine with not adding stuff to the language - or even removing stuff. But I like to see some agreement about basic concepts to be well documented so that at least all active contributors read the sentences leading to the same interpretation of the words they have read. /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 Oct 15 13:23:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2333A690E for ; Thu, 15 Oct 2009 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_20=-0.74, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 5mJl-RCzjkUz for ; Thu, 15 Oct 2009 13:23:39 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 8823A3A689D for ; Thu, 15 Oct 2009 13:23:39 -0700 (PDT) Received: from [68.142.194.243] by n17.bullet.mail.mud.yahoo.com with NNFMP; 15 Oct 2009 20:23:41 -0000 Received: from [68.142.201.73] by t1.bullet.mud.yahoo.com with NNFMP; 15 Oct 2009 20:23:41 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 15 Oct 2009 20:23:41 -0000 X-Yahoo-Newman-Id: 763.90073.bm@omp425.mail.mud.yahoo.com Received: (qmail 75587 invoked from network); 15 Oct 2009 20:23:40 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 15 Oct 2009 13:23:40 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: X_W2JxcVM1kbHjJprkid_4cwp8Jkswn0fnGCnbQXpQsQzR0wpnQPlnIUlImDweJyPKKu1S4SSD7T60.IO94VBmcib638nhtZamnVU3V6uJ36L0uO3brY5M21L_8A.uBpHq.gELfJTHfPF7hDJs69cFTF_1jIWZzh.rwnub6ZPUnq4O45XpLUKSjtJNr.Dvyaj_rQmqHtdfglqMFy0zj360byDOOqJF6LRW0ca2LcKn72t3Phl6m6V3ktYwKEJdie X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD784E7.102@netconfcentral.com> Date: Thu, 15 Oct 2009 13:24:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer , David Kessens , NETMOD Working Group References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> In-Reply-To: <20091015194435.GB125@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2009 20:23:40 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 15, 2009 at 07:57:49PM +0200, Phil Shafer wrote: > >> In any case, having this scenario documented in a first-class >> statement instead of in the description string seems like a Good >> Thing. But there's a long list of other Good Things we can add, >> and I'm not sure this one is a clear "must have". >> >> So I'd rate myself "+1/4" on s-c leafs. Where do others stand? > > My recollection is that we did not agree what defaults are. And one > _part_ of the discussion was around s-c leafs - so we came up with a > proposal to formalize this. Now such a proposal is on the table and it > seems not all people agree to it and it seems some people prefer to > defer this issues post 1.0 so we don't have to work it out. Going back > to the original discussion, does it mean we now agree what defaults > are? Do we agree what config is? > > I am fine with not adding stuff to the language - or even removing > stuff. But I like to see some agreement about basic concepts to be > well documented so that at least all active contributors read the > sentences leading to the same interpretation of the words they have > read. > Before several comments from lots of people, it wasn't clear how s-c really affected everything already in place. Phil and Martin made me realize the client doesn't need to worry about s-c leafs creating during the commit, and that is not harmful to the client at all. Static defaults are handled rather well in YANG. There is flexibility with refine and deviation to specify the default, even for a particular session. Algorithmic defaults should be left to the future, such as XPath expressions to define the algorithm. System created defaults which cannot be documented with default-stmt, refine-stmt, or deviation-stmt, or a TBD dynamic-default-stmt, should be quite rare. These s-c leafs that cannot pick a value until the commit should be allowed, but we don't need any special rules because after they appear in running, they are normal leafs. I am willing to say all YANG config constraints apply to the visible config=true nodes + YANG defaults, and leave constraints applied to the operational state as future work. That means the operator must make sure all the nodes referenced in must/when expressions exist in the configuration, or contain the default value. > /js > Andy From cfinss@dial.pipex.com Fri Oct 16 10:23: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 6324828C114 for ; Fri, 16 Oct 2009 10:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.429 X-Spam-Level: * X-Spam-Status: No, score=1.429 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_50=0.001, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om4JJ1WX7e4v for ; Fri, 16 Oct 2009 10:23:55 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 76BBF3A69B2 for ; Fri, 16 Oct 2009 10:23:55 -0700 (PDT) X-Trace: 204168354/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.39/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.39 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAA9J2Eo+vGkn/2dsb2JhbACDJUKNHshBCoQmBA X-IronPort-AV: E=Sophos;i="4.44,574,1249254000"; d="scan'208";a="204168354" X-IP-Direction: IN Received: from 1cust39.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.39]) by smtp.pipex.tiscali.co.uk with SMTP; 16 Oct 2009 18:23:50 +0100 Message-ID: <001101ca4e7c$bba45220$0601a8c0@allison> From: "tom.petch" To: "Kent Watsen" , "Phil Shafer" , "Juergen Schoenwaelder" References: <20091015064200.GA22071@elstar.local><200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> Date: Fri, 16 Oct 2009 18:00:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETMOD Working Group Subject: Re: [netmod] What is config? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:23:56 -0000 I think that that discussion went down a rat hole - apologies for my part in that - leaving the main issue of what constitutes what in this tri-partite split unresolved. So, no, I see no consensus to add that to any I-D. What is config is an unresolved issue. Tom Petch ----- Original Message ----- From: "Kent Watsen" To: "Phil Shafer" ; "Juergen Schoenwaelder" Cc: "NETMOD Working Group" Sent: Thursday, October 15, 2009 9:29 PM Subject: Re: [netmod] What is config? > > It looks like a helpful addition to the arch draft, though I would leave out the "Implications" section since it is speculative... > > Thanks, > Kent > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > > Of Phil Shafer > > Sent: Thursday, October 15, 2009 8:09 AM > > To: Juergen Schoenwaelder > > Cc: NETMOD Working Group > > Subject: Re: [netmod] What is config? > > > > Juergen Schoenwaelder writes: > > >See the start of the thread "Configuration Data versus Operational > > >State Data versus Statistics": > > > > > >http://www.ietf.org/mail-archive/web/netmod/current/msg03850.html > > > > Apologies, I missed this thread. Unless there are objections, > > I'll add this to the arch draft. > > > > Thanks, > > Phil From cfinss@dial.pipex.com Fri Oct 16 10:23: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 13F673A68C1 for ; Fri, 16 Oct 2009 10:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMP-WdMgaxJm for ; Fri, 16 Oct 2009 10:23:56 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 16F2B28C0FF for ; Fri, 16 Oct 2009 10:23:55 -0700 (PDT) X-Trace: 204168378/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.39/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.39 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAA9J2Eo+vGkn/2dsb2JhbACDJUKNHrk2CY8CAgiCRIFiBA X-IronPort-AV: E=Sophos;i="4.44,574,1249254000"; d="scan'208";a="204168378" X-IP-Direction: IN Received: from 1cust39.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.39]) by smtp.pipex.tiscali.co.uk with SMTP; 16 Oct 2009 18:23:58 +0100 Message-ID: <001201ca4e7c$bc661b80$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <20091014232652.GC16302@nsn.com><200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> Date: Fri, 16 Oct 2009 18:19:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:23:57 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" j.schoenwaelder@jacobs-university.de Sent: Thursday, October 15, 2009 9:44 PM > My recollection is that we did not agree what defaults are. And one > _part_ of the discussion was around s-c leafs - so we came up with a > proposal to formalize this. Now such a proposal is on the table and it > seems not all people agree to it and it seems some people prefer to > defer this issues post 1.0 so we don't have to work it out. Going back > to the original discussion, does it mean we now agree what defaults > are? Do we agree what config is? My take is no and no, the latter, what config is, being the major stumbling block. Tom Petch > I am fine with not adding stuff to the language - or even removing > stuff. But I like to see some agreement about basic concepts to be > well documented so that at least all active contributors read the > sentences leading to the same interpretation of the words they have > read. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Oct 16 11:54:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510A93A67B1 for ; Fri, 16 Oct 2009 11:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkwBG5fkmiC9 for ; Fri, 16 Oct 2009 11:54:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5D3283A685E for ; Fri, 16 Oct 2009 11:54:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50275C0009; Fri, 16 Oct 2009 20:54:41 +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 z-n-iEPic3Vp; Fri, 16 Oct 2009 20:54:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09A1EC0005; Fri, 16 Oct 2009 20:54:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 803D6D44E38; Fri, 16 Oct 2009 20:54:39 +0200 (CEST) Date: Fri, 16 Oct 2009 20:54:39 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20091016185439.GB1841@elstar.local> Mail-Followup-To: "tom.petch" , Kent Watsen , Phil Shafer , NETMOD Working Group References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> <001101ca4e7c$bba45220$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001101ca4e7c$bba45220$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] What is config? 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, 16 Oct 2009 18:54:38 -0000 On Fri, Oct 16, 2009 at 06:00:12PM +0200, tom.petch wrote: > I think that that discussion went down a rat hole - apologies > for my part in that - leaving the main issue of what constitutes > what in this tri-partite split unresolved. > > So, no, I see no consensus to add that to any I-D. > > What is config is an unresolved issue. Can you be a bit more constructive and explain what is wrong with the text so that we can fix it and make forward progress? /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 Oct 16 12:38: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 817423A68B7 for ; Fri, 16 Oct 2009 12:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_40=-0.185, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=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 6h0IoAsQKeBA for ; Fri, 16 Oct 2009 12:38:47 -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 C67953A63D3 for ; Fri, 16 Oct 2009 12:38:47 -0700 (PDT) Received: from [209.191.108.96] by n11.bullet.mail.mud.yahoo.com with NNFMP; 16 Oct 2009 19:38:50 -0000 Received: from [68.142.201.240] by t3.bullet.mud.yahoo.com with NNFMP; 16 Oct 2009 19:38:50 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 16 Oct 2009 19:38:50 -0000 X-Yahoo-Newman-Id: 579478.75129.bm@omp401.mail.mud.yahoo.com Received: (qmail 70191 invoked from network); 16 Oct 2009 19:38:50 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 16 Oct 2009 12:38:50 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8J37dcUVM1k9esTMK.dhx6oPda77piWl6vtBu8SMLbbNybbeWzqlpOhvNseoiTd959lOK9nEexriY6jpT3J3K3hQ7OcRDxEv1ndg.Ac1GEeiQ6gDnS7sFONbD6aT275FkbxHuQxUAEzwJPpStD4YdHwQHYnPZ6n21TNQQRnCHMT8o0N01n9iyGR3TfaO_BS7M0aniat8KFyP.25l8CSB0WXiUtTlGfIjHUqTyZS9NNtLf_X.3.o2B52QO6FRvEgQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD8CBE9.4020504@netconfcentral.com> Date: Fri, 16 Oct 2009 12:39:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" , Kent Watsen , Phil Shafer , NETMOD Working Group References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> <001101ca4e7c$bba45220$0601a8c0@allison> <20091016185439.GB1841@elstar.local> In-Reply-To: <20091016185439.GB1841@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] What is 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: Fri, 16 Oct 2009 19:38:48 -0000 Juergen Schoenwaelder wrote: > On Fri, Oct 16, 2009 at 06:00:12PM +0200, tom.petch wrote: >> I think that that discussion went down a rat hole - apologies >> for my part in that - leaving the main issue of what constitutes >> what in this tri-partite split unresolved. >> >> So, no, I see no consensus to add that to any I-D. >> >> What is config is an unresolved issue. > > Can you be a bit more constructive and explain what is wrong with the > text so that we can fix it and make forward progress? > I am willing to leave this area of work for the future, but a concern I have is that description-stmts and constraints are traditionally written to describe what happens in the running system. Nothing 'happens' in the config file. It is not intuitive at all to think about a data model object semantics this way. At first it was not clear that s-c leafs are 'sticky' -- they stay in the config as soon as they are created and do not change. IMO, there is no value in a s-c clause, just document the behavior wrt/candidate and that is enough. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Oct 16 12:59: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 F0DD73A68B7 for ; Fri, 16 Oct 2009 12:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzNUBNK+srqx for ; Fri, 16 Oct 2009 12:59: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 BE5E33A63D3 for ; Fri, 16 Oct 2009 12:59:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4AD9C0009; Fri, 16 Oct 2009 21:59:51 +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 io6BmV+nUqCd; Fri, 16 Oct 2009 21:59:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94DA6C0005; Fri, 16 Oct 2009 21:59:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 106CDD4513D; Fri, 16 Oct 2009 21:59:50 +0200 (CEST) Date: Fri, 16 Oct 2009 21:59:50 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091016195949.GB2207@elstar.local> Mail-Followup-To: Andy Bierman , "tom.petch" , Kent Watsen , Phil Shafer , NETMOD Working Group References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> <001101ca4e7c$bba45220$0601a8c0@allison> <20091016185439.GB1841@elstar.local> <4AD8CBE9.4020504@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD8CBE9.4020504@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] What is config? 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, 16 Oct 2009 19:59:49 -0000 On Fri, Oct 16, 2009 at 09:39:21PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Oct 16, 2009 at 06:00:12PM +0200, tom.petch wrote: > >> I think that that discussion went down a rat hole - apologies > >> for my part in that - leaving the main issue of what constitutes > >> what in this tri-partite split unresolved. > >> > >> So, no, I see no consensus to add that to any I-D. > >> > >> What is config is an unresolved issue. > > > > Can you be a bit more constructive and explain what is wrong with the > > text so that we can fix it and make forward progress? > > > > I am willing to leave this area of work > for the future, but a concern I have is > that description-stmts and constraints > are traditionally written to describe > what happens in the running system. > > Nothing 'happens' in the config file. > It is not intuitive at all to think > about a data model object semantics this way. > > At first it was not clear that s-c leafs are 'sticky' -- > they stay in the config as soon as they are created and > do not change. IMO, there is no value in a s-c clause, > just document the behavior wrt/candidate and that is enough. Are you in the wrong thread? /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 Oct 16 13:29: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 715C73A67B6 for ; Fri, 16 Oct 2009 13:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_05=-1.11, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=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 QAX17VgsXfyF for ; Fri, 16 Oct 2009 13:29:12 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id B4BA53A67A2 for ; Fri, 16 Oct 2009 13:29:12 -0700 (PDT) Received: (qmail 70967 invoked from network); 16 Oct 2009 20:29:14 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 16 Oct 2009 13:29:14 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: iWVbX7sVM1lqGc_MJIIxOsI_hqaI20xDsgDRcciRvzLaKLfLokKGuI71KZGzmqrNTd7RLMWE9ulEKgYS6Is4YSNiz7XB_EVcJZlk8n8mgz7FTxTkO8AVWTIEI5C1dXUumWMFvUp29zxIFvX62DHLfxcQM572oG3d.70a1ABXGwrBxxIbeLddP9TbhD2xhHnBpgPWTe9L8w2aEiOaB9ID7PUzVeqTf.1aK0TOjFDAiGTGy77RYwWi45JX5L..sjU70QqHof20SRIqRNuIs7GD8y8cKMcrf9Ef0SsPgSVjknCNlXK3BpxED4HYctmp2I1n X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD8D7B9.9020408@netconfcentral.com> Date: Fri, 16 Oct 2009 13:29:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , "tom.petch" , Kent Watsen , Phil Shafer , NETMOD Working Group References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> <001101ca4e7c$bba45220$0601a8c0@allison> <20091016185439.GB1841@elstar.local> <4AD8CBE9.4020504@netconfcentral.com> <20091016195949.GB2207@elstar.local> In-Reply-To: <20091016195949.GB2207@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] What is 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: Fri, 16 Oct 2009 20:29:13 -0000 Juergen Schoenwaelder wrote: > On Fri, Oct 16, 2009 at 09:39:21PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Oct 16, 2009 at 06:00:12PM +0200, tom.petch wrote: >>>> I think that that discussion went down a rat hole - apologies >>>> for my part in that - leaving the main issue of what constitutes >>>> what in this tri-partite split unresolved. >>>> >>>> So, no, I see no consensus to add that to any I-D. >>>> >>>> What is config is an unresolved issue. >>> Can you be a bit more constructive and explain what is wrong with the >>> text so that we can fix it and make forward progress? >>> >> I am willing to leave this area of work >> for the future, but a concern I have is >> that description-stmts and constraints >> are traditionally written to describe >> what happens in the running system. >> >> Nothing 'happens' in the config file. >> It is not intuitive at all to think >> about a data model object semantics this way. >> >> At first it was not clear that s-c leafs are 'sticky' -- >> they stay in the config as soon as they are created and >> do not change. IMO, there is no value in a s-c clause, >> just document the behavior wrt/candidate and that is enough. > > Are you in the wrong thread? > no -- system-creatable is part of the config definition. So is default, mandatory, unique, etc. All the scattered rules combine to create some sort of architecture. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Oct 16 13:31: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 19E563A6817 for ; Fri, 16 Oct 2009 13:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLhqo9HzEFJO for ; Fri, 16 Oct 2009 13:31: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 E2DF03A682B for ; Fri, 16 Oct 2009 13:31:23 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18732C0009; Fri, 16 Oct 2009 22:31:28 +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 tR-vsSsjc4AQ; Fri, 16 Oct 2009 22:31:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77100C0005; Fri, 16 Oct 2009 22:31:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 06580D453E3; Fri, 16 Oct 2009 22:31:25 +0200 (CEST) Date: Fri, 16 Oct 2009 22:31:25 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091016203125.GA2387@elstar.local> Mail-Followup-To: Andy Bierman , "tom.petch" , Kent Watsen , Phil Shafer , NETMOD Working Group References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> <001101ca4e7c$bba45220$0601a8c0@allison> <20091016185439.GB1841@elstar.local> <4AD8CBE9.4020504@netconfcentral.com> <20091016195949.GB2207@elstar.local> <4AD8D7B9.9020408@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD8D7B9.9020408@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] What is config? 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, 16 Oct 2009 20:31:25 -0000 On Fri, Oct 16, 2009 at 10:29:45PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Oct 16, 2009 at 09:39:21PM +0200, Andy Bierman wrote: > >> Juergen Schoenwaelder wrote: > >>> On Fri, Oct 16, 2009 at 06:00:12PM +0200, tom.petch wrote: > >>>> I think that that discussion went down a rat hole - apologies > >>>> for my part in that - leaving the main issue of what constitutes > >>>> what in this tri-partite split unresolved. > >>>> > >>>> So, no, I see no consensus to add that to any I-D. > >>>> > >>>> What is config is an unresolved issue. > >>> Can you be a bit more constructive and explain what is wrong with the > >>> text so that we can fix it and make forward progress? > >>> > >> I am willing to leave this area of work > >> for the future, but a concern I have is > >> that description-stmts and constraints > >> are traditionally written to describe > >> what happens in the running system. > >> > >> Nothing 'happens' in the config file. > >> It is not intuitive at all to think > >> about a data model object semantics this way. > >> > >> At first it was not clear that s-c leafs are 'sticky' -- > >> they stay in the config as soon as they are created and > >> do not change. IMO, there is no value in a s-c clause, > >> just document the behavior wrt/candidate and that is enough. > > > > Are you in the wrong thread? > > > > no -- system-creatable is part of the config definition. > So is default, mandatory, unique, etc. All the scattered > rules combine to create some sort of architecture. I still think you are in the wrong thread. This thread was supposed to discuss the text for the architecture document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Oct 16 19:58: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 5E6A93A6842 for ; Fri, 16 Oct 2009 19:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGeUCil+LiLY for ; Fri, 16 Oct 2009 19:58:19 -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 7B2173A682E for ; Fri, 16 Oct 2009 19:58:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iaAR03Z5Nd7blrFIopG2+khUmzm6WNh8V9tlRgt37X6mTYgJ0+L2SJif6y9JaFgY; 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 [99.30.226.77] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MyzUr-00045I-La for netmod@ietf.org; Fri, 16 Oct 2009 22:58:21 -0400 Message-ID: <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091012.183346.123577726.mbj@tail-f.com> Date: Fri, 16 Oct 2009 19:59:48 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9ec77b5f91215b1fd9bd9e5676fb63fa3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.77 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 02:58:20 -0000 Hi - > From: "Martin Bjorklund" > To: > Sent: Monday, October 12, 2009 9:33 AM > Subject: [netmod] system-creatable ... > Here is proposed text for a new statement "system-creatable" > (a.k.a. "assigned-by system"). > > > 7.6.6. The leaf's system-creatable Statement > > The "system-creatable" statement, which is optional, specifies > whether the server is permitted to create instances of a leaf. Such > leafs are used when the device needs to record persistent values that > cannot be known until the device validates the configuration. The > argument is one of the strings "true" or "false". If not specified, > the default is "false". > > If "system-creatable" is "true", the server MAY create an instance of Replace "MAY" with "MUST". Otherwise, interoperability will suffer. > the leaf in the data tree, if it doesn't exist, in the following > cases. The behavior depends on the leaf's closest ancestor node in > the schema tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the server MAY Replace "MAY" with "MUST". > create an instance of the leaf if it doesn't exist. > > o Otherwise, if this ancestor is a case node, the server MAY create Replace "MAY" with "MUST". > an instance of the leaf in the data tree if any node from the case > exists in the data tree, or if the case node is the choice's > default case, and no nodes from any other case exist in the data > tree. > > o Otherwise, the server MAY create an instance of the leaf in the > data tree if the ancestor node exists in the data tree. Replace "MAY" with "MUST". As I see it, the only difference between system-creatable and "default" is that a default value is explicitly given in the model, and is consequently in some sense redundant when given in response to a retrieval operation. Randy From jmh@joelhalpern.com Fri Oct 16 20:04: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 436533A68F0 for ; Fri, 16 Oct 2009 20:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 3kIFlv7L3P1Y for ; Fri, 16 Oct 2009 20:04:27 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 847F43A67EA for ; Fri, 16 Oct 2009 20:04:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5650B323188E; Fri, 16 Oct 2009 20:04:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id B1290323188B; Fri, 16 Oct 2009 20:04:31 -0700 (PDT) Message-ID: <4AD93440.1020007@joelhalpern.com> Date: Fri, 16 Oct 2009 23:04:32 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Randy Presuhn References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> In-Reply-To: <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 03:04:28 -0000 I do not think the intend was that if something is marked system-createable, then the system is required to ensure that it exists. Rather, it was a notification to the client that if the client cares about this node, then after doing a config commit (and maybe after doing a verify, we need to sort that out), the client should check to see if the system has created a value for the node. I do not believe that there is any interoperability problem if the system does not create the node. After all, if the system does need a value for the node, then the system will create it. Yours, Joel Randy Presuhn wrote: > Hi - > >> From: "Martin Bjorklund" >> To: >> Sent: Monday, October 12, 2009 9:33 AM >> Subject: [netmod] system-creatable > ... >> Here is proposed text for a new statement "system-creatable" >> (a.k.a. "assigned-by system"). >> >> >> 7.6.6. The leaf's system-creatable Statement >> >> The "system-creatable" statement, which is optional, specifies >> whether the server is permitted to create instances of a leaf. Such >> leafs are used when the device needs to record persistent values that >> cannot be known until the device validates the configuration. The >> argument is one of the strings "true" or "false". If not specified, >> the default is "false". >> >> If "system-creatable" is "true", the server MAY create an instance of > > Replace "MAY" with "MUST". Otherwise, interoperability will suffer. > >> the leaf in the data tree, if it doesn't exist, in the following >> cases. The behavior depends on the leaf's closest ancestor node in >> the schema tree which is not a non-presence container: >> >> o If no such ancestor exists in the schema tree, the server MAY > > Replace "MAY" with "MUST". > >> create an instance of the leaf if it doesn't exist. >> >> o Otherwise, if this ancestor is a case node, the server MAY create > > Replace "MAY" with "MUST". > >> an instance of the leaf in the data tree if any node from the case >> exists in the data tree, or if the case node is the choice's >> default case, and no nodes from any other case exist in the data >> tree. >> >> o Otherwise, the server MAY create an instance of the leaf in the >> data tree if the ancestor node exists in the data tree. > > Replace "MAY" with "MUST". > > As I see it, the only difference between system-creatable and "default" > is that a default value is explicitly given in the model, and is consequently > in some sense redundant when given in response to a retrieval operation. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From randy_presuhn@mindspring.com Fri Oct 16 20:22: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 DBBE13A69EF for ; Fri, 16 Oct 2009 20:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cys1USHYK9PC for ; Fri, 16 Oct 2009 20:22:28 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 161BD3A69EB for ; Fri, 16 Oct 2009 20:22:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KKkn188yuJPkYG0D+V5p7O+/uaWIqutAGneedvPaNGOf2/3VKBn2AjJqXFbe43AC; 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 [99.30.226.77] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MyzsE-0007vp-DI for netmod@ietf.org; Fri, 16 Oct 2009 23:22:30 -0400 Message-ID: <024301ca4ed9$46701220$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> Date: Fri, 16 Oct 2009 20:24:01 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9b8db07bf84431073134d79349278cdf0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.77 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 03:22:29 -0000 Hi - > From: "Joel M. Halpern" > To: "Randy Presuhn" > Cc: > Sent: Friday, October 16, 2009 8:04 PM > Subject: Re: [netmod] system-creatable > > I do not think the intend was that if something is marked > system-createable, then the system is required to ensure that it exists. > Rather, it was a notification to the client that if the client cares > about this node, then after doing a config commit (and maybe after doing > a verify, we need to sort that out), the client should check to see if > the system has created a value for the node. > > I do not believe that there is any interoperability problem if the > system does not create the node. After all, if the system does need a > value for the node, then the system will create it. The proposed text does not say so. It merely says "MAY". The only hint of support for your reading is "Such leafs are used when the device needs to record persistent values that cannot be known until the device validates the configuration." That text, however, only provides rationale, and does not require devices that "need" values to actually create them. If your reading is what is intended, the text needs to be more explicit. Randy From jmh@joelhalpern.com Fri Oct 16 20:43: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 60D0D3A6814 for ; Fri, 16 Oct 2009 20:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 eqLMOjpRjpn6 for ; Fri, 16 Oct 2009 20:42:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3EFA93A67E7 for ; Fri, 16 Oct 2009 20:42:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 43BCE3232098; Fri, 16 Oct 2009 20:43:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 967A43232097; Fri, 16 Oct 2009 20:43:02 -0700 (PDT) Message-ID: <4AD93D47.9040303@joelhalpern.com> Date: Fri, 16 Oct 2009 23:43:03 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Randy Presuhn References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> In-Reply-To: <024301ca4ed9$46701220$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 03:43:01 -0000 I can well believe that the text needs to be more explicit. Yours, Joel Randy Presuhn wrote: > Hi - > >> From: "Joel M. Halpern" >> To: "Randy Presuhn" >> Cc: >> Sent: Friday, October 16, 2009 8:04 PM >> Subject: Re: [netmod] system-creatable >> >> I do not think the intend was that if something is marked >> system-createable, then the system is required to ensure that it exists. >> Rather, it was a notification to the client that if the client cares >> about this node, then after doing a config commit (and maybe after doing >> a verify, we need to sort that out), the client should check to see if >> the system has created a value for the node. >> >> I do not believe that there is any interoperability problem if the >> system does not create the node. After all, if the system does need a >> value for the node, then the system will create it. > > The proposed text does not say so. > > It merely says "MAY". The only hint of support for your > reading is "Such leafs are used when the device needs to > record persistent values that cannot be known until the device > validates the configuration." That text, however, only provides > rationale, and does not require devices that "need" values to > actually create them. > > If your reading is what is intended, the text needs to be more > explicit. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Sat Oct 17 03:26:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5CB3A659B for ; Sat, 17 Oct 2009 03:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[AWL=-0.852, 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 FxY61HPnQNGV for ; Sat, 17 Oct 2009 03:26:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 37E4F3A67A8 for ; Sat, 17 Oct 2009 03:26:39 -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 C3EB6D800C0 for ; Sat, 17 Oct 2009 12:26:39 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Sat, 17 Oct 2009 12:26:38 +0200 Message-Id: <1255775198.7825.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] proposed change to 7.3.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 10:26:41 -0000 Hi, the last paragraph in Sec. 7.3.4 should also cover the case when a restriction specified in a leaf definition is incompatible with the default value of the leaf's type. OLD If the base type has a default value, and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. If the base type's default value is not valid according to the new restrictions, the derived type MUST define a new default value. NEW If the base type has a default value, and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. If the base type's default value is not valid according to the new restrictions specified in a derived type or leaf definition, the derived type or leaf definition MUST specify a new default value compatible with the restrictions. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Sat Oct 17 05:06: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 BE8313A6851 for ; Sat, 17 Oct 2009 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.383 X-Spam-Level: X-Spam-Status: No, score=0.383 tagged_above=-999 required=5 tests=[AWL=-0.781, 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 igFUF+t2I4xx for ; Sat, 17 Oct 2009 05:06:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A30283A677D for ; Sat, 17 Oct 2009 05:06:00 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7CEB1D800CC; Sat, 17 Oct 2009 14:06:04 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <001201ca4e7c$bc661b80$0601a8c0@allison> References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> <001201ca4e7c$bc661b80$0601a8c0@allison> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 17 Oct 2009 14:06:02 +0200 Message-Id: <1255781162.4652.11.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 12:06:01 -0000 tom.petch píše v Pá 16. 10. 2009 v 18:19 +0200: > ---- Original Message ----- > From: "Juergen Schoenwaelder" j.schoenwaelder@jacobs-university.de > Sent: Thursday, October 15, 2009 9:44 PM > > > My recollection is that we did not agree what defaults are. And one > > _part_ of the discussion was around s-c leafs - so we came up with a > > proposal to formalize this. Now such a proposal is on the table and it > > seems not all people agree to it and it seems some people prefer to > > defer this issues post 1.0 so we don't have to work it out. Going back > > to the original discussion, does it mean we now agree what defaults > > are? Do we agree what config is? > > My take is no and no, the latter, what config is, being the major stumbling > block. I believe the 'default' issue can be resolved by a minor reformulation - something is probably already in the queue for -08. My interpretation is that 'default' is a statement that allows to determine when two configurations with differing infosets are equivalent - with all consequences for server behaviour etc. What a config is seems more complicated. I think though it is necessary to settle on what a "canonical" configuration is - it is the one to which all YANG constraints apply. My impression from the conf call was that the participants agreed that this should be the "report-all" style with all defaults filled-in. Lada > > Tom Petch > > > I am fine with not adding stuff to the language - or even removing > > stuff. But I like to see some agreement about basic concepts to be > > well documented so that at least all active contributors read the > > sentences leading to the same interpretation of the words they have > > read. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Oct 17 08: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 655953A6934 for ; Sat, 17 Oct 2009 08:39:27 -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=-1.129, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=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 qE40y3IzNBdH for ; Sat, 17 Oct 2009 08:39:26 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 6BAFE3A6827 for ; Sat, 17 Oct 2009 08:39:26 -0700 (PDT) Received: (qmail 56864 invoked from network); 17 Oct 2009 15:39:29 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 17 Oct 2009 08:39:29 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: o0T3dVYVM1lx.f33e0ZEVWSNgjAn.M1ySpIh6DteYy97zIm4xTEthyXvPMETZIxfCGhreJ86P_vqTG_4womOSGKtvV3QbHpo7ZOVWJS5bTwW_cuO8p8GZ0HXQGcIjo7GxFCuOfgwMt.wi0OTza63kdnDiMxTSm2PtVzpKcUialYCS09nup2iStg7T6Zqj_DvG07IpM0JeW26vBUa7eOZni2rw17PuTT7Q3WiNsuNuaoPqLvd7ciNkdOGUx9bJX3XhVpg X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD9E554.2070004@netconfcentral.com> Date: Sat, 17 Oct 2009 08:40:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> <001201ca4e7c$bc661b80$0601a8c0@allison> <1255781162.4652.11.camel@nomad> In-Reply-To: <1255781162.4652.11.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 15:39:27 -0000 Ladislav Lhotka wrote: > tom.petch píše v Pá 16. 10. 2009 v 18:19 +0200: >> ---- Original Message ----- >> From: "Juergen Schoenwaelder" j.schoenwaelder@jacobs-university.de >> Sent: Thursday, October 15, 2009 9:44 PM >> >>> My recollection is that we did not agree what defaults are. And one >>> _part_ of the discussion was around s-c leafs - so we came up with a >>> proposal to formalize this. Now such a proposal is on the table and it >>> seems not all people agree to it and it seems some people prefer to >>> defer this issues post 1.0 so we don't have to work it out. Going back >>> to the original discussion, does it mean we now agree what defaults >>> are? Do we agree what config is? >> My take is no and no, the latter, what config is, being the major stumbling >> block. > > I believe the 'default' issue can be resolved by a minor reformulation - > something is probably already in the queue for -08. My interpretation is > that 'default' is a statement that allows to determine when two > configurations with differing infosets are equivalent - with all > consequences for server behaviour etc. > > What a config is seems more complicated. I think though it is necessary > to settle on what a "canonical" configuration is - it is the one to > which all YANG constraints apply. My impression from the conf call was > that the participants agreed that this should be the "report-all" style > with all defaults filled-in. > Yes -- this is what I remember. I also remember several times we were reassured that a server-created leaf that did not contain the YANG default value did exist. Then it changed to they exist in running, but not candidate. The servers that implement 'explicit' basic behavior for filtering defaults will never show the client these s-c leafs, even in the running config. The solution of forcing data modelers to ignore s-c leafs in constraint rules is not going to work, especially if these leafs are supposed to turn into 'normal' leafs. The s-c leaf is unmanageable without with-defaults=report-all. It is essentially an undocumented default -- a leaf invisible from the client, except the client has no clue what value the server is using. Setting s-c=true is supposed to be a license to keep these leafs invisible from the client. That alone is reason not to add to the system-creatable statement. > Lada > Andy > >> Tom Petch >> >>> I am fine with not adding stuff to the language - or even removing >>> stuff. But I like to see some agreement about basic concepts to be >>> well documented so that at least all active contributors read the >>> sentences leading to the same interpretation of the words they have >>> read. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Sat Oct 17 09:34: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 A4B163A6980 for ; Sat, 17 Oct 2009 09:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_40=-0.185, 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 nL4wMkd7NhvG for ; Sat, 17 Oct 2009 09:34:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 72B993A697F for ; Sat, 17 Oct 2009 09:34:47 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 285DEC0002; Sat, 17 Oct 2009 18:34:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tI3RYUVgsL65; Sat, 17 Oct 2009 18:34:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB063C0006; Sat, 17 Oct 2009 18:34:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A420D4610A; Sat, 17 Oct 2009 18:34:50 +0200 (CEST) Date: Sat, 17 Oct 2009 18:34:50 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091017163450.GA3555@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETMOD Working Group References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> <001201ca4e7c$bc661b80$0601a8c0@allison> <1255781162.4652.11.camel@nomad> <4AD9E554.2070004@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD9E554.2070004@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] finish up 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: Sat, 17 Oct 2009 16:34:48 -0000 On Sat, Oct 17, 2009 at 05:40:04PM +0200, Andy Bierman wrote: > I also remember several times we were reassured > that a server-created leaf that did not contain the > YANG default value did exist. > > Then it changed to they exist in running, but not candidate. I think you can only reasonably create s-c leafs at commit time. Until commit, candidate is just a scratch pad. > The servers that implement 'explicit' basic behavior > for filtering defaults will never show the client these s-c leafs, > even in the running config. I think this summary is wrong. Once creation has taken place, the s-c leafs are part of the config. I think people wrote this here multiple times. > The solution of forcing data modelers to ignore s-c leafs in > constraint rules is not going to work, especially if these leafs > are supposed to turn into 'normal' leafs. > > The s-c leaf is unmanageable without with-defaults=report-all. > It is essentially an undocumented default -- a leaf invisible > from the client, except the client has no clue what value > the server is using. You are making up a story - and I am slowly getting tired of these false claims. > Setting s-c=true is supposed to be a license to keep these > leafs invisible from the client. That alone is reason > not to add to the system-creatable statement. You are making up a story and than drawing a pointless conclusion. Why are you doing 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 andy@netconfcentral.com Sat Oct 17 10:01:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8333A6974 for ; Sat, 17 Oct 2009 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, 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 dlQfs-kfQOC5 for ; Sat, 17 Oct 2009 10:01:06 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id B084B3A6855 for ; Sat, 17 Oct 2009 10:01:06 -0700 (PDT) Received: (qmail 52276 invoked from network); 17 Oct 2009 17:01:10 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 17 Oct 2009 17:01:09 -0000 X-YMail-OSG: 7C1CrQIVM1m_IK5jB3Xp1CoSCeEqyFwamvD0xAiuB04ddbxyrtfnPuTiNtNU0CZ81dUBr6XTNDn43DbDelUcYfAfjpq8qZf18JuQhhIHQ7195s5N14o7HhBwFpZUxL4BajQ8B.ueGXlrtzUaARStcc2KGIWAy9_X9rsjiSg2E1vDZcfzlu5nszdl0XHbTued00k4iemEaiMvJqmf_v_tIQzBCnMb4Zk.jLJPECRGq47bfMG0tHR6iviDjFht0VCeraoq6FC6khFmCLSF3q5saxk5ISAdbzm6Xw3YDCpQUqAJhp1Qlq5PlQIImIs4grNH5w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD9F878.7090900@netconfcentral.com> Date: Sat, 17 Oct 2009 10:01:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , NETMOD Working Group References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> <001201ca4e7c$bc661b80$0601a8c0@allison> <1255781162.4652.11.camel@nomad> <4AD9E554.2070004@netconfcentral.com> <20091017163450.GA3555@elstar.local> In-Reply-To: <20091017163450.GA3555@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:01:07 -0000 Juergen Schoenwaelder wrote: > On Sat, Oct 17, 2009 at 05:40:04PM +0200, Andy Bierman wrote: > >> I also remember several times we were reassured >> that a server-created leaf that did not contain the >> YANG default value did exist. >> >> Then it changed to they exist in running, but not candidate. > > I think you can only reasonably create s-c leafs at commit time. > Until commit, candidate is just a scratch pad. > >> The servers that implement 'explicit' basic behavior >> for filtering defaults will never show the client these s-c leafs, >> even in the running config. > > I think this summary is wrong. Once creation has taken place, the s-c > leafs are part of the config. I think people wrote this here multiple > times. > So they will always be returned in a plain by every server? If so, then good. If not, then how are they normal? They are invisible, but unlike the YANG default, there is no derived value for the client to extract from the meta-data. >> The solution of forcing data modelers to ignore s-c leafs in >> constraint rules is not going to work, especially if these leafs >> are supposed to turn into 'normal' leafs. >> >> The s-c leaf is unmanageable without with-defaults=report-all. >> It is essentially an undocumented default -- a leaf invisible >> from the client, except the client has no clue what value >> the server is using. > > You are making up a story - and I am slowly getting tired of these > false claims. > So how does the client retrieve these nodes if the optional with-defaults capability is not implemented? Are you saying these s-c leafs turn into explicit nodes in running, so they are always visible? >> Setting s-c=true is supposed to be a license to keep these >> leafs invisible from the client. That alone is reason >> not to add to the system-creatable statement. > > You are making up a story and than drawing a pointless conclusion. > Why are you doing this? > I am trying to understand how compliant servers that use explicit-mode work. It seems to me, these s-c nodes will never be seen by the client, even though they affect the config like defaults. > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Oct 17 13:32: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 365B53A6985 for ; Sat, 17 Oct 2009 13:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.728, 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 Yo75Nruz6PNz for ; Sat, 17 Oct 2009 13:32:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DF8D63A67FD for ; Sat, 17 Oct 2009 13:32:03 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F40F3C0010; Sat, 17 Oct 2009 22:32:08 +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 P3pQqoE77CoX; Sat, 17 Oct 2009 22:32:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1054C000E; Sat, 17 Oct 2009 22:32:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D8A3D462C6; Sat, 17 Oct 2009 22:32:07 +0200 (CEST) Date: Sat, 17 Oct 2009 22:32:07 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091017203207.GA3650@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETMOD Working Group References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> <001201ca4e7c$bc661b80$0601a8c0@allison> <1255781162.4652.11.camel@nomad> <4AD9E554.2070004@netconfcentral.com> <20091017163450.GA3555@elstar.local> <4AD9F878.7090900@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD9F878.7090900@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] finish up 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: Sat, 17 Oct 2009 20:32:05 -0000 On Sat, Oct 17, 2009 at 07:01:44PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Sat, Oct 17, 2009 at 05:40:04PM +0200, Andy Bierman wrote: > > > >> I also remember several times we were reassured > >> that a server-created leaf that did not contain the > >> YANG default value did exist. > >> > >> Then it changed to they exist in running, but not candidate. > > > > I think you can only reasonably create s-c leafs at commit time. > > Until commit, candidate is just a scratch pad. > > > >> The servers that implement 'explicit' basic behavior > >> for filtering defaults will never show the client these s-c leafs, > >> even in the running config. > > > > I think this summary is wrong. Once creation has taken place, the s-c > > leafs are part of the config. I think people wrote this here multiple > > times. > > > > So they will always be returned in a plain > by every server? If so, then good. If not, then > how are they normal? They are invisible, but unlike > the YANG default, there is no derived value for the > client to extract from the meta-data. My understanding is that once an s-c leaf exists, it is an ordinary leaf. > >> The solution of forcing data modelers to ignore s-c leafs in > >> constraint rules is not going to work, especially if these leafs > >> are supposed to turn into 'normal' leafs. > >> > >> The s-c leaf is unmanageable without with-defaults=report-all. > >> It is essentially an undocumented default -- a leaf invisible > >> from the client, except the client has no clue what value > >> the server is using. > > > > You are making up a story - and I am slowly getting tired of these > > false claims. > > > > So how does the client retrieve these nodes if > the optional with-defaults capability is not implemented? > Are you saying these s-c leafs turn into explicit > nodes in running, so they are always visible? That is my understanding. > >> Setting s-c=true is supposed to be a license to keep these > >> leafs invisible from the client. That alone is reason > >> not to add to the system-creatable statement. > > > > You are making up a story and than drawing a pointless conclusion. > > Why are you doing this? > > > > I am trying to understand how compliant servers > that use explicit-mode work. It seems to me, > these s-c nodes will never be seen by the client, even > though they affect the config like defaults. I am wondering which email message made you believe 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 andy@netconfcentral.com Sat Oct 17 15:06: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 B5C1E3A690D for ; Sat, 17 Oct 2009 15:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 NWyQPu9xkQ3w for ; Sat, 17 Oct 2009 15:06:14 -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 E7AE33A68E4 for ; Sat, 17 Oct 2009 15:06:14 -0700 (PDT) Received: (qmail 27952 invoked from network); 17 Oct 2009 22:06:18 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 17 Oct 2009 15:06:17 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: KPeu7W0VM1lqKNBSyxXQihWmUtZzKKs6btGf0z4YfMxzkRbkNwGLCOuzbvlFHeksGxzjCQOD6Gls6uk25mf.Mw4mIxmjHT6zZtVM6F.MTc44V5osJdupe3HRZTIvzMNAS_GW8yateX72P4zkMy8PkyUX6WUjZyXye1PouZdt_v1Zyn0gLg40m4GN28tQ._9oX4CbcIfCaQJh_Lrv5ewWDWmcaMPy9UYuZtZoV48djKQKiRaWAwmd0mg7r7DabLdz X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADA3FFE.9050900@netconfcentral.com> Date: Sat, 17 Oct 2009 15:06:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , NETMOD Working Group References: <20091014232652.GC16302@nsn.com> <200910151757.n9FHvoBi024868@idle.juniper.net> <20091015194435.GB125@elstar.local> <001201ca4e7c$bc661b80$0601a8c0@allison> <1255781162.4652.11.camel@nomad> <4AD9E554.2070004@netconfcentral.com> <20091017163450.GA3555@elstar.local> <4AD9F878.7090900@netconfcentral.com> <20091017203207.GA3650@elstar.local> In-Reply-To: <20091017203207.GA3650@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 22:06:15 -0000 Juergen Schoenwaelder wrote: > On Sat, Oct 17, 2009 at 07:01:44PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Sat, Oct 17, 2009 at 05:40:04PM +0200, Andy Bierman wrote: >>> >>>> I also remember several times we were reassured >>>> that a server-created leaf that did not contain the >>>> YANG default value did exist. >>>> >>>> Then it changed to they exist in running, but not candidate. >>> I think you can only reasonably create s-c leafs at commit time. >>> Until commit, candidate is just a scratch pad. >>> >>>> The servers that implement 'explicit' basic behavior >>>> for filtering defaults will never show the client these s-c leafs, >>>> even in the running config. >>> I think this summary is wrong. Once creation has taken place, the s-c >>> leafs are part of the config. I think people wrote this here multiple >>> times. >>> >> So they will always be returned in a plain >> by every server? If so, then good. If not, then >> how are they normal? They are invisible, but unlike >> the YANG default, there is no derived value for the >> client to extract from the meta-data. > > My understanding is that once an s-c leaf exists, it is an ordinary > leaf. So they are visible on all types of servers all the time, and not filtered: report-all: would be returned explicit: would be returned trim: N/A, since an s-c leaf cannot have a YANG default, or it is ignored, if the typedef has a default > >>>> The solution of forcing data modelers to ignore s-c leafs in >>>> constraint rules is not going to work, especially if these leafs >>>> are supposed to turn into 'normal' leafs. >>>> >>>> The s-c leaf is unmanageable without with-defaults=report-all. >>>> It is essentially an undocumented default -- a leaf invisible >>>> from the client, except the client has no clue what value >>>> the server is using. >>> You are making up a story - and I am slowly getting tired of these >>> false claims. >>> >> So how does the client retrieve these nodes if >> the optional with-defaults capability is not implemented? >> Are you saying these s-c leafs turn into explicit >> nodes in running, so they are always visible? > > That is my understanding. The draft needs to say this somewhere. Once an s-c leaf is created, such as uid, it does need to be saved, otherwise the server may not derive the same value again. > >>>> Setting s-c=true is supposed to be a license to keep these >>>> leafs invisible from the client. That alone is reason >>>> not to add to the system-creatable statement. >>> You are making up a story and than drawing a pointless conclusion. >>> Why are you doing this? >>> >> I am trying to understand how compliant servers >> that use explicit-mode work. It seems to me, >> these s-c nodes will never be seen by the client, even >> though they affect the config like defaults. > > I am wondering which email message made you believe this. > The definition of explicit in the with-defaults draft is self-referencing, and useless. I brought this issue up with the WG and Balazs a long time ago. What is an 'explicit' default? Every month or so, we find out new details on how it is supposed to work. I would have though a server-created leaf would not count as an explicitly created leaf, because I keep hearing from you and Phil that explicit means only the leafs the client provides. Now it means all the client leafs, plus the s-c leafs. That's fine. Just trying to keep up with the concepts and terms that keep changing. Don't assume everybody has the same understanding of the poorly documented concepts as you do. > /js > Andy From phil@juniper.net Sat Oct 17 20:07: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 785003A68AB for ; Sat, 17 Oct 2009 20:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 od-A7AG5Z+LV for ; Sat, 17 Oct 2009 20:07:31 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 978783A6358 for ; Sat, 17 Oct 2009 20:07:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKStqGdsdH5tWlwNt8O2S4ceYbMoly1xki@postini.com; Sat, 17 Oct 2009 20:07:37 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 17 Oct 2009 20:06:00 -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); Sat, 17 Oct 2009 20:06:00 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 20:05:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 20:05:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9I35xj74750; Sat, 17 Oct 2009 20:05:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9I2r6XG061181; Sun, 18 Oct 2009 02:53:07 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910180253.n9I2r6XG061181@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ADA3FFE.9050900@netconfcentral.com> Date: Sat, 17 Oct 2009 22:53:06 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Oct 2009 03:05:59.0855 (UTC) FILETIME=[EB3D7BF0:01CA4F9F] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Oct 2009 03:07:32 -0000 Andy Bierman writes: >I would have though a server-created leaf would not >count as an explicitly created leaf, because I keep >hearing from you and Phil that explicit means only >the leafs the client provides. Now it means all >the client leafs, plus the s-c leafs. My objection has been constant, that default values are not magically part of the configuration database, and that only data in the configuration database should be reported in output. s-c leafs are real leafs, so they are really created in the configuration database. Once they are created, they are normal leafs. They should be reported in the , be changable by , and in all ways be normal. "s-c" means on that the system can create them if they don't exist. Remember that "client provides" is meaningless, since the client is not the only source of configuration. If a CLI user says "set foo 42", then foo is part of the configuration database. Thanks, Phil From andy@netconfcentral.com Sun Oct 18 09:51: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 834E23A6968 for ; Sun, 18 Oct 2009 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 aMzsuxM-2SCo for ; Sun, 18 Oct 2009 09:51:04 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id D00943A695D for ; Sun, 18 Oct 2009 09:51:04 -0700 (PDT) Received: (qmail 59600 invoked from network); 18 Oct 2009 16:51:08 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 18 Oct 2009 09:51:08 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: CIyXcmQVM1mx6m8OeefuUiBwhygL6SEvMLDLY5EQ6yan9hBo.VbDVK.pJhw6K5hamMg1OPQDg9.QX5htJPPN.tvyCK5eVBaXMKymIEyoC0wSgZ39gTziBLciAQr9T8VsSFIHlYnG7o9nvTL2Sy77Tbf2Ua75Qlzg.1yTeSohuO26O.ICIGdxwxZ2JTUKbS3BYKJ6wN5T.pDVjbbsd2l2y53CicHjHRBsFKkrHcyRdwkqPU9TzmjSRGtKg_9cCKB7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADB4728.3080704@netconfcentral.com> Date: Sun, 18 Oct 2009 09:49:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910180253.n9I2r6XG061181@idle.juniper.net> In-Reply-To: <200910180253.n9I2r6XG061181@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Oct 2009 16:51:05 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I would have though a server-created leaf would not >> count as an explicitly created leaf, because I keep >> hearing from you and Phil that explicit means only >> the leafs the client provides. Now it means all >> the client leafs, plus the s-c leafs. > > My objection has been constant, that default values are not magically > part of the configuration database, and that only data in the > configuration database should be reported in output. > > s-c leafs are real leafs, so they are really created in the > configuration database. Once they are created, they are normal > leafs. They should be reported in the , be changable > by , and in all ways be normal. "s-c" means on that > the system can create them if they don't exist. > > Remember that "client provides" is meaningless, since the client > is not the only source of configuration. If a CLI user says "set > foo 42", then foo is part of the configuration database. > This is why I got confused, and perhaps Lada as well. The term 'explicitly set' suggests that it was set through the management protocol, by some entity other than the managed entity (the server). But any leaf set by any possible mechanism, is explicitly set. A YANG default is presumably implicitly set because the server already knows the value. So any internal server application, regardless of whether it uses NETCONF to transfer the commands, will create only explicit nodes? So even if an internal server app changes a value back to its YANG default, that node is still explicit, and always returned by a server that returns with-defaults=explicit? The YANG spec has to contain all the normative details for all YANG behavior, not the Informational Arch spec. Not sure what to write, but some text should be added to clarify explicitly set leafs. > Thanks, > Phil > Andy From andy@netconfcentral.com Sun Oct 18 13:30: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 29B4F3A69AE for ; Sun, 18 Oct 2009 13:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_20=-0.74, UNPARSEABLE_RELAY=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 bmlJEufzzKL9 for ; Sun, 18 Oct 2009 13:30:40 -0700 (PDT) Received: from n11b.bullet.mail.mud.yahoo.com (n11b.bullet.mail.mud.yahoo.com [209.191.125.178]) by core3.amsl.com (Postfix) with SMTP id 800D23A69BE for ; Sun, 18 Oct 2009 13:30:40 -0700 (PDT) Received: from [68.142.200.224] by n11.bullet.mail.mud.yahoo.com with NNFMP; 18 Oct 2009 20:30:45 -0000 Received: from [68.142.201.242] by t5.bullet.mud.yahoo.com with NNFMP; 18 Oct 2009 20:30:45 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 18 Oct 2009 20:30:45 -0000 X-Yahoo-Newman-Id: 215801.89459.bm@omp403.mail.mud.yahoo.com Received: (qmail 4976 invoked from network); 18 Oct 2009 20:30:44 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 18 Oct 2009 13:30:44 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 2aMFQg0VM1l4zy3Zw8AfgLdjmfMORE7_JmVZJv_9V00c627vNcabizjHuw4mYjpcl.W77_9lG_qkoUR8K6w.YOYtUKRDAeAvmQt8NxC8v7fO8TWZHhEIWYBHfBDc0_SVPPTRV.jYLBP_LukYP6bmeQUjDWnfRVB9KGBpR7oTgRQLDPJ7z.r6R9.ORxQgo7rXspfJnL2JlmSAZMN9LttCxu6OevIq.ijJTF53I98Fz.CFXsFM8QkEJZFwpBuna3pV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADB7B1D.7010505@netconfcentral.com> Date: Sun, 18 Oct 2009 13:31:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-07, sec 3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Oct 2009 20:30:42 -0000 Hi, This section needs to define more terms, hopefully in their own sub-sections. A lot of time has been wasted (over and over) because important details were under-specified, and not universally mis-understood. default values static dynamic explicitly-set nodes system-created nodes system-altered nodes system-deleted nodes valid database running database what is visible? is the load-startup stop-on-error or continue-on-error? where are the startup errors, if continue-on-error? are there multiple startup files to load from? candidate database what is visible, and when? startup database what is saved to NV-storage? state data what are the different types of state data? Every one of these terms seems to have different interpretations. They should be standardized, if possible. ------------------ o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state [RFC4741]. Is this the complete and correct definition of configuration data? To me, all it says wrt/ YANG is config-stmt property = true (or inherited from parent). Is that enough? Neither YANG or NETCONF tries to define the specific server behavior when a complete config is used to merge or replace another one (copy-config, commit). Perhaps the server converts every node to canonical format and ordering for every comparison, and skips nodes which have not changed. Perhaps not. Perhaps some random combination of methods. (Future work, not YANG 1.0). Andy From Washam.Fan@huaweisymantec.com Sun Oct 18 18:42:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027313A6908 for ; Sun, 18 Oct 2009 18:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xycGJNjaYmHa for ; Sun, 18 Oct 2009 18:42:05 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id C73443A62C1 for ; Sun, 18 Oct 2009 18:42:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KRQ00AZ5NDOVG90@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Mon, 19 Oct 2009 09:41:49 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KRQ00GYVNDO6900@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Mon, 19 Oct 2009 09:41:48 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 19 Oct 2009 09:41:48 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 19 Oct 2009 09:41:48 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4ADB4728.3080704@netconfcentral.com> References: <200910180253.n9I2r6XG061181@idle.juniper.net> <4ADB4728.3080704@netconfcentral.com> Cc: NETMOD Working Group Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 01:42:06 -0000 My interpretation, nodes set by the client via Netconf including those with default values or set by the server via internal mechanisms excluding those with default values are considered as "explicitly set" nodes. washam ----- Original Message ----- From: Andy Bierman Date: Monday, October 19, 2009 0:52 am Subject: Re: [netmod] finish up To: Phil Shafer Cc: NETMOD Working Group > Phil Shafer wrote: > > Andy Bierman writes: > >> I would have though a server-created leaf would not > >> count as an explicitly created leaf, because I keep > >> hearing from you and Phil that explicit means only > >> the leafs the client provides. Now it means all > >> the client leafs, plus the s-c leafs. > > > > My objection has been constant, that default values are not magically > > part of the configuration database, and that only data in the > > configuration database should be reported in output. > > > > s-c leafs are real leafs, so they are really created in the > > configuration database. Once they are created, they are normal > > leafs. They should be reported in the , be changable > > by , and in all ways be normal. "s-c" means on that > > the system can create them if they don't exist. > > > > Remember that "client provides" is meaningless, since the client > > is not the only source of configuration. If a CLI user says "set > > foo 42", then foo is part of the configuration database. > > > > This is why I got confused, > and perhaps Lada as well. > > The term 'explicitly set' suggests that > it was set through the management protocol, > by some entity other than the managed entity (the server). > > But any leaf set by any possible mechanism, > is explicitly set. A YANG default is presumably > implicitly set because the server already knows the value. > > So any internal server application, regardless of whether > it uses NETCONF to transfer the commands, will create > only explicit nodes? So even if an internal > server app changes a value back to its YANG default, > that node is still explicit, and always returned > by a server that returns with-defaults=explicit? > > The YANG spec has to contain all the normative > details for all YANG behavior, not the Informational > Arch spec. Not sure what to write, but some text > should be added to clarify explicitly set leafs. > > > > > Thanks, > > Phil > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Mon Oct 19 00:53:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A933A6860 for ; Mon, 19 Oct 2009 00:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.237, 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 hDirUpVe7SQA for ; Mon, 19 Oct 2009 00:53: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 313543A677C for ; Mon, 19 Oct 2009 00:53:30 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5ABDC76C4F3; Mon, 19 Oct 2009 09:53:35 +0200 (CEST) Date: Mon, 19 Oct 2009 09:53:34 +0200 (CEST) Message-Id: <20091019.095334.197736777.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ADB4728.3080704@netconfcentral.com> References: <200910180253.n9I2r6XG061181@idle.juniper.net> <4ADB4728.3080704@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] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 07:53:31 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Remember that "client provides" is meaningless, since the client > > is not the only source of configuration. If a CLI user says "set > > foo 42", then foo is part of the configuration database. > > > > This is why I got confused, > and perhaps Lada as well. > > The term 'explicitly set' suggests that > it was set through the management protocol, > by some entity other than the managed entity (the server). > > But any leaf set by any possible mechanism, > is explicitly set. A YANG default is presumably > implicitly set because the server already knows the value. We don't use this term for s-c leafs. Maybe we should rephrase the text on defaults so that we don't use this term? I.e. just say that the default value is used if the leaf doesn't exist. This might be better since the term "explicitly set" sort of indicates that some leafs might be "implicitily set", and since we never talk about that I can see that it lead to confusion. /martin From mbj@tail-f.com Mon Oct 19 00:56: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 B2B113A68A5 for ; Mon, 19 Oct 2009 00:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.211, 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 SeIG793k7Se8 for ; Mon, 19 Oct 2009 00:56: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 E5E963A6820 for ; Mon, 19 Oct 2009 00:56:19 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5AA9276C4F3; Mon, 19 Oct 2009 09:56:26 +0200 (CEST) Date: Mon, 19 Oct 2009 09:56:25 +0200 (CEST) Message-Id: <20091019.095625.72310290.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091017203207.GA3650@elstar.local> References: <20091017163450.GA3555@elstar.local> <4AD9F878.7090900@netconfcentral.com> <20091017203207.GA3650@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] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 07:56:20 -0000 Juergen Schoenwaelder wrote: > On Sat, Oct 17, 2009 at 07:01:44PM +0200, Andy Bierman wrote: > > Juergen Schoenwaelder wrote: > > > On Sat, Oct 17, 2009 at 05:40:04PM +0200, Andy Bierman wrote: > > >> The servers that implement 'explicit' basic behavior > > >> for filtering defaults will never show the client these s-c leafs, > > >> even in the running config. > > > > > > I think this summary is wrong. Once creation has taken place, the s-c > > > leafs are part of the config. I think people wrote this here multiple > > > times. > > > > > > > So they will always be returned in a plain > > by every server? If so, then good. If not, then > > how are they normal? They are invisible, but unlike > > the YANG default, there is no derived value for the > > client to extract from the meta-data. > > My understanding is that once an s-c leaf exists, it is an ordinary > leaf. Yes. > > So how does the client retrieve these nodes if > > the optional with-defaults capability is not implemented? > > Are you saying these s-c leafs turn into explicit > > nodes in running, so they are always visible? > > That is my understanding. Yes. > > I am trying to understand how compliant servers > > that use explicit-mode work. It seems to me, > > these s-c nodes will never be seen by the client, even > > though they affect the config like defaults. > > I am wondering which email message made you believe this. So am I. Can we clarify the text somehow so that people do not draw this conclusion? So Andy, with these clarifications, do you think we should add the s-c statement or not? /martin From andy@netconfcentral.com Mon Oct 19 02:17: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 15BFA28C0F1 for ; Mon, 19 Oct 2009 02:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 9LRW3gtAn6iL for ; Mon, 19 Oct 2009 02:17:48 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 520A73A6916 for ; Mon, 19 Oct 2009 02:17:48 -0700 (PDT) Received: (qmail 43382 invoked from network); 19 Oct 2009 09:17:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Oct 2009 09:17:53 -0000 X-YMail-OSG: 9HLqh4YVM1lFUcNahiQN05239wagz7qZlKg8CXjosYzwC1AOjtBqJbIyLk4GMC8TEeZuIQJj28ETDGIsC3dr1vT4Nanl_EY.rZiv9ysJ6PbWarWZ3_jMs8cBdPyeozDr2wWP5pV2PVvQTbKW9hwSWnT5SSdscyYhGM4kE1tqfkKdQ8vwuvWQQlX7RDcLrzwf8YDn2LUo2vtp1OpqkjYI3BCVMj5OI5qF7YqfeQCUNBzgmmJSrRjb7OkXF86sGyFYgGR2HGytvkU9RdHgVLgLJ__gJJhGrKzJmKC61wd4mBylrb9dOKSLy2w8YWNXkH6uBWwud8NxBDnfZPOeWtHi1DAKN8ASdaqGLBiVLD909kAKK6RfMt1UPNHRAoOtu8yv8eKcOS8D81g6Ids- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADC2E70.80200@netconfcentral.com> Date: Mon, 19 Oct 2009 02:16:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20091017163450.GA3555@elstar.local> <4AD9F878.7090900@netconfcentral.com> <20091017203207.GA3650@elstar.local> <20091019.095625.72310290.mbj@tail-f.com> In-Reply-To: <20091019.095625.72310290.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 09:17:49 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Sat, Oct 17, 2009 at 07:01:44PM +0200, Andy Bierman wrote: >>> Juergen Schoenwaelder wrote: >>>> On Sat, Oct 17, 2009 at 05:40:04PM +0200, Andy Bierman wrote: >>>>> The servers that implement 'explicit' basic behavior >>>>> for filtering defaults will never show the client these s-c leafs, >>>>> even in the running config. >>>> I think this summary is wrong. Once creation has taken place, the s-c >>>> leafs are part of the config. I think people wrote this here multiple >>>> times. >>>> >>> So they will always be returned in a plain >>> by every server? If so, then good. If not, then >>> how are they normal? They are invisible, but unlike >>> the YANG default, there is no derived value for the >>> client to extract from the meta-data. >> My understanding is that once an s-c leaf exists, it is an ordinary >> leaf. > > Yes. > >>> So how does the client retrieve these nodes if >>> the optional with-defaults capability is not implemented? >>> Are you saying these s-c leafs turn into explicit >>> nodes in running, so they are always visible? >> That is my understanding. > > Yes. > >>> I am trying to understand how compliant servers >>> that use explicit-mode work. It seems to me, >>> these s-c nodes will never be seen by the client, even >>> though they affect the config like defaults. >> I am wondering which email message made you believe this. > > So am I. Can we clarify the text somehow so that people do not draw > this conclusion? > > > So Andy, with these clarifications, do you think we should add the s-c > statement or not? > It certainly makes more sense, now that the terminology is cleared up. I am still unclear on 2 points: - validation: nothing special right? s-c leafs can have constraints, but they are applied to running initially, not to candidate - mandatory: should be allowed; Lada's addition of mandatory=true to the user ID example makes sense; meaning is unchanged; > > /martin > Andy From mbj@tail-f.com Mon Oct 19 02:25: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 9551F28C0E0 for ; Mon, 19 Oct 2009 02:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-sF7kc1fz+3 for ; Mon, 19 Oct 2009 02:25: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 990C228C134 for ; Mon, 19 Oct 2009 02:25:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A59B76C4F3; Mon, 19 Oct 2009 11:26:02 +0200 (CEST) Date: Mon, 19 Oct 2009 11:26:01 +0200 (CEST) Message-Id: <20091019.112601.101033217.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ADC2E70.80200@netconfcentral.com> References: <20091017203207.GA3650@elstar.local> <20091019.095625.72310290.mbj@tail-f.com> <4ADC2E70.80200@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] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 09:25:57 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > So Andy, with these clarifications, do you think we should add the s-c > > statement or not? > > > > It certainly makes more sense, now that the terminology is cleared up. Good! > I am still unclear on 2 points: > - validation: nothing special right? > s-c leafs can have constraints, but they are applied > to running initially, not to candidate > - mandatory: should be allowed; > Lada's addition of mandatory=true to the > user ID example makes sense; meaning is unchanged; This will depend on what we say in the document about *when* such leafs are created. In the first proposal, we said that the server creates those leafs at commit time (or edit-config towards running). You suggested that we should be more lax and let this be an implementation detail. If we pick one of those proposals, you cannot have 'mandatory' on a s-c leaf, since the leaf will not exist until after validation (at least on some implemtations). As for other constraints (must / unique) it depends on how the constraint is written - if it requires the leaf to exist, it won't work, but you can e.g. do 'unique uid;' in the example. The server MUST make sure it picks a value that doesn't break any constraints. /martin From j.schoenwaelder@jacobs-university.de Mon Oct 19 02:44: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 743BA28C122 for ; Mon, 19 Oct 2009 02:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 69o3VLQhMnc9 for ; Mon, 19 Oct 2009 02:44:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 56B1B3A68B1 for ; Mon, 19 Oct 2009 02:44:27 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEC06C0014; Mon, 19 Oct 2009 11:44:33 +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 Ovxbx9hO4-q9; Mon, 19 Oct 2009 11:44:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB611C0002; Mon, 19 Oct 2009 11:44:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 948D1D47A18; Mon, 19 Oct 2009 11:44:31 +0200 (CEST) Date: Mon, 19 Oct 2009 11:44:31 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091019094431.GA4708@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <20091017203207.GA3650@elstar.local> <20091019.095625.72310290.mbj@tail-f.com> <4ADC2E70.80200@netconfcentral.com> <20091019.112601.101033217.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20091019.112601.101033217.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] finish up 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, 19 Oct 2009 09:44:28 -0000 On Mon, Oct 19, 2009 at 11:26:01AM +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > So Andy, with these clarifications, do you think we should add the s-c > > > statement or not? > > > > > > > It certainly makes more sense, now that the terminology is cleared up. > > Good! > > > I am still unclear on 2 points: > > - validation: nothing special right? > > s-c leafs can have constraints, but they are applied > > to running initially, not to candidate > > - mandatory: should be allowed; > > Lada's addition of mandatory=true to the > > user ID example makes sense; meaning is unchanged; > > This will depend on what we say in the document about *when* such > leafs are created. In the first proposal, we said that the server > creates those leafs at commit time (or edit-config towards running). > You suggested that we should be more lax and let this be an > implementation detail. > > If we pick one of those proposals, you cannot have 'mandatory' on a > s-c leaf, since the leaf will not exist until after validation (at > least on some implemtations). Does NETCONF somewhere spell out how validation is done if it happens during commit? If not, we can leave this implementation dependent as long as the result is validÂ. The real issue then is the explicit validate operation, which is not bound to a commit, or am I missing something? Here we would have to pick a solution; I am not sure yet which one I prefer. Restricting constraints for s-c leafs achieves the goal but seems a heavy-weight choice just to make :validate work. /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 Mon Oct 19 03:34:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BE33A691F for ; Mon, 19 Oct 2009 03:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.173, 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 CrA2dAUo0LT0 for ; Mon, 19 Oct 2009 03:34:09 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0BE1E3A67A3 for ; Mon, 19 Oct 2009 03:34:08 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0021376C4F3; Mon, 19 Oct 2009 12:28:10 +0200 (CEST) Date: Mon, 19 Oct 2009 12:28:10 +0200 (CEST) Message-Id: <20091019.122810.24814928.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091019094431.GA4708@elstar.local> References: <4ADC2E70.80200@netconfcentral.com> <20091019.112601.101033217.mbj@tail-f.com> <20091019094431.GA4708@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 10:34:10 -0000 Juergen Schoenwaelder wrote: > On Mon, Oct 19, 2009 at 11:26:01AM +0200, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > Martin Bjorklund wrote: > > > > So Andy, with these clarifications, do you think we should add = the s-c > > > > statement or not? > > > > = > > > = > > > It certainly makes more sense, now that the terminology is cleare= d up. > > = > > Good! > > = > > > I am still unclear on 2 points: > > > - validation: nothing special right? > > > s-c leafs can have constraints, but they are applied > > > to running initially, not to candidate > > > - mandatory: should be allowed; > > > Lada's addition of mandatory=3Dtrue to the > > > user ID example makes sense; meaning is unchanged; > > = > > This will depend on what we say in the document about *when* such > > leafs are created. In the first proposal, we said that the server > > creates those leafs at commit time (or edit-config towards running)= .= > > You suggested that we should be more lax and let this be an > > implementation detail. > > = > > If we pick one of those proposals, you cannot have 'mandatory' on a= > > s-c leaf, since the leaf will not exist until after validation (at > > least on some implemtations). > = > Does NETCONF somewhere spell out how validation is done if it happens= > during commit? If not, we can leave this implementation dependent as > long as the result is valid=C2. No. But YANG says: If the datastore is or , these constraints MUST be enforced at the end of the or operation. If the datastore is , the constraint enforcement is delayed until a or operation. > The real issue then is the explicit validate operation, which is not > bound to a commit, or am I missing something? It is also for clients that want to do off-line validation. If they rely on the server to create s-c leafs, their validation will fail if a constraint requires the s-c leaf to exist. > Here we would have to > pick a solution; I am not sure yet which one I prefer. Restricting > constraints for s-c leafs achieves the goal but seems a heavy-weight > choice just to make :validate work. Do you have an alternative suggestion? /martin From mbj@tail-f.com Mon Oct 19 03:38:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FDD3A67E6 for ; Mon, 19 Oct 2009 03:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.158, 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 JVh8wPbJm77i for ; Mon, 19 Oct 2009 03:38:23 -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 770083A67A3 for ; Mon, 19 Oct 2009 03:38:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0E11476C4F3; Mon, 19 Oct 2009 12:38:30 +0200 (CEST) Date: Mon, 19 Oct 2009 12:38:29 +0200 (CEST) Message-Id: <20091019.123829.90055554.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255775198.7825.8.camel@missotis> References: <1255775198.7825.8.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] proposed change to 7.3.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 10:38:24 -0000 Ladislav Lhotka wrote: > Hi, > > the last paragraph in Sec. 7.3.4 should also cover the case when a > restriction specified in a leaf definition is incompatible with the > default value of the leaf's type. But 7.3.4 is called "The typedef's default Statement". We should not talk about leafs here. In 7.6.3 we say: The value of the "default" statement MUST be valid according to the type specified in the leaf's "type" statement. Maybe I miss your point? /martin > OLD > > If the base type has a default value, and the new derived type does > not specify a new default value, the base type's default value is > also the default value of the new derived type. If the base type's > default value is not valid according to the new restrictions, the > derived type MUST define a new default value. > > NEW > > If the base type has a default value, and the new derived type does > not specify a new default value, the base type's default value is > also the default value of the new derived type. > > If the base type's default value is not valid according to the new > restrictions specified in a derived type or leaf definition, > the derived type or leaf definition MUST specify a new default value > compatible with the restrictions. > > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Mon Oct 19 03:40: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 2E5F93A6935 for ; Mon, 19 Oct 2009 03:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=0.486, 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 aJaaZGxE07RC for ; Mon, 19 Oct 2009 03:40:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 48B443A67A3 for ; Mon, 19 Oct 2009 03:40:29 -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 3BE16D800CC; Mon, 19 Oct 2009 12:40:35 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4ADC2E70.80200@netconfcentral.com> References: <20091017163450.GA3555@elstar.local> <4AD9F878.7090900@netconfcentral.com> <20091017203207.GA3650@elstar.local> <20091019.095625.72310290.mbj@tail-f.com> <4ADC2E70.80200@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 12:40:33 +0200 Message-Id: <1255948833.22426.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 10:40:30 -0000 Andy Bierman píše v Po 19. 10. 2009 v 02:16 -0700: > > I am still unclear on 2 points: > - validation: nothing special right? > s-c leafs can have constraints, but they are applied > to running initially, not to candidate > - mandatory: should be allowed; > Lada's addition of mandatory=true to the > user ID example makes sense; meaning is unchanged; But candidate would then be invalid if mandatory s-c leafs are missing. So far we assumed that validity of candidate may be relaxed in the area of referential integrity only. Lada > > > > > /martin > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Oct 19 03:46: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 6F2C928C12F for ; Mon, 19 Oct 2009 03:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=0.451, 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 qod87PwDXx1q for ; Mon, 19 Oct 2009 03:46:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9DB6D3A67A3 for ; Mon, 19 Oct 2009 03:46: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 58596D800CE; Mon, 19 Oct 2009 12:46:59 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091019.123829.90055554.mbj@tail-f.com> References: <1255775198.7825.8.camel@missotis> <20091019.123829.90055554.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 12:46:57 +0200 Message-Id: <1255949217.22426.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] proposed change to 7.3.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 10:46:53 -0000 Martin Bjorklund píše v Po 19. 10. 2009 v 12:38 +0200: > Ladislav Lhotka wrote: > > Hi, > > > > the last paragraph in Sec. 7.3.4 should also cover the case when a > > restriction specified in a leaf definition is incompatible with the > > default value of the leaf's type. > > But 7.3.4 is called "The typedef's default Statement". We should not > talk about leafs here. In 7.6.3 we say: > > The value of the "default" statement MUST be valid according to the > type specified in the leaf's "type" statement. > > > Maybe I miss your point? leaf foo { type bar { range "1..10"; } } typedef bar { type uint8; default 42; } The default here is typedef's. Lada > > > /martin > > > > OLD > > > > If the base type has a default value, and the new derived type does > > not specify a new default value, the base type's default value is > > also the default value of the new derived type. If the base type's > > default value is not valid according to the new restrictions, the > > derived type MUST define a new default value. > > > > NEW > > > > If the base type has a default value, and the new derived type does > > not specify a new default value, the base type's default value is > > also the default value of the new derived type. > > > > If the base type's default value is not valid according to the new > > restrictions specified in a derived type or leaf definition, > > the derived type or leaf definition MUST specify a new default value > > compatible with the restrictions. > > > > Lada > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Oct 19 03:57: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 498773A681B for ; Mon, 19 Oct 2009 03:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.146, 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 a0vN904UcTYp for ; Mon, 19 Oct 2009 03:57: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 70ABB3A67AC for ; Mon, 19 Oct 2009 03:57:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0639376C4F3; Mon, 19 Oct 2009 12:57:34 +0200 (CEST) Date: Mon, 19 Oct 2009 12:57:33 +0200 (CEST) Message-Id: <20091019.125733.176341457.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255949217.22426.18.camel@missotis> References: <1255775198.7825.8.camel@missotis> <20091019.123829.90055554.mbj@tail-f.com> <1255949217.22426.18.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] proposed change to 7.3.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 10:57:28 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAxOS4gMTAuIDIwMDkgdiAxMjozOCArMDIwMDoNCj4gPiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPiANCj4g PiA+IHRoZSBsYXN0IHBhcmFncmFwaCBpbiBTZWMuIDcuMy40IHNob3VsZCBhbHNvIGNvdmVyIHRo ZSBjYXNlIHdoZW4gYQ0KPiA+ID4gcmVzdHJpY3Rpb24gc3BlY2lmaWVkIGluIGEgbGVhZiBkZWZp bml0aW9uIGlzIGluY29tcGF0aWJsZSB3aXRoIHRoZQ0KPiA+ID4gZGVmYXVsdCB2YWx1ZSBvZiB0 aGUgbGVhZidzIHR5cGUuDQo+ID4gDQo+ID4gQnV0IDcuMy40IGlzIGNhbGxlZCAiVGhlIHR5cGVk ZWYncyBkZWZhdWx0IFN0YXRlbWVudCIuICBXZSBzaG91bGQgbm90DQo+ID4gdGFsayBhYm91dCBs ZWFmcyBoZXJlLiAgSW4gNy42LjMgd2Ugc2F5Og0KPiA+IA0KPiA+ICAgVGhlIHZhbHVlIG9mIHRo ZSAiZGVmYXVsdCIgc3RhdGVtZW50IE1VU1QgYmUgdmFsaWQgYWNjb3JkaW5nIHRvIHRoZQ0KPiA+ ICAgdHlwZSBzcGVjaWZpZWQgaW4gdGhlIGxlYWYncyAidHlwZSIgc3RhdGVtZW50Lg0KPiA+IA0K PiA+IA0KPiA+IE1heWJlIEkgbWlzcyB5b3VyIHBvaW50Pw0KPiANCj4gbGVhZiBmb28gew0KPiAg ICAgdHlwZSBiYXIgew0KPiAgICAgICAgIHJhbmdlICIxLi4xMCI7DQo+ICAgICB9DQo+IH0NCj4g DQo+IHR5cGVkZWYgYmFyIHsNCj4gICAgIHR5cGUgdWludDg7DQo+ICAgICBkZWZhdWx0IDQyOw0K PiB9DQo+IA0KPiBUaGUgZGVmYXVsdCBoZXJlIGlzIHR5cGVkZWYncy4NCg0KT2suICBHb3QgaXQu ICAgSSBzdWdnZXN0IHdlIHdyaXRlOg0KDQpORVcNCg0KICAgSWYgdGhlIGJhc2UgdHlwZSBoYXMg YSBkZWZhdWx0IHZhbHVlLCBhbmQgdGhlIG5ldyBkZXJpdmVkIHR5cGUgZG9lcyANCiAgIG5vdCBz cGVjaWZ5IGEgbmV3IGRlZmF1bHQgdmFsdWUsIHRoZSBiYXNlIHR5cGUncyBkZWZhdWx0IHZhbHVl IGlzDQogICBhbHNvIHRoZSBkZWZhdWx0IHZhbHVlIG9mIHRoZSBuZXcgZGVyaXZlZCB0eXBlLg0K DQogICBJZiB0aGUgdHlwZSdzIGRlZmF1bHQgdmFsdWUgaXMgbm90IHZhbGlkIGFjY29yZGluZyB0 byB0aGUgbmV3DQogICByZXN0cmljdGlvbnMgc3BlY2lmaWVkIGluIGEgZGVyaXZlZCB0eXBlIG9y IGxlYWYgZGVmaW5pdGlvbiwNCiAgIHRoZSBkZXJpdmVkIHR5cGUgb3IgbGVhZiBkZWZpbml0aW9u IE1VU1Qgc3BlY2lmeSBhIG5ldyBkZWZhdWx0IHZhbHVlDQogICBjb21wYXRpYmxlIHdpdGggdGhl IHJlc3RyaWN0aW9ucy4NCg0KaW5zdGVhZC4NCg0KSSB3YXMgY29uZnVzZWQgYnkgdGhlIGZhY3Qg dGhhdCB0aGUgdHdvIHBhcmFncmFwaHMgc3RhcnRlZCB3aXRoICJJZg0KdGhlIGJhc2UgdHlwZSIs IGJ1dCB0aGV5IHRhbGtlZCBhYm91dCBkaWZmZXJlbnQgdGhpbmdzLi4uDQoNCg0KL21hcnRpbg0K From lhotka@cesnet.cz Mon Oct 19 04:02: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 B506028C160 for ; Mon, 19 Oct 2009 04:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=0.421, 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 YWv4CcTxx-jK for ; Mon, 19 Oct 2009 04:02:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D951A3A67AC for ; Mon, 19 Oct 2009 04:01:54 -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 B550BD800C1; Mon, 19 Oct 2009 13:02:01 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091019.125733.176341457.mbj@tail-f.com> References: <1255775198.7825.8.camel@missotis> <20091019.123829.90055554.mbj@tail-f.com> <1255949217.22426.18.camel@missotis> <20091019.125733.176341457.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 13:01:59 +0200 Message-Id: <1255950119.22426.19.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] proposed change to 7.3.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 11:02:03 -0000 Martin Bjorklund píše v Po 19. 10. 2009 v 12:57 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Po 19. 10. 2009 v 12:38 +0200: > > > Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > the last paragraph in Sec. 7.3.4 should also cover the case when a > > > > restriction specified in a leaf definition is incompatible with the > > > > default value of the leaf's type. > > > > > > But 7.3.4 is called "The typedef's default Statement". We should not > > > talk about leafs here. In 7.6.3 we say: > > > > > > The value of the "default" statement MUST be valid according to the > > > type specified in the leaf's "type" statement. > > > > > > > > > Maybe I miss your point? > > > > leaf foo { > > type bar { > > range "1..10"; > > } > > } > > > > typedef bar { > > type uint8; > > default 42; > > } > > > > The default here is typedef's. > > Ok. Got it. I suggest we write: > > NEW > > If the base type has a default value, and the new derived type does > not specify a new default value, the base type's default value is > also the default value of the new derived type. > > If the type's default value is not valid according to the new > restrictions specified in a derived type or leaf definition, > the derived type or leaf definition MUST specify a new default value > compatible with the restrictions. > > instead. OK. Lada > > I was confused by the fact that the two paragraphs started with "If > the base type", but they talked about different things... > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Oct 19 04:11: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 E39073A6840 for ; Mon, 19 Oct 2009 04:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=0.395, 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 p2mHuZjf4BXF for ; Mon, 19 Oct 2009 04:11:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 80EED3A681B for ; Mon, 19 Oct 2009 04:11: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 3DC0AD80095; Mon, 19 Oct 2009 13:11:53 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091019.112601.101033217.mbj@tail-f.com> References: <20091017203207.GA3650@elstar.local> <20091019.095625.72310290.mbj@tail-f.com> <4ADC2E70.80200@netconfcentral.com> <20091019.112601.101033217.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 13:11:51 +0200 Message-Id: <1255950711.22426.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 11:11:48 -0000 Martin Bjorklund píše v Po 19. 10. 2009 v 11:26 +0200: > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > So Andy, with these clarifications, do you think we should add the s-c > > > statement or not? > > > > > > > It certainly makes more sense, now that the terminology is cleared up. > > Good! > > > I am still unclear on 2 points: > > - validation: nothing special right? > > s-c leafs can have constraints, but they are applied > > to running initially, not to candidate > > - mandatory: should be allowed; > > Lada's addition of mandatory=true to the > > user ID example makes sense; meaning is unchanged; > > This will depend on what we say in the document about *when* such > leafs are created. In the first proposal, we said that the server > creates those leafs at commit time (or edit-config towards running). > You suggested that we should be more lax and let this be an > implementation detail. If an s-c leaf is not in candidate but is also a list key - which makes a very good sense in the uid example - then the client could not use the keys to address individual list items in candidate. So I think s-c leafs have to be filled already in candidate, unless we introduce new CLRs. Lada > > If we pick one of those proposals, you cannot have 'mandatory' on a > s-c leaf, since the leaf will not exist until after validation (at > least on some implemtations). > > As for other constraints (must / unique) it depends on how the > constraint is written - if it requires the leaf to exist, it won't > work, but you can e.g. do 'unique uid;' in the example. The server > MUST make sure it picks a value that doesn't break any constraints. > > > /martin > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Oct 19 04:12: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 908903A691C for ; Mon, 19 Oct 2009 04:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_50=0.001, 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 e2lZrZap5G7i for ; Mon, 19 Oct 2009 04:12: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 64F833A681B for ; Mon, 19 Oct 2009 04:12:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00C76C0016; Mon, 19 Oct 2009 13:12:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lvKCad+cLUN6; Mon, 19 Oct 2009 13:12:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3274BC0002; Mon, 19 Oct 2009 13:12:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8B22D47E58; Mon, 19 Oct 2009 13:12:21 +0200 (CEST) Date: Mon, 19 Oct 2009 13:12:21 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091019111221.GD4765@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4ADC2E70.80200@netconfcentral.com> <20091019.112601.101033217.mbj@tail-f.com> <20091019094431.GA4708@elstar.local> <20091019.122810.24814928.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091019.122810.24814928.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] finish up 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, 19 Oct 2009 11:12:17 -0000 On Mon, Oct 19, 2009 at 12:28:10PM +0200, Martin Bjorklund wrote: > > The real issue then is the explicit validate operation, which is not > > bound to a commit, or am I missing something? > > It is also for clients that want to do off-line validation. If they > rely on the server to create s-c leafs, their validation will fail if > a constraint requires the s-c leaf to exist. In the case of such a tool, the knowledge that an s-c leaf is involved can simply lead to a meaningful warning instead of an error message: constraint "XYZ" fails but involves server created leafs and it may be satisfied when committed This is where machine readable information that there are s-c leafs would be meaningful to have. > > Here we would have to pick a solution; I am not sure yet which one > > I prefer. Restricting constraints for s-c leafs achieves the goal > > but seems a heavy-weight choice just to make :validate work. > > Do you have an alternative suggestion? If we could do the same as above with NETCONF - but I am not sure we can do this easily. /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 Mon Oct 19 04:25: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 9D7C528C187 for ; Mon, 19 Oct 2009 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.136, 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 eukCNDrdZ0Kn for ; Mon, 19 Oct 2009 04:25:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CDF3028C160 for ; Mon, 19 Oct 2009 04:25:36 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 632AC76C4F3; Mon, 19 Oct 2009 13:25:43 +0200 (CEST) Date: Mon, 19 Oct 2009 13:25:43 +0200 (CEST) Message-Id: <20091019.132543.179795445.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255950711.22426.27.camel@missotis> References: <4ADC2E70.80200@netconfcentral.com> <20091019.112601.101033217.mbj@tail-f.com> <1255950711.22426.27.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] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 11:25:37 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQbyAxOS4gMTAuIDIwMDkgdiAxMToyNiArMDIwMDoNCj4gPiBBbmR5IEJp ZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPiB3cm90ZToNCj4gPiA+IE1hcnRpbiBCam9y a2x1bmQgd3JvdGU6DQo+ID4gPiA+IFNvIEFuZHksIHdpdGggdGhlc2UgY2xhcmlmaWNhdGlvbnMs IGRvIHlvdSB0aGluayB3ZSBzaG91bGQgYWRkIHRoZSBzLWMNCj4gPiA+ID4gc3RhdGVtZW50IG9y IG5vdD8NCj4gPiA+ID4gDQo+ID4gPiANCj4gPiA+IEl0IGNlcnRhaW5seSBtYWtlcyBtb3JlIHNl bnNlLCBub3cgdGhhdCB0aGUgdGVybWlub2xvZ3kgaXMgY2xlYXJlZCB1cC4NCj4gPiANCj4gPiBH b29kIQ0KPiA+IA0KPiA+ID4gSSBhbSBzdGlsbCB1bmNsZWFyIG9uIDIgcG9pbnRzOg0KPiA+ID4g ICAtIHZhbGlkYXRpb246ICBub3RoaW5nIHNwZWNpYWwgcmlnaHQ/DQo+ID4gPiAgICAgIHMtYyBs ZWFmcyBjYW4gaGF2ZSBjb25zdHJhaW50cywgYnV0IHRoZXkgYXJlIGFwcGxpZWQNCj4gPiA+ICAg ICAgdG8gcnVubmluZyBpbml0aWFsbHksIG5vdCB0byBjYW5kaWRhdGUNCj4gPiA+ICAgLSBtYW5k YXRvcnk6ICBzaG91bGQgYmUgYWxsb3dlZDsNCj4gPiA+ICAgICAgTGFkYSdzIGFkZGl0aW9uIG9m IG1hbmRhdG9yeT10cnVlIHRvIHRoZQ0KPiA+ID4gICAgICB1c2VyIElEIGV4YW1wbGUgbWFrZXMg c2Vuc2U7IG1lYW5pbmcgaXMgdW5jaGFuZ2VkOw0KPiA+IA0KPiA+IFRoaXMgd2lsbCBkZXBlbmQg b24gd2hhdCB3ZSBzYXkgaW4gdGhlIGRvY3VtZW50IGFib3V0ICp3aGVuKiBzdWNoDQo+ID4gbGVh ZnMgYXJlIGNyZWF0ZWQuICBJbiB0aGUgZmlyc3QgcHJvcG9zYWwsIHdlIHNhaWQgdGhhdCB0aGUg c2VydmVyDQo+ID4gY3JlYXRlcyB0aG9zZSBsZWFmcyBhdCBjb21taXQgdGltZSAob3IgZWRpdC1j b25maWcgdG93YXJkcyBydW5uaW5nKS4NCj4gPiBZb3Ugc3VnZ2VzdGVkIHRoYXQgd2Ugc2hvdWxk IGJlIG1vcmUgbGF4IGFuZCBsZXQgdGhpcyBiZSBhbg0KPiA+IGltcGxlbWVudGF0aW9uIGRldGFp bC4NCj4gDQo+IElmIGFuIHMtYyBsZWFmIGlzIG5vdCBpbiBjYW5kaWRhdGUgYnV0IGlzIGFsc28g YSBsaXN0IGtleQ0KDQpXZSBuZWVkIHRvIHNheSB0aGF0IGFuIHMtYyBsZWFmIGNhbm5vdCBiZSBh IGtleS4gIFRoZSBjbGllbnQgbXVzdA0KYWx3YXlzIGdpdmUgdGhlIGtleSB2YWx1ZXMgZm9yIGxp c3QgZW50cmllcyBpbiBlZGl0LWNvbmZpZy4NCg0KPiAtIHdoaWNoIG1ha2VzDQo+IGEgdmVyeSBn b29kIHNlbnNlIGluIHRoZSB1aWQgZXhhbXBsZQ0KDQpOb3QgcmVhbGx5LCBzaW5jZSB5b3UgY2Fu IGhhdmUgbXVsdGlwbGUgdXNlcnMgd2l0aCB0aGUgc2FtZSB1aWQuDQoNCg0KDQovbWFydGluDQo= From mbj@tail-f.com Mon Oct 19 04:37: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 5A2003A699F for ; Mon, 19 Oct 2009 04:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.127, 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 vQGTRe9NEwzB for ; Mon, 19 Oct 2009 04:37:00 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9C8D03A698F for ; Mon, 19 Oct 2009 04:37:00 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A7E5776C4F3; Mon, 19 Oct 2009 13:37:06 +0200 (CEST) Date: Mon, 19 Oct 2009 13:37:06 +0200 (CEST) Message-Id: <20091019.133706.19084232.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091019111221.GD4765@elstar.local> References: <20091019094431.GA4708@elstar.local> <20091019.122810.24814928.mbj@tail-f.com> <20091019111221.GD4765@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] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 11:37:01 -0000 Juergen Schoenwaelder wrote: > If we could do the same as above with NETCONF - but I am not sure we > can do this easily. So you want to return "true", "false", or "maybe" :) I think restricting constraints for s-c leafs makes more sense. Actually, we would not have a hard restriction - just as we allow must expressions to refer to garbage leafs, we would allow them to refer to s-c leafs; they will just always fail (depending on how the expression is written - it is of course possible to write expressions that take non-existing leafs into account, and it might be useful.) /martin From lhotka@cesnet.cz Mon Oct 19 04:56: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 74EDC3A67E6 for ; Mon, 19 Oct 2009 04:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 P8aM6sToK2EU for ; Mon, 19 Oct 2009 04:56:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9D45F3A67C0 for ; Mon, 19 Oct 2009 04:56:04 -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 46968D800C0; Mon, 19 Oct 2009 13:56:11 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091019.133706.19084232.mbj@tail-f.com> References: <20091019094431.GA4708@elstar.local> <20091019.122810.24814928.mbj@tail-f.com> <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 13:56:09 +0200 Message-Id: <1255953369.22426.49.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 11:56:05 -0000 Martin Bjorklund píše v Po 19. 10. 2009 v 13:37 +0200: > Juergen Schoenwaelder wrote: > > If we could do the same as above with NETCONF - but I am not sure we > > can do this easily. > > So you want to return "true", "false", or "maybe" :) > > I think restricting constraints for s-c leafs makes more sense. > Actually, we would not have a hard restriction - just as we allow must > expressions to refer to garbage leafs, we would allow them to refer to > s-c leafs; they will just always fail (depending on how the expression > is written - it is of course possible to write expressions that take > non-existing leafs into account, and it might be useful.) I don't think s-c leafs are worth these complications. For server operation it is only important that all required configuration parameters be available when they are needed. The "schematic sugar" of filling in some of these values on behalf of the client can be considered implementation detail - and my plan actually is to implement it in the manager software, not in the server. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Oct 19 05:03: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 99FEE3A68BB for ; Mon, 19 Oct 2009 05:03:58 -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=0.119, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaGSfUuPopha for ; Mon, 19 Oct 2009 05:03: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 E0FD33A67D4 for ; Mon, 19 Oct 2009 05:03:57 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 57E7276C4F3; Mon, 19 Oct 2009 14:04:04 +0200 (CEST) Date: Mon, 19 Oct 2009 14:04:04 +0200 (CEST) Message-Id: <20091019.140404.251361587.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1255953369.22426.49.camel@missotis> References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 12:03:58 -0000 Ladislav Lhotka wrote: > I don't think s-c leafs are worth these complications. So what is your proposal? /martin From lhotka@cesnet.cz Mon Oct 19 05:26: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 896AB28C144 for ; Mon, 19 Oct 2009 05:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=-0.352, 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 DWMZhV-TNq4M for ; Mon, 19 Oct 2009 05:26:13 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CD3F728C123 for ; Mon, 19 Oct 2009 05:26:12 -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 3FF63D80095; Mon, 19 Oct 2009 14:26:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091019.140404.251361587.mbj@tail-f.com> References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> <20091019.140404.251361587.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 14:26:17 +0200 Message-Id: <1255955177.22426.69.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 12:26:13 -0000 Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: > Ladislav Lhotka wrote: > > I don't think s-c leafs are worth these complications. > > So what is your proposal? Keep this issue outside of YANG as implementation dependent. The three types of leafs currently are: 1. Mandatory - must be present, otherwise the configuration is not valid. 2. Optional, no default - needn't be present, the system must be able to operate without them. 3. Optional, default specified in DM - needn't be present, in which case the server must behave exactly as if they are present and have the default value. Do we need anything else? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Mon Oct 19 07:02: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 B805F28C1B1 for ; Mon, 19 Oct 2009 07:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-1.102, 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 oUU4KHKHBF5r for ; Mon, 19 Oct 2009 07:02:11 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id BCFE228C149 for ; Mon, 19 Oct 2009 07:02:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EA09C32317A9; Mon, 19 Oct 2009 07:02:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 41CB832317A7; Mon, 19 Oct 2009 07:02:16 -0700 (PDT) Message-ID: <4ADC7169.8060701@joelhalpern.com> Date: Mon, 19 Oct 2009 10:02:17 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ladislav Lhotka References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> <20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> In-Reply-To: <1255955177.22426.69.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 14:02:11 -0000 Maybe I am a broken record. None of the issues raised about system-created leaves have anything to do with the system-createable statement. All of the issues are present in the existing text. We have to say something to clarify what is permitted. If the system chooses to create a leaf, when is it allowed / required to create it, and how does this interact with validation? Can constraints reference optional leaves or leaves that the system may create? If so, how is the client to verify the configuration, or is he not expected to be able to verify such configuration? At this poiint, I can probably live with any consistent story that is explained clearly. As far as I can tell, our current state is that reasonable clients drawing on the document may well have expectations that do not match what reasonable devices drawing on the same document will do. And these inconsistencies will harm interoperability. (One may need to hypothesise a couple of model writers who draw different understandings to cause complete collapse.) Yours, Joel Ladislav Lhotka wrote: > Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: >> Ladislav Lhotka wrote: >>> I don't think s-c leafs are worth these complications. >> So what is your proposal? > > Keep this issue outside of YANG as implementation dependent. The three > types of leafs currently are: > > 1. Mandatory - must be present, otherwise the configuration is not > valid. > > 2. Optional, no default - needn't be present, the system must be > able to operate without them. > > 3. Optional, default specified in DM - needn't be present, in which > case the server must behave exactly as if they are present and have > the default value. > > Do we need anything else? > > Lada > >> >> /martin From mbj@tail-f.com Mon Oct 19 07:06: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 D03573A69A7 for ; Mon, 19 Oct 2009 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJUWmJJPlNja for ; Mon, 19 Oct 2009 07:06:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1C50C3A68C6 for ; Mon, 19 Oct 2009 07:06:42 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 48CD776C4F3; Mon, 19 Oct 2009 16:06:48 +0200 (CEST) Date: Mon, 19 Oct 2009 16:06:47 +0200 (CEST) Message-Id: <20091019.160647.106378846.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4ADC7169.8060701@joelhalpern.com> References: <20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> <4ADC7169.8060701@joelhalpern.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 14:06:42 -0000 "Joel M. Halpern" wrote: > Maybe I am a broken record. > None of the issues raised about system-created leaves have anything to do with > the system-createable statement. All of the issues are present in the existing > text. I agree. If Andy is ok with s-c with the additional clarifications, it seems that most people actually are in favor of adding s-c. Do you agree? Is it time to check consensus? If not, it would be good to get a sense of where people stand. /martin From cfinss@dial.pipex.com Mon Oct 19 08:21: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 A738B3A687B for ; Mon, 19 Oct 2009 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.015 X-Spam-Level: * X-Spam-Status: No, score=1.015 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_50=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WavdSK0amMsW for ; Mon, 19 Oct 2009 08:21:13 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 905873A685C for ; Mon, 19 Oct 2009 08:21:13 -0700 (PDT) X-Trace: 293889519/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.146/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.146 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEADMh3Eo+vGmS/2dsb2JhbACDJI1ZylAKhCcE X-IronPort-AV: E=Sophos;i="4.44,585,1249254000"; d="scan'208";a="293889519" X-IP-Direction: IN Received: from 1cust146.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.146]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Oct 2009 16:21:16 +0100 Message-ID: <012b01ca50c7$1559c880$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <20091015064200.GA22071@elstar.local> <200910151209.n9FC9MCZ022703@idle.juniper.net> <84600D05C20FF943918238042D7670FD36646BFBA4@EMBX01-HQ.jnpr.net> <001101ca4e7c$bba45220$0601a8c0@allison> <20091016185439.GB1841@elstar.local> <4AD8CBE9.4020504@netconfcentral.com> <20091016195949.GB2207@elstar.local> <4AD8D7B9.9020408@netconfcentral.com> Date: Mon, 19 Oct 2009 16:17:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETMOD Working Group Subject: Re: [netmod] What is config? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 15:21:14 -0000 Juergen I think that Andy summarises this well, > no -- system-creatable is part of the config definition. > So is default, mandatory, unique, etc. All the scattered > rules combine to create some sort of architecture. and so we need to resolve the issues before we have text for the architecture I-D. Look at Joel and Randy on s-c, agreeing that the text has more than one meaning (I don't know which is right - ironic that you should say > so that at least all active contributors read the > sentences leading to the same interpretation of the words they have > read. ) or the question of the stickiness of s-c objects (I don't know if there is consensus on that or not), or Phil, in the finish-up thread, on defaults and what is in config, which I understand and disagree with as the solution to a problem, and that all over this weekend just gone. My thinking is mostly with Andy and Lada, and not with Phil and yourself. I find the definition you give puts too much into operational state, too little into config. And the text you put forward 7 weeks ago calls for upgrades to netconf, new operations, new mandatory datastores, to create a three way split instead of our current config and not-config. You said it was for discussion but I do not yet see that discussion happening. So no, I am not ready to propose alternative text. Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Andy Bierman" ; "tom.petch" ; "Kent Watsen" ; "Phil Shafer" ; "NETMOD Working Group" Sent: Friday, October 16, 2009 10:29 PM Subject: Re: [netmod] What is config? > Juergen Schoenwaelder wrote: > > On Fri, Oct 16, 2009 at 09:39:21PM +0200, Andy Bierman wrote: > >> Juergen Schoenwaelder wrote: > >>> On Fri, Oct 16, 2009 at 06:00:12PM +0200, tom.petch wrote: > >>>> I think that that discussion went down a rat hole - apologies > >>>> for my part in that - leaving the main issue of what constitutes > >>>> what in this tri-partite split unresolved. > >>>> > >>>> So, no, I see no consensus to add that to any I-D. > >>>> > >>>> What is config is an unresolved issue. > >>> Can you be a bit more constructive and explain what is wrong with the > >>> text so that we can fix it and make forward progress? > >>> > >> I am willing to leave this area of work > >> for the future, but a concern I have is > >> that description-stmts and constraints > >> are traditionally written to describe > >> what happens in the running system. > >> > >> Nothing 'happens' in the config file. > >> It is not intuitive at all to think > >> about a data model object semantics this way. > >> > >> At first it was not clear that s-c leafs are 'sticky' -- > >> they stay in the config as soon as they are created and > >> do not change. IMO, there is no value in a s-c clause, > >> just document the behavior wrt/candidate and that is enough. > > > > Are you in the wrong thread? > > > > no -- system-creatable is part of the config definition. > So is default, mandatory, unique, etc. All the scattered > rules combine to create some sort of architecture. > > > > /js > > > > Andy From mbj@tail-f.com Mon Oct 19 09:42: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 AD0EC3A69D4 for ; Mon, 19 Oct 2009 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.106, 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 z8x3J5gXOxa0 for ; Mon, 19 Oct 2009 09:42: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 E45293A6861 for ; Mon, 19 Oct 2009 09:42:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2946276C4F3; Mon, 19 Oct 2009 18:42:36 +0200 (CEST) Date: Mon, 19 Oct 2009 18:42:35 +0200 (CEST) Message-Id: <20091019.184235.08754396.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <024301ca4ed9$46701220$6801a8c0@oemcomputer> References: <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> 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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 16:42:30 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Joel M. Halpern" > > To: "Randy Presuhn" > > Cc: > > Sent: Friday, October 16, 2009 8:04 PM > > Subject: Re: [netmod] system-creatable > > > > I do not think the intend was that if something is marked > > system-createable, then the system is required to ensure that it exists. > > Rather, it was a notification to the client that if the client cares > > about this node, then after doing a config commit (and maybe after doing > > a verify, we need to sort that out), the client should check to see if > > the system has created a value for the node. > > > > I do not believe that there is any interoperability problem if the > > system does not create the node. After all, if the system does need a > > value for the node, then the system will create it. > > The proposed text does not say so. > > It merely says "MAY". The only hint of support for your > reading is "Such leafs are used when the device needs to > record persistent values that cannot be known until the device > validates the configuration." That text, however, only provides > rationale, and does not require devices that "need" values to > actually create them. > > If your reading is what is intended, the text needs to be more > explicit. Yes, what Joel wrote is the intention. It says that the server MAY create the leaf. I do not understand what text you want to add. "The server MAY create the leaf, if it is needed by the server"? /martin From randy_presuhn@mindspring.com Mon Oct 19 11:18:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6263A681E for ; Mon, 19 Oct 2009 11:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, 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 g3md6TdQ3dDZ for ; Mon, 19 Oct 2009 11:18:31 -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 91B903A6781 for ; Mon, 19 Oct 2009 11:18:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Fkwia4C8s5JQO8dE5XFP5DNO5s+7VaG0KESmBac/YzfjXj6juUs+Aifz2paBSuYg; 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 [99.41.55.89] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MzwoV-0005zl-95 for netmod@ietf.org; Mon, 19 Oct 2009 14:18:35 -0400 Message-ID: <002401ca50e8$cd6ba8a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer><4AD93440.1020007@joelhalpern.com><024301ca4ed9$46701220$6801a8c0@oemcomputer> <20091019.184235.08754396.mbj@tail-f.com> Date: Mon, 19 Oct 2009 11:20:12 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f97261e4ffe16f587d16ff3ef7b5d721dd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.89 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 18:18:32 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, October 19, 2009 9:42 AM > Subject: Re: [netmod] system-creatable ... > Yes, what Joel wrote is the intention. It says that the server MAY > create the leaf. I do not understand what text you want to add. "The > server MAY create the leaf, if it is needed by the server"? I understand the case for bits like user-id to be assignable by the system. I agree that there is value in identifying those bits in an information model, so that clients will be able to know which bits necessary for a successful configuration will (not merely "might") be generated by the server if not supplied by the client. What I have a bit of trouble with is the very idea that a model would specify bits of information that may or may not be needed by the server. At first glance, such things would seem to be symptomatic of a badly designed model, so I'd appreciate a use case. All the ones I can think of are like user-id; for the system to fail to supply a value would be distinctly unhelpful, and not the kind of behaviour we'd want to go out of our way to support. The "MAY" language is of no help to the client - it provides no guarantee that the server will supply a value if the client omits one from the configuration. Randy From lhotka@cesnet.cz Mon Oct 19 11:20: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 477833A6919 for ; Mon, 19 Oct 2009 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMloBA5BvGPe for ; Mon, 19 Oct 2009 11:20:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 77C523A681E for ; Mon, 19 Oct 2009 11:20:31 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E0831D80096 for ; Mon, 19 Oct 2009 20:20:37 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 19 Oct 2009 20:20:36 +0200 Message-Id: <1255976436.4160.1.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: [netmod] [Fwd: New Version Notification for draft-ietf-netmod-dsdl-map-04] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 18:20:32 -0000 Hi, this is the -04 version of DSDL mapping draft. In my view, it should be ready for WGLC. Lada -------- PÅ™eposlaná zpráva -------- Od: IETF I-D Submission Tool Komu: lhotka@cesnet.cz Kopie: rohan@ekabal.com, schishol@nortel.com PÅ™edmÄ›t: New Version Notification for draft-ietf-netmod-dsdl-map-04 Datum: Mon, 19 Oct 2009 11:18:15 -0700 (PDT) A new version of I-D, draft-ietf-netmod-dsdl-map-04.txt has been successfuly submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-ietf-netmod-dsdl-map Revision: 04 Title: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Creation_date: 2009-10-19 WG ID: netmod Number_of_pages: 120 Abstract: This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO 19757. The following DSDL schema languages are used by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF PDU etc. Procedures for schema- based validation of such documents are also discussed. The IETF Secretariat. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Mon Oct 19 11: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 5FA173A6934; Mon, 19 Oct 2009 11:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019183001.5FA173A6934@core3.amsl.com> Date: Mon, 19 Oct 2009 11:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-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: Mon, 19 Oct 2009 18:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-04.txt Pages : 120 Date : 2009-10-19 This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO 19757. The following DSDL schema languages are used by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF PDU etc. Procedures for schema- based validation of such documents are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-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-dsdl-map-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19111815.I-D@ietf.org> --NextPart-- From kwatsen@juniper.net Mon Oct 19 11:36: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 59DC03A68B9 for ; Mon, 19 Oct 2009 11:36:22 -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 1HFPUA8x1vam for ; Mon, 19 Oct 2009 11:36:21 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 57CE13A6857 for ; Mon, 19 Oct 2009 11:36:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKStyxqsGYJM4vXGkxEJZpm/rbyTJ/nBML@postini.com; Mon, 19 Oct 2009 11:36:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Mon, 19 Oct 2009 11:36:17 -0700 From: Kent Watsen To: "'Joel M. Halpern'" , Ladislav Lhotka Date: Mon, 19 Oct 2009 11:36:16 -0700 Thread-Topic: [netmod] finish up Thread-Index: AcpQxM/pk6vJk5eoRoql8Fy9VMs3nQAH0PuQ Message-ID: <84600D05C20FF943918238042D7670FD36646BFBC4@EMBX01-HQ.jnpr.net> References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> <20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> <4ADC7169.8060701@joelhalpern.com> In-Reply-To: <4ADC7169.8060701@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 18:36:22 -0000 I'm with Lada, leave s-c out of YANG for now. Even though the current def= inition is OK, I think it's too narrow of a solution to be all that useful = - for instance: - why are only-leafs and only-creatable? - what about containers or list-elements? - why not modifiable and deletable? - what if the server has a user-defined commit script that modifies config even though it's not marked s-c in the YANG model? I'd wait for next YANG version to define a mechanism to that enables a serv= er to report when/where it created config. This is what we (Juniper) did a= nd it works great. I want to submit an I-D to the WG, but I don't want to = have it be limited by this s-c definition > If the system > chooses to create a leaf, when is it allowed / required to create it, > and how does this interact with validation? > > Can constraints reference > optional leaves or leaves that the system may create? If so, how is the > client to verify the configuration, or is he not expected to be able to > verify such configuration? In the YANG model, these leafs would not be mandatory - all normal rules ap= ply, is there really anything more that needs to be said? One thing I have not heard discussed is that the s-c leafs need to be creat= ed as part of the transaction - prior to the RPC-Reply being sent. This is= important as we (Juniper) have also created a capability for devices to re= turn the timestamp/fingerprint of their running config, which allows a clie= nt to discover when it's out of sync without having to get the entire confi= g from the device. Here is the sequence we use: if RPC-Reply indicates implicit-changes on nodes identified in RPC-Reply // get new timestamp/fingerprint Its important that the changes occur as part of the transaction so that the= y can be reported in the RPC-Reply =20 Thanks, Kent From andy@netconfcentral.com Mon Oct 19 11:46: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 F2DDB28C132 for ; Mon, 19 Oct 2009 11:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 aUWEeiu5HhLs for ; Mon, 19 Oct 2009 11:46:20 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 3AA2828C0FC for ; Mon, 19 Oct 2009 11:46:20 -0700 (PDT) Received: (qmail 23237 invoked from network); 19 Oct 2009 18:46:25 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 19 Oct 2009 11:46:24 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: O_JN4hIVM1l79aG3IcOW9hQe570G.digHFiNooG3NngaKrAl28cah7J9fL1FCrnVuhdzUDn1N_JSIh6bsCUq.7wCadmAQqiu9mgOcIkcCQypgTLNbumlTmyr3EwSTlbqxiAnK.bc4bkEx01PPL4hRIKm_kPoSZ6DiGmWCgdeXe8gPd4BV1f8jatPqY67CvtmeYQwjBxlSYS08wFhu9ZeNXTTnmTZDKwMKTL1nptyldOboinjANkTIbuPCmkA3G.ztCoZGxhZuMMf8jMNQ.buHVzuAhjMCYe8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADCB42D.2010307@netconfcentral.com> Date: Mon, 19 Oct 2009 11:47:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> <20091019.184235.08754396.mbj@tail-f.com> In-Reply-To: <20091019.184235.08754396.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 18:46:21 -0000 Martin Bjorklund wrote: > "Randy Presuhn" wrote: >> Hi - >> >>> From: "Joel M. Halpern" >>> To: "Randy Presuhn" >>> Cc: >>> Sent: Friday, October 16, 2009 8:04 PM >>> Subject: Re: [netmod] system-creatable >>> >>> I do not think the intend was that if something is marked >>> system-createable, then the system is required to ensure that it exists. >>> Rather, it was a notification to the client that if the client cares >>> about this node, then after doing a config commit (and maybe after doing >>> a verify, we need to sort that out), the client should check to see if >>> the system has created a value for the node. >>> >>> I do not believe that there is any interoperability problem if the >>> system does not create the node. After all, if the system does need a >>> value for the node, then the system will create it. >> The proposed text does not say so. >> >> It merely says "MAY". The only hint of support for your >> reading is "Such leafs are used when the device needs to >> record persistent values that cannot be known until the device >> validates the configuration." That text, however, only provides >> rationale, and does not require devices that "need" values to >> actually create them. >> >> If your reading is what is intended, the text needs to be more >> explicit. > > Yes, what Joel wrote is the intention. It says that the server MAY > create the leaf. I do not understand what text you want to add. "The > server MAY create the leaf, if it is needed by the server"? > The s-c statement is ignored by the server, like mandatory for /rpc/output leafs. If the server violates the rule, it must be a bug. On the client side, knowing s-c=false says the server will not provide a value. Knowing s-c=true says the server may provide a value. Not that useful. This new statement doesn't actually change anything for the client, other than the possibility of a warning message, as Juergen suggested. The s-c property doesn't actually impact the 'constraints ripple effect' (mandatory leaf X w/must-stmt forces every leaf in the must-stmt to be mandatory, if X is set). If a leaf is part of a constraint, the client must provide the relevant 'associated nodes'. The s-c statement doesn't change that a bit. IMO, the behavior may be OK (but may be problematic wrt/ corner-cases), but the clause doesn't seem to help the client at all. > > /martin Andy From mbj@tail-f.com Mon Oct 19 12:11: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 03ACC3A6857 for ; Mon, 19 Oct 2009 12:11:13 -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 UB3oTPpnObSg for ; Mon, 19 Oct 2009 12:11:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3C9423A69D1 for ; Mon, 19 Oct 2009 12:11:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 51C3E76C4D1; Mon, 19 Oct 2009 21:11:15 +0200 (CEST) Date: Mon, 19 Oct 2009 21:11:14 +0200 (CEST) Message-Id: <20091019.211114.208668357.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ADCB42D.2010307@netconfcentral.com> References: <024301ca4ed9$46701220$6801a8c0@oemcomputer> <20091019.184235.08754396.mbj@tail-f.com> <4ADCB42D.2010307@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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 19:11:13 -0000 Andy Bierman wrote: > On the client side, knowing s-c=false says the server will > not provide a value. Knowing s-c=true says the server may > provide a value. Not that useful. I think it is useful, b/c it tells the client which leafs may be created by the server. It knows that other leafs will not be created by the server. So if the alternative is to do nothing, what can a client expect from a conformant server? Is the server allowed to do anything? /martin From randy_presuhn@mindspring.com Mon Oct 19 12:19:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F4B28C0DB for ; Mon, 19 Oct 2009 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, 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 BY9xacAWOqtm for ; Mon, 19 Oct 2009 12:19:48 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E6C993A69D9 for ; Mon, 19 Oct 2009 12:19:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=a62NVPlXkbJ0+T9qrUHS02bFU4q5NCuOE4hfS5QGoENXM9bDdCZjEPrpjx6PUWH0; 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 [99.41.55.89] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mzxlq-0002nk-Ie for netmod@ietf.org; Mon, 19 Oct 2009 15:19:54 -0400 Message-ID: <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <024301ca4ed9$46701220$6801a8c0@oemcomputer><20091019.184235.08754396.mbj@tail-f.com><4ADCB42D.2010307@netconfcentral.com> <20091019.211114.208668357.mbj@tail-f.com> Date: Mon, 19 Oct 2009 12:21:32 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f98ced4dfc02af5de85c4eed61962deccc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.89 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 19:19:49 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Monday, October 19, 2009 12:11 PM > Subject: Re: [netmod] system-creatable > > Andy Bierman wrote: > > On the client side, knowing s-c=false says the server will > > not provide a value. Knowing s-c=true says the server may > > provide a value. Not that useful. > > I think it is useful, b/c it tells the client which leafs may be > created by the server. It knows that other leafs will not be created > by the server. > > So if the alternative is to do nothing, what can a client expect from > a conformant server? Is the server allowed to do anything? That's a strawman. Another alternative is to use MUST rather than MAY. Then the client would know exactly what to expect, and the requirements for the server would be unambiguous. Randy From mbj@tail-f.com Mon Oct 19 12: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 1AFEE3A6923 for ; Mon, 19 Oct 2009 12:32:15 -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 ZsiJqe2sb5DB for ; Mon, 19 Oct 2009 12:32: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 4DDB028C106 for ; Mon, 19 Oct 2009 12:32:14 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2792B76C4D1; Mon, 19 Oct 2009 21:32:20 +0200 (CEST) Date: Mon, 19 Oct 2009 21:32:20 +0200 (CEST) Message-Id: <20091019.213220.223416025.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> References: <4ADCB42D.2010307@netconfcentral.com> <20091019.211114.208668357.mbj@tail-f.com> <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> 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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 19:32:15 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: ; > > Sent: Monday, October 19, 2009 12:11 PM > > Subject: Re: [netmod] system-creatable > > > > Andy Bierman wrote: > > > On the client side, knowing s-c=false says the server will > > > not provide a value. Knowing s-c=true says the server may > > > provide a value. Not that useful. > > > > I think it is useful, b/c it tells the client which leafs may be > > created by the server. It knows that other leafs will not be created > > by the server. > > > > So if the alternative is to do nothing, what can a client expect from > > a conformant server? Is the server allowed to do anything? > > That's a strawman. I don't think it is - people *have* suggested that we should not add s-c, and I really want to know what people think should be allowed. Kent talked about thir commit scripts, and AFAIK, these scripts can do anything. If we don't add s-c, I think we should add text that describes what a server is allowed to do, and what a client can expect. > Another alternative is to use MUST rather than > MAY. Then the client would know exactly what to expect, and the > requirements for the server would be unambiguous. Yes. /martin From andy@netconfcentral.com Mon Oct 19 12:46: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 0A3EA28C164 for ; Mon, 19 Oct 2009 12:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 Ju6Y7L+7WFoD for ; Mon, 19 Oct 2009 12:45: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 5E13328C14A for ; Mon, 19 Oct 2009 12:45:59 -0700 (PDT) Received: (qmail 77763 invoked from network); 19 Oct 2009 19:46:04 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 19 Oct 2009 12:46:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YpEaFf8VM1mDl4AGBXAakEawSmB8xeWj62vtLn2z4BV1iupyOjGz9rcm1tD79cJ5nESIl8TMl3iTq4_bOpofU09cF2hsyFCBy3bxZH0bWPBJwE5sc2Or1U6pmnc8_z5oiV_v6wZdSyWmYqRtu5VBAFz20cFxgKtwclTPoJ1sSVpT.EgLZcKL3ktAVQ13aJIiDbYs.zMvQS6ENYGDFOWicTW1y77KEhORotZwKMrkKM8W_bj7lgRJLuWitmQpJG6Dkh4BcJroPgX6SJv8XKYlu5Pa.XEa3kAnfkksf.c_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADCC227.7060501@netconfcentral.com> Date: Mon, 19 Oct 2009 12:46:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <024301ca4ed9$46701220$6801a8c0@oemcomputer><20091019.184235.08754396.mbj@tail-f.com><4ADCB42D.2010307@netconfcentral.com> <20091019.211114.208668357.mbj@tail-f.com> <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> In-Reply-To: <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 19:46:00 -0000 Randy Presuhn wrote: > Hi - > >> From: "Martin Bjorklund" >> To: >> Cc: ; >> Sent: Monday, October 19, 2009 12:11 PM >> Subject: Re: [netmod] system-creatable >> >> Andy Bierman wrote: >>> On the client side, knowing s-c=false says the server will >>> not provide a value. Knowing s-c=true says the server may >>> provide a value. Not that useful. >> I think it is useful, b/c it tells the client which leafs may be >> created by the server. It knows that other leafs will not be created >> by the server. >> >> So if the alternative is to do nothing, what can a client expect from >> a conformant server? Is the server allowed to do anything? > > That's a strawman. Another alternative is to use MUST rather than > MAY. Then the client would know exactly what to expect, and the > requirements for the server would be unambiguous. > The problem with MUST is that is turns every s-c=true leaf into mandatory=true. At best, you could say server MUST create the leaf, or MUST return the appropriate , I prefer to leave mandatory=true meaning the client is responsible for making sure the leaf exists. That could be one of: A - create the leaf B - hope that the server will create the leaf Robust client applications will probably not choose plan B. That's how we got here. Sometimes mandatory=true means (B) will work. IMO, usually not a problem (*). The client is still responsible, so use plan B at your own risk. The server is responsible for only adding leafs that keep the config valid. (* == data model design will impact this problem. Top-level leafs are kind of an exception. Usually, the client MUST create the container parent, list parent, or case siblings to make the s-c problem relevant. In these cases, I don't see any problem if the server fills in valid leafs during the commit. It probably is a problem wrt/ offline validation, but 1 of many.) > Randy Andy From phil@juniper.net Mon Oct 19 12:50: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 13E573A6903 for ; Mon, 19 Oct 2009 12:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 xNsEVU-EAsWm for ; Mon, 19 Oct 2009 12:50:13 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 38A973A68C1 for ; Mon, 19 Oct 2009 12:50:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKStzC8XT6C0KXSlpNpr94o7kCeC3qypnh@postini.com; Mon, 19 Oct 2009 12:50:20 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 19 Oct 2009 12:45: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, 19 Oct 2009 12:45:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 12:45:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 12:45: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 n9JJjnj63341; Mon, 19 Oct 2009 12:45:49 -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 n9JJWuIw035997; Mon, 19 Oct 2009 19:32:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910191932.n9JJWuIw035997@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> Date: Mon, 19 Oct 2009 15:32:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Oct 2009 19:45:50.0174 (UTC) FILETIME=[C2AB77E0:01CA50F4] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 19:50:14 -0000 "Randy Presuhn" writes: >That's a strawman. Another alternative is to use MUST rather than >MAY. Then the client would know exactly what to expect, and the >requirements for the server would be unambiguous. If it is "MUST" the client will have to refetch the config to know the final config. If it is "MAY" the client will have to refetch the config to know the final config. I'm missing why it needs to be MUST. What does this solve? If the server does not create it, the client's behavior is the same. The idea of having edit-config and/or commit-config return a list of created, changed, and deleted nodes seem like a better answer. I'm thinking we should leave s-c until we get some operational experience. We may end up with a different answer, like a module that augments the replies for edit-config and commit-config. Thanks, Phil From randy_presuhn@mindspring.com Mon Oct 19 13: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 872563A680C for ; Mon, 19 Oct 2009 13:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 7guDDncnDTp0 for ; Mon, 19 Oct 2009 13:06:49 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 8A88E3A67DD for ; Mon, 19 Oct 2009 13:06:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OgZyEQ6HNL8J6+TPFz65sSH9lE/TjtaeEozA7CSE8S1zlCXhyx3PyitjU10YH5mK; 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 [99.41.55.89] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MzyVM-0003c2-Em for netmod@ietf.org; Mon, 19 Oct 2009 16:06:56 -0400 Message-ID: <00e101ca50f7$effa8f80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <024301ca4ed9$46701220$6801a8c0@oemcomputer><20091019.184235.08754396.mbj@tail-f.com><4ADCB42D.2010307@netconfcentral.com> <20091019.211114.208668357.mbj@tail-f.com> <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> <4ADCC227.7060501@netconfcentral.com> Date: Mon, 19 Oct 2009 13:08:33 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9a7477efd70baca58bdf02b7f08503451350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.89 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 20:06:50 -0000 Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Monday, October 19, 2009 12:46 PM > Subject: Re: [netmod] system-creatable ... > > That's a strawman. Another alternative is to use MUST rather than > > MAY. Then the client would know exactly what to expect, and the > > requirements for the server would be unambiguous. > > > > The problem with MUST is that is turns every s-c=true > leaf into mandatory=true. No. Mandatory=true means the *client* is required to supply the information. The text I proposed does not have that effect. The MAY->MUST changes proposed only affected what was required of the *server*, not what was required of the client. (though s-c only makes sense for information that is in some more general sense "required", if not in the technical "mandatory=true" sense) Why on earth would one want a model to specify that the server should create information that it doesn't need? > At best, you could say server MUST create the leaf, Yes, that is what the text changes I proposed did. > or MUST return the appropriate , This should only happen under pathological circumstances, like ENOMEM, not on an implementation whim. > I prefer to leave mandatory=true meaning the client > is responsible for making sure the leaf exists. No one is proposing that we change that. > That could be one of: > A - create the leaf > B - hope that the server will create the leaf > > Robust client applications will probably not choose plan B. What I am arguing for is that s-c should, instead of your "plan B", be *required* to create such leaves when the client omits the data. > That's how we got here. > Sometimes mandatory=true means (B) will work. Let's *not* confuse s-c with mandatory=true. > IMO, usually not a problem (*). The client is still responsible, > so use plan B at your own risk. The server is responsible > for only adding leafs that keep the config valid. s-c (as I'd like to see it) is a way of identifying the bits which the server *must* create to meet these requirements, rather than a merely advisory facility that says "oh, by the way, if you don't supply this bit, some servers might make up a value for you if they feel like it at the moment." > (* == data model design will impact this problem. > Top-level leafs are kind of an exception. > Usually, the client MUST create the container parent, > list parent, or case siblings to make the s-c problem relevant. > In these cases, I don't see any problem if the server > fills in valid leafs during the commit. It probably > is a problem wrt/ offline validation, but 1 of many.) Lots of things are problems wrt/offline validation. I don't see s-c bits as making offline validation any harder than it already is. Randy From jmh@joelhalpern.com Mon Oct 19 13:13: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 AE2233A685A for ; Mon, 19 Oct 2009 13:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 k982kUTJBuLI for ; Mon, 19 Oct 2009 13:13:43 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CF15E3A67B0 for ; Mon, 19 Oct 2009 13:13:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4149532317AA; Mon, 19 Oct 2009 13:13:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 53C3832317A9; Mon, 19 Oct 2009 13:13:50 -0700 (PDT) Message-ID: <4ADCC87F.8070408@joelhalpern.com> Date: Mon, 19 Oct 2009 16:13:51 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Randy Presuhn References: <024301ca4ed9$46701220$6801a8c0@oemcomputer><20091019.184235.08754396.mbj@tail-f.com><4ADCB42D.2010307@netconfcentral.com> <20091019.211114.208668357.mbj@tail-f.com> <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> <4ADCC227.7060501@netconfcentral.com> <00e101ca50f7$effa8f80$6801a8c0@oemcomputer> In-Reply-To: <00e101ca50f7$effa8f80$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 20:13:44 -0000 There seem to be two related but distinct needs: 1) Randy, you seem to be asking for a marking that tells the sesrver what it must create. 2) The proposed definition basically says "client, if for any reason your operation depends upon knowing the value of this node, then after the commit you better fetch the node, because the system may well have chosen to create a value for this." I find (2) to be useful. I understand what a management system can do because of that marking. It can be argued that it is not extremely useful because many management systems will fetch the config after a committ anyway. On the other hand, I do not understand who is helped by definition (1). The managed device does not really care. It either needs the information, in whcihc case it was alreayd prepared to create it, or it does not need the information, in which case it may well have no clue as to what value to use in this node it has been ordered to create. The client does not appear to be helped either. It is exceedingly rare that the client requires a node to exist, but does not care about its value. Somewhat confused by teh discussion, Joel Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: >> Sent: Monday, October 19, 2009 12:46 PM >> Subject: Re: [netmod] system-creatable > ... >>> That's a strawman. Another alternative is to use MUST rather than >>> MAY. Then the client would know exactly what to expect, and the >>> requirements for the server would be unambiguous. >>> >> The problem with MUST is that is turns every s-c=true >> leaf into mandatory=true. > > No. Mandatory=true means the *client* is required to supply > the information. The text I proposed does not have that effect. > The MAY->MUST changes proposed only affected what was > required of the *server*, not what was required of the client. > > (though s-c only makes sense for information that is in some > more general sense "required", if not in the technical "mandatory=true" > sense) Why on earth would one want a model to specify that the > server should create information that it doesn't need? > >> At best, you could say server MUST create the leaf, > > Yes, that is what the text changes I proposed did. > >> or MUST return the appropriate , > > This should only happen under pathological circumstances, > like ENOMEM, not on an implementation whim. > >> I prefer to leave mandatory=true meaning the client >> is responsible for making sure the leaf exists. > > No one is proposing that we change that. > >> That could be one of: >> A - create the leaf >> B - hope that the server will create the leaf >> >> Robust client applications will probably not choose plan B. > > What I am arguing for is that s-c should, instead of your "plan B", > be *required* to create such leaves when the client omits the data. > >> That's how we got here. >> Sometimes mandatory=true means (B) will work. > > Let's *not* confuse s-c with mandatory=true. > >> IMO, usually not a problem (*). The client is still responsible, >> so use plan B at your own risk. The server is responsible >> for only adding leafs that keep the config valid. > > s-c (as I'd like to see it) is a way of identifying the bits which the > server *must* create to meet these requirements, rather than > a merely advisory facility that says "oh, by the way, if you don't > supply this bit, some servers might make up a value for you > if they feel like it at the moment." > >> (* == data model design will impact this problem. >> Top-level leafs are kind of an exception. >> Usually, the client MUST create the container parent, >> list parent, or case siblings to make the s-c problem relevant. >> In these cases, I don't see any problem if the server >> fills in valid leafs during the commit. It probably >> is a problem wrt/ offline validation, but 1 of many.) > > Lots of things are problems wrt/offline validation. I don't see > s-c bits as making offline validation any harder than it already is. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From randy_presuhn@mindspring.com Mon Oct 19 13:20:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150203A68D6 for ; Mon, 19 Oct 2009 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEsBMFg05Q4I for ; Mon, 19 Oct 2009 13:20:53 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 34E6D3A68BB for ; Mon, 19 Oct 2009 13:20:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Xjlf4/qUh+z5SaxIgRoHsg89Yg46Kbb04HaLSxS/cpakvyApGcjdvmXSFtzpf60i; 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 [99.41.55.89] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mzyiy-0006eD-2y for netmod@ietf.org; Mon, 19 Oct 2009 16:21:00 -0400 Message-ID: <00e601ca50f9$e7a7e7e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910191932.n9JJWuIw035997@idle.juniper.net> Date: Mon, 19 Oct 2009 13:22:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9bc25bd54125e9f7cf574c7ba9f762ea3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.89 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 20:20:54 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Monday, October 19, 2009 12:32 PM > Subject: Re: [netmod] system-creatable > > "Randy Presuhn" writes: > >That's a strawman. Another alternative is to use MUST rather than > >MAY. Then the client would know exactly what to expect, and the > >requirements for the server would be unambiguous. > > If it is "MUST" the client will have to refetch the config to know > the final config. > > If it is "MAY" the client will have to refetch the config to know > the final config. > > I'm missing why it needs to be MUST. What does this solve? If the > server does not create it, the client's behavior is the same. If it's a MUST, then, in our user-id example, no client needs to have user-id allocation logic. If its a MAY, then all clients will need user-id allocation logic, in order to accommodate the servers that don't. ... > I'm thinking we should leave s-c until we get some operational > experience. We may end up with a different answer, like a module > that augments the replies for edit-config and commit-config. There are a bunch of cases, especially in provisioning, where a client only needs to allocate / reserve a "foo", without much or any concern about which one is to be allocated. Once allocated, however, for purposes of configuration backup/restore and versioning, which one got allocated matters a great deal, since the "which one" may be information that has meaning and gets propagated beyond the immediate control of the configuration management system. I think this could be turned into an argument for a "reserve" or "allocate" operation, but I wouldn't want to do it without having a coherent metamodel and object lifecycle to support it. For the same reason (lack of metamodel & lifecycle) I can agree with deferring s-c. Randy From randy_presuhn@mindspring.com Mon Oct 19 13:38: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 023E23A6911 for ; Mon, 19 Oct 2009 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 d+vLudtbKJqb for ; Mon, 19 Oct 2009 13:38:31 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 426DB3A692E for ; Mon, 19 Oct 2009 13:38:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oGdCIuXtzuPpvmoUT09y7Tmhza2RFsO2K2i+ZhGyvr74Js1etGpd2FM7pM81e33o; 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 [99.41.55.89] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mzyzc-0001cF-8N for netmod@ietf.org; Mon, 19 Oct 2009 16:38:12 -0400 Message-ID: <00ed01ca50fc$4ebd7420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <024301ca4ed9$46701220$6801a8c0@oemcomputer><20091019.184235.08754396.mbj@tail-f.com><4ADCB42D.2010307@netconfcentral.com> <20091019.211114.208668357.mbj@tail-f.com> <004d01ca50f1$5e9d7bc0$6801a8c0@oemcomputer> <4ADCC227.7060501@netconfcentral.com> <00e101ca50f7$effa8f80$6801a8c0@oemcomputer> <4ADCC87F.8070408@joelhalpern.com> Date: Mon, 19 Oct 2009 13:39:50 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f98037d8320882a4b64bf07bdb4e6f6310350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.89 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 20:38:32 -0000 Hi - > From: "Joel M. Halpern" > To: "Randy Presuhn" > Cc: > Sent: Monday, October 19, 2009 1:13 PM > Subject: Re: [netmod] system-creatable > > There seem to be two related but distinct needs: > 1) Randy, you seem to be asking for a marking that tells the sesrver > what it must create. It also tells the client what it can depend on the server to create if the client does not supply a value. > 2) The proposed definition basically says "client, if for any reason > your operation depends upon knowing the value of this node, then after > the commit you better fetch the node, because the system may well have > chosen to create a value for this." > > I find (2) to be useful. I understand what a management system can do > because of that marking. It can be argued that it is not extremely > useful because many management systems will fetch the config after a > committ anyway. But (2) is already true for everything anyway, since bits of configuration data may have been put in place by other clients, as well as the server itself. > On the other hand, I do not understand who is helped by definition (1). > The managed device does not really care. It either needs the > information, in whcihc case it was alreayd prepared to create it, or it > does not need the information, in which case it may well have no clue as > to what value to use in this node it has been ordered to create. >From an *interoperability* perspective it does matter. Can a client rely on a server to supply a c-s value? With the MAY language, it cannot. > The client does not appear to be helped either. It is exceedingly rare > that the client requires a node to exist, but does not care about its value. The client may care a great deal about the value, but doesn't care how the server arrives at it. Group IDs, User IDs, MAC addresses (writeable on some systems, but normally it's preferable to let the system use what it reads from hardware) SNMP Engine IDs (may be computed from local information, but architecturally they're *administrative*, and should be considered configuration data) backup media from a "scratch" pool - just a few examples. Randy From andy@netconfcentral.com Mon Oct 19 14:00: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 A30C23A68A9 for ; Mon, 19 Oct 2009 14:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 73UwPDxUAqR9 for ; Mon, 19 Oct 2009 14:00:35 -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 A5AC93A67B0 for ; Mon, 19 Oct 2009 14:00:34 -0700 (PDT) Received: from [68.142.200.224] by n14.bullet.mail.mud.yahoo.com with NNFMP; 19 Oct 2009 21:00:40 -0000 Received: from [68.142.201.64] by t5.bullet.mud.yahoo.com with NNFMP; 19 Oct 2009 21:00:40 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 19 Oct 2009 21:00:40 -0000 X-Yahoo-Newman-Id: 352439.59764.bm@omp416.mail.mud.yahoo.com Received: (qmail 33552 invoked from network); 19 Oct 2009 21:00:39 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 19 Oct 2009 14:00:39 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: sHbli.YVM1me9H9skD7QXEpO7o.ngnDZ9BvF1QQ352JjwwA34qr4ToocYgJqj6xiiKwG_.ZN_ff3Rpz7sGzPhFkMWV_DbHA8ciCuTZ6OFs7sj0jYnjUeW04ty6_d39oXzv8yPesDai9eQXdlQUB7hSsUgcEm5wLj3T_VOQUz_L5NY502jIpWfUM2gwfvEe2t3svoOAwv5jLR9JwUncb0zeEgrF2m5vU2_Om8TFCBDV0UNh1KbsFV2j1gPKSpJCso X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADCD329.3000502@netconfcentral.com> Date: Mon, 19 Oct 2009 13:59:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910191932.n9JJWuIw035997@idle.juniper.net> In-Reply-To: <200910191932.n9JJWuIw035997@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 21:00:35 -0000 Phil Shafer wrote: > "Randy Presuhn" writes: >> That's a strawman. Another alternative is to use MUST rather than >> MAY. Then the client would know exactly what to expect, and the >> requirements for the server would be unambiguous. > > If it is "MUST" the client will have to refetch the config to know > the final config. > > If it is "MAY" the client will have to refetch the config to know > the final config. > > I'm missing why it needs to be MUST. What does this solve? If the > server does not create it, the client's behavior is the same. > > The idea of having edit-config and/or commit-config return a list > of created, changed, and deleted nodes seem like a better answer. > > I'm thinking we should leave s-c until we get some operational > experience. We may end up with a different answer, like a module > that augments the replies for edit-config and commit-config. > I agree with you (for a change :-) One might even use notifications to inform the client(s) that the running config has changed. There are lots of factors that might make the s-c leaf a non-problem. Experience is knowing which theoretical problems were not real problems, and which real problems were totally missed by the theories. Let's write some standard YANG modules first, (ACM anyone?) and see what works and what doesn't. > Thanks, > Phil Andy From jmh@joelhalpern.com Mon Oct 19 14:05: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 6C8C23A6977 for ; Mon, 19 Oct 2009 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 yZJuxWrxyLx2 for ; Mon, 19 Oct 2009 14:05:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A7E733A692F for ; Mon, 19 Oct 2009 14:05:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3907A3231776; Mon, 19 Oct 2009 14:05:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 471133228026; Mon, 19 Oct 2009 14:05:15 -0700 (PDT) Message-ID: <4ADCD48B.1060307@joelhalpern.com> Date: Mon, 19 Oct 2009 17:05:15 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Randy Presuhn , NETMOD Working Group References: <200910191932.n9JJWuIw035997@idle.juniper.net> <00e601ca50f9$e7a7e7e0$6801a8c0@oemcomputer> <4ADCCC4C.1020405@joelhalpern.com> <00f401ca50fc$ee0276c0$6801a8c0@oemcomputer> In-Reply-To: <00f401ca50fc$ee0276c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 21:05:09 -0000 Part of my problem may be a failure of imagination. I have trouble imagining a field for which the data model requires that the field exist the system can reliably know the value and the client can not reasonably be expected to know the value. The userid case is not actually a good example of this, because the system may not need userids. As something the system may create, if it needs them, it makes sense to me. As a global requirement that the user model MUST have valid userids, I don't follow it. (Requiring that IDs, if they are used, be unique, makes sense because good security practice says to avoid confusing users.) We can give up on all notion of knowing what the system may modify, and take the view that since multi-manager means that you can never know anyway, the client effectively must refresh his model before beginning any operation, and after any commit if operation is continuing. But folks have repeatedly said that thye do not want clients to have to fetch everything in sight. (There are meaningful alternatives for dealing with multi-manager, but they will not cope with system-created very well.) Yours, Joel Randy Presuhn wrote: > Hi - > >> From: "Joel M. Halpern" >> To: "Randy Presuhn" >> Sent: Monday, October 19, 2009 1:30 PM >> Subject: Re: [netmod] system-creatable >> >> I do not follow your reasoning about the relationship between whether >> S-C is a must and the user-id example. >> >> If user-id is mandatory, then the client better be prepared to create it. > > It is not mandatory, at least not in the Yang sense. > >> If user-id is optional, then clients do not have to create it if they >> don't want to. > > Agreed. > >> If user-id is optional and system-createable, then the client is not >> required to create it, but the client should be aware that the system >> may choose to assign it a value, for example, if it uses userids. > > replace "may" with "MUST". > >> I suppose we could add the mixed case of a leaf declared as both >> mandatory and system-createable, to indicate that the system is required >> to create it if the client does not. The verbiage would be pretty >> strange, but at least we don't use the optional case that I think is useful. > > I don't want to go there. > > I think the confusion may come from the shorthand. When I say > "MAY" and "MUST" here, I am referring to the replacement of > the "MAY" in the proposed text with "MUST" The "MAYs" in the > proposed text all had to do with *server* requirements, not > client requirements. > > Randy > > From jmh@joelhalpern.com Mon Oct 19 14:34: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 EC45728C130 for ; Mon, 19 Oct 2009 14:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 Zo0+f8orwH7T for ; Mon, 19 Oct 2009 14:34:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 1FABE28C11A for ; Mon, 19 Oct 2009 14:34:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id AA65C3228026; Mon, 19 Oct 2009 14:34:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 035313231776; Mon, 19 Oct 2009 14:34:17 -0700 (PDT) Message-ID: <4ADCDB5B.9060707@joelhalpern.com> Date: Mon, 19 Oct 2009 17:34:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <200910191932.n9JJWuIw035997@idle.juniper.net> <4ADCD329.3000502@netconfcentral.com> In-Reply-To: <4ADCD329.3000502@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 21:34:13 -0000 If we want to punt, then we need to explicitly say: "Warning, the contents of running after the commit may be different from those of candidate before the commit. Any client expecting to perform continued operations on the configuration is advised to perform a get-config operation after a commit." At that point, the system can do whatever it wants, and the client has been warned that unexpected things may happen. That still leaves some very odd corner cases about constraints that reference optional leaves that the system chooses to fill in. But, well, if we want to punt then we punt. Yours, Joel Andy Bierman wrote: > Phil Shafer wrote: >> "Randy Presuhn" writes: >>> That's a strawman. Another alternative is to use MUST rather than >>> MAY. Then the client would know exactly what to expect, and the >>> requirements for the server would be unambiguous. >> If it is "MUST" the client will have to refetch the config to know >> the final config. >> >> If it is "MAY" the client will have to refetch the config to know >> the final config. >> >> I'm missing why it needs to be MUST. What does this solve? If the >> server does not create it, the client's behavior is the same. >> >> The idea of having edit-config and/or commit-config return a list >> of created, changed, and deleted nodes seem like a better answer. >> >> I'm thinking we should leave s-c until we get some operational >> experience. We may end up with a different answer, like a module >> that augments the replies for edit-config and commit-config. >> > > I agree with you (for a change :-) > > One might even use notifications to inform the client(s) > that the running config has changed. There are lots of > factors that might make the s-c leaf a non-problem. > > Experience is knowing which theoretical problems > were not real problems, and which real problems > were totally missed by the theories. Let's write some > standard YANG modules first, (ACM anyone?) and see > what works and what doesn't. > > >> Thanks, >> Phil > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Mon Oct 19 14:48: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 6E8EB3A67B8 for ; Mon, 19 Oct 2009 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 1WSXUh-bdFDt for ; Mon, 19 Oct 2009 14:48:41 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 927093A66B4 for ; Mon, 19 Oct 2009 14:48:41 -0700 (PDT) Received: from [68.142.200.226] by n17.bullet.mail.mud.yahoo.com with NNFMP; 19 Oct 2009 21:48:47 -0000 Received: from [68.142.201.244] by t7.bullet.mud.yahoo.com with NNFMP; 19 Oct 2009 21:48:47 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 19 Oct 2009 21:48:47 -0000 X-Yahoo-Newman-Id: 307299.7830.bm@omp405.mail.mud.yahoo.com Received: (qmail 55944 invoked from network); 19 Oct 2009 21:48:46 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 19 Oct 2009 14:48:46 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 1KmOGwUVM1nho4L5cltEgFbj2qiJKY8WP2RGcXufXnZ9PQWVY86Tdo7t_WAXcYltuJh6GVKEuYeciKUL_jA6ZqGWgUFHLs7uv99rTZ14KW5y_9grg3WQPirzVCNtcIlSZ4vMzD2cyIl1C181CVsl4BjFPCZY2Bcc6jae0rzOiSy25ORerY2b11maQ99juo0CRAfOzYq6N9KqEu_WNLSP3Gt9QjFASdY1HPQZHLEIt2_Vv5IjjY_O9ub1eTvzHLSc X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADCDE70.4020008@netconfcentral.com> Date: Mon, 19 Oct 2009 14:47:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200910191932.n9JJWuIw035997@idle.juniper.net> <4ADCD329.3000502@netconfcentral.com> <4ADCDB5B.9060707@joelhalpern.com> In-Reply-To: <4ADCDB5B.9060707@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2009 21:48:42 -0000 Joel M. Halpern wrote: > If we want to punt, then we need to explicitly say: > "Warning, the contents of running after the commit may be different from > those of candidate before the commit. Any client expecting to perform > continued operations on the configuration is advised to perform a > get-config operation after a commit." > > At that point, the system can do whatever it wants, and the client has > been warned that unexpected things may happen. That still leaves some > very odd corner cases about constraints that reference optional leaves > that the system chooses to fill in. But, well, if we want to punt then > we punt. > I do not think leaving out the s-c-stmt is punting. There was never any intent to make s-c=true a MUST, as Randy wants. The original intent was to make sure the server MUST NOT create particular leafs. The description-stmt can still cover this case. If the client edits the running config directly, then this is more of a problem than with candidate -> commit, since a get-config is needed after every edit-config. As Randy pointed out, arbitrary, non-discoverable optional behavior is useless to the client. Yet, I see no basis to pick universal MUST/SHOULD/MAY language here at all. It seems data-model dependent to me. (description-stmt!) > Yours, > Joel > Andy From mbj@tail-f.com Tue Oct 20 01:14: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 1BF373A68A5 for ; Tue, 20 Oct 2009 01:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 I1nNw-7a2UzF for ; Tue, 20 Oct 2009 01:14: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 427AD3A6767 for ; Tue, 20 Oct 2009 01:14:27 -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 B18DB61600D; Tue, 20 Oct 2009 10:14:33 +0200 (CEST) Date: Tue, 20 Oct 2009 10:14:33 +0200 (CEST) Message-Id: <20091020.101433.66017270.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ADCDE70.4020008@netconfcentral.com> References: <4ADCD329.3000502@netconfcentral.com> <4ADCDB5B.9060707@joelhalpern.com> <4ADCDE70.4020008@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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 08:14:28 -0000 Andy Bierman wrote: > Joel M. Halpern wrote: > > If we want to punt, then we need to explicitly say: > > "Warning, the contents of running after the commit may be different from > > those of candidate before the commit. Any client expecting to perform > > continued operations on the configuration is advised to perform a > > get-config operation after a commit." > > > > At that point, the system can do whatever it wants, and the client has > > been warned that unexpected things may happen. That still leaves some > > very odd corner cases about constraints that reference optional leaves > > that the system chooses to fill in. But, well, if we want to punt then > > we punt. > > > > I do not think leaving out the s-c-stmt is punting. > There was never any intent to make s-c=true a MUST, > as Randy wants. The original intent was to make sure > the server MUST NOT create particular leafs. > The description-stmt can still cover this case. So, instead of marking the leafs that the client might have to refetch, you want to do it the other way around? > As Randy pointed out, arbitrary, non-discoverable optional behavior > is useless to the client. Yet, I see no basis to > pick universal MUST/SHOULD/MAY language here at all. It seems > data-model dependent to me. (description-stmt!) Do we agree it is data-model dependent (not implementation dependent)? We should optmize for the common case. So if we don't want to introduce s-c, we could use the description statement for this, but be explicit about it in the spec. I.e. say that the server MUST NOT create/delete/modify any config data unless dictated by the data model (in the description statement). /martin From balazs.lengyel@ericsson.com Tue Oct 20 02:57: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 D3A773A67E1 for ; Tue, 20 Oct 2009 02:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohLnKpq1ZFga for ; Tue, 20 Oct 2009 02:57:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E27E73A6927 for ; Tue, 20 Oct 2009 02:57:53 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-4f-4add89a889c7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 44.BA.24026.8A98DDA4; Tue, 20 Oct 2009 11:58:00 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:57:04 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:57:04 +0200 Message-ID: <4ADD896F.40301@ericsson.com> Date: Tue, 20 Oct 2009 11:57:03 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netmod@ietf.org References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> <4AD93D47.9040303@joelhalpern.com> In-Reply-To: <4AD93D47.9040303@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 09:57:04.0475 (UTC) FILETIME=[AD5352B0:01CA516B] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 09:57:54 -0000 Hello, Some general comments about system creatable from a late comer: - system-created should be part of the validation e.g. unique, must, ... - can you mark a leaf-list as system-creatable? I assume yes - mandatory should be allowed for system-created as Andy proposed, meaning the system MUST create the leaf - Ericsson is already using system-created list entries all over our models (OK today they are not YANG models, but the concept is the same). I mentally visualize this them as created by an autoconfig system using the NETCONF interface internally. This is not the best method, but OK Balazs From balazs.lengyel@ericsson.com Tue Oct 20 03:20: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 17E463A6832 for ; Tue, 20 Oct 2009 03:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQdgPYeprHPO for ; Tue, 20 Oct 2009 03:20:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 126FC3A6821 for ; Tue, 20 Oct 2009 03:20:55 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-79-4add8f0e0909 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 22.CC.24026.E0F8DDA4; Tue, 20 Oct 2009 12:21:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 12:21:01 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 12:21:01 +0200 Message-ID: <4ADD8F0D.2080607@ericsson.com> Date: Tue, 20 Oct 2009 12:21:01 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Martin Bjorklund References: <4ADCD329.3000502@netconfcentral.com> <4ADCDB5B.9060707@joelhalpern.com> <4ADCDE70.4020008@netconfcentral.com> <20091020.101433.66017270.mbj@tail-f.com> In-Reply-To: <20091020.101433.66017270.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 10:21:01.0423 (UTC) FILETIME=[05D02FF0:01CA516F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 10:20:57 -0000 On 10/20/09 10:14, Martin Bjorklund wrote: > We should optmize for the common case. So if we don't want to > introduce s-c, we could use the description statement for this, but be > explicit about it in the spec. I.e. say that the server MUST NOT > create/delete/modify any config data unless dictated by the data model > (in the description statement). > So auto-configuration would not be allowed? I assume you are allowed to put a management app on your node, that can use the Netconf interface to configure the node itself. Also as we are in a multi-user environment, the configuration can be changed between operations by another user, so such a MUST NOT CHANGE rules won't protect you really. Balazs From phil@juniper.net Tue Oct 20 06: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 1D96F3A67E4 for ; Tue, 20 Oct 2009 06:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 Yj29F8wCNOBG for ; Tue, 20 Oct 2009 06:32:06 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 6BA493A67CF for ; Tue, 20 Oct 2009 06:32:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSt273SJyT/zB2PRZ0FFYM8dbV4p9Tm7c@postini.com; Tue, 20 Oct 2009 06:32: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.375.2; Tue, 20 Oct 2009 06:27:46 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 06:27:47 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 06:27:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 06:27:46 -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 n9KDRjj57749; Tue, 20 Oct 2009 06:27:45 -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 n9KDEpYg045363; Tue, 20 Oct 2009 13:14:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910201314.n9KDEpYg045363@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4ADD896F.40301@ericsson.com> Date: Tue, 20 Oct 2009 09:14:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Oct 2009 13:27:46.0289 (UTC) FILETIME=[1C6F0E10:01CA5189] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 13:32:08 -0000 Balazs Lengyel writes: >- Ericsson is already using system-created list entries all over our models (OK today th >ey are >not YANG models, but the concept is the same). I mentally visualize this them as created > by an >autoconfig system using the NETCONF interface internally. This is not the best method, b >ut OK Are your list entries more "initial" or "default" configuration than "s-c" config? Are they merely the initial contents of the configuration, or will they be system created at various points in the lifespan of the device? In JUNOS, we have "factory default" config that is loaded when the box boots up with no config, but I consider this distinct from "s-c" leafs, since "s-c" can appear during an edit-config or commit-config operation. Thanks, Phil From balazs.lengyel@ericsson.com Tue Oct 20 06:56: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 E850F3A69DA for ; Tue, 20 Oct 2009 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CU8eBTHtYns for ; Tue, 20 Oct 2009 06:56:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DD7613A69BF for ; Tue, 20 Oct 2009 06:56:24 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-39-4addc18e4578 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A7.B2.24026.E81CDDA4; Tue, 20 Oct 2009 15:56:31 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:56:25 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:56:24 +0200 Message-ID: <4ADDC188.2060205@ericsson.com> Date: Tue, 20 Oct 2009 15:56:24 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Phil Shafer References: <200910201314.n9KDEpYg045363@idle.juniper.net> In-Reply-To: <200910201314.n9KDEpYg045363@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 13:56:24.0672 (UTC) FILETIME=[1CAB7E00:01CA518D] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 13:56:26 -0000 Hello Phil, Most of them are factory default/initial, but in our system any list ("managed object") can be marked as system created, meaning that it will be created once it's parent list (object) is in place. E.g. When a 155 Mbit SDH interface is created an SDH VC-4 path layer is automatically created within. Balazs On 10/20/09 15:14, Phil Shafer wrote: > Balazs Lengyel writes: >> - Ericsson is already using system-created list entries all over our models (OK today th >> ey are >> not YANG models, but the concept is the same). I mentally visualize this them as created >> by an >> autoconfig system using the NETCONF interface internally. This is not the best method, b >> ut OK > > Are your list entries more "initial" or "default" configuration > than "s-c" config? Are they merely the initial contents of the > configuration, or will they be system created at various points > in the lifespan of the device? > > In JUNOS, we have "factory default" config that is loaded when > the box boots up with no config, but I consider this distinct > from "s-c" leafs, since "s-c" can appear during an edit-config > or commit-config operation. > > Thanks, > Phil > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Tue Oct 20 08:46: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 71AFD28C126 for ; Tue, 20 Oct 2009 08:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 bCkuvYsjZ7TR for ; Tue, 20 Oct 2009 08:45:59 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id C4D6828C0F1 for ; Tue, 20 Oct 2009 08:45:59 -0700 (PDT) Received: (qmail 40100 invoked from network); 20 Oct 2009 15:46:07 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2009 08:46:06 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6tBDnMgVM1lfX8ufXmSw40mI1WjdOrGsD6fgPzncfuEtt1Rta0wBw2vJ4MNR0Hv935bFwXfYVVqqQNoHRO3k.qgG75KEhI.ARPqmeVUNQV4aHTd3iTlzEeJGbWLYsaHw0gv5yfg9SzuqmYHiebxohCZ4L1jZgrYUoUvEooTH1QTxslg_bTxi2LxayakBG.4JLmamuPXQQJ4QneWGnaeApd.I4pZiZ2JVNJt10l0M._ypn1i3sVhi3fMZ9l8YsaZoXRz155f08zTJqsDOA.0PJ9PVFUHWr1aG X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADDDB6E.9040908@netconfcentral.com> Date: Tue, 20 Oct 2009 08:46:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Balazs Lengyel References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> <4AD93D47.9040303@joelhalpern.com> <4ADD896F.40301@ericsson.com> In-Reply-To: <4ADD896F.40301@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 15:46:00 -0000 Balazs Lengyel wrote: > Hello, > Some general comments about system creatable from a late comer: > - system-created should be part of the validation e.g. unique, must, ... This seems to be a data-model dependent issue. Validation still works, but if the server has not created the node yet, then the candidate config will not reflect what will be transferred to running during the commit. Problem? Yes. CLI Reality? Yes. > - can you mark a leaf-list as system-creatable? I assume yes > - mandatory should be allowed for system-created as Andy proposed, > meaning the system MUST create the leaf > My first interpretation of s-c mandatory was wrong. I now think it still applies, but it means the client is still responsible, not the server (server still MAY, not MUST). If what you and Randy want is important, then it shows that the s-c property is an enumeration, not a boolean. system-creatable (required, optional, not-allowed); > - Ericsson is already using system-created list entries all over our > models (OK today they are not YANG models, but the concept is the same). > I mentally visualize this them as created by an autoconfig system using > the NETCONF interface internally. This is not the best method, but OK > In implementation, the module probably checks what explicit config is already provided, and if none, sets up the hard-wired initial settings. This 'startup mode' may be an area of future standardization, but it is far outside the scope of current NETCONF specs. > Balazs Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From randy_presuhn@mindspring.com Tue Oct 20 10:13: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 9FDB13A6896 for ; Tue, 20 Oct 2009 10:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5DFrcfn1Roh for ; Tue, 20 Oct 2009 10:13:12 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 2F1293A6861 for ; Tue, 20 Oct 2009 10:12:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mRKqdcZoi0i/GGEQvyqrMp/F3lvNDG0/zax2ybTkgD5Yrj6T7MUfG7SCPLIso44a; 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 [99.55.174.129] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N0IGD-0000Dw-V8 for netmod@ietf.org; Tue, 20 Oct 2009 13:12:38 -0400 Message-ID: <000e01ca51a8$c06cecc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> <4AD93D47.9040303@joelhalpern.com><4ADD896F.40301@ericsson.com> <4ADDDB6E.9040908@netconfcentral.com> Date: Tue, 20 Oct 2009 10:14:13 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9b2afba712c8844848806abbbf83ab309350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.129 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 17:13:12 -0000 Hi - > From: "Andy Bierman" > To: "Balazs Lengyel" > Cc: > Sent: Tuesday, October 20, 2009 8:46 AM > Subject: Re: [netmod] system-creatable .... > If what you and Randy want is important, then it shows > that the s-c property is an enumeration, not a boolean. > > system-creatable (required, optional, not-allowed); ... To dispell any confusion about "what Randy wants"... *If* there is to be a system-creatable property, it should behave like this: if a client fails to supply a value, then the server MUST supply one, otherwise the creation request fails. In this sense it shares some similarity with "mandatory", but should not be confused with it. I think the enumeration/boolean question is the tip of the proverbial iceberg that is the underlying object/configuration lifecycle model we don't have. Others' points about pre-configuration, factory defaults, auto-configuration, and what happens in multi-manager situations make that clear. >From the perspective of a client, "optional" is not always distinguishable from not-allowed. Consider the multi-manager situation. (But hopefully this pathological case would be avoided by partial locking and selective commits. :-) * 0.5 However, the divergence in underlying assumptions about lifecycle leads me to think that we'll end up not doing this property until we develop a successor to yang and netconf. It's too early to nail it down now, and by the time we have enough experience with yang models to come to agreement, there will be too much diversity in deployed systems to permit standardization. Randy From andy@netconfcentral.com Tue Oct 20 11:13: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 6BEE328C158 for ; Tue, 20 Oct 2009 11:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 Dk2hJLP+u4sE for ; Tue, 20 Oct 2009 11:13:49 -0700 (PDT) Received: from n12b.bullet.mail.mud.yahoo.com (n12b.bullet.mail.mud.yahoo.com [209.191.125.179]) by core3.amsl.com (Postfix) with SMTP id 8532328C0FE for ; Tue, 20 Oct 2009 11:13:49 -0700 (PDT) Received: from [68.142.200.221] by n12.bullet.mail.mud.yahoo.com with NNFMP; 20 Oct 2009 18:13:56 -0000 Received: from [68.142.201.66] by t9.bullet.mud.yahoo.com with NNFMP; 20 Oct 2009 18:13:56 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 20 Oct 2009 18:13:55 -0000 X-Yahoo-Newman-Id: 996190.75767.bm@omp418.mail.mud.yahoo.com Received: (qmail 78329 invoked from network); 20 Oct 2009 18:13:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2009 18:13:54 -0000 X-YMail-OSG: poiRFuIVM1n0i5aIvauvwY0wAglQBgkkMnxpnpwUD0YkXaTDR_lu0ascKzrKd_23ICqf4Zl7_RBjVuqf14dPhBcj1Dln6Oh.PFwzBw.ykoVjj90gUU5vVP4VZ8jLPh.tpB_Ps4UyABeKeUy4KJGYzKu60WW.ztI3jmJ1jTHaMqr1bk9L.CWFofWjKZkIjsmI7bHZlLJuKGPiaBSp5Khjx0tVf7PuzeTL5yOTvDO_u_11ER9xZluZ8VEMv64IXUnUFzdLb3j3EtvfmounpBBWi8uBN4_IJ3o5LK3e2A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADDFE12.6060709@netconfcentral.com> Date: Tue, 20 Oct 2009 11:14:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <20091012.183346.123577726.mbj@tail-f.com> <022b01ca4ed5$e4ae28e0$6801a8c0@oemcomputer> <4AD93440.1020007@joelhalpern.com> <024301ca4ed9$46701220$6801a8c0@oemcomputer> <4AD93D47.9040303@joelhalpern.com><4ADD896F.40301@ericsson.com> <4ADDDB6E.9040908@netconfcentral.com> <000e01ca51a8$c06cecc0$6801a8c0@oemcomputer> In-Reply-To: <000e01ca51a8$c06cecc0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2009 18:13:50 -0000 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Balazs Lengyel" >> Cc: >> Sent: Tuesday, October 20, 2009 8:46 AM >> Subject: Re: [netmod] system-creatable > .... >> If what you and Randy want is important, then it shows >> that the s-c property is an enumeration, not a boolean. >> >> system-creatable (required, optional, not-allowed); > ... > > To dispell any confusion about "what Randy wants"... > > *If* there is to be a system-creatable property, it should > behave like this: if a client fails to supply a value, then > the server MUST supply one, otherwise the creation > request fails. In this sense it shares some similarity > with "mandatory", but should not be confused with it. > > I think the enumeration/boolean question is the tip of the > proverbial iceberg that is the underlying object/configuration > lifecycle model we don't have. Others' points about pre-configuration, > factory defaults, auto-configuration, and what happens in > multi-manager situations make that clear. > >>From the perspective of a client, "optional" is not always > distinguishable from not-allowed. Consider the multi-manager > situation. (But hopefully this pathological case would be > avoided by partial locking and selective commits. :-) * 0.5 > > However, the divergence in underlying assumptions about lifecycle > leads me to think that we'll end up not doing this property until > we develop a successor to yang and netconf. It's too early to > nail it down now, and by the time we have enough experience > with yang models to come to agreement, there will be too much > diversity in deployed systems to permit standardization. > Hmmm... I don't think we need to wait that long to make progress. The problem with the IETF these days is that there is no sense of urgency to get anything done. NETCONF/YANG will keep morphing via capabilities as we proceed. There is never going to be one-size-fits-all, and that's why N/Y has a chance. IMO, we have already wasted at least a year on corner-case features that will only affect the most advanced usage. Even still, there are years of 'advanced work' yet to be done. The NETCONF/NETMOD WGs will have to somehow convince other WGs, vendors, and SDOs that N/Y is a better solution that the current 'XML BCP' (write an XSD schema and create your own protocol, or just copy the XML file to the device). The first step in convincing anybody to use N/Y is to finish it. Create a stable platform and build on it over time. All NETCONF work is currently held up, waiting for YANG to be published. > Randy Andy From lhotka@cesnet.cz Wed Oct 21 00:57:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B1A3A69E1 for ; Wed, 21 Oct 2009 00:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.354, 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 vzGPuqzuBBEI for ; Wed, 21 Oct 2009 00:57:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id ED01B3A68A7 for ; Wed, 21 Oct 2009 00:57:18 -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 59BD6D80096 for ; Wed, 21 Oct 2009 09:57:26 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200910191932.n9JJWuIw035997@idle.juniper.net> References: <200910191932.n9JJWuIw035997@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 21 Oct 2009 09:57:24 +0200 Message-Id: <1256111845.5927.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 07:57:19 -0000 Phil Shafer píše v Po 19. 10. 2009 v 15:32 -0400: > "Randy Presuhn" writes: > >That's a strawman. Another alternative is to use MUST rather than > >MAY. Then the client would know exactly what to expect, and the > >requirements for the server would be unambiguous. > > If it is "MUST" the client will have to refetch the config to know > the final config. > > If it is "MAY" the client will have to refetch the config to know > the final config. But with MAY, what happens if neither the client nor the server provides a value? If the configuration parameter is needed for server operation (and I guess most are), this would result in an error condition. > > I'm missing why it needs to be MUST. What does this solve? If the > server does not create it, the client's behavior is the same. > > The idea of having edit-config and/or commit-config return a list > of created, changed, and deleted nodes seem like a better answer. > > I'm thinking we should leave s-c until we get some operational > experience. We may end up with a different answer, like a module > that augments the replies for edit-config and commit-config. I agree. Lada > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Oct 21 01:23:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDB63A6768 for ; Wed, 21 Oct 2009 01:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsSs-Az-OToV for ; Wed, 21 Oct 2009 01:23:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3E3893A657C for ; Wed, 21 Oct 2009 01:23: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 8C2F9D800C0 for ; Wed, 21 Oct 2009 10:23:31 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4ADD8F0D.2080607@ericsson.com> References: <4ADCD329.3000502@netconfcentral.com> <4ADCDB5B.9060707@joelhalpern.com> <4ADCDE70.4020008@netconfcentral.com> <20091020.101433.66017270.mbj@tail-f.com> <4ADD8F0D.2080607@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 21 Oct 2009 10:23:30 +0200 Message-Id: <1256113410.5927.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 08:23:24 -0000 Balazs Lengyel píše v Út 20. 10. 2009 v 12:21 +0200: > > On 10/20/09 10:14, Martin Bjorklund wrote: > > > We should optmize for the common case. So if we don't want to > > introduce s-c, we could use the description statement for this, but be > > explicit about it in the spec. I.e. say that the server MUST NOT > > create/delete/modify any config data unless dictated by the data model > > (in the description statement). > > > So auto-configuration would not be allowed? I assume you are allowed to put a management app on > your node, that can use the Netconf interface to configure the node itself. > > Also as we are in a multi-user environment, the configuration can be changed between operations > by another user, so such a MUST NOT CHANGE rules won't protect you really. Right, that's why I think the guarantees that s-c can potentially offer are quite weak. So I'd say we shouldn't optimize prematurely. Lada > > Balazs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Wed Oct 21 01:56: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 B7F173A6810 for ; Wed, 21 Oct 2009 01:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYgz1drM7eAq for ; Wed, 21 Oct 2009 01:56:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 96A473A680A for ; Wed, 21 Oct 2009 01:56:24 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-f4-4adeccbf3d2f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DA.FF.04191.FBCCEDA4; Wed, 21 Oct 2009 10:56:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:56:30 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:56:29 +0200 Message-ID: <4ADECCBD.60408@ericsson.com> Date: Wed, 21 Oct 2009 10:56:29 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Ladislav Lhotka References: <4ADCD329.3000502@netconfcentral.com> <4ADCDB5B.9060707@joelhalpern.com> <4ADCDE70.4020008@netconfcentral.com> <20091020.101433.66017270.mbj@tail-f.com> <4ADD8F0D.2080607@ericsson.com> <1256113410.5927.32.camel@missotis> In-Reply-To: <1256113410.5927.32.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 08:56:29.0812 (UTC) FILETIME=[614F8340:01CA522C] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 08:56:42 -0000 Hello, If we use system-created as opposed to system-creatable this helps, as you know that the system will definitevly create the value unless provided by the client. The manager does not need to create it. One possible way to mark this is to use mandatory, but maybe "system-supplies-default" is better. Balazs From mbj@tail-f.com Wed Oct 21 02:00: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 5075D3A6883 for ; Wed, 21 Oct 2009 02:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHszBuDJsTNj for ; Wed, 21 Oct 2009 02:00:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 62BE53A6882 for ; Wed, 21 Oct 2009 02:00:29 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B591616002; Wed, 21 Oct 2009 11:00:37 +0200 (CEST) Date: Wed, 21 Oct 2009 11:00:36 +0200 (CEST) Message-Id: <20091021.110036.94278076.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1256113410.5927.32.camel@missotis> References: <20091020.101433.66017270.mbj@tail-f.com> <4ADD8F0D.2080607@ericsson.com> <1256113410.5927.32.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] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 09:00:30 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQmFsYXpzIExlbmd5 ZWwgcMOtxaFlIHYgw5p0IDIwLiAxMC4gMjAwOSB2IDEyOjIxICswMjAwOg0KPiA+IA0KPiA+IE9u IDEwLzIwLzA5IDEwOjE0LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+IA0KPiA+ID4gV2Ug c2hvdWxkIG9wdG1pemUgZm9yIHRoZSBjb21tb24gY2FzZS4gIFNvIGlmIHdlIGRvbid0IHdhbnQg dG8NCj4gPiA+IGludHJvZHVjZSBzLWMsIHdlIGNvdWxkIHVzZSB0aGUgZGVzY3JpcHRpb24gc3Rh dGVtZW50IGZvciB0aGlzLCBidXQgYmUNCj4gPiA+IGV4cGxpY2l0IGFib3V0IGl0IGluIHRoZSBz cGVjLiAgSS5lLiBzYXkgdGhhdCB0aGUgc2VydmVyIE1VU1QgTk9UDQo+ID4gPiBjcmVhdGUvZGVs ZXRlL21vZGlmeSBhbnkgY29uZmlnIGRhdGEgdW5sZXNzIGRpY3RhdGVkIGJ5IHRoZSBkYXRhIG1v ZGVsDQo+ID4gPiAoaW4gdGhlIGRlc2NyaXB0aW9uIHN0YXRlbWVudCkuDQo+ID4gPg0KPiA+IFNv IGF1dG8tY29uZmlndXJhdGlvbiB3b3VsZCBub3QgYmUgYWxsb3dlZD8gSSBhc3N1bWUgeW91IGFy ZSBhbGxvd2VkIHRvIHB1dCBhDQo+ID4gbWFuYWdlbWVudCBhcHAgb24NCj4gPiB5b3VyIG5vZGUs IHRoYXQgY2FuIHVzZSB0aGUgTmV0Y29uZiBpbnRlcmZhY2UgdG8gY29uZmlndXJlIHRoZSBub2Rl IGl0c2VsZi4NCj4gPiANCj4gPiBBbHNvIGFzIHdlIGFyZSBpbiBhIG11bHRpLXVzZXIgZW52aXJv bm1lbnQsIHRoZSBjb25maWd1cmF0aW9uIGNhbiBiZSBjaGFuZ2VkDQo+ID4gYmV0d2VlbiBvcGVy YXRpb25zDQo+ID4gYnkgYW5vdGhlciB1c2VyLCBzbyBzdWNoIGEgTVVTVCBOT1QgQ0hBTkdFIHJ1 bGVzIHdvbid0IHByb3RlY3QgeW91IHJlYWxseS4NCj4gDQo+IFJpZ2h0LCB0aGF0J3Mgd2h5IEkg dGhpbmsgdGhlIGd1YXJhbnRlZXMgdGhhdCBzLWMgY2FuIHBvdGVudGlhbGx5IG9mZmVyDQo+IGFy ZSBxdWl0ZSB3ZWFrLiBTbyBJJ2Qgc2F5IHdlIHNob3VsZG4ndCBvcHRpbWl6ZSBwcmVtYXR1cmVs eS4NCg0KSSB0aGluayB0aGVyZSBpcyBhIHJhdGhlciBiaWcgZGlmZmVyZW5jZS4gIFdoZW4gdGhl IHNlcnZlciBjcmVhdGVzIHMtYw0KbGVhZnMsIGl0IGRvZXMgaXQgYXMgcGFydCBvZiBhIGNsaWVu dCBvcGVyYXRpb24gKGNvbW1pdCBvcg0KZWRpdC1jb25maWcpLCBfZXZlbiBpZiB0aGUgY2xpZW50 IGhhcyBhIGxvY2tfLiAgQW55dGhpbmcgdGhhdCBpbXBsZW1lbnRzDQpjaGFuZ2VzIGFzIGEgY2xp ZW50IChldmVuIGlmIGl0IGlzIGEgImJ1aWx0LWluIGNsaWVudCIgZXhlY3V0aW5nIG9uDQp0aGUg ZGV2aWNlKSwgY2Fubm90IG1ha2UgYW55IGNoYW5nZXMgaWYgdGhlcmUgaXMgYSBsb2NrLiAgIE1h cmtpbmcNCmxlYWZzIGFzIHMtYyB0ZWxscyB0aGUgY2xpZW50IHdoYXQgdG8gZXhwZWN0IGFsc28g d2hlbiBpdCBoYXMgdGhlDQpsb2NrLg0KDQoNCi9tYXJ0aW4NCg== From balazs.lengyel@ericsson.com Wed Oct 21 02:58: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 0B0323A68F6 for ; Wed, 21 Oct 2009 02:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-NuNI4aNiY0 for ; Wed, 21 Oct 2009 02:58:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CF5173A68A7 for ; Wed, 21 Oct 2009 02:58:14 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-4c-4adedb3e6cd0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 6F.F5.04191.E3BDEDA4; Wed, 21 Oct 2009 11:58:22 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 11:58:21 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 11:58:21 +0200 Message-ID: <4ADEDB3C.8060102@ericsson.com> Date: Wed, 21 Oct 2009 11:58:20 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Martin Bjorklund References: <20091020.101433.66017270.mbj@tail-f.com> <4ADD8F0D.2080607@ericsson.com> <1256113410.5927.32.camel@missotis> <20091021.110036.94278076.mbj@tail-f.com> In-Reply-To: <20091021.110036.94278076.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Oct 2009 09:58:21.0168 (UTC) FILETIME=[05737F00:01CA5235] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 09:58:16 -0000 On 10/21/09 11:00, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Balazs Lengyel píše v Út 20. 10. 2009 v 12:21 +0200: >>> >>> On 10/20/09 10:14, Martin Bjorklund wrote: >>> >>>> We should optmize for the common case. So if we don't want to >>>> introduce s-c, we could use the description statement for this, but be >>>> explicit about it in the spec. I.e. say that the server MUST NOT >>>> create/delete/modify any config data unless dictated by the data model >>>> (in the description statement). >>>> >>> So auto-configuration would not be allowed? I assume you are allowed to put a >>> management app on >>> your node, that can use the Netconf interface to configure the node itself. >>> >>> Also as we are in a multi-user environment, the configuration can be changed >>> between operations >>> by another user, so such a MUST NOT CHANGE rules won't protect you really. >> >> Right, that's why I think the guarantees that s-c can potentially offer >> are quite weak. So I'd say we shouldn't optimize prematurely. > > I think there is a rather big difference. When the server creates s-c > leafs, it does it as part of a client operation (commit or > edit-config), _even if the client has a lock_. Anything that implements > changes as a client (even if it is a "built-in client" executing on > the device), cannot make any changes if there is a lock. Marking > leafs as s-c tells the client what to expect also when it has the > lock. > > Yes. Also s-c can also create stuff _during_ an operation of another client while the built-in client is not allowed to do that. I agree s-c is more powerful. Personally I would like to see a broad s-c; for leafs, containers, lists, leaf-list, with modifications (like Kent). But I can accept if that is YANG 2.0 and Ericsson will just have some deviations/extensions. Balazs From balazs.lengyel@ericsson.com Wed Oct 21 02:58: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 4029C3A695C for ; Wed, 21 Oct 2009 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVmEstuQr9mJ for ; Wed, 21 Oct 2009 02:58:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4C9D53A68A7 for ; Wed, 21 Oct 2009 02:58:56 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-6e-4adedb676058 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A0.1B.24026.76BDEDA4; Wed, 21 Oct 2009 11:59:03 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 11:58:57 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 11:58:57 +0200 Message-ID: <4ADEDB61.3010200@ericsson.com> Date: Wed, 21 Oct 2009 11:58:57 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Martin Bjorklund References: <20091020.101433.66017270.mbj@tail-f.com> <4ADD8F0D.2080607@ericsson.com> <1256113410.5927.32.camel@missotis> <20091021.110036.94278076.mbj@tail-f.com> In-Reply-To: <20091021.110036.94278076.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 09:58:57.0474 (UTC) FILETIME=[1B175A20:01CA5235] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 09:58:57 -0000 Hello, Is it proposed to allow s-c for leaf-lists? Balazs From cfinss@dial.pipex.com Wed Oct 21 03:56: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 F2D123A67F8 for ; Wed, 21 Oct 2009 03:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8VyGJaXB9Da for ; Wed, 21 Oct 2009 03:56:25 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 955FE3A67B5 for ; Wed, 21 Oct 2009 03:56:25 -0700 (PDT) X-Trace: 149315703/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.245/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.245 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAJ+F3ko+vGn1/2dsb2JhbACDJEKNJMk1CoQnBA X-IronPort-AV: E=Sophos;i="4.44,596,1249254000"; d="scan'208";a="149315703" X-IP-Direction: IN Received: from 1cust245.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.245]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Oct 2009 11:56:32 +0100 Message-ID: <001601ca5234$6d6cbbe0$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , "Martin Bjorklund" References: <20091019111221.GD4765@elstar.local><20091019.133706.19084232.mbj@tail-f.com><1255953369.22426.49.camel@missotis><20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> Date: Wed, 21 Oct 2009 11:53:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 10:56:26 -0000 ---- Original Message ----- From: "Ladislav Lhotka" Sent: Monday, October 19, 2009 2:26 PM > Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: > > Ladislav Lhotka wrote: > > > I don't think s-c leafs are worth these complications. > > > > So what is your proposal? > > Keep this issue outside of YANG as implementation dependent. The three > types of leafs currently are: > > 1. Mandatory - must be present, otherwise the configuration is not > valid. and I assume must be created by client, system has no choice > 2. Optional, no default - needn't be present, the system must be > able to operate without them. so I assume may be created by client else not present (in any sense, not visible in any retrieval operation) > 3. Optional, default specified in DM - needn't be present, in which > case the server must behave exactly as if they are present and have > the default value. so may be created by client if not must be 'created' with default value by system (and so visible in some form of retrieval) which leaves out two possible use cases (looking back to see what came up in earlier discussions) 4 may be created by client else may be created by system else not present (so may be visible in some form of retrieval if system did create it) 5 may be created by client else must be created by system but data model cannot suggest a suitable value (visible in some form of retrieval) Tom Petch > Do we need anything else? > > Lada > > > > > > > /martin > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > From lhotka@cesnet.cz Wed Oct 21 04:00:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951DE3A68A4 for ; Wed, 21 Oct 2009 04:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=0.389, 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 Icq5-FfO8a95 for ; Wed, 21 Oct 2009 04:00:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C73D13A6891 for ; Wed, 21 Oct 2009 04:00:22 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AB31DD800E8; Wed, 21 Oct 2009 13:00:30 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091021.110036.94278076.mbj@tail-f.com> References: <20091020.101433.66017270.mbj@tail-f.com> <4ADD8F0D.2080607@ericsson.com> <1256113410.5927.32.camel@missotis> <20091021.110036.94278076.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 21 Oct 2009 13:00:28 +0200 Message-Id: <1256122828.5927.61.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 11:00:23 -0000 Martin Bjorklund píše v St 21. 10. 2009 v 11:00 +0200: > > Right, that's why I think the guarantees that s-c can potentially offer > > are quite weak. So I'd say we shouldn't optimize prematurely. > > I think there is a rather big difference. When the server creates s-c > leafs, it does it as part of a client operation (commit or > edit-config), _even if the client has a lock_. Anything that implements > changes as a client (even if it is a "built-in client" executing on > the device), cannot make any changes if there is a lock. Marking > leafs as s-c tells the client what to expect also when it has the > lock. Yes, I understand this, but does it really make a difference? Consider this typical scenario: lock perform an operation unlock If the server runs a "post-operation" script immediately after the unlock and that script adds any non-s-c values, how does it help the client to know that the new leafs were NOT declared as s-c in the data model? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf2@dial.pipex.com Wed Oct 21 03:56: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 8F5BB3A67B5 for ; Wed, 21 Oct 2009 03:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfR8YpDKsFGr for ; Wed, 21 Oct 2009 03:56:03 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 6F89E3A6843 for ; Wed, 21 Oct 2009 03:56:03 -0700 (PDT) X-Trace: 294528846/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.245/None/ietf2@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.245 X-IP-MAIL-FROM: ietf2@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFABeG3ko+vGn1/2dsb2JhbACDJEKNJMk5CoQnBA X-IronPort-AV: E=Sophos;i="4.44,596,1249254000"; d="scan'208";a="294528846" X-IP-Direction: IN Received: from 1cust245.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.245]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Oct 2009 11:56:08 +0100 Message-ID: <001001ca5234$5f04af40$0601a8c0@allison> From: "t.petch" To: "Ladislav Lhotka" , "Martin Bjorklund" References: <20091019111221.GD4765@elstar.local><20091019.133706.19084232.mbj@tail-f.com><1255953369.22426.49.camel@missotis><20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> Date: Wed, 21 Oct 2009 11:52:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Wed, 21 Oct 2009 04:25:31 -0700 Cc: netmod@ietf.org Subject: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "t.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 10:56:04 -0000 ---- Original Message ----- From: "Ladislav Lhotka" Sent: Monday, October 19, 2009 2:26 PM > Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: > > Ladislav Lhotka wrote: > > > I don't think s-c leafs are worth these complications. > > > > So what is your proposal? > > Keep this issue outside of YANG as implementation dependent. The three > types of leafs currently are: > > 1. Mandatory - must be present, otherwise the configuration is not > valid. and I assume must be created by client, system has no choice > 2. Optional, no default - needn't be present, the system must be > able to operate without them. so I assume may be created by client else not present (in any sense, not visible in any retrieval operation) > 3. Optional, default specified in DM - needn't be present, in which > case the server must behave exactly as if they are present and have > the default value. so may be created by client if not must be 'created' with default value by system (and so visible in some form of retrieval) which leaves out two possible use cases (looking back to see what came up in earlier discussions) 4 may be created by client else may be created by system else not present (so may be visible in some form of retrieval if system did create it) 5 may be created by client else must be created by system but data model cannot suggest a suitable value (visible in some form of retrieval) Tom Petch > Do we need anything else? > > Lada > > > > > > > /martin > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > From balazs.lengyel@ericsson.com Wed Oct 21 04:47: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 420353A6A4A for ; Wed, 21 Oct 2009 04:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of+QVhsU7wcw for ; Wed, 21 Oct 2009 04:47:26 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5D3953A6A30 for ; Wed, 21 Oct 2009 04:47:26 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-9a-4adef4d6250c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B3.48.08816.6D4FEDA4; Wed, 21 Oct 2009 13:47:34 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 13:47:33 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 13:47:32 +0200 Message-ID: <4ADEF4D4.5000709@ericsson.com> Date: Wed, 21 Oct 2009 13:47:32 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netmod@ietf.org References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 11:47:32.0999 (UTC) FILETIME=[46A59170:01CA5244] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 11:47:27 -0000 Hello, I am rejoining after a long pause so I am not up to date with all emails, still I would like to reiterate one point: Earlier it was intentionally left open whether a leaf not set by the client, which has a default value exists in the database or not. For many existing node it does exist in the database (e.g. Ericsson), for other it does not (e.g. Juniper). We should not try to specify in YANG if it exists or not. Balazs From lhotka@cesnet.cz Wed Oct 21 04:54: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 DF9053A6874 for ; Wed, 21 Oct 2009 04:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=0.372, 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 cxnU2jpZab9S for ; Wed, 21 Oct 2009 04:54:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C85703A681B for ; Wed, 21 Oct 2009 04:54:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 45A73D800C0; Wed, 21 Oct 2009 13:54:19 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <001601ca5234$6d6cbbe0$0601a8c0@allison> References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> <20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> <001601ca5234$6d6cbbe0$0601a8c0@allison> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 21 Oct 2009 13:54:17 +0200 Message-Id: <1256126057.5927.104.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 11:54:12 -0000 tom.petch píše v St 21. 10. 2009 v 11:53 +0200: > ---- Original Message ----- > From: "Ladislav Lhotka" > Sent: Monday, October 19, 2009 2:26 PM > > > Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: > > > Ladislav Lhotka wrote: > > > > I don't think s-c leafs are worth these complications. > > > > > > So what is your proposal? > > > > Keep this issue outside of YANG as implementation dependent. The three > > types of leafs currently are: > > > > 1. Mandatory - must be present, otherwise the configuration is not > > valid. > > and I assume must be created by client, system has no choice It depends on the point(s) in the workflow where validity is checked and enforced. If it is at commit time, both client and server have a chance to supply the mandatory leaf. However, YANG only says the leaf must be there when the configuration is required to be valid, nothing more. So I think this also covers your case 5. > > > 2. Optional, no default - needn't be present, the system must be > > able to operate without them. > > so I assume may be created by client else not present (in any sense, not > visible in any retrieval operation) Yes. > > > 3. Optional, default specified in DM - needn't be present, in which > > case the server must behave exactly as if they are present and have > > the default value. > > so may be created by client if not must be 'created' with default value > by system (and so visible in some form of retrieval) Yes, with-defaults=report-all. > > which leaves out two possible use cases (looking back to see what > came up in earlier discussions) > > 4 may be created by client else may be created by system else not present > (so may be visible in some form of retrieval if system did create it) This case doesn't make much sense to me, unless the value of the leaf is completely irrelevant. > > 5 may be created by client else must be created by system but data model > cannot suggest a suitable value (visible in some form of retrieval) > Lada > Tom Petch > > > Do we need anything else? > > > > Lada > > > > > > > > > > > /martin > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Wed Oct 21 07:15: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 5FB4B3A6930 for ; Wed, 21 Oct 2009 07:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjEnhyjJIOZF for ; Wed, 21 Oct 2009 07:15:28 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA3B3A68DF for ; Wed, 21 Oct 2009 07:15:28 -0700 (PDT) X-Trace: 205808654/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.4/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.4 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAAe03ko+vGQE/2dsb2JhbACDJCcbjSTKfQqCRQqBWAQ X-IronPort-AV: E=Sophos;i="4.44,597,1249254000"; d="scan'208";a="205808654" X-IP-Direction: IN Received: from 1cust4.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.4]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Oct 2009 15:15:33 +0100 Message-ID: <000201ca5250$3b0f4c00$0601a8c0@allison> From: "tom.petch" To: "Joel M. Halpern" , "Randy Presuhn" , "NETMOD Working Group" References: <200910191932.n9JJWuIw035997@idle.juniper.net><00e601ca50f9$e7a7e7e0$6801a8c0@oemcomputer><4ADCCC4C.1020405@joelhalpern.com><00f401ca50fc$ee0276c0$6801a8c0@oemcomputer> <4ADCD48B.1060307@joelhalpern.com> Date: Wed, 21 Oct 2009 14:38:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:15:29 -0000 ----- Original Message ----- From: "Joel M. Halpern" Sent: Monday, October 19, 2009 11:05 PM > Part of my problem may be a failure of imagination. > I have trouble imagining a field for which > the data model requires that the field exist > the system can reliably know the value > and the client can not reasonably be expected to know the value. Joel Gerhard said that this was a use case for IPFIX at the back end of August last year. As one of the few people to have used YANG in anger, I take that as a clear requirement. I disagree with the current formulation of system-creatable on this (I want MUST and not MAY), on restricting the system to be able to create only nodes with system-creatable (that for me came from nowhere) and with the leaf only existing after validation and so not being available to any of the extra logic that YANG adds:-( So as currently formulated, I find it of no additional value. Tom Petch > > The userid case is not actually a good example of this, because the > system may not need userids. As something the system may create, if it > needs them, it makes sense to me. As a global requirement that the user > model MUST have valid userids, I don't follow it. (Requiring that IDs, > if they are used, be unique, makes sense because good security practice > says to avoid confusing users.) > > We can give up on all notion of knowing what the system may modify, and > take the view that since multi-manager means that you can never know > anyway, the client effectively must refresh his model before beginning > any operation, and after any commit if operation is continuing. But > folks have repeatedly said that thye do not want clients to have to > fetch everything in sight. (There are meaningful alternatives for > dealing with multi-manager, but they will not cope with system-created > very well.) > > Yours, > Joel > > Randy Presuhn wrote: > > Hi - > > > >> From: "Joel M. Halpern" > >> To: "Randy Presuhn" > >> Sent: Monday, October 19, 2009 1:30 PM > >> Subject: Re: [netmod] system-creatable > >> > >> I do not follow your reasoning about the relationship between whether > >> S-C is a must and the user-id example. > >> > >> If user-id is mandatory, then the client better be prepared to create it. > > > > It is not mandatory, at least not in the Yang sense. > > > >> If user-id is optional, then clients do not have to create it if they > >> don't want to. > > > > Agreed. > > > >> If user-id is optional and system-createable, then the client is not > >> required to create it, but the client should be aware that the system > >> may choose to assign it a value, for example, if it uses userids. > > > > replace "may" with "MUST". > > > >> I suppose we could add the mixed case of a leaf declared as both > >> mandatory and system-createable, to indicate that the system is required > >> to create it if the client does not. The verbiage would be pretty > >> strange, but at least we don't use the optional case that I think is useful. > > > > I don't want to go there. > > > > I think the confusion may come from the shorthand. When I say > > "MAY" and "MUST" here, I am referring to the replacement of > > the "MAY" in the proposed text with "MUST" The "MAYs" in the > > proposed text all had to do with *server* requirements, not > > client requirements. > > > > Randy > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From phil@juniper.net Wed Oct 21 07:20: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 12D8A3A6955 for ; Wed, 21 Oct 2009 07:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 SIeBhnX+DAoL for ; Wed, 21 Oct 2009 07:20:21 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 0CC023A6930 for ; Wed, 21 Oct 2009 07:20:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSt8YpVieHXBQFJWsynR3GTf8cT3c9h2A@postini.com; Wed, 21 Oct 2009 07:20:30 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 21 Oct 2009 07:12:07 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:12:08 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:12:06 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:12:04 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9LEC4j80846; Wed, 21 Oct 2009 07:12:04 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9LDx8nd061432; Wed, 21 Oct 2009 13:59:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910211359.n9LDx8nd061432@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1256111845.5927.16.camel@missotis> Date: Wed, 21 Oct 2009 09:59:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Oct 2009 14:12:04.0738 (UTC) FILETIME=[7767EE20:01CA5258] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 14:20:22 -0000 Ladislav Lhotka writes: >But with MAY, what happens if neither the client nor the server provides >a value? If the configuration parameter is needed for server operation >(and I guess most are), this would result in an error condition. If the server know that it the leaf must have a value, then it will do The Right Thing and provide it. Thanks, Phil From lhotka@cesnet.cz Wed Oct 21 07:43:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D1F3A689E for ; Wed, 21 Oct 2009 07:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-0.388, 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 iWhQFa2HmUIS for ; Wed, 21 Oct 2009 07:43:21 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A40A93A6819 for ; Wed, 21 Oct 2009 07:43:21 -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 A65FCD800C0; Wed, 21 Oct 2009 16:43:29 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200910211359.n9LDx8nd061432@idle.juniper.net> References: <200910211359.n9LDx8nd061432@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 21 Oct 2009 16:43:28 +0200 Message-Id: <1256136208.5927.129.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 14:43:23 -0000 Phil Shafer píše v St 21. 10. 2009 v 09:59 -0400: > Ladislav Lhotka writes: > >But with MAY, what happens if neither the client nor the server provides > >a value? If the configuration parameter is needed for server operation > >(and I guess most are), this would result in an error condition. > > If the server know that it the leaf must have a value, then > it will do The Right Thing and provide it. How does the client know that the server knows? :-) The subsystem in the server that operates on configuration data based on client requests needn't be integrated with the subsystem that reads the configuration and modifies server behaviour. The role of the former can be just to make sure that the commited configuration is valid according to the data model. So I guess this boils down to the question whether the configuration without the s-c leaf is valid or not. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Oct 21 08:12:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E2D3A689E for ; Wed, 21 Oct 2009 08:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 N84cqAGQZF2c for ; Wed, 21 Oct 2009 08:12:04 -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 2CC753A6878 for ; Wed, 21 Oct 2009 08:12:04 -0700 (PDT) Received: from [68.142.200.227] by n14.bullet.mail.mud.yahoo.com with NNFMP; 21 Oct 2009 15:12:13 -0000 Received: from [68.142.201.245] by t8.bullet.mud.yahoo.com with NNFMP; 21 Oct 2009 15:12:13 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 21 Oct 2009 15:12:13 -0000 X-Yahoo-Newman-Id: 143063.69380.bm@omp406.mail.mud.yahoo.com Received: (qmail 91170 invoked from network); 21 Oct 2009 15:12:12 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 21 Oct 2009 08:12:12 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: RQ3h3pkVM1nMaJt9kz8RXroRp9uv3prGgM2U7ZMfeUHdTysBjp9LndaAcmqT9zbXeORKHMEqWwV0GnxtedXpRhFPsEGSFkEJnWGorpi_u3gu7aQ8m.2FTOOw5eLxXaxwrWwaTDHGzFKUmh1SidIYs0yiaL9xKR4XG7fSG.r0D74E5LRWn3dRMW5lZfdDPmgYSQFRIXcKcqOkpm_ij3QgZ4RNzeAqlsXGLkWB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADF2484.7050505@netconfcentral.com> Date: Wed, 21 Oct 2009 08:11:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Balazs Lengyel References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.com> <4ADEF4D4.5000709@ericsson.com> In-Reply-To: <4ADEF4D4.5000709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 15:12:05 -0000 Balazs Lengyel wrote: > Hello, > I am rejoining after a long pause so I am not up to date with all > emails, still I would like to reiterate one point: > > Earlier it was intentionally left open whether a leaf not set by the > client, which has a default value exists in the database or not. For > many existing node it does exist in the database (e.g. Ericsson), for > other it does not (e.g. Juniper). We should not try to specify in YANG > if it exists or not. > We agreed that the validation is done against a conceptual XML document containing the explicit nodes plus the YANG defaults. Now there is some complications for the candidate because some s-c leafs cannot appear in candidate until after the commit. Unless the leaf contains the YANG default value, it is not a default -- it is an explicit leaf. > Balazs Andy From balazs.lengyel@ericsson.com Wed Oct 21 09:02:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8398D3A6844; Wed, 21 Oct 2009 09:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WrCuhU7GFZY; Wed, 21 Oct 2009 09:02:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 30F153A68CC; Wed, 21 Oct 2009 09:02:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-09-4adf309147cf Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 06.C5.04191.1903FDA4; Wed, 21 Oct 2009 18:02:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:02:25 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:02:24 +0200 Message-ID: <4ADF3090.7090903@ericsson.com> Date: Wed, 21 Oct 2009 18:02:24 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Phil Shafer References: <200909011930.n81JU7WS093379@idle.juniper.net> In-Reply-To: <200909011930.n81JU7WS093379@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 16:02:24.0779 (UTC) FILETIME=[E14205B0:01CA5267] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 16:02:19 -0000 Hello, I have the feeling that we should make with-defaults MANDATORY for all nodes using YANG. (Currently report-all is the only mode that is mandatory to support in with-defaults.) Opinions? Balazs On 09/01/09 21:30, Phil Shafer wrote: > Andy Bierman writes: >> You want to force your way of thinking on everybody >> else by insisting that your server does not need >> to ever make the full data-set available to any client, >> or to even let the client know what sort of 'server-pruning' >> is being done. > > The current scheme in YANG allows the server to behave in any of > the three styles listed in the with-defaults draft. We have > sufficient flexibility to allow you to work the way you want, and > to allow others to work the way they work. This is good. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Wed Oct 21 09:08:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA0C3A6959 for ; Wed, 21 Oct 2009 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 Mwqr62KpiFoC for ; Wed, 21 Oct 2009 09:08:47 -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 760053A69AE for ; Wed, 21 Oct 2009 09:08:47 -0700 (PDT) Received: (qmail 97786 invoked from network); 21 Oct 2009 16:08:54 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 21 Oct 2009 09:08:54 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: SPTXSJAVM1lj4MPEKNdRhWAjD9RrX1CcXrNS3j3RUsrOZ2NQP3j_UQnK6W9L9SXAR5qyZudYiqO_l0W1AVpLTMbLfI0JSs0fDrSl70hACoo_L5YV7HUu2yd2E16clhkPNmlxV77moV6jWe5sdvSzo6s5UPDL51gV29m_KDcLlr__EdF04o48WsoQ6epACpeaU.rmTAb8HSvEc2xmGu6FN1lI1UcKUQ4B_JAKIMorzhzyTEZREFIDLO7ZNSAPU7y7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADF324A.60207@netconfcentral.com> Date: Wed, 21 Oct 2009 09:09:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200910211359.n9LDx8nd061432@idle.juniper.net> <1256136208.5927.129.camel@missotis> In-Reply-To: <1256136208.5927.129.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 16:08:48 -0000 Ladislav Lhotka wrote: > Phil Shafer píše v St 21. 10. 2009 v 09:59 -0400: >> Ladislav Lhotka writes: >>> But with MAY, what happens if neither the client nor the server provides >>> a value? If the configuration parameter is needed for server operation >>> (and I guess most are), this would result in an error condition. >> If the server know that it the leaf must have a value, then >> it will do The Right Thing and provide it. > > How does the client know that the server knows? :-) The subsystem in the > server that operates on configuration data based on client requests > needn't be integrated with the subsystem that reads the configuration > and modifies server behaviour. The role of the former can be just to > make sure that the commited configuration is valid according to the data > model. > > So I guess this boils down to the question whether the configuration > without the s-c leaf is valid or not. > This is why the mandatory-stmt is still valid, even for leafs that have the s-c=true property. The client knows that mandatory=true means it is responsible for making sure the leaf exists. The client cannot rely on the server to create the leaf. The description-stmt should clarify the s-c property. There may be inherent complexity in the data model that requires human comprehension. (YANG isn't going to solve that problem ;-) > Lada > >> Thanks, >> Phil Andy From phil@juniper.net Wed Oct 21 09:20:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAB728B56A for ; Wed, 21 Oct 2009 09:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 MbVQPMMBEN1J for ; Wed, 21 Oct 2009 09:20:50 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 55B793A68CC for ; Wed, 21 Oct 2009 09:20:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSt805RrHkQDRDAs5/2v5uJKMD9N8lWQ8@postini.com; Wed, 21 Oct 2009 09:20:58 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 21 Oct 2009 09:15:47 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:15:48 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:15:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:15:46 -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 n9LGFjj38073; Wed, 21 Oct 2009 09:15:46 -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 n9LG2okv062461; Wed, 21 Oct 2009 16:02:50 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910211602.n9LG2okv062461@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ADF324A.60207@netconfcentral.com> Date: Wed, 21 Oct 2009 12:02:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Oct 2009 16:15:46.0894 (UTC) FILETIME=[BF5B0EE0:01CA5269] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 16:20:50 -0000 Andy Bierman writes: >This is why the mandatory-stmt is still valid, >even for leafs that have the s-c=true property. > The client knows that mandatory=true means it is responsible >for making sure the leaf exists. The client cannot rely on >the server to create the leaf. These two paragraphs seem to read opposite. If the client cannot rely on the server to create the leaf, then it must create the leaf itself, which means s-c leafs and mandatory can't coexist. My view is that mandatory and s-c do not make sense, since the client needs to be able to validate the config before sending it to the server, and this combination is not enforcable on the client. Thanks, Phil From phil@juniper.net Wed Oct 21 09:21: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 DF75C28C0F5; Wed, 21 Oct 2009 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ntzmcPrVLJHF; Wed, 21 Oct 2009 09:21:25 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 7F81128B56A; Wed, 21 Oct 2009 09:21:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSt81CkqdB5uFxpnA/nMRezbp/EamwCFm@postini.com; Wed, 21 Oct 2009 09:21:34 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 21 Oct 2009 09:16:30 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:16:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:16:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:16:28 -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 n9LGGQj38826; Wed, 21 Oct 2009 09:16: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 n9LG3VNP062477; Wed, 21 Oct 2009 16:03:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910211603.n9LG3VNP062477@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4ADF3090.7090903@ericsson.com> Date: Wed, 21 Oct 2009 12:03:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Oct 2009 16:16:28.0831 (UTC) FILETIME=[D85A22F0:01CA5269] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list , netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 16:21:26 -0000 Balazs Lengyel writes: >I have the feeling that we should make with-defaults MANDATORY for all nodes using YANG. >(Currently report-all is the only mode that is mandatory to support in with-defaults.) >Opinions? I disagree. There's nothing in YANG that requires with-defaults. Thanks, Phil From andy@netconfcentral.com Wed Oct 21 09:40: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 00B163A6990 for ; Wed, 21 Oct 2009 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 443VPmg9eFyX for ; Wed, 21 Oct 2009 09:40:46 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id D12F23A6842 for ; Wed, 21 Oct 2009 09:40:42 -0700 (PDT) Received: (qmail 73253 invoked from network); 21 Oct 2009 16:40:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Oct 2009 16:40:49 -0000 X-YMail-OSG: .TwrpEYVM1n9OvV4CunFH4S2ZM0evyXA0BLhwM9KKExhQoNXlynLZTggzn9hwY3t7o8ayBq25zuAWcJgiZPRQFzsB88gtf3r6YS4U9SyURwR4y3JvY09EJhiC.FjJrQQtYX0a56JLFG8QTpkerhyPwqNlizzaBcHYYtoHj2QGVt_KpL5ajHThBEkzjpmWqsFZzVW06onu0aQz8_I6O271evxBVL6vm1TFbTtkHDjPRutY3l46z8aD33nlU6XHXx631EZIiGD278- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADF39C5.7040100@netconfcentral.com> Date: Wed, 21 Oct 2009 09:41:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Balazs Lengyel References: <200909011930.n81JU7WS093379@idle.juniper.net> <4ADF3090.7090903@ericsson.com> In-Reply-To: <4ADF3090.7090903@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf mailing list Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 16:40:47 -0000 Balazs Lengyel wrote: > Hello, > I have the feeling that we should make with-defaults MANDATORY for all > nodes using YANG. > (Currently report-all is the only mode that is mandatory to support in > with-defaults.) > Opinions? I was thinking that, until Phil explained to us that a system-created node (not a YANG default) is an explicit node. Every defaults style MUST return s-c leafs. The leafs that can get left out are YANG defaults. Here are some open issues that impact the reliability of the meta-data the client needs to derive the proper defaults: I think MUST implement with-defaults is a more user-friendly solution than the following: * Agree that using revision statements is mandatory * Agree that the server MUST advertise all its modules in the * Agreed that import/include by revision SHOULD be used in vendor modules and MUST (+) be used in standard modules. + I am not convinced mandatory import-by-rev is a workable solution. I think it will lead to a rats-nest of version dependencies. Instead, YANG should specify that the most recent revision date supported by the server MUST be used if no revision-date is provided. E.g, A -> B -> C, but now A wants to import the new version of C, but also wants B to use the same version of C; otherwise typedefs/groupings in B are out-of-synch with those in A. If vendor(A) is not vendor(B), then updating B may be difficult or impossible. In the IETF, it will mean republishing RFCs just to change 1 import-stmt, which could turn into a boiler-plate/process nightmare. > Balazs Andy From andy@netconfcentral.com Wed Oct 21 09:45: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 866873A680D for ; Wed, 21 Oct 2009 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 P6JDOqIQFxEF for ; Wed, 21 Oct 2009 09:45:52 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 898723A659B for ; Wed, 21 Oct 2009 09:45:52 -0700 (PDT) Received: from [68.142.200.227] by n19.bullet.mail.mud.yahoo.com with NNFMP; 21 Oct 2009 16:46:00 -0000 Received: from [68.142.201.254] by t8.bullet.mud.yahoo.com with NNFMP; 21 Oct 2009 16:46:00 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 21 Oct 2009 16:45:59 -0000 X-Yahoo-Newman-Id: 984078.18668.bm@omp415.mail.mud.yahoo.com Received: (qmail 14208 invoked from network); 21 Oct 2009 16:45:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 21 Oct 2009 16:45:59 -0000 X-YMail-OSG: nFQXBj4VM1lFs0VAWel4yMkJ8zoyKWiZ3GNJXHM2_ANRew2l95DdWIdmREsQwXKxn1zD8N8Kp.IcUlbowJ9Q6rnu9HkA4YxJUOdJCoB6_OLvheWXKAljUTxxlJydegpUPWZrXWZXR2j2YpZVVF5IE99p7KXa.3cFv3unL9Fd0nI7LG7HP5ZyuJnn71KJ62NBwgyrRmdL7WljjWS6KZ9C1FbeGXeAgJEE24zs0Pf7m21LHgeHtLXhBhXjGptr_yO_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADF3AFB.1010102@netconfcentral.com> Date: Wed, 21 Oct 2009 09:46:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910211602.n9LG2okv062461@idle.juniper.net> In-Reply-To: <200910211602.n9LG2okv062461@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 16:45:53 -0000 Phil Shafer wrote: > Andy Bierman writes: >> This is why the mandatory-stmt is still valid, >> even for leafs that have the s-c=true property. >> > The client knows that mandatory=true means it is responsible >> for making sure the leaf exists. The client cannot rely on >> the server to create the leaf. > > These two paragraphs seem to read opposite. If the client cannot > rely on the server to create the leaf, then it must create the leaf > itself, which means s-c leafs and mandatory can't coexist. > > My view is that mandatory and s-c do not make sense, since the > client needs to be able to validate the config before sending it > to the server, and this combination is not enforcable on the client. > But mandatoty-stmt is not defined the way you want. It just means the node must exist. If the client is aware that a particular server will create a particular s-c leaf, then why force it to send the node? The s-c=true is just a MAY create, not a MUST create. That leaves a lot of fuzzy ground. I think we need to drop s-c and move on. We do not agree that one very narrow implementation strategy is necessary or sufficient. > Thanks, > Phil > Andy From phil@juniper.net Wed Oct 21 10:11: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 6FD403A68F8 for ; Wed, 21 Oct 2009 10:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 xhwYq9FTExDD for ; Wed, 21 Oct 2009 10:11:35 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 873803A682A for ; Wed, 21 Oct 2009 10:11:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSt9AzYbXhZ/4eFpWgTgvqKqZpH+sIdiN@postini.com; Wed, 21 Oct 2009 10:11:44 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 21 Oct 2009 09:59:24 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:59:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:59:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:59: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 n9LGxMj58901; Wed, 21 Oct 2009 09:59:22 -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 n9LGkQM2063025; Wed, 21 Oct 2009 16:46:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910211646.n9LGkQM2063025@idle.juniper.net> To: Andy Bierman In-Reply-To: <4ADF3AFB.1010102@netconfcentral.com> Date: Wed, 21 Oct 2009 12:46:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Oct 2009 16:59:22.0872 (UTC) FILETIME=[D6999F80:01CA526F] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 17:11:36 -0000 Andy Bierman writes: >But mandatoty-stmt is not defined >the way you want. It just means the >node must exist. If the client is aware >that a particular server will create a particular >s-c leaf, then why force it to send the node? Mandatory means the node must exist in a valid config, so both the client and server can enforce this. The new text for s-c leafs requires that s-c leafs not be mandatory so that clients and servers can continue to enforce the mandatory constraint. Thanks, Phil From andy@netconfcentral.com Wed Oct 21 11:04: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 0B7833A6853 for ; Wed, 21 Oct 2009 11:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 dXxaW8h6oWWw for ; Wed, 21 Oct 2009 11:04:58 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 3B4223A67FA for ; Wed, 21 Oct 2009 11:04:58 -0700 (PDT) Received: (qmail 9671 invoked from network); 21 Oct 2009 18:05:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 21 Oct 2009 18:05:05 -0000 X-YMail-OSG: _vFfhLQVM1mzg0ooqI7Hue7076CSCsSMGADZew3M7RYXLrMMFI.HVpxuX0uDcFGsGbUJ8NI4fTTAqAIPVoSAC.QcLqEXX28xiDaHHm18z..ZtTKtu0u0OlYG44.4s2UJ9XOnQPsArxskCwmpIDQtKbyyQ0eJIsIYobtEVZxt6Ybe.6Z5phRPtcQ75s9oSUYl743bx6rlxI8g0P7bglh.YidFDjhsxWYqGYsue6Ms23U6tbR.oM4zr.7n9xzHtPQMkwaiGO9xh8lcK9CtQ5.n8_KKswzY.swqnmSfjW3GdBO7GF1wzBQaozDjMNuFDT5z X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADF4D85.1050307@netconfcentral.com> Date: Wed, 21 Oct 2009 11:05:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910211646.n9LGkQM2063025@idle.juniper.net> In-Reply-To: <200910211646.n9LGkQM2063025@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2009 18:04:59 -0000 Phil Shafer wrote: > Andy Bierman writes: >> But mandatoty-stmt is not defined >> the way you want. It just means the >> node must exist. If the client is aware >> that a particular server will create a particular >> s-c leaf, then why force it to send the node? > > Mandatory means the node must exist in a valid config, so > both the client and server can enforce this. huh? the definition of mandatory-stmt does not say anything about the client MUST create the value. leaf client-must-always-set { type string; mandatory true; system-creatable false; } leaf client-set-depends-on-data-model { type string; mandatory true;; system-creatable true; } The new > text for s-c leafs requires that s-c leafs not be mandatory > so that clients and servers can continue to enforce the > mandatory constraint. > That isn't true. Since s-c=true means server MAY create, the client (offline) validation for all nodes without a default-stmt, regardless of the mandatory-stmt, is not reliable. I do not see how these s-c leafs can be left outside part or all of the validation model, especially since they become 'normal' leafs once created. This is not a workable solution. This s-c statement is too narrow and creates too many CLRs to be included in YANG 1.0. > Thanks, > Phil > Andy From muenz@net.in.tum.de Thu Oct 22 01:08: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 0D20E3A67F3 for ; Thu, 22 Oct 2009 01:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.402, 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 qiT8OIJoquOy for ; Thu, 22 Oct 2009 01:08:49 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id D4A913A6893 for ; Thu, 22 Oct 2009 01:08:48 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B466D4806C for ; Thu, 22 Oct 2009 10:08:56 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id A837A5517 for ; Thu, 22 Oct 2009 10:08:56 +0200 (CEST) Message-ID: <4AE0134A.2010400@net.in.tum.de> Date: Thu, 22 Oct 2009 10:09:46 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030103040200050205080102" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 08:08:50 -0000 This is a cryptographically signed message in MIME format. --------------ms030103040200050205080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, >>> Part of my problem may be a failure of imagination. I have trouble >>> imagining a field for which the data model requires that the field >>> exist the system can reliably know the value and the client can not >>> reasonably be expected to know the value. > > Joel > > Gerhard said that this was a use case for IPFIX at the back end of > August last year. As one of the few people to have used YANG in > anger, I take that as a clear requirement. Correct. In IPFIX, we always say something like: "If not configured, the Selector ID is assigned by the Monitoring Device." in the description clause. We could add a MUST in these sentences to make it clear. I went through the IPFIX configuration data model and found two reasons for system-created-if-not-provided-by-user parameters: - device-specific defaults Example: sendBufferSize (of a socket) IMO, it does not make sense to set a default value in the data model. It does not make sense to make this parameter mandatory, either. - logical identifiers which are mapped to (physical) resources Example: observationPointId This ID is mapped to an ifIndex or an entPhysicalIndex. The user might be interested in configuring this mapping. In other cases, however, he may let the device choose an appropriate value. In the later case, the user will be relieved from coping for the uniqueness of observationPointIds. That's it. Regards, Gerhard > I disagree with the current formulation of system-creatable on this > (I want MUST and not MAY), on restricting the system to be able > to create only nodes with system-creatable (that for me came from > nowhere) and with the leaf only existing after validation and so not > being available to any of the extra logic that YANG adds:-( > > So as currently formulated, I find it of no additional value. > Tom Petch > >>> >>> The userid case is not actually a good example of this, because the >>> system may not need userids. As something the system may create, >>> if it needs them, it makes sense to me. As a global requirement >>> that the user model MUST have valid userids, I don't follow it. >>> (Requiring that IDs, if they are used, be unique, makes sense >>> because good security practice says to avoid confusing users.) >>> >>> We can give up on all notion of knowing what the system may modify, >>> and take the view that since multi-manager means that you can never >>> know anyway, the client effectively must refresh his model before >>> beginning any operation, and after any commit if operation is >>> continuing. But folks have repeatedly said that thye do not want >>> clients to have to fetch everything in sight. (There are meaningful >>> alternatives for dealing with multi-manager, but they will not cope >>> with system-created very well.) >>> >>> Yours, Joel >>> >>> Randy Presuhn wrote: >>>>> Hi - >>>>> >>>>>>> From: "Joel M. Halpern" To: "Randy >>>>>>> Presuhn" Sent: Monday, >>>>>>> October 19, 2009 1:30 PM Subject: Re: [netmod] >>>>>>> system-creatable >>>>>>> >>>>>>> I do not follow your reasoning about the relationship >>>>>>> between whether >>>>>>> S-C is a must and the user-id example. >>>>>>> >>>>>>> If user-id is mandatory, then the client better be prepared >>>>>>> to create it. >>>>> >>>>> It is not mandatory, at least not in the Yang sense. >>>>> >>>>>>> If user-id is optional, then clients do not have to create >>>>>>> it if they >>>>>>> don't want to. >>>>> >>>>> Agreed. >>>>> >>>>>>> If user-id is optional and system-createable, then the >>>>>>> client is not >>>>>>> required to create it, but the client should be aware that >>>>>>> the system >>>>>>> may choose to assign it a value, for example, if it uses >>>>>>> userids. >>>>> >>>>> replace "may" with "MUST". >>>>> >>>>>>> I suppose we could add the mixed case of a leaf declared as >>>>>>> both mandatory and system-createable, to indicate that the >>>>>>> system is required >>>>>>> to create it if the client does not. The verbiage would be >>>>>>> pretty strange, but at least we don't use the optional case >>>>>>> that I think is useful. >>>>> >>>>> I don't want to go there. >>>>> >>>>> I think the confusion may come from the shorthand. When I say >>>>> "MAY" and "MUST" here, I am referring to the replacement of the >>>>> "MAY" in the proposed text with "MUST" The "MAYs" in the >>>>> proposed text all had to do with *server* requirements, not >>>>> client requirements. >>>>> >>>>> Randy >>>>> >>>>> > --------------ms030103040200050205080102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDIyMDgwOTQ2WjAjBgkqhkiG9w0BCQQxFgQU U52TLVKgTcBA+JasTmOmf80ULoowXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQAI+tNpiD2lCVLHiOBYqjgyUzQFw2M1 w8mENKfRQQRf17LKP3JDX/911kpcJ9szqy9FcRnv00cTg2rAsio5SJpRaBvnWdLY+9/NM0SN T9jGviIzSTAubuXC3sUqYZBPDbj3e0SQfYWCMGN6EO04o5Ykhduam3u0707yKqRbaBdcWSyv xt5pnnDCDDxsM0pM9hZ3/Qp48l4cJxuJsNv1+SGbIKpoDgYOSPvKyu+ie4r3imNWo4MPHnLr lbaiZMIa9ULc+u88AOu6fkuNdSH+H8aVpES8IY9oxCF570Mnv2TCnr1cdIlRbrpKYEw0kBfd /8k9E8SdP9vjWIqgVidaSZooAAAAAAAA --------------ms030103040200050205080102-- From andy@netconfcentral.com Thu Oct 22 03:38: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 168933A6905 for ; Thu, 22 Oct 2009 03:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 hgqmH94Rs9wb for ; Thu, 22 Oct 2009 03:38:49 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id ED7D43A68FA for ; Thu, 22 Oct 2009 03:38:48 -0700 (PDT) Received: (qmail 50008 invoked from network); 22 Oct 2009 10:38:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 22 Oct 2009 10:38:58 -0000 X-YMail-OSG: AYDrRsoVM1njAU8SfCQTqWHxavoT58bfaommN9Ep5hmboBElNoqtDPUvf2HjpPLmoeEnGRim_reShNfAs2B3GarNKVv8iPFYpJs5pXqBiTfZhtoh2HfnMOOiFLTz0Gogh7f7wuFdFM08DmOse5HaCEoufRJV0BxBFzJBFhcQ_yUyEWAHHT2h1mNcSMa1etDzpVMkbjZNsuRiSO7J8L9TlVGjccp8Q7bZSsX4dCT8hJusTeW0yaY3XdYWgMaU_4qw6CnR8h7YyHPA6B1jLZsYBddVLYqe1s7WtzQOxSLGaudaZQ5cUy0J6iRi X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE03679.8070506@netconfcentral.com> Date: Thu, 22 Oct 2009 03:39:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Gerhard Muenz References: <4AE0134A.2010400@net.in.tum.de> In-Reply-To: <4AE0134A.2010400@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 10:38:50 -0000 Gerhard Muenz wrote: > > Hi, > >>>> Part of my problem may be a failure of imagination. I have trouble >>>> imagining a field for which the data model requires that the field >>>> exist the system can reliably know the value and the client can not >>>> reasonably be expected to know the value. >> >> Joel >> >> Gerhard said that this was a use case for IPFIX at the back end of >> August last year. As one of the few people to have used YANG in >> anger, I take that as a clear requirement. > > Correct. In IPFIX, we always say something like: > > "If not configured, the Selector ID is assigned by the Monitoring > Device." > > in the description clause. We could add a MUST in these sentences to > make it clear. > > I went through the IPFIX configuration data model and found two reasons > for system-created-if-not-provided-by-user parameters: > > - device-specific defaults > Example: sendBufferSize (of a socket) > IMO, it does not make sense to set a default value in the data model. > It does not make sense to make this parameter mandatory, either. > > - logical identifiers which are mapped to (physical) resources > Example: observationPointId > This ID is mapped to an ifIndex or an entPhysicalIndex. > The user might be interested in configuring this mapping. In other > cases, however, he may let the device choose an appropriate value. > In the later case, the user will be relieved from coping for the > uniqueness of observationPointIds. > > That's it. > I just reviewed http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-03.txt and I can't find any indication whatsoever that the objects marked as "If not configured..." cannot be selected by the server during the edit-config to candidate. None of these objects seem to have the special property shared with the 'uid' example of being unknowable until after the commit. (Even in the uid example, the server could reserve a value during the edit-config.) IMO, s-c is currently unworkable because of this 'invisible to validation' requirement. It seems like an extreme corner-case. The server MUST figure out what value to use during the edit-commit, and s-c leafs MUST be part of candidate validation. I do not see any problem with ipfix-psamp.yang wrt/ this requirement. > Regards, > Gerhard > > > >> I disagree with the current formulation of system-creatable on this >> (I want MUST and not MAY), on restricting the system to be able >> to create only nodes with system-creatable (that for me came from >> nowhere) and with the leaf only existing after validation and so not >> being available to any of the extra logic that YANG adds:-( >> >> So as currently formulated, I find it of no additional value. The only minor value of the current s-c is if it is set to false, then the client knows the server will not create a leaf that the client doesn't care about anyway. >> Tom Petch >> Andy From lhotka@cesnet.cz Thu Oct 22 04:09: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 583D83A69CE for ; Thu, 22 Oct 2009 04:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=-0.835, 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 t8PMeQm38FcQ for ; Thu, 22 Oct 2009 04:09:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 865633A69DC for ; Thu, 22 Oct 2009 04:09:44 -0700 (PDT) Received: from [195.113.219.162] (eduroam-162.cesnet.cz [195.113.219.162]) by office2.cesnet.cz (Postfix) with ESMTP id A1890D80096 for ; Thu, 22 Oct 2009 13:09:53 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Thu, 22 Oct 2009 13:09:51 +0200 Message-Id: <1256209791.5552.7.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] identityref value X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 11:09:45 -0000 Hi, yang-07 says the value of identityref type can be QName of ANY type derived from identityref's base type. However, I think the selection must be limited to the identities declared in the modules that the server advertizes in , otherwise the server may not be able to check/understand the value. So what's the rule here? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Oct 22 04:14: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 DB7F23A69C5 for ; Thu, 22 Oct 2009 04:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 PVazodlAmkgI for ; Thu, 22 Oct 2009 04:14:12 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 1E1983A699A for ; Thu, 22 Oct 2009 04:14:12 -0700 (PDT) Received: (qmail 99186 invoked from network); 22 Oct 2009 11:14:19 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 22 Oct 2009 04:14:19 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: aIg69dUVM1mjFz0nI54shpzKyFXBttW_gEGx.D_lEx3gWCsaOXlrNRsurYWjWH.REKNFXywC55SxVA6NeND0w90D2HBkiLaltDWMc020Z9g1WiXFdyC7Wiuas.nL_FiIewtz_rTJ4wA2OHYfCswzCMZzuStiDdgq.pYZcHwyNSjjmk0PMWqwQyo.Wup94mW49CxR_Z7Lyy4GjhMRPXgl1HdC8FIWA9pGnR4wp7rPcuBqkHouDilCHORePeMEGl05wexLDcne6HDJ_zoMz61f84gqmGeVB5vQEmN85skKT77QNhUvC0fRCaRDVKvdEiOU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE03EC2.6070504@netconfcentral.com> Date: Thu, 22 Oct 2009 04:15:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1256209791.5552.7.camel@nomad> In-Reply-To: <1256209791.5552.7.camel@nomad> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref value X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 11:14:13 -0000 Ladislav Lhotka wrote: > Hi, > > yang-07 says the value of identityref type can be QName of ANY type > derived from identityref's base type. However, I think the selection > must be limited to the identities declared in the modules that the > server advertizes in , otherwise the server may not be able to > check/understand the value. So what's the rule here? > Isn't it just an XML prefix inside the PDU? There must be an xmlns attribute identifying the module namespace, and there must be a capability in the to match that namespace. > Lada > Andy From lhotka@cesnet.cz Thu Oct 22 04:35: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 1823228C107 for ; Thu, 22 Oct 2009 04:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=0.404, 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 8GnMNZ1mzoUM for ; Thu, 22 Oct 2009 04:35:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 49EA528C0FF for ; Thu, 22 Oct 2009 04:35:06 -0700 (PDT) Received: from [195.113.219.162] (eduroam-162.cesnet.cz [195.113.219.162]) by office2.cesnet.cz (Postfix) with ESMTP id AA1C4D800E8; Thu, 22 Oct 2009 13:35:15 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4AE03EC2.6070504@netconfcentral.com> References: <1256209791.5552.7.camel@nomad> <4AE03EC2.6070504@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 22 Oct 2009 13:35:13 +0200 Message-Id: <1256211313.5552.26.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref value X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 11:35:07 -0000 Andy Bierman píše v ÄŒt 22. 10. 2009 v 04:15 -0700: > Ladislav Lhotka wrote: > > Hi, > > > > yang-07 says the value of identityref type can be QName of ANY type > > derived from identityref's base type. However, I think the selection > > must be limited to the identities declared in the modules that the > > server advertizes in , otherwise the server may not be able to > > check/understand the value. So what's the rule here? > > > > Isn't it just an XML prefix inside the PDU? > There must be an xmlns attribute identifying the > module namespace, and there must be a capability in > the to match that namespace. Yes, but the prefix just points to a module where the identity is supposed to be defined, but the server may not have access to this module at run time. Lada > > > > Lada > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Oct 22 04:45: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 09D6B3A68A3 for ; Thu, 22 Oct 2009 04:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYxF6XrsUvXK for ; Thu, 22 Oct 2009 04:45: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 32D513A6875 for ; Thu, 22 Oct 2009 04:45:53 -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 61D1D616002; Thu, 22 Oct 2009 13:46:01 +0200 (CEST) Date: Thu, 22 Oct 2009 13:46:00 +0200 (CEST) Message-Id: <20091022.134600.187824165.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1256209791.5552.7.camel@nomad> References: <1256209791.5552.7.camel@nomad> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identityref value X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 11:45:54 -0000 Ladislav Lhotka wrote: > Hi, > > yang-07 says the value of identityref type can be QName of ANY type > derived from identityref's base type. However, I think the selection > must be limited to the identities declared in the modules that the > server advertizes in , otherwise the server may not be able to > check/understand the value. So what's the rule here? Yes. How about this: OLD: Valid values for an identityref are any identities derived from the identityref's base identity. NEW: Valid values for an identityref are any identities derived from the identityref's base identity. On a particular server, the valid values are further restricted to the set of identities defined in the modules supported by the server. /martin From lhotka@cesnet.cz Thu Oct 22 04:54: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 A5C763A6836 for ; Thu, 22 Oct 2009 04:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=0.389, 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 1jN7k-DQoGUl for ; Thu, 22 Oct 2009 04:54:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C89D43A6849 for ; Thu, 22 Oct 2009 04:54:48 -0700 (PDT) Received: from [195.113.219.162] (eduroam-162.cesnet.cz [195.113.219.162]) by office2.cesnet.cz (Postfix) with ESMTP id 4A873D80095; Thu, 22 Oct 2009 13:54:58 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091022.134600.187824165.mbj@tail-f.com> References: <1256209791.5552.7.camel@nomad> <20091022.134600.187824165.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 22 Oct 2009 13:54:56 +0200 Message-Id: <1256212496.5552.28.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identityref value X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 11:54:49 -0000 Martin Bjorklund píše v ÄŒt 22. 10. 2009 v 13:46 +0200: > Ladislav Lhotka wrote: > > Hi, > > > > yang-07 says the value of identityref type can be QName of ANY type > > derived from identityref's base type. However, I think the selection > > must be limited to the identities declared in the modules that the > > server advertizes in , otherwise the server may not be able to > > check/understand the value. So what's the rule here? > > Yes. > > How about this: > > OLD: > > Valid values for an identityref are any identities derived from the > identityref's base identity. > > NEW: > > Valid values for an identityref are any identities derived from the > identityref's base identity. On a particular server, the valid values > are further restricted to the set of identities defined in the modules > supported by the server. Yes, this was my idea, provided that supported == advertized. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Thu Oct 22 06:15: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 220FA3A6A16; Thu, 22 Oct 2009 06:15:02 -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: <20091022131502.220FA3A6A16@core3.amsl.com> Date: Thu, 22 Oct 2009 06:15:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-08.txt Pages : 178 Date : 2009-10-22 YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22060314.I-D@ietf.org> --NextPart-- From phil@juniper.net Thu Oct 22 06:47:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C833A69EA for ; Thu, 22 Oct 2009 06:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 lglmTiO6ZADF for ; Thu, 22 Oct 2009 06:47:09 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 69E9E3A6910 for ; Thu, 22 Oct 2009 06:46:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSuBiXHA7CbBUw/QW0ulD0H5kCRvQN8Gq@postini.com; Thu, 22 Oct 2009 06:47:17 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 22 Oct 2009 06:37:49 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 06:37:49 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 06:37:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 06:37:47 -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 n9MDbjj89340; Thu, 22 Oct 2009 06:37:45 -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 n9MDOn6r072526; Thu, 22 Oct 2009 13:24:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910221324.n9MDOn6r072526@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AE03679.8070506@netconfcentral.com> Date: Thu, 22 Oct 2009 09:24:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Oct 2009 13:37:47.0218 (UTC) FILETIME=[D7710B20:01CA531C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org, Gerhard Muenz Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 13:47:10 -0000 Andy Bierman writes: >IMO, s-c is currently unworkable because of this 'invisible to validation' requirement. It seems like an extreme corner-case. The server MUST >figure out what value to use during the edit-commit, and s-c leafs >MUST be part of candidate validation. I do not see any problem >with ipfix-psamp.yang wrt/ this requirement. If s-c leafs are required for validation, then the client cannot validate config before sending it to the server. Since we want clients to be able to validate config before sending it to the server, we have to say that s-c leafs are not created until after validation. Thanks, Phil From phil@juniper.net Thu Oct 22 07:45: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 573173A6A67 for ; Thu, 22 Oct 2009 07:45:29 -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.562, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 BzJW3Dv36brX for ; Thu, 22 Oct 2009 07:45:28 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id AB7393A6A6D for ; Thu, 22 Oct 2009 07:45:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSuBwCxiXfqxPYJWtInKy0Bfbz8G2JDD3@postini.com; Thu, 22 Oct 2009 07:45: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.375.2; Thu, 22 Oct 2009 07:36:44 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 07:36:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 07:36:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 07:36:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9MEahj15296; Thu, 22 Oct 2009 07:36: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 n9MENknQ072751; Thu, 22 Oct 2009 14:23:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910221423.n9MENknQ072751@idle.juniper.net> To: Gerhard Muenz In-Reply-To: <4AE0134A.2010400@net.in.tum.de> Date: Thu, 22 Oct 2009 10:23:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Oct 2009 14:36:43.0586 (UTC) FILETIME=[1347FA20:01CA5325] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 14:45:29 -0000 Gerhard Muenz writes: >- device-specific defaults > Example: sendBufferSize (of a socket) > IMO, it does not make sense to set a default value in the data model. > It does not make sense to make this parameter mandatory, either. Are you really wanting device-specific defaults to appear as part of the config data? >- logical identifiers which are mapped to (physical) resources > Example: observationPointId > This ID is mapped to an ifIndex or an entPhysicalIndex. > The user might be interested in configuring this mapping. In other > cases, however, he may let the device choose an appropriate value. > In the later case, the user will be relieved from coping for the > uniqueness of observationPointIds. I think this one fits in the "twin leafs" discussion, where you have one leaf that allows the user to configure a fixed value (via a config=true node) and a distinct leaf where the current value can be retrieve (via a config=false node). Thanks, Phil From balazs.lengyel@ericsson.com Thu Oct 22 08:01:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A092528C14D for ; Thu, 22 Oct 2009 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fWaL+doGaPo for ; Thu, 22 Oct 2009 08:01:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 49B023A6A6C for ; Thu, 22 Oct 2009 08:01:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-6c-4ae073d9f82b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DA.03.04191.9D370EA4; Thu, 22 Oct 2009 17:01:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:01:28 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:01:25 +0200 Message-ID: <4AE073C4.7050709@ericsson.com> Date: Thu, 22 Oct 2009 17:01:24 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Phil Shafer References: <200910221324.n9MDOn6r072526@idle.juniper.net> In-Reply-To: <200910221324.n9MDOn6r072526@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 15:01:25.0571 (UTC) FILETIME=[869CF130:01CA5328] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org, Gerhard Muenz Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 15:01:38 -0000 Hello, According to an earlier suggestion: The device MUST create s-c values in a way, that the configuration remains valid. This ensures that although they are not part of the validation, it is ensured that the configuration stays valid. Is this acceptable? In rare cases you should be able to set data that makes it impossible for the device to set valid s-c values, but that seems to need some really strange rules. Anyway YANG rules will never be able to cover everything. Balazs On 10/22/09 15:24, Phil Shafer wrote: > Andy Bierman writes: >> IMO, s-c is currently unworkable because of this 'invisible to validation' > requirement. It seems like an extreme corner-case. The server MUST >> figure out what value to use during the edit-commit, and s-c leafs >> MUST be part of candidate validation. I do not see any problem >> with ipfix-psamp.yang wrt/ this requirement. > > If s-c leafs are required for validation, then the client > cannot validate config before sending it to the server. Since > we want clients to be able to validate config before sending > it to the server, we have to say that s-c leafs are not created > until after validation. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Thu Oct 22 08:46: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 2DCF13A689A for ; Thu, 22 Oct 2009 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_20=-0.74, UNPARSEABLE_RELAY=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 fjpn3rEgv2Qe for ; Thu, 22 Oct 2009 08:46:05 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 616E93A6878 for ; Thu, 22 Oct 2009 08:46:05 -0700 (PDT) Received: (qmail 94316 invoked from network); 22 Oct 2009 15:46:12 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 22 Oct 2009 08:46:12 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: fMrSfS0VM1l.aXfcgGzzJLej8cNlpwa8SrpoKhHasJ_4oXi.qUt5c_NNvI_mda1WNVwY6e8UfbaK6Ezbu_IdiMMY8DZk4w4.4MtYUqFr1sjgHt17PY4ueMZt4C2lvaCrKSPrAjEJBjQV9.ykJQrM8WNeSLUXAJIMSdAf031XYdfeNjCwIFggfSDsjwzb7rXKQuNenYb6pbtzgL1WNlTH_f2WOXax4ULZRE0A65u3irVM9EN3MBBIjdIJvYgoogE7SzpGYZfY2UW2ZXeUV5d0lsoldNaB_MZ7nAJOELBOmLH6XXLZgOAgXEwrsZleF2wXeA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE07E7C.6080803@netconfcentral.com> Date: Thu, 22 Oct 2009 08:47:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 15:46:06 -0000 Hi, The rules for updating a module changed in -08. It is unrealistic to forbid the addition of a default-stmt. The likely usage in standards will be to add a default after a few years. YANG forces every data modeler to know every appropriate default on Day One of version -00. This is absurd. Why is YANG making this CLR? It seems to me that the price for letting the server hide YANG defaults is way too high. Server implementation of with-defaults removes the need for saturating the language with all these CLRs. Andy From muenz@net.in.tum.de Thu Oct 22 09:18: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 E62213A6819 for ; Thu, 22 Oct 2009 09:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.302, 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 yU+nvF3CKv8W for ; Thu, 22 Oct 2009 09:18:49 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id C4FAE3A67FA for ; Thu, 22 Oct 2009 09:18:48 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 1696E4806C; Thu, 22 Oct 2009 18:18:56 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0330450B1; Thu, 22 Oct 2009 18:18:56 +0200 (CEST) Message-ID: <4AE08622.3050307@net.in.tum.de> Date: Thu, 22 Oct 2009 18:19:46 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4AE0134A.2010400@net.in.tum.de> <4AE066C6.2030807@joelhalpern.com> In-Reply-To: <4AE066C6.2030807@joelhalpern.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090409070704070005010905" X-Virus-Scanned: ClamAV using ClamSMTP Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 16:18:50 -0000 This is a cryptographically signed message in MIME format. --------------ms090409070704070005010905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Joel, Joel M. Halpern wrote: > I had forgotten about some of this, and I apologize. > With regard to the IDs (like observationPointId), for constructs being > defined (not for references, etc), what is the use case for user > definition of the ID? Thre may well be a need for such, but if not, > then that field could be state data, making things much simpler. Yes, probably that's the way to go. I was thinking of one use-case: selectionSequenceId defines a filter chain in the monitoring device. The ID value reappears in the exported data, labeling the flows whose packets passed this filter chain. So, if I configure the selectionSequenceId, I know what I have to look for in the output. But I might as well retrieve the ID value assigned by the device (as state parameter) and than search for this value in the output. The retrieval of the state parameter is on more step for the user, but not a big deal. Regards, Gerhard > > Yours, > Joel > > Gerhard Muenz wrote: >> Hi, >> >>>>> Part of my problem may be a failure of imagination. I have trouble >>>>> imagining a field for which the data model requires that the field >>>>> exist the system can reliably know the value and the client can not >>>>> reasonably be expected to know the value. >>> Joel >>> >>> Gerhard said that this was a use case for IPFIX at the back end of >>> August last year. As one of the few people to have used YANG in >>> anger, I take that as a clear requirement. >> Correct. In IPFIX, we always say something like: >> >> "If not configured, the Selector ID is assigned by the Monitoring >> Device." >> >> in the description clause. We could add a MUST in these sentences to >> make it clear. >> >> I went through the IPFIX configuration data model and found two reasons >> for system-created-if-not-provided-by-user parameters: >> >> - device-specific defaults >> Example: sendBufferSize (of a socket) >> IMO, it does not make sense to set a default value in the data model. >> It does not make sense to make this parameter mandatory, either. >> >> - logical identifiers which are mapped to (physical) resources >> Example: observationPointId >> This ID is mapped to an ifIndex or an entPhysicalIndex. >> The user might be interested in configuring this mapping. In other >> cases, however, he may let the device choose an appropriate value. >> In the later case, the user will be relieved from coping for the >> uniqueness of observationPointIds. >> >> That's it. >> >> Regards, >> Gerhard --------------ms090409070704070005010905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDIyMTYxOTQ2WjAjBgkqhkiG9w0BCQQxFgQU 5VWrpRWyx6AD+CxjONjeAasEwigwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQCzHhfXpFac4OLi4qLTWvVmco5Loi3a NW0JcaDPacAL5e2BNMLdwbcl5B/jRJKy2/zZBYq7XNSyRqLPF3EcmVUJRvY3dkmt8JVrV0eZ ROq67E8m1t7ILsYdUG3Pktn3vt/l3mGjnQPeKWz/6wPza9KhGerVOnsJqYGk/YWB7eKlHqGg TCvZnnQAOsgPotDSHMphY4pNYag4kUf6Js4zliXKj9hHYdw6CPQeQ0QYOUoF3uVPpaO/A8gL bcLghk1lGh/6cOElFVF4ZtK/YJohvz9y6b/Gjf2eO0dmhfyUJ2XgNwWxs2wM5D+pYs+tz3hf 8kuplHZDJnJzP5n19VKuz75pAAAAAAAA --------------ms090409070704070005010905-- From muenz@net.in.tum.de Thu Oct 22 09: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 BF0FF3A6891 for ; Thu, 22 Oct 2009 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.241, 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 yESRBz8D1nQQ for ; Thu, 22 Oct 2009 09:23:14 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id E8D903A68A0 for ; Thu, 22 Oct 2009 09:23:13 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9E7964806C; Thu, 22 Oct 2009 18:23:19 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9640C50B1; Thu, 22 Oct 2009 18:23:19 +0200 (CEST) Message-ID: <4AE08729.6010509@net.in.tum.de> Date: Thu, 22 Oct 2009 18:24:09 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200910221423.n9MENknQ072751@idle.juniper.net> In-Reply-To: <200910221423.n9MENknQ072751@idle.juniper.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010507060209020107010901" X-Virus-Scanned: ClamAV using ClamSMTP Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 16:23:14 -0000 This is a cryptographically signed message in MIME format. --------------ms010507060209020107010901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil Shafer wrote: > Gerhard Muenz writes: >> - device-specific defaults >> Example: sendBufferSize (of a socket) >> IMO, it does not make sense to set a default value in the data model. >> It does not make sense to make this parameter mandatory, either. > > Are you really wanting device-specific defaults to appear > as part of the config data? I don't care. I, as a data model writer, just do not want to define an arbitrary default value. The vendor should define one for his device. If there is a way to force vendors to provide a deviation or whatever defining vendor-specific defaults for these specific leafs, I'm also fine with that. Regards, Gerhard --------------ms010507060209020107010901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDIyMTYyNDA5WjAjBgkqhkiG9w0BCQQxFgQU /X9DYznX8UluWYzwGDL1s9tm6XMwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQC94kNMii0Y5dXHftLZNH8n54YY+DsF SF2vsTnqvQTgSpxNAawwMAc+fDfXMbwHDAXC6yfUFcvkb/qLVpzJyd7ynYmoaKk0HZinqF/t rA/CwQXqokFi7ICF8B7gZdMDPdfGFYECli3QwYSKSX3gtisGPTBuLb+3019X/Q/W6igXTdtk syOiVSPahlsoVycn6Mshs3pmcT8HDCO/cmux8QqRvoL3J4AT5N235TX34RXskBfKFSNo5tjZ eK+mpswxppT4pyn1eUTIYVmdMwBc7r8GoGni7mofliv6Jx1w90TyNARyvAgCp9c3q+bH8a9X ZMN/KAdotGQuisjX9Kx3FhInAAAAAAAA --------------ms010507060209020107010901-- From randy_presuhn@mindspring.com Thu Oct 22 09:31: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 25D163A6883 for ; Thu, 22 Oct 2009 09:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs99PVaKXOgG for ; Thu, 22 Oct 2009 09:31:26 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 8570C3A67BD for ; Thu, 22 Oct 2009 09:31:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VCZTOeOkK4phqDhyNVW1GXJoR3ujAUaUzkcERUcrvegujwFlitLHDnU+GSfXszBj; 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 [99.41.52.188] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N10Zb-00079i-VT for netmod@ietf.org; Thu, 22 Oct 2009 12:31:36 -0400 Message-ID: <004e01ca5335$5ea4a120$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910221324.n9MDOn6r072526@idle.juniper.net> Date: Thu, 22 Oct 2009 09:33:20 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f955b54b1301e8a0f37733ef18aa02ed77350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.52.188 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 16:31:31 -0000 Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: ; "Gerhard Muenz" > Sent: Thursday, October 22, 2009 6:24 AM > Subject: Re: [netmod] system-creatable ... > If s-c leafs are required for validation, then the client > cannot validate config before sending it to the server. Since > we want clients to be able to validate config before sending > it to the server, we have to say that s-c leafs are not created > until after validation. ... There's validation, and then there's validation. Talking about validation as though it only happens once is not helpful. Way back in the rcdml discussions, it quickly became clear that there were multiple kinds (or phases) of validation, differing primarily in the completeness of the information available to the validating entity. There are things that a client simply is not in a position to validate, and s-c items are just one of many examples. It might be helpful to the discussion to be explicit about the possible kinds of validations, and their limitations. Randy From cfinss@dial.pipex.com Thu Oct 22 11:13: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 D4A4028C169 for ; Thu, 22 Oct 2009 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.747 X-Spam-Level: X-Spam-Status: No, score=0.747 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_50=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt5rJuaBY-3X for ; Thu, 22 Oct 2009 11:13:13 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id BB2BA28C135 for ; Thu, 22 Oct 2009 11:13:12 -0700 (PDT) X-Trace: 206238153/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.83/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.83 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEANI94Eo+vGRT/2dsb2JhbACDJYFPjBy6AZFGCoEogjpTBA X-IronPort-AV: E=Sophos;i="4.44,606,1249254000"; d="scan'208";a="206238153" X-IP-Direction: IN Received: from 1cust83.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.83]) by smtp.pipex.tiscali.co.uk with SMTP; 22 Oct 2009 19:13:20 +0100 Message-ID: <001d01ca533a$9bf650a0$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> <20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> <001601ca5234$6d6cbbe0$0601a8c0@allison> <1256126057.5927.104.camel@missotis> Date: Thu, 22 Oct 2009 19:07:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 18:13:14 -0000 ----- Original Message ----- From: "Ladislav Lhotka" Sent: Wednesday, October 21, 2009 1:54 PM > tom.petch píše v St 21. 10. 2009 v 11:53 +0200: > > ---- Original Message ----- > > From: "Ladislav Lhotka" > > Sent: Monday, October 19, 2009 2:26 PM > > > > > Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: > > > > Ladislav Lhotka wrote: > > > > > I don't think s-c leafs are worth these complications. > > > > > > > > So what is your proposal? > > > > > > Keep this issue outside of YANG as implementation dependent. The three > > > types of leafs currently are: > > > > > > 1. Mandatory - must be present, otherwise the configuration is not > > > valid. > > > > and I assume must be created by client, system has no choice > > It depends on the point(s) in the workflow where validity is checked and > enforced. If it is at commit time, both client and server have a chance > to supply the mandatory leaf. However, YANG only says the leaf must be > there when the configuration is required to be valid, nothing more. So I > think this also covers your case 5. > > > > > > 2. Optional, no default - needn't be present, the system must be > > > able to operate without them. > > > > so I assume may be created by client else not present (in any sense, not > > visible in any retrieval operation) > > Yes. > > > > > > 3. Optional, default specified in DM - needn't be present, in which > > > case the server must behave exactly as if they are present and have > > > the default value. > > > > so may be created by client if not must be 'created' with default value > > by system (and so visible in some form of retrieval) > > Yes, with-defaults=report-all. > > > > > which leaves out two possible use cases (looking back to see what > > came up in earlier discussions) > > > > 4 may be created by client else may be created by system else not present > > (so may be visible in some form of retrieval if system did create it) > > This case doesn't make much sense to me, unless the value of the leaf is > completely irrelevant. Lada Two reasons for suggesting this somewhat vague case. More importantly, the other cases are hedged around with restrictions, some overt, others that Andy comes up with, so this is a get out, saying that we may not have thought of everything that a data modeller wants to do, and this allows them to specify what they want in the description clause. Less importantly, I am wondering how to model an interface slot, which may have a ethernet card or may have an HDLC card, each with a different set of parameters; simple approach is to allow the lot, and let the user/system sort out which they need in any particular instant. TomPetch > > > > 5 may be created by client else must be created by system but data model > > cannot suggest a suitable value (visible in some form of retrieval) > > > > Lada > > > Tom Petch > > > > > Do we need anything else? > > > > > > Lada > > > > > > > > > > > > > > > /martin > > > -- From andy@netconfcentral.com Thu Oct 22 12:15: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 1FF7B28C1A1 for ; Thu, 22 Oct 2009 12:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6, UNPARSEABLE_RELAY=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 HVpOcq71dg1C for ; Thu, 22 Oct 2009 12:15:27 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 17E4328C126 for ; Thu, 22 Oct 2009 12:15:27 -0700 (PDT) Received: from [68.142.200.221] by n20.bullet.mail.mud.yahoo.com with NNFMP; 22 Oct 2009 19:15:35 -0000 Received: from [68.142.201.73] by t9.bullet.mud.yahoo.com with NNFMP; 22 Oct 2009 19:15:35 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 22 Oct 2009 19:15:35 -0000 X-Yahoo-Newman-Id: 501189.93692.bm@omp425.mail.mud.yahoo.com Received: (qmail 66650 invoked from network); 22 Oct 2009 19:15:35 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 22 Oct 2009 12:15:34 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 302Iz88VM1mNnLwUb6EEBR0V0ntWBGX5mOTIxHVr22yyLDiVKqKGGwrRhxWdtbMImi_2f0UnJTcSSZ0e5o9mDfVogugyI5CK.ZHQ6TLhztlvSmhG6Ueg4skrQJlgRdSZk2qH65xJKFez0rj1Q8j3ASTSqVqqv9PsWT6nH8xaU5OVqVK1A1RYeEFzBIVQS0s3UzVNboyg.QggyZIo1udgg7rkzKbeLTobZ0j.GpXSKG_314JLZbJKAlZWBrlmh2jNgEQ6QSZYueenqDIZjnS1JWFoC0pQx4VISYWpS9Xr0fX2KxIFdCLO X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE0AF56.9050800@netconfcentral.com> Date: Thu, 22 Oct 2009 12:15:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <20091019111221.GD4765@elstar.local> <20091019.133706.19084232.mbj@tail-f.com> <1255953369.22426.49.camel@missotis> <20091019.140404.251361587.mbj@tail-f.com> <1255955177.22426.69.camel@missotis> <001601ca5234$6d6cbbe0$0601a8c0@allison> <1256126057.5927.104.camel@missotis> <001d01ca533a$9bf650a0$0601a8c0@allison> In-Reply-To: <001d01ca533a$9bf650a0$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 19:15:28 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" > Sent: Wednesday, October 21, 2009 1:54 PM > >> tom.petch píše v St 21. 10. 2009 v 11:53 +0200: >>> ---- Original Message ----- >>> From: "Ladislav Lhotka" >>> Sent: Monday, October 19, 2009 2:26 PM >>> >>>> Martin Bjorklund píše v Po 19. 10. 2009 v 14:04 +0200: >>>>> Ladislav Lhotka wrote: >>>>>> I don't think s-c leafs are worth these complications. >>>>> So what is your proposal? >>>> Keep this issue outside of YANG as implementation dependent. The three >>>> types of leafs currently are: >>>> >>>> 1. Mandatory - must be present, otherwise the configuration is not >>>> valid. >>> and I assume must be created by client, system has no choice >> It depends on the point(s) in the workflow where validity is checked and >> enforced. If it is at commit time, both client and server have a chance >> to supply the mandatory leaf. However, YANG only says the leaf must be >> there when the configuration is required to be valid, nothing more. So I >> think this also covers your case 5. >> >>>> 2. Optional, no default - needn't be present, the system must be >>>> able to operate without them. >>> so I assume may be created by client else not present (in any sense, not >>> visible in any retrieval operation) >> Yes. >> >>>> 3. Optional, default specified in DM - needn't be present, in which >>>> case the server must behave exactly as if they are present and have >>>> the default value. >>> so may be created by client if not must be 'created' with default value >>> by system (and so visible in some form of retrieval) >> Yes, with-defaults=report-all. >> >>> which leaves out two possible use cases (looking back to see what >>> came up in earlier discussions) >>> >>> 4 may be created by client else may be created by system else not present >>> (so may be visible in some form of retrieval if system did create it) >> This case doesn't make much sense to me, unless the value of the leaf is >> completely irrelevant. > > Lada > > Two reasons for suggesting this somewhat vague case. More importantly, > the other cases are hedged around with restrictions, some overt, others > that Andy comes up with, so this is a get out, saying that we may not > have thought of everything that a data modeller wants to do, and this > allows them to specify what they want in the description clause. > > Less importantly, I am wondering how to model an interface slot, which > may have a ethernet card or may have an HDLC card, each with a different > set of parameters; simple approach is to allow the lot, and let the user/system > sort out which they need in any particular instant. > >From the POV of a data model designer, the s-c leaf proposal is just too fragile. Just because the server MAY provide a value is no reason to write the YANG module with kid gloves, making sure no conceptual referential integrity requirements include an s-c leaf. This is only relevant in a small number of corner-cases, not nearly 'all' s-c leafs, as the proposal claims. If the s-c leaf is created during boot-up or if was already added to running before the session started, then the client is expected to treat the s-c leaf as just a normal leaf. Since we keep discussing the s-c-stmt, instead of agreeing to leave it out of YANG 1.0: Summary of proposed changes to s-c stmt: 1) All s-c leafs are part of the validation model. 2) The server MAY create an s-c leaf at any time in either candidate or running, providing the config remains valid. 3) Validation of s-c leafs in candidate is only assured during a real operation, not a operation or off-line validation procedure. 4) mandatory-stmt is allowed with s-c-stmt. true=node MUST exist, as before; if s-c=false, then client MUST provide, otherwise server MAY provide and client must make sure server will do this (read the description-stmt). 5) All s-c nodes are explicit nodes, except if a deviation adds a YANG default, and the leaf contains that value. 6) It is better practice to use a deviation-stmt to add a vendor-specific default, than to use an s-c-stmt. They are not the same thing. Usage guidelines for s-c leafs are still very unclear. 7) The description-stmt SHOULD be used to specify if/when/how the server creation requirement is SHOULD or MUST, instead of a MAY requirement (if s-c=true). > TomPetch Andy From phil@juniper.net Thu Oct 22 12:37: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 CA5E728C114 for ; Thu, 22 Oct 2009 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, 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 Ra4Z4m7HOuNf for ; Thu, 22 Oct 2009 12:37:16 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 0D6C728C197 for ; Thu, 22 Oct 2009 12:37:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSuC0chjF5ypJMSwM8/KRIiSvCGhBg0I3@postini.com; Thu, 22 Oct 2009 12:37: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.375.2; Thu, 22 Oct 2009 12:32:31 -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, 22 Oct 2009 12:32:31 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:32:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:32:30 -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 n9MJWRj62003; Thu, 22 Oct 2009 12:32:28 -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 n9MJJUvh075390; Thu, 22 Oct 2009 19:19:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910221919.n9MJJUvh075390@idle.juniper.net> To: Andy Bierman In-Reply-To: <4AE0AF56.9050800@netconfcentral.com> Date: Thu, 22 Oct 2009 15:19:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Oct 2009 19:32:30.0286 (UTC) FILETIME=[65237EE0:01CA534E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 19:37:17 -0000 Andy Bierman writes: >From the POV of a data model designer, the s-c leaf proposal >is just too fragile. Just because the server MAY provide >a value is no reason to write the YANG module with kid gloves, >making sure no conceptual referential integrity requirements >include an s-c leaf. Following the rules is no more "kid gloves" than not having config nodes to refer to non-config data. >This is only relevant in a small >number of corner-cases, not nearly 'all' s-c leafs, as the proposal claims. What "'all'" in the proposal are your referring to? > 1) All s-c leafs are part of the validation model. -1, since I want the client to be able to validate the config. If the s-c leafs are required for validation, then the client can't validate. > 2) The server MAY create an s-c leaf at any time > in either candidate or running, providing the > config remains valid. -1, since this impacts interoperability. If I make a list of users, some with and some without uids, the "any time" means user A may make user B invalid for some implementations. > 3) Validation of s-c leafs in candidate is only assured during a > real operation, not a operation or off-line > validation procedure. -1, since I want the client to be able to validate the config. Not allowing validation during a operation is silly. Not allowing offline validation goes in the face of all our work to allow clients to know they are sending valid config, instead of the old "fire and pray" approach. > 4) mandatory-stmt is allowed with s-c-stmt. > true=node MUST exist, as before; if s-c=false, then > client MUST provide, otherwise server MAY provide and client > must make sure server will do this (read the description-stmt). -1, since I want the client to be able to validate the config. If an s-c leaf can be mandatory, then the client cannot validate. > 5) All s-c nodes are explicit nodes, except if a deviation adds a YANG default, > and the leaf contains that value. Don't follow you here. > 6) It is better practice to use a deviation-stmt to add a > vendor-specific default, than to use an s-c-stmt. > They are not the same thing. Usage guidelines for s-c leafs > are still very unclear. +1 > 7) The description-stmt SHOULD be used to specify if/when/how > the server creation requirement is SHOULD or MUST, instead > of a MAY requirement (if s-c=true). +1 Thanks, Phil From andy@netconfcentral.com Thu Oct 22 13:05: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 853DA3A69DB for ; Thu, 22 Oct 2009 13:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0cVKXjimiGx for ; Thu, 22 Oct 2009 13:05:51 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id AB9A33A69D3 for ; Thu, 22 Oct 2009 13:05:51 -0700 (PDT) Received: (qmail 45861 invoked from network); 22 Oct 2009 20:06:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 22 Oct 2009 20:05:59 -0000 X-YMail-OSG: GmhZjiAVM1noFAtje_yDEaCey8OG3ZdCsNYFIu5HJ_jRfYHyFO.eUm.DdtjvDu0xlWcCjnPDFFIvjW2RHnBr2ZN0k1p9mj4DADdBY0sNrDJp2b4qwKyNEQ4nkivKg2D3J8t3pJ.gszEMun5KOVWa0OWKetLx.giGG4v9QluiwJtdQ0KfhPo7BE.Rp0r9VK44MZNCVic3ZLQVD6u6GvtMt7NQhFrWIUJS3wJyV3bzP4YJqSfzmfTX6Dt9Ee5FVMzCpprVujBGEEBhd7xzakTddAojEqoYhBhThmZ_QSpDTggPn2f5Ntkz.k_rXzH0QvZb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE0BB27.3050401@netconfcentral.com> Date: Thu, 22 Oct 2009 13:05:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910221919.n9MJJUvh075390@idle.juniper.net> In-Reply-To: <200910221919.n9MJJUvh075390@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 20:05:52 -0000 Phil Shafer wrote: There are several people who think the s-c leaf MUST be part of the validation model. It seems to be a majority to me. The consensus seems about split on server MAY vs. MUST create as well. I expect the co-Chairs to determine consensus based on mailing list input at some point, instead of relying on in-person input at the IETF meeting. Andy > Andy Bierman writes: >>From the POV of a data model designer, the s-c leaf proposal >> is just too fragile. Just because the server MAY provide >> a value is no reason to write the YANG module with kid gloves, >> making sure no conceptual referential integrity requirements >> include an s-c leaf. > > Following the rules is no more "kid gloves" than not having config > nodes to refer to non-config data. > >> This is only relevant in a small >> number of corner-cases, not nearly 'all' s-c leafs, as the proposal claims. > > What "'all'" in the proposal are your referring to? > >> 1) All s-c leafs are part of the validation model. > > -1, since I want the client to be able to validate the config. > > If the s-c leafs are required for validation, then the client > can't validate. > >> 2) The server MAY create an s-c leaf at any time >> in either candidate or running, providing the >> config remains valid. > > -1, since this impacts interoperability. > > If I make a list of users, some with and some without uids, > the "any time" means user A may make user B invalid for > some implementations. > >> 3) Validation of s-c leafs in candidate is only assured during a >> real operation, not a operation or off-line >> validation procedure. > > -1, since I want the client to be able to validate the config. > > Not allowing validation during a operation is silly. > Not allowing offline validation goes in the face of all our > work to allow clients to know they are sending valid config, > instead of the old "fire and pray" approach. > >> 4) mandatory-stmt is allowed with s-c-stmt. >> true=node MUST exist, as before; if s-c=false, then >> client MUST provide, otherwise server MAY provide and client >> must make sure server will do this (read the description-stmt). > > -1, since I want the client to be able to validate the config. > > If an s-c leaf can be mandatory, then the client cannot validate. > >> 5) All s-c nodes are explicit nodes, except if a deviation adds a YANG default, >> and the leaf contains that value. > > Don't follow you here. > >> 6) It is better practice to use a deviation-stmt to add a >> vendor-specific default, than to use an s-c-stmt. >> They are not the same thing. Usage guidelines for s-c leafs >> are still very unclear. > > +1 > >> 7) The description-stmt SHOULD be used to specify if/when/how >> the server creation requirement is SHOULD or MUST, instead >> of a MAY requirement (if s-c=true). > > +1 > > Thanks, > Phil > From mbj@tail-f.com Thu Oct 22 13:42: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 8F6403A6956 for ; Thu, 22 Oct 2009 13:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM+vbgnHkO2Y for ; Thu, 22 Oct 2009 13:42:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8B0443A6919 for ; Thu, 22 Oct 2009 13:42:49 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C655616002; Thu, 22 Oct 2009 22:42:58 +0200 (CEST) Date: Thu, 22 Oct 2009 22:42:58 +0200 (CEST) Message-Id: <20091022.224258.35591954.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AE0BB27.3050401@netconfcentral.com> References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@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] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 20:42:50 -0000 Andy Bierman wrote: > There are several people who think the s-c leaf MUST > be part of the validation model. It seems to be a majority > to me. Note that the revised proposal says that s-c leafs are not created until after validation, so their initial value is not available for validation, but the server MUST NOT assign value which breaks any constraint. I don't think the majority is against this? > The consensus seems about split on server MAY vs. MUST create > as well. I have just seen Randy proposing this. > I expect the co-Chairs to determine consensus > based on mailing list input at some point, instead of relying > on in-person input at the IETF meeting. I agree that we do not have consensus to add s-c. The first question is if we can agree that this is a data modeling issue, and not an implementation issue? I see a couple of alternatives in order to move forward: 1a. Do nothing. Let implementations and data models figure out how/if/when/why the server can modify the configuration data. 1b. As 1a. but add text that documents this. 2a. Add text that says that the server MUST NOT modify config data unless dictated by the data model (through description clauses or future extensions). 2b. Add text that says that the server is free to modify config data in any way it wants, unless constrained by the data model (through description clauses or future extensions). 3. Add formal statements (e.g. the current s-c) to control how the server can modfiy config. My preference would be 3 or 2a. /martin From mbj@tail-f.com Thu Oct 22 13:46: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 B542928C114 for ; Thu, 22 Oct 2009 13:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.086, 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 oFz1aB-06dnn for ; Thu, 22 Oct 2009 13:46:43 -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 EED593A69F0 for ; Thu, 22 Oct 2009 13:46:42 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AAED3616002; Thu, 22 Oct 2009 22:46:52 +0200 (CEST) Date: Thu, 22 Oct 2009 22:46:52 +0200 (CEST) Message-Id: <20091022.224652.97646831.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AE07E7C.6080803@netconfcentral.com> References: <4AE07E7C.6080803@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 20:46:43 -0000 Andy Bierman wrote: > Hi, > > The rules for updating a module changed in -08. This was based on your comments. I thought we agreed that this was necessary, b/c of typedef defaults and import w/o revision. > It is unrealistic to forbid the addition of > a default-stmt. The likely usage in standards > will be to add a default after a few years. Ok, so an alternative could be this: A "default" statement can be added to a leaf that does not have a default value (either directly or indirectly through its type). Do we agree that a default cannot be modified? /martin From andy@netconfcentral.com Thu Oct 22 14:07: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 E88DB3A68D0 for ; Thu, 22 Oct 2009 14:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 5YLQpOJi4rfR for ; Thu, 22 Oct 2009 14:07:11 -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 4DF2928C101 for ; Thu, 22 Oct 2009 14:07:11 -0700 (PDT) Received: (qmail 51415 invoked from network); 22 Oct 2009 21:07:18 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 22 Oct 2009 14:07:18 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 3yMSYYkVM1nPLNLF_J2nlHHdVumorz8aoa25BZougfBucc7Yv4h977YJXR4DrLq9PNzuzZGn9QTb2HHHpnUPkw904qR13Nn44HIe0TIZwkcguT_aVKdrCX4DPOxKGWBBCGQWTvsL0gznOuDPyhl.7.Fh90mxVM6xnff1r3Kkt3pw4sXuzCYpRcwZnS3CDGTIUDQAkjxVGXASPGMopMuHe4j9MQwyhmyNGmGMbDZv2NpK36tLp.V2pYKtprV8R.dGZCkfRQA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE0C986.8050800@netconfcentral.com> Date: Thu, 22 Oct 2009 14:07:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> In-Reply-To: <20091022.224652.97646831.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 21:07:12 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The rules for updating a module changed in -08. > > This was based on your comments. I thought we agreed that this was > necessary, b/c of typedef defaults and import w/o revision. > >> It is unrealistic to forbid the addition of >> a default-stmt. The likely usage in standards >> will be to add a default after a few years. > > Ok, so an alternative could be this: > > A "default" statement can be added to a leaf that does not have a > default value (either directly or indirectly through its type). > A default can always be added to a leaf, regardless of the default in the type-stmt. It takes precedence over the typedef. > Do we agree that a default cannot be modified? > yes > > > /martin > Andy From mbj@tail-f.com Thu Oct 22 14:12: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 8351C3A687D for ; Thu, 22 Oct 2009 14:12:34 -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 gNh8x67dpp85 for ; Thu, 22 Oct 2009 14:12:33 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A8FF73A67E3 for ; Thu, 22 Oct 2009 14:12:33 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 681AB616002; Thu, 22 Oct 2009 23:12:43 +0200 (CEST) Date: Thu, 22 Oct 2009 23:12:43 +0200 (CEST) Message-Id: <20091022.231243.205162044.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AE0C986.8050800@netconfcentral.com> References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <4AE0C986.8050800@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2009 21:12:34 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> The rules for updating a module changed in -08. > > > > This was based on your comments. I thought we agreed that this was > > necessary, b/c of typedef defaults and import w/o revision. > > > >> It is unrealistic to forbid the addition of > >> a default-stmt. The likely usage in standards > >> will be to add a default after a few years. > > > > Ok, so an alternative could be this: > > > > A "default" statement can be added to a leaf that does not have a > > default value (either directly or indirectly through its type). > > > > A default can always be added to a leaf, > regardless of the default in the type-stmt. > It takes precedence over the typedef. Right, but the problem is, as you pointed out, if we have this: typedef foo { type int32; default 42; } leaf bar { type foo; } Now, bar has '42' as default value. In the next rev we do: leaf bar { type foo; default 4711; // we were allowed to add a default stmt } The effect is that we modified the default value of bar, and we agreed that you're not allowed to modify a default value. /martin From andy@netconfcentral.com Thu Oct 22 18:25: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 35CD23A697F for ; Thu, 22 Oct 2009 18:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 JE3U4kvd54Y8 for ; Thu, 22 Oct 2009 18:25:24 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 625793A6968 for ; Thu, 22 Oct 2009 18:25:24 -0700 (PDT) Received: (qmail 78601 invoked from network); 23 Oct 2009 01:25:32 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 23 Oct 2009 01:25:31 -0000 X-YMail-OSG: 4k3N7IoVM1lFJW1MgiVt2g1fiZVGRI2y.LulhpXoBeS3bESoCmET7CcLkwEA5OpyEVVoffxmXPK1sOAD7R.krzCXUgcLYqixJCE34SdXk5GlD5zzd5HAnmfN3_ESAWhsL3fymU4DILoY6E7WXSWqdE1h7ZCdUka8vhPpvqVwyAryjo126qkraw4pt04pKMt9_SXXQNlLaL5YEgtK190HdzHqs3xOjRfk3sBHuYIyPm9MzUdgPMqLi0iERqTGKmgY9g1qo4XQ0SyslMGL_CeTDGHCIKtoRTl5.PmtXe7sRzmt.ktrZ7HVYNDKV5GpniXGeJxq68bZpvJdgRzet_uK52VvxbvBL_DaBNPwHngMe8py5Fg5TrtV7en5sdrAVA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1060D.30202@netconfcentral.com> Date: Thu, 22 Oct 2009 18:25:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <4AE0C986.8050800@netconfcentral.com> <20091022.231243.205162044.mbj@tail-f.com> In-Reply-To: <20091022.231243.205162044.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 01:25:25 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> The rules for updating a module changed in -08. >>> This was based on your comments. I thought we agreed that this was >>> necessary, b/c of typedef defaults and import w/o revision. >>> >>>> It is unrealistic to forbid the addition of >>>> a default-stmt. The likely usage in standards >>>> will be to add a default after a few years. >>> Ok, so an alternative could be this: >>> >>> A "default" statement can be added to a leaf that does not have a >>> default value (either directly or indirectly through its type). >>> OK -- this text is fine. Andy >> A default can always be added to a leaf, >> regardless of the default in the type-stmt. >> It takes precedence over the typedef. > > Right, but the problem is, as you pointed out, if we have this: > > typedef foo { > type int32; > default 42; > } > > leaf bar { > type foo; > } > > Now, bar has '42' as default value. > > In the next rev we do: > > leaf bar { > type foo; > default 4711; // we were allowed to add a default stmt > } > > The effect is that we modified the default value of bar, and we agreed > that you're not allowed to modify a default value. > > > /martin > From lhotka@cesnet.cz Fri Oct 23 01:55:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D7F3A67F3 for ; Fri, 23 Oct 2009 01:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT-lKonC+iW0 for ; Fri, 23 Oct 2009 01:55:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 27DB83A6768 for ; Fri, 23 Oct 2009 01:55:47 -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 224CBD800E8; Fri, 23 Oct 2009 10:55:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20091022.224258.35591954.mbj@tail-f.com> References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 23 Oct 2009 10:55:55 +0200 Message-Id: <1256288155.5261.31.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 08:55:49 -0000 Hi, I'd really appreciate if we put this discussion off for now and resume it after YANG 1.0. As we saw in IPFIX examples, the system-created leafs may sometimes be device-specific defaults and sometimes sort of operational values. Also, Kent previously suggested other server actions similar to s-c. So I think we need a broader view of the problem. Anyway, few comments are below. Martin Bjorklund píše v Čt 22. 10. 2009 v 22:42 +0200: > Andy Bierman wrote: > > There are several people who think the s-c leaf MUST > > be part of the validation model. It seems to be a majority > > to me. > > Note that the revised proposal says that s-c leafs are not created > until after validation, so their initial value is not available for > validation, but the server MUST NOT assign value which breaks any > constraint. I don't think the majority is against this? I'd prefer to have all data available for validation at some point. I also don't like the fact that the current semantics of mandatory is lost for these leafs. > > > The consensus seems about split on server MAY vs. MUST create > > as well. > > I have just seen Randy proposing this. No, I also support MUST. > > > I expect the co-Chairs to determine consensus > > based on mailing list input at some point, instead of relying > > on in-person input at the IETF meeting. > > I agree that we do not have consensus to add s-c. > > The first question is if we can agree that this is a data modeling > issue, and not an implementation issue? I am now inclined towards considering it an implementation issue. > > > I see a couple of alternatives in order to move forward: > > 1a. Do nothing. Let implementations and data models figure out > how/if/when/why the server can modify the configuration data. This is my preferred choice for YANG 1.0. Lada > > 1b. As 1a. but add text that documents this. > > 2a. Add text that says that the server MUST NOT modify config data > unless dictated by the data model (through description clauses > or future extensions). > > 2b. Add text that says that the server is free to modify config data > in any way it wants, unless constrained by the data model > (through description clauses or future extensions). > > 3. Add formal statements (e.g. the current s-c) to control how the > server can modfiy config. > > > My preference would be 3 or 2a. > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Fri Oct 23 05:42: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 0FADB3A689D for ; Fri, 23 Oct 2009 05:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 9VsajKFI-FB6 for ; Fri, 23 Oct 2009 05:42:55 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 304AF3A62C1 for ; Fri, 23 Oct 2009 05:42:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSuGk07G9S6+x7RPEToxtvIDRVIDb5nm0@postini.com; Fri, 23 Oct 2009 05:43:06 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 23 Oct 2009 05:39:44 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 05:39:44 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 05:39:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 05:39:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9NCdgj66883; Fri, 23 Oct 2009 05:39:42 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9NCQjsT083004; Fri, 23 Oct 2009 12:26:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910231226.n9NCQjsT083004@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1256288155.5261.31.camel@missotis> Date: Fri, 23 Oct 2009 08:26:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Oct 2009 12:39:43.0571 (UTC) FILETIME=[E5707230:01CA53DD] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 12:42:57 -0000 Ladislav Lhotka writes: >> > The consensus seems about split on server MAY vs. MUST create >> > as well. >> I have just seen Randy proposing this. >No, I also support MUST. Can you explain what extra information "MUST" would denote to either the client or the server? The server will know what it needs to do based on the description (since the contents will need special code implementing what the description says will be allowed). The client knows that anytime it ships a config that is missing an s-c leaf, it must refetch the config if it wants to see what the leaf will contain. "MUST" does not change the behavior of either side, but forces the hand of the modeler, who may only want a "MAY". Thanks, Phil From lhotka@cesnet.cz Fri Oct 23 06:21: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 349F23A6900 for ; Fri, 23 Oct 2009 06:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[AWL=-0.382, 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 iHcPcI1Ys9Ac for ; Fri, 23 Oct 2009 06:21:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 563CE3A68D7 for ; Fri, 23 Oct 2009 06:21: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 D7F63D800C0; Fri, 23 Oct 2009 15:21:55 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200910231226.n9NCQjsT083004@idle.juniper.net> References: <200910231226.n9NCQjsT083004@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 23 Oct 2009 15:21:54 +0200 Message-Id: <1256304114.5261.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 13:21:47 -0000 Phil Shafer píše v Pá 23. 10. 2009 v 08:26 -0400: > Ladislav Lhotka writes: > >> > The consensus seems about split on server MAY vs. MUST create > >> > as well. > >> I have just seen Randy proposing this. > >No, I also support MUST. > > Can you explain what extra information "MUST" would denote > to either the client or the server? The server will know The client has a guarantee that the server will supply a value. As I wrote before, the server needn't be a monolithic application and for processes that cooperate through the configuration datastore it is important know that the configuration is valid and all values are in their places. > what it needs to do based on the description (since the > contents will need special code implementing what the > description says will be allowed). The client knows > that anytime it ships a config that is missing an s-c leaf, > it must refetch the config if it wants to see what the > leaf will contain. "MUST" does not change the behavior If the server only MAY set the value, it's also possible the leaf in the re-fetched config will contain nothing, right? > of either side, but forces the hand of the modeler, who > may only want a "MAY". Maybe I don't understand it properly. If the parameter in question is required for server operation - and those in the examples we had are - and client doesn't provide a value, the server can: 1. set the value in the configuration and use it internally 2. use some value behind the scenes without showing it in the configuration 3. report an error I think only 1 makes sense and I understand it as the "MUST" variant. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Fri Oct 23 06:49: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 9B5DB3A6821 for ; Fri, 23 Oct 2009 06:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 2sMzLl-en5fq for ; Fri, 23 Oct 2009 06:49:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C60383A63EB for ; Fri, 23 Oct 2009 06:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 9EE3E32317AB; Fri, 23 Oct 2009 06:49:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-163.clppva.btas.verizon.net [71.161.50.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id E084F32317AE; Fri, 23 Oct 2009 06:49:39 -0700 (PDT) Message-ID: <4AE1B473.3090702@joelhalpern.com> Date: Fri, 23 Oct 2009 09:49:39 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ladislav Lhotka References: <200910231226.n9NCQjsT083004@idle.juniper.net> <1256304114.5261.65.camel@missotis> In-Reply-To: <1256304114.5261.65.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 13:49:30 -0000 Let me rephrase your statement: "If the parameter in question is require for operation of all servers," then the modeler would want to represent it as a must. But it is pretty easy to envision cases where depending upon the implementation, the field may be necesary, useufl, or almost irrelevant. There are also modeling constructs where the field is clearly necessary in all implementations. Unfortunatley, we only have so many dimensions we can represent in the modelling language. We all know that some information ends up in the description clause. What Martin, Phil, and I have been saying is that the piece of information that seems useful to us is whether the system may choose to fill in this field during the process of committing the configuration. I.e. it will be filled in as part of the users actions. One can argue that a conservative implementation has to assume that anyway. In that case, we don't need this marking. One can also look for different value, such as the client knowing that the FIELD will be filled by the server. I consider that to be less useful. What I consider necessary at this point is that we put in text that clearly indicates what can be modified by the server, and what constraints such modifications must meet. Yours, Joel Ladislav Lhotka wrote: ... >> of either side, but forces the hand of the modeler, who >> may only want a "MAY". > > Maybe I don't understand it properly. If the parameter in question is > required for server operation - and those in the examples we had are - > and client doesn't provide a value, the server can: > > 1. set the value in the configuration and use it internally > 2. use some value behind the scenes without showing it in the > configuration > 3. report an error > > I think only 1 makes sense and I understand it as the "MUST" variant. > > Lada > From cfinss@dial.pipex.com Fri Oct 23 06:54:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F24C3A67F1 for ; Fri, 23 Oct 2009 06:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=1.725, 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 L3OUyLJQDudv for ; Fri, 23 Oct 2009 06:54:17 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 1C4413A672E for ; Fri, 23 Oct 2009 06:54:16 -0700 (PDT) X-Trace: 295313916/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.110/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.110 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEABtS4Uo+vGRu/2dsb2JhbACDI0KNKsgmCoQ1BA X-IronPort-AV: E=Sophos;i="4.44,612,1249254000"; d="scan'208";a="295313916" X-IP-Direction: IN Received: from 1cust110.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.110]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Oct 2009 14:54:25 +0100 Message-ID: <05a401ca53df$9a204920$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , References: <200910221324.n9MDOn6r072526@idle.juniper.net> <004e01ca5335$5ea4a120$6801a8c0@oemcomputer> Date: Fri, 23 Oct 2009 14:38:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:54:18 -0000 ---- Original Message ----- From: "Randy Presuhn" Sent: Thursday, October 22, 2009 6:33 PM > > From: "Phil Shafer" > > To: "Andy Bierman" > > Cc: ; "Gerhard Muenz" > > Sent: Thursday, October 22, 2009 6:24 AM > > Subject: Re: [netmod] system-creatable > ... > > If s-c leafs are required for validation, then the client > > cannot validate config before sending it to the server. Since > > we want clients to be able to validate config before sending > > it to the server, we have to say that s-c leafs are not created > > until after validation. > ... > > There's validation, and then there's validation. Talking about validation > as though it only happens once is not helpful. Way back in the > rcdml discussions, it quickly became clear that there were multiple > kinds (or phases) of validation, differing primarily in the completeness > of the information available to the validating entity. There are things that > a client simply is not in a position to validate, and s-c items are just > one of many examples. It might be helpful to the discussion to be > explicit about the possible kinds of validations, and their limitations. Absolutely. What we need is a 'validate and fix' where the server provides, as and where permitted by YANG, all the values needed to make the config in candidate valid. S-C nodes could be part of this and could then be referred to by all the logic that YANG adds to data modelling. Then a second stage would be commit to running with all the S-C nodes already provided as part of the 'validate and fix'. Edits must then be different (quite right too - people who edit running configurations deserve all that happens to them :-) Tom Petch > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Fri Oct 23 06:54:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E386A3A6821 for ; Fri, 23 Oct 2009 06:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=1.510, 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 8MR+a+nImLdH for ; Fri, 23 Oct 2009 06:54:18 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id B07F83A67ED for ; Fri, 23 Oct 2009 06:54:17 -0700 (PDT) X-Trace: 295313929/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.110/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.110 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEABtS4Uo+vGRu/2dsb2JhbACDI0KNKsgmCoQ1BA X-IronPort-AV: E=Sophos;i="4.44,612,1249254000"; d="scan'208";a="295313929" X-IP-Direction: IN Received: from 1cust110.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.110]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Oct 2009 14:54:26 +0100 Message-ID: <05a501ca53df$9ae9b3a0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Martin Bjorklund" References: <200910221919.n9MJJUvh075390@idle.juniper.net><4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> Date: Fri, 23 Oct 2009 14:50:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:54:19 -0000 ----- Original Message ----- From: "Martin Bjorklund" Sent: Thursday, October 22, 2009 10:42 PM > Andy Bierman wrote: > > There are several people who think the s-c leaf MUST > > be part of the validation model. It seems to be a majority > > to me. > > Note that the revised proposal says that s-c leafs are not created > until after validation, so their initial value is not available for > validation, but the server MUST NOT assign value which breaks any > constraint. I don't think the majority is against this? I am against it. It just slices off part of the 'config' and stops us using the good things of YANG, the extra logic it brings, against a part of the config. I do not see many things as CLRs, but I do see this as one. Rather, redefine validate to let it create S-C nodes and then validate afterwards. I am also in Randy's MUST camp, not MAY. And if I have to choose one of the options below - I do not want to - then 2b would be my preferred choice. Tom Petch > > > The consensus seems about split on server MAY vs. MUST create > > as well. > > I have just seen Randy proposing this. > > > I expect the co-Chairs to determine consensus > > based on mailing list input at some point, instead of relying > > on in-person input at the IETF meeting. > > I agree that we do not have consensus to add s-c. > > The first question is if we can agree that this is a data modeling > issue, and not an implementation issue? > > I see a couple of alternatives in order to move forward: > > 1a. Do nothing. Let implementations and data models figure out > how/if/when/why the server can modify the configuration data. > > 1b. As 1a. but add text that documents this. > > 2a. Add text that says that the server MUST NOT modify config data > unless dictated by the data model (through description clauses > or future extensions). > > 2b. Add text that says that the server is free to modify config data > in any way it wants, unless constrained by the data model > (through description clauses or future extensions). > > 3. Add formal statements (e.g. the current s-c) to control how the > server can modfiy config. > > My preference would be 3 or 2a. > > /martin From lhotka@cesnet.cz Fri Oct 23 07:07: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 7C7CB3A6842 for ; Fri, 23 Oct 2009 07:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-x6J3CV6CXm for ; Fri, 23 Oct 2009 07:07:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6DF893A67E1 for ; Fri, 23 Oct 2009 07:07:49 -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 E69DCD800C0; Fri, 23 Oct 2009 16:07:59 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4AE1B473.3090702@joelhalpern.com> References: <200910231226.n9NCQjsT083004@idle.juniper.net> <1256304114.5261.65.camel@missotis> <4AE1B473.3090702@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 23 Oct 2009 16:07:58 +0200 Message-Id: <1256306878.5261.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 14:07:50 -0000 Joel M. Halpern píše v Pá 23. 10. 2009 v 09:49 -0400: > Let me rephrase your statement: > "If the parameter in question is require for operation of all servers," > then the modeler would want to represent it as a must. > But it is pretty easy to envision cases where depending upon the > implementation, the field may be necesary, useufl, or almost irrelevant. Can you give me an example? I don't get how this varying relevance could occur for the same data model. Lada > There are also modeling constructs where the field is clearly > necessary in all implementations. > > Unfortunatley, we only have so many dimensions we can represent in the > modelling language. We all know that some information ends up in the > description clause. What Martin, Phil, and I have been saying is that > the piece of information that seems useful to us is whether the system > may choose to fill in this field during the process of committing the > configuration. I.e. it will be filled in as part of the users actions. > One can argue that a conservative implementation has to assume that > anyway. In that case, we don't need this marking. > One can also look for different value, such as the client knowing that > the FIELD will be filled by the server. I consider that to be less useful. > > What I consider necessary at this point is that we put in text that > clearly indicates what can be modified by the server, and what > constraints such modifications must meet. > > Yours, > Joel > > Ladislav Lhotka wrote: > ... > >> of either side, but forces the hand of the modeler, who > >> may only want a "MAY". > > > > Maybe I don't understand it properly. If the parameter in question is > > required for server operation - and those in the examples we had are - > > and client doesn't provide a value, the server can: > > > > 1. set the value in the configuration and use it internally > > 2. use some value behind the scenes without showing it in the > > configuration > > 3. report an error > > > > I think only 1 makes sense and I understand it as the "MUST" variant. > > > > Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Oct 23 07:27: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 51B5F3A67E1 for ; Fri, 23 Oct 2009 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emcMNx69oBWs for ; Fri, 23 Oct 2009 07:27:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 376333A67D9 for ; Fri, 23 Oct 2009 07:27: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 97D98D800C0; Fri, 23 Oct 2009 16:27:38 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <05a401ca53df$9a204920$0601a8c0@allison> References: <200910221324.n9MDOn6r072526@idle.juniper.net> <004e01ca5335$5ea4a120$6801a8c0@oemcomputer> <05a401ca53df$9a204920$0601a8c0@allison> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 23 Oct 2009 16:27:37 +0200 Message-Id: <1256308057.5261.87.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 14:27:29 -0000 tom.petch píše v Pá 23. 10. 2009 v 14:38 +0200: > ---- Original Message ----- > From: "Randy Presuhn" > Sent: Thursday, October 22, 2009 6:33 PM > > > > From: "Phil Shafer" > > > To: "Andy Bierman" > > > Cc: ; "Gerhard Muenz" > > > Sent: Thursday, October 22, 2009 6:24 AM > > > Subject: Re: [netmod] system-creatable > > ... > > > If s-c leafs are required for validation, then the client > > > cannot validate config before sending it to the server. Since > > > we want clients to be able to validate config before sending > > > it to the server, we have to say that s-c leafs are not created > > > until after validation. > > ... > > > > There's validation, and then there's validation. Talking about validation > > as though it only happens once is not helpful. Way back in the > > rcdml discussions, it quickly became clear that there were multiple > > kinds (or phases) of validation, differing primarily in the completeness > > of the information available to the validating entity. There are things that > > a client simply is not in a position to validate, and s-c items are just > > one of many examples. It might be helpful to the discussion to be > > explicit about the possible kinds of validations, and their limitations. > > Absolutely. What we need is a 'validate and fix' where the server provides, > as and where permitted by YANG, all the values needed to make the config > in candidate valid. S-C nodes could be part of this and could then be referred > to by all the logic that YANG adds to data modelling. > > Then a second stage would be commit to running with all the S-C nodes > already provided as part of the 'validate and fix'. > > Edits must then be different (quite right too - people who edit running > configurations deserve all that happens to them :-) I agree. I tried to outline a validation procedure in the DSDL mapping draft, including two different phases - "full" and "noref" (the latter doesn't check referential integrity). However, I believe these issues are not specific to DSDL validation, so they should be addressed probably in the architecture draft. The split between our two camps probably has to do with the dual role that a data model plays - validation capabilities versus guidelines for server implementors. I do admit I put emphasis on the former role. Lada > > Tom Petch > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Oct 23 07:30:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53463A683E for ; Fri, 23 Oct 2009 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=0.627, 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 fu68+RpFFtCS for ; Fri, 23 Oct 2009 07:30:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F07DD3A67D9 for ; Fri, 23 Oct 2009 07:30:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D42DEC0057; Fri, 23 Oct 2009 16:30:26 +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 c2vkP4Ct9h-4; Fri, 23 Oct 2009 16:30:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9C87C0042; Fri, 23 Oct 2009 16:30:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 88F42D53F44; Fri, 23 Oct 2009 16:30:24 +0200 (CEST) Date: Fri, 23 Oct 2009 16:30:24 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091023143024.GB10059@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091022.224652.97646831.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default 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, 23 Oct 2009 14:30:18 -0000 On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: > Ok, so an alternative could be this: > > A "default" statement can be added to a leaf that does not have a > default value (either directly or indirectly through its type). > > Do we agree that a default cannot be modified? Can someone remind me what the rationale is? Adding a default statement causes an implementation that happens not to use the default value to be non-compliant. We get the same effect if someone changes a default value. Note that adding a default statement to something that has already an implicit default does not hurt if the value is the same... /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 Oct 23 07:41: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 D82C63A67E6 for ; Fri, 23 Oct 2009 07:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 s6K69Df337I3 for ; Fri, 23 Oct 2009 07:41:19 -0700 (PDT) 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 825D13A67D9 for ; Fri, 23 Oct 2009 07:41:19 -0700 (PDT) Received: from [68.142.194.244] by n13.bullet.mail.mud.yahoo.com with NNFMP; 23 Oct 2009 14:41:28 -0000 Received: from [68.142.201.243] by t2.bullet.mud.yahoo.com with NNFMP; 23 Oct 2009 14:41:28 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 23 Oct 2009 14:41:28 -0000 X-Yahoo-Newman-Id: 680502.12999.bm@omp404.mail.mud.yahoo.com Received: (qmail 60973 invoked from network); 23 Oct 2009 14:41:28 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 23 Oct 2009 07:41:27 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: tKtCa.wVM1lPEy6mi_3KesolSXOQ37MStnavqrhqPnquh20sdl9pvzVDWKkXh7hbGSif9SXXBkhFzrIS9BbZ.KnSVL86PhTSabKEjrWBWZcRLBtD_QAilG3I7YBliMEBnG4iz4nN1bNKR6aiPG5RSsqoxh7UkPh2yFAxXHIuhxxvpR3jChpmK.hAZxe9WXQ8s._mJ5FZnqxB8Rw7n99XUUyA77e1MZkHMCz4UcGCd9Ky2NxIWcohrH7dmx1DuAa5IZCNY1oKM2jxMkUl8GXpgsU.WXYN204J X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1C09C.4050601@netconfcentral.com> Date: Fri, 23 Oct 2009 07:41:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200910231226.n9NCQjsT083004@idle.juniper.net> <1256304114.5261.65.camel@missotis> <4AE1B473.3090702@joelhalpern.com> In-Reply-To: <4AE1B473.3090702@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 14:41:21 -0000 Joel M. Halpern wrote: > Let me rephrase your statement: > "If the parameter in question is require for operation of all servers," > then the modeler would want to represent it as a must. > But it is pretty easy to envision cases where depending upon the > implementation, the field may be necesary, useufl, or almost irrelevant. > There are also modeling constructs where the field is clearly necessary > in all implementations. > > Unfortunatley, we only have so many dimensions we can represent in the > modelling language. We all know that some information ends up in the > description clause. What Martin, Phil, and I have been saying is that > the piece of information that seems useful to us is whether the system > may choose to fill in this field during the process of committing the > configuration. I.e. it will be filled in as part of the users actions. > One can argue that a conservative implementation has to assume that > anyway. In that case, we don't need this marking. > One can also look for different value, such as the client knowing that > the FIELD will be filled by the server. I consider that to be less useful. > > What I consider necessary at this point is that we put in text that > clearly indicates what can be modified by the server, and what > constraints such modifications must meet. > I guess I am in the MUST camp, although I prefer to leave s-c-stmt out of YANG. >From the client developer perspective, 'server MAY create' is very close to useless. It certainly is not worth all the CLRs that come with this bit of meta-data. All config=true objects MUST be part of the configuration validation model. A 3rd party app cannot rely on MAY create, and so the server-creatable aspect of the leaf is of no use. The client will set everything explicitly instead. A 1st or 2nd party developer may be used to hacking code to get it to work with ad-hoc server CLI. They may bother (through trial and error) to hard-code various objects to use the s-c value instead. Unlike other standard node types, there doesn't seem to be much standard behavior in an s-c leaf at all. > Yours, > Joel > Andy > Ladislav Lhotka wrote: > ... >>> of either side, but forces the hand of the modeler, who >>> may only want a "MAY". >> >> Maybe I don't understand it properly. If the parameter in question is >> required for server operation - and those in the examples we had are - >> and client doesn't provide a value, the server can: >> >> 1. set the value in the configuration and use it internally >> 2. use some value behind the scenes without showing it in the >> configuration >> 3. report an error >> >> I think only 1 makes sense and I understand it as the "MUST" variant. >> >> Lada >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Fri Oct 23 07:50: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 5AF413A6784 for ; Fri, 23 Oct 2009 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 4kOv9GbgLTG6 for ; Fri, 23 Oct 2009 07:50:57 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id BCDFC3A63EB for ; Fri, 23 Oct 2009 07:50:56 -0700 (PDT) Received: (qmail 13872 invoked from network); 23 Oct 2009 14:51:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 23 Oct 2009 14:51:04 -0000 X-YMail-OSG: vXdFL0kVM1l1ucN4dF06s7gJAZ69u92hKr_6Yx61zYU.EWRdlwayy2MuAk.SdR218BPRIxdIGgBPSmki2arUuIUarfGjK9Vo3GPNdfWLXRy993Bs.V71RoTROyTiFUStL4fa9lO2fb8UuZ6Cg7s43jKX_5ppZwk0Eg31wGJLab_ZNBgPzp2iE3zg5_soPnCL_CExSxnXBHQGVT5WX6Oq3AYZwHEYmB_2e8HAwd4I1isRuK94p4J0Mm.wRHNdhMLjCT36wL1VDlnPU_ECLWlBNhYuBNldhOKwCszOkC2071vWowujPeKA9gFdT6YHkUSV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1C2DC.9000500@netconfcentral.com> Date: Fri, 23 Oct 2009 07:51:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <20091023143024.GB10059@elstar.local> In-Reply-To: <20091023143024.GB10059@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 14:50:58 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: > >> Ok, so an alternative could be this: >> >> A "default" statement can be added to a leaf that does not have a >> default value (either directly or indirectly through its type). >> >> Do we agree that a default cannot be modified? > > Can someone remind me what the rationale is? Adding a default > statement causes an implementation that happens not to use the default > value to be non-compliant. We get the same effect if someone changes a > default value. The server is compliant to the version with the same revision-date that is advertised in the . There may be 50 new versions of the data model that the server is not compliant with. So what? Let's say the ipfix leafs that end up with vendor-defaults get implemented by several vendors. After a few years, the IPFIX WG notices that consensus has developed for a particular default value. It increases interoperability to add a MUST requirement to the standard, such as a default. Clients have to deal with micro-versioning in YANG. If you assume the current revision that you happen to implement is the only version that could ever exist, your code may not work all the time. A CLR preventing the addition of a default is not going to lower client complexity 1 bit. It will just raise complexity for YANG writers. > > Note that adding a default statement to something that has already an > implicit default does not hurt if the value is the same... > > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Oct 23 08:00: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 2CA413A68F6 for ; Fri, 23 Oct 2009 08:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.598, 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 ZULuIEIgB-VZ for ; Fri, 23 Oct 2009 08:00: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 4201D3A689D for ; Fri, 23 Oct 2009 08:00:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA5E5C000D; Fri, 23 Oct 2009 17:00:10 +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 FTNzHrhMtNpr; Fri, 23 Oct 2009 17:00: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 B306EC000E; Fri, 23 Oct 2009 17:00:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C02CD541E6; Fri, 23 Oct 2009 17:00:08 +0200 (CEST) Date: Fri, 23 Oct 2009 17:00:08 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091023150008.GA10254@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <20091023143024.GB10059@elstar.local> <4AE1C2DC.9000500@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE1C2DC.9000500@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-08: changing a default 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, 23 Oct 2009 15:00:07 -0000 On Fri, Oct 23, 2009 at 04:51:08PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: > > > >> Ok, so an alternative could be this: > >> > >> A "default" statement can be added to a leaf that does not have a > >> default value (either directly or indirectly through its type). > >> > >> Do we agree that a default cannot be modified? > > > > Can someone remind me what the rationale is? Adding a default > > statement causes an implementation that happens not to use the default > > value to be non-compliant. We get the same effect if someone changes a > > default value. > > The server is compliant to the version > with the same revision-date that is advertised > in the . There may be 50 new versions > of the data model that the server is not compliant with. So what? > > Let's say the ipfix leafs that end up with vendor-defaults > get implemented by several vendors. After a few years, > the IPFIX WG notices that consensus has developed for > a particular default value. It increases interoperability > to add a MUST requirement to the standard, such as a default. > > Clients have to deal with micro-versioning in YANG. > If you assume the current revision that > you happen to implement is the only version > that could ever exist, your code may not work all the time. > > A CLR preventing the addition of a default is not going to > lower client complexity 1 bit. It will just raise > complexity for YANG writers. I guess I did not express my question well. Trying again: If we allow adding defaults (because version matters), why is it then forbidden to modify a default? /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 Oct 23 08:18: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 B70193A6836 for ; Fri, 23 Oct 2009 08:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 UYY497qbh2f4 for ; Fri, 23 Oct 2009 08:18:24 -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 0F1013A67E4 for ; Fri, 23 Oct 2009 08:18:24 -0700 (PDT) Received: (qmail 8933 invoked from network); 23 Oct 2009 15:18:32 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 23 Oct 2009 08:18:32 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: fTr._kgVM1ncI7kJH39CJXQjAd6MQ.IP2NGYftgpBy4M53BOFyflH2PGkQ8eUawseqn1jop7_TpTwU6rxLHS5EW1ahYojWnXIf3V9X6M1sDyQeI7VEi_D0MI9u60iI6UGUrYAU0FpWz9dYeMDgL25s1RXhns.2N_XwM1GMFwfnAUlMO1hNR5E8uyRNV3ag7Zk1ZPuM3uYA.dczH2E2PiDA.ETahTntOMbfNYeSo2asRwIex7Gtuxz40IPHbo1Wev X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1C94C.2090807@netconfcentral.com> Date: Fri, 23 Oct 2009 08:18:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4AE07E7C.6080803@netconfcentral.com> <20091022.224652.97646831.mbj@tail-f.com> <20091023143024.GB10059@elstar.local> <4AE1C2DC.9000500@netconfcentral.com> <20091023150008.GA10254@elstar.local> In-Reply-To: <20091023150008.GA10254@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang-08: changing a default X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 15:18:24 -0000 Juergen Schoenwaelder wrote: > On Fri, Oct 23, 2009 at 04:51:08PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Oct 22, 2009 at 10:46:52PM +0200, Martin Bjorklund wrote: >>> >>>> Ok, so an alternative could be this: >>>> >>>> A "default" statement can be added to a leaf that does not have a >>>> default value (either directly or indirectly through its type). >>>> >>>> Do we agree that a default cannot be modified? >>> Can someone remind me what the rationale is? Adding a default >>> statement causes an implementation that happens not to use the default >>> value to be non-compliant. We get the same effect if someone changes a >>> default value. >> The server is compliant to the version >> with the same revision-date that is advertised >> in the . There may be 50 new versions >> of the data model that the server is not compliant with. So what? >> >> Let's say the ipfix leafs that end up with vendor-defaults >> get implemented by several vendors. After a few years, >> the IPFIX WG notices that consensus has developed for >> a particular default value. It increases interoperability >> to add a MUST requirement to the standard, such as a default. >> >> Clients have to deal with micro-versioning in YANG. >> If you assume the current revision that >> you happen to implement is the only version >> that could ever exist, your code may not work all the time. >> >> A CLR preventing the addition of a default is not going to >> lower client complexity 1 bit. It will just raise >> complexity for YANG writers. > > I guess I did not express my question well. Trying again: If we allow > adding defaults (because version matters), why is it then forbidden to > modify a default? > Oh -- I agree with you. One open issue is whether modules MUST use revision-stmt. If not, then *any* change made to a module is going to potentially break the client. The default-stmt is special because YANG chooses to make it special, not because it is. > /js > Andy From root@core3.amsl.com Fri Oct 23 08: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 1459A3A67E4; Fri, 23 Oct 2009 08: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: <20091023153002.1459A3A67E4@core3.amsl.com> Date: Fri, 23 Oct 2009 08:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-types-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, 23 Oct 2009 15: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-04.txt Pages : 32 Date : 2009-10-23 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-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-types-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23081735.I-D@ietf.org> --NextPart-- From phil@juniper.net Fri Oct 23 09:51:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A0E3A6914 for ; Fri, 23 Oct 2009 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga20eI8XZd00 for ; Fri, 23 Oct 2009 09:51:08 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id D0C933A68AD for ; Fri, 23 Oct 2009 09:51:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSuHfA3eQcaqj2AJ4XbuGpN0tutn8ZZL+@postini.com; Fri, 23 Oct 2009 09:51: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.375.2; Fri, 23 Oct 2009 09:47:39 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 09:47:39 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 09:47:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 09:47:37 -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 n9NGlbj76359; Fri, 23 Oct 2009 09:47:37 -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 n9NGYdaG085435; Fri, 23 Oct 2009 16:34:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910231634.n9NGYdaG085435@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1256304114.5261.65.camel@missotis> Date: Fri, 23 Oct 2009 12:34:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Oct 2009 16:47:37.0908 (UTC) FILETIME=[873C2740:01CA5400] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 16:51:08 -0000 Ladislav Lhotka writes: >> Can you explain what extra information "MUST" would denote >> to either the client or the server? The server will know >The client has a guarantee that the server will supply a value. But I'm trying to understand why the guarantee matters to the client and how it changes any behavior on the part of the client. If the client wants post-s-c config, it knows that it needs to refetch it, and that post-s-c config may still not contain the s-c leaf. >As I wrote before, the server needn't be a monolithic application and >for processes that cooperate through the configuration datastore it is >important know that the configuration is valid and all values are in >their places. If the server didn't see the need to set the s-c leaf, we know that the description must allow this. Our client can rest assured that all config is valid and in the right place, even if that means an s-c leaf does not exist. >If the server only MAY set the value, it's also possible the leaf in the >re-fetched config will contain nothing, right? Yes. Thanks, Phil From andy@netconfcentral.com Fri Oct 23 10:19: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 2AC493A6849 for ; Fri, 23 Oct 2009 10:19:20 -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.469, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 qIFEddkvn7sx for ; Fri, 23 Oct 2009 10:19:19 -0700 (PDT) Received: from n22a.bullet.mail.mud.yahoo.com (n22a.bullet.mail.mud.yahoo.com [68.142.207.188]) by core3.amsl.com (Postfix) with SMTP id 4206A3A6784 for ; Fri, 23 Oct 2009 10:19:19 -0700 (PDT) Received: from [68.142.200.224] by n22.bullet.mail.mud.yahoo.com with NNFMP; 23 Oct 2009 17:19:28 -0000 Received: from [68.142.201.71] by t5.bullet.mud.yahoo.com with NNFMP; 23 Oct 2009 17:19:28 -0000 Received: from [127.0.0.1] by omp423.mail.mud.yahoo.com with NNFMP; 23 Oct 2009 17:19:28 -0000 X-Yahoo-Newman-Id: 399296.2004.bm@omp423.mail.mud.yahoo.com Received: (qmail 8746 invoked from network); 23 Oct 2009 17:19:27 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 23 Oct 2009 10:19:27 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ggEa.DwVM1ntDtvXnNi8pM3DJrI2phNLlP2dkShyYtCBYmhqA.wkQn86XnRMEDUo2wIZOot7m_sC.q5aVBRa8ymR0qRvEjwFfNeY.V2fDGIBUKvzSRfBE1GaEQ_ZElGWWfGNO4UbEEr0XzYoxMjSSwSPIoOkytceQwNMyQHoRzXiv5V43PsdCtghduTCcpR.Ek1Ho0ru0w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1E5A5.4070405@netconfcentral.com> Date: Fri, 23 Oct 2009 10:19:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910231634.n9NGYdaG085435@idle.juniper.net> In-Reply-To: <200910231634.n9NGYdaG085435@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 17:19:20 -0000 Phil Shafer wrote: > Ladislav Lhotka writes: >>> Can you explain what extra information "MUST" would denote >>> to either the client or the server? The server will know >> The client has a guarantee that the server will supply a value. > > But I'm trying to understand why the guarantee matters to the client > and how it changes any behavior on the part of the client. If > the client wants post-s-c config, it knows that it needs to refetch > it, and that post-s-c config may still not contain the s-c leaf. > If the client can rely on the server to create a reasonable value, then the client developer does not need to write code to set that leaf. (MUST) Since the client developer cannot rely on the server to create a reasonable default (MAY), the developer can either ignore that leaf or write code to support it. If the client ignores the leaf (at its own peril), then it doesn't really matter who creates that leaf, i.e., server or some other application. If there is code to set the leaf explicitly, then the client will use it every time, and not guess/wait-and-see what the server will do. Either way, the s-c boolean has no real value to the client developer. >> As I wrote before, the server needn't be a monolithic application and >> for processes that cooperate through the configuration datastore it is >> important know that the configuration is valid and all values are in >> their places. > > If the server didn't see the need to set the s-c leaf, we > know that the description must allow this. Our client > can rest assured that all config is valid and in the right > place, even if that means an s-c leaf does not exist. > >> If the server only MAY set the value, it's also possible the leaf in the >> re-fetched config will contain nothing, right? > > Yes. > > Thanks, > Phil Andy From randy_presuhn@mindspring.com Fri Oct 23 10:24: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 E66CA3A68B8 for ; Fri, 23 Oct 2009 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=-0.729, 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 8UAjZN1fFngI for ; Fri, 23 Oct 2009 10:24:16 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id E37853A6851 for ; Fri, 23 Oct 2009 10:24:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QVb6rpQ1rWcU8O6htMRecfvLnsa+EbOAJdMKfjcd4QtAImi1szT0z0qUnnq2BNIk; 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 [99.41.54.98] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N1NsI-0006c7-CK for netmod@ietf.org; Fri, 23 Oct 2009 13:24:26 -0400 Message-ID: <005701ca5405$eaa2fc00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910231634.n9NGYdaG085435@idle.juniper.net> Date: Fri, 23 Oct 2009 10:26:10 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f90c170cd40c88ccbe0b8b2c129f31a5c0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.98 Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 17:24:17 -0000 Hi - > From: "Phil Shafer" > To: "Ladislav Lhotka" > Cc: > Sent: Friday, October 23, 2009 9:34 AM > Subject: Re: [netmod] use cases was: finish up > > Ladislav Lhotka writes: > >> Can you explain what extra information "MUST" would denote > >> to either the client or the server? The server will know > >The client has a guarantee that the server will supply a value. > > But I'm trying to understand why the guarantee matters to the client > and how it changes any behavior on the part of the client. If > the client wants post-s-c config, it knows that it needs to refetch > it, and that post-s-c config may still not contain the s-c leaf. You're only looking at part of the problem. The difference is in how the value is allocated. With the "MAY" behaviour, the client needs to replicate whatever allocation logic the server should have had, in case the server didn't feel like allocating one that day. With the "MUST" behaviour, client implementors don't need to replicate that logic unless they have some other compelling reason to. For the cases of "s-c" that I'd care about, the only times a client would supply an s-c value would be in a configuration restore from archive, or to ensure parameter consistency across systems after initially allocated on a "master". > >As I wrote before, the server needn't be a monolithic application and > >for processes that cooperate through the configuration datastore it is > >important know that the configuration is valid and all values are in > >their places. > > If the server didn't see the need to set the s-c leaf, we > know that the description must allow this. Our client > can rest assured that all config is valid and in the right > place, even if that means an s-c leaf does not exist. But that means the data wouldn't be merely s-c. From an information modeling perspective, it is truly optional. What's happening here looks like an attempt to to ram two closely-related models together and pretend that they are a single model. The implementation which requires the s-c bit of information and the implementation which does not require that bit of information are clearly working with different information models, even if the only difference between the two models is the optionality of that bit of information. Randy From phil@juniper.net Fri Oct 23 11:39:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1DB3A6856 for ; Fri, 23 Oct 2009 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 YfckH-stmrge for ; Fri, 23 Oct 2009 11:39:38 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E0D393A6844 for ; Fri, 23 Oct 2009 11:39:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSuH4c0PLSkhAG9oNQ19tvKImq2oZnEaV@postini.com; Fri, 23 Oct 2009 11:39:49 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 23 Oct 2009 11:36: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); Fri, 23 Oct 2009 11:36:34 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:36:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:36: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 n9NIaWj27396; Fri, 23 Oct 2009 11:36: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 n9NINZCU086343; Fri, 23 Oct 2009 18:23:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910231823.n9NINZCU086343@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <005701ca5405$eaa2fc00$6801a8c0@oemcomputer> Date: Fri, 23 Oct 2009 14:23:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Oct 2009 18:36:33.0230 (UTC) FILETIME=[BE9726E0:01CA540F] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 18:39:38 -0000 "Randy Presuhn" writes: >You're only looking at part of the problem. The difference is in how >the value is allocated. With the "MAY" behaviour, the client needs >to replicate whatever allocation logic the server should have had, in >case the server didn't feel like allocating one that day. With the "MUST" >behaviour, client implementors don't need to replicate that logic unless >they have some other compelling reason to. Consider the following slightly faked-up scenario: an IDP detection policy is shared between a set of chassis. To be shared, the policy needs a unique number, but some policies (based on the needs of the policy) are not shared and do not need this number. The system MAY create the "number" leaf if the policy needs it, but won't bother creating it if it does not need it. I guess this leaf could be made irrelevant by using a "must" statement that discards it unless the policy needs it. Thanks, Phil From randy_presuhn@mindspring.com Fri Oct 23 13:03: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 1765A3A679F for ; Fri, 23 Oct 2009 13:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 M6KTF5Yf0CPw for ; Fri, 23 Oct 2009 13:03:15 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 1B7703A6939 for ; Fri, 23 Oct 2009 13:03:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LjRID9UNNJPpI+IIYgmzIw/zskAMWGBIgM3KNkq+cBqF5PqNxh0QxQt86rH2CT5G; 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 [99.41.54.98] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N1QM7-0006R0-GY for netmod@ietf.org; Fri, 23 Oct 2009 16:03:23 -0400 Message-ID: <006e01ca541c$20916f20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910231823.n9NINZCU086343@idle.juniper.net> Date: Fri, 23 Oct 2009 13:05:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f995e2ab6d0998c29788a3a03978c3a7be350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.98 Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 20:03:16 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Friday, October 23, 2009 11:23 AM > Subject: Re: [netmod] use cases was: finish up > > "Randy Presuhn" writes: > >You're only looking at part of the problem. The difference is in how > >the value is allocated. With the "MAY" behaviour, the client needs > >to replicate whatever allocation logic the server should have had, in > >case the server didn't feel like allocating one that day. With the "MUST" > >behaviour, client implementors don't need to replicate that logic unless > >they have some other compelling reason to. > > Consider the following slightly faked-up scenario: an IDP detection > policy is shared between a set of chassis. To be shared, the policy > needs a unique number, but some policies (based on the needs of the > policy) are not shared and do not need this number. The system MAY > create the "number" leaf if the policy needs it, but won't bother > creating it if it does not need it. > > I guess this leaf could be made irrelevant by using a "must" statement > that discards it unless the policy needs it. This dives into the question of "optional" configuration data that isn't really optional - there is a (potentially complex) presence condition, in this case the semantics of the policy's "payload" that determins whether the policy is or is not shareable. Slightly different ways to look at the handling of "conditionally mandatory" stuff include (1) subclassing, though this gets messy when there are multiple "conditionally mandatory" bits; (2) packaging this stuff into aspects, though I don't see a terribly tidy way for yang to handle these; (3) wrapping the conditionally mandatory bits into types that permit "N/A" as a potential value. (To the specifics of the example, however, I think the computational burden of figuring out whether a policy would need a number would probably be greater than unconditionally assigning one. :-) However, recognizing that there are cases where s-c behaviour is useful, the conditionally mandatory case seems to me to be a corner case. I think some more experience with actual models and implementation might be needed to figure out how to do it right. For example, to what extent should the representation of the conditions be machine- readable in the model? On the other hand, this question doesn't even arise for the "MUST" interpretation. I'm not arguing that we need to do the s-c at this time. Rather, I'm arguing that if we do do s-c at this time, the MUST approach is much more tractable than the MAY approach. The MAY approach may have its legitimate uses, but doing it right means (at least to me) going through the exercise of figuring out the limits of conditionally mandatory elements in models, which in your example goes far beyond what can reasonably be expressed today. Randy From phil@juniper.net Fri Oct 23 13:22: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 E0C853A6995 for ; Fri, 23 Oct 2009 13:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZITNSSuc7I0 for ; Fri, 23 Oct 2009 13:22:57 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 07C513A6972 for ; Fri, 23 Oct 2009 13:22:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSuIQqsgWixU6oKvx+Kf2oQCOMIPofTIj@postini.com; Fri, 23 Oct 2009 13:23:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 23 Oct 2009 13:20: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); Fri, 23 Oct 2009 13:20:34 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 13:20:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 13:20: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 n9NKKWj71459; Fri, 23 Oct 2009 13:20: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 n9NK7Z5Y087642; Fri, 23 Oct 2009 20:07:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910232007.n9NK7Z5Y087642@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <006e01ca541c$20916f20$6801a8c0@oemcomputer> Date: Fri, 23 Oct 2009 16:07:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Oct 2009 20:20:33.0395 (UTC) FILETIME=[4604C430:01CA541E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 20:22:58 -0000 "Randy Presuhn" writes: >I'm not arguing that we need to do the s-c at this time. >Rather, I'm arguing that if we do do s-c at this time, >the MUST approach is much more tractable than the MAY >approach. The MAY approach may have its legitimate uses, >but doing it right means (at least to me) going through >the exercise of figuring out the limits of conditionally >mandatory elements in models, which in your example goes >far beyond what can reasonably be expressed today. My concerns are more practical. MUST forces a modeler to do something that might not be required, and the real difference (in terms of behaviors) in MUST and MAY is near zero. The client will refetch either way (if it cares). The server will be driven by the behavior required in the "description", not the "s-c" statement. Thanks, Phil From randy_presuhn@mindspring.com Fri Oct 23 13:54: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 710AF3A699D for ; Fri, 23 Oct 2009 13:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.506, 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 fvDNlLmLWQN4 for ; Fri, 23 Oct 2009 13:54:41 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id B11013A693B for ; Fri, 23 Oct 2009 13:54:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EQweXQyd14vrfSLcL8pQ2S+AfwUFuQ4xNl3vhG82dzlQjy1z1qidIO1VO3YKSByh; 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 [99.41.54.98] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N1R9w-0003xo-9N for netmod@ietf.org; Fri, 23 Oct 2009 16:54:52 -0400 Message-ID: <000401ca5423$51b9cc80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910232007.n9NK7Z5Y087642@idle.juniper.net> Date: Fri, 23 Oct 2009 13:56:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9cdcc3edded02fa301c1b0fff4e315b09350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.98 Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2009 20:54:42 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Friday, October 23, 2009 1:07 PM > Subject: Re: [netmod] use cases was: finish up ... > My concerns are more practical. MUST forces a modeler to do something > that might not be required, and the real difference (in terms of > behaviors) in MUST and MAY is near zero. As both Andy and I have pointed out, it makes a huge difference for the client implementation. > The client will refetch > either way (if it cares). That's not the point, as both Andy and I have pointed out. > The server will be driven by the behavior > required in the "description", not the "s-c" statement. The problem is what the client is required to do. If the server cannot be relied on to supply required s-c values, equivalent, or potentially more complex logic, which would otherwise not be needed, must be implemented in clients. Randy From phil@juniper.net Sun Oct 25 11:14: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 E954F3A69B5 for ; Sun, 25 Oct 2009 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 oyAP4w1RDk5P for ; Sun, 25 Oct 2009 11:14:16 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 10E5E3A69B4 for ; Sun, 25 Oct 2009 11:14:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSuSVg+HzNY1rKeaLtKXm6W9pfN9iujj5@postini.com; Sun, 25 Oct 2009 11:14:29 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 25 Oct 2009 11:14:01 -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); Sun, 25 Oct 2009 11:14:01 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 11:14:00 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 11:14:00 -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 n9PIDxj34878; Sun, 25 Oct 2009 11:13:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n9PI10v1096048; Sun, 25 Oct 2009 18:01:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910251801.n9PI10v1096048@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <000401ca5423$51b9cc80$6801a8c0@oemcomputer> Date: Sun, 25 Oct 2009 14:01:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Oct 2009 18:14:00.0526 (UTC) FILETIME=[ED2466E0:01CA559E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Oct 2009 18:14:17 -0000 "Randy Presuhn" writes: >The problem is what the client is required to do. If the server >cannot be relied on to supply required s-c values, equivalent, >or potentially more complex logic, which would otherwise not be >needed, must be implemented in clients. I don't see that. If the client doesn't care enough to give it a value when it creates the instance, and the server doesn't see a need to set it when it is validating the config, then neither side needs to set it. There's no requirement that this logic must be implemented in the clients. Thanks, Phil From andy@netconfcentral.com Sun Oct 25 11:34: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 DC87F3A6883 for ; Sun, 25 Oct 2009 11:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_64=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 ZyMLQDE7KaHq for ; Sun, 25 Oct 2009 11:34:51 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 3495E3A69BD for ; Sun, 25 Oct 2009 11:34:51 -0700 (PDT) Received: (qmail 85717 invoked from network); 25 Oct 2009 18:35:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2009 18:35:02 -0000 X-YMail-OSG: 0Oi6hhMVM1nXvyIOjzYVer43Wz_S8Vs8hb3LJ5PvcUCbZIC1RwILmO9T83fPkhOLIvVSWzGH7leIS9Y69_dIXf3.xps3z7RqkhDHwa_lM16PzGeo6XGrFZU4vBLfRq60tW2NgSeS5DjnEI7JaJYI2vwPqWlnhpD5H81WYOOZ4MIIPhVp9qf3zSMQbOCY8ibIvwpiGJisCTS6i1__xxHBsqUm4.bW1TS9wkmh2KOFxW5kjmnyJ0PV4ENI6Fj2sVmaQy8Em_.chJKxyc2QN1A5xKgioriGPiyWj2eWMbD4JZichQZcXF2JLwpWBk5sQ0B.fg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE49A65.8060800@netconfcentral.com> Date: Sun, 25 Oct 2009 11:35:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200910251801.n9PI10v1096048@idle.juniper.net> In-Reply-To: <200910251801.n9PI10v1096048@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Oct 2009 18:34:52 -0000 Phil Shafer wrote: > "Randy Presuhn" writes: >> The problem is what the client is required to do. If the server >> cannot be relied on to supply required s-c values, equivalent, >> or potentially more complex logic, which would otherwise not be >> needed, must be implemented in clients. > > I don't see that. If the client doesn't care enough to give it a > value when it creates the instance, and the server doesn't see a > need to set it when it is validating the config, then neither side > needs to set it. There's no requirement that this logic must be > implemented in the clients. > How does the client know what the server will 'see' and 'decide', wrt/ creating the leaf or not? We do not agree that the s-c leaf is part of the YANG constraints, so we cannot agree on why the client would care if the server creates a valid leaf (or not), to keep some must/when/unique constraint from causing an error. IMO, it is more important to leave the current validation model alone, and that means all config=true objects are allowed to be used in configuration database constraints. > Thanks, > Phil Andy From andy@netconfcentral.com Sun Oct 25 12:20: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 F105328C117 for ; Sun, 25 Oct 2009 12:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_50=0.001, UNPARSEABLE_RELAY=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 ohDOnlYIIjem for ; Sun, 25 Oct 2009 12:20:43 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 0311A3A692A for ; Sun, 25 Oct 2009 12:20:42 -0700 (PDT) Received: (qmail 55810 invoked from network); 25 Oct 2009 19:20:53 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2009 12:20:52 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: MnFz2XIVM1lHxb.wi1TfCV._bubkLEYjwec0VXlnxoLSzETwZGjJ7YVooBFW39kkkq785.db6fuE6kySUDbFqBLPrvCm1PGPvdWT3hYfxsykZ6x4RbFZoPLViMmbgRYIK4mjY3AlCly6s2M0xIdIPbEALm4izx0SJn4_YXEekqcFBt7h7jzEDmBhGATZAvBAeHG.XViXYwT6_arn4b_Sq2gH3.DnDNbK_karnmd59lgbZdGw2u4Mdq9AY49tpXW8gLgcmLhr31GdwVkkd1ocEbnQZ.aBeXk4f.WSDFwvUPQg9itK.N4nVg2kb_rU38g- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE4A525.2040406@netconfcentral.com> Date: Sun, 25 Oct 2009 12:21:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-types-04 bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 19:20:45 -0000 Hi, I was trying to compile this module with the version of yangdump that is about to be released, and if complained because the 'date-and-time' description-stmt is a single-quoted string, and it contains 2 single quotes (device's). YANG has no way to escape those quotes? (I think not.) Andy From randy_presuhn@mindspring.com Sun Oct 25 15:15: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 C5D223A69F6 for ; Sun, 25 Oct 2009 15:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpMO0OC5SusS for ; Sun, 25 Oct 2009 15:15:20 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id CD3CF3A6949 for ; Sun, 25 Oct 2009 15:15:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LWDOZHwJv7iGG+kqs+8fftptPWWXiVSy4fdeWCYieGy8z8Qb7125yFr3/FxHJ7EY; 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 [99.23.162.212] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N2BN6-0006YO-7F for netmod@ietf.org; Sun, 25 Oct 2009 18:15:32 -0400 Message-ID: <002501ca55c0$ecd8e680$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910251801.n9PI10v1096048@idle.juniper.net> Date: Sun, 25 Oct 2009 15:17:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f900685d60834a97552b07302734515ddd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.212 Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Oct 2009 22:15:20 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Sunday, October 25, 2009 11:01 AM > Subject: Re: [netmod] use cases was: finish up > > "Randy Presuhn" writes: > >The problem is what the client is required to do. If the server > >cannot be relied on to supply required s-c values, equivalent, > >or potentially more complex logic, which would otherwise not be > >needed, must be implemented in clients. > > I don't see that. If the client doesn't care enough to give it a > value when it creates the instance, and the server doesn't see a > need to set it when it is validating the config, then neither side > needs to set it. There's no requirement that this logic must be > implemented in the clients. If "neither side needs to set it" then it's truly optional, and the model should identify it as such. If it's truly necessary, but the server can be relied to create it if not supplied by the client - well, that seems a reasonable use of s-c. If it's what other standards would call "conditionally mandatory", then a compromise would be to say that the server MUST create it when not supplied by the client *if* the conditions that make it mandatory (presumably rigorously spelled out in description text) are satisfied. What I can't abide is just leaving it to an implementation's whims, which is what the proposed "MAY" language would do. But I think this group needs to step back a bit and think about what conditionally mandatory parameters really mean architecturally. Usually their presence corresponds to the selection of a particular capability or package of capabilities. In such case, at least at a conceptual level, they're mandatory bits within an optional presence container. Randy From j.schoenwaelder@jacobs-university.de Sun Oct 25 15:45:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B23C3A695A for ; Sun, 25 Oct 2009 15:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.549, 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 ExfrVTdWTpmc for ; Sun, 25 Oct 2009 15:45:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 407CD3A691F for ; Sun, 25 Oct 2009 15:45:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8A0AC0017; Sun, 25 Oct 2009 23:45:49 +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 BUzT8vlBH4er; Sun, 25 Oct 2009 23:45:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC657C0014; Sun, 25 Oct 2009 23:45:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C85D8D58163; Sun, 25 Oct 2009 23:45:47 +0100 (CET) Date: Sun, 25 Oct 2009 23:45:47 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20091025224547.GA16396@elstar.local> Mail-Followup-To: Randy Presuhn , "netmod@ietf.org" References: <200910251801.n9PI10v1096048@idle.juniper.net> <002501ca55c0$ecd8e680$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501ca55c0$ecd8e680$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] use cases was: finish up 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, 25 Oct 2009 22:45:38 -0000 On Sun, Oct 25, 2009 at 11:17:20PM +0100, Randy Presuhn wrote: > But I think this group needs to step back a bit and think about what > conditionally mandatory parameters really mean architecturally. Usually > their presence corresponds to the selection of a particular capability > or package of capabilities. In such case, at least at a conceptual level, > they're mandatory bits within an optional presence container. I think the YANG mechanism here are features. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Oct 25 16:10: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 D625928C18F for ; Sun, 25 Oct 2009 16:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.527, 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 MXWrU70nNUTo for ; Sun, 25 Oct 2009 16:10:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1523F28C148 for ; Sun, 25 Oct 2009 16:10:03 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7B73C0015; Mon, 26 Oct 2009 00:10:15 +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 jYDDO2-zxCY0; Mon, 26 Oct 2009 00:10:14 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B62FCC0014; Mon, 26 Oct 2009 00:10:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1E69BD58208; Mon, 26 Oct 2009 00:10:13 +0100 (CET) Date: Mon, 26 Oct 2009 00:10:13 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20091025231013.GA16427@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4AE4A525.2040406@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE4A525.2040406@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang-types-04 bug 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, 25 Oct 2009 23:10:03 -0000 On Sun, Oct 25, 2009 at 08:21:09PM +0100, Andy Bierman wrote: > I was trying to compile this module with the version of > yangdump that is about to be released, and if complained > because the 'date-and-time' description-stmt is a > single-quoted string, and it contains 2 single quotes (device's). > > YANG has no way to escape those quotes? (I think not.) Sorry for not catching this before posting the ID. I will fix this problem in the next revision. I conclude for myself that using single quote strings (that do not allow escape sequences) for textual arguments is not a good YANG usage pattern. /ks -- 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 Sun Oct 25 19:16: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 930D63A6A1E for ; Sun, 25 Oct 2009 19:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 7YYnN9TyNELS for ; Sun, 25 Oct 2009 19:16:32 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id ACEC53A6A1C for ; Sun, 25 Oct 2009 19:16:32 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSuUGjI466aA2b57ffFCFkB6Ls4AbMDCs@postini.com; Sun, 25 Oct 2009 19:16: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.375.2; Sun, 25 Oct 2009 19:12:19 -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, 25 Oct 2009 19:12:20 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 19:12:19 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 19:12:18 -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 n9Q2CIj93637; Sun, 25 Oct 2009 19:12:18 -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 n9Q1xIWJ097692; Mon, 26 Oct 2009 01:59:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910260159.n9Q1xIWJ097692@idle.juniper.net> To: "Randy Presuhn" In-Reply-To: <002501ca55c0$ecd8e680$6801a8c0@oemcomputer> Date: Sun, 25 Oct 2009 21:59:18 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Oct 2009 02:12:18.0592 (UTC) FILETIME=[BE85C200:01CA55E1] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Oct 2009 02:16:33 -0000 "Randy Presuhn" writes: >If it's what other standards would call "conditionally mandatory", >then a compromise would be to say that the server MUST create it >when not supplied by the client *if* the conditions that make it >mandatory (presumably rigorously spelled out in description text) >are satisfied. What I can't abide is just leaving it to >an implementation's whims, which is what the proposed "MAY" >language would do. I read "MUST if xxxx" as "MAY", in which case "conditionally mandatory" means "the implementor must read the description to know what they are doing", which is unavoidable on the server side. I do not read "MAY" as the "implementation's whims", since the implementor must live by the rules in the description. Thanks, Phil From lhotka@cesnet.cz Mon Oct 26 05:41: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 D11D23A6828 for ; Mon, 26 Oct 2009 05:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M77kW5Gm5ycR for ; Mon, 26 Oct 2009 05:41:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CC4C03A6807 for ; Mon, 26 Oct 2009 05:41:07 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 750ABD80095; Mon, 26 Oct 2009 13:41:20 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20091025231013.GA16427@elstar.local> References: <4AE4A525.2040406@netconfcentral.com> <20091025231013.GA16427@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 26 Oct 2009 13:41:18 +0100 Message-Id: <1256560878.21590.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] yang-types-04 bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:41:08 -0000 Juergen Schoenwaelder píše v Po 26. 10. 2009 v 00:10 +0100: > On Sun, Oct 25, 2009 at 08:21:09PM +0100, Andy Bierman wrote: > > > I was trying to compile this module with the version of > > yangdump that is about to be released, and if complained > > because the 'date-and-time' description-stmt is a > > single-quoted string, and it contains 2 single quotes (device's). > > > > YANG has no way to escape those quotes? (I think not.) > > Sorry for not catching this before posting the ID. I will fix this > problem in the next revision. I conclude for myself that using single > quote strings (that do not allow escape sequences) for textual > arguments is not a good YANG usage pattern. Hmm, where does the draft say that an unescaped apostrophe (single-quote) is illegal in a double-quoted string? It only says: A single quote character cannot occur in a single quoted string, even when preceded by a backslash. IMO "'" represents a legal YANG string consisting of one single-quote character. Lada > > /ks > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Oct 26 05:54: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 990E33A6768 for ; Mon, 26 Oct 2009 05:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=0.341, 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 YR6Ti0g1FVYW for ; Mon, 26 Oct 2009 05:54:13 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B101A28C0E2 for ; Mon, 26 Oct 2009 05:54:13 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C371FD800CC for ; Mon, 26 Oct 2009 13:54:24 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <1256560878.21590.6.camel@missotis> References: <4AE4A525.2040406@netconfcentral.com> <20091025231013.GA16427@elstar.local> <1256560878.21590.6.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 26 Oct 2009 13:54:23 +0100 Message-Id: <1256561663.21590.9.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] yang-types-04 bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:54:14 -0000 Ladislav Lhotka píše v Po 26. 10. 2009 v 13:41 +0100: > Juergen Schoenwaelder píše v Po 26. 10. 2009 v 00:10 +0100: > > On Sun, Oct 25, 2009 at 08:21:09PM +0100, Andy Bierman wrote: > > > > > I was trying to compile this module with the version of > > > yangdump that is about to be released, and if complained > > > because the 'date-and-time' description-stmt is a > > > single-quoted string, and it contains 2 single quotes (device's). > > > > > > YANG has no way to escape those quotes? (I think not.) > > > > Sorry for not catching this before posting the ID. I will fix this > > problem in the next revision. I conclude for myself that using single > > quote strings (that do not allow escape sequences) for textual > > arguments is not a good YANG usage pattern. > > Hmm, where does the draft say that an unescaped apostrophe > (single-quote) is illegal in a double-quoted string? It only says: > > A single quote character cannot occur in a single > quoted string, even when preceded by a backslash. > > IMO "'" represents a legal YANG string consisting of one single-quote > character. Oops, I misunderstood the problem, sorry for the confusion. Perhaps the string "'" could be listed among the special strings in 6.1.3.1. Lada > > Lada > > > > > /ks > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From spakes@snmp.com Mon Oct 26 07:27:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C173A68ED for ; Mon, 26 Oct 2009 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtf8gO8h45YC for ; Mon, 26 Oct 2009 07:27:25 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id C22CB3A68AA for ; Mon, 26 Oct 2009 07:27:24 -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 KAA24530; Mon, 26 Oct 2009 10:27:34 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA10273; Mon, 26 Oct 2009 10:27:34 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 26 Oct 2009 10:27:34 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] float vs. decimal (fwd) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Oct 2009 14:27:26 -0000 Between March 11 and June 9, there was a lengthy discussion on this list that resulted in a proposal to add a derived type called 'real' to draft-ietf-netmod-yang-types-04. The proposal was submitted in its final form (below) before WGLC for draft-ietf-netmod-yang-types-03 ended on June 10. The draft-ietf-netmod-yang-types-04 document is out now and I see that the new derived type was not included. Juergen's alternative proposal to make decimal64's fraction-digits substatement be optional (15-May) is not reflected in draft-ietf-netmod-yang-08 either. Was this omission done intentionally, and if so, why? -David typedef real { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } type decimal64 { fraction-digits 17; range "-9.99999999999999999 .. 9.99999999999999999"; } type decimal64 { fraction-digits 16; range "-99.9999999999999999 .. 99.9999999999999999"; } type decimal64 { fraction-digits 15; range "-999.999999999999999 .. 999.999999999999999"; } type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The real type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type real is able to express configuration and state data as any of the real numbers in the set. The real type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. Positive numbers larger than 99999999999999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -99999999999999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -99999999999999999.9 and 99999999999999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the real type through rounding or truncation. For example, pi could be rounded (up) to 3.14159265358979324 or truncated to 3.14159265358979323 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } On Wed, 27 May 2009, David Partain wrote: > This is the working group last call on the current working group > document: > > - Common YANG Data Types: > http://tools.ietf.org/html/draft-ietf-netmod-yang-types-03.txt > > The editor and the chairs think that this document is mature enough for > WGLC. This WGLC will last until June 10, 2009. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From randy_presuhn@mindspring.com Mon Oct 26 11:00: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 E52AE3A6AC5 for ; Mon, 26 Oct 2009 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMIP5WqOdQ-B for ; Mon, 26 Oct 2009 11:00:19 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id AFC913A6B2C for ; Mon, 26 Oct 2009 11:00:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HcD12IpKLuXgVl6MBHWPJiHkqwnsHWy3BdWDKrMAzFOEtW7Ah4/nR5I7vGmktp+u; 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 [99.41.54.155] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N2Tro-00067K-Qr for netmod@ietf.org; Mon, 26 Oct 2009 14:00:29 -0400 Message-ID: <001001ca5666$77c91440$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910260159.n9Q1xIWJ097692@idle.juniper.net> Date: Mon, 26 Oct 2009 11:02:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f916e81c3900d4920c611dd9d5c8e6dae5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.155 Subject: Re: [netmod] use cases was: finish up X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 26 Oct 2009 18:00:21 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Sunday, October 25, 2009 6:59 PM > Subject: Re: [netmod] use cases was: finish up ... > I read "MUST if xxxx" as "MAY", in which case "conditionally > mandatory" means "the implementor must read the description to know > what they are doing", which is unavoidable on the server side. > I do not read "MAY" as the "implementation's whims", since > the implementor must live by the rules in the description. RFC 2119 doesn't support that reading. It says "[t]his word, or the adjective 'OPTIONAL', mean[s] that an item is truly optional." Randy From root@core3.amsl.com Mon Oct 26 11: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 65B0828C2BB; Mon, 26 Oct 2009 11:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026184501.65B0828C2BB@core3.amsl.com> Date: Mon, 26 Oct 2009 11:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-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, 26 Oct 2009 18: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 : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-02.txt Pages : 28 Date : 2009-10-26 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-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-usage-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26114309.I-D@ietf.org> --NextPart-- From david.partain@ericsson.com Tue Oct 27 06:56: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 4154B3A684A for ; Tue, 27 Oct 2009 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYUv1V1jVDtA for ; Tue, 27 Oct 2009 06:56:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 409773A6955 for ; Tue, 27 Oct 2009 06:56:23 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-27-4ae6fc146f86 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 68.B2.24026.41CF6EA4; Tue, 27 Oct 2009 14:56:36 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 14:56:36 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 14:56:35 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 27 Oct 2009 14:56:35 +0100 User-Agent: KMail/1.9.10 References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> In-Reply-To: <20091022.224258.35591954.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: <200910271456.35311.david.partain@ericsson.com> X-OriginalArrivalTime: 27 Oct 2009 13:56:35.0886 (UTC) FILETIME=[4C3EDCE0:01CA570D] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 13:56:24 -0000 Hi, The various documents have been updated in advance of the upcoming IETF, and, unless I'm mistaken, we seem to have one sticky issue left to clear up, and that is what to do about system-creatable. Last week, Martin published a set of possible choices of what we could do. It would be helpful if everyone who cares would reply to this message telling me / the group what you think the right answer is. The choices are below. If you think there are other possible choices, please say so. I've renumbered just to try to make it clearer what you're "voting" for. 1. Do nothing in the draft and let implementations and data models figure out how/if/when/why the server can modify the configuration data. 2. Do nothing but write in the document that we _know_ it's an issue but we're still not doing anything. 3. Add text that says that the server MUST NOT modify config data unless dictated by the data model (through description clauses or future extensions). 4. Add text that says that the server is free to modify config data in any way it wants, unless constrained by the data model (through description clauses or future extensions). 5. Add formal statements (e.g. the current s-c) to control how the server can modfiy config. Please let your voice be heard as soon as possible. Please try to choose one... Thanks. David From jmh@joelhalpern.com Tue Oct 27 07:04:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E562A28C205 for ; Tue, 27 Oct 2009 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 dtHnzBfHEVJZ for ; Tue, 27 Oct 2009 07:04:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3D07B28C1F2 for ; Tue, 27 Oct 2009 07:04:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id DB13E32317AD; Tue, 27 Oct 2009 07:04:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-52-196.clppva.btas.verizon.net [71.161.52.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 23F1232317AB; Tue, 27 Oct 2009 07:04:24 -0700 (PDT) Message-ID: <4AE6FDE8.7080706@joelhalpern.com> Date: Tue, 27 Oct 2009 10:04:24 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Partain References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> In-Reply-To: <200910271456.35311.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 14:04:11 -0000 You said "Please try to choose one..." With that dictum in mind: 5 would be my preference. I will say that I think 1 would be a serious mistake, as it is likely to induce interoperability failures. Yours, Joel David Partain wrote: > Hi, > > The various documents have been updated in advance of the upcoming IETF, and, > unless I'm mistaken, we seem to have one sticky issue left to clear up, and > that is what to do about system-creatable. > > Last week, Martin published a set of possible choices of what we could do. > > It would be helpful if everyone who cares would reply to this message telling > me / the group what you think the right answer is. > > The choices are below. If you think there are other possible choices, please > say so. I've renumbered just to try to make it clearer what you're "voting" > for. > > 1. Do nothing in the draft and let implementations and data models figure out > how/if/when/why the server can modify the configuration data. > > 2. Do nothing but write in the document that we _know_ it's an issue but we're > still not doing anything. > > 3. Add text that says that the server MUST NOT modify config data unless > dictated by the data model (through description clauses or future > extensions). > > 4. Add text that says that the server is free to modify config data in any way > it wants, unless constrained by the data model (through description clauses > or future extensions). > > 5. Add formal statements (e.g. the current s-c) to control how the server can > modfiy config. > > Please let your voice be heard as soon as possible. Please try to choose > one... > > Thanks. > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Tue Oct 27 07:15: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 063503A686A for ; Tue, 27 Oct 2009 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmO56KxNp2A3 for ; Tue, 27 Oct 2009 07:15:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 291F53A682B for ; Tue, 27 Oct 2009 07:14:53 -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 E03D1D800E8 for ; Tue, 27 Oct 2009 15:15:06 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200910271456.35311.david.partain@ericsson.com> References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 27 Oct 2009 15:15:05 +0100 Message-Id: <1256652905.12133.11.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 14:15:02 -0000 Hi David, if this choice refers to YANG 1.0, my preference is 1 but I am also fine with 2 - it could be actually helpful if the _issue_ gets formulated rather than the solution. Lada David Partain píše v Út 27. 10. 2009 v 14:56 +0100: > Hi, > > The various documents have been updated in advance of the upcoming IETF, and, > unless I'm mistaken, we seem to have one sticky issue left to clear up, and > that is what to do about system-creatable. > > Last week, Martin published a set of possible choices of what we could do. > > It would be helpful if everyone who cares would reply to this message telling > me / the group what you think the right answer is. > > The choices are below. If you think there are other possible choices, please > say so. I've renumbered just to try to make it clearer what you're "voting" > for. > > 1. Do nothing in the draft and let implementations and data models figure out > how/if/when/why the server can modify the configuration data. > > 2. Do nothing but write in the document that we _know_ it's an issue but we're > still not doing anything. > > 3. Add text that says that the server MUST NOT modify config data unless > dictated by the data model (through description clauses or future > extensions). > > 4. Add text that says that the server is free to modify config data in any way > it wants, unless constrained by the data model (through description clauses > or future extensions). > > 5. Add formal statements (e.g. the current s-c) to control how the server can > modfiy config. > > Please let your voice be heard as soon as possible. Please try to choose > one... > > Thanks. > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Oct 27 07:16: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 8C32A3A682B for ; Tue, 27 Oct 2009 07:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 471FPnR3YJmg for ; Tue, 27 Oct 2009 07:16:19 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 9A2853A6833 for ; Tue, 27 Oct 2009 07:16:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSucAweg8CcjzKgQwPXXQarh0fR7UTfDF@postini.com; Tue, 27 Oct 2009 07:16:34 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.375.2; Tue, 27 Oct 2009 07:11:13 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 07:11:13 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 07:11:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 07:11:10 -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 n9REBAj05328; Tue, 27 Oct 2009 07:11:10 -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 n9RDw9IJ016447; Tue, 27 Oct 2009 13:58:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910271358.n9RDw9IJ016447@idle.juniper.net> To: David Partain In-Reply-To: <200910271456.35311.david.partain@ericsson.com> Date: Tue, 27 Oct 2009 09:58:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Oct 2009 14:11:10.0786 (UTC) FILETIME=[55BA0220:01CA570F] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 14:16:20 -0000 David Partain writes: >1. Do nothing in the draft and let implementations and data models figure out >how/if/when/why the server can modify the configuration data. -1 >2. Do nothing but write in the document that we _know_ it's an issue but we're >still not doing anything. This is the minimum we need to do. >3. Add text that says that the server MUST NOT modify config data unless >dictated by the data model (through description clauses or future >extensions). -1. "MUST unless you make an extension" has no force. >4. Add text that says that the server is free to modify config data in any way >it wants, unless constrained by the data model (through description clauses >or future extensions). ditto. >5. Add formal statements (e.g. the current s-c) to control how the server can >modfiy config. I'd learn toward this, but I really think there's too much conflict to move down this path. s-c should be broken out into a distinct I-D. So I guess that makes me a "2". Thanks, Phil From dromasca@avaya.com Tue Oct 27 07:25: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 CC3163A693F for ; Tue, 27 Oct 2009 07:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 0ERDykqb61NH for ; Tue, 27 Oct 2009 07:25:30 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7F2993A68FB for ; Tue, 27 Oct 2009 07:25:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,633,1249272000"; d="scan'208";a="161483902" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2009 10:25:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2009 10:25:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 15:25:29 +0100 Message-ID: In-Reply-To: <200910271456.35311.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Wrapping up system-creatable Thread-Index: AcpXDVKsJFQLMZRCScGpOw65XWM+lQAA3gWw References: <200910221919.n9MJJUvh075390@idle.juniper.net><4AE0BB27.3050401@netconfcentral.com><20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> From: "Romascanu, Dan (Dan)" To: "David Partain" , Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 14:25:30 -0000 (speaking as a contributor who cares) I think that the WG MUST achieve #5 sooner or later. As I know that the nasty AD is pushing on us to deliver, it looks like we are forced to fall back on #2 right now and start working on #5 as soon as we have delivered our main chartered items.=20 Dan > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of David Partain > Sent: Tuesday, October 27, 2009 3:57 PM > To: netmod@ietf.org > Subject: [netmod] Wrapping up system-creatable >=20 > Hi, >=20 > The various documents have been updated in advance of the=20 > upcoming IETF, and, unless I'm mistaken, we seem to have one=20 > sticky issue left to clear up, and that is what to do about=20 > system-creatable. >=20 > Last week, Martin published a set of possible choices of what=20 > we could do. >=20 > It would be helpful if everyone who cares would reply to this=20 > message telling me / the group what you think the right answer is. >=20 > The choices are below. If you think there are other possible=20 > choices, please say so. I've renumbered just to try to make=20 > it clearer what you're "voting"=20 > for. >=20 > 1. Do nothing in the draft and let implementations and data=20 > models figure out how/if/when/why the server can modify the=20 > configuration data. >=20 > 2. Do nothing but write in the document that we _know_ it's=20 > an issue but we're still not doing anything. >=20 > 3. Add text that says that the server MUST NOT modify config=20 > data unless dictated by the data model (through description=20 > clauses or future extensions). >=20 > 4. Add text that says that the server is free to modify=20 > config data in any way it wants, unless constrained by the=20 > data model (through description clauses or future extensions). >=20 > 5. Add formal statements (e.g. the current s-c) to control=20 > how the server can modfiy config. >=20 > Please let your voice be heard as soon as possible. Please=20 > try to choose one... >=20 > Thanks. >=20 > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mbj@tail-f.com Tue Oct 27 07:26: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 B0E0D3A698C for ; Tue, 27 Oct 2009 07:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.079, 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 72pKYcNHszfj for ; Tue, 27 Oct 2009 07:26:36 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5E27E3A693F for ; Tue, 27 Oct 2009 07:26:36 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6320C76C220; Tue, 27 Oct 2009 15:26:49 +0100 (CET) Date: Tue, 27 Oct 2009 15:26:48 +0100 (CET) Message-Id: <20091027.152648.154058828.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200910271456.35311.david.partain@ericsson.com> References: <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.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] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 14:26:37 -0000 My votes are for 5,3,2, in that order, where 2 probably is the most realistic. /martin David Partain wrote: > The choices are below. If you think there are other possible choices, > please > say so. I've renumbered just to try to make it clearer what you're > "voting" > for. > > 1. Do nothing in the draft and let implementations and data models > figure out > how/if/when/why the server can modify the configuration data. > > 2. Do nothing but write in the document that we _know_ it's an issue > but we're > still not doing anything. > > 3. Add text that says that the server MUST NOT modify config data > unless > dictated by the data model (through description clauses or future > extensions). > > 4. Add text that says that the server is free to modify config data in > any way > it wants, unless constrained by the data model (through description > clauses > or future extensions). > > 5. Add formal statements (e.g. the current s-c) to control how the > server can > modfiy config. > > Please let your voice be heard as soon as possible. Please try to > choose > one... > > Thanks. > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Tue Oct 27 07:30: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 5B4A03A68AB for ; Tue, 27 Oct 2009 07:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.515, 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 40Ws59k8haPC for ; Tue, 27 Oct 2009 07:30:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5942F3A6832 for ; Tue, 27 Oct 2009 07:30:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D6C0C0027; Tue, 27 Oct 2009 15:30:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YwvAnHbLbel6; Tue, 27 Oct 2009 15:30:43 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88E6DC0005; Tue, 27 Oct 2009 15:30:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5D667D5B46F; Tue, 27 Oct 2009 15:30:42 +0100 (CET) Date: Tue, 27 Oct 2009 15:30:42 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20091027143042.GA18024@elstar.local> Mail-Followup-To: David Partain , "netmod@ietf.org" References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910271456.35311.david.partain@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Wrapping up system-creatable 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, 27 Oct 2009 14:30:31 -0000 On Tue, Oct 27, 2009 at 02:56:35PM +0100, David Partain wrote: > 2. Do nothing but write in the document that we _know_ it's an issue > but we're still not doing anything. I believe this is the best we can do in order to make forward progress on YANG 1.0 and taking the time to work out a good solution. It appears to me that s-c is only the tip of an iceberg. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Tue Oct 27 07:50: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 1E2893A69D1 for ; Tue, 27 Oct 2009 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 K0Ct9hCmzoqW for ; Tue, 27 Oct 2009 07:50:51 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 4BE5D3A6975 for ; Tue, 27 Oct 2009 07:50:51 -0700 (PDT) Received: (qmail 85247 invoked from network); 27 Oct 2009 14:51:04 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 27 Oct 2009 07:51:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: l_xX3s4VM1kWY2NWxBCiAn5jTyS7HdeSQuILKyJTpn3FYoT_zl070b4DSpK9ma40xxmA_TdgvHA_W1UB9L4LKTvlzeOxcq9wvHWscbHngGKZ10or8yPVpIZYvhws575KtK4NwNyQ52g4.ZruF.NhvEt6uV2Y8xWIhyEsPHBSvA0F8XNJtxbGYdCYF.olBDo2RxsfQ3Mf04mDRTnhe7LpZBXngip.ZInRbCsgs4RKiFjX3E3qCXUicX5LzAumyIOUwtdGL6Dud8BJgD5Jj5gj98CeRL0Cg4brc_6E99NVr1G0cvd_MBY3Er1eFyW1U0jK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE708F2.4050901@netconfcentral.com> Date: Tue, 27 Oct 2009 07:51:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> In-Reply-To: <200910271456.35311.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 14:50:52 -0000 David Partain wrote: > Hi, > > The various documents have been updated in advance of the upcoming IETF, and, > unless I'm mistaken, we seem to have one sticky issue left to clear up, and > that is what to do about system-creatable. > > Last week, Martin published a set of possible choices of what we could do. > > It would be helpful if everyone who cares would reply to this message telling > me / the group what you think the right answer is. > > The choices are below. If you think there are other possible choices, please > say so. I've renumbered just to try to make it clearer what you're "voting" > for. > > 1. Do nothing in the draft and let implementations and data models figure out > how/if/when/why the server can modify the configuration data. > > 2. Do nothing but write in the document that we _know_ it's an issue but we're > still not doing anything. > (2) is the best outcome we can achieve, since there is no consensus on most of the important s-c details. Nor is there consensus that s-c is sufficient in scope or utility. I don't think we understand the problem well enough to write anything really useful in the draft. > 3. Add text that says that the server MUST NOT modify config data unless > dictated by the data model (through description clauses or future > extensions). This is could be added to the Usage Guidelines I-D, so it would apply to modules in drafts. In general the data model is the only source for making decisions what the server is allowed to do for that section of the conceptual database. The implementor MUST NOT do stuff that is not specified in the data model. > > 4. Add text that says that the server is free to modify config data in any way > it wants, unless constrained by the data model (through description clauses > or future extensions). > > 5. Add formal statements (e.g. the current s-c) to control how the server can > modfiy config. > > Please let your voice be heard as soon as possible. Please try to choose > one... > > Thanks. > > David Andy From kwatsen@juniper.net Tue Oct 27 09:24: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 69B9E28C1B0 for ; Tue, 27 Oct 2009 09:24: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 86e2A33Y0afL for ; Tue, 27 Oct 2009 09:24:06 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 5748028C1A4 for ; Tue, 27 Oct 2009 09:24:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSucetCPKtwFDmlFs9h0F4BmPiJkiXjl1@postini.com; Tue, 27 Oct 2009 09:24:21 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 27 Oct 2009 09:23:09 -0700 From: Kent Watsen To: 'David Partain' , "netmod@ietf.org" Date: Tue, 27 Oct 2009 09:23:08 -0700 Thread-Topic: [netmod] Wrapping up system-creatable Thread-Index: AcpXDU/tNszsMfB4Qzq1/GV4eMULjAAFALtQ Message-ID: <84600D05C20FF943918238042D7670FD367D54B4EB@EMBX01-HQ.jnpr.net> References: <200910221919.n9MJJUvh075390@idle.juniper.net> <4AE0BB27.3050401@netconfcentral.com> <20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> In-Reply-To: <200910271456.35311.david.partain@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 16:24:07 -0000 In preference order: 1, 4, 2 As mentioned before, I will submit an ID shortly for a more holistic approa= ch for this... Thanks, Kent > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of David Partain > Sent: Tuesday, October 27, 2009 9:57 AM > To: netmod@ietf.org > Subject: [netmod] Wrapping up system-creatable >=20 > Hi, >=20 > The various documents have been updated in advance of the upcoming IETF, > and, > unless I'm mistaken, we seem to have one sticky issue left to clear up, > and > that is what to do about system-creatable. >=20 > Last week, Martin published a set of possible choices of what we could do= . >=20 > It would be helpful if everyone who cares would reply to this message > telling > me / the group what you think the right answer is. >=20 > The choices are below. If you think there are other possible choices, > please > say so. I've renumbered just to try to make it clearer what you're > "voting" > for. >=20 > 1. Do nothing in the draft and let implementations and data models figure > out > how/if/when/why the server can modify the configuration data. >=20 > 2. Do nothing but write in the document that we _know_ it's an issue but > we're > still not doing anything. >=20 > 3. Add text that says that the server MUST NOT modify config data unless > dictated by the data model (through description clauses or future > extensions). >=20 > 4. Add text that says that the server is free to modify config data in an= y > way > it wants, unless constrained by the data model (through description > clauses > or future extensions). >=20 > 5. Add formal statements (e.g. the current s-c) to control how the serve= r > can > modfiy config. >=20 > Please let your voice be heard as soon as possible. Please try to choose > one... >=20 > Thanks. >=20 > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From randy_presuhn@mindspring.com Tue Oct 27 09:57: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 60F853A685D for ; Tue, 27 Oct 2009 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXldfLK0rpYa for ; Tue, 27 Oct 2009 09:57:56 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id A4D133A67E2 for ; Tue, 27 Oct 2009 09:57:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bkw6EyDQkwOMx+fPnMyD+5zfPC49SCAfOGjNlRrkhOBaT7/rzdbOpxDRdGiwml/m; 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 [99.187.239.76] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N2pN4-0007OW-LB for netmod@ietf.org; Tue, 27 Oct 2009 12:58:10 -0400 Message-ID: <001801ca5726$eee46640$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910221919.n9MJJUvh075390@idle.juniper.net><4AE0BB27.3050401@netconfcentral.com><20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> Date: Tue, 27 Oct 2009 10:00:04 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f96e0b2ab903f6a6790e8f58fb2aaa50c9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.239.76 Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2009 16:57:57 -0000 Hi - I could live with 2. I think 3 and 4 are potentially problematic. Lots of daemons in the details. :-) I strongly oppose both 1 and 5 (if the latter is understood as being the current s-c proposal) I could support 5 if it were understood as a re-formulated s-c proposal, though I do agree with Juergen about the probable presence of icebergs. Randy From cfinss@dial.pipex.com Tue Oct 27 11:21: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 1939528C0CF for ; Tue, 27 Oct 2009 11:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=1.328, 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 rmPxzOwB1ZYA for ; Tue, 27 Oct 2009 11:21:52 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id DFFCA3A691E for ; Tue, 27 Oct 2009 11:21:51 -0700 (PDT) X-Trace: 151837871/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.23/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.23 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EACfX5ko+vGQX/2dsb2JhbACDI416yHUKhDUE X-IronPort-AV: E=Sophos;i="4.44,634,1249254000"; d="scan'208";a="151837871" X-IP-Direction: IN Received: from 1cust23.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.23]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Oct 2009 18:22:03 +0000 Message-ID: <006c01ca5729$9f071e80$0601a8c0@allison> From: "tom.petch" To: "David Partain" , References: <200910221919.n9MJJUvh075390@idle.juniper.net><4AE0BB27.3050401@netconfcentral.com><20091022.224258.35591954.mbj@tail-f.com> <200910271456.35311.david.partain@ericsson.com> Date: Tue, 27 Oct 2009 18:19:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Wrapping up system-creatable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:21:53 -0000 4 I think the best. Tom Petch ----- Original Message ----- From: "David Partain" To: Sent: Tuesday, October 27, 2009 2:56 PM Subject: [netmod] Wrapping up system-creatable > Hi, > > The various documents have been updated in advance of the upcoming IETF, and, > unless I'm mistaken, we seem to have one sticky issue left to clear up, and > that is what to do about system-creatable. > > Last week, Martin published a set of possible choices of what we could do. > > It would be helpful if everyone who cares would reply to this message telling > me / the group what you think the right answer is. > > The choices are below. If you think there are other possible choices, please > say so. I've renumbered just to try to make it clearer what you're "voting" > for. > > 1. Do nothing in the draft and let implementations and data models figure out > how/if/when/why the server can modify the configuration data. > > 2. Do nothing but write in the document that we _know_ it's an issue but we're > still not doing anything. > > 3. Add text that says that the server MUST NOT modify config data unless > dictated by the data model (through description clauses or future > extensions). > > 4. Add text that says that the server is free to modify config data in any way > it wants, unless constrained by the data model (through description clauses > or future extensions). > > 5. Add formal statements (e.g. the current s-c) to control how the server can > modfiy config. > > Please let your voice be heard as soon as possible. Please try to choose > one... > > Thanks. > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Sat Oct 31 12:49: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 A132A3A6767 for ; Sat, 31 Oct 2009 12:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, UNPARSEABLE_RELAY=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 J3W33Qy88r+a for ; Sat, 31 Oct 2009 12:49:56 -0700 (PDT) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id BEF763A6768 for ; Sat, 31 Oct 2009 12:49:56 -0700 (PDT) Received: from [209.191.108.96] by n15.bullet.mail.mud.yahoo.com with NNFMP; 31 Oct 2009 19:50:15 -0000 Received: from [68.142.201.73] by t3.bullet.mud.yahoo.com with NNFMP; 31 Oct 2009 19:50:15 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 31 Oct 2009 19:50:15 -0000 X-Yahoo-Newman-Id: 13200.38197.bm@omp425.mail.mud.yahoo.com Received: (qmail 28384 invoked from network); 31 Oct 2009 19:50:14 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 31 Oct 2009 12:50:14 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: rgb3jEcVM1lkuKNBmxOoUCh4PV08Yi2HHmtyep_oYKAtR45EG8VTCYVkKtrlrUXOxVmpuqUL.N8eJW5_QthAZ.6BcFtKGntenvgX9C52xo7H40hRs6qSFd6nkx3XkbhWJT5O0C7g85_CCX4.OUN5PTGCc66_cIVmZy3X5ro5jWG8xHNUoxO3.sg7swBpJcZQP0c6efw4JvlIaxiIKE3FnBPyXtcCE0z49OMV2wI5M5vO_E0XoCwws5shlxIhzrDr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AEC94B0.6050703@netconfcentral.com> Date: Sat, 31 Oct 2009 12:49:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 19:49:57 -0000 Hi, (Note: Some or all of these issues may have been raised before.) This is another aspect of YANG database behavior that is very broken. Consider this old MIB design translation: container toaster { ... leaf toasterControl { type enumeration { enum up { value 1; description "Abort toasting (perhaps in the event of an emergency)"; } enum down { value 2; description "Begin toasting."; } } // config true; mandatory true; description "This variable controls the current state of the toaster."; } } Will YANG support operational knobs like this? (IMO, no.) Clearly there is no intent to make the value 'sticky', or to save it across reboots. MIBs are full of operational knobs like this 'toasterControl' leaf. One solution that is not optimal is to create ad-hoc RPC verbs for every knob: rpc make-toast { ... } rpc cancel-toast { .. } A better approach is an inline 'action-stmt' extension, replacing the 'toasterControl' leaf with 'make-toast' and 'cancel-toast' actions. This is certainly not a system-created leaf. The dual-leaf (admin/oper status) approach does not apply either, because, in this case, the writable leaf is an operational button, not persistent configuration. How should YANG deal with this sort of leaf? Andy From jmh@joelhalpern.com Sat Oct 31 13:40:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5523A67D6 for ; Sat, 31 Oct 2009 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 Qi300RAYXF6I for ; Sat, 31 Oct 2009 13:40:02 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 713F73A6767 for ; Sat, 31 Oct 2009 13:40:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0BC4F32317B3; Sat, 31 Oct 2009 13:40:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 55B9A32317AF; Sat, 31 Oct 2009 13:40:20 -0700 (PDT) Message-ID: <4AECA0B6.2010708@joelhalpern.com> Date: Sat, 31 Oct 2009 16:40:22 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4AEC94B0.6050703@netconfcentral.com> In-Reply-To: <4AEC94B0.6050703@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 20:40:03 -0000 While I do not know what the right answer is for YANG, let's not get too distracted by the SNMP answer. The mechanism used for this sort of thing by SNMP is a kludge designed to work around the limitaiton where the only operations were get and set. Some sort of action semantics would seem the appropriate mecahnism for YANG / Netconf rpc. Yours, Joel Andy Bierman wrote: > Hi, > > (Note: Some or all of these issues may have been raised before.) > > This is another aspect of YANG database behavior that > is very broken. Consider this old MIB design translation: > > container toaster { > ... > leaf toasterControl { > type enumeration { > enum up { > value 1; > description > "Abort toasting (perhaps in the event of > an emergency)"; > } > enum down { > value 2; > description > "Begin toasting."; > } > } > // config true; > mandatory true; > description > "This variable controls the current state of > the toaster."; > } > } > > Will YANG support operational knobs like this? (IMO, no.) > Clearly there is no intent to make the value 'sticky', > or to save it across reboots. MIBs are full of operational > knobs like this 'toasterControl' leaf. > > One solution that is not optimal is > to create ad-hoc RPC verbs for every knob: > > rpc make-toast { ... } > > rpc cancel-toast { .. } > > A better approach is an inline 'action-stmt' extension, > replacing the 'toasterControl' leaf with 'make-toast' > and 'cancel-toast' actions. > > This is certainly not a system-created leaf. > The dual-leaf (admin/oper status) approach does not apply either, > because, in this case, the writable leaf is an operational button, > not persistent configuration. > > How should YANG deal with this sort of leaf? > > > Andy > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Sat Oct 31 14:58:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E98A3A67F3 for ; Sat, 31 Oct 2009 14:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=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 nDDQGh0TkIkj for ; Sat, 31 Oct 2009 14:58:10 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 9A9123A67A3 for ; Sat, 31 Oct 2009 14:58:10 -0700 (PDT) Received: (qmail 93095 invoked from network); 31 Oct 2009 21:58:26 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 31 Oct 2009 14:58:26 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8OaTjA4VM1m8akvLAx87bgqpGxN9BeaWtMn7sbjS2yNHh1a75SHBbm8Sr0eGXEWYy2jQAnD7A0LqQ6NOKpN098uHs4dKDyA9Ijq0DPEO4N1Tat9ZrAizo6QGPhcm2smlzEKHc02LfOS0Z5DK4nQ9hpNduC1kfv0b.D3KLWDSxzbDLJhybLo9Mlq2AUvXzAioyvi806xZDj059ypL.o8ERaZke0CYeDG37WuppzbTvefRKaSMcv7rHuKZ4NabgRJF5NFQzfnqWBYE4W7Ws.UPFqmKGDYUDn1I._XuDObIo2vHwS6rZno- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AECB2B8.6030609@netconfcentral.com> Date: Sat, 31 Oct 2009 14:57:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4AEC94B0.6050703@netconfcentral.com> <4AECA0B6.2010708@joelhalpern.com> In-Reply-To: <4AECA0B6.2010708@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] operational knobs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 21:58:11 -0000 Joel M. Halpern wrote: > While I do not know what the right answer is for YANG, let's not get too > distracted by the SNMP answer. The mechanism used for this sort of > thing by SNMP is a kludge designed to work around the limitaiton where > the only operations were get and set. > Agreed -- but I view the IETF SNMP experience as more than a distraction. We are theoretically asking IETF WGs to stop using SMIv2 and start using YANG to design data models. I think the differences, and guidelines wrt/ those differences, are relevant to a significant portion of the IETF community. > Some sort of action semantics would seem the appropriate mecahnism for > YANG / Netconf rpc. > Agreed -- so a config=true leaf like this would be the wrong YANG construct to use. The description-stmt does not override the N/Y meaning of config=true for commit/NV-save operations. BTW, I don't see any real implementation barriers to allowing actions (==inline rpc-stmt) or events (-- inline notification-stmt) but everybody has a different idea how this is supposed to work, so we should leave it out of 1.0. > Yours, > Joel Andy > > Andy Bierman wrote: >> Hi, >> >> (Note: Some or all of these issues may have been raised before.) >> >> This is another aspect of YANG database behavior that >> is very broken. Consider this old MIB design translation: >> >> container toaster { >> ... >> leaf toasterControl { >> type enumeration { >> enum up { >> value 1; >> description >> "Abort toasting (perhaps in the event of >> an emergency)"; >> } >> enum down { >> value 2; >> description >> "Begin toasting."; >> } >> } >> // config true; >> mandatory true; >> description >> "This variable controls the current state of >> the toaster."; >> } >> } >> >> Will YANG support operational knobs like this? (IMO, no.) >> Clearly there is no intent to make the value 'sticky', >> or to save it across reboots. MIBs are full of operational >> knobs like this 'toasterControl' leaf. >> >> One solution that is not optimal is >> to create ad-hoc RPC verbs for every knob: >> >> rpc make-toast { ... } >> >> rpc cancel-toast { .. } >> >> A better approach is an inline 'action-stmt' extension, >> replacing the 'toasterControl' leaf with 'make-toast' >> and 'cancel-toast' actions. >> >> This is certainly not a system-created leaf. >> The dual-leaf (admin/oper status) approach does not apply either, >> because, in this case, the writable leaf is an operational button, >> not persistent configuration. >> >> How should YANG deal with this sort of leaf? >> >> >> Andy >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >