From dromasca@avaya.com Wed Feb 2 10:06:52 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B593A6DBC for ; Wed, 2 Feb 2011 10:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 flBZCFMP3lHe for ; Wed, 2 Feb 2011 10:06:51 -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 216673A6DC5 for ; Wed, 2 Feb 2011 10:06:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAMtSU3GmAcF/2dsb2JhbAClHHOidAKZAIVTBI8l X-IronPort-AV: E=Sophos;i="4.60,415,1291611600"; d="scan'208";a="262832525" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Feb 2011 13:10:10 -0500 X-IronPort-AV: E=Sophos;i="4.60,415,1291611600"; d="scan'208";a="577597122" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2011 13:10:10 -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: Wed, 2 Feb 2011 19:10:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-netconf-rfc4742bis-06.txt Thread-Index: AcvDBFeNn4+Dcj9xTh+pOTHyRhMh6w== From: "Romascanu, Dan (Dan)" To: "netconf" Subject: [Netconf] AD review of draft-ietf-netconf-rfc4742bis-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:06:52 -0000 I have reviewed draft-ietf-netconf-rfc4742bis-06.txt. Having also followed closely this work in the WG I find the document in good shape, and unless there are any objections I will send it immediately to IETF Last Call. I have only one major observation - Section 9 ' Changes Log is marked for removal. It's OK to remove the sections showing delta sections from one version to another, but a 'Changes from RFC 4742' section would be useful. Please consider this section together with the other IETF Last Call comments.=20 Regards, Dan From iesg-secretary@ietf.org Wed Feb 2 14:01:19 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F183A6E0D; Wed, 2 Feb 2011 14:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 fiYFRw9Av5Cu; Wed, 2 Feb 2011 14:01:19 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED91A3A6DF6; Wed, 2 Feb 2011 14:01:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110202220118.26822.69634.idtracker@localhost> Date: Wed, 02 Feb 2011 14:01:18 -0800 Cc: netconf@ietf.org Subject: [Netconf] Last Call: (Using the NETCONF Configuration Protocol over Secure Shell (SSH)) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:01:19 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/ No IPR declarations have been submitted directly on this I-D. From Internet-Drafts@ietf.org Thu Feb 3 06:45:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F001F3A699E; Thu, 3 Feb 2011 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 DnzWKQX6Uf+P; Thu, 3 Feb 2011 06:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200C03A699C; Thu, 3 Feb 2011 06:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110203144502.8873.90811.idtracker@localhost> Date: Thu, 03 Feb 2011 06:45:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-access-control-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol Access Control Model Author(s) : A. Bierman, M. Bjorklund Filename : draft-ietf-netconf-access-control-02.txt Pages : 53 Date : 2011-02-03 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment, which promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF operations and content. This document discusses requirements for a suitable access control model, and provides one solution which meets these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-access-control-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-03063735.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Fri Feb 4 05:51:18 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D49C3A6927 for ; Fri, 4 Feb 2011 05:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 m+w0uxNgihyu for ; Fri, 4 Feb 2011 05:51:16 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 863903A68DE for ; Fri, 4 Feb 2011 05:51:13 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PlM7P-0003lX-Nu for netconf@ietf.org; Fri, 04 Feb 2011 14:54:38 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PlM7P-0002BP-H7 for netconf@ietf.org; Fri, 04 Feb 2011 14:54:35 +0100 Message-ID: <4D4C051B.5010308@bwijnen.net> Date: Fri, 04 Feb 2011 14:54:35 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ad79d313a5b276934ff62907a8bc237f Subject: [Netconf] Fwd: tsv-dir review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 13:51:18 -0000 FYI -------- Original Message -------- Subject: tsv-dir review of draft-ietf-netconf-4741bis-07 Date: Fri, 4 Feb 2011 12:37:48 +0000 From: Rolf Winter To: tsv-dir@ietf.org , tsv-area@ietf.org , ietf@ietf.org , draft-ietf-netconf-4741bis@tools.ietf.org Hi, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This draft is basically ready for publication, but has nits that should be fixed before publication. There are no transport-related concerns that I could spot. Some nits: Section 2.1: second paragraph (below), second sentence doesn't parse quite right for me. Especially as the following sentence seems to imply the opposite. I read this as "The client can change things that cannot be changed" --> "NETCONF connections are long-lived, persisting between protocol operations. This allows the client to make changes to the state of the connection that will persist for the lifetime of the connection. For example, authentication information specified for a connection remains in effect until the connection is closed." You have "Authentication" in titles twice (in 2.2 and 2.3). Can do without in 2.2 as you dedicate a whole section on it. Section 2.2. "NETCONF connections must" is not a "MUST". Is this intentional (BTW, you don't mention integrity in the security considerations section any more). "NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol." I read this as every transport protocol that NETCONF can run over (SSH e.g.) needs to specify this, but I think this is not what you require or even can ask for. But maybe I misunderstand the sentence. Regarding this error: enum operation-failed { description "Request could not be completed because the requested operation failed for some reason not covered by any other error condition."; } This is send if the XML is not well formed. Maybe you could dedicate a message to this that makes trouble shooting a little easier such as "XML-format-error" or something. That's about it. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From bertietf@bwijnen.net Mon Feb 7 03:36:24 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A954A3A6DE4 for ; Mon, 7 Feb 2011 03:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Ttti6D0e2yif for ; Mon, 7 Feb 2011 03:36:23 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 69B913A6DD5 for ; Mon, 7 Feb 2011 03:36:21 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PmPOH-00012W-QN for netconf@ietf.org; Mon, 07 Feb 2011 12:36:23 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PmPOH-0008Ty-If for netconf@ietf.org; Mon, 07 Feb 2011 12:36:21 +0100 Message-ID: <4D4FD935.50309@bwijnen.net> Date: Mon, 07 Feb 2011 12:36:21 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fee9c4327ce196a357b7dc81826ac949 Subject: [Netconf] Fwd: Last Call: (Network Configuration Protocol (NETCONF)) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 11:36:24 -0000 Dear WG participants, IETF Last Call for this document has ended. AS far as I know, we have had 3 review comments, - one from the IANA crew. Juergen and Andy have I think sufficiently) answered that one. But I'll check and make sure that IANA is now indeed happy (or at least understands the proper actions to be taken). - One from the gen area by Brian Carpenter - One from the tsv area by Rolf Winter. The last two commenters both raised concerns about not-so-consistent use of RFC2119 language. My understanding is that 3 editors of the document are working on a revision of the draft that addresses this (plus any other comments we recieved). Hopefully we will see that soon and then be able to continue with the IESG process. Bert Wijnen Document Shepherd -------- Original Message -------- Subject: Last Call: (Network Configuration Protocol (NETCONF)) to Proposed Standard Date: Mon, 24 Jan 2011 06:57:55 -0800 From: The IESG To: IETF-Announce CC: netconf@ietf.org The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Network Configuration Protocol (NETCONF)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From bertietf@bwijnen.net Mon Feb 7 03:42:00 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F253A3A6DDA; Mon, 7 Feb 2011 03:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.938 X-Spam-Level: X-Spam-Status: No, score=-101.938 tagged_above=-999 required=5 tests=[AWL=0.661, 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 DQWlSwIStPd8; Mon, 7 Feb 2011 03:41:59 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 69B493A6C80; Mon, 7 Feb 2011 03:41:58 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PmPTh-0001kh-Ne; Mon, 07 Feb 2011 12:41:59 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PmPTh-0000M5-Jo; Mon, 07 Feb 2011 12:41:57 +0100 Message-ID: <4D4FDA85.8020508@bwijnen.net> Date: Mon, 07 Feb 2011 12:41:57 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Rolf Winter References: <791AD3077F94194BB2BDD13565B6295D8ED1FC@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D8ED1FC@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40397b40a57ea4f62d53ec1cbe48a1782 Cc: "draft-ietf-netconf-4741bis@tools.ietf.org" , "tsv-area@ietf.org" , netconf , "tsv-dir@ietf.org" Subject: Re: [Netconf] tsv-dir review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 11:42:00 -0000 Thanks for your review and comments Rolf. All comments together are being considered by the editors and possibly will result in a new revision. We'll keep you updated. Bert Wijnen Document Shepherd On 2/4/11 1:37 PM, Rolf Winter wrote: > Hi, > > I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. > > This draft is basically ready for publication, but has nits that should be fixed before publication. There are no transport-related concerns that I could spot. > > Some nits: > > Section 2.1: second paragraph (below), second sentence doesn't parse quite right for me. Especially as the following sentence seems to imply the opposite. I read this as "The client can change things that cannot be changed" > > --> "NETCONF connections are long-lived, persisting between protocol > operations. This allows the client to make changes to the state of > the connection that will persist for the lifetime of the connection. > For example, authentication information specified for a connection > remains in effect until the connection is closed." > > You have "Authentication" in titles twice (in 2.2 and 2.3). Can do without in 2.2 as you dedicate a whole section on it. > > Section 2.2. "NETCONF connections must" is not a "MUST". Is this intentional (BTW, you don't mention integrity in the security considerations section any more). > > "NETCONF transport protocols therefore MUST explain how a NETCONF username is > derived from the authentication mechanisms supported by the transport > protocol." I read this as every transport protocol that NETCONF can run over (SSH e.g.) needs to specify this, but I think this is not what you require or even can ask for. But maybe I misunderstand the sentence. > > Regarding this error: > enum operation-failed { > description > "Request could not be completed because the requested > operation failed for some reason not covered by > any other error condition."; > } > This is send if the XML is not well formed. Maybe you could dedicate a message to this that makes trouble shooting a little easier such as "XML-format-error" or something. > > That's about it. > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From bertietf@bwijnen.net Mon Feb 7 03:44:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7F83A6DE3; Mon, 7 Feb 2011 03:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.158 X-Spam-Level: X-Spam-Status: No, score=-102.158 tagged_above=-999 required=5 tests=[AWL=0.441, 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 QqsnJzxLk3Y4; Mon, 7 Feb 2011 03:44:42 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id D825A3A6C80; Mon, 7 Feb 2011 03:44:41 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PmPWO-0001mc-43; Mon, 07 Feb 2011 12:44:45 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PmPWN-0000WS-Nm; Mon, 07 Feb 2011 12:44:43 +0100 Message-ID: <4D4FDB2B.9070902@bwijnen.net> Date: Mon, 07 Feb 2011 12:44:43 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D460960.5050208@gmail.com> In-Reply-To: <4D460960.5050208@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43aace048ff2c311468651263a9ad7f7a Cc: General Area Review Team , netconf , draft-ietf-netconf-4741bis.all@tools.ietf.org Subject: Re: [Netconf] Gen-ART LC review of draft-ietf-netconf-4741bis-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 11:44:43 -0000 Brian, thanks for your review and comments All comments together are being considered by the editors and possibly will result in a new revision. We'll keep you updated. Bert Wijnen Document Shepherd On 1/31/11 1:59 AM, Brian E Carpenter wrote: > Please see attached review. draft-ietf-netconf-4741bis-07-carpenter.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netconf-4741bis-07.txt Reviewer: Brian Carpenter Review Date: 2011-01-31 IETF LC End Date: 2011-02-07 IESG Telechat date: Summary: Almost ready - review use of normative words -------- Comment: -------- This is a 121 page document with a very large amount of code included, including code explicitly marked as being normative content. I have not checked this code in any way. Minor issues ------------ I'm a little confused by some of the non-normative uses of lower case "should". For example: "1.3. Capabilities A NETCONF capability is a set of functionality that supplements the base NETCONF specification. The capability is identified by a uniform resource identifier (URI). These URIs should follow the guidelines as described in Section 8. ... "8. Capabilities This section defines a set of capabilities that a client or a server MAY implement." So if the capabalities are a formal MAY, what is that apparently non-normative "should" supposed to mean? I suggest that the sentence would be less confusing if it said: "Section 8 provides guidelines for these URIs." Another example: "Appendix D. Capability Template This non-normative section defines a template that should be used to define protocol capabilities. " If it's non-normative, how is the reader to interpret "should"? Doesn't it mean "could" or "might"? There are tens of instances of lower case "should" and I wonder how many of them are confusing in this way. Similarly: "2.3. Authentication NETCONF connections must be authenticated. " Surely that should be normative MUST? And there are lots of other lower case "must" and "may". The latter is especially confusing because in examples like this: "6.4.4. Select All Elements within the Subtree This filter contains two containment nodes (,) and one selection node (). All instances of the element in the same sibling set are selected in the filter output. The client may need to know that is used as an instance identifier..." s/may/might/ would be appropriate, but in "The filter element may optionally contain a "type" attribute." s/may optionally/MAY/ would be appropriate. The current mix of RFC 2119 terms, apparently normative lower case terms, and apparently non-normative use of "may" and "should" seems like it needs cleaning up compared to RFC4741. From kwatsen@juniper.net Mon Feb 7 08:30:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA4E3A6E1E for ; Mon, 7 Feb 2011 08:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRZlYfVtY3UP for ; Mon, 7 Feb 2011 08:30:10 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id DDEA03A6E18 for ; Mon, 7 Feb 2011 08:30:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTVAeFv7U0ZlszeFwd6pRbLY0wiLbqqJ4@postini.com; Mon, 07 Feb 2011 08:30:14 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, 7 Feb 2011 08:27:04 -0800 From: Kent Watsen To: "netconf@ietf.org" Date: Mon, 7 Feb 2011 08:27:10 -0800 Thread-Topic: a couple 4741bis lingering issues Thread-Index: AcvG495bAzmJXY93Q12TuKMPcAmFRA== Message-ID: <84600D05C20FF943918238042D7670FD3751C759B9@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 Subject: [Netconf] a couple 4741bis lingering issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:30:11 -0000 I'm not sure if it's too late to bring this up, but I was reviewing the mai= ling list archive and realized that two issues didn't seem to reach closure= : 1. before This issue was first raised by Martin over a year ago and then again by me= (though I messed up and wrote comes *after* when I meant *before*): http://www.ietf.org/mail-archive/web/netconf/current/msg03876.html http://www.ietf.org/mail-archive/web/netconf/current/msg06072.html Both times the thread peters out and yet the issue remains in 4741bis-07. = Shouldn't the spec provide guidance on how to handle an error after = has started to stream? 2. Namespace passing This issue is much more recent, but I'm not sure if a consensus to not chan= ge the current text was reached. Andy last posted about a rare corner-case= , but does that mean we stick with the status quo though many said that imp= lementations were unlikely to support it? http://www.ietf.org/mail-archive/web/netconf/current/msg06709.html Thanks, Kent From kwatsen@juniper.net Mon Feb 7 09:12:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FDC3A6E32 for ; Mon, 7 Feb 2011 09:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4di4fySeZMKx for ; Mon, 7 Feb 2011 09:12:00 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 8C8D23A6E2E for ; Mon, 7 Feb 2011 09:12:00 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTVAn5JV+k5Dzm708B5/h2p5toZKzW7Uh@postini.com; Mon, 07 Feb 2011 09:12:05 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 7 Feb 2011 09:05:27 -0800 From: Kent Watsen To: "netconf@ietf.org" Date: Mon, 7 Feb 2011 09:05:32 -0800 Thread-Topic: a couple 4741bis lingering issues Thread-Index: AcvG495bAzmJXY93Q12TuKMPcAmFRAABKyvw Message-ID: <84600D05C20FF943918238042D7670FD3751C75A1C@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3751C759B9@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3751C759B9@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 Subject: Re: [Netconf] a couple 4741bis lingering issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:12:02 -0000 For the first issue, could we define: =20 This schema validates previous responses while also allowing to= show up after . Seems that this would not break backwards compatibi= lity, since both peers would need to advertize base:1.1 for it to be used. Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Monday, February 07, 2011 11:27 AM To: netconf@ietf.org Subject: [Netconf] a couple 4741bis lingering issues I'm not sure if it's too late to bring this up, but I was reviewing the mai= ling list archive and realized that two issues didn't seem to reach closure= : 1. before This issue was first raised by Martin over a year ago and then again by me= (though I messed up and wrote comes *after* when I meant *before*): http://www.ietf.org/mail-archive/web/netconf/current/msg03876.html http://www.ietf.org/mail-archive/web/netconf/current/msg06072.html Both times the thread peters out and yet the issue remains in 4741bis-07. = Shouldn't the spec provide guidance on how to handle an error after = has started to stream? 2. Namespace passing This issue is much more recent, but I'm not sure if a consensus to not chan= ge the current text was reached. Andy last posted about a rare corner-case= , but does that mean we stick with the status quo though many said that imp= lementations were unlikely to support it? http://www.ietf.org/mail-archive/web/netconf/current/msg06709.html Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Feb 8 01:14:51 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6632F3A708B for ; Tue, 8 Feb 2011 01:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=0.331, 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 XnAFzCMLibzA for ; Tue, 8 Feb 2011 01:14:50 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 124573A6DDB for ; Tue, 8 Feb 2011 01:14:48 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pmjeu-0003ob-6k; Tue, 08 Feb 2011 10:14:53 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pmjet-00086t-RR; Tue, 08 Feb 2011 10:14:51 +0100 Message-ID: <4D51098B.60001@bwijnen.net> Date: Tue, 08 Feb 2011 10:14:51 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3751C759B9@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3751C759B9@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4318fc08610f85207e8615537233b7c04 Cc: "netconf@ietf.org" Subject: Re: [Netconf] a couple 4741bis lingering issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:14:51 -0000 Kent, you are indeed quite late. In fact, WG LC (last Call) closed several weeks ago. IETF LC closed yesterday. Besides that, I believe we did discuss these issues before, and did not get to consensus. And thus decided to not make any changes for these items. We can of course keep reopening old issues over and over again, but that way we will never get a new document published. So I am inclined to declare this as "we do not want to reopen this discussion since I do not see why we would reach consensus this time:. (can't check with my co-chair right now) Bert Document Shepherd and co-chair of NETCONF On 2/7/11 5:27 PM, Kent Watsen wrote: > I'm not sure if it's too late to bring this up, but I was reviewing the mailing list archive and realized that two issues didn't seem to reach closure: > > > 1. before > > This issue was first raised by Martin over a year ago and then again by me (though I messed up and wrote comes *after* when I meant *before*): > > http://www.ietf.org/mail-archive/web/netconf/current/msg03876.html > http://www.ietf.org/mail-archive/web/netconf/current/msg06072.html > > Both times the thread peters out and yet the issue remains in 4741bis-07. Shouldn't the spec provide guidance on how to handle an error after has started to stream? > > > 2. Namespace passing > > This issue is much more recent, but I'm not sure if a consensus to not change the current text was reached. Andy last posted about a rare corner-case, but does that mean we stick with the status quo though many said that implementations were unlikely to support it? > > http://www.ietf.org/mail-archive/web/netconf/current/msg06709.html > > > Thanks, > Kent > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Tue Feb 8 01:55:28 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4133A70B5 for ; Tue, 8 Feb 2011 01:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2RXqsMH2g72 for ; Tue, 8 Feb 2011 01:55: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 BE2103A70B6 for ; Tue, 8 Feb 2011 01:55:26 -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 7FCD176C2C7 for ; Tue, 8 Feb 2011 10:55:31 +0100 (CET) Date: Tue, 08 Feb 2011 10:55:31 +0100 (CET) Message-Id: <20110208.105531.57695171697347878.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Feb__8_10_55_31_2011_457)--" Content-Transfer-Encoding: 7bit Subject: [Netconf] Fw: apps-team review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:55:28 -0000 ----Next_Part(Tue_Feb__8_10_55_31_2011_457)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on thermopyle.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,HTML_FONT_FACE_BAD, HTML_MESSAGE autolearn=no version=3.2.4 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail-iw0-f179.google.com (mail-iw0-f179.google.com [209.85.214.179]) by mail.tail-f.com (Postfix) with ESMTPS id AAB6176C30C for ; Mon, 7 Feb 2011 19:03:08 +0100 (CET) Received: by iwb12 with SMTP id 12so4958051iwb.10 for ; Mon, 07 Feb 2011 10:03:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.39.67 with SMTP id f3mr17814783ibe.42.1297101786490; Mon, 07 Feb 2011 10:03:06 -0800 (PST) Received: by 10.231.160.133 with HTTP; Mon, 7 Feb 2011 10:03:06 -0800 (PST) Date: Mon, 7 Feb 2011 10:03:06 -0800 Message-ID: Subject: apps-team review of draft-ietf-netconf-4741bis-07 From: Joshua Bell To: apps-review@ietf.org, rpe@juniper.net, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com Cc: SM Content-Type: multipart/alternative; boundary=00032557635a38a7f0049bb50b1d X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5 int cnt prob spamicity histogram 0.00 160 0.029993 0.026725 ################################################ 0.10 12 0.107311 0.033656 #### 0.20 0 0.000000 0.033656 0.30 0 0.000000 0.033656 0.40 0 0.000000 0.033656 0.50 0 0.000000 0.033656 0.60 0 0.000000 0.033656 0.70 0 0.000000 0.033656 0.80 1 0.883282 0.044349 # 0.90 7 0.972104 0.165540 ### --00032557635a38a7f0049bb50b1d Content-Type: text/plain; charset=UTF-8 == Boilerplate == I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netconf-4741bis-07 Title: Network Configuration Protocol (NETCONF) Reviewer: Joshua Bell Review Date: 2011-02-04 IETF Last Call Date: 2011-02-07 == Summary == This draft is almost ready for publication but has a few issues that should be fixed before publication. The issues I note are not significant detractions from the overall high quality and readability of the I-D. The I-D is an update to RFC 4741 and has therefore "stood the test of time". I was not familiar with the previous RFC and thus reviewed the document as "new to me", then went back and did a cursory review of my feedback to see what applied to the previous document as well. == Major Issues == none == Minor Issues unique to the I-D == Section 3 XML Considerations includes: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives an 'rpc' message that is not well-formed XML, it SHOULD reply with an 'operation-failed' error. If a reply cannot be sent for any reason, the server MUST close the session. The behavior when an 'rpc' message is received that is well-formed XML but specifies an encoding other than UTF-8 is not strictly defined. This could occur where the encoding is defined via an XML declaration, such as (XML declarations are explicitly permitted a few lines down in the I-D). I suggest that the I-D specify that if a non-UTF-8 encoding is specified the peer SHOULD reply with an 'operation-failed' error, if this is the expected behavior. Section 8.9.1 XPath Capability Description includes: The data model used in the XPath expression is the same as that used in XPath 1.0 [2], with the same extension for root node children as used by XSLT 1.0 [11] (section 3.1). Specifically, it means that the root node may have any number of element nodes as its children. It is unclear how this applies. My understanding is that in XSLT this wording refers to the results tree of a transform, and allows for a transform which e.g. outputs a non-well-formed XML document with multiple top-level elements (e.g. "") rather than a well-formed document with a single root element. However, this section of the I-D is describing the input data model to the XPath filter expression, and which explicitly yields a node-set as a result rather than a result tree. If this text is intended to describe the XML returned by the or operation, it should be stated separately from the description of the XPath data model. On a possibly related note, the next bit which describes how the node-set selected by the XPath expression yields the output tree seems underspecified: The response message contains the subtrees selected by the filter expression. For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message. It is unclear (to me) exactly what the output should be when the node-set results of the XPath expression contains multiple nodes. For example (simplified relative to the examples in the I-D). given the filter: select="/users/user[name='fred' or name='barney'] Would this yield: fred barney or: fred barney The former is strongly implied by the non-XPath-based filter logic defined in section 6 (i.e. the text "Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data."), but the latter is hinted at by the note about the "XSLT extension for root node children" called out above. In either case, more clarity in the normative text would be worthwhile, as well as an example. == Minor Issues in common with RFC 4741 == Section 4.1 and 4.2 define the usage of the "message-id" attribute. Since the value is an arbitrary string selected by the sender, it is possible that XML processing would modify this value as part of attribute-value normalization: http://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize - I suggest adding the requirement that senders ensure that message-ids are already normalized per these rules so that they round-trip cleanly. Section 4.2 is where the element first appears but only in examples; unlike 4.3 which explicitly calls out and 4.4 which explicitly calls out ; is also not identified in the XML Schema in Appendix B. This leads to the impression that is just an example element, but it is defined normatively as part of the positive response in sections 7.1 and 7.7 == Nits in common with RFC 4741 == Section 5.1 has odd bulleting around the paragraph for "Running" (a single bullet point). (This looks like residue from an earlier revision where multiple datastores were defined but then made optional via capabilities.) Attribute names are called out inconsistently within the document. E.g. "... the select attribute...", "containing a 'type' attribute...", "... a "message-id" attribute...". For improved readability this should be standardized. Finally, I did not manually verify all of the filter examples in Section 6. >From a cursory inspection, the introduction of the namespace wildcarding (Section 6.2.1) should not change the validity of the samples from RFC 4741. If there is a sample dataset and utility that could be used to quickly validate the filters in all cases it would be a good idea. -- Josh --00032557635a38a7f0049bb50b1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=3D=3D Boilerplate =3D=3D

I have been selecte= d as the Applications Area Review Team reviewer for this draft (for backgro= und on apps-review, please see http://www.apps.ietf.org/c= ontent/applications-area-review-team).=C2=A0

Please resolve these comments along with any other Last= Call comments you may receive. Please wait for direction from your documen= t shepherd or AD before posting a new version of the draft.

Document: draft-ietf-netconf-4741bis-07
Title: Network= Configuration Protocol (NETCONF)
Reviewer: Joshua Bell
Review Date: 2011-02-04
IETF Last Call Date: 2011-02-07

=3D=3D Summary =3D=3D

This dra= ft is almost ready for publication but has a few issues that should be fixe= d before publication.=C2=A0The issues I note are not significant detraction= s from the overall high quality and readability of the I-D.

The I-D is an update to RFC 4741 and has therefore &quo= t;stood the test of time". I was not familiar with the previous RFC an= d thus reviewed the document as "new to me", then went back and d= id a cursory review of my feedback to see what applied to the previous docu= ment as well.

=3D=3D Major Issues =3D=3D

non= e

=3D=3D Minor Issues unique to the I-D =3D=3D

=
Section 3 XML Considerations includes:

   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  If a
   peer receives an 'rpc' message that is not well-formed XML, it S=
HOULD
   reply with an 'operation-failed' error.  If a reply cannot be se=
nt
   for any reason, the server MUST close the session.

The behavior when an 'rpc' m= essage is received that is well-formed XML but specifies an encoding other = than UTF-8 is not strictly defined. This could occur where the encoding is= =C2=A0defined via an XML declaration, such as=C2=A0<?xml version=3D&quo= t;1.0" encoding=3D"EUC-JP" ?> (XML declarations ar= e explicitly permitted a few lines down in the I-D). I suggest that the I-D= specify that if a non-UTF-8 encoding is specified the peer SHOULD reply wi= th an 'operation-failed' error, if this is the expected behavior.

Section 8.9.1 XPath Capability Description includ= es:

   The data model used in the XPath expression is the same as that used
   in XPath 1.0 [2], with the same extension for root node children as
   used by XSLT 1.0 [11] (section 3.1).  Specifically, it means that the
   root node may have any number of element nodes as its children.

It is unclear how this applies.= My understanding is that in XSLT this wording refers to the results tree o= f a transform, and allows for a transform which e.g. outputs a non-well-for= med XML document with multiple top-level elements (e.g. "<elem/>= <elem/><elem/>") rather than a well-formed document with a= single root element. However, this section of the I-D is describing the in= put data model to the XPath filter expression, and which explicitly yields = a node-set as a result rather than a result tree.=C2=A0If this text is inte= nded to describe the XML returned by the <get/> or <get-config/>= ; operation, it should be stated separately from the description of the XPa= th data model.

On a possibly related note, the next bit which describe= s how the node-set selected by the XPath expression yields the output tree = seems underspecified:

   The response message contains the subtrees selected by the filter
   expression.  For each such subtree, the path from the data model root
   node down to the subtree, including any elements or attributes
   necessary to uniquely identify the subtree, are included in the
   response message.

It is unclear (to me) exactly what the output should be when the node-set r= esults of the XPath expression contains multiple nodes. For example=C2=A0(simplif= ied relative to the examples in the I-D).=C2=A0given the filter:

=C2=A0=C2=A0 select=3D"/users= /user[name=3D'fred' or name=3D'barney']

Would this yield:

           <users>

    =
         <user>
               <name>fred</name>
             </user>

             <user>
               <name>barney</name>
             </user>

            </users>

or:




           <users>
             <user>
               <name>fred</name>
             </user>
           </users>


           <users>
             <user>
               <name>barney</name>
             </user>
           </users>

The f= ormer is strongly implied by the non-XPath-based filter logic defined in se= ction 6 (i.e. the text "Specific the request contains multiple filter subtree expressions = that select the same data."), but the la= tter is hinted at by the note about the "XSLT extension for root node = children" called out above. In either case, more clarity in the normat= ive text would be worthwhile, as well as an example.


=3D=3D Minor Issues in common with RFC 4= 741 =3D=3D

Section 4.1 and 4.2 define the usage of= the "message-id" attribute. Since the value is an arbitrary stri= ng selected by the sender, it is possible that XML processing would modify = this value as part of attribute-value normalization: http://www.= w3.org/TR/2008/REC-xml-20081126/#AVNormalize - I suggest adding the req= uirement that senders ensure that message-ids are already normalized per th= ese rules so that they round-trip cleanly.

Section 4.2 is where the <data> element first app= ears but only in examples; unlike 4.3 which explicitly calls out <rpc-er= ror> and 4.4 which explicitly calls out <ok>; <data> is also= not identified in the XML Schema in Appendix B. This leads to the impressi= on that <data> is just an example element, but it is defined normativ= ely as part of the positive response in sections 7.1 and 7.7=C2=A0


=3D=3D Nits in common with RFC 4741 =3D= =3D

Section 5.1 has odd bulleting around the parag= raph for "Running" (a single bullet point). (This looks like resi= due from an earlier revision where multiple datastores were defined but the= n made optional via capabilities.)

Attribute names are called out inconsistently with= in the document. E.g. "... the select attribute...", "contai= ning a 'type' attribute...", "... a "message-id"= ; attribute...". For improved readability this should be standardized.=

Finally, I did not manually verify all of the fil= ter examples in Section 6. From a cursory inspection, the introduction of t= he namespace wildcarding (Section 6.2.1) should not change the validity of = the samples from RFC 4741. If there is a sample dataset and utility that co= uld be used to quickly validate the filters in all cases it would be a good= idea.

-- Josh

--00032557635a38a7f0049bb50b1d-- ----Next_Part(Tue_Feb__8_10_55_31_2011_457)---- From mbj@tail-f.com Tue Feb 8 01:55:45 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A003A70B5 for ; Tue, 8 Feb 2011 01:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.221, 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 hYXHrmwxXTjp for ; Tue, 8 Feb 2011 01:55:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9D8B83A70B6 for ; Tue, 8 Feb 2011 01:55:43 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4DD2876C2DE for ; Tue, 8 Feb 2011 10:55:49 +0100 (CET) Date: Tue, 08 Feb 2011 10:55:49 +0100 (CET) Message-Id: <20110208.105549.1139759117160836880.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Feb__8_10_55_49_2011_620)--" Content-Transfer-Encoding: 7bit Subject: [Netconf] Fw: Review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:55:45 -0000 ----Next_Part(Tue_Feb__8_10_55_49_2011_620)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on thermopyle.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.2.4 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by mail.tail-f.com (Postfix) with ESMTPS id 342F176C255 for ; Tue, 8 Feb 2011 03:05:22 +0100 (CET) Received: from usaga02-in.huawei.com ([206.16.17.70]) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pmcx8-0003d3-Sn for draft-ietf-netconf-4741bis@tools.ietf.org; Mon, 07 Feb 2011 18:05:16 -0800 Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGA009ZO0GHR5@usaga02-in.huawei.com> for draft-ietf-netconf-4741bis@tools.ietf.org; Mon, 07 Feb 2011 18:05:06 -0800 (PST) Received: from TingZousc1 ([10.193.34.106]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGA0082F0GHMN@usaga02-in.huawei.com> for draft-ietf-netconf-4741bis@tools.ietf.org; Mon, 07 Feb 2011 18:05:05 -0800 (PST) Date: Mon, 07 Feb 2011 18:05:05 -0800 From: Tina Tsou To: secdir@ietf.org Cc: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietf@ietf.org Message-id: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvHNJologxQ/mhUTsec0i/teATXiw== X-SA-Exim-Connect-IP: 206.16.17.70 X-SA-Exim-Rcpt-To: draft-ietf-netconf-4741bis@tools.ietf.org X-SA-Exim-Mail-From: tena@huawei.com Subject: Review of draft-ietf-netconf-4741bis-07 X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5 int cnt prob spamicity histogram 0.00 62 0.021045 0.016213 ################################################ 0.10 7 0.110223 0.025637 ###### 0.20 0 0.000000 0.025637 0.30 0 0.000000 0.025637 0.40 0 0.000000 0.025637 0.50 0 0.000000 0.025637 0.60 0 0.000000 0.025637 0.70 0 0.000000 0.025637 0.80 6 0.884930 0.145666 ##### 0.90 7 0.970960 0.289876 ###### I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. It is well written, so only some editorial comments are below. #1 " 2.2. Authentication, Integrity, and Confidentiality ... 2.3. Authentication ... " Perhaps the Titles of 2.2 and 2.3 can harmonize better to explain why there are two "authentications" here. #2 " 6.2. Subtree Filter Components A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that may be present in a subtree filter: o Namespace Selection o Attribute Match Expressions o Containment Nodes o Selection Nodes o Content Match Nodes ... " If a figure could be provided to describe the relationship among these 5 components and when it becomes what, it would be very helpful for readers to understand more easily. #3 " 6.2.3. Containment Nodes Nodes that contain child elements within a subtree filter are called "containment nodes". I would say "Child Elements Nodes" or "Child Nodes" might be a little bit more of straight forward than "Containment Nodes". #4 " 7.2. ... Parameters: ... merge: The configuration data in the parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior. ... " Has the parameter been introduced before? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html ----Next_Part(Tue_Feb__8_10_55_49_2011_620)---- From bertietf@bwijnen.net Tue Feb 8 02:06:06 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1413A70C1; Tue, 8 Feb 2011 02:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 i-ZdWe6OhJ2j; Tue, 8 Feb 2011 02:06:05 -0800 (PST) Received: from relay.versatel.net (beverwijk.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id A52903A70AB; Tue, 8 Feb 2011 02:06:05 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PmkSY-0007PZ-Ch; Tue, 08 Feb 2011 11:06:10 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Joshua Bell" , References: In-Reply-To: Date: Tue, 8 Feb 2011 11:04:37 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: SM , Netconf Subject: Re: [Netconf] apps-team review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:06:07 -0000 Josh, thanks for your review and comments All comments together are being considered by the editors and possibly will result in a new revision. We'll keep you updated. Bert Wijnen Document Shepherd ----- Original Message ----- From: "Joshua Bell" To: ; ; ; ; Cc: "SM" Sent: Monday, February 07, 2011 7:03 PM Subject: apps-team review of draft-ietf-netconf-4741bis-07 > == Boilerplate == > > I have been selected as the Applications Area Review Team reviewer for this > draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-netconf-4741bis-07 > Title: Network Configuration Protocol (NETCONF) > Reviewer: Joshua Bell > Review Date: 2011-02-04 > IETF Last Call Date: 2011-02-07 > > == Summary == > > This draft is almost ready for publication but has a few issues that should > be fixed before publication. The issues I note are not significant > detractions from the overall high quality and readability of the I-D. > > The I-D is an update to RFC 4741 and has therefore "stood the test of time". > I was not familiar with the previous RFC and thus reviewed the document as > "new to me", then went back and did a cursory review of my feedback to see > what applied to the previous document as well. > > == Major Issues == > > none > > == Minor Issues unique to the I-D == > > Section 3 XML Considerations includes: > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a > peer receives an 'rpc' message that is not well-formed XML, it SHOULD > reply with an 'operation-failed' error. If a reply cannot be sent > for any reason, the server MUST close the session. > > > The behavior when an 'rpc' message is received that is well-formed XML but > specifies an encoding other than UTF-8 is not strictly defined. This could > occur where the encoding is defined via an XML declaration, such as version="1.0" encoding="EUC-JP" ?> (XML declarations are explicitly > permitted a few lines down in the I-D). I suggest that the I-D specify that > if a non-UTF-8 encoding is specified the peer SHOULD reply with an > 'operation-failed' error, if this is the expected behavior. > > Section 8.9.1 XPath Capability Description includes: > > The data model used in the XPath expression is the same as that used > in XPath 1.0 [2], with the same extension for root node children as > used by XSLT 1.0 [11] (section 3.1). Specifically, it means that the > root node may have any number of element nodes as its children. > > > It is unclear how this applies. My understanding is that in XSLT this > wording refers to the results tree of a transform, and allows for a > transform which e.g. outputs a non-well-formed XML document with multiple > top-level elements (e.g. "") rather than a well-formed > document with a single root element. However, this section of the I-D is > describing the input data model to the XPath filter expression, and which > explicitly yields a node-set as a result rather than a result tree. If this > text is intended to describe the XML returned by the or > operation, it should be stated separately from the description of the XPath > data model. > > On a possibly related note, the next bit which describes how the node-set > selected by the XPath expression yields the output tree seems > underspecified: > > The response message contains the subtrees selected by the filter > expression. For each such subtree, the path from the data model root > node down to the subtree, including any elements or attributes > necessary to uniquely identify the subtree, are included in the > response message. > > > It is unclear (to me) exactly what the output should be when the node-set > results of the XPath expression contains multiple nodes. For example > (simplified > relative to the examples in the I-D). given the filter: > > select="/users/user[name='fred' or name='barney'] > > Would this yield: > > > > > fred > > > > barney > > > > > > or: > > > > fred > > > > > > > barney > > > > > The former is strongly implied by the non-XPath-based filter logic defined > in section 6 (i.e. the text "Specific data instances are not duplicated in > the response in the event that the request contains multiple filter subtree > expressions that select the same data."), but the latter is hinted at by the > note about the "XSLT extension for root node children" called out above. In > either case, more clarity in the normative text would be worthwhile, as well > as an example. > > > == Minor Issues in common with RFC 4741 == > > Section 4.1 and 4.2 define the usage of the "message-id" attribute. Since > the value is an arbitrary string selected by the sender, it is possible that > XML processing would modify this value as part of attribute-value > normalization: http://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize - I > suggest adding the requirement that senders ensure that message-ids are > already normalized per these rules so that they round-trip cleanly. > > Section 4.2 is where the element first appears but only in examples; > unlike 4.3 which explicitly calls out and 4.4 which explicitly > calls out ; is also not identified in the XML Schema in Appendix > B. This leads to the impression that is just an example element, but > it is defined normatively as part of the positive response in sections 7.1 > and 7.7 > > > == Nits in common with RFC 4741 == > > Section 5.1 has odd bulleting around the paragraph for "Running" (a single > bullet point). (This looks like residue from an earlier revision where > multiple datastores were defined but then made optional via capabilities.) > > Attribute names are called out inconsistently within the document. E.g. "... > the select attribute...", "containing a 'type' attribute...", "... a > "message-id" attribute...". For improved readability this should be > standardized. > > Finally, I did not manually verify all of the filter examples in Section 6. > From a cursory inspection, the introduction of the namespace wildcarding > (Section 6.2.1) should not change the validity of the samples from RFC 4741. > If there is a sample dataset and utility that could be used to quickly > validate the filters in all cases it would be a good idea. > > -- Josh > From bertietf@bwijnen.net Tue Feb 8 02:06:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388623A70D0; Tue, 8 Feb 2011 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 wr7eIFDXTogL; Tue, 8 Feb 2011 02:06:08 -0800 (PST) Received: from relay.versatel.net (beverwijk.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id DE3363A70CE; Tue, 8 Feb 2011 02:06:07 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PmkSZ-0007PZ-5r; Tue, 08 Feb 2011 11:06:11 +0100 Message-ID: <8361477078854CCF9EBF9CDA8CEAF44A@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Tina Tsou" , References: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> In-Reply-To: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> Date: Tue, 8 Feb 2011 11:06:06 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: Netconf , iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:06:09 -0000 Tina, thanks for your review and comments All comments together are being considered by the editors and possibly will result in a new revision. We'll keep you updated. But I believe you are also on our netconf wg mailing list, so you'll see it there too. Bert Wijnen Document Shepherd ----- Original Message ----- From: "Tina Tsou" To: Cc: ; ; Sent: Tuesday, February 08, 2011 3:05 AM Subject: Review of draft-ietf-netconf-4741bis-07 >I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > It is well written, so only some editorial comments are below. > > #1 > " > 2.2. Authentication, Integrity, and Confidentiality > ... > 2.3. Authentication > ... > " > > Perhaps the Titles of 2.2 and 2.3 can harmonize better to explain why there > are two "authentications" here. > > #2 > " > 6.2. Subtree Filter Components > > A subtree filter is comprised of XML elements and their XML > attributes. There are five types of components that may be present > in a subtree filter: > > o Namespace Selection > > o Attribute Match Expressions > > o Containment Nodes > > o Selection Nodes > > o Content Match Nodes > ... > " > > If a figure could be provided to describe the relationship among these 5 > components and when it becomes what, it would be very helpful for readers to > understand more easily. > > #3 > " > 6.2.3. Containment Nodes > > Nodes that contain child elements within a subtree filter are called > "containment nodes". > > I would say "Child Elements Nodes" or "Child Nodes" might be a little bit > more of straight forward than "Containment Nodes". > > > #4 > " > 7.2. > ... > Parameters: > ... > merge: The configuration data in the parameter is > merged with the configuration at the corresponding level in > the target datastore. This is the default behavior. > ... > " > Has the parameter been introduced before? > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > > From bertietf@bwijnen.net Wed Feb 9 00:01:07 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441CE3A6932 for ; Wed, 9 Feb 2011 00:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 DH3UTG6KP7xq for ; Wed, 9 Feb 2011 00:01:06 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 5B17D3A692F for ; Wed, 9 Feb 2011 00:01:03 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pn4z7-0001iV-Nr for netconf@ietf.org; Wed, 09 Feb 2011 09:01:11 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pn4z7-0007yy-F1 for netconf@ietf.org; Wed, 09 Feb 2011 09:01:09 +0100 Message-ID: <4D5249C5.7040303@bwijnen.net> Date: Wed, 09 Feb 2011 09:01:09 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd482027ae450d3d468935955d3c383dadc Subject: [Netconf] Fwd: [IANA #426231] Re: Last Call: (Network Configuration Protocol (NETCONF)) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 08:01:07 -0000 FYI -------- Original Message -------- Subject: [IANA #426231] Re: Last Call: (Network Configuration Protocol (NETCONF)) to Proposed Standard Date: Wed, 9 Feb 2011 00:50:58 +0000 From: Amanda Baber via RT Reply-To: drafts-lastcall@iana.org CC: biermana@Brocade.com, rpe@juniper.net, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, netconf-chairs@tools.ietf.org, bertietf@bwijnen.net They did. Thanks! Amanda On Mon Feb 07 11:40:39 2011, bertietf@bwijnen.net wrote: > Amanda/IANA, > > Did the below explanations make things clear? > > Thanks, > Bert WIjnen > Document Shepherd > > On 2/5/11 5:34 PM, Andy Bierman wrote: > > Hi, > > > > These are the specific capabilities to update the RFC reference. > > Also the '1.1' capabilities are missing from the assignment. > > > > Andy > > > > > > > > IANA is requested to update the allocations of the following > > capabilities to reference this document when it is published as > an > > RFC. > > > > +-------------------- > +----------------------------------------------+ > > | Index | Capability Identifier > | > > +-------------------- > +----------------------------------------------+ > > | :writable-running | > urn:ietf:params:netconf:capability:writable- | > > | | running:1.0 > | > > | | > | > > | :candidate | > urn:ietf:params:netconf:capability:candidate | > > | | :1.0 > | > > | | > | > > | :rollback-on-error | > urn:ietf:params:netconf:capability:rollback- | > > | | on-error:1.0 > | > > | | > | > > | :startup | > urn:ietf:params:netconf:capability:startup:1 | > > | | .0 > | > > | | > | > > | :url | > urn:ietf:params:netconf:capability:url:1.0 | > > | | > | > > | :xpath | > urn:ietf:params:netconf:capability:xpath:1.0 | > > +-------------------- > +----------------------------------------------+ > > > > IANA is requested to add the following capabilities to the > registry: > > > > +--------------------- > +---------------------------------------------+ > > | Index | Capability Identifier > | > > +--------------------- > +---------------------------------------------+ > > | :base:1.1 | urn:ietf:params:netconf:base:1.1 > | > > | | > | > > | :confirmed-commit:1 | > urn:ietf:params:netconf:capability:confirme | > > | .1 | d-commit:1.1 > | > > | | > | > > | :validate:1.1 | > urn:ietf:params:netconf:capability:validate | > > | | :1.1 > | > > +--------------------- > +---------------------------------------------+ > > > > > > > > > > -----Original Message----- > > From: Amanda Baber via RT [mailto:drafts-lastcall@iana.org] > > Sent: Friday, February 04, 2011 7:06 PM > > Cc: rpe@juniper.net; mbj@tail-f.com; j.schoenwaelder@jacobs- > university.de; Andy Bierman; netconf-chairs@tools.ietf.org; > iesg@ietf.org > > Subject: [IANA #423100] Last Call: 07.txt> (Network Configuration Protocol (NETCONF)) to Proposed > Standard > > > > IESG: > > > > IANA has reviewed draft-ietf-netconf-4741bis-07.txt, which is > > currently in Last Call, and has the following comments: > > > > IANA understands that, upon approval of this document, there are > four > > actions that IANA needs to complete. > > > > First, in the IEFT XML namespace registry located at: > > > > http://www.iana.org/assignments/xml-registry/ns.html > > > > a new namespace is to be registered as follows: > > > > ns: netconf:base:1.0 > > URI: urn:ietf:params:xml:ns:netconf:base:1.0 > > Registration template: NONE > > Reference: [RFC-to-be] > > > > Second, in the IANA XML schema registry located at: > > > > http://www.iana.org/assignments/xml-registry/schema.html > > > > a new schema is to be registered as follows: > > > > ID: netconf > > URI: urn:ietf:params:xml:schema:netconf > > Filename: [as provided in Appendix B of the approved document] > > Reference: [RFC-to-be] > > > > Third, in the YANG Module Names subregistry of the Yang parameters > > registry located at: > > > > http://www.iana.org/assignments/yang-parameters/yang- > parameters.xhtml > > > > a new module is to be added to the registry as follows: > > > > name: ietf-netconf > > namespace: urn:ietf:params:xml:ns:netconf:base:1.0 > > prefix: nc > > module: [left blank] > > reference: [RFC-to-be] > > > > Fourth, in the Network Configuration Protocol (NETCONF) Capability > URNs > > registry located at: > > > > http://www.iana.org/assignments/netconf-capability-urns/netconf- > capability-urns.xhtml > > > > the references for the existing, registered URNs should be updated > to > > reference [RFC-to-be]. In addition, the matrix entry for the Network > > Configuration Protocol (NETCONF) Capability URNs registry should be > > updated to reference [RFC-to-be]. IANA understand that this document > > adds no new registration to the the Network Configuration Protocol > > (NETCONF) Capability URNs registry, but simply updates the > references of > > the existing registrations. > > > > IANA understands that these are the only actions that need to be > > completed upon approval of this document. > > > > Thanks, > > > > Amanda Baber > > IANA > > > > On Mon Jan 24 15:01:13 2011, noreply@ietf.org wrote: > >> The IESG has received a request from the Network Configuration WG > >> (netconf) to consider the following document: > >> - 'Network Configuration Protocol (NETCONF)' > >> as a Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks, and > solicits > >> final comments on this action. Please send substantive comments to > the > >> ietf@ietf.org mailing lists by 2011-02-07. Exceptionally, comments > may be > >> sent to iesg@ietf.org instead. In either case, please retain the > >> beginning of the Subject line to allow automated sorting. > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > > > > > From Internet-Drafts@ietf.org Fri Feb 11 05:45:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8793C3A6995; Fri, 11 Feb 2011 05:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 Dd5mimLTWoy6; Fri, 11 Feb 2011 05:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02633A6999; Fri, 11 Feb 2011 05:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110211134501.5908.71615.idtracker@localhost> Date: Fri, 11 Feb 2011 05:45:01 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 13:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-08.txt Pages : 121 Date : 2011-02-11 The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as Remote Procedure Calls (RPC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-4741bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-11053501.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Fri Feb 11 07:37:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55673A688F for ; Fri, 11 Feb 2011 07:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 URqNLQqy339Z for ; Fri, 11 Feb 2011 07:37:11 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id A13EF3A69B2 for ; Fri, 11 Feb 2011 07:37:10 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pnv3i-0002Fe-47 for netconf@ietf.org; Fri, 11 Feb 2011 16:37:24 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=osx46.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pnv3h-0001M9-TB for netconf@ietf.org; Fri, 11 Feb 2011 16:37:21 +0100 Message-ID: <4D5557B1.6080104@bwijnen.net> Date: Fri, 11 Feb 2011 16:37:21 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43c7d54a48dffbcf5eacd1a690956b26c Subject: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:37:12 -0000 WG Members, please do a quick check on the new revision. It is easiest of you look though the diffs at http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 The revision 08 is the result of the editors trying to resolve and address all the IETF Last Call issues (they were all posted to this list last week). If you find that they made any fatal flaws in that process, pls let us (the WG chairs and preferably also the WG mailing list) know by 17 Feb 2011. Bert Wijnen Document Shepherd -------- Original Message -------- Subject: New Version Notification - draft-ietf-netconf-4741bis-08.txt Date: Fri, 11 Feb 2011 05:45:01 -0800 From: Internet-Draft@ietf.org To: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, dromasca@avaya.com New version (-08) has been submitted for draft-ietf-netconf-4741bis-08.txt. http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-08.txt Sub state has been changed to AD Follow up from New Id Needed Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 IETF Secretariat. From kwatsen@juniper.net Fri Feb 11 12:29:13 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCF63A6997 for ; Fri, 11 Feb 2011 12:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01Y7gdVv6iuZ for ; Fri, 11 Feb 2011 12:29:11 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id A3D633A6975 for ; Fri, 11 Feb 2011 12:29:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTVWcJZTTYu7ajfsPaaGWfU8PQow4wuzS@postini.com; Fri, 11 Feb 2011 12:29:26 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, 11 Feb 2011 12:27:10 -0800 From: Kent Watsen To: "netconf@ietf.org" Date: Fri, 11 Feb 2011 12:27:23 -0800 Thread-Topic: [Netconf] namespace passing Thread-Index: Acu77s7CD0lI3howTYiCUP1jZvPc3AONLtxw Message-ID: <84600D05C20FF943918238042D7670FD3759E08E06@EMBX01-HQ.jnpr.net> References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> <20110121.221403.250794340.mbj@tail-f.com> <1295884463.4317.43.camel@behold> <4D3DAE0E.9000601@andybierman.com> <1295889407.4317.83.camel@behold> <4D3DBB62.5080801@andybierman.com> In-Reply-To: <4D3DBB62.5080801@andybierman.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: PeiYu Yang Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:29:13 -0000 [CC-ing my colleague PeiYu, who helped with this analysis] We made a discovery while considering the ramifications of 1) the client be= ing allowed to use any namespace-passing strategy and 2) the server must re= turn all attributes (including xmlns) passed by the client. The discovery is that, regardless of which namespace-passing strategy the c= lient uses in its RPC, the server can hardcode how it returns the *payload*= in the RPC reply. Specifically, note that for each of the 6 namespace pas= sing strategies that I wrote in my OP, it is always *acceptable* for the de= vice to return the payload: done This is a very nice finding as it reduces the burden on devices tremendousl= y, thus paving the way for adoption and interoperability. Note: all of the following examples validate to the following YANG module: module foo { namespace "http://acme.com/example"; prefix "foo"; revision 2011-01-16 { description "Initial conception"; } rpc do-something { input { leaf what { type string; } } output { container do-something-reply { leaf result { type string; } } } } } Strategy #1 rpc --------------- write code Strategy #1 both ideal and acceptable rpc-reply ----------------------------------------------- done Strategy #2 rpc --------------- write code Strategy #2 ideal rpc-reply --------------------------- done Strategy #2 acceptable rpc-reply -------------------------------- done Strategy #3 rpc --------------- write code Strategy #3 ideal rpc-reply --------------------------- done Strategy #3 acceptable rpc-reply -------------------------------- done Strategy #4 rpc --------------- write code Strategy #4 both ideal and acceptable rpc-reply ----------------------------------------------- done Strategy #5 rpc --------------- write code Strategy #5 ideal rpc-reply --------------------------- done Strategy #5 acceptable rpc-reply -------------------------------- done Strategy #6 rpc --------------- write code Strategy #6 ideal rpc-reply --------------------------- done Strategy #6 acceptable rpc-reply -------------------------------- done PS: these examples assume a 3rd-party defined namespace, but the same appli= es for the NetConf namespace. For instance, an can *always* be retur= ned as: Regardless of how the xmlns attributes had to be set in the ele= ment. Thanks, Kent From kwatsen@juniper.net Fri Feb 11 12:34:48 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00E73A6997 for ; Fri, 11 Feb 2011 12:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrtsMAPJLVKa for ; Fri, 11 Feb 2011 12:34:47 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 5443F3A6925 for ; Fri, 11 Feb 2011 12:34:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTVWddJcN0oNQVRLLFLVmSrNIqKZmgx1k@postini.com; Fri, 11 Feb 2011 12:35:03 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, 11 Feb 2011 12:33:10 -0800 From: Kent Watsen To: "Bert (IETF) Wijnen" , netconf Date: Fri, 11 Feb 2011 12:33:23 -0800 Thread-Topic: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt Thread-Index: AcvKAY7rlNF2gh3fSKq7qr+O046J8AAKTDtg Message-ID: <84600D05C20FF943918238042D7670FD3759E08E1D@EMBX01-HQ.jnpr.net> References: <4D5557B1.6080104@bwijnen.net> In-Reply-To: <4D5557B1.6080104@bwijnen.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 Subject: Re: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:34:48 -0000 Looks good to me, especially the more normative use of MUST/SHOULD/MAY - th= at was a very good suggestion. K. -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert (IETF) Wijnen Sent: Friday, February 11, 2011 10:37 AM To: netconf Subject: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741b= is-08.txt WG Members, please do a quick check on the new revision. It is easiest of you look though the diffs at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-4741bis-08 The revision 08 is the result of the editors trying to resolve and address all the IETF Last Call issues (they were all posted to this list last week)= . If you find that they made any fatal flaws in that process, pls let us (the WG chairs and preferably also the WG mailing list) know by 17 Feb 2011. Bert Wijnen Document Shepherd -------- Original Message -------- Subject: New Version Notification - draft-ietf-netconf-4741bis-08.txt Date: Fri, 11 Feb 2011 05:45:01 -0800 From: Internet-Draft@ietf.org To: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.o= rg, dromasca@avaya.com New version (-08) has been submitted for draft-ietf-netconf-4741bis-08.txt. http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-08.txt Sub state has been changed to AD Follow up from New Id Needed Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-4741bis-08 IETF Secretariat. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From ietf@andybierman.com Fri Feb 11 12:56:13 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875CD3A69CA for ; Fri, 11 Feb 2011 12:56:13 -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 KxKMbaZCjIgd for ; Fri, 11 Feb 2011 12:56:12 -0800 (PST) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by core3.amsl.com (Postfix) with SMTP id 8B4983A67B3 for ; Fri, 11 Feb 2011 12:56:12 -0800 (PST) Received: from [98.139.91.68] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 20:56:25 -0000 Received: from [98.139.91.4] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 20:56:25 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 20:56:25 -0000 X-Yahoo-Newman-Id: 649868.44601.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 3604 invoked from network); 11 Feb 2011 20:56:25 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 11 Feb 2011 12:56:22 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Zpj_w9sVM1mcFhhkX07L1aarQmGVNJRiAT_MoXDnymuytRs vr2ykRpbFaOlFcr783DCd3.C6KBqebkwSHbkIkgbGqmK3fUWWwA746KMydM0 AckZTj2c.JrL9gB_nWthA1DOZCp_UaxMYtKxTMqOx0cGLKPh6pNwy7pNdpUR O05fW40YMDW7aJLE6Di9xL7I.G4dRlecOjdTrYo0cgt_ejkNtT_7bE4tofXy aJioPcXctuUCJyW3jZHREpWCyPuSdihQKwjQSVlZW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D55A28D.2060805@andybierman.com> Date: Fri, 11 Feb 2011 12:56:45 -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: <4D5557B1.6080104@bwijnen.net> <84600D05C20FF943918238042D7670FD3759E08E1D@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3759E08E1D@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:56:13 -0000 On 02/11/2011 12:33 PM, Kent Watsen wrote: > Looks good to me, especially the more normative use of MUST/SHOULD/MAY - that was a very good suggestion. > Actually, I changed too many must to MUST. Bert, is it OK if I issue a quick -09 with the normative MUST/SHOULD taken out of the non-normative appendixes? > K. > Andy > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen > Sent: Friday, February 11, 2011 10:37 AM > To: netconf > Subject: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt > > WG Members, please do a quick check on the new revision. > It is easiest of you look though the diffs at > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 > > The revision 08 is the result of the editors trying to resolve and address > all the IETF Last Call issues (they were all posted to this list last week). > > If you find that they made any fatal flaws in that process, pls let us (the > WG chairs and preferably also the WG mailing list) know by 17 Feb 2011. > > Bert Wijnen > Document Shepherd > > -------- Original Message -------- > Subject: New Version Notification - draft-ietf-netconf-4741bis-08.txt > Date: Fri, 11 Feb 2011 05:45:01 -0800 > From: Internet-Draft@ietf.org > To: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, dromasca@avaya.com > > > > New version (-08) has been submitted for draft-ietf-netconf-4741bis-08.txt. > http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-08.txt > Sub state has been changed to AD Follow up from New Id Needed > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 > > IETF Secretariat. > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bwijnen@bwijnen.net Sat Feb 12 05:08:06 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EC93A6A43 for ; Sat, 12 Feb 2011 05:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3dYxb2+Ezfu for ; Sat, 12 Feb 2011 05:08:05 -0800 (PST) Received: from relay.versatel.net (relay54.tele2.vuurwerk.nl [62.250.3.54]) by core3.amsl.com (Postfix) with ESMTP id DBA2E3A683D for ; Sat, 12 Feb 2011 05:08:02 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PoFCz-00081B-Q5; Sat, 12 Feb 2011 14:08:17 +0100 Message-ID: From: "Bert Wijnen" To: "Andy Bierman" , "Kent Watsen" References: <4D5557B1.6080104@bwijnen.net> <84600D05C20FF943918238042D7670FD3759E08E1D@EMBX01-HQ.jnpr.net> <4D55A28D.2060805@andybierman.com> In-Reply-To: <4D55A28D.2060805@andybierman.com> Date: Sat, 12 Feb 2011 14:08:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: netconf Subject: Re: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 13:08:06 -0000 Yes, pls go ahead Bert ----- Original Message ----- From: "Andy Bierman" To: "Kent Watsen" Cc: "Bert (IETF) Wijnen" ; "netconf" Sent: Friday, February 11, 2011 9:56 PM Subject: Re: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt > On 02/11/2011 12:33 PM, Kent Watsen wrote: >> Looks good to me, especially the more normative use of MUST/SHOULD/MAY - that >> was a very good suggestion. >> > > Actually, I changed too many must to MUST. > Bert, is it OK if I issue a quick -09 with the normative MUST/SHOULD taken out > of the non-normative appendixes? > > >> K. >> > > Andy > >> >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of >> Bert (IETF) Wijnen >> Sent: Friday, February 11, 2011 10:37 AM >> To: netconf >> Subject: [Netconf] Short WG Last Call: New Version >> draft-ietf-netconf-4741bis-08.txt >> >> WG Members, please do a quick check on the new revision. >> It is easiest of you look though the diffs at >> >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 >> >> The revision 08 is the result of the editors trying to resolve and address >> all the IETF Last Call issues (they were all posted to this list last week). >> >> If you find that they made any fatal flaws in that process, pls let us (the >> WG chairs and preferably also the WG mailing list) know by 17 Feb 2011. >> >> Bert Wijnen >> Document Shepherd >> >> -------- Original Message -------- >> Subject: New Version Notification - draft-ietf-netconf-4741bis-08.txt >> Date: Fri, 11 Feb 2011 05:45:01 -0800 >> From: Internet-Draft@ietf.org >> To: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, >> dromasca@avaya.com >> >> >> >> New version (-08) has been submitted for draft-ietf-netconf-4741bis-08.txt. >> http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-08.txt >> Sub state has been changed to AD Follow up from New Id Needed >> >> Diff from previous version: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 >> >> IETF Secretariat. >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > From Internet-Drafts@ietf.org Sat Feb 12 09:00:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028313A6AC9; Sat, 12 Feb 2011 09:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 QX4cdSc1oORf; Sat, 12 Feb 2011 09:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2315B3A6A1B; Sat, 12 Feb 2011 09:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110212170002.3621.82228.idtracker@localhost> Date: Sat, 12 Feb 2011 09:00:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 17:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-09.txt Pages : 121 Date : 2011-02-12 The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as Remote Procedure Calls (RPC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-4741bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-12085830.I-D@ietf.org> --NextPart-- From ietf@andybierman.com Sat Feb 12 09:33:15 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414703A698E for ; Sat, 12 Feb 2011 09:33:15 -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 hagkQOigg7n3 for ; Sat, 12 Feb 2011 09:33:14 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 81A443A6784 for ; Sat, 12 Feb 2011 09:33:14 -0800 (PST) Received: (qmail 15933 invoked from network); 12 Feb 2011 17:33:29 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 12 Feb 2011 09:33:26 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: nTJrTXQVM1kCqHpJSxnzR6Xk...fTgQdgaULWQVe7Bklmfg kuh_nf13DlczyW.Kp3fZ5jj.hhikxEkhhcgwLNN3hVrXEATNc324NvdLWDhK xaYAtVh4HBzzE9CSdHy3M8mdmk3rtByVkfGC7du2M8OgI0U4v2rv2i5OIP7a 72.Dba5tbmckes0NMM6DttsqYae5ewlY469vPh_Fr8eQ.vpxOZAVLH_OayRw HTej_AiF0qHPbo5nzE20kJ3E7_DtPp0Xws3uB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D56C48B.3040303@andybierman.com> Date: Sat, 12 Feb 2011 09:34:03 -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: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] malformed problem in 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 17:33:15 -0000 Hi, The latest draft introduced a new error-tag 'malformed-message': sec 3: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives an message that is not well-formed XML or not encoded in UTF-8, it SHOULD reply with a "malformed-message" error. If a reply cannot be sent for any reason, the server MUST close the session. Appendix A: error-tag: malformed-message error-type: rpc error-severity: error error-info: none Description: A message could not be handled because it failed to be parsed correctly. For example, the message is not well-formed XML or it uses an invalid character set. Very nice -- but a base:1.1 server cannot send this error-tag to a base:1.0 client. The server agrees to use RFC 4741 unless both peers advertise base:1.1. So more text is needed explaining that. Andy From ietf@andybierman.com Sat Feb 12 19:27:12 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431793A6A84 for ; Sat, 12 Feb 2011 19:27:12 -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 8FOsZop+vhKj for ; Sat, 12 Feb 2011 19:27:11 -0800 (PST) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 7E7083A6A83 for ; Sat, 12 Feb 2011 19:27:11 -0800 (PST) Received: (qmail 59244 invoked from network); 13 Feb 2011 03:27:25 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 12 Feb 2011 19:27:21 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .1aoVhkVM1m99N1TAy_xsLEZn9MjnGUjdQkvZharGsvhO0T CHKJNaIkvDxbPAevWaFXS5TOEC64fSkhTF0jQTM7zdzRo.2rwZf198LyK0sN 9F0AJ4IajtccC9LK3nclFL_h7PEvhfzeGdqSfl5pQuP9X8VRbPrHmYcocOPv CASuBRmV1u88UMfYh5BP_emI7Rjz3rHGJ0ByXjUe.IYg4Ft8knyQHlTOg9UG 2dbFMnO9zuWpHbrsRqZINDXzzfKMlLtOn5avqINxBYT5lX.CJoC5uqV13Lcr FL9s1Pl4.gv7ZGshg9tAmkajc9w2h_YmyMtVAEpmw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D574FC4.6040605@andybierman.com> Date: Sat, 12 Feb 2011 19:28:04 -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: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] milestone? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 03:27:12 -0000 Hi, The latest yuma release (1.14-4) has been added by somebody to the Ubuntu 10.04 Synaptic package manager. I think it's the first NETCONF package to be included in Ubuntu. Makes me want to finish moving the project to sourceforge.net. :-) Andy From scott.brim@gmail.com Tue Feb 15 06:37:19 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7622C3A6A41; Tue, 15 Feb 2011 06:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LfjTuExovw+n; Tue, 15 Feb 2011 06:37:18 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 95B323A6A25; Tue, 15 Feb 2011 06:37:18 -0800 (PST) Received: by ywk9 with SMTP id 9so106384ywk.31 for ; Tue, 15 Feb 2011 06:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=XgyYZbxjfHamwCkQo9nGL/ofjhu8ZgvSj20YWNWjCXo=; b=VlVS/y6mNzQIhDM1Ue80uX5HseQULC7cYiqhbXK8/qw7ZZHyJDGwjnnvDbHK73pi+H Nu/btVSVYSebILDIEIzGl9X+tli95Be5pswAQXuXMfuCmCUbs0aVof42tPO9UmVozjrS DqFx1zp+pwcAc2AN4qLXGxiEaD0pPCPxAsvJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OdinFpp5D5Nr/U6nqq5TdM2GoXPE/msf99h+LPsNb/WGee08hYN22Ch4zngwFoyT4s PVxjgiGhLcBJqgtKCmdfzsVoq/yyucc5nZUFEnuld+nts7JIc1euU9BeVKQjnB+wNOIA Zhparhjc/G5IJ2NqOtWGDwXW2KVabkbFJR6tc= MIME-Version: 1.0 Received: by 10.90.30.5 with SMTP id d5mr6250690agd.132.1297780664060; Tue, 15 Feb 2011 06:37:44 -0800 (PST) Received: by 10.91.180.19 with HTTP; Tue, 15 Feb 2011 06:37:44 -0800 (PST) Date: Tue, 15 Feb 2011 09:37:44 -0500 Message-ID: From: Scott W Brim To: gen-art , draft-ietf-netconf-rfc4742bis , netconf Content-Type: multipart/alternative; boundary=0016362838227a4c51049c531bee X-Mailman-Approved-At: Tue, 15 Feb 2011 06:57:57 -0800 Subject: [Netconf] gen-art review of draft-ietf-netconf-rfc4742bis-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 14:37:19 -0000 --0016362838227a4c51049c531bee Content-Type: text/plain; charset=ISO-8859-1 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netconf-rfc4742bis-06 Reviewer: Scott Brim Review Date: 2011-02-15 IETF LC End Date: 2011-02-16 IESG Telechat date: Summary: this draft is ready for publication as a standards track RFC --0016362838227a4c51049c531bee Content-Type: text/html; charset=ISO-8859-1 I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netconf-rfc4742bis-06
Reviewer: Scott Brim
Review Date: 2011-02-15
IETF LC End Date: 2011-02-16
IESG Telechat date:

Summary: this draft is ready for publication as a standards track RFC
--0016362838227a4c51049c531bee-- From ramu.n@huawei.com Tue Feb 15 18:26:13 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE25A3A6C26 for ; Tue, 15 Feb 2011 18:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FR_3TAG_3TAG=1.758, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNJGmap-vpA0 for ; Tue, 15 Feb 2011 18:26:12 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 81C993A6B6A for ; Tue, 15 Feb 2011 18:26:12 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGO007U7US5NX@szxga03-in.huawei.com> for netconf@ietf.org; Wed, 16 Feb 2011 10:26:29 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGO00IPTUS5KB@szxga03-in.huawei.com> for netconf@ietf.org; Wed, 16 Feb 2011 10:26:29 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 16 Feb 2011 10:25:16 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.65]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 16 Feb 2011 10:26:28 +0800 Date: Wed, 16 Feb 2011 02:26:26 +0000 From: ramu n X-Originating-IP: [10.18.1.38] To: "netconf@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_J1e5tIN4V/iRXV0Gl9q3qQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Regarding empty value provided for xml element in edit-config operation Thread-index: AcvNgOllh1gqzwv0Ry+N/wv0OrIc9A== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Netconf] Regarding empty value provided for xml element in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 02:32:21 -0000 --Boundary_(ID_J1e5tIN4V/iRXV0Gl9q3qQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, In operation, If an empty value is provided for xml element. How the empty values in edit-config should be handled. Example: Ethernet0/0 In the above edit-config request, has empty value. If the element is string data type, can it be treated as NUL string as value of element. If element is not a string data type, How it should be handled. Thanks & Regards, Ramu N --Boundary_(ID_J1e5tIN4V/iRXV0Gl9q3qQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi,

 

In <edit-config> operation, If an empty value is provided for xml element. How the empty values in edit-config should be handled.

 

Example:

    <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu></mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

 

In the above edit-config request, <mtu></mtu> has empty value.

If the <mtu> element is string data type, can it be treated as NUL string as value of <mtu> element.

If <mtu> element is not a string data type, How it should be handled.

 

Thanks & Regards,

Ramu N

--Boundary_(ID_J1e5tIN4V/iRXV0Gl9q3qQ)-- From biermana@Brocade.com Tue Feb 15 19:27:29 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED16B3A6CD9 for ; Tue, 15 Feb 2011 19:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, 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 U5S7bS8NmDYd for ; Tue, 15 Feb 2011 19:27:25 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id A3E713A6CAB for ; Tue, 15 Feb 2011 19:27:25 -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 p1G3RlLZ030858; Tue, 15 Feb 2011 19:27:47 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id ug679g08w-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Feb 2011 19:27:47 -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, 15 Feb 2011 19:35:00 -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; Tue, 15 Feb 2011 19:27:46 -0800 From: Andy Bierman To: ramu n , "netconf@ietf.org" Date: Tue, 15 Feb 2011 19:27:45 -0800 Thread-Topic: [Netconf] Regarding empty value provided for xml element in edit-config operation Thread-Index: AcvNgOllh1gqzwv0Ry+N/wv0OrIc9AACE1og Message-ID: References: In-Reply-To: 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_B11AB91666F22D498EEC66410EB3D3C4F416B5BA3CHQ1EXCH01corp_" 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-02-16_01:2011-02-16, 2011-02-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1102150194 Subject: Re: [Netconf] Regarding empty value provided for xml element in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 03:27:29 -0000 --_000_B11AB91666F22D498EEC66410EB3D3C4F416B5BA3CHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If leaf mtu is type 'empty' or 'string', then or is val= id. Otherwise it is an invalid-value error. Andy From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of ramu n Sent: Tuesday, February 15, 2011 6:26 PM To: netconf@ietf.org Subject: [Netconf] Regarding empty value provided for xml element in edit-c= onfig operation Hi, In operation, If an empty value is provided for xml element. = How the empty values in edit-config should be handled. Example: Ethernet0/0 In the above edit-config request, has empty value. If the element is string data type, can it be treated as NUL string a= s value of element. If element is not a string data type, How it should be handled. Thanks & Regards, Ramu N --_000_B11AB91666F22D498EEC66410EB3D3C4F416B5BA3CHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If leaf m= tu is type ‘empty’ or ‘string’, then <mtu /> = or <mtu></mtu> is valid.

Otherwise it is an invalid-value error.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Andy

 

 

 

From: netco= nf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of r= amu n
Sent: Tuesday, February 15, 2011 6:26 PM
To: netc= onf@ietf.org
Subject: [Netconf] Regarding empty value provided fo= r xml element in edit-config operation

 

Hi,

 

In <edit-config>= operation, If an empty value is provided for xml element. How the empty va= lues in edit-config should be handled.

=  

Example:

    <rpc message-id=3D"101"=
;
   =
;       xmlns=3D"urn:ietf:params:xml:ns:=
netconf:base:1.0">
       <edit-config>=

     =
;    <target>
         &nbs=
p; <running/>
         </target>
    &nbs=
p;    <config>
         &nbs=
p; <top xmlns=3D"http://example.com/schema/1.2/config">
   &nbs=
p;         <interface>
    &=
nbsp;          <name>Eth=
ernet0/0</name>
            =
   <mtu></mtu>
         &nb=
sp;   </interface>
         &nbs=
p; </top>
&nb=
sp;        </config>
     &n=
bsp; </edit-config>
     </rpc>

=  

In the above edit-config request, <mtu></mtu> has empty value.=

If the <mtu> element is string data type, can it be t= reated as NUL string as value of <mtu> element.

=

If <mtu> element is not a string data type, How it should b= e handled.

 

Thanks & Regards,

Ramu N

= --_000_B11AB91666F22D498EEC66410EB3D3C4F416B5BA3CHQ1EXCH01corp_-- From rohitpobbathi@huawei.com Tue Feb 15 21:43:59 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE003A6D3F for ; Tue, 15 Feb 2011 21:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FR_3TAG_3TAG=1.758, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW1yiFCcAkeT for ; Tue, 15 Feb 2011 21:43:54 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8AD663A6D5C for ; Tue, 15 Feb 2011 21:43:53 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGP00H4J3XMPP@szxga03-in.huawei.com> for netconf@ietf.org; Wed, 16 Feb 2011 13:44:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGP000BI3XMO5@szxga03-in.huawei.com> for netconf@ietf.org; Wed, 16 Feb 2011 13:44:10 +0800 (CST) Received: from BLRNSHTIPL8NC ([10.18.1.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGP005AI3XLQ6@szxml06-in.huawei.com> for netconf@ietf.org; Wed, 16 Feb 2011 13:44:10 +0800 (CST) Date: Wed, 16 Feb 2011 11:14:08 +0530 From: Rohit A Pobbathi In-reply-to: To: 'Andy Bierman' , netconf@ietf.org Message-id: <14F3BBBBD7AA4D93AF204C4433EF3665@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_syvNeSmP3yRDPRMPxvIO8A)" Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High Thread-index: AcvNgOllh1gqzwv0Ry+N/wv0OrIc9AACE1ogAASrmYA= Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 05:43:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_syvNeSmP3yRDPRMPxvIO8A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Andy, Thanks for input. Our question in specific is how to handle a SELECTION node (i.e. or ) in a Request ? The intention of the SELECTION node in request is to set the particular element to DEFAULT i.e. to CLEAR the value. Is there any mechanism to set the value of Fields to Default in Edit ? Thanks & Regards, Rohit **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, February 16, 2011 8:58 AM To: ramu n; netconf@ietf.org Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation If leaf mtu is type 'empty' or 'string', then or is valid. Otherwise it is an invalid-value error. Andy From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ramu n Sent: Tuesday, February 15, 2011 6:26 PM To: netconf@ietf.org Subject: [Netconf] Regarding empty value provided for xml element in edit-config operation Hi, In operation, If an empty value is provided for xml element. How the empty values in edit-config should be handled. Example: Ethernet0/0 In the above edit-config request, has empty value. If the element is string data type, can it be treated as NUL string as value of element. If element is not a string data type, How it should be handled. Thanks & Regards, Ramu N --Boundary_(ID_syvNeSmP3yRDPRMPxvIO8A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Andy,

 

Thanks for input.

 

Our question in specific is how to handle a SELECTION node (i.e. <mtu /> or <mtu></mtu>) in a <edit-config> Request ?

 

The intention of the SELECTION node in <edit-config> request is to set the particular element to DEFAULT i.e. to CLEAR the value.

 

Is there any mechanism to set the value of Fields to Default in Edit ?

 

Thanks & Regards,

Rohit

 

 

***************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, February 16, 2011 8:58 AM
To: ramu n; netconf@ietf.org
Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation

 

If leaf mtu is type ‘empty’ or ‘string’, then <mtu /> or <mtu></mtu> is valid.

Otherwise it is an invalid-value error.

 

 

Andy

 

 

 

From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ramu n
Sent: Tuesday, February 15, 2011 6:26 PM
To: netconf@ietf.org
Subject: [Netconf] Regarding empty value provided for xml element in edit-config operation

 

Hi,

 

In <edit-config> operation, If an empty value is provided for xml element. How the empty values in edit-config should be handled.

 

Example:

    <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu></mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

 

In the above edit-config request, <mtu></mtu> has empty value.

If the <mtu> element is string data type, can it be treated as NUL string as value of <mtu> element.

If <mtu> element is not a string data type, How it should be handled.

 

Thanks & Regards,

Ramu N

--Boundary_(ID_syvNeSmP3yRDPRMPxvIO8A)-- From j.schoenwaelder@jacobs-university.de Tue Feb 15 22:46:46 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFC33A6DAD for ; Tue, 15 Feb 2011 22:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 2hZalOBIJQD6 for ; Tue, 15 Feb 2011 22:46:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6FE4B3A6D48 for ; Tue, 15 Feb 2011 22:46:45 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D736C0003; Wed, 16 Feb 2011 07:47:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PqyWti7QjgPc; Wed, 16 Feb 2011 07:47:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6FCCC0004; Wed, 16 Feb 2011 07:47:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 26B72167447C; Wed, 16 Feb 2011 07:46:56 +0100 (CET) Date: Wed, 16 Feb 2011 07:46:56 +0100 From: Juergen Schoenwaelder To: Rohit A Pobbathi Message-ID: <20110216064656.GA78790@elstar.local> Mail-Followup-To: Rohit A Pobbathi , 'Andy Bierman' , netconf@ietf.org References: <14F3BBBBD7AA4D93AF204C4433EF3665@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14F3BBBBD7AA4D93AF204C4433EF3665@china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Andy Bierman' , netconf@ietf.org Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 06:46:47 -0000 On Wed, Feb 16, 2011 at 11:14:08AM +0530, Rohit A Pobbathi wrote: > > Is there any mechanism to set the value of Fields to Default in Edit ? > You may want to read http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-14 to understand the various issues around defaults. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Feb 16 00:40:08 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3A63A6DD1 for ; Wed, 16 Feb 2011 00:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 Q9zLMN8S-8aV for ; Wed, 16 Feb 2011 00:40:07 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3F0863A6DBE for ; Wed, 16 Feb 2011 00:40:05 -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 5FAC976C19F; Wed, 16 Feb 2011 09:40:32 +0100 (CET) Date: Wed, 16 Feb 2011 09:40:31 +0100 (CET) Message-Id: <20110216.094031.68035565067234869.mbj@tail-f.com> To: rohitpobbathi@huawei.com From: Martin Bjorklund In-Reply-To: <14F3BBBBD7AA4D93AF204C4433EF3665@china.huawei.com> References: <14F3BBBBD7AA4D93AF204C4433EF3665@china.huawei.com> 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: biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 08:40:08 -0000 Hi, Rohit A Pobbathi wrote: > Our question in specific is how to handle a SELECTION node (i.e. or > ) in a Request ? would be a "selection node" if it was part of a subtree filter in a or request. In an , means that the mtu leaf should be set to the value "", or created if it was of type 'empty'. > The intention of the SELECTION node in request is to set the > particular element to DEFAULT i.e. to CLEAR the value. > > Is there any mechanism to set the value of Fields to Default in Edit ? As Juergen wrote, see the with-defaults draft for details. But the short answer is that you need to delete the leaf in order to get the "reset to default" behavior: Note that this operation might fail, depending on how defaults are handled by the server, and the contents of the datastore (see with-defaults for details!). If you have a server that supports :base:1.1 (as defined in draft-ietf-netconf-4741bis), you can send: This operation doesn't fail if the mtu doesn't exist. /martin From mbj@tail-f.com Thu Feb 17 00:02:36 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D2D3A6D48 for ; Thu, 17 Feb 2011 00:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa3XpvWHFIdI for ; Thu, 17 Feb 2011 00:02:36 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 009373A6D23 for ; Thu, 17 Feb 2011 00:02:35 -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 C643C76C20F for ; Thu, 17 Feb 2011 09:03:04 +0100 (CET) Date: Thu, 17 Feb 2011 09:03:03 +0100 (CET) Message-Id: <20110217.090303.980790058481806116.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [Netconf] UML from YANG X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 08:02:36 -0000 Hi, This might be of interest to the WG. We have released pyang version 1.1, which includes a UML visualization plugin. With this tool, you can generate UML diagrams from one or more YANG data models. See http://code.google.com/p/pyang for details and downloads. /martin From bertietf@bwijnen.net Fri Feb 18 06:47:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7483A6DF3 for ; Fri, 18 Feb 2011 06:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 rSBDTDb2Bvmr for ; Fri, 18 Feb 2011 06:47:42 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 0A3E13A6DC6 for ; Fri, 18 Feb 2011 06:47:40 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PqRch-0007qg-TR for netconf@ietf.org; Fri, 18 Feb 2011 15:48:11 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PqRch-00074w-Bs for netconf@ietf.org; Fri, 18 Feb 2011 15:47:55 +0100 Message-ID: <4D5E869B.2070908@bwijnen.net> Date: Fri, 18 Feb 2011 15:47:55 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf References: <4D5557B1.6080104@bwijnen.net> In-Reply-To: <4D5557B1.6080104@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c75c9aed44df50c737c421aabdabc160 Subject: Re: [Netconf] Short WG Last Call: New Version draft-ietf-netconf-4741bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14:47:43 -0000 WG Last Call ended on the 17th. Since this WG LC, there was a quick rev to revision 09, because I (as document shepherd) found that the rfc2119 language was also put into non-normative appendix. So that was removed. Since then, there was one issue raised (about the malformed-message error tag. So we (WG chairs) conclude taht we have WG consensus on revision 09, with the following RFC-editor note: On page 87, OLD: error-tag: malformed-message error-type: rpc error-severity: error error-info: none Description: A message could not be handled because it failed to be parsed correctly. For example, the message is not well-formed XML or it uses an invalid character set. NEW: error-tag: malformed-message error-type: rpc error-severity: error error-info: none Description: A message could not be handled because it failed to be parsed correctly. For example, the message is not well-formed XML or it uses an invalid character set. This error-tag is new in :base:1.1 and MUST NOT be sent to old clients. I will hand the doc back into the hands of our AD for processing it in the IESG. Bert Wijnen Document shepherd On 2/11/11 4:37 PM, Bert (IETF) Wijnen wrote: > WG Members, please do a quick check on the new revision. > It is easiest of you look though the diffs at > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-08 > > The revision 08 is the result of the editors trying to resolve and address > all the IETF Last Call issues (they were all posted to this list last week). > > If you find that they made any fatal flaws in that process, pls let us (the > WG chairs and preferably also the WG mailing list) know by 17 Feb 2011. > > Bert Wijnen > Document Shepherd From bertietf@bwijnen.net Mon Feb 21 00:21:36 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7843A6FBE; Mon, 21 Feb 2011 00:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 SGXiU3wSSdbj; Mon, 21 Feb 2011 00:21:35 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 0F83A3A6FCE; Mon, 21 Feb 2011 00:21:32 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PrR23-0006mc-2y; Mon, 21 Feb 2011 09:22:12 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PrR22-0006Sn-QL; Mon, 21 Feb 2011 09:22:10 +0100 Message-ID: <4D6220B4.8000804@bwijnen.net> Date: Mon, 21 Feb 2011 09:22:12 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Rolf Winter References: <791AD3077F94194BB2BDD13565B6295D8ED1FC@DAPHNIS.office.hd> <4D4FDA85.8020508@bwijnen.net> In-Reply-To: <4D4FDA85.8020508@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4573d1a70b8c6d415d60061450489e0d1 Cc: "tsv-dir@ietf.org" , "tsv-area@ietf.org" , netconf , "draft-ietf-netconf-4741bis@tools.ietf.org" Subject: Re: [Netconf] tsv-dir review of draft-ietf-netconf-4741bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 08:21:36 -0000 Revision 9 is out and tries to address all IETF LX comments Here is the diff between the rev you reviewed and the latest one: http://tools.ietf.org/rfcdiff?url1=draft-ietf-netconf-4741bis-07&url2=draft-ietf-netconf-4741bis-09 Bert document shepherd On 2/7/11 12:41 PM, Bert (IETF) Wijnen wrote: > Thanks for your review and comments Rolf. > > All comments together are being considered by the editors and possibly will > result in a new revision. > > We'll keep you updated. > > Bert Wijnen > Document Shepherd > > On 2/4/11 1:37 PM, Rolf Winter wrote: >> Hi, >> >> I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These >> comments were written primarily for the transport area directors, but are copied to the document's authors for their information >> and to allow them to address any issues raised. The authors should consider this review together with any other last-call >> comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. >> >> This draft is basically ready for publication, but has nits that should be fixed before publication. There are no >> transport-related concerns that I could spot. >> >> Some nits: >> >> Section 2.1: second paragraph (below), second sentence doesn't parse quite right for me. Especially as the following sentence >> seems to imply the opposite. I read this as "The client can change things that cannot be changed" >> >> --> "NETCONF connections are long-lived, persisting between protocol >> operations. This allows the client to make changes to the state of >> the connection that will persist for the lifetime of the connection. >> For example, authentication information specified for a connection >> remains in effect until the connection is closed." >> >> You have "Authentication" in titles twice (in 2.2 and 2.3). Can do without in 2.2 as you dedicate a whole section on it. >> >> Section 2.2. "NETCONF connections must" is not a "MUST". Is this intentional (BTW, you don't mention integrity in the security >> considerations section any more). >> >> "NETCONF transport protocols therefore MUST explain how a NETCONF username is >> derived from the authentication mechanisms supported by the transport >> protocol." I read this as every transport protocol that NETCONF can run over (SSH e.g.) needs to specify this, but I think this >> is not what you require or even can ask for. But maybe I misunderstand the sentence. >> >> Regarding this error: >> enum operation-failed { >> description >> "Request could not be completed because the requested >> operation failed for some reason not covered by >> any other error condition."; >> } >> This is send if the XML is not well formed. Maybe you could dedicate a message to this that makes trouble shooting a little >> easier such as "XML-format-error" or something. >> >> That's about it. >> >> Best, >> >> Rolf >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Internet-Drafts@ietf.org Wed Feb 23 04:45:04 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0DC3A69E6; Wed, 23 Feb 2011 04:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 SBa48JBcuxDs; Wed, 23 Feb 2011 04:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06EF3A6875; Wed, 23 Feb 2011 04:45:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110223124503.19626.10897.idtracker@localhost> Date: Wed, 23 Feb 2011 04:45:03 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 12:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-rfc4742bis-07.txt Pages : 14 Date : 2011-02-23 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-rfc4742bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-23044015.I-D@ietf.org> --NextPart-- From mehmet.ersue@nsn.com Wed Feb 23 04:51:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57AD3A6875 for ; Wed, 23 Feb 2011 04:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Mr3u4NMMKwzi for ; Wed, 23 Feb 2011 04:51:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DA7AD3A67CC for ; Wed, 23 Feb 2011 04:51:30 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1NCqDgt031643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 13:52:13 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1NCqCnY012847; Wed, 23 Feb 2011 13:52:13 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 13:52:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 23 Feb 2011 13:52:06 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401AAA9A2@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4742bis Going to IESG Chat WAS:FW: New Version Notification for draft-ietf-netconf-rfc4742bis-07 Thread-Index: AcvTVu+tqxM3sDuGSoGw6UMk7azEygAAHS7Q From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" , "ext Margaret Wasserman" X-OriginalArrivalTime: 23 Feb 2011 12:52:07.0897 (UTC) FILETIME=[7AAD9490:01CBD358] Subject: [Netconf] 4742bis Going to IESG Chat WAS:FW: New Version Notification for draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 12:51:33 -0000 SGkgQWxsLA0KDQpJRVRGIExDIGZvciA0NzQyYmlzIGhhcyBmaW5pc2hlZCB3aXRoIG5vIGNvbW1l bnRzLg0KQWxzbyB0aGUgR2VuLUFSVCByZXZpZXdlciBzdGF0ZWQgdGhhdCB0aGUgZHJhZnQgaXMg cmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGEgc3RhbmRhcmRzIHRyYWNrIFJGQy4NCg0KQmVydCBh bmQgbXlzZWxmIGNhbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBicmluZ2luZyA0NzQxYmlzIGFu ZCA0NzQyYmlzIHRvZ2V0aGVyIHRvIHRoZSBJRVNHIGNoYXQgd291bGQgYmUgdGhlIG9wdGltdW0u DQoNCldlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uLCB3aGljaCBpbmNsdWRlcyB0aGUgcmVxdWVz dGVkIGV4dGVuc2lvbiB3aXRoIHRoZSBhcHBlbmRpeCBoaWdobGlnaHRpbmcgdGhlIGNoYW5nZXMg Y29tcGFyZWQgdG8gNDc0Mi4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1uZXRjb25mLXJmYzQ3NDJiaXMtMDcgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTA3LnR4dCANCg0KRGFuIHdpbGwgYnJp bmcgdGhlIGRvY3VtZW50IHRvIHRoZSBJRVNHIGNoYXQgb24gTWFyY2ggMywgMjAxMS4NCg0KVGhh bmsgeW91IE1hcmdhcmV0IGFuZCBhbGwgdG8gYnJpbmcgdGhlIGRyYWZ0IHNvIGZhci4NCg0KQ2hl ZXJzLCANCk1laG1ldCANCihkb2N1bWVudCBzaGVwaGVyZCkNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogZXh0IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlk c3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIzLCAyMDEx IDE6NDAgUE0NClRvOiBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQpDYzogbXJ3QHBh aW5sZXNzLXNlY3VyaXR5LmNvbTsgdGVkLmdvZGRhcmRAaWNlc29mdC5jb20NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzQ3NDJiaXMt MDcgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQy YmlzLTA3LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1laG1ldCBFcnN1 ZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt aWV0Zi1uZXRjb25mLXJmYzQ3NDJiaXMNClJldmlzaW9uOgkgMDcNClRpdGxlOgkJIFVzaW5nIHRo ZSBORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgb3ZlciBTZWN1cmUgU2hlbGwgKFNTSCkN CkNyZWF0aW9uX2RhdGU6CSAyMDExLTAyLTIzDQpXRyBJRDoJCSBuZXRjb25mDQpOdW1iZXJfb2Zf cGFnZXM6IDE0DQoNCkFic3RyYWN0Og0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2Qg Zm9yIGludm9raW5nIGFuZCBydW5uaW5nIHRoZSBORVRDT05GDQpwcm90b2NvbCB3aXRoaW4gYSBT ZWN1cmUgU2hlbGwgKFNTSCkgc2Vzc2lvbiBhcyBhbiBTU0ggc3Vic3lzdGVtLg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg==