From kwatsen@juniper.net Mon Jan 3 11:44:59 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2953A6B39 for ; Mon, 3 Jan 2011 11:44:59 -0800 (PST) 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 ImZCVWqskEdI for ; Mon, 3 Jan 2011 11:44:58 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 18CBF3A6B37 for ; Mon, 3 Jan 2011 11:44:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTSIntpq60v60O2vrnIR/E3VfIhA/+EZn@postini.com; Mon, 03 Jan 2011 11:47:05 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 3 Jan 2011 11:43:08 -0800 From: Kent Watsen To: Juergen Schoenwaelder Date: Mon, 3 Jan 2011 11:43:10 -0800 Thread-Topic: [netmod] how to know which module revision an RPC is for? Thread-Index: AcuovD1hVpjq19GDQEKeFW7jKvX21gCwV+mQ Message-ID: <84600D05C20FF943918238042D7670FD3745A2C133@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> <4D1BD759.1090207@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20101231072840.GA10546@elstar.local> In-Reply-To: <20101231072840.GA10546@elstar.local> 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] how to know which module revision an RPC is for? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Jan 2011 19:44:59 -0000 > It depends on what "break in compatibility" means.=20 I think we all know it means that some aspect of an existing client integra= tion stops working. > Which text in section 10 of RFC 6020 makes you believe that removing > "mandatory" is allowed? Section 10 says: a "mandatory" statement may be removed or changed from "tr= ue" to "false". Please see my 12/30@2:06 email for how this makes sense fo= r inputs but not outputs... Thanks, Kent From mbj@tail-f.com Fri Jan 7 05:27:30 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E676C3A68BC for ; Fri, 7 Jan 2011 05:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2xk+llCwXp3 for ; Fri, 7 Jan 2011 05:27:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8BD343A683B for ; Fri, 7 Jan 2011 05:27:27 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A851076C257; Fri, 7 Jan 2011 14:29:32 +0100 (CET) Date: Fri, 07 Jan 2011 14:29:31 +0100 (CET) Message-Id: <20110107.142931.168032226.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374562B427@EMBX01-HQ.jnpr.net> <4D1B7629.2000807@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] how to know which module revision an RPC is for? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Jan 2011 13:27:30 -0000 Hi, Kent Watsen wrote: > Hi Andy, > > > > You can add a leaf to the input for the client to request > > a specific version. > > I don't understand, can you provide an example? Oh, wait, do you > mean that the payload of the RPC itself would have a > element? I think often you can add a more explicit parameter to the input, e.g. if the new revision added a field to the output, you can add an input field to let the client indicate that it supports the new version. /martin From mbj@tail-f.com Fri Jan 7 05:34:53 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B523A68BC for ; Fri, 7 Jan 2011 05:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEi1Nd9vVmEz for ; Fri, 7 Jan 2011 05:34:52 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 71C353A683B for ; Fri, 7 Jan 2011 05:34:52 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A22E76C257; Fri, 7 Jan 2011 14:36:58 +0100 (CET) Date: Fri, 07 Jan 2011 14:36:57 +0100 (CET) Message-Id: <20110107.143657.194513514.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] how to know which module revision an RPC is for? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Jan 2011 13:34:53 -0000 Hi, > Other concerns not yet addressed: > > 1. unclear how "obsolete" status can ever be used (as to do so would break > backwards compatibility) I agree with Juergen and Andy. A robust client that sees a new revision it does not understand will have to be prepared that some nodes are obsolete and thus not implemented on the server. This is of course something that has to be taken into account when obsoleting an object. > 2. missing clarification that removing a "mandatory" statement is only allow > for inputs (RPCs and config) I think you are right that this is a bug in the spec. > 3. missing clarifying statement that clients must skip over unrecognized > elements in a response I don't think we can mandate that a client MUST skip over unrecognized elements. Maybe SHOULD. But this would be a clarification; it more or less follows from the text that a client should do this. Being explicit is of course good. > 4. no expiration policy (or are implementations to be forever backwards > compatible?) If your product implements an RFC with an obsolete object, you are "allowed" to removed the object from your implemenation. Your customers may not like it though, but then it's a business decision if you remove the object anyway :) /martin From kwatsen@juniper.net Fri Jan 7 14:36:29 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE93C28C0D8 for ; Fri, 7 Jan 2011 14:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6ueAM6lFiXR for ; Fri, 7 Jan 2011 14:36:26 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 17BA33A6992 for ; Fri, 7 Jan 2011 14:36:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTSeV6GEvFMmG1bu03Bc7UJwbqTFKd6Jv@postini.com; Fri, 07 Jan 2011 14:38:33 PST 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; Fri, 7 Jan 2011 14:34:39 -0800 From: Kent Watsen To: "netmod@ietf.org" Date: Fri, 7 Jan 2011 14:34:31 -0800 Thread-Topic: YANG-based validation? Thread-Index: Acuuuw2HDGhVaFnBSHeBme4pc0+/0w== Message-ID: <84600D05C20FF943918238042D7670FD374618C927@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A72A736D-C413-4683-BD30-16BBCDA546C3} x-cr-hashedpuzzle: AVOv AZYb CIOU Cj8M C6eO Dhi8 FYrv Gb7E GdLJ G800 Hmn5 J4bG KNm3 Kdf/ Km1o KzYW; 1; bgBlAHQAbQBvAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A72A736D-C413-4683-BD30-16BBCDA546C3}; awB3AGEAdABzAGUAbgBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Fri, 07 Jan 2011 22:34:31 GMT;WQBBAE4ARwAtAGIAYQBzAGUAZAAgAHYAYQBsAGkAZABhAHQAaQBvAG4APwA= acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_84600D05C20FF943918238042D7670FD374618C927EMBX01HQjnprn_" MIME-Version: 1.0 Subject: [netmod] YANG-based validation? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Jan 2011 22:36:29 -0000 --_000_84600D05C20FF943918238042D7670FD374618C927EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm looking for a utility to validate XML configuration and RPC messages de= fined by a YANG module. For XSD and RelaxNG schema, I would normally use `xmllint --schema` or `xml= int --relaxng`... Is the best option currently to use either `yumadump` or `pyang` to generat= e the XSD and then use xmllint? Thanks, Kent --_000_84600D05C20FF943918238042D7670FD374618C927EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
I’m looking for a utility to validate XML configuration and RPC = messages defined by a YANG module.
 
For XSD and RelaxNG schema, I would normally use `xmllint --schema` or= `xmlint --relaxng`…
 
Is the best option currently to use either `yumadump` or `pyang` to ge= nerate the XSD and then use xmllint?
 
Thanks,
Kent
 
 
 
 --_000_84600D05C20FF943918238042D7670FD374618C927EMBX01HQjnprn_-- From kwatsen@juniper.net Fri Jan 7 17:00:15 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42823A6961 for ; Fri, 7 Jan 2011 17:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGGdIhdDXE1V for ; Fri, 7 Jan 2011 17:00:11 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4CF053A68BA for ; Fri, 7 Jan 2011 16:59:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTSe3eDUogcEkqXnQdrRTBk5wWhnuAVWM@postini.com; Fri, 07 Jan 2011 17:01:56 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 7 Jan 2011 16:59:11 -0800 From: Kent Watsen To: "netmod@ietf.org" Date: Fri, 7 Jan 2011 16:59:06 -0800 Thread-Topic: questions for how yang's output statement maps to rpc-replies Thread-Index: Acuuz0Aw286dETzERjawUYk4/XPR0w== Message-ID: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_84600D05C20FF943918238042D7670FD374618CB28EMBX01HQjnprn_" MIME-Version: 1.0 Subject: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 01:00:15 -0000 --_004_84600D05C20FF943918238042D7670FD374618CB28EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following is from RFC 6020, section 4.2.9: YANG Example: rpc activate-software-image { input { leaf image-name { type string; } } output { leaf status { type string; } } } NETCONF XML Example: acmefw-2.3 The image acmefw-2.3 is being installed. Note that the rpc-reply uses the leaf node's name (i.e. "status") as oppose= d to something rpc-specific like "activate-software-image-response". I kno= w that a module developer could use rpc-specific values, but because they d= on't have to means that tools have to support that possibility. To see where this breaks down, imagine two different RPCs, each defining an= output called "status", which are distinctly different from each other. T= his means that the schemas are not stateless and validators cannot treat th= em as such... In trying to see if I was missing anything, I decided to analyze the XSD ge= nerated by both `yangdump` and `pyang`, to see what they do... As you can see by looking at the attached files, I'm unable to draw any con= clusions as: 1. Pyang doesn't have any output for the rpc-reply 2. Yangdump generates an output, but it's not clear what it's trying to rep= resent due to it not being valid XSD. FYI, here are some of the issues I f= ound: - needs to be an - remove the duplicate global namespace - add the "xs:" prefix to all XMLSchema types - remove the abstract=3D"true" for xs:element - missing import of netconf schema - invalid use of dataInlineType (should use new rpcResponseType in 474= 1bis) So, here are my questions: - what is the valid XSD for the output statement suppose to be? - assuming that multiple RPCs can define the same response name, does it = necessitate=20 defining each rpc-reply in its own XSD file so as avoid redundant decla= ration errors? Thanks, Kent --_004_84600D05C20FF943918238042D7670FD374618CB28EMBX01HQjnprn_ Content-Type: text/xml; name="demo.yangdump.xsd" Content-Description: demo.yangdump.xsd Content-Disposition: attachment; filename="demo.yangdump.xsd"; size=3054; creation-date="Fri, 07 Jan 2011 15:10:06 GMT"; modification-date="Fri, 07 Jan 2011 15:10:06 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNjaGVtYSB4bWxuczp4cz0i aHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiCiAgeG1sbnM9Imh0dHA6Ly9kZW1vLmp1 bmlwZXIubmV0L2RlbW8iCiAgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vZGVtby5qdW5pcGVyLm5l dC9kZW1vIgogIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIiBhdHRyaWJ1dGVGb3JtRGVm YXVsdD0idW5xdWFsaWZpZWQiCiAgeG1sOmxhbmc9ImVuIiB2ZXJzaW9uPSIyMDExLTAxLTAxIgog IHhtbG5zOm5jeD0iaHR0cDovL25ldGNvbmZjZW50cmFsLm9yZy9ucy95dW1hLW5jeCIKICB4bWxu czpuYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIgogIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSI+CiAgPGFubm90YXRpb24+CiAgICA8ZG9j dW1lbnRhdGlvbj4KICAgICAgQ29udmVydGVkIGZyb20gWUFORyBmaWxlICdkZW1vLnlhbmcnIGJ5 IHlhbmdkdW1wIHZlcnNpb24gMS4xNC5leHBvcnRlZAogICAgICAKICAgICAgTW9kdWxlOiBkZW1v CiAgICAgIFZlcnNpb246IDIwMTEtMDEtMDEKICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgIDxhcHBp bmZvPgogICAgICA8c291cmNlIHhtbG5zPSJodHRwOi8vbmV0Y29uZmNlbnRyYWwub3JnL25zL3l1 bWEtbmN4Ij4KICAgICAgICBkZW1vLnlhbmc8L3NvdXJjZT4KICAgIDwvYXBwaW5mbz4KICAgIDxh cHBpbmZvPgogICAgICA8cmV2aXNpb24geG1sbnM9Imh0dHA6Ly9uZXRjb25mY2VudHJhbC5vcmcv bnMveXVtYS1uY3giPgogICAgICAgIDx2ZXJzaW9uPjIwMTEtMDEtMDE8L3ZlcnNpb24+CiAgICAg ICAgPGRlc2NyaXB0aW9uPkluaXRpYWwgY29uY2VwdGlvbgogICAgICAgIDwvZGVzY3JpcHRpb24+ CiAgICAgIDwvcmV2aXNpb24+CiAgICA8L2FwcGluZm8+CiAgPC9hbm5vdGF0aW9uPgoKICA8Y29t cGxleFR5cGUgbmFtZT0iZ2V0LWZvby1pbmZvcm1hdGlvbl9vdXRwdXRfdHlwZV9fIj4KICAgIDxj b21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJuYzpkYXRhSW5saW5lVHlwZSI+ CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZm9vYmFyLWluZm9y bWF0aW9uIiB0eXBlPSJ4czpzdHJpbmciCiAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPgogICAg ICAgICAgPGVsZW1lbnQgbmFtZT0iX18uZ2V0LWZvby1pbmZvcm1hdGlvbi5BX18iIG1pbk9jY3Vy cz0iMCIKICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiIGFic3RyYWN0PSJ0cnVlIi8+ CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250 ZW50PgogIDwvY29tcGxleFR5cGU+CgogIDxlbGVtZW50IG5hbWU9ImdldC1mb28taW5mb3JtYXRp b24iCiAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmM6cnBjT3BlcmF0aW9uIj4KICAgIDxhbm5vdGF0 aW9uPgogICAgICA8YXBwaW5mbz4KICAgICAgICA8cnBjLW91dHB1dCB4bWxucz0iaHR0cDovL25l dGNvbmZjZW50cmFsLm9yZy9ucy95dW1hLW5jeCI+CiAgICAgICAgICBnZXQtZm9vLWluZm9ybWF0 aW9uX291dHB1dF90eXBlX18KICAgICAgICA8L3JwYy1vdXRwdXQ+CiAgICAgIDwvYXBwaW5mbz4K ICAgIDwvYW5ub3RhdGlvbj4KICAgIDxjb21wbGV4VHlwZT4KICAgICAgPGNvbXBsZXhDb250ZW50 PgogICAgICAgIDxleHRlbnNpb24gYmFzZT0ibmM6cnBjT3BlcmF0aW9uVHlwZSI+CiAgICAgICAg ICA8c2VxdWVuY2U+CiAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9Il9fLmdldC1mb28taW5mb3Jt YXRpb24uQV9fIiBtaW5PY2N1cnM9IjAiCiAgICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5k ZWQiIGFic3RyYWN0PSJ0cnVlIi8+CiAgICAgICAgICA8L3NlcXVlbmNlPgogICAgICAgIDwvZXh0 ZW5zaW9uPgogICAgICA8L2NvbXBsZXhDb250ZW50PgogICAgPC9jb21wbGV4VHlwZT4KICA8L2Vs ZW1lbnQ+CgogIDxjb21wbGV4VHlwZSBuYW1lPSJnZXQtYmFyLWluZm9ybWF0aW9uX291dHB1dF90 eXBlX18iPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9Im5jOmRh dGFJbmxpbmVUeXBlIj4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1l PSJmb29iYXItaW5mb3JtYXRpb24iIHR5cGU9InhzOnN0cmluZyIKICAgICAgICAgICAgbWluT2Nj dXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJfXy5nZXQtYmFyLWluZm9ybWF0aW9u LkFfXyIgbWluT2NjdXJzPSIwIgogICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIgYWJz dHJhY3Q9InRydWUiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAg IDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KCiAgPGVsZW1lbnQgbmFtZT0iZ2V0 LWJhci1pbmZvcm1hdGlvbiIKICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuYzpycGNPcGVyYXRpb24i PgogICAgPGFubm90YXRpb24+CiAgICAgIDxhcHBpbmZvPgogICAgICAgIDxycGMtb3V0cHV0IHht bG5zPSJodHRwOi8vbmV0Y29uZmNlbnRyYWwub3JnL25zL3l1bWEtbmN4Ij4KICAgICAgICAgIGdl dC1iYXItaW5mb3JtYXRpb25fb3V0cHV0X3R5cGVfXwogICAgICAgIDwvcnBjLW91dHB1dD4KICAg ICAgPC9hcHBpbmZvPgogICAgPC9hbm5vdGF0aW9uPgogICAgPGNvbXBsZXhUeXBlPgogICAgICA8 Y29tcGxleENvbnRlbnQ+CiAgICAgICAgPGV4dGVuc2lvbiBiYXNlPSJuYzpycGNPcGVyYXRpb25U eXBlIj4KICAgICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgICAgPGVsZW1lbnQgbmFtZT0iX18u Z2V0LWJhci1pbmZvcm1hdGlvbi5BX18iIG1pbk9jY3Vycz0iMCIKICAgICAgICAgICAgICBtYXhP Y2N1cnM9InVuYm91bmRlZCIgYWJzdHJhY3Q9InRydWUiLz4KICAgICAgICAgIDwvc2VxdWVuY2U+ CiAgICAgICAgPC9leHRlbnNpb24+CiAgICAgIDwvY29tcGxleENvbnRlbnQ+CiAgICA8L2NvbXBs ZXhUeXBlPgogIDwvZWxlbWVudD4KCjwvc2NoZW1hPgoK --_004_84600D05C20FF943918238042D7670FD374618CB28EMBX01HQjnprn_ Content-Type: text/xml; name="demo.pyang.xsd" Content-Description: demo.pyang.xsd Content-Disposition: attachment; filename="demo.pyang.xsd"; size=1992; creation-date="Fri, 07 Jan 2011 15:02:29 GMT"; modification-date="Fri, 07 Jan 2011 15:10:06 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHhzOnNjaGVtYSB4bWxuczp4 cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiCiAgICAgICAgICAgeG1sbnM6eWlu PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOnNjaGVtYTp5YW5nOnlpbjoxIgogICAgICAgICAgIHhtbG5z Om5jPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICAgICAgICAg dGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vZGVtby5qdW5pcGVyLm5ldC9kZW1vIgogICAgICAgICAg IHhtbG5zPSJodHRwOi8vZGVtby5qdW5pcGVyLm5ldC9kZW1vIgogICAgICAgICAgIGVsZW1lbnRG b3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAgICAgICAgIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1 bnF1YWxpZmllZCIKICAgICAgICAgICB2ZXJzaW9uPSIyMDExLTAxLTAxIgogICAgICAgICAgIHht bDpsYW5nPSJlbiIKICAgICAgICAgICB4bWxuczpkZW1vPSJodHRwOi8vZGVtby5qdW5pcGVyLm5l dC9kZW1vIj4KCiAgPHhzOmltcG9ydAogICAgIG5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnht bDpuczpuZXRjb25mOmJhc2U6MS4wIgogICAgIHNjaGVtYUxvY2F0aW9uPSJodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbmV0Y29uZi54c2QiLz4KICA8 eHM6YW5ub3RhdGlvbj4KICAgIDx4czpkb2N1bWVudGF0aW9uPgogICAgICBUaGlzIHNjaGVtYSB3 YXMgZ2VuZXJhdGVkIGZyb20gdGhlIFlBTkcgbW9kdWxlIGRlbW8KICAgICAgYnkgcHlhbmcgdmVy c2lvbiAxLjAuCgogICAgICBUaGUgc2NoZW1hIGRlc2NyaWJlcyBhbiBpbnN0YW5jZSBkb2N1bWVu dCBjb25zaXN0aW5nCiAgICAgIG9mIHRoZSBlbnRpcmUgY29uZmlndXJhdGlvbiBkYXRhIHN0b3Jl LCBvcGVyYXRpb25hbAogICAgICBkYXRhLCBycGMgb3BlcmF0aW9ucywgYW5kIG5vdGlmaWNhdGlv bnMuCiAgICAgIFRoaXMgc2NoZW1hIGNhbiB0aHVzIE5PVCBiZSB1c2VkIGFzLWlzIHRvCiAgICAg IHZhbGlkYXRlIE5FVENPTkYgUERVcy4KICAgIDwveHM6ZG9jdW1lbnRhdGlvbj4KICA8L3hzOmFu bm90YXRpb24+CgoKICA8eHM6ZWxlbWVudCBuYW1lPSJnZXQtZm9vLWluZm9ybWF0aW9uIiBzdWJz dGl0dXRpb25Hcm91cD0ibmM6cnBjT3BlcmF0aW9uIj4KICAgIDx4czpjb21wbGV4VHlwZT4KICAg ICAgPHhzOmNvbXBsZXhDb250ZW50PgogICAgICAgIDx4czpleHRlbnNpb24gYmFzZT0ibmM6cnBj T3BlcmF0aW9uVHlwZSI+CiAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4KICAgICAgICAgICAgICA8 eHM6YW55IG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiCiAgICAgICAgICAgICAg ICAgICAgICBuYW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4Ii8+CiAgICAg ICAgICAgIDwveHM6c2VxdWVuY2U+CiAgICAgICAgPC94czpleHRlbnNpb24+CiAgICAgIDwveHM6 Y29tcGxleENvbnRlbnQ+CiAgICA8L3hzOmNvbXBsZXhUeXBlPgogIDwveHM6ZWxlbWVudD4KICA8 eHM6ZWxlbWVudCBuYW1lPSJnZXQtYmFyLWluZm9ybWF0aW9uIiBzdWJzdGl0dXRpb25Hcm91cD0i bmM6cnBjT3BlcmF0aW9uIj4KICAgIDx4czpjb21wbGV4VHlwZT4KICAgICAgPHhzOmNvbXBsZXhD b250ZW50PgogICAgICAgIDx4czpleHRlbnNpb24gYmFzZT0ibmM6cnBjT3BlcmF0aW9uVHlwZSI+ CiAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4KICAgICAgICAgICAgICA8eHM6YW55IG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lc3Bh Y2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4Ii8+CiAgICAgICAgICAgIDwveHM6c2Vx dWVuY2U+CiAgICAgICAgPC94czpleHRlbnNpb24+CiAgICAgIDwveHM6Y29tcGxleENvbnRlbnQ+ CiAgICA8L3hzOmNvbXBsZXhUeXBlPgogIDwveHM6ZWxlbWVudD4KCjwveHM6c2NoZW1hPgoK --_004_84600D05C20FF943918238042D7670FD374618CB28EMBX01HQjnprn_ Content-Type: application/octet-stream; name="demo.yang" Content-Description: demo.yang Content-Disposition: attachment; filename="demo.yang"; size=450; creation-date="Fri, 07 Jan 2011 15:02:29 GMT"; modification-date="Fri, 07 Jan 2011 15:10:06 GMT" Content-Transfer-Encoding: base64 bW9kdWxlIGRlbW8gewoKICAgIG5hbWVzcGFjZSAiaHR0cDovL2RlbW8uanVuaXBlci5uZXQvZGVt byI7CgogICAgcHJlZml4ICJkZW1vIjsKCiAgICByZXZpc2lvbiAyMDExLTAxLTAxIHsKICAgICAg ICBkZXNjcmlwdGlvbiAiSW5pdGlhbCBjb25jZXB0aW9uIjsKICAgIH0KCiAgICBycGMgZ2V0LWZv by1pbmZvcm1hdGlvbiB7CiAgICAgICAgb3V0cHV0IHsKICAgICAgICAgICAgbGVhZiBmb29iYXIt aW5mb3JtYXRpb24gewogICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7CiAgICAgICAgICAgIH0K ICAgICAgICB9CiAgICB9CgogICAgcnBjIGdldC1iYXItaW5mb3JtYXRpb24gewogICAgICAgIG91 dHB1dCB7CiAgICAgICAgICAgIGxlYWYgZm9vYmFyLWluZm9ybWF0aW9uIHsKICAgICAgICAgICAg ICAgIHR5cGUgc3RyaW5nOwogICAgICAgICAgICB9CiAgICAgICAgfQogICAgfQoKCn0K --_004_84600D05C20FF943918238042D7670FD374618CB28EMBX01HQjnprn_-- From ietf@andybierman.com Fri Jan 7 18:00:46 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BAD3A6966 for ; Fri, 7 Jan 2011 18:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7xehyeV8DmM for ; Fri, 7 Jan 2011 18:00:45 -0800 (PST) Received: from nm19-vm0.bullet.mail.ne1.yahoo.com (nm19-vm0.bullet.mail.ne1.yahoo.com [98.138.91.59]) by core3.amsl.com (Postfix) with SMTP id 0FB523A6945 for ; Fri, 7 Jan 2011 18:00:44 -0800 (PST) Received: from [98.138.90.54] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2011 02:02:48 -0000 Received: from [98.138.89.198] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2011 02:02:48 -0000 Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 08 Jan 2011 02:02:48 -0000 X-Yahoo-Newman-Id: 633250.34176.bm@omp1056.mail.ne1.yahoo.com Received: (qmail 56540 invoked from network); 8 Jan 2011 02:02:48 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 07 Jan 2011 18:02:45 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YA0qgwMVM1mCOH.LQRj_Kd5bsEvolXKdgzPYLnYWWOywrrP rZF6nwq3jQ1fhXI4lZuW9i3SbAzXKs_zztvjv9CEkiFV4y8tz0mpB7KoAfN_ zEjzdOfmElr.61BZ5Ww5_1K8djgwPiuziVPszxx5wkql_halUaSElBYmawGd RhT2hngRglnOarHVoDclw.c_v._3m0qK2bVMUZEBH4PAFZQmk982hJ1pazJj XD8KQl.GPN2Zb999UHHywKz0IAChHZf86eKVuPKSUW_Hj.c_vzqubzXHevyE tzok4Mx25tWGkc7Cz9q0YCJNEYJa46ptuBK57Kcc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D27C5BE.3040701@andybierman.com> Date: Fri, 07 Jan 2011 18:02:38 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 02:00:46 -0000 On 01/07/2011 04:59 PM, Kent Watsen wrote: > > Hi, The XSD generation from yangdump is out-of-date. I don't know when it will be updated to match 4741bis and fix the known bugs. Andy > Following is from RFC 6020, section 4.2.9: > > YANG Example: > > rpc activate-software-image { > input { > leaf image-name { > type string; > } > } > output { > leaf status { > type string; > } > } > } > > NETCONF XML Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > acmefw-2.3 > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > The image acmefw-2.3 is being installed. > > > > > Note that the rpc-reply uses the leaf node's name (i.e. "status") as opposed to something rpc-specific like "activate-software-image-response". I know that a module developer could use rpc-specific values, but because they don't have to means that tools have to support that possibility. > > To see where this breaks down, imagine two different RPCs, each defining an output called "status", which are distinctly different from each other. This means that the schemas are not stateless and validators cannot treat them as such... > > In trying to see if I was missing anything, I decided to analyze the XSD generated by both `yangdump` and `pyang`, to see what they do... > > As you can see by looking at the attached files, I'm unable to draw any conclusions as: > > 1. Pyang doesn't have any output for the rpc-reply > > 2. Yangdump generates an output, but it's not clear what it's trying to represent due to it not being valid XSD. FYI, here are some of the issues I found: > - needs to be an > - remove the duplicate global namespace > - add the "xs:" prefix to all XMLSchema types > - remove the abstract="true" for xs:element > - missing import of netconf schema > - invalid use of dataInlineType (should use new rpcResponseType in 4741bis) > > > So, here are my questions: > - what is the valid XSD for the output statement suppose to be? > - assuming that multiple RPCs can define the same response name, does it necessitate > defining each rpc-reply in its own XSD file so as avoid redundant declaration errors? > The validation is not stateless, as you noted. A tool has to be told which rpc-reply variant is expected. The validation for and is not schema-friendly, since the element is anyxml. > > Thanks, > Kent Andy > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Sat Jan 8 03:26:33 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0103628C0E2 for ; Sat, 8 Jan 2011 03:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_74=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 vdHT1lbJC-6b for ; Sat, 8 Jan 2011 03:26:31 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 38A7A3A69DE for ; Sat, 8 Jan 2011 03:26:30 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id EDD552CDE057 for ; Sat, 8 Jan 2011 12:28:06 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 Jan 2011 12:28:06 +0100 Message-ID: <1294486086.2926.8.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 11:26:33 -0000 Hi Kent, the RELAX NG schema generated by pyang works fine and validates your rpc-reply, see the transcript below. The test module has two rpcs with outputs containing leafs with the same name but conflicting type. The RELAX NG schema for rpc-reply contains a choice between the two alternatives. Lada ====================================================================== $ cat rpctest.yang module rpctest { namespace "http://acme.example.com/system"; prefix rt; rpc activate-software-image { input { leaf image-name { type string; } } output { leaf status { type string; } } } rpc something-else { input { leaf foo-bar { type uint8; } } output { leaf status { type uint16; } } } } $ yang2dsdl -t rpc-reply rpctest.yang == Generating RELAX NG schema './rpctest-rpc-reply.rng' Done. == Generating Schematron schema './rpctest-rpc-reply.sch' Done. == Generating DSRL schema './rpctest-rpc-reply.dsrl' Done. $ trang -I rng -O rnc rpctest-rpc-reply.rng rpctest-rpc-reply.rnc $ cat rpctest-rpc-reply.rnc default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" namespace rt = "http://acme.example.com/system" include "relaxng-lib.rnc" start = element rpc-reply { message-id-attribute, (grammar { start = element rt:status { xsd:string }? | element rt:status { xsd:unsignedShort }? }) } $ cat rpctest.xml The image acmefw-2.3 is being installed. $ yang2dsdl -t rpc-reply -j -s -b rpctest -v rpctest.xml == Using pre-generated schemas == Validating grammar and datatypes ... rpctest.xml validates. == Adding default values... done. == Validating semantic constraints ... No errors found. On Pá, 2011-01-07 at 16:59 -0800, Kent Watsen wrote: > > Following is from RFC 6020, section 4.2.9: > > YANG Example: > > rpc activate-software-image { > input { > leaf image-name { > type string; > } > } > output { > leaf status { > type string; > } > } > } > > NETCONF XML Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > acmefw-2.3 > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > The image acmefw-2.3 is being installed. > > > > > Note that the rpc-reply uses the leaf node's name (i.e. "status") as opposed to something rpc-specific like "activate-software-image-response". I know that a module developer could use rpc-specific values, but because they don't have to means that tools have to support that possibility. > > To see where this breaks down, imagine two different RPCs, each defining an output called "status", which are distinctly different from each other. This means that the schemas are not stateless and validators cannot treat them as such... > > In trying to see if I was missing anything, I decided to analyze the XSD generated by both `yangdump` and `pyang`, to see what they do... > > As you can see by looking at the attached files, I'm unable to draw any conclusions as: > > 1. Pyang doesn't have any output for the rpc-reply > > 2. Yangdump generates an output, but it's not clear what it's trying to represent due to it not being valid XSD. FYI, here are some of the issues I found: > - needs to be an > - remove the duplicate global namespace > - add the "xs:" prefix to all XMLSchema types > - remove the abstract="true" for xs:element > - missing import of netconf schema > - invalid use of dataInlineType (should use new rpcResponseType in 4741bis) > > > So, here are my questions: > - what is the valid XSD for the output statement suppose to be? > - assuming that multiple RPCs can define the same response name, does it necessitate > defining each rpc-reply in its own XSD file so as avoid redundant declaration errors? > > > Thanks, > Kent > > > > _______________________________________________ > 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 Sat Jan 8 05:39:17 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7634A28C0F0 for ; Sat, 8 Jan 2011 05:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.069, 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 d1Pxm7JlQm6I for ; Sat, 8 Jan 2011 05:39:16 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A475828C0E3 for ; Sat, 8 Jan 2011 05:39:16 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A90176C250; Sat, 8 Jan 2011 14:41:23 +0100 (CET) Date: Sat, 08 Jan 2011 14:41:22 +0100 (CET) Message-Id: <20110108.144122.174090604.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD374618C927@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618C927@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG-based validation? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 13:39:17 -0000 Kent Watsen wrote: > > I'm looking for a utility to validate XML configuration and RPC messages > defined by a YANG module. > > For XSD and RelaxNG schema, I would normally use `xmllint --schema` or `xmlint > --relaxng`... > > Is the best option currently to use either `yumadump` or `pyang` to generate > the XSD and then use xmllint? As for pyang, the XSD output is out of date, but there is the DSDL output that works well for validation of config, rpcs, state data, etc. There are currently no plans to update the XSD plugin, but if anyone would like to contribute that would be very welcome. /martin From mbj@tail-f.com Sat Jan 8 05:41:18 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE64A28C0F0 for ; Sat, 8 Jan 2011 05:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.064, 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 3gTc2iD+2XEl for ; Sat, 8 Jan 2011 05:41:18 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1795E28C0E3 for ; Sat, 8 Jan 2011 05:41:18 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 76D8376C250; Sat, 8 Jan 2011 14:43:25 +0100 (CET) Date: Sat, 08 Jan 2011 14:43:22 +0100 (CET) Message-Id: <20110108.144322.146900499.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 13:41:19 -0000 Kent Watsen wrote: > So, here are my questions: > - what is the valid XSD for the output statement suppose to be? > - assuming that multiple RPCs can define the same response name, does it > - necessitate > defining each rpc-reply in its own XSD file so as avoid redundant > declaration errors? This is a well-known problem with the XSD in 4741. In 4741bis (thanks to you :) the output is now also a substitution group which makes things a bit better. /martin From lhotka@cesnet.cz Sat Jan 8 10:11:44 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1F73A6805 for ; Sat, 8 Jan 2011 10:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-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 O-p+jHqZ31eG for ; Sat, 8 Jan 2011 10:11:43 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 444BD3A677C for ; Sat, 8 Jan 2011 10:11:39 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id CB3512CDE05B for ; Sat, 8 Jan 2011 19:13:46 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 Jan 2011 19:13:46 +0100 Message-ID: <1294510426.2926.24.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 18:11:44 -0000 On Pá, 2011-01-07 at 16:59 -0800, Kent Watsen wrote: > To see where this breaks down, imagine two different RPCs, each > defining an output called "status", which are distinctly different > from each other. This means that the schemas are not stateless and > validators cannot treat them as such... > In fact, the idea of a common "stateless" schema for all rpc-replies is flawed because every rpc-reply is a separate document independent of other rpc-replies, so it only makes sense to talk about a schema for a particular rpc-reply. Consider this: rpc foo { output { leaf status { type string; must "starts-with(.,'FOO')"; } } } rpc bar { output { leaf status { type string; must "starts-with(.,'BAR')"; } } } The must conditions are contradictory, so in order to be able to validate a rpc-reply, one has to know whether it is a reply to "foo" or "bar". Lada > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Sat Jan 8 10:52:18 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC0E3A680F for ; Sat, 8 Jan 2011 10:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.591 X-Spam-Level: X-Spam-Status: No, score=-4.591 tagged_above=-999 required=5 tests=[AWL=-1.992, 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 0-3jByyHgL+3 for ; Sat, 8 Jan 2011 10:52:17 -0800 (PST) Received: from chip3og116.obsmtp.com (chip3og116.obsmtp.com [64.18.14.81]) by core3.amsl.com (Postfix) with ESMTP id 4263B3A6802 for ; Sat, 8 Jan 2011 10:52:17 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTSiy4cNePABB0c1v6LRKzUSOFcp7jKCT@postini.com; Sat, 08 Jan 2011 10:54:26 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 8 Jan 2011 10:52:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p08IqgU72165; Sat, 8 Jan 2011 10:52:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p08IUT69010133; Sat, 8 Jan 2011 18:30:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201101081830.p08IUT69010133@idle.juniper.net> To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> Date: Sat, 8 Jan 2011 13:30:29 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 18:52:18 -0000 Kent Watsen writes: >To see where this breaks down, imagine two different RPCs, each defining an= > output called "status", which are distinctly different from each other. Two top-level "status" reply elements in the same module (namespace) with different types would be a bug in the YANG module, right? Just like two RPC statements with the same name would be a bug. Should we call this out specifically? Thanks, Phil From biermana@Brocade.com Sat Jan 8 11:17:14 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF863A680F for ; Sat, 8 Jan 2011 11:17:14 -0800 (PST) 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.235, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duqcz4Hg0+40 for ; Sat, 8 Jan 2011 11:17:13 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 45C4B3A6805 for ; Sat, 8 Jan 2011 11:17:13 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p08JEhTo016512; Sat, 8 Jan 2011 11:19:21 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id tpepqrays-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 08 Jan 2011 11:19:21 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 8 Jan 2011 11:25:31 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sat, 8 Jan 2011 11:19:20 -0800 From: Andy Bierman To: Phil Shafer , Kent Watsen Date: Sat, 8 Jan 2011 11:19:18 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuvZX2v7QP+0nD+Q4eNo34W2jaFRgAAoqCQ Message-ID: References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <201101081830.p08IUT69010133@idle.juniper.net> In-Reply-To: <201101081830.p08IUT69010133@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-08_07:2011-01-07, 2011-01-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101080078 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 19:17:14 -0000 Hi, The and operations both return . IMO, the current restrictions are fine. It is a hassle to make sure the output child nodes are all unique within the namespace. RFC 6020 is done. Validating random XML documents is a low priority. The client knows what it called. It can tell the random validator which XSD to use. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Phil Shafer Sent: Saturday, January 08, 2011 10:30 AM To: Kent Watsen Cc: netmod@ietf.org Subject: Re: [netmod] questions for how yang's output statement maps to rpc= -replies Kent Watsen writes: >To see where this breaks down, imagine two different RPCs, each defining a= n=3D > output called "status", which are distinctly different from each other. Two top-level "status" reply elements in the same module (namespace) with different types would be a bug in the YANG module, right? Just like two RPC statements with the same name would be a bug. Should we call this out specifically? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Sat Jan 8 12:03:00 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB0B3A681A for ; Sat, 8 Jan 2011 12:03:00 -0800 (PST) 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 oPq79Ss38a-b for ; Sat, 8 Jan 2011 12:02:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6E2023A6814 for ; Sat, 8 Jan 2011 12:02:59 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E45D476C26D; Sat, 8 Jan 2011 21:05:06 +0100 (CET) Date: Sat, 08 Jan 2011 21:05:05 +0100 (CET) Message-Id: <20110108.210505.256180069.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <201101081830.p08IUT69010133@idle.juniper.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 20:03:00 -0000 Andy Bierman wrote: > Hi, > > The and operations both return . > IMO, the current restrictions are fine. It is a hassle to > make sure the output child nodes are all unique within the namespace. > RFC 6020 is done. > > Validating random XML documents is a low priority. > The client knows what it called. It can tell the random > validator which XSD to use. +1! /martin From lhotka@cesnet.cz Sat Jan 8 13:29:48 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F234C3A6827 for ; Sat, 8 Jan 2011 13:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, NO_RELAYS=-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 hngJYuJssxNY for ; Sat, 8 Jan 2011 13:29:47 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id B40993A683C for ; Sat, 8 Jan 2011 13:29:46 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id F2FB42CDE05B; Sat, 8 Jan 2011 22:31:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201101081830.p08IUT69010133@idle.juniper.net> Date: Sat, 8 Jan 2011 22:31:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D4729ED-C3ED-43C1-A927-53847D342F10@cesnet.cz> References: <201101081830.p08IUT69010133@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1082) Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 21:29:48 -0000 On Jan 8, 2011, at 7:30 PM, Phil Shafer wrote: > Kent Watsen writes: >> To see where this breaks down, imagine two different RPCs, each = defining an=3D >> output called "status", which are distinctly different from each = other. >=20 > Two top-level "status" reply elements in the same module (namespace) > with different types would be a bug in the YANG module, right? Just > like two RPC statements with the same name would be a bug. Should > we call this out specifically? No, each rpc output has its own namespace. In contrast, rpc names share = the same namespace. Lada >=20 > 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 Sat Jan 8 15:08:38 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5359528C127 for ; Sat, 8 Jan 2011 15:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 7B6aGizaP3HJ for ; Sat, 8 Jan 2011 15:08:37 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 578F428C120 for ; Sat, 8 Jan 2011 15:08:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTSju9b1XO+nYEEIbsPW20IINgu2b5nu7@postini.com; Sat, 08 Jan 2011 15:10:47 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 8 Jan 2011 15:06:32 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p08N6VU27114; Sat, 8 Jan 2011 15:06:32 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p08MiI0V010910; Sat, 8 Jan 2011 22:44:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201101082244.p08MiI0V010910@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <0D4729ED-C3ED-43C1-A927-53847D342F10@cesnet.cz> Date: Sat, 8 Jan 2011 17:44:18 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Jan 2011 23:08:38 -0000 Ladislav Lhotka writes: >No, each rpc output has its own namespace. In contrast, rpc names share = >the same namespace. I'm confused. How does "each rpc output [have] its own namespace"? Why doesn't the namespace of the module cover all rpc output contents? Thanks, Phil From lhotka@cesnet.cz Sun Jan 9 00:43:45 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0AAE3A67F8 for ; Sun, 9 Jan 2011 00:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-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 iZPn-3ezDb5C for ; Sun, 9 Jan 2011 00:43:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 613F93A67EC for ; Sun, 9 Jan 2011 00:43:43 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 8BBB22CDE057; Sun, 9 Jan 2011 09:45:52 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201101082244.p08MiI0V010910@idle.juniper.net> References: <201101082244.p08MiI0V010910@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sun, 09 Jan 2011 09:45:51 +0100 Message-ID: <1294562751.6461.6.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Jan 2011 08:43:45 -0000 On So, 2011-01-08 at 17:44 -0500, Phil Shafer wrote: > Ladislav Lhotka writes: > >No, each rpc output has its own namespace. In contrast, rpc names share = > >the same namespace. > > I'm confused. How does "each rpc output [have] its own namespace"? > Why doesn't the namespace of the module cover all rpc output contents? Sec. 6.2.1, 7th bullet: o All leafs, leaf-lists, lists, containers, choices, rpcs, notifications, and anyxmls defined (directly or through a uses statement) within a parent node or at the top level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the closest ancestor node that is not a case or choice node. So namespace of the "status" leaf in the following snippet is scoped to its parent node which is "output". On the other hand, the name of the rpc ("foo") is at the top-level of the module. rpc foo { output { leaf status { type string; must "starts-with(.,'FOO')"; } } } Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Sun Jan 9 09:02:47 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA75B3A67A5 for ; Sun, 9 Jan 2011 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRviHRwo6EbX for ; Sun, 9 Jan 2011 09:02:47 -0800 (PST) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.107]) by core3.amsl.com (Postfix) with SMTP id 15B3A3A67AB for ; Sun, 9 Jan 2011 09:02:46 -0800 (PST) Received: (qmail 1278 invoked from network); 9 Jan 2011 17:04:51 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 09 Jan 2011 09:04:48 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: sO6WcioVM1maDZXcMqYNPU2JFMfp6LtVdyFSW06XxJltlMS mFTMTOcn2_r0gNlPzkQmf7RgV4rBiMV8oBcUmZXZsl68d.X3R.IL1pQtAuSY kxz1y0bnpSo0g5qnduB0lYlCH_HNsQzLZuSd7FT8EoFhI526pDWRuguTtTWJ NLX_PBi0rAqEtF2jxzb5QP0b_Kw0AQfbB1NO.RLb6ffO1UfLREyDIKotlzID wHenDtMQFZ3.L.nfPKsRsM4CFyDeamhX5RopMWue5XojovNznhItk.AQ4f7l lTWoNkotS5bDIGQR_Whv.G2t23wZf7ptJm4moF3m_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D29EAA4.8090204@andybierman.com> Date: Sun, 09 Jan 2011 09:04:36 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <201101082244.p08MiI0V010910@idle.juniper.net> <1294562751.6461.6.camel@behold> In-Reply-To: <1294562751.6461.6.camel@behold> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Jan 2011 17:02:48 -0000 On 01/09/2011 12:45 AM, Ladislav Lhotka wrote: > On So, 2011-01-08 at 17:44 -0500, Phil Shafer wrote: >> Ladislav Lhotka writes: >>> No, each rpc output has its own namespace. In contrast, rpc names share = >>> the same namespace. >> >> I'm confused. How does "each rpc output [have] its own namespace"? >> Why doesn't the namespace of the module cover all rpc output contents? > > Sec. 6.2.1, 7th bullet: > > o All leafs, leaf-lists, lists, containers, choices, rpcs, > notifications, and anyxmls defined (directly or through a uses > statement) within a parent node or at the top level of the module > or its submodules share the same identifier namespace. This > namespace is scoped to the parent node or module, unless the > parent node is a case node. In that case, the namespace is scoped > to the closest ancestor node that is not a case or choice node. > > So namespace of the "status" leaf in the following snippet is scoped to > its parent node which is "output". On the other hand, the name of the > rpc ("foo") is at the top-level of the module. > > rpc foo { > output { > leaf status { > type string; > must "starts-with(.,'FOO')"; > } > } > } > An external validator (i.e. has no knowledge of the corresponding ) is not really supported in NETCONF. For example, what about these replies: This RPC defines output, so is not a valid response for this . This RPC defines optional output, so it is possible the server will not return it. (An if-feature in the 'status' leaf would also cause this response for an unsupported feature.) In hindsight, the rpc QName should have been used to wrapper any /rpc/output content in an : FOObar BARbar > Lada Andy > >> >> Thanks, >> Phil > From kwatsen@juniper.net Mon Jan 10 11:48:48 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465033A6B12 for ; Mon, 10 Jan 2011 11:48:48 -0800 (PST) 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 KQhFnW+FXbil for ; Mon, 10 Jan 2011 11:48:47 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id CA4023A6830 for ; Mon, 10 Jan 2011 11:48:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTStjHa5RUePluq6u3cKpP8rw7QmBffH/@postini.com; Mon, 10 Jan 2011 11:50:54 PST 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; Mon, 10 Jan 2011 11:49:03 -0800 From: Kent Watsen To: Ladislav Lhotka , Phil Shafer Date: Mon, 10 Jan 2011 11:48:58 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: Acuv2XLvmlw/fU/uTbWM1kW9B8Ck8ABBuCtA Message-ID: <84600D05C20FF943918238042D7670FD37464047CF@EMBX01-HQ.jnpr.net> References: <201101082244.p08MiI0V010910@idle.juniper.net> <1294562751.6461.6.camel@behold> In-Reply-To: <1294562751.6461.6.camel@behold> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_84600D05C20FF943918238042D7670FD37464047CFEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Jan 2011 19:48:48 -0000 --_003_84600D05C20FF943918238042D7670FD37464047CFEMBX01HQjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gSSdtIGNvbmZ1c2VkLiAgSG93IGRvZXMgImVhY2ggcnBjIG91dHB1dCBbaGF2ZV0gaXRzIG93 biBuYW1lc3BhY2UiPw0KPj4gV2h5IGRvZXNuJ3QgdGhlIG5hbWVzcGFjZSBvZiB0aGUgbW9kdWxl IGNvdmVyIGFsbCBycGMgb3V0cHV0IGNvbnRlbnRzPw0KPg0KPiBTZWMuIDYuMi4xLCA3dGggYnVs bGV0Og0KPg0KPiAgIG8gIEFsbCBsZWFmcywgbGVhZi1saXN0cywgbGlzdHMsIGNvbnRhaW5lcnMs IGNob2ljZXMsIHJwY3MsDQo+ICAgICAgbm90aWZpY2F0aW9ucywgYW5kIGFueXhtbHMgZGVmaW5l ZCAoZGlyZWN0bHkgb3IgdGhyb3VnaCBhIHVzZXMNCj4gICAgICBzdGF0ZW1lbnQpIHdpdGhpbiBh IHBhcmVudCBub2RlIG9yIGF0IHRoZSB0b3AgbGV2ZWwgb2YgdGhlIG1vZHVsZQ0KPiAgICAgIG9y IGl0cyBzdWJtb2R1bGVzIHNoYXJlIHRoZSBzYW1lIGlkZW50aWZpZXIgbmFtZXNwYWNlLiAgVGhp cw0KPiAgICAgIG5hbWVzcGFjZSBpcyBzY29wZWQgdG8gdGhlIHBhcmVudCBub2RlIG9yIG1vZHVs ZSwgdW5sZXNzIHRoZQ0KPiAgICAgIHBhcmVudCBub2RlIGlzIGEgY2FzZSBub2RlLiAgSW4gdGhh dCBjYXNlLCB0aGUgbmFtZXNwYWNlIGlzIHNjb3BlZA0KPiAgICAgIHRvIHRoZSBjbG9zZXN0IGFu Y2VzdG9yIG5vZGUgdGhhdCBpcyBub3QgYSBjYXNlIG9yIGNob2ljZSBub2RlLg0KPg0KPiBTbyBu YW1lc3BhY2Ugb2YgdGhlICJzdGF0dXMiIGxlYWYgaW4gdGhlIGZvbGxvd2luZyBzbmlwcGV0IGlz IHNjb3BlZCB0bw0KPiBpdHMgcGFyZW50IG5vZGUgd2hpY2ggaXMgIm91dHB1dCIuIE9uIHRoZSBv dGhlciBoYW5kLCB0aGUgbmFtZSBvZiB0aGUNCj4gcnBjICgiZm9vIikgaXMgYXQgdGhlIHRvcC1s ZXZlbCBvZiB0aGUgbW9kdWxlLg0KPg0KPiAgcnBjIGZvbyB7DQo+ICAgIG91dHB1dCB7DQo+ICAg ICAgbGVhZiBzdGF0dXMgew0KPiAgICAgICAgdHlwZSBzdHJpbmc7DQo+ICAgICAgICBtdXN0ICJz dGFydHMtd2l0aCguLCdGT08nKSI7DQo+ICAgICAgfQ0KPiAgICB9DQo+ICB9DQoNCg0KRGVzcGl0 ZSB3aGF0IHNlY3Rpb24gNi4yLjEgc2F5cywgdGhlIGV4YW1wbGUgYmVsb3cgZnJvbSBzZWN0aW9u IDQuMi45IHNob3dzIHRoZSBzdGF0dXMgbm9kZSBpbiB0aGUgbW9kdWxlJ3MgbmFtZXNwYWNlIChp LmUuIHhtbG5zPSJodHRwOi8vYWNtZS5leGFtcGxlLmNvbS9zeXN0ZW0iKToNCg0KICAgICA8cnBj LXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCiAgICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgICAgICA8c3RhdHVzIHhtbG5zPSJo dHRwOi8vYWNtZS5leGFtcGxlLmNvbS9zeXN0ZW0iPg0KICAgICAgICAgVGhlIGltYWdlIGFjbWVm dy0yLjMgaXMgYmVpbmcgaW5zdGFsbGVkLg0KICAgICAgIDwvc3RhdHVzPg0KICAgICA8L3JwYy1y ZXBseT4NCg0KSXMgdGhlIGV4YW1wbGUgd3Jvbmc/DQoNCg0KQWxzbywgcGxlYXNlIG5vdGUgdGhh dCB3aXRoIFhTRCgqKSwgdGhlIG9ubHkgd2F5IEkgaGF2ZSBiZWVuIGFibGUgdG8gdmFsaWRhdGUg dHdvIFJQQyByZXBsaWVzIGhhdmluZyB0aGUgc2FtZSBuYW1lIGFuZCBuYW1lc3BhY2UgaXMgdG8g ZGVmaW5lIHRoZW0gaW50byBkaXN0aW5jdCBYU0QgZmlsZXMgKHNlZSBhdHRhY2hlZCBYU0QgZmls ZXMpLiAgVGhlIGltcGxpY2F0aW9uIG9mIHRoaXMgaXMgdGhhdCBhIFlBTkctdG8tWFNEIGNvbnZl cnRvciB3b3VsZCBuZWVkIHRvIGdlbmVyYXRlIGFuIFhTRCBmaWxlIHBlciBSUEMuLi4NCg0KKiBS ZWxheE5HIGFuZCBEU0RMIGFyZSBuaWNlLCBidXQgdGhlIE5ldENvbmYgc2NoZW1hIGlzIFhTRCwg c28gSSdtIHVzaW5nIGl0DQoNCg0KVGhhbmtzLA0KS2VudA0KDQo= --_003_84600D05C20FF943918238042D7670FD37464047CFEMBX01HQjnprn_ Content-Type: text/xml; name="get-foo-information.xsd" Content-Description: get-foo-information.xsd Content-Disposition: attachment; filename="get-foo-information.xsd"; size=1103; creation-date="Mon, 10 Jan 2011 09:55:17 GMT"; modification-date="Mon, 10 Jan 2011 10:18:43 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KCjx4czpzY2hlbWEgeG1sbnM6 eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgICAgICAgIHhtbG5zOm5j PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICAgICAgICAgeG1s bnM9Imh0dHA6Ly9hY21lLmV4YW1wZS5jb20vZGVtbyIKICAgICAgICAgICB0YXJnZXROYW1lc3Bh Y2U9Imh0dHA6Ly9hY21lLmV4YW1wZS5jb20vZGVtbyIKICAgICAgICAgICBlbGVtZW50Rm9ybURl ZmF1bHQ9InF1YWxpZmllZCI+CgoKICAgPHhzOmltcG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBh cmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIgCiAgICAgICAgICAgICAgc2NoZW1hTG9jYXRp b249Im5ldGNvbmYueHNkIi8+CiAgIAogICAKICAgPHhzOmVsZW1lbnQgbmFtZT0iZ2V0LWZvby1p bmZvcm1hdGlvbiIgc3Vic3RpdHV0aW9uR3JvdXA9Im5jOnJwY09wZXJhdGlvbiI+CiAgICAgIDx4 czpjb21wbGV4VHlwZT4KICAgICAgICAgPHhzOmNvbXBsZXhDb250ZW50PgogICAgICAgICAgICA8 eHM6ZXh0ZW5zaW9uIGJhc2U9Im5jOnJwY09wZXJhdGlvblR5cGUiLz4KICAgICAgICAgPC94czpj b21wbGV4Q29udGVudD4KICAgICAgPC94czpjb21wbGV4VHlwZT4KICAgPC94czplbGVtZW50Pgog ICAgCiAgIAogICA8eHM6ZWxlbWVudCBuYW1lPSJzdGF0dXMiIHN1YnN0aXR1dGlvbkdyb3VwPSJu YzpycGNSZXNwb25zZSI+CiAgICAgIDx4czpjb21wbGV4VHlwZT4KICAgICAgICAgPHhzOmNvbXBs ZXhDb250ZW50PgogICAgICAgICAgICA8eHM6ZXh0ZW5zaW9uIGJhc2U9Im5jOnJwY1Jlc3BvbnNl VHlwZSI+CiAgICAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4KICAgICAgICAgICAgICAgICAgPHhz OmVsZW1lbnQgbmFtZT0idmFsdWUiIHR5cGU9InhzOnN0cmluZyIvPgogICAgICAgICAgICAgICA8 L3hzOnNlcXVlbmNlPgogICAgICAgICAgICA8L3hzOmV4dGVuc2lvbj4KICAgICAgICAgPC94czpj b21wbGV4Q29udGVudD4KICAgICAgPC94czpjb21wbGV4VHlwZT4KICAgPC94czplbGVtZW50Pgog ICAKICAgCjwveHM6c2NoZW1hPgo= --_003_84600D05C20FF943918238042D7670FD37464047CFEMBX01HQjnprn_ Content-Type: text/xml; name="get-bar-information.xsd" Content-Description: get-bar-information.xsd Content-Disposition: attachment; filename="get-bar-information.xsd"; size=1107; creation-date="Mon, 10 Jan 2011 09:55:23 GMT"; modification-date="Mon, 10 Jan 2011 10:19:13 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KCjx4czpzY2hlbWEgeG1sbnM6 eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgICAgICAgIHhtbG5zOm5j PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICAgICAgICAgeG1s bnM9Imh0dHA6Ly9hY21lLmV4YW1wZS5jb20vZGVtbyIKICAgICAgICAgICB0YXJnZXROYW1lc3Bh Y2U9Imh0dHA6Ly9hY21lLmV4YW1wZS5jb20vZGVtbyIKICAgICAgICAgICBlbGVtZW50Rm9ybURl ZmF1bHQ9InF1YWxpZmllZCI+CgoKICAgPHhzOmltcG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBh cmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIgCiAgICAgICAgICAgICAgc2NoZW1hTG9jYXRp b249Im5ldGNvbmYueHNkIi8+CiAgIAogICAKICAgPHhzOmVsZW1lbnQgbmFtZT0iZ2V0LWJhci1p bmZvcm1hdGlvbiIgc3Vic3RpdHV0aW9uR3JvdXA9Im5jOnJwY09wZXJhdGlvbiI+CiAgICAgIDx4 czpjb21wbGV4VHlwZT4KICAgICAgICAgPHhzOmNvbXBsZXhDb250ZW50PgogICAgICAgICAgICA8 eHM6ZXh0ZW5zaW9uIGJhc2U9Im5jOnJwY09wZXJhdGlvblR5cGUiLz4KICAgICAgICAgPC94czpj b21wbGV4Q29udGVudD4KICAgICAgPC94czpjb21wbGV4VHlwZT4KICAgPC94czplbGVtZW50Pgog ICAKICAgCiAgIDx4czplbGVtZW50IG5hbWU9InN0YXR1cyIgc3Vic3RpdHV0aW9uR3JvdXA9Im5j OnJwY1Jlc3BvbnNlIj4KICAgICAgPHhzOmNvbXBsZXhUeXBlPgogICAgICAgICA8eHM6Y29tcGxl eENvbnRlbnQ+CiAgICAgICAgICAgIDx4czpleHRlbnNpb24gYmFzZT0ibmM6cnBjUmVzcG9uc2VU eXBlIj4KICAgICAgICAgICAgICAgPHhzOnNlcXVlbmNlPgogICAgICAgICAgICAgICAgICA8eHM6 ZWxlbWVudCBuYW1lPSJ2YWx1ZSIgdHlwZT0ieHM6dW5zaWduZWRJbnQiLz4KICAgICAgICAgICAg ICAgPC94czpzZXF1ZW5jZT4KICAgICAgICAgICAgPC94czpleHRlbnNpb24+CiAgICAgICAgIDwv eHM6Y29tcGxleENvbnRlbnQ+CiAgICAgIDwveHM6Y29tcGxleFR5cGU+CiAgIDwveHM6ZWxlbWVu dD4KICAgCiAgIAo8L3hzOnNjaGVtYT4K --_003_84600D05C20FF943918238042D7670FD37464047CFEMBX01HQjnprn_-- From kwatsen@juniper.net Mon Jan 10 12:22:03 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F02228C125 for ; Mon, 10 Jan 2011 12:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_25=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 yWG34abvuze3 for ; Mon, 10 Jan 2011 12:22:02 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 7198828C0F9 for ; Mon, 10 Jan 2011 12:22:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTStq7MngD7IuoTtsGJKpz0PZLGqz7Ukl@postini.com; Mon, 10 Jan 2011 12:24:17 PST 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; Mon, 10 Jan 2011 12:21:23 -0800 From: Kent Watsen To: Ladislav Lhotka , "netmod@ietf.org" Date: Mon, 10 Jan 2011 12:21:22 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuvJwjIrO9gaMXbSYS/Xbr5HSKTsgB2GdYw Message-ID: <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> In-Reply-To: <1294486086.2926.8.camel@behold> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Jan 2011 20:22:03 -0000 DQo+IHRoZSBSRUxBWCBORyBzY2hlbWEgZ2VuZXJhdGVkIGJ5IHB5YW5nIHdvcmtzIGZpbmUgYW5k IHZhbGlkYXRlcyB5b3VyDQo+IHJwYy1yZXBseSwgc2VlIHRoZSB0cmFuc2NyaXB0IGJlbG93LiBU aGUgdGVzdCBtb2R1bGUgaGFzIHR3byBycGNzIHdpdGgNCj4gb3V0cHV0cyBjb250YWluaW5nIGxl YWZzIHdpdGggdGhlIHNhbWUgbmFtZSBidXQgY29uZmxpY3RpbmcgdHlwZS4gVGhlDQo+IFJFTEFY IE5HIHNjaGVtYSBmb3IgcnBjLXJlcGx5IGNvbnRhaW5zIGEgY2hvaWNlIGJldHdlZW4gdGhlIHR3 bw0KPiBhbHRlcm5hdGl2ZXMuDQoNCg0KSGkgTGFkYSwNCg0KVGhhbmtzIGZvciB0aGUgZXhhbXBs ZXMuICBBcyBJIHdyb3RlIGluIG15IG90aGVyIG1lc3NhZ2UsIEknbSB0cnlpbmcgdG8gZG8gdGhp cyB3aXRoIFhTRCwgYXMgdGhhdCBpcyB3aGF0IHRoZSBOZXRDb25mIHNwZWMgdXNlcyB0byBkZWZp bmUgdGhlIHRyYW5zcG9ydC4NCg0KSSB0aG91Z2h0IHlvdXIgaWRlYSBvZiB1c2luZyBhICdjaG9p Y2UnIHdhcyBwcmV0dHkgY2xldmVyLCBzbyBJIHRyaWVkIHRvIHJlcHJvZHVjZSB0aGUgaWRlYSBp biBYU0QgYnV0LCB1bmZvcnR1bmF0ZWx5LCBpdCBpcyBub3QgbGVnYWwgWFNEIHRvIGhhdmUgdHdv IGVsZW1lbnRzIHdpdGggdGhlIHNhbWUgbmFtZSBkZWZpbmVkIHVuZGVyIGFuIDx4czpjaG9pY2U+ LiAgSSB0aGVuIGRlY2lkZWQgdG8gdHJ5IHVzaW5nIGEgPHhzOnVuaW9uPiwgYnV0IHRoYXQgYWxz byBkaWRuJ3Qgd29yayBiZWNhdXNlIHhzOnVuaW9uIGNhbiBvbmx5IGJlIHVzZWQgZm9yIHNpbXBs ZVR5cGVzLCBhbmQgdGhlIE5ldENvbmYgWFNEIGRlZmluZXMgIm5jOnJwY1Jlc3BvbnNlVHlwZSIg YXMgYSBjb21wbGV4VHlwZS4gIFRoaXMgYnJpbmdzIG1lIHRvIG15IGxhc3QgcHJvYmxlbSwgd2hp Y2ggaXMgdGhhdCwgYmVjYXVzZSBpdCBtdXN0IGJlIGEgY29tcGxleFR5cGUsIGl0IGNhbm5vdCBp dHNlbGYgY29udGFpbiBkYXRhOyB0aGF0IGlzLCBJIGNhbm5vdCBnZW5lcmF0ZSBYU0QgKHVzaW5n IHRoZSA0NzQxYml6LTA2IFhTRCkgdG8gdmFsaWRhdGU6DQoNCiAgPHJwYy1yZXBseSBtZXNzYWdl LWlkPSIxMDEiDQogICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0 Y29uZjpiYXNlOjEuMCI+DQogICAgPHN0YXR1cyB4bWxucz0iaHR0cDovL2FjbWUuZXhhbXBlLmNv bS9zeXN0ZW0iPg0KICAgICAgVGhlIGltYWdlIGFjbWVmdy0yLjMgaXMgYmVpbmcgaW5zdGFsbGVk DQogICAgPC9zdGF0dXM+DQogIDwvcnBjLXJlcGx5Pg0KDQoNCkkgaGFkIHRvIGRlZmluZSBhbiBl bGVtZW50IChpLmUuIDx2YWx1ZT4pIHRvIHBsYWNlIHRoZSBkYXRhIGludG86DQoNCiAgPHJwYy1y ZXBseSBtZXNzYWdlLWlkPSIxMDEiDQogICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFt czp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgPHN0YXR1cyB4bWxucz0iaHR0cDovL2Fj bWUuZXhhbXBlLmNvbS9zeXN0ZW0iPg0KICAgICAgIDx2YWx1ZT5UaGUgaW1hZ2UgYWNtZWZ3LTIu MyBpcyBiZWluZyBpbnN0YWxsZWQ8L3ZhbHVlPg0KICAgIDwvc3RhdHVzPg0KICA8L3JwYy1yZXBs eT4NCg0KDQpUaGlzIG1lYW5zIHRoYXQgdGhlcmUgaXMgbm8gd2F5LCB1c2luZyB0aGUgWFNEIHRo YXQgd2lsbCBiZSBwdWJsaXNoZWQgaW4gNDc0MWJpei0wNiwgdG8gZGV2ZWxvcCBYU0QgdG8gdmFs aWRhdGUgdGhlIGV4YW1wbGUgc2hvd24gaW4gUkZDIDYwMjAsIHNlY3Rpb24gNC4yLjkuDQoNClBl cmhhcHMgdGhlIHF1ZXN0aW9uIGlzIGlmIHdlJ3JlIHRyeWluZyB0byBzdXBwb3J0IFhTRCBhdCBh bGw/ICBJIGtub3cgdGhlIENoYXJ0ZXIgc2F5cyB0aGUgV0cgd2lsbCBvbmx5IGRlZmluZSBhIG1h cHBpbmcgdG8gRFNETCwgYnV0IG5vdyBpdCBzZWVtcyB0aGF0IGEgbWFwcGluZyB0byBYU0QgaXNu 4oCZdCBldmVuIHBvc3NpYmxlIC0gaXMgdGhhdCBPSz8NCg0KDQpUaGFua3MsDQpLZW50DQoNCg0K DQo= From lhotka@cesnet.cz Tue Jan 11 01:27:20 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D833A69F8 for ; Tue, 11 Jan 2011 01:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-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 fv0qPBqmKXpM for ; Tue, 11 Jan 2011 01:27:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 1AC8D3A63EB for ; Tue, 11 Jan 2011 01:27:17 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 6E9F02CDE057; Tue, 11 Jan 2011 10:29:32 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD37464047CF@EMBX01-HQ.jnpr.net> References: <201101082244.p08MiI0V010910@idle.juniper.net> <1294562751.6461.6.camel@behold> <84600D05C20FF943918238042D7670FD37464047CF@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 11 Jan 2011 10:29:31 +0100 Message-ID: <1294738171.6052.23.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 09:27:20 -0000 On Po, 2011-01-10 at 11:48 -0800, Kent Watsen wrote: > >> I'm confused. How does "each rpc output [have] its own namespace"? > >> Why doesn't the namespace of the module cover all rpc output contents? > > > > Sec. 6.2.1, 7th bullet: > > > > o All leafs, leaf-lists, lists, containers, choices, rpcs, > > notifications, and anyxmls defined (directly or through a uses > > statement) within a parent node or at the top level of the module > > or its submodules share the same identifier namespace. This > > namespace is scoped to the parent node or module, unless the > > parent node is a case node. In that case, the namespace is scoped > > to the closest ancestor node that is not a case or choice node. > > > > So namespace of the "status" leaf in the following snippet is scoped to > > its parent node which is "output". On the other hand, the name of the > > rpc ("foo") is at the top-level of the module. > > > > rpc foo { > > output { > > leaf status { > > type string; > > must "starts-with(.,'FOO')"; > > } > > } > > } > > > Despite what section 6.2.1 says, the example below from section 4.2.9 shows the status node in the module's namespace (i.e. xmlns="http://acme.example.com/system"): > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > The image acmefw-2.3 is being installed. > > > > Is the example wrong? No, it's OK, sec. 6.2.1 talks about *identifier namespaces*, i.e. scoping of node names within a YANG module which has nothing to do with XML namespaces - all names in a module, be it in the data part or rpc, belong to the same XML namespace. > > > Also, please note that with XSD(*), the only way I have been able to validate two RPC replies having the same name and namespace is to define them into distinct XSD files (see attached XSD files). The implication of this is that a YANG-to-XSD convertor would need to generate an XSD file per RPC... > > * RelaxNG and DSDL are nice, but the NetConf schema is XSD, so I'm using it IMO the XSD schema in 4741bis is pretty much unusable for formal validation because it tries to be a common schema for both client and server. I summarized the problems in the now expired draft http://tools.ietf.org/id/draft-lhotka-netconf-relaxng-00.txt (sec. 2), I think most objections remain valid. Lada > > > Thanks, > Kent > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Jan 11 08:04:13 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CB13A6824 for ; Tue, 11 Jan 2011 08:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-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 zgmeuLpzgWEH for ; Tue, 11 Jan 2011 08:04:13 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id AB7E33A6809 for ; Tue, 11 Jan 2011 08:04:12 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id D1D582CDE04B; Tue, 11 Jan 2011 17:06:27 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 11 Jan 2011 17:06:27 +0100 Message-ID: <1294761987.6052.120.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 16:04:13 -0000 On Po, 2011-01-10 at 12:21 -0800, Kent Watsen wrote: > > This means that there is no way, using the XSD that will be published > in 4741biz-06, to develop XSD to validate the example shown in RFC > 6020, section 4.2.9. > > Perhaps the question is if we're trying to support XSD at all? I know > the Charter says the WG will only define a mapping to DSDL, but now it > seems that a mapping to XSD isn’t even possible - is that OK? For validation of instance documents using off-the-shelf XML tools, DSDL currently seems to be the only serious option. The only problem is, as you rightly say, that NETCONF messages are defined using XSD. I had proposed RELAX NG many times for this purpose but the NETCONF WG consensus was in favor of XSD. If there was any interest, I could resurrect the old I-D which IMO provides quite a strict RELAX NG validation framework for all NETCONF stuff and can be combined with data model schemas. Lada > > > Thanks, > Kent > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Tue Jan 11 11:04:19 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36593A69A4 for ; Tue, 11 Jan 2011 11:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1zkcsTyB4jE for ; Tue, 11 Jan 2011 11:04:18 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id A49913A67FF for ; Tue, 11 Jan 2011 11:04:18 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0BJ0YgQ021280; Tue, 11 Jan 2011 11:06:33 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id trvhrg0qj-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jan 2011 11:06:33 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 11:12:29 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 11 Jan 2011 11:06:21 -0800 From: Andy Bierman To: Ladislav Lhotka , Kent Watsen Date: Tue, 11 Jan 2011 11:06:20 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuxqYrdnxGDoRS+TM6Z25xRaAPJvAAFITQQ Message-ID: References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> In-Reply-To: <1294761987.6052.120.camel@behold> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-11_08:2011-01-11, 2011-01-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101110083 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 19:04:20 -0000 SGksDQoNCkkgZG8gbm90IHRoaW5rIHdlIG5lZWQgdG8gcmVkbyB0aGUgcHJvdG9jb2wgc2NoZW1h IGluIFJlbGF4TkcuDQpUaGUgWFNEIHVzZXMgc3Vic3RpdHV0aW9uR3JvdXAgdG8gcGx1ZyBpbiBk aWZmZXJlbnQgdmFyaWFudHMNCnRvIDxycGMtcmVwbHk+LiAgVGhlcmUgaGFzIG5ldmVyIGJlZW4g dGhlIGFiaWxpdHkgdG8gYXNzb2NpYXRlDQphIFFOYW1lIHdpdGggYSBzaW5nbGUgcmVwbHkuICBV cCB1bnRpbCBub3csIG5vYm9keSBoYXMgc2FpZA0Kd2UgbmVlZCB0aGUgY2xpZW50IHRvIGJlIHN0 YXRlbGVzcyBzbyBpdCBjYW4gdmFsaWRhdGUgcmFuZG9tIDxycGMtcmVwbHk+DQpjb250ZW50cy4g IEdpdmVuIHRoYXQgdGhlIG9ubHkgMyBzdGFuZGFyZCBvcGVyYXRpb25zIHRoYXQgcmV0dXJuIGRh dGENCnVzZSAnYW55eG1sJyBlbmNvZGluZywgdGhlcmUgaXMgcmVhbGx5IG5vdCBtdWNoIHRvIHZh bGlkYXRlIGluIGEgcmVwbHkuDQoNCg0KQW5keQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFkaXNsYXYgTGhvdGthDQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDExLCAyMDExIDg6MDYgQU0NClRvOiBLZW50IFdhdHNlbg0KQ2M6IG5ldG1vZEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIHF1ZXN0aW9ucyBmb3IgaG93IHlhbmcncyBvdXRw dXQgc3RhdGVtZW50IG1hcHMgdG8gcnBjLXJlcGxpZXMNCg0KT24gUG8sIDIwMTEtMDEtMTAgYXQg MTI6MjEgLTA4MDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiANCj4gVGhpcyBtZWFucyB0aGF0IHRo ZXJlIGlzIG5vIHdheSwgdXNpbmcgdGhlIFhTRCB0aGF0IHdpbGwgYmUgcHVibGlzaGVkDQo+IGlu IDQ3NDFiaXotMDYsIHRvIGRldmVsb3AgWFNEIHRvIHZhbGlkYXRlIHRoZSBleGFtcGxlIHNob3du IGluIFJGQw0KPiA2MDIwLCBzZWN0aW9uIDQuMi45Lg0KPiANCj4gUGVyaGFwcyB0aGUgcXVlc3Rp b24gaXMgaWYgd2UncmUgdHJ5aW5nIHRvIHN1cHBvcnQgWFNEIGF0IGFsbD8gIEkga25vdw0KPiB0 aGUgQ2hhcnRlciBzYXlzIHRoZSBXRyB3aWxsIG9ubHkgZGVmaW5lIGEgbWFwcGluZyB0byBEU0RM LCBidXQgbm93IGl0DQo+IHNlZW1zIHRoYXQgYSBtYXBwaW5nIHRvIFhTRCBpc27igJl0IGV2ZW4g cG9zc2libGUgLSBpcyB0aGF0IE9LPw0KDQpGb3IgdmFsaWRhdGlvbiBvZiBpbnN0YW5jZSBkb2N1 bWVudHMgdXNpbmcgb2ZmLXRoZS1zaGVsZiBYTUwgdG9vbHMsIERTREwNCmN1cnJlbnRseSBzZWVt cyB0byBiZSB0aGUgb25seSBzZXJpb3VzIG9wdGlvbi4gVGhlIG9ubHkgcHJvYmxlbSBpcywgYXMN CnlvdSByaWdodGx5IHNheSwgdGhhdCBORVRDT05GIG1lc3NhZ2VzIGFyZSBkZWZpbmVkIHVzaW5n IFhTRC4gSSBoYWQNCnByb3Bvc2VkIFJFTEFYIE5HIG1hbnkgdGltZXMgZm9yIHRoaXMgcHVycG9z ZSBidXQgdGhlIE5FVENPTkYgV0cNCmNvbnNlbnN1cyB3YXMgaW4gZmF2b3Igb2YgWFNELiBJZiB0 aGVyZSB3YXMgYW55IGludGVyZXN0LCBJIGNvdWxkDQpyZXN1cnJlY3QgdGhlIG9sZCBJLUQgd2hp Y2ggSU1PIHByb3ZpZGVzIHF1aXRlIGEgc3RyaWN0IFJFTEFYIE5HDQp2YWxpZGF0aW9uIGZyYW1l d29yayBmb3IgYWxsIE5FVENPTkYgc3R1ZmYgYW5kIGNhbiBiZSBjb21iaW5lZCB3aXRoIGRhdGEN Cm1vZGVsIHNjaGVtYXMuDQoNCkxhZGENCg0KPiANCj4gDQo+IFRoYW5rcywNCj4gS2VudA0KPiAN Cj4gDQo+IA0KDQotLSANCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUDQpQR1AgS2V5IElEOiBFNzRF OEMwQw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From lhotka@cesnet.cz Tue Jan 11 12:41:24 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DB528C129 for ; Tue, 11 Jan 2011 12:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-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 iG9d82G0jvip for ; Tue, 11 Jan 2011 12:41:23 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id D4C2B28C0F9 for ; Tue, 11 Jan 2011 12:41:21 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 95C622CDE05B; Tue, 11 Jan 2011 21:43:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: Date: Tue, 11 Jan 2011 21:43:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> To: Andy Bierman X-Mailer: Apple Mail (2.1082) Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 20:41:24 -0000 On Jan 11, 2011, at 8:06 PM, Andy Bierman wrote: > Hi, >=20 > I do not think we need to redo the protocol schema in RelaxNG. I don't mind the protocol schema in 4741bis, this could remain as it is = if people prefer it, but perhaps a standard framework for relatively = strict validation could be useful. It looks like I am not the only one = who performs instance validation with xmllint or jing. And the framework = is essentially done - in my expired I-D. =20 > The XSD uses substitutionGroup to plug in different variants > to . There has never been the ability to associate > a QName with a single reply. Up until now, nobody has said > we need the client to be stateless so it can validate random = > contents. Given that the only 3 standard operations that return data > use 'anyxml' encoding, there is really not much to validate in a = reply. Sure, validation cannot be stateless. One option that I actually plan to = implement in pyang is to pass the rpc request to the validator which can = then figure out the precise schema to be used for the reply.=20 The anyxmls in 4741bis are just placeholders for higher-layer data. My = idea is that the schemas could be layered in the same way as NETCONF = protocol.=20 Lada >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf Of Ladislav Lhotka > Sent: Tuesday, January 11, 2011 8:06 AM > To: Kent Watsen > Cc: netmod@ietf.org > Subject: Re: [netmod] questions for how yang's output statement maps = to rpc-replies >=20 > On Po, 2011-01-10 at 12:21 -0800, Kent Watsen wrote: >>=20 >> This means that there is no way, using the XSD that will be published >> in 4741biz-06, to develop XSD to validate the example shown in RFC >> 6020, section 4.2.9. >>=20 >> Perhaps the question is if we're trying to support XSD at all? I = know >> the Charter says the WG will only define a mapping to DSDL, but now = it >> seems that a mapping to XSD isn=92t even possible - is that OK? >=20 > For validation of instance documents using off-the-shelf XML tools, = DSDL > currently seems to be the only serious option. The only problem is, as > you rightly say, that NETCONF messages are defined using XSD. I had > proposed RELAX NG many times for this purpose but the NETCONF WG > consensus was in favor of XSD. If there was any interest, I could > resurrect the old I-D which IMO provides quite a strict RELAX NG > validation framework for all NETCONF stuff and can be combined with = data > model schemas. >=20 > Lada >=20 >>=20 >>=20 >> Thanks, >> Kent >>=20 >>=20 >>=20 >=20 > --=20 > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From kwatsen@juniper.net Tue Jan 11 12:47:18 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7ED28C125 for ; Tue, 11 Jan 2011 12:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_210=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 ruPeO3Ei3rsK for ; Tue, 11 Jan 2011 12:47:17 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id A205E28C0F9 for ; Tue, 11 Jan 2011 12:47:17 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTSzCXUdbDja4s6VtghZqzVLhijw1TjQX@postini.com; Tue, 11 Jan 2011 12:49:35 PST 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; Tue, 11 Jan 2011 12:48:23 -0800 From: Kent Watsen To: Ladislav Lhotka Date: Tue, 11 Jan 2011 12:48:20 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuxceE5h928edsPQxmvooPZBpxZ3gANmrFw Message-ID: <84600D05C20FF943918238042D7670FD37465B858C@EMBX01-HQ.jnpr.net> References: <201101082244.p08MiI0V010910@idle.juniper.net> <1294562751.6461.6.camel@behold> <84600D05C20FF943918238042D7670FD37464047CF@EMBX01-HQ.jnpr.net> <1294738171.6052.23.camel@behold> In-Reply-To: <1294738171.6052.23.camel@behold> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 20:47:18 -0000 PiBObywgaXQncyBPSywgc2VjLiA2LjIuMSB0YWxrcyBhYm91dCAqaWRlbnRpZmllciBuYW1lc3Bh Y2VzKiwgaS5lLg0KPiBzY29waW5nIG9mIG5vZGUgbmFtZXMgd2l0aGluIGEgWUFORyBtb2R1bGUg d2hpY2ggaGFzIG5vdGhpbmcgdG8gZG8gd2l0aA0KPiBYTUwgbmFtZXNwYWNlcyAtIGFsbCBuYW1l cyBpbiBhIG1vZHVsZSwgYmUgaXQgaW4gdGhlIGRhdGEgcGFydCBvciBycGMsDQo+IGJlbG9uZyB0 byB0aGUgc2FtZSBYTUwgbmFtZXNwYWNlLiANCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlv bi4gIA0KDQoNCg0KPiBJTU8gdGhlIFhTRCBzY2hlbWEgaW4gNDc0MWJpcyBpcyBwcmV0dHkgbXVj aCB1bnVzYWJsZSBmb3IgZm9ybWFsDQo+IHZhbGlkYXRpb24gYmVjYXVzZSBpdCB0cmllcyB0byBi ZSBhIGNvbW1vbiBzY2hlbWEgZm9yIGJvdGggY2xpZW50IGFuZA0KPiBzZXJ2ZXIuIEkgc3VtbWFy aXplZCB0aGUgcHJvYmxlbXMgaW4gdGhlIG5vdyBleHBpcmVkIGRyYWZ0DQo+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1saG90a2EtbmV0Y29uZi1yZWxheG5nLTAwLnR4dA0KPiAoc2Vj LiAyKSwgSSB0aGluayBtb3N0IG9iamVjdGlvbnMgcmVtYWluIHZhbGlkLg0KDQpUaGFua3MgZm9y IHRoZSBsaW5rIC0gdGhvc2UgYXJlIHNvbWUgcHJldHR5IGdvb2QgcG9pbnRzIGFib3V0IFhTRCBh bmQgSSBzZWUgaG93IHlvdXIgUmVsYXhORyBzY2hlbWEgYWRkcmVzc2VzIHRob3NlIHBvaW50cy4g ICBBZGRpdGlvbmFsbHksIGRpZCB5b3Ugc2VlIHRoZSBvdGhlciBlbWFpbCBJIHNlbnQgeWVzdGVy ZGF5IHdoZXJlIEkgc2hvd2VkIGhvdyB0aGUgNDc0MWJpcyBzY2hlbWEgY291bGQgbm90IGJlIHVz ZWQgdG8gZGVzY3JpYmUgYW4gUlBDIHJlcGx5IHRoYXQgd2FzIGp1c3QgYW4geHM6c2ltcGxlVHlw ZT8NCg0KDQoNCg== From kwatsen@juniper.net Tue Jan 11 13:21:40 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6AF3A67B3 for ; Tue, 11 Jan 2011 13:21:39 -0800 (PST) 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 vIBbDdJhQOVR for ; Tue, 11 Jan 2011 13:21:33 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id D95E93A677C for ; Tue, 11 Jan 2011 13:21:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTSzKYhfq2ieIuDDYP/Vp7o/DgbeE8I+2@postini.com; Tue, 11 Jan 2011 13:23:50 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 11 Jan 2011 13:20:33 -0800 From: Kent Watsen To: Andy Bierman , Ladislav Lhotka Date: Tue, 11 Jan 2011 13:20:31 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuxqYrdnxGDoRS+TM6Z25xRaAPJvAAFITQQAAOGl5A= Message-ID: <84600D05C20FF943918238042D7670FD37465B85DD@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 21:21:40 -0000 DQo+IFRoZSBYU0QgdXNlcyBzdWJzdGl0dXRpb25Hcm91cCB0byBwbHVnIGluIGRpZmZlcmVudCB2 YXJpYW50cw0KPiB0byA8cnBjLXJlcGx5Pi4gIFRoZXJlIGhhcyBuZXZlciBiZWVuIHRoZSBhYmls aXR5IHRvIGFzc29jaWF0ZQ0KPiBhIFFOYW1lIHdpdGggYSBzaW5nbGUgcmVwbHkuICANCg0KU28g dGhlbiB5b3UgYWdyZWUgdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiA0LjIuOSBjb25mbGljdHMgd2l0 aCA0NzQxYml6IHNpbmNlIHRoZSA0NzQxYml6IHNjaGVtYSByZXF1aXJlcyBhIGNvbXBsZXhUeXBl IChub3QgYSBzaW1wbGVUeXBlKT8NCg0KDQoNCj4gVXAgdW50aWwgbm93LCBub2JvZHkgaGFzIHNh aWQgd2UgbmVlZCB0aGUgY2xpZW50IHRvIGJlIHN0YXRlbGVzcyBzbyBpdCBjYW4gdmFsaWRhdGUg cmFuZG9tIDxycGMtcmVwbHk+IGNvbnRlbnRzLiAgDQoNClRoZSBvcmlnaW5hbCBzdGF0ZW1lbnQg d2FzIHRvbyBicm9hZC4gIEl0J3MganVzdCB0aGF0IHdlIGhhdmUgYSBzaW5nbGUgWFNEIGZpbGUg Zm9yIGVhY2ggb2Ygb3VyIHByb3ByaWV0YXJ5IGNhcGFiaWxpdGllcy4gIFdlIGhhdmUgYWx3YXlz IGJlZW4gYWJsZSB0byBkbyB0aGlzIHNpbmNlIGVhY2ggUlBDLVJlcGx5IGhhcyBhIHVuaXF1ZSBu YW1lIChuZXZlciBzb21ldGhpbmcgZ2VuZXJpYyBsaWtlICJzdGF0dXMiKS4gIFRodXMgb3VyIHZh bGlkYXRvcnMgY291bGQganVzdCBwYXNzIHRoZSBlbnRpcmUgWFNEIGludG8gYHhtbGxpbnRgIGFu ZCBsZXQgaXQgc2VsZWN0IHRoZSBtYXRjaGluZyBlbGVtZW50ICh0aGF0J3MgdGhlICdzdGF0ZWxl c3MnIHBhcnQpLiAgSSBzdXBwb3NlIGl0IHdhcyBhIGJhZCBhc3N1bXB0aW9uIHdlIGNvdWxkIGRv IHRoaXMgYWxsIGFsb25nLCBhcyBOZXRDb25mIHNwZWMgZG9lc24ndCBzYXkgYW55dGhpbmcgYWJv dXQgaXQsIGJ1dCBub3cgaXQgc2VlbXMgdGhhdCwgaWYgd2Ugd2FudCB0byBjb250aW51ZSB1c2lu ZyBYU0QsIHdlJ2QgbmVlZCB0byBkZWZpbmUgZWFjaCBSUEMgaW4gaXRzIG93biBYU0QgZmlsZSBh bmQgdXBkYXRlIG91ciB2YWxpZGF0b3IgdG8gcGFzcyB0aGUgcHJjLXNwZWNpZmljIFhTRCB0byBg eG1sbGludGAuICBBbnl3YXksIEknbSBzb3JyeSBJIGJyb3VnaHQgdGhpcyB1cCwgbGV0J3MgZHJv cCBpdCBub3csIGl0J3Mgbm90IGEgV0cgaXNzdWUuDQoNCg0KDQo+IEdpdmVuIHRoYXQgdGhlIG9u bHkgMyBzdGFuZGFyZCBvcGVyYXRpb25zIHRoYXQgcmV0dXJuIGRhdGENCj4gdXNlICdhbnl4bWwn IGVuY29kaW5nLCB0aGVyZSBpcyByZWFsbHkgbm90IG11Y2ggdG8gdmFsaWRhdGUgaW4gYSByZXBs eS4NCg0KSSdtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgdGhpcywgYnV0IHdlIHVzZSBYU0Qg bW9kZWwgdGhlIGV4YWN0IGNvbnRlbnRzIG9mIGVhY2ggYW5kIGV2ZXJ5IG9uZSBvZiBvdXIgcnBj cyBhbmQgcnBjLXJlcGxpZXMuICBHaXZlbiB0aGF0IHdlIGhhdmUgcXVpdGUgYSBudW1iZXIgb2Yg cHJvcHJpZXRhcnkgY2FwYWJpbGl0aWVzLCBmb3JtYWwgdmFsaWRhdGlvbiBpcyBwcmV0dHkgY3Jp dGljYWwgaW4gb3VyIGludGVyb3BlcmFiaWxpdHkgd2l0aCAzcmQtcGFydGllcy4uLg0KDQoNCg== From lhotka@cesnet.cz Tue Jan 11 13:24:24 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2A13A67B3 for ; Tue, 11 Jan 2011 13:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, NO_RELAYS=-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 W3tfB5nAI++A for ; Tue, 11 Jan 2011 13:24:22 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 9F4223A67B7 for ; Tue, 11 Jan 2011 13:24:22 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 94F052CDE057; Tue, 11 Jan 2011 22:26:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <84600D05C20FF943918238042D7670FD37465B858C@EMBX01-HQ.jnpr.net> Date: Tue, 11 Jan 2011 22:26:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <678FE83B-CCFB-4095-B285-83CEE15EF0AE@cesnet.cz> References: <201101082244.p08MiI0V010910@idle.juniper.net> <1294562751.6461.6.camel@behold> <84600D05C20FF943918238042D7670FD37464047CF@EMBX01-HQ.jnpr.net> <1294738171.6052.23.camel@behold> <84600D05C20FF943918238042D7670FD37465B858C@EMBX01-HQ.jnpr.net> To: Kent Watsen X-Mailer: Apple Mail (2.1082) Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 21:24:24 -0000 On Jan 11, 2011, at 9:48 PM, Kent Watsen wrote: >> No, it's OK, sec. 6.2.1 talks about *identifier namespaces*, i.e. >> scoping of node names within a YANG module which has nothing to do = with >> XML namespaces - all names in a module, be it in the data part or = rpc, >> belong to the same XML namespace.=20 >=20 > Thanks for the clarification. =20 >=20 >=20 >=20 >> IMO the XSD schema in 4741bis is pretty much unusable for formal >> validation because it tries to be a common schema for both client and >> server. I summarized the problems in the now expired draft >> http://tools.ietf.org/id/draft-lhotka-netconf-relaxng-00.txt >> (sec. 2), I think most objections remain valid. >=20 > Thanks for the link - those are some pretty good points about XSD and = I see how your RelaxNG schema addresses those points. Additionally, = did you see the other email I sent yesterday where I showed how the = 4741bis schema could not be used to describe an RPC reply that was just = an xs:simpleType? Yes, but I must admit I don't have enough XSD expertise to help you. Use = RELAX NG instead. :-) Lada >=20 >=20 >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Tue Jan 11 13:44:00 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AC13A67EC for ; Tue, 11 Jan 2011 13:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7z+WpSg8tNE for ; Tue, 11 Jan 2011 13:43:59 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 6073B3A67C1 for ; Tue, 11 Jan 2011 13:43:59 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0BLVJCC023368; Tue, 11 Jan 2011 13:46:15 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id trvhrg456-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jan 2011 13:46:15 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 13:52:22 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 11 Jan 2011 13:46:14 -0800 From: Andy Bierman To: Kent Watsen , Ladislav Lhotka Date: Tue, 11 Jan 2011 13:46:13 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuxqYrdnxGDoRS+TM6Z25xRaAPJvAAFITQQAAOGl5AAAsYf8A== Message-ID: References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> <84600D05C20FF943918238042D7670FD37465B85DD@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD37465B85DD@EMBX01-HQ.jnpr.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-11_08:2011-01-11, 2011-01-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101110103 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Jan 2011 21:44:00 -0000 SWYgdGhlIFhTRCBpbiA0NzQxYmlzIGhhcyBlcnJvcnMgaW4gaXQsIHRoZXkgc2hvdWxkIGJlIGZp eGVkLg0KSSBkb24ndCB0aGluayB0aGUgV0cgZXZlciBjb25zaWRlcmVkIHRoZSBuYW1pbmcgY29u ZmxpY3QgaXNzdWVzIGluIDxycGMtcmVwbHk+DQp0aGF0IGEgY2xpZW50IG11c3QgZGVhbCB3aXRo LiAgRGlzY3Vzc2lvbnMgd2VyZSB2ZXJ5IHNlcnZlci1mb2N1c2VkLg0KSSB0aGluayB0aGVyZSB3 YXMgYSBjb25jZXJuIGFib3V0IHdhc3RpbmcgYmFuZHdpZHRoIHdpdGggZXh0cmEgY29udGFpbmVy cw0KdGhhdCBoYXZlIG5vIHB1cnBvc2UuDQoNClRoZXJlIGhhcyBiZWVuIGFuIGFzc3VtcHRpb24g dGhhdCB0aGUgY2xpZW50IHdpbGwganVzdCBrbm93IHdoaWNoIFJQQw0Kd2FzIHNlbnQsIGFuZCB0 aGF0IGlzIGhvdyB0aGUgPHJwYy1yZXBseT4gd2lsbCBiZSBwcm9jZXNzZWQuDQpJIHRoaW5rIHdl IGFyZSBzdHVjayB3aXRoIHRoaXMgYXNzdW1wdGlvbi4NCg0KQW5keQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2VudCBXYXRzZW4gW21haWx0bzprd2F0c2VuQGp1bmlwZXIu bmV0XSANClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTEsIDIwMTEgMToyMSBQTQ0KVG86IEFuZHkg Qmllcm1hbjsgTGFkaXNsYXYgTGhvdGthDQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBS RTogW25ldG1vZF0gcXVlc3Rpb25zIGZvciBob3cgeWFuZydzIG91dHB1dCBzdGF0ZW1lbnQgbWFw cyB0byBycGMtcmVwbGllcw0KDQoNCj4gVGhlIFhTRCB1c2VzIHN1YnN0aXR1dGlvbkdyb3VwIHRv IHBsdWcgaW4gZGlmZmVyZW50IHZhcmlhbnRzDQo+IHRvIDxycGMtcmVwbHk+LiAgVGhlcmUgaGFz IG5ldmVyIGJlZW4gdGhlIGFiaWxpdHkgdG8gYXNzb2NpYXRlDQo+IGEgUU5hbWUgd2l0aCBhIHNp bmdsZSByZXBseS4gIA0KDQpTbyB0aGVuIHlvdSBhZ3JlZSB0aGUgZXhhbXBsZSBpbiBzZWN0aW9u IDQuMi45IGNvbmZsaWN0cyB3aXRoIDQ3NDFiaXogc2luY2UgdGhlIDQ3NDFiaXogc2NoZW1hIHJl cXVpcmVzIGEgY29tcGxleFR5cGUgKG5vdCBhIHNpbXBsZVR5cGUpPw0KDQoNCg0KPiBVcCB1bnRp bCBub3csIG5vYm9keSBoYXMgc2FpZCB3ZSBuZWVkIHRoZSBjbGllbnQgdG8gYmUgc3RhdGVsZXNz IHNvIGl0IGNhbiB2YWxpZGF0ZSByYW5kb20gPHJwYy1yZXBseT4gY29udGVudHMuICANCg0KVGhl IG9yaWdpbmFsIHN0YXRlbWVudCB3YXMgdG9vIGJyb2FkLiAgSXQncyBqdXN0IHRoYXQgd2UgaGF2 ZSBhIHNpbmdsZSBYU0QgZmlsZSBmb3IgZWFjaCBvZiBvdXIgcHJvcHJpZXRhcnkgY2FwYWJpbGl0 aWVzLiAgV2UgaGF2ZSBhbHdheXMgYmVlbiBhYmxlIHRvIGRvIHRoaXMgc2luY2UgZWFjaCBSUEMt UmVwbHkgaGFzIGEgdW5pcXVlIG5hbWUgKG5ldmVyIHNvbWV0aGluZyBnZW5lcmljIGxpa2UgInN0 YXR1cyIpLiAgVGh1cyBvdXIgdmFsaWRhdG9ycyBjb3VsZCBqdXN0IHBhc3MgdGhlIGVudGlyZSBY U0QgaW50byBgeG1sbGludGAgYW5kIGxldCBpdCBzZWxlY3QgdGhlIG1hdGNoaW5nIGVsZW1lbnQg KHRoYXQncyB0aGUgJ3N0YXRlbGVzcycgcGFydCkuICBJIHN1cHBvc2UgaXQgd2FzIGEgYmFkIGFz c3VtcHRpb24gd2UgY291bGQgZG8gdGhpcyBhbGwgYWxvbmcsIGFzIE5ldENvbmYgc3BlYyBkb2Vz bid0IHNheSBhbnl0aGluZyBhYm91dCBpdCwgYnV0IG5vdyBpdCBzZWVtcyB0aGF0LCBpZiB3ZSB3 YW50IHRvIGNvbnRpbnVlIHVzaW5nIFhTRCwgd2UnZCBuZWVkIHRvIGRlZmluZSBlYWNoIFJQQyBp biBpdHMgb3duIFhTRCBmaWxlIGFuZCB1cGRhdGUgb3VyIHZhbGlkYXRvciB0byBwYXNzIHRoZSBw cmMtc3BlY2lmaWMgWFNEIHRvIGB4bWxsaW50YC4gIEFueXdheSwgSSdtIHNvcnJ5IEkgYnJvdWdo dCB0aGlzIHVwLCBsZXQncyBkcm9wIGl0IG5vdywgaXQncyBub3QgYSBXRyBpc3N1ZS4NCg0KDQoN Cj4gR2l2ZW4gdGhhdCB0aGUgb25seSAzIHN0YW5kYXJkIG9wZXJhdGlvbnMgdGhhdCByZXR1cm4g ZGF0YQ0KPiB1c2UgJ2FueXhtbCcgZW5jb2RpbmcsIHRoZXJlIGlzIHJlYWxseSBub3QgbXVjaCB0 byB2YWxpZGF0ZSBpbiBhIHJlcGx5Lg0KDQpJJ20gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0 aGlzLCBidXQgd2UgdXNlIFhTRCBtb2RlbCB0aGUgZXhhY3QgY29udGVudHMgb2YgZWFjaCBhbmQg ZXZlcnkgb25lIG9mIG91ciBycGNzIGFuZCBycGMtcmVwbGllcy4gIEdpdmVuIHRoYXQgd2UgaGF2 ZSBxdWl0ZSBhIG51bWJlciBvZiBwcm9wcmlldGFyeSBjYXBhYmlsaXRpZXMsIGZvcm1hbCB2YWxp ZGF0aW9uIGlzIHByZXR0eSBjcml0aWNhbCBpbiBvdXIgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIDNy ZC1wYXJ0aWVzLi4uDQoNCg0K From kwatsen@juniper.net Tue Jan 11 13:59:12 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231C63A67EB for ; Tue, 11 Jan 2011 13:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKIcksXp0UBR for ; Tue, 11 Jan 2011 13:59:11 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 483563A67C1 for ; Tue, 11 Jan 2011 13:59:11 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTSzTNyfjPu0iGJzqGKSapKh3krfJ/jHd@postini.com; Tue, 11 Jan 2011 14:01:29 PST 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; Tue, 11 Jan 2011 14:00:29 -0800 From: Kent Watsen To: Ladislav Lhotka , Andy Bierman Date: Tue, 11 Jan 2011 14:00:27 -0800 Thread-Topic: [netmod] formal validation (was: questions...) Thread-Index: Acux0AkNKrr1B69SRjadJzfDCpc4ugABXdNw Message-ID: <84600D05C20FF943918238042D7670FD37465B8684@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> In-Reply-To: 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] formal validation (was: questions...) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:59:12 -0000 > but perhaps a standard framework for relatively strict validation could b= e useful. > It looks like I am not the only one who performs instance validation with= xmllint > or jing Yes, exactly. In fact, I imagine most device vendors run unit tests, in or= der to claim they implement a capability. For them, the output schema is m= ore important than the input schema. On the flip side, for NMS vendors tha= t need to validate the messages their app sends to devices, the input schem= a is more important than the output schema. We do both at Juniper...albeit= with XSD (because we were doing XSD before YANG was a standard) =20 > One option that I actually plan to implement in pyang is to pass the rpc = request > to the validator which can then figure out the precise schema to be used = for the reply.=20 I'm glad you brought this up. The RNG schema that `yang2dsdl` generates is= concerning as the validation can only determine that the rpc-reply is vali= d to a large number of matching elements. But if there is more than one R= PC returning "", I want to be very sure that I'm validating against= the schema for the specific RPC that was executed. BTW, the way yang2dsdl= generates the RPC scheme is less concerning, since it's not possible for t= wo RPCs to have the same name in the same module... PS, I also looked at the output generated by `pyang -f dsdl` and wanted to = note that: 1) it doesn't seem to be valid, `xmllint --relaxng` complains about=20 having no children and having no start 2) the schema it generates for RPCs and RPC-Replies is very different than yang2dsdl's, but since they're both shipped with the same tool-ch= ain, which is to be considered more official? Thanks, Kent From kwatsen@juniper.net Tue Jan 11 17:05:23 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB7F3A680B for ; Tue, 11 Jan 2011 17:05:23 -0800 (PST) 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 SE5r0hVuyvC7 for ; Tue, 11 Jan 2011 17:05:22 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 94D403A67EF for ; Tue, 11 Jan 2011 17:05:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTSz+2phwGZ1SJc2+TJGcUaMwaVc2mN/i@postini.com; Tue, 11 Jan 2011 17:07:41 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 11 Jan 2011 17:03:47 -0800 From: Kent Watsen To: Andy Bierman , Ladislav Lhotka Date: Tue, 11 Jan 2011 17:03:40 -0800 Thread-Topic: [netmod] questions for how yang's output statement maps to rpc-replies Thread-Index: AcuxqYrdnxGDoRS+TM6Z25xRaAPJvAAFITQQAAOGl5AAAsYf8AAA8oZw Message-ID: <84600D05C20FF943918238042D7670FD37465B8962@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> <84600D05C20FF943918238042D7670FD37465B85DD@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] questions for how yang's output statement maps to rpc-replies X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Jan 2011 01:05:23 -0000 DQo+IElmIHRoZSBYU0QgaW4gNDc0MWJpcyBoYXMgZXJyb3JzIGluIGl0LCB0aGV5IHNob3VsZCBi ZSBmaXhlZC4NCj4gSSBkb24ndCB0aGluayB0aGUgV0cgZXZlciBjb25zaWRlcmVkIHRoZSBuYW1p bmcgY29uZmxpY3QgaXNzdWVzIGluIDxycGMtcmVwbHk+DQo+IHRoYXQgYSBjbGllbnQgbXVzdCBk ZWFsIHdpdGguICBEaXNjdXNzaW9ucyB3ZXJlIHZlcnkgc2VydmVyLWZvY3VzZWQuDQo+IEkgdGhp bmsgdGhlcmUgd2FzIGEgY29uY2VybiBhYm91dCB3YXN0aW5nIGJhbmR3aWR0aCB3aXRoIGV4dHJh IGNvbnRhaW5lcnMNCj4gdGhhdCBoYXZlIG5vIHB1cnBvc2UuDQoNClVnaCwgSSB3YXMgZmluYWxs eSBhYmxlIHRvIGRlZmluZSBhbiBYU0Qgc2NoZW1hIHRoYXQgd291bGQgdmFsaWRhdGUgdGhlIHJw Yy1yZXBseSBleGFtcGxlIGluIDYwMjAsIHNlY3Rpb24gNC4yLjkgdXNpbmcgdGhlIDQ3NDFiaXog c2NoZW1hOg0KDQogICA8eHM6ZWxlbWVudCBuYW1lPSJzdGF0dXMiIHN1YnN0aXR1dGlvbkdyb3Vw PSJuYzpycGNSZXNwb25zZSI+DQogICAgICA8eHM6Y29tcGxleFR5cGUgbWl4ZWQ9InRydWUiPg0K ICAgICAgICAgPHhzOmNvbXBsZXhDb250ZW50Pg0KICAgICAgICAgICAgPHhzOmV4dGVuc2lvbiBi YXNlPSJuYzpycGNSZXNwb25zZVR5cGUiLz4NCiAgICAgICAgIDwveHM6Y29tcGxleENvbnRlbnQ+ DQogICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgPC94czplbGVtZW50Pg0KDQpJJ20gdXNpbmcg dGhlIG1peGVkPSJ0cnVlIiBhdHRyaWJ1dGUgdG8gYWxsb3cgdGhlICJjb21wbGV4VHlwZSIgdG8g Y29udGFpbiBjaGFyYWN0ZXIgZGF0YS4gIFRoaXMgaXNuJ3QgaWRlYWwsIHNpbmNlIGl0J3MgZWZm ZWN0aXZlbHkgbGlrZSAiIyNhbnkiLCBidXQgaXQgd29ya3MsIHdoaWNoIG1lYW5zIHRoaXMgY29u ZmxpY3QgaXMgcmVzb2x2ZWQgKHllYWghKQ0KDQoNCg0KPiBUaGVyZSBoYXMgYmVlbiBhbiBhc3N1 bXB0aW9uIHRoYXQgdGhlIGNsaWVudCB3aWxsIGp1c3Qga25vdyB3aGljaCBSUEMNCj4gd2FzIHNl bnQsIGFuZCB0aGF0IGlzIGhvdyB0aGUgPHJwYy1yZXBseT4gd2lsbCBiZSBwcm9jZXNzZWQuDQo+ IEkgdGhpbmsgd2UgYXJlIHN0dWNrIHdpdGggdGhpcyBhc3N1bXB0aW9uLg0KDQpJIHJldHJhY3Rl ZC9leHBsYWluZWQgbXkgInN0YXRlbGVzcyIgY29tbWVudCBpbiBteSBwcmV2aW91cyBlbWFpbC4g IEknbSBPSyB3aXRoIHRoZSBjbGllbnQgaGF2aW5nIHRvIGtub3cgZXhhY3RseSB3aGljaCBzY2hl bWEgdG8gdXNlIHdoZW4gdmFsaWRhdGluZyBhbiBSUEMtUmVwbHk7IGl0J3MgYSBiaXQgbW9yZSBp bnZvbHZlZCwgYnV0IHRyYWN0YWJsZS4uLg0KDQpUaGFua3MsDQpLZW50DQoNCg0K From lhotka@cesnet.cz Tue Jan 11 22:56:07 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638033A6998 for ; Tue, 11 Jan 2011 22:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-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 YFY0F6x0c1N2 for ; Tue, 11 Jan 2011 22:56:05 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 29F983A699D for ; Tue, 11 Jan 2011 22:56:04 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0235E2CDE057; Wed, 12 Jan 2011 07:58:21 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD37465B8684@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374618CB28@EMBX01-HQ.jnpr.net> <1294486086.2926.8.camel@behold> <84600D05C20FF943918238042D7670FD3746404874@EMBX01-HQ.jnpr.net> <1294761987.6052.120.camel@behold> <84600D05C20FF943918238042D7670FD37465B8684@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 12 Jan 2011 07:58:21 +0100 Message-ID: <1294815501.12118.24.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: Andy Bierman , "netmod@ietf.org" Subject: Re: [netmod] formal validation (was: questions...) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 06:56:07 -0000 On Út, 2011-01-11 at 14:00 -0800, Kent Watsen wrote: > > but perhaps a standard framework for relatively strict validation could be useful. > > It looks like I am not the only one who performs instance validation with xmllint > > or jing > > Yes, exactly. In fact, I imagine most device vendors run unit tests, > in order to claim they implement a capability. For them, the output > schema is more important than the input schema. On the flip side, for > NMS vendors that need to validate the messages their app sends to > devices, the input schema is more important than the output schema. > We do both at Juniper...albeit with XSD (because we were doing XSD > before YANG was a standard) What's the opinion of others? Would it be useful to review and resubmit the old draft, maybe more focused on validation? http://tools.ietf.org/id/draft-lhotka-netconf-relaxng-00.txt ... > > PS, I also looked at the output generated by `pyang -f dsdl` and wanted to note that: > > 1) it doesn't seem to be valid, `xmllint --relaxng` complains about > having no children and having no start Yes, this is intentional, the hybrid schema contains multiple schemas divided by special markers in one document, so it is not a valid RELAX NG schema. This should probably be mentioned in the YANG-to-DSDL spec and in the pyang manpage. > > 2) the schema it generates for RPCs and RPC-Replies is very different > than yang2dsdl's, but since they're both shipped with the same tool-chain, > which is to be considered more official? The output of "pyang -f dsdl" is just an interim product that is used internally by the yang2dsdl script. It cannot be used for direct validation (except maybe informal validation by humans). Lada > > > Thanks, > Kent > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From kwatsen@juniper.net Wed Jan 12 15:13:25 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95533A67EC for ; Wed, 12 Jan 2011 15:13:25 -0800 (PST) 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 Tzd7cipUn8kw for ; Wed, 12 Jan 2011 15:13:24 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id BFCD53A6830 for ; Wed, 12 Jan 2011 15:13:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTS42HODCNPdd9qPhsD8ZB8sHhwRPacP2@postini.com; Wed, 12 Jan 2011 15:15:45 PST 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; Wed, 12 Jan 2011 15:13:03 -0800 From: Kent Watsen To: Martin Bjorklund Date: Wed, 12 Jan 2011 15:13:00 -0800 Thread-Topic: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) Thread-Index: Acuub8o9rHt5iGbHRUub4TlVyTEMKgEOD0qg Message-ID: <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> In-Reply-To: <20110107.143657.194513514.mbj@tail-f.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] backwards compatibility (was: how to know which module revision an RPC is for?) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Jan 2011 23:13:25 -0000 Martin writes: > > 1. unclear how "obsolete" status can ever be used (as to do so would br= eak > backwards compatibility) >=20 > I agree with Juergen and Andy. A robust client that sees a new > revision it does not understand will have to be prepared that some > nodes are obsolete and thus not implemented on the server. >=20 > This is of course something that has to be taken into account when > obsoleting an object. We have to treat inputs and outputs separately. For outputs, like RPC-Reply or Notifications, I agree that a client needs t= o be prepared that a 'non-mandatory' node may be obsoleted. On the other h= and, 'mandatory' output nodes can never be obsoleted (at least not without = a deprecation policy), as doing so may break interoperability with existing= clients. For inputs, like RPC and Configuration, though I agree that mandatory nodes= can be deprecated, I don't believe that deprecated nodes can ever be obsol= eted (at least not without an expiration policy), as doing so may break int= eroperability with existing clients. >> 2. missing clarification that removing a "mandatory" statement is only a= llow >> for inputs (RPCs and config) > > I think you are right that this is a bug in the spec. Great! - so do we start 6070bis? >> 3. missing clarifying statement that clients must skip over unrecognized >> elements in a response > > I don't think we can mandate that a client MUST skip over unrecognized > elements. Maybe SHOULD. But this would be a clarification; it more > or less follows from the text that a client should do this. Being > explicit is of course good. Yes, an explicit statement would be a very good as YANG's versioning strate= gy depends on it... >> 4. no expiration policy (or are implementations to be forever backwards >> compatible?) > > If your product implements an RFC with an obsolete object, you are > "allowed" to removed the object from your implemenation. Your > customers may not like it though, but then it's a business decision if > you remove the object anyway :) OK, there may be scenarios where it comes to that, but I'm talking about th= e much more benign cases: 1. obsoleting inputs long since deprecated. This would allow the server = to remove the legacy code needed to support the deprecated node 2. obsoleting a 'mandatory' output. This would allow the server to remov= e some special code it may have implemented just to generate a required value In both these cases, clients can be gracefully migrated off time presumably= supported input or output via a temporal policy (i.e. a 1-year grace perio= d). Case in point, given the choice between breaking clients and having to= bend over backwards for a finite amount of time, Juniper will likely bend = over every time. We simply cannot afford to break interoperability with cl= ients, and yet we don't want to have cruft in our code forever either. An = "expiration strategy" for deprecated inputs and an "deprecation strategy" f= or mandatory outputs would be very welcomed enhancement to YANG's versionin= g strategy. Thanks, Kent From biermana@Brocade.com Wed Jan 12 16:42:51 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFCD3A67D9 for ; Wed, 12 Jan 2011 16:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65NtB8OSfGIc for ; Wed, 12 Jan 2011 16:42:51 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id F0EF43A65A6 for ; Wed, 12 Jan 2011 16:42:50 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0D0Ufh5020496; Wed, 12 Jan 2011 16:45:12 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id tsm37046x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Jan 2011 16:45:12 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 Jan 2011 16:51:18 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 12 Jan 2011 16:45:11 -0800 From: Andy Bierman To: Kent Watsen , Martin Bjorklund Date: Wed, 12 Jan 2011 16:45:10 -0800 Thread-Topic: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) Thread-Index: Acuub8o9rHt5iGbHRUub4TlVyTEMKgEOD0qgAASx/PA= Message-ID: References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-12_08:2011-01-12, 2011-01-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101120169 Cc: "netmod@ietf.org" Subject: Re: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Jan 2011 00:42:51 -0000 Hi, I have a problem with changing 6020 to say a client MUST do X Y Z with the = reply. There are no requirements at all on data 'exiting the protocol'. Since the client does not have to use the reply to do more NETCONF protocol interactions, there is nothing for the standard to say about what the client does with an . Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Kent Watsen Sent: Wednesday, January 12, 2011 3:13 PM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] backwards compatibility (was: how to know which modul= e revision an RPC is for?) Martin writes: > > 1. unclear how "obsolete" status can ever be used (as to do so would br= eak > backwards compatibility) >=20 > I agree with Juergen and Andy. A robust client that sees a new > revision it does not understand will have to be prepared that some > nodes are obsolete and thus not implemented on the server. >=20 > This is of course something that has to be taken into account when > obsoleting an object. We have to treat inputs and outputs separately. For outputs, like RPC-Reply or Notifications, I agree that a client needs t= o be prepared that a 'non-mandatory' node may be obsoleted. On the other h= and, 'mandatory' output nodes can never be obsoleted (at least not without = a deprecation policy), as doing so may break interoperability with existing= clients. For inputs, like RPC and Configuration, though I agree that mandatory nodes= can be deprecated, I don't believe that deprecated nodes can ever be obsol= eted (at least not without an expiration policy), as doing so may break int= eroperability with existing clients. >> 2. missing clarification that removing a "mandatory" statement is only a= llow >> for inputs (RPCs and config) > > I think you are right that this is a bug in the spec. Great! - so do we start 6070bis? >> 3. missing clarifying statement that clients must skip over unrecognized >> elements in a response > > I don't think we can mandate that a client MUST skip over unrecognized > elements. Maybe SHOULD. But this would be a clarification; it more > or less follows from the text that a client should do this. Being > explicit is of course good. Yes, an explicit statement would be a very good as YANG's versioning strate= gy depends on it... >> 4. no expiration policy (or are implementations to be forever backwards >> compatible?) > > If your product implements an RFC with an obsolete object, you are > "allowed" to removed the object from your implemenation. Your > customers may not like it though, but then it's a business decision if > you remove the object anyway :) OK, there may be scenarios where it comes to that, but I'm talking about th= e much more benign cases: 1. obsoleting inputs long since deprecated. This would allow the server = to remove the legacy code needed to support the deprecated node 2. obsoleting a 'mandatory' output. This would allow the server to remov= e some special code it may have implemented just to generate a required value In both these cases, clients can be gracefully migrated off time presumably= supported input or output via a temporal policy (i.e. a 1-year grace perio= d). Case in point, given the choice between breaking clients and having to= bend over backwards for a finite amount of time, Juniper will likely bend = over every time. We simply cannot afford to break interoperability with cl= ients, and yet we don't want to have cruft in our code forever either. An = "expiration strategy" for deprecated inputs and an "deprecation strategy" f= or mandatory outputs would be very welcomed enhancement to YANG's versionin= g strategy. Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From kwatsen@juniper.net Wed Jan 12 16:55:30 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C667A3A686E for ; Wed, 12 Jan 2011 16:55:30 -0800 (PST) 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 y7Qma4xD9rFG for ; Wed, 12 Jan 2011 16:55:29 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 486243A680A for ; Wed, 12 Jan 2011 16:55:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTS5OB28ineSugfbN7fLCWKb9zgHjVGIO@postini.com; Wed, 12 Jan 2011 16:57:46 PST 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; Wed, 12 Jan 2011 16:55:52 -0800 From: Kent Watsen To: Andy Bierman , Martin Bjorklund Date: Wed, 12 Jan 2011 16:55:47 -0800 Thread-Topic: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) Thread-Index: Acuub8o9rHt5iGbHRUub4TlVyTEMKgEOD0qgAASx/PAAAEwAwA== Message-ID: <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> In-Reply-To: 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] backwards compatibility (was: how to know which module revision an RPC is for?) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Jan 2011 00:55:30 -0000 Is this response to #3 or #4? If #3, it's OK if it's a SHOULD, as Martin = suggested. If #4 then it looks like 6020 has painted itself into a corner.= .. -----Original Message----- From: Andy Bierman [mailto:biermana@Brocade.com]=20 Sent: Wednesday, January 12, 2011 7:45 PM To: Kent Watsen; Martin Bjorklund Cc: netmod@ietf.org Subject: RE: [netmod] backwards compatibility (was: how to know which modul= e revision an RPC is for?) Hi, I have a problem with changing 6020 to say a client MUST do X Y Z with the = reply. There are no requirements at all on data 'exiting the protocol'. Since the client does not have to use the reply to do more NETCONF protocol interactions, there is nothing for the standard to say about what the client does with an . Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Kent Watsen Sent: Wednesday, January 12, 2011 3:13 PM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] backwards compatibility (was: how to know which modul= e revision an RPC is for?) Martin writes: > > 1. unclear how "obsolete" status can ever be used (as to do so would br= eak > backwards compatibility) >=20 > I agree with Juergen and Andy. A robust client that sees a new > revision it does not understand will have to be prepared that some > nodes are obsolete and thus not implemented on the server. >=20 > This is of course something that has to be taken into account when > obsoleting an object. We have to treat inputs and outputs separately. For outputs, like RPC-Reply or Notifications, I agree that a client needs t= o be prepared that a 'non-mandatory' node may be obsoleted. On the other h= and, 'mandatory' output nodes can never be obsoleted (at least not without = a deprecation policy), as doing so may break interoperability with existing= clients. For inputs, like RPC and Configuration, though I agree that mandatory nodes= can be deprecated, I don't believe that deprecated nodes can ever be obsol= eted (at least not without an expiration policy), as doing so may break int= eroperability with existing clients. >> 2. missing clarification that removing a "mandatory" statement is only a= llow >> for inputs (RPCs and config) > > I think you are right that this is a bug in the spec. Great! - so do we start 6020bis? >> 3. missing clarifying statement that clients must skip over unrecognized >> elements in a response > > I don't think we can mandate that a client MUST skip over unrecognized > elements. Maybe SHOULD. But this would be a clarification; it more > or less follows from the text that a client should do this. Being > explicit is of course good. Yes, an explicit statement would be a very good as YANG's versioning strate= gy depends on it... >> 4. no expiration policy (or are implementations to be forever backwards >> compatible?) > > If your product implements an RFC with an obsolete object, you are > "allowed" to removed the object from your implemenation. Your > customers may not like it though, but then it's a business decision if > you remove the object anyway :) OK, there may be scenarios where it comes to that, but I'm talking about th= e much more benign cases: 1. obsoleting inputs long since deprecated. This would allow the server = to remove the legacy code needed to support the deprecated node 2. obsoleting a 'mandatory' output. This would allow the server to remov= e some special code it may have implemented just to generate a required value In both these cases, clients can be gracefully migrated off time presumably= supported input or output via a temporal policy (i.e. a 1-year grace perio= d). Case in point, given the choice between breaking clients and having to= bend over backwards for a finite amount of time, Juniper will likely bend = over every time. We simply cannot afford to break interoperability with cl= ients, and yet we don't want to have cruft in our code forever either. An = "expiration strategy" for deprecated inputs and an "deprecation strategy" f= or mandatory outputs would be very welcomed enhancement to YANG's versionin= g strategy. Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From biermana@Brocade.com Wed Jan 12 17:11:11 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66443A67EE for ; Wed, 12 Jan 2011 17:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ydNqZUD3tXO for ; Wed, 12 Jan 2011 17:11:09 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 000C53A67A4 for ; Wed, 12 Jan 2011 17:11:08 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0D1DRf1021512; Wed, 12 Jan 2011 17:13:29 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id tsqht8002-6 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Jan 2011 17:13:29 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 Jan 2011 17:19:26 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 12 Jan 2011 17:13:14 -0800 From: Andy Bierman To: Kent Watsen , Martin Bjorklund Date: Wed, 12 Jan 2011 17:13:13 -0800 Thread-Topic: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) Thread-Index: Acuub8o9rHt5iGbHRUub4TlVyTEMKgEOD0qgAASx/PAAAEwAwAAAR2Bg Message-ID: References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-13_01:2011-01-12, 2011-01-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101120176 Cc: "netmod@ietf.org" Subject: Re: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Jan 2011 01:11:12 -0000 Hi, It is for #3. Per #4: One might ask if we have any obsolete SNMP objects (standard or proprietary) and if so, how did it work out? I see ipForwardTable in RFC 4292 is obsolete. It seems reasonable to me to have IETF guidelines that an object must be at status 'deprecated' for a year or 2 before it can move to 'obsol= ete'. I don't think different policies for different types of objects is needed. If you don't have the current schema, there might be nodes of any type changed to obsolete since the version you know about. This is OK. You cannot apply your contract for last year's model to this year's model. You need to read the new contract. Andy -----Original Message----- From: Kent Watsen [mailto:kwatsen@juniper.net]=20 Sent: Wednesday, January 12, 2011 4:56 PM To: Andy Bierman; Martin Bjorklund Cc: netmod@ietf.org Subject: RE: [netmod] backwards compatibility (was: how to know which modul= e revision an RPC is for?) Is this response to #3 or #4? If #3, it's OK if it's a SHOULD, as Martin = suggested. If #4 then it looks like 6020 has painted itself into a corner.= .. -----Original Message----- From: Andy Bierman [mailto:biermana@Brocade.com]=20 Sent: Wednesday, January 12, 2011 7:45 PM To: Kent Watsen; Martin Bjorklund Cc: netmod@ietf.org Subject: RE: [netmod] backwards compatibility (was: how to know which modul= e revision an RPC is for?) Hi, I have a problem with changing 6020 to say a client MUST do X Y Z with the = reply. There are no requirements at all on data 'exiting the protocol'. Since the client does not have to use the reply to do more NETCONF protocol interactions, there is nothing for the standard to say about what the client does with an . Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Kent Watsen Sent: Wednesday, January 12, 2011 3:13 PM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] backwards compatibility (was: how to know which modul= e revision an RPC is for?) Martin writes: > > 1. unclear how "obsolete" status can ever be used (as to do so would br= eak > backwards compatibility) >=20 > I agree with Juergen and Andy. A robust client that sees a new > revision it does not understand will have to be prepared that some > nodes are obsolete and thus not implemented on the server. >=20 > This is of course something that has to be taken into account when > obsoleting an object. We have to treat inputs and outputs separately. For outputs, like RPC-Reply or Notifications, I agree that a client needs t= o be prepared that a 'non-mandatory' node may be obsoleted. On the other h= and, 'mandatory' output nodes can never be obsoleted (at least not without = a deprecation policy), as doing so may break interoperability with existing= clients. For inputs, like RPC and Configuration, though I agree that mandatory nodes= can be deprecated, I don't believe that deprecated nodes can ever be obsol= eted (at least not without an expiration policy), as doing so may break int= eroperability with existing clients. >> 2. missing clarification that removing a "mandatory" statement is only a= llow >> for inputs (RPCs and config) > > I think you are right that this is a bug in the spec. Great! - so do we start 6020bis? >> 3. missing clarifying statement that clients must skip over unrecognized >> elements in a response > > I don't think we can mandate that a client MUST skip over unrecognized > elements. Maybe SHOULD. But this would be a clarification; it more > or less follows from the text that a client should do this. Being > explicit is of course good. Yes, an explicit statement would be a very good as YANG's versioning strate= gy depends on it... >> 4. no expiration policy (or are implementations to be forever backwards >> compatible?) > > If your product implements an RFC with an obsolete object, you are > "allowed" to removed the object from your implemenation. Your > customers may not like it though, but then it's a business decision if > you remove the object anyway :) OK, there may be scenarios where it comes to that, but I'm talking about th= e much more benign cases: 1. obsoleting inputs long since deprecated. This would allow the server = to remove the legacy code needed to support the deprecated node 2. obsoleting a 'mandatory' output. This would allow the server to remov= e some special code it may have implemented just to generate a required value In both these cases, clients can be gracefully migrated off time presumably= supported input or output via a temporal policy (i.e. a 1-year grace perio= d). Case in point, given the choice between breaking clients and having to= bend over backwards for a finite amount of time, Juniper will likely bend = over every time. We simply cannot afford to break interoperability with cl= ients, and yet we don't want to have cruft in our code forever either. An = "expiration strategy" for deprecated inputs and an "deprecation strategy" f= or mandatory outputs would be very welcomed enhancement to YANG's versionin= g strategy. Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu Jan 13 00:05:16 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D293A6ABC for ; Thu, 13 Jan 2011 00:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.114 X-Spam-Level: X-Spam-Status: No, score=-103.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8qlJGpUU0Sw for ; Thu, 13 Jan 2011 00:05:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C00203A6AB3 for ; Thu, 13 Jan 2011 00:05:15 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43484C001D; Thu, 13 Jan 2011 09:07:37 +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 sgWAViPfG9V2; Thu, 13 Jan 2011 09:07:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31E76C0018; Thu, 13 Jan 2011 09:07:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7D5A0161B147; Thu, 13 Jan 2011 09:07:35 +0100 (CET) Date: Thu, 13 Jan 2011 09:07:35 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20110113080735.GA6029@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] backwards compatibility (was: how to know which module revision an RPC is for?) 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, 13 Jan 2011 08:05:16 -0000 On Wed, Jan 12, 2011 at 05:13:13PM -0800, Andy Bierman wrote: > It seems reasonable to me to have IETF guidelines that an object > must be at status 'deprecated' for a year or 2 before it can move to > 'obsolete'. Most RFCs spin very slowly and I would first of all trust the WGs responsible for them that they know best when it is appropriate to obsolete a definition. I think we should only add more rules if we have evidence that there is a problem to be fixed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Thu Jan 13 06:29:17 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39A928C0F9 for ; Thu, 13 Jan 2011 06:29:17 -0800 (PST) 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 IAWldQzTw1d4 for ; Thu, 13 Jan 2011 06:29:16 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id AFCEE28C0F8 for ; Thu, 13 Jan 2011 06:29:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTS8Mxc5vwJa9zNcb1iU7/RPUj62f5yXM@postini.com; Thu, 13 Jan 2011 06:31:39 PST 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; Thu, 13 Jan 2011 06:29:11 -0800 From: Kent Watsen To: Juergen Schoenwaelder , Andy Bierman Date: Thu, 13 Jan 2011 06:29:08 -0800 Thread-Topic: [netmod] backwards compatibility Thread-Index: Acuy+L7pJUb9LEENT1y36iyqepxvlgALxcjw Message-ID: <84600D05C20FF943918238042D7670FD37466F7ED3@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.net> <20110113080735.GA6029@elstar.local> In-Reply-To: <20110113080735.GA6029@elstar.local> 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] backwards compatibility X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Jan 2011 14:29:17 -0000 > Most RFCs spin very slowly and I would first of all trust the WGs > responsible for them that they know best when it is appropriate to > obsolete a definition. I think we should only add more rules if we > have evidence that there is a problem to be fixed. This isn't just about IETF-defined modules; YANG is used to define 3rd-part= ies data-models as well If we don't want to provide an ability to deprecate a 'mandatory' output el= ement, then perhaps we should disallow any output value from being marked '= mandatory' in the first place - at least then servers can deprecate them wi= th impunity. BTW, my other point, that deprecated input values can never being obsoleted= , equally applies to IETF-defined modules. But let's be clear, this isn't = about being able to deprecate input elements, this is about vendors not bei= ng able to safely remove the support for deprecated input elements - see th= e distinction? Thanks, Kent From j.schoenwaelder@jacobs-university.de Thu Jan 13 06:58:02 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0088C28C0E3 for ; Thu, 13 Jan 2011 06:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PZCuOXzCHsK for ; Thu, 13 Jan 2011 06:58:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C95E53A6B9A for ; Thu, 13 Jan 2011 06:58:00 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB036C0018; Thu, 13 Jan 2011 16:00:21 +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 8u29eTNHmycU; Thu, 13 Jan 2011 16:00:20 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84D2CC0003; Thu, 13 Jan 2011 16:00:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 288E5161C506; Thu, 13 Jan 2011 16:00:20 +0100 (CET) Date: Thu, 13 Jan 2011 16:00:20 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110113150019.GA8193@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.net> <20110113080735.GA6029@elstar.local> <84600D05C20FF943918238042D7670FD37466F7ED3@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD37466F7ED3@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andy Bierman , "netmod@ietf.org" Subject: Re: [netmod] backwards compatibility 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, 13 Jan 2011 14:58:02 -0000 On Thu, Jan 13, 2011 at 06:29:08AM -0800, Kent Watsen wrote: > > > Most RFCs spin very slowly and I would first of all trust the WGs > > responsible for them that they know best when it is appropriate to > > obsolete a definition. I think we should only add more rules if we > > have evidence that there is a problem to be fixed. > > This isn't just about IETF-defined modules; YANG is used to define 3rd-parties data-models as well I do not think the IETF can effectively define rules how other organizations deprecate or obsolete definitions. [...] > BTW, my other point, that deprecated input values can never being > obsoleted, equally applies to IETF-defined modules. But let's be > clear, this isn't about being able to deprecate input elements, this > is about vendors not being able to safely remove the support for > deprecated input elements - see the distinction? I believe there are big differences in deployment scenarios. In some environments, software gets regularly updated, in other environments this happens much less frequently or in some only when boxes are replaced. Is it realistic to find concensus on a universal time span that works well for all YANG modules in all possible deployments? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Jan 13 12:38:08 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E2C3A6A6D for ; Thu, 13 Jan 2011 12:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi4q0VwPBBeN for ; Thu, 13 Jan 2011 12:38:07 -0800 (PST) Received: from smtp103.sbc.mail.ac4.yahoo.com (smtp103.sbc.mail.ac4.yahoo.com [76.13.13.242]) by core3.amsl.com (Postfix) with SMTP id 11DC83A6A85 for ; Thu, 13 Jan 2011 12:38:06 -0800 (PST) Received: (qmail 91651 invoked from network); 13 Jan 2011 20:40:20 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.ac4.yahoo.com with SMTP; 13 Jan 2011 12:40:17 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: oSXO2pAVM1nUNBBDsuSX1Sc4Sg62jIabzeWVez46DWBRMxv vkHtK6YjhiR7E04RUI.8AZ2YhdGGC_1jnailqoPjr39GTCaaX9So71io0fxH Pmy_bBFnFL5X2AOTajxYhQWFrV7YskSBUBMyFfB5S8exGwi6wP7Eh8B4bX22 M5Mv7ez4Obb.qN27JIbzRb1CXfPTHeTEwe0EtSIJVCMUvnAbLiXVwVpyI1OD VbSu1xL3EEt0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D2F6339.4040600@andybierman.com> Date: Thu, 13 Jan 2011 12:40:25 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> <20110107.143657.194513514.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD37465B9247@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD37465B93CB@EMBX01-HQ.jnpr.net> <20110113080735.GA6029@elstar.local> <84600D05C20FF943918238042D7670FD37466F7ED3@EMBX01-HQ.jnpr.net> <20110113150019.GA8193@elstar.local> In-Reply-To: <20110113150019.GA8193@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] backwards compatibility X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Jan 2011 20:38:08 -0000 On 01/13/2011 07:00 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 13, 2011 at 06:29:08AM -0800, Kent Watsen wrote: >> Juergen is right. IMO, the WG has already addressed this problem with (implemented in yuma, BTW). The old contract does not apply to servers which do not claim to support that version of the contract. Period. Get the new contract and check if the old features you need are still in it. IETF objects will follow strict rules. It may be easy to obsolete something if there are few implementations. It will have to be on a case-by-case basis, like MIB objects. Andy >>> Most RFCs spin very slowly and I would first of all trust the WGs >>> responsible for them that they know best when it is appropriate to >>> obsolete a definition. I think we should only add more rules if we >>> have evidence that there is a problem to be fixed. >> >> This isn't just about IETF-defined modules; YANG is used to define 3rd-parties data-models as well > > I do not think the IETF can effectively define rules how other > organizations deprecate or obsolete definitions. > > [...] > >> BTW, my other point, that deprecated input values can never being >> obsoleted, equally applies to IETF-defined modules. But let's be >> clear, this isn't about being able to deprecate input elements, this >> is about vendors not being able to safely remove the support for >> deprecated input elements - see the distinction? > > I believe there are big differences in deployment scenarios. In some > environments, software gets regularly updated, in other environments > this happens much less frequently or in some only when boxes are > replaced. Is it realistic to find concensus on a universal time span > that works well for all YANG modules in all possible deployments? > > /js > From biermana@Brocade.com Thu Jan 20 09:16:53 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5211A3A7037 for ; Thu, 20 Jan 2011 09:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 GKGSHxZUUIJU for ; Thu, 20 Jan 2011 09:16:49 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 9A0F73A6FDE for ; Thu, 20 Jan 2011 09:16:49 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0KHDsPW011443 for ; Thu, 20 Jan 2011 09:19:33 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id txnuv04dt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Jan 2011 09:19:32 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Jan 2011 09:21:10 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 20 Jan 2011 09:19:32 -0800 From: Andy Bierman To: "netmod@ietf.org" Date: Thu, 20 Jan 2011 09:19:31 -0800 Thread-Topic: Q about config-stmt processing Thread-Index: Acu4xjMqOlZugsycRDW09kKyuufaKw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B11AB91666F22D498EEC66410EB3D3C4F41671D51AHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-20_06:2011-01-20, 2011-01-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101200078 Subject: [netmod] Q about config-stmt processing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:16:53 -0000 --_000_B11AB91666F22D498EEC66410EB3D3C4F41671D51AHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have run into a YANG compiler difference between pyang and yangdump, and I want the WG to decide which is right. >From RFC 6020, sec 7.19.1: If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node. If the top node does not specify a "config" statement, the default is "true". YANG example: grouping A { leaf a { type string; } } container foo { config false; uses A; } augment /foo { leaf b { type string; } } In this example, yangdump says it is legal and pyang says it is not because= /foo/b is a config=3Dtrue node. Is /foo/b a config=3Dtrue or a config=3Dfalse no= de? We need all conforming YANG compilers to agree on the answer. The issue is the meaning of 'parent schema node' for a node within a top-le= vel augment-stmt. Is that node a top-level node? IMO - no, because augment is specifying the= parent schema node for the contents of the augments. Also, an inline leaf or a leaf via 'uses= ' should behave the same way for the config-stmt property. (/foo/a is clearly config=3Dfalse node) Andy --_000_B11AB91666F22D498EEC66410EB3D3C4F41671D51AHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have run= into a YANG compiler difference between pyang and yangdump,
and I want = the WG to decide which is right.

&n= bsp;

From RFC 6020, sec 7.19.1:

 

  If "confi= g" is not specified, the default is the same as the parent<= /span>

   schema node's "config" value.  I= f the parent node is a "case" node,

&nb= sp;  the value is the same as the "case" node's parent "= ;choice" node.

 

   If the top node does not specify a "config" st= atement, the default is

   "true&q= uot;.

 

 = ;

YANG example:

 <= /o:p>

 

    gr= ouping A {

       l= eaf a { type string; }

    }<= /o:p>

 

    co= ntainer foo {

      conf= ig false;

      uses A;<= o:p>

    }

 

    augment /foo {=

      leaf b { type string; }=

    }

&= nbsp;

In this example, yangdump says i= t is legal and pyang says it is not because /foo/b
is a config=3Dtrue no= de.   Is /foo/b a config=3Dtrue or a config=3Dfalse node?
We n= eed all conforming YANG compilers to agree on the answer.

 

The issue is th= e meaning of ‘parent schema node’ for a node within a top-level= augment-stmt.

Is that node a top-level = node?  IMO – no, because augment is specifying the parent schema= node
for the contents of the augments.  Also, an inline leaf or a = leaf via ‘uses’ should behave the same
way for the config-st= mt property. (/foo/a is clearly config=3Dfalse node)

 

 

Andy

 

 

= --_000_B11AB91666F22D498EEC66410EB3D3C4F41671D51AHQ1EXCH01corp_-- From lhotka@cesnet.cz Thu Jan 20 09:34:36 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491C03A714C for ; Thu, 20 Jan 2011 09:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-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 fOEdnJTxxzKd for ; Thu, 20 Jan 2011 09:34:35 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 1B4563A7138 for ; Thu, 20 Jan 2011 09:34:35 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 1CA162CDE05B for ; Thu, 20 Jan 2011 18:37:17 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 20 Jan 2011 18:37:15 +0100 Message-ID: <1295545035.1647.46.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Q about config-stmt processing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:34:36 -0000 On Čt, 2011-01-20 at 09:19 -0800, Andy Bierman wrote: > Hi, > > > > I have run into a YANG compiler difference between pyang and yangdump, > and I want the WG to decide which is right. > > > > From RFC 6020, sec 7.19.1: > > > > If "config" is not specified, the default is the same as the parent > > schema node's "config" value. If the parent node is a "case" node, > > the value is the same as the "case" node's parent "choice" node. > > > > If the top node does not specify a "config" statement, the default > is > > "true". > > > > > > YANG example: > > > > > > grouping A { > > leaf a { type string; } > > } > > > > container foo { > > config false; > > uses A; > > } > > > > augment /foo { > > leaf b { type string; } > > } > > > > In this example, yangdump says it is legal and pyang says it is not > because /foo/b > is a config=true node. Is /foo/b a config=true or a config=false > node? > We need all conforming YANG compilers to agree on the answer. IMO yangdump is correct here. Container "foo" should be considered the schema tree parent for both leafs "a" and "b". Lada > > > > The issue is the meaning of ‘parent schema node’ for a node within a > top-level augment-stmt. > > Is that node a top-level node? IMO – no, because augment is > specifying the parent schema node > for the contents of the augments. Also, an inline leaf or a leaf via > ‘uses’ should behave the same > way for the config-stmt property. (/foo/a is clearly config=false > node) > > > > > > Andy > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From wwwrun@rfc-editor.org Mon Jan 24 17:31:46 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AB23A6B49; Mon, 24 Jan 2011 17:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6QN+5piwMho; Mon, 24 Jan 2011 17:31:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 77F7D3A6B46; Mon, 24 Jan 2011 17:31:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E7DC7E0744; Mon, 24 Jan 2011 17:34:41 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110125013441.E7DC7E0744@rfc-editor.org> Date: Mon, 24 Jan 2011 17:34:41 -0800 (PST) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] RFC 6087 on Guidelines for Authors and Reviewers of YANG Data Model Documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Jan 2011 01:31:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6087 Title: Guidelines for Authors and Reviewers of YANG Data Model Documents Author: A. Bierman Status: Informational Stream: IETF Date: January 2011 Mailbox: andy.bierman@brocade.com Pages: 26 Characters: 49969 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-yang-usage-11.txt URL: http://www.rfc-editor.org/rfc/rfc6087.txt 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 Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dromasca@avaya.com Tue Jan 25 01:23:58 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF4D3A6A7A for ; Tue, 25 Jan 2011 01:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5F6k-WU4XDF for ; Tue, 25 Jan 2011 01:23:57 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 4182A3A63CB for ; Tue, 25 Jan 2011 01:23:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAPclPk3GmAcF/2dsb2JhbACWVY4ec6NIApkYhU8EkAk X-IronPort-AV: E=Sophos;i="4.60,373,1291611600"; d="scan'208";a="261303589" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jan 2011 04:26:53 -0500 X-IronPort-AV: E=Sophos;i="4.60,373,1291611600"; d="scan'208";a="574477509" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2011 04:26:53 -0500 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, 25 Jan 2011 10:26:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] RFC 6087 on Guidelines for Authors and Reviewers of YANGData Model Documents Thread-Index: Acu8MBKuqHumRNpwSFyoPwQnDVQNWQAQbaew From: "Romascanu, Dan (Dan)" To: Subject: [netmod] FW: RFC 6087 on Guidelines for Authors and Reviewers of YANGData Model Documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Jan 2011 09:23:58 -0000 Special thanks to Andy for writing and pushing this work ahead, and thanks and congratulations to the whole WG for contributing to this work.=20 Regards, Dan -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Tuesday, January 25, 2011 3:35 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: netmod@ietf.org; rfc-editor@rfc-editor.org Subject: [netmod] RFC 6087 on Guidelines for Authors and Reviewers of YANGData Model Documents A new Request for Comments is now available in online RFC libraries. =20 RFC 6087 Title: Guidelines for Authors and Reviewers=20 of YANG Data Model Documents=20 Author: A. Bierman Status: Informational Stream: IETF Date: January 2011 Mailbox: andy.bierman@brocade.com Pages: 26 Characters: 49969 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-yang-usage-11.txt URL: http://www.rfc-editor.org/rfc/rfc6087.txt 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 Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Tue Jan 25 02:33:21 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E103A6A59 for ; Tue, 25 Jan 2011 02:33:21 -0800 (PST) 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.550, 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 asDQDswPqp6p for ; Tue, 25 Jan 2011 02:33:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 63E343A6838 for ; Tue, 25 Jan 2011 02:33:19 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5158C616001; Tue, 25 Jan 2011 11:36:15 +0100 (CET) Date: Tue, 25 Jan 2011 11:36:12 +0100 (CET) Message-Id: <20110125.113612.171769114.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1295545035.1647.46.camel@behold> References: <1295545035.1647.46.camel@behold> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] Q about config-stmt processing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:33:21 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gT24gxIx0LCAyMDEx LTAxLTIwIGF0IDA5OjE5IC0wODAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4gSGksDQo+ID4g DQo+ID4gIA0KPiA+IA0KPiA+IEkgaGF2ZSBydW4gaW50byBhIFlBTkcgY29tcGlsZXIgZGlmZmVy ZW5jZSBiZXR3ZWVuIHB5YW5nIGFuZCB5YW5nZHVtcCwNCj4gPiBhbmQgSSB3YW50IHRoZSBXRyB0 byBkZWNpZGUgd2hpY2ggaXMgcmlnaHQuDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IEZyb20gUkZD IDYwMjAsIHNlYyA3LjE5LjE6DQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+ICAgSWYgImNvbmZpZyIg aXMgbm90IHNwZWNpZmllZCwgdGhlIGRlZmF1bHQgaXMgdGhlIHNhbWUgYXMgdGhlIHBhcmVudA0K PiA+IA0KPiA+ICAgIHNjaGVtYSBub2RlJ3MgImNvbmZpZyIgdmFsdWUuICBJZiB0aGUgcGFyZW50 IG5vZGUgaXMgYSAiY2FzZSIgbm9kZSwNCj4gPiANCj4gPiAgICB0aGUgdmFsdWUgaXMgdGhlIHNh bWUgYXMgdGhlICJjYXNlIiBub2RlJ3MgcGFyZW50ICJjaG9pY2UiIG5vZGUuDQo+ID4gDQo+ID4g IA0KPiA+IA0KPiA+ICAgIElmIHRoZSB0b3Agbm9kZSBkb2VzIG5vdCBzcGVjaWZ5IGEgImNvbmZp ZyIgc3RhdGVtZW50LCB0aGUgZGVmYXVsdA0KPiA+IGlzDQo+ID4gDQo+ID4gICAgInRydWUiLg0K PiA+IA0KPiA+ICANCj4gPiANCj4gPiAgDQo+ID4gDQo+ID4gWUFORyBleGFtcGxlOg0KPiA+IA0K PiA+ICANCj4gPiANCj4gPiAgDQo+ID4gDQo+ID4gICAgIGdyb3VwaW5nIEEgew0KPiA+IA0KPiA+ ICAgICAgICBsZWFmIGEgeyB0eXBlIHN0cmluZzsgfQ0KPiA+IA0KPiA+ICAgICB9DQo+ID4gDQo+ ID4gIA0KPiA+IA0KPiA+ICAgICBjb250YWluZXIgZm9vIHsNCj4gPiANCj4gPiAgICAgICBjb25m aWcgZmFsc2U7DQo+ID4gDQo+ID4gICAgICAgdXNlcyBBOw0KPiA+IA0KPiA+ICAgICB9DQo+ID4g DQo+ID4gIA0KPiA+IA0KPiA+ICAgICBhdWdtZW50IC9mb28gew0KPiA+IA0KPiA+ICAgICAgIGxl YWYgYiB7IHR5cGUgc3RyaW5nOyB9DQo+ID4gDQo+ID4gICAgIH0NCj4gPiANCj4gPiAgDQo+ID4g DQo+ID4gSW4gdGhpcyBleGFtcGxlLCB5YW5nZHVtcCBzYXlzIGl0IGlzIGxlZ2FsIGFuZCBweWFu ZyBzYXlzIGl0IGlzIG5vdA0KPiA+IGJlY2F1c2UgL2Zvby9iDQo+ID4gaXMgYSBjb25maWc9dHJ1 ZSBub2RlLiAgIElzIC9mb28vYiBhIGNvbmZpZz10cnVlIG9yIGEgY29uZmlnPWZhbHNlDQo+ID4g bm9kZT8NCj4gPiBXZSBuZWVkIGFsbCBjb25mb3JtaW5nIFlBTkcgY29tcGlsZXJzIHRvIGFncmVl IG9uIHRoZSBhbnN3ZXIuDQo+IA0KPiBJTU8geWFuZ2R1bXAgaXMgY29ycmVjdCBoZXJlLiBDb250 YWluZXIgImZvbyIgc2hvdWxkIGJlIGNvbnNpZGVyZWQgdGhlDQo+IHNjaGVtYSB0cmVlIHBhcmVu dCBmb3IgYm90aCBsZWFmcyAiYSIgYW5kICJiIi4NCg0KSSBhZ3JlZSB3aXRoIGJvdGggb2YgeW91 LiAgKGFuZCBJIGhhdmUgZml4ZWQgdGhlIGJ1ZyBpbiBweWFuZyA6KQ0KDQoNCi9tYXJ0aW4NCg0K DQoNCj4gDQo+IExhZGENCj4gDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IFRoZSBpc3N1ZSBpcyB0 aGUgbWVhbmluZyBvZiDigJhwYXJlbnQgc2NoZW1hIG5vZGXigJkgZm9yIGEgbm9kZSB3aXRoaW4g YQ0KPiA+IHRvcC1sZXZlbCBhdWdtZW50LXN0bXQuDQo+ID4gDQo+ID4gSXMgdGhhdCBub2RlIGEg dG9wLWxldmVsIG5vZGU/ICBJTU8g4oCTIG5vLCBiZWNhdXNlIGF1Z21lbnQgaXMNCj4gPiBzcGVj aWZ5aW5nIHRoZSBwYXJlbnQgc2NoZW1hIG5vZGUNCj4gPiBmb3IgdGhlIGNvbnRlbnRzIG9mIHRo ZSBhdWdtZW50cy4gIEFsc28sIGFuIGlubGluZSBsZWFmIG9yIGEgbGVhZiB2aWENCj4gPiDigJh1 c2Vz4oCZIHNob3VsZCBiZWhhdmUgdGhlIHNhbWUNCj4gPiB3YXkgZm9yIHRoZSBjb25maWctc3Rt dCBwcm9wZXJ0eS4gKC9mb28vYSBpcyBjbGVhcmx5IGNvbmZpZz1mYWxzZQ0KPiA+IG5vZGUpDQo+ ID4gDQo+ID4gIA0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiBBbmR5DQo+ID4gDQo+ID4gIA0KPiA+ IA0KPiA+ICANCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K PiANCj4gLS0gDQo+IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUDQo+IFBHUCBLZXkgSUQ6IEU3NEU4 QzBDDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K