From owner-netconf@ops.ietf.org Thu Dec 2 15:00:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22282 for ; Thu, 2 Dec 2004 15:00:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZwuN-000EpP-8n for netconf-data@psg.com; Thu, 02 Dec 2004 19:46:31 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZwuM-000EpC-If for netconf@ops.ietf.org; Thu, 02 Dec 2004 19:46:30 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2004 13:27:08 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB2IIPtX028735; Thu, 2 Dec 2004 13:18:26 -0500 (EST) Received: from sberl-w2k.cisco.com (sjc-vpn4-127.cisco.com [10.21.80.127]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZL92717; Thu, 2 Dec 2004 10:26:08 -0800 (PST) Message-Id: <4.3.2.7.2.20041202100905.03c47ec8@mira-sjcm-1.cisco.com> X-Sender: sberl@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Dec 2004 10:18:43 -0800 To: Andy Bierman , netconf@ops.ietf.org From: Steve Berl Subject: Re: Begin WG Last Call: draft-ietf-netconf-prot-04 In-Reply-To: <4.3.2.7.2.20041031090013.02b62948@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Not sure if anyone mentioned this yet, but the comments in the schema in appendix B are not valid XML. http://www.w3.org/TR/2004/REC-xml-20040204/#sec-comments specifies that "--" MUST not occur within comments. XMLSPY v5 also rejects these. Does the definition of rpcType, rpc-errorType, and rpc-replyType in the schema need to add an xs:anyType to allow for vendor specific extensions? If not what is the mechanism by which this schema can be extended to allow for vendor specific operations? -steve At 08:25 AM 10/31/2004, Andy Bierman wrote: >Hi, > >The NETCONF WG has completed work on the NETCONF Configuration >Protocol. The WG proposes that the Internet draft >'draft-ietf-netconf-prot-04.txt' is the completed version of >this document. This document can be found at: >http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-04.txt > >Abstract: > The NETCONF configuration protocol defined in this document provides > mechanisms to install, manipulate, and delete the configuration of > network devices. It uses an XML-based data encoding for the > configuration data as well as the protocol messages. The NETCONF > protocol operations are realized on top of a simple RPC layer. > >The WG members are strongly urged to review this document as >soon as possible, and express any concerns, or identify any errors, >in an email to the NETCONF WG mailing list. > >Unless there are strong objections, published on the NETCONF WG mailing >list by November 28, 2004, this document will be forwarded to the OPS >Area Directors for standards track consideration by the IESG. > >Please send all comments to the WG mailing list at netconf@ops.ietf.org. > >Andy and Simon > > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 3 16:56:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09837 for ; Fri, 3 Dec 2004 16:56:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CaLCR-000At0-RY for netconf-data@psg.com; Fri, 03 Dec 2004 21:42:47 +0000 Received: from [207.217.121.252] (helo=pop-a065d14.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CaLCM-000Asc-Mv for netconf@ops.ietf.org; Fri, 03 Dec 2004 21:42:42 +0000 Received: from h-66-167-206-184.snvacaid.dynamic.covad.net ([66.167.206.184] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CaLCF-0001nr-00; Fri, 03 Dec 2004 13:42:35 -0800 Message-ID: <015801c4d981$58eaadc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "netconf" References: <200412021235.HAA08915@ietf.org> Subject: Re: I-D ACTION:draft-montpetit-ipdvb-config-00.txt Date: Fri, 3 Dec 2004 13:45:03 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - Could you comment on how this protocol proposal differs from the work undertaken by the IETF netconf working group? Randy > From: > To: > Sent: Thursday, December 02, 2004 4:35 AM > Subject: I-D ACTION:draft-montpetit-ipdvb-config-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Protocols for MPEG-2 network configuration > Author(s) : M. Montpetit > Filename : draft-montpetit-ipdvb-config-00.txt > Pages : 9 > Date : 2004-12-1 > > This document describes novel protocols to bind IPv4/IPv6 > addresses and flows to MPEG-2 Transport Streams (TS). For MPEG-2 > systems to become true subnetworks of the general Internet, > methods are required to signal IPv4/v6 addresses to the link > receivers and transmitters; this is known as Address Resolution > (AR), or Neighbour Discovery (ND). In MPEG-2 networks, an IP > address must be associated with a Packet ID (PID) and specific > transmission multiplex. In this documents 2 mechanisms based on > standard XML semantics and multimedia signalling are introduced > to comply to established IP over DVB AR established. These > protocols are seen to complement the current approaches based on > SI table with a more IP centric approach. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-montpetit-ipdvb-config-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-montpetit-ipdvb-config-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-montpetit-ipdvb-config-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 8 09:09:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26653 for ; Wed, 8 Dec 2004 09:09:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cc2Kt-0005M4-L3 for netconf-data@psg.com; Wed, 08 Dec 2004 13:58:31 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cc2Kq-0005LX-IF for netconf@ops.ietf.org; Wed, 08 Dec 2004 13:58:28 +0000 Received: from [157.159.100.241] (MCI-050eb301d36.int-evry.fr [157.159.100.241]) by smtp2.int-evry.fr (Postfix) with ESMTP id 422B132264 for ; Wed, 8 Dec 2004 14:45:42 +0100 (CET) Message-ID: <41B704F6.5030109@int-evry.fr> Date: Wed, 08 Dec 2004 14:43:18 +0100 From: noe User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: question on queries Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-5.109, requis 4.5, autolearn=not spam, ALL_TRUSTED -3.30, AWL 0.14, BAYES_00 -2.60, RATWR10_MESSID 0.65) X-MailScanner-From: nejat_onay.erkose@int-evry.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello everyone, In revision 4 of the netconf draft from part 6.8.3 thrrough 7.0 all examples have the structure like the one below: Shouldn't there be a source element to indicate source file, after get-config element ? -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 9 20:48:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08464 for ; Thu, 9 Dec 2004 20:48:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CcZhv-00080T-8J for netconf-data@psg.com; Fri, 10 Dec 2004 01:36:31 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CcZhs-00080A-BJ for netconf@ops.ietf.org; Fri, 10 Dec 2004 01:36:28 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBA1aQMa016867 for ; Thu, 9 Dec 2004 19:36:26 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Dec 2004 02:36:25 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505E0D0E7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Last Call: 'The Extensible Markup Language (XML) Configuratio n Access Protocol (XCAP)' to Proposed Standard Date: Fri, 10 Dec 2004 02:36:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk I ahve not looked at this document yet. But the title/abstract sounds as if we may want to check it. Bert -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org]On Behalf Of The IESG Sent: Thursday, December 09, 2004 16:27 To: IETF-Announce Cc: simple@ietf.org Subject: Last Call: 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)' to Proposed Standard The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 10 02:49:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19507 for ; Fri, 10 Dec 2004 02:49:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CcfN9-000J1G-Cs for netconf-data@psg.com; Fri, 10 Dec 2004 07:39:27 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CcfN5-000J0w-UC for netconf@ops.ietf.org; Fri, 10 Dec 2004 07:39:24 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9F3743798; Fri, 10 Dec 2004 08:39:22 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09968-05; Fri, 10 Dec 2004 08:39:21 +0100 (CET) Received: from james (Ib8e8.i.pppool.de [85.73.184.232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 834FA3792; Fri, 10 Dec 2004 08:39:21 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CcfN3-0000j4-4t; Fri, 10 Dec 2004 08:39:21 +0100 Date: Fri, 10 Dec 2004 08:39:20 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Cc: "Netconf (E-mail)" Subject: Re: FW: Last Call: 'The Extensible Markup Language (XML) Configuratio n Access Protocol (XCAP)' to Proposed Standard Message-ID: <20041210073920.GB2262@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Wijnen, Bert (Bert)" , "Netconf (E-mail)" References: <7D5D48D2CAA3D84C813F5B154F43B15505E0D0E7@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15505E0D0E7@nl0006exch001u.nl.lucent.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Dec 10, 2004 at 02:36:23AM +0100, Wijnen, Bert (Bert) wrote: > I ahve not looked at this document yet. > But the title/abstract sounds as if we may want to check it. I referred earlier to this piece of work since it is very related to what netconf is doing and they use a so called node selector which is a subset of full XPath (and I mentioned this while we were working through the issue of XPath support within NETCONF). So yes, I consider this related work (as much as I consider the EPP related work). However, things differ quite a bit in the details and have different community background. Over time, I have learned that having multiple approaches to solve related problems but which take the specifics into account is not necessarily a bad thing. XCAP is designed to access configurations of a certain set of applications which netconf focusses on network devices mainly. There are differences between these spaces and so there may be differences between the approaches. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 10 17:33:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04331 for ; Fri, 10 Dec 2004 17:33:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CctCF-000GpK-K4 for netconf-data@psg.com; Fri, 10 Dec 2004 22:25:07 +0000 Received: from [144.189.100.102] (helo=motgate4.mot.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CctCB-000Gnj-51 for netconf@ops.ietf.org; Fri, 10 Dec 2004 22:25:03 +0000 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id iBAMRU6D003390 for ; Fri, 10 Dec 2004 15:27:31 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iBAMNZrT008469 for ; Fri, 10 Dec 2004 16:23:37 -0600 Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id iBAMOttv014686; Fri, 10 Dec 2004 16:24:55 -0600 (CST) Received: from motorola.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTPA id <0I8J00LJY29JHL@ims1.labs.mot.com>; Fri, 10 Dec 2004 16:24:55 -0600 (CST) Date: Fri, 10 Dec 2004 16:24:54 -0600 From: Sandeep Adwankar Subject: Re: FW: Last Call: 'The Extensible Markup Language (XML) Configuratio nAccess Protocol (XCAP)' to Proposed Standard To: "Wijnen, Bert (Bert)" Cc: "Netconf (E-mail)" Message-id: <41BA2236.45B7AA0E@motorola.com> Organization: Motorola Labs MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <7D5D48D2CAA3D84C813F5B154F43B15505E0D0E7@nl0006exch001u.nl.lucent.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT This protocol relies on HTTP-based semantics. Seems similar to "REST"? http://dsonline.computer.org/0412/d/oz001a.htm http://www.xml.com/pub/a/ws/2002/02/20/rest.html?page=1 --Sandeep "Wijnen, Bert (Bert)" wrote: > I ahve not looked at this document yet. > But the title/abstract sounds as if we may want to check it. > > Bert > > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org]On Behalf Of The IESG > Sent: Thursday, December 09, 2004 16:27 > To: IETF-Announce > Cc: simple@ietf.org > Subject: Last Call: 'The Extensible Markup Language (XML) Configuration > Access Protocol (XCAP)' to Proposed Standard > > The IESG has received a request from the SIP for Instant Messaging and > Presence Leveraging Extensions WG to consider the following document: > > - 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) ' > 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 any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 13 12:45:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01947 for ; Mon, 13 Dec 2004 12:45:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CdtxL-000GYM-0Q for netconf-data@psg.com; Mon, 13 Dec 2004 17:25:55 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CdtxA-000GXF-Cy for netconf@ops.ietf.org; Mon, 13 Dec 2004 17:25:44 +0000 Received: from [157.159.43.101] (noe.maisel.int-evry.fr [157.159.43.101]) by smtp2.int-evry.fr (Postfix) with ESMTP id EBE4E304EE for ; Mon, 13 Dec 2004 18:24:10 +0100 (CET) Message-ID: <41BDCF98.9090802@int-evry.fr> Date: Mon, 13 Dec 2004 18:21:28 +0100 From: noe User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: edit-config Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-5.088, requis 4.5, autolearn=not spam, ALL_TRUSTED -3.30, AWL 0.17, BAYES_00 -2.60, RATWR10_MESSID 0.65) X-MailScanner-From: nejat_onay.erkose@int-evry.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, I couldn't understand something about "operation" attribute in edit-config request,revision 4 page 28. That is, when there is no "operation" attrb. we should merge the data with the "target file" from the corresponding level. That is a default behaviour. However in the example after the explanation , if i am not wrong ,we are again replacing the value of "mtu" under the interface element. Shouldn't we here add a new interface into the taget configuration ? "If the operation attribute is not specified, the configuration is merged into the configuration datastore. The operation attribute has one of the following values: merge: The configuration data identified by the element containing this attribute is merged with the configuration at the corresponding level in the configuration datastore identified by the target parameter. This is the default behavior. " Example: Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration: Ethernet0/0 1500 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 13 23:22:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27775 for ; Mon, 13 Dec 2004 23:22:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ce3zm-000BwM-08 for netconf-data@psg.com; Tue, 14 Dec 2004 04:09:06 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ce3zg-000Bun-VQ for netconf@ops.ietf.org; Tue, 14 Dec 2004 04:09:01 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2004 21:15:26 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBE48uVw014800 for ; Mon, 13 Dec 2004 20:08:56 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn2-668.cisco.com [10.21.114.156]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBX18380; Mon, 13 Dec 2004 20:08:58 -0800 (PST) Message-Id: <4.3.2.7.2.20041213200054.01f30548@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Dec 2004 20:08:57 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: End WG Last Call: draft-ietf-netconf-prot-04 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The first WG Last Call for the NETCONF Configuration Protocol document is now concluded. I'd like to thank the numerous WG members who reviewed the document and sent comments to the mailing list. The WGLC for the application mappings documents will remain open a bit longer since they have not been widely reviewed yet. A number of issues and clarifications were raised during the review period. The following lists identify these issues (Innn) and clarifications (Cnnn) for further comment. The WG must now resolve any remaining issues on the WG mailing list, so an updated draft can be finished ASAP. [ed. - The lists have not been scrubbed or entered into an issue tracking system. Please send separate emails for each issue, and use the issue (or clarification) ID number in the subject line. thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 13 23:24:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28019 for ; Mon, 13 Dec 2004 23:24:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ce43r-000CWO-Q1 for netconf-data@psg.com; Tue, 14 Dec 2004 04:13:19 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ce43m-000CVt-1q for netconf@ops.ietf.org; Tue, 14 Dec 2004 04:13:14 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2004 21:19:38 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBE4DBsv014305 for ; Mon, 13 Dec 2004 20:13:12 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn2-668.cisco.com [10.21.114.156]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBX18511; Mon, 13 Dec 2004 20:13:09 -0800 (PST) Message-Id: <4.3.2.7.2.20041213201055.0252a650@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Dec 2004 20:13:09 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: End WG Last Call: draft-ietf-netconf-prot-04.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_763601380==_" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --=====================_763601380==_ Content-Type: text/plain; charset="us-ascii" Hi, The first WG Last Call for the NETCONF Configuration Protocol document is now concluded. I'd like to thank the numerous WG members who reviewed the document and sent comments to the mailing list. The WGLC for the application mappings documents will remain open a bit longer since they have not been widely reviewed yet. A number of issues and clarifications were raised during the review period. The following lists identify these issues (Innn) and clarifications (Cnnn) for further comment. The WG must now resolve any remaining issues on the WG mailing list, so an updated draft can be finished ASAP. [ed. - The lists have not been scrubbed or entered into an issue tracking system yet.] Please send separate emails for each issue, and use the issue (or clarification) ID number in the subject line. thanks, Andy --=====================_763601380==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="prot_issues.txt" I001) Locking) 4 emails supporting requirement to allow get and get-config even if the confitg is locked. -------------------------- I002) Session ID) How is this conveyed to the client? -------------------------- I003) 1.1: "MUST support at least one, and MAY support more than one." For security I'd really rather see the MAY be a SHOULD in that sentence. -------------------------- I004) 4.5: pipelining: " request are processed serially" This should be a MUST. Doing otherwise leads to indeterminate results. --------------------------- I005) section 6: I don't think this section is ready to go to the IESG yet. It needs more review and editing. --------------------------- I006) section 6: I have a few concerns about the filtering as defined. 1) I find it confusing that there is a subtle difference between selection of a particular set of values vs selecting a particular value. The difference between: and John Is very very subtle. Definable, certainly, but subtle as well. This means people will get it wrong and get confused (especially for more complex examples). 2) I don't think it's possible using the current filter system to select empty values. IE, this: Will select all user's names, not a user with a blank name. (please don't tell me you're going to distinguish between and ) 3) logical and vs logical or in selections In the document this example: root fred barney superuser Indicates that there is an implicit logical OR between the tags and an implicit logical AND between the sub-tags (name/type in the third user selection). This is, again, subtle and subject to poor understanding by users which will lead to errors. One solution to some of these problems would be to separate the selected nodes from the value matched nodes using different groups. Or add an attribute or something. Anything that makes it more obvious what is going on and is desired. ----------------------- I007) 7.2: default-operation: none... "as well allowing a simple existence test for configuration data". This statement should be stricken, IMHO. If you want an existence test, you should write one into the protocol (get-config will do this now). I don't think you should cobble in a feature this way. It may be that it exists and can be used this way, but I don't think documenting it this way so it becomes officially supported practice is wise. ------------------------- I008) 7.2 and others: Is it legal to specify config for non-existent devices. IE, can I upload a config for a interface which I haven't physically inserted yet? Or is this going to be implementation specific? It should be at least mentioned one way or another. -------------------------- I009) 7.2: I fail to see how these operations are going to work in some cases which I'm sure will come up in the future. I'm going to use the examples enclosed in the section, but I don't think they're necessarily the right ones to use. But you'll get the idea. The problem comes from the assumption of the data model that I'm not convinced will be true. Take the case of messing with an interface. The examples all show various operations working on an interface named "Ethernet0/0", and only in the sentences above is it sort-of-mentioned in English text that the index when searching for things to modify are going to be based on the name. There is no mention of this actually in the protocol. Sure, in this particular case it is likely this may be the only selectable method in the resulting data model and that is yet to be determined and out of scope. However, I think it is highly likely that we will end up with a data model(s) that will allow for separate indexes. So, for the purposes of example, lets say that you could select an interface by address as well (very conceivable). Is this legal for a replace: 1500
1.2.3.4
Would that allow you to replace the MTU just as you would if you specified the name? Or are you going to restrict data models in the future to only one set of unique indexes? Can I set the MTU of all interfaces which are up using something like: up 1500 This is a solvable problem, obviously. My only concern is that no where is this type of usage of the protocol discussed. It does have implications on the resulting data models that are allowed to be defined. Fundamentally, this results from data to change and selectors being intermixed, which technically I think is a mistake (they should be marked by attributes or in a special section of the tree. I'm sure that concept will die a horrible death and I'll get flamed for mentioning it. So, let me just end by repeating: it needs discussion regardless if you don't want to explicitly talk about how to select particular values. -------------------- I010) 7.2 replace: what happens if you replace a container with a set of elements (say A, B, and C) but the original object also contained a D element. Does the new one get D as well, or is that nuked (I think is the case) if operation=replace is put on the high level object (as opposed to each element for A B and C). -------------------- I011) 7.3 copy from remote to remote is a "may choose not to support". I think this is fundamentally a bad thing to ever allow. netconf should not be a file transfer protocol. The security issues surrounding such a notion haven't been discussed. You can't easily specify access control rights for when you're allowed to do so. It essentially lets any firewall implementing netconf (that implements URL to URL copying and has access to both an internal and external network) to be used as a transfer hole in a security domain. I really think you should say that implementations MUST NOT support this. It is well beyond the scope of what netconf should do. It is highly suspect from a security point of view and will only add more work in the future as you'll have to write access control rights for when this is acceptable and when it is not and by what users. -------------------- I012) 7.3 example shows the use of ftp. Can we use something more secure in the example please? -------------------- I013) 7.4: #url allows a url to appear as a delete. doing remote file management using netconf is questionable at best. From a security point of view, it makes me cringe. -------------------- I014) 8.8.5.1: so with #url capability supporting ftp I can force a netconf client to remote edit files? Is this really wise? -------------------- I015) url summary: there are two types of urls: local and remote. Some operations make sense for some of those, some for others. Some operations, IMHO, should not be allowed on remote types. -------------------- I016) 9: Implementators SHOULD also provide a well thought out authorization scheme with NETCONF. => MUST -------------------- I017) 9: you need to discuss that global operations MUST disallow the changing of information that an individual does not have authorization to perform. EG, if a user U is not allowed to configure an IP address on an interface but someone else has configured an IP address for an interface within the , then the user U must not be allowed to perform a copy-config or commit from to . -------------------- I018) 9: Similarly, you need to discuss what happens if you don't use a lock. Specifically, if user U1 modifies the candidate config in a way that user U2 is not allowed to, and since U1 MUST NOT be able to commit those changes then not using a lock could leave a system in a state where neither U1 nor U2 can commit their changes to running. -------------------- I019) Commit operation atomicity [PROT, missing section number] Proposed change: If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration must remain unchanged. Response: Capital "'MUST' remain unchanged" and I'm happy with the wording. -------------------- I020) d) The description of the error-info states that vendor specific elements may only be added at the end of the sequence. I do not really see the need for this rule since namespaces should be used anyway. I would prefer to not introduce such rules, the specification should instead spell out that any extensions/additions must have their own namespace. -------------------- I021) g) I had some trouble to figure out what RPC responses can contain. Section 4.4 says that an element is sent in messages if no error occurred. Looking at the examples shown later on, it looks like is only present if the RPC was successful and no other result data was returned. I am not sure why this is needed at all. Things get a bit more irritating if I look at the elements. Such an element is used to signal an error or a warning. This raises the question whether a warning can be returned even though the RPC succeeds. Will I then get or followed by an signalling a warning? Or will the warning come first? If the RPC does not abort on error, I would suggest that I can get multiple errors. But this does not seem to be the case (according to the NETCONF RelaxNG spec.) The RelaxNG spec (did not check the xsd) requires the element to be while section 4.2 shows an example which shows . If the idea is indeed that RPC results always show up in a element, then why not replace with an empty element? I recall some discussion that errors/warnings may actually be generated while an operation is processed and that they were even supposed at some point to interleave the data portion. So I assume there is something missing here. Perhaps the examples used later in the document focus too much on the no error cases. -------------------- I022) r) Section 7.1 IMHO misses text which explain how overlapping operation attributes are handled. What for example happens if I have: <... operation="delete"> <... operation="merge"/> There might be more interesting combinations. I would prefer to have well defined rules so that all implementors do the same thing here. If there are nested operation attribute value combinations that do not make sense, I think it would be fair to request that such things are checked before starting the execution of the merge. -------------------- I023) t) After reading the part of the spec, I felt that there is in general a need to have more elements of the procedure spelled out. I think it would help implementors tremendously if it were spelled out which tests have to be performed, what the error codes are that can be generated and so on. At the moment, the document leaves it to the implementor to figure out what needs to be checked, in which order, before are while processing an edit-config and so on. I believe it would help interoperability if some more guidance would be given here. -------------------- I024) E) Section 8.8.3 says shows the following urn format: urn:ietf:params:xml:ns:netconf:base:1.0#url?protocol={protocol-name,...} It is unclear what are meta characters here. I guess '{' and '}' are meta characters if I look at the subsequent examples. Anyway, the more general comment here is that you identity URI schemes and not protocols. So perhaps the example should be: urn:ietf:params:xml:ns:netconf:base:1.0#url?schemes=http,ftp,file Perhaps life would be even easier if the schemes were announce as separate capabilities: urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=http urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=ftp urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=file Perhaps a general discussion how to deal with parameters in capabilties would be useful. The later version has the advantage that I do not have to parse the full scheme to check whether the 'file' scheme is supported - a simle string match is good enough. (But parsing this on the other hand does not seem overly complex either). --=====================_763601380==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="clarifications.txt" ----------------------- C001) BEEP, sec. 2.5 BEEP Profile for NETCONF There are three commands in the BEEP profile. and . s/three/two -------------------------- C002) PROT, new sec. add deferred features list appendix ----------------------------- C003) PROT, remove sec. remove the netconf-state data model and all references to it --------------------------- C004) PROT, sec. 9 9. Security Considerations This standard does not specify an authorization scheme, as such a I think it is better to say This document does not specify .... --------------------------- C005) 1.1: "during any session" -> "during any authorized session" --------------------------- C006) 1.1: "Session specific attributes affect only the session in which they are changed." It'll likely be possible to change attributes of a "target" session? (kill-session is almost changing attributes, but I could see other more true changes being allowed in the future). --------------------------- C007) 1.1: for the application stack diagram, it'd be helpful if you added the stack numbers in the left hand box to match the numbers below. The first time I looked at it, it took a sec to realize the numbered list below was counting bottom up. --------------------------- C008) 1.2: "These capabilities must" -> MUST? (actually this sentence is somewhat redundant with the first, but I'm not complaining) --------------------------- C009) 1.2: "The capability URI" -> "A capability URI" --------------------------- C010) 1.3: The document in general discusses configuration and state. Discussions within the IETF in the last number of years has included "control" objects as well. I'd at least mention them, even if you are either excluding them or lumping them in to the other category. --------------------------- C011) 1.3: "file would be too large" -> remove "too". subjective. Maybe "unnecessarily" would be a better choice. --------------------------- C012) 1.3: "Note that the NETCONF protocol is concerned only with information required to get the system software into its desired running state." This is not true. state information retrieval has already been defined (and even contracts earlier sentences about "state"). --------------------------- C013) 1.3: "If a local database of user authentication..." I'd say this sentence is beyond scope of the document. You're talking about the data model here. --------------------------- C014) 2.1: last p: reference the future "lock" section near the lock word. --------------------------- C015) 2.2: Security and Privacy is an indeterminate title. How about "Security, Authentication and Integrity" instead? --------------------------- C016) 2.3: Authentication: "...entity can be trusted." -> "identity has been sufficiently proven". Trust is not implied at all by merely authentication. --------------------------- C017) 2.3: "should use RADIUS" -> "should allow the use of RADIUS" --------------------------- C018) 2.3: "whose permissions and capabilities are know" -> "whose permissions are known". Authentication has nothing to do with capability negotiation. I actually think better wording could be used in this paragraph in general. Something that says based on the authentication it should be possible to determine the authorization level of the incoming session (it's 5:30AM. I can't think of better wording at the moment) --------------------------- C019) somewhere: A brief intro on http vs urn's in the xmlns tags should be mentioned somewhere so the reader understands why one is used in some places and not in others. --------------------------- C020) 4.1, last example: "example.net/house" -> "example.net/world" --------------------------- C021) 4.3 "The includes" should this be a MUST? --------------------------- C022) 4.3 error-tag: ... See list below for allowed values -> see appendix A --------------------------- C023) 4.3: error-message: "the error condition." -> "the error condition intended for human consumption." (IE, don't expect it to be machine parsible). --------------------------- C024) 4.3: error-info: the list below -> the list in appendex A --------------------------- C025) 5.1: I'd be tempted to say that though some netconf operations work on things like state, they're not considered to be part of the configuration datastore --------------------------- C026) 5.1: Section 8.3 and Section 8.7 -> "Capability sections 8.3 and 8.7" for clarity. --------------------------- C027) 6.1-6.3: various parts of 6.2 and 6.3 are very redundant with 6.1. EG: last P in 6.2 is same as 4th in 6.1, 6.3 is the 5th P in 6.1... Most of the text could use a bit of clean-up. It doesn't read as well as the rest of the document (which is very well written, so my expectations have come to be a bit high at this point). --------------------------- C028) 6 general: A diagram to help match terminology against parameters would be helpful up front. By the end of the section, my head was spinning with all the terms regarding matching nodes vs leaves vs .... --------------------------- C029) 6.1 last p: "or modified or acted upon?" somewhere for operations that don't just "select"? --------------------------- C030) 6.5: "the only the content match nodes, plus"... remove "only" --------------------------- C031) 6.6: This section probably needs to be rewritten. I could barely grok it after staring at it for a while. --------------------------- C032) 6.7: agent -> server. (I don't think the rest of the doc talks about "agent"s much. I may be wrong). --------------------------- C033) 6.8.2: type=subtree should be mentioned above somewhere first ideally (I know it's mentioned later) --------------------------- C034) 6.8.3: The node used in the examples worries me. Is each standard/company going to define its own "top"? --------------------------- C035) 6.8.6: siibling -> sibling --------------------------- C036) 6.8.8: schema/2.0 -> schema/1.2 --------------------------- C037) 6.8.8: "same results" -> "similar results". The results won't be exactly identical, right? --------------------------- C038) 7: move the "get" operation up the list under the "get-config" operation for better grouping. --------------------------- C039) 7: is "operation not supported" allowed even for the netconf core operations? I'm not sure there is requirements anywhere (MUST/SHOULD) for the operational sets that are required to be implemented (simply defining them doesn't state requirement for implementing them). --------------------------- C040) 7.1: get-config requires? the source parameter. If so, many of the (previous, eg) examples don't contain it. --------------------------- C041) 7.1: positive response: says element returned is contained within but many of the examples fail to meet this (frequently they use "data" including in the example in this section!) --------------------------- C042) 7.2: "The target configuration is not simply" -> "... not necessarily simply" --------------------------- C043) 7.2: should probably mention that the operation tag is allowed to be used repeatedly in the tree? It's only sort "sort of" obvious. --------------------------- C044) 7.2 replace/create: It would be useful to explicitly talk about how "containers" (eg users) vs "objects" (a user) is treated with this. IE, if operation=replace is specified at the users level, then *all* the users are replaced. If specified at the user level, then just a single user is replaced. This is important for the reader to understand. --------------------------- C045) 7 general: it would be useful if potential error codes were specified in the operation lists... Right now its sort of open in many places. --------------------------- C046) 7.2 delete: what happens if you do this: Fred That'll just delete the name, technically, not the user. Is that legal? This is where a protocol without a data-model usage case runs into problems. The concept of containers is important when talking about operations that affect instances of those containers. --------------------------- C047) 7.2 replace: Can I do a name change on the search index? IE, if the interface name is configurable can I change it? There is no operation to support this thus I must do a delete and create (or equivelent), right? --------------------------- C048) 7.2 delete: can I delete all interfaces with MTU of 1500? Does multiple matches in a data model that may not have defined MTU as a unique index allowed within the protocol? --------------------------- C049) 7.2 "Delete the interface" -> "Delete the configuration for the interface". --------------------------- C050) 7.3 "Otherwise, a new one is created" -> "Otherwise, a new one is created if allowed." --------------------------- C051) 7.3 "A device may choose not to support remote to remote copy operations" -> add "(URL to URL)". (though see my other message on the concern with this first). --------------------------- C052) 7.5 "human users" -> "console users" --------------------------- C053) 7.5: delete "lack of network connectivity". Let the transport deal with that. If the transport looses it, thats a valid signal. I don't think netconf should be directly tied to a lower level than the transport. --------------------------- C054) 7.5: "If the lock is already held, the element will be LOCK_DENIED": It'd be better to distinguish between denied due to access not allowed vs denied vs in-use by someone else. --------------------------- C055) 7.5: most of the other examples have wording separation between them. This section doesn't so I'd recommend adding "Example showing an error when a lock is already in use:" in between the two examples for better readability. --------------------------- C056) 7.7: examples don't contain the node that others do. This is inconsistent throughout the doc. I just wrote it down here. --------------------------- C057) 7.8: need to mention that replies to previous queries are still sent. (processing is mentioned, but not the replies to those operations) --------------------------- C058) 8: "... standards bodies or published as proprietary by vendors" -> add "etc, ..." or something at the end. Current wording is too limiting to the types of organizations that are likely to publish specs. --------------------------- C059) 8: it is not clear from the sentences why you specified two urns (one with an embedded xml:ns tag and one without). --------------------------- C060) 8: "each peer needs to understand only those capabilities that it might use..." This is not entirely true for #validate. It affects the results of the on-error parameter if available. In some cases you'll potentially get errors back and in others not. Sort of requires that you understand if the capability is there so you can prepare for or expect errors back. Not sure you want to change anything though. --------------------------- C061) 8.3.1: "creating a manipulating" -> creating and manipulating --------------------------- C062) 8.3.1: I'd use a specific example operation in the example for "operation" rather than the generic term. It doesn't match the rest of the examples in the document by making it generic. --------------------------- C063) 8.3.1: for example, through another capability: Add "EG, lock") --------------------------- C064) 8.3.4.1: why doesn't the text refer to "" here? A commit is really a copy-config from to even if #writable-running isn't available and thus I'd make that statement so the understanding is clear. --------------------------- C065) 8.3.4.2: I'd state that discard-changes is essentially a copy from running to candidate. --------------------------- C066) 8.4.5.1: confirmed-timeout: please please please at least use seconds rather than minutes here. You're making an assumption about operational environments. seconds allows for rapid decisions, but still allows for longer time periods as well (2^32 seconds is a long time). --------------------------- C067) 8.5.1: "to be inadvertently altered or removed": This isn't true is it? Isn't the roll back only applied to the current operation? IE, a single edit-config in which case it is only rolled back to the start of the edit-config and has nothing to do with what other people have done either before or after the current operation? --------------------------- C068) 8.6.1: "at least for syntax errors". So the exact operation results are indeterminate? Some devices do something things with this capability and others do others. --------------------------- C069) 8.7.1: if startup == running in the rest of the document without this capability, it should probably be mentioned before this point when first discussing running. --------------------------- C070) 8.9.5.1: example needs top too? --------------------------- C071) 7.7: get should explicitly specify that it only works on running? --------------------------- C072) 7.5: second bullet: committed -> committed or rolled back --------------------------- C073) 1. The Abstract section includes acronyms that would better be expanded (XML, RPC) --------------------------- C074) 2. Section 1.3 - ' Note that the NETCONF protocol is concerned only with information required to get the system software into its desired running state.' Isn't this too limiting? Are other aspects of device configuration really excluded, or should we rather say ' Note that the NETCONF protocol is concerned only with information required to get the device behavior into its desired state (for example getting the system software into its desired running state).'? Response: What about changing "system software" to "device" in this sentence (I agree with you but want a shorter sentence): Note that the NETCONF protocol is concerned only with information required to get the device into its desired running state. --------------------------- C075) 3. No DTDs - The introduction says 'The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange. while secttion 3.2 dully specifies that ' Document type declarations (DTDs) are not permitted to appear in NETCONF content.' Is not this a contradiction? Response: The "No DTDs" restriction means that DTDs are not allowed to be embedded directly inside NETCONF content. Embedded DTDs are an official feature of XML that nobody seems to use these days, as they are awkward and not useful or desirable in NETCONF (we don't want to require a NETCONF entity to be able to parse DTDs, for one thing). The use of DTDs themselves to describe XML content that could be used with NETCONF is fine. --------------------------- C076) 4. Section 7.5 - what is an 'Expect script'? From http://expect.nist.gov/ - "Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really makes this stuff trivial. Expect is also useful for testing these same applications. [...]" Proposed terminology change: Expect scripts -> CLI scripts --------------------------- C077) 5. Section 9, second paragraph - what means 'unbnownest'? This appears to be a misspelling of the word "unbeknownst", a dictionary entry for which appears below. --------------------------- C078) a) The introduction makes the promise that "applications can access both the syntactic and semantic content of the device's native user interface" via NETCONF. I think this promise is a bit too strong. --------------------------- C079) b) I never liked the replacement of "transport protocol" with "application protocol" - I think the later term is even more confusing as the original term "transport protocol". Note that I found a few places where the document still refers to the "transport" (just search for it). (Transport is used in the error reporting mechanism, see the ErrorType definition. Replacing transport here with application would clearly cause confusion.) As said above, I prefer the reintroduction of the term "transport" or even "NETCONF transport" with an explanation in section 1 that transport in this document refers to the NETCONF transport, which is not the same as a transport layer protocol. --------------------------- C080) c) Section 4.3, error-tag description should refer to appendix A as follows: error-tag: String identifying the error condition. See Appendix A for allowed values. --------------------------- C081) e) I prefer "implementor" over "vendor", "implementation-specific" over "vendor-specific" and so on. This affects several places (just search for vendor). --------------------------- C082) f) Is there any reason why error tags are ALL_CAPS and use underscores while the other XML elements all use hyphens and lowercase? --------------------------- C083) h) page 15: replace "an XSD" with "a schema". --------------------------- C084) i) page 17: "...containment nodes the element hierarchy..." -> "...containment nodes of the element hierarchy..." --------------------------- C085) j) page 18: "...get request..." -> "...get operation..." --------------------------- C086) k) page 19: "...the filter This..." -> "...the filter. This..." --------------------------- C087) l) page 22: "...siibling..." -> "...sibling..." --------------------------- C088) m) The title of section 6.8.8 should be changed to "Elements with attribute naming" or something similar since NETCONF does not deal with tables. --------------------------- C089) n) The first paragraph in section 6.8.8 refers to 'schema/2.0' while the example uses 'schema/1.2'. --------------------------- C090) o) Section 7.1 says under "Positive Response" that the reply contains a element which I think must be a element. --------------------------- C091) p) The description of test-option in section 7.2 says it can take two values while the xsd says it can take three values. --------------------------- C092) q) Section 7.1 on page describes rollback-on-error which is however not mentioned in the xsd. --------------------------- C093) s) Example on page 32: I suggest to replace 255.0.0.0 with 24 as this seems to be the more general concept. --------------------------- C094) u) Section 7.3 says: "The source and target parameters cannot identify the same URL or configuration datastore." Why not say which error code is being returned in this case and that it when this must be checked? [This is kind of an example for comment t) shown above.] --------------------------- C095) v) page 36: "...Expect scripts..." -> "...CLI scripts..." --------------------------- C096) w) Section 7.5, star bullet two on page 37: Does this only apply if the commit capability is present? --------------------------- C097) x) There are several XML lines which exceed the allowed column number are require some re-formatting. --------------------------- C098) y) Section 7.7 refers to configuration and state data without saying which configuration source is meant here. I assume it is the configuration data set. Perhaps this should be made clear somewhere. --------------------------- C099) y) Section 7.9 refers to a 'Bad Value' error, which does not seem to exist. --------------------------- C100) z) page 44: "...proprietary vendors." -> "...proprietary extensions." --------------------------- C101) A) Section 8.3.4.1: I assume it copies to - perhaps this should be spelled out. --------------------------- C102) B) I was wondering what the difference is between the #candidate and just a named file://candidate scratch buffer, e.g. lock running lock file://candidate copy running file://candidate edit file://candidate ... copy file://candidate running unlock file://candidate unlock running Perhaps it is the locking? In the example in Appendix D, only the is locked - does that imply a lock on candidate as well as it is somehow magically tied to ? (And is it magically tied to ?) Some more explanation might be worthwhile (perhaps in the appendix). I would find it useful to know whether there are any real differences here. If there are no real differences, why do we have two different ways to achieve the same thing? --------------------------- C103) C) Section 8.4.5.1 talks about "a confirming commit" without really saying what that is. I think the example should be extended to show a confirming commit. (Right now, one has to look into the appendix where you can find an example. It looks like the confirming commit is a plain commit without the element. This raises the question if it is possible to extend a confirmed commit by just sending another confirmed commit before the timer goes off. --------------------------- C104) D) Section 8.6.4.1 uses the datastore to illustrate the operation. Since is an optional feature, would it not make more sense to choose a data store that is always present? Or does #validate not make sense if there is no #startup, no #candidate and no #url capability? --------------------------- C105) F) page 56: "...SHOULD also provide..." -> "...SHOULD provide..." --------------------------- C106) G) page 56: "...incompatable." -> "...incompatible." --------------------------- C107) H) page 57: "...person in the middle..." -> "...eavesdropping..." (I don't think you have to be in the middle of the communication to simply listed to the conversation.) --------------------------- C108) I) Section 10 needs to spell out the registration rules for the urn namespace that netconf is using I think. --------------------------- C109) J) Reference [4] is not cited so it can't be normative. --------------------------- C110) K) References [9], [10] and [11] are not cited. --------------------------- C111) L) Appendix D assumes that either #candidate or #url?scheme=file is present. Does it meant without these capabilities, you are seriously restricted in the sense that you can't have a robust scheme to configure multiple devices? If yes, this probably needs to be spelled out somewhere clearly so that implementors understand which capabilities are important and for what reason. --------------------------- C112) M) page 72: incomplete sentence "...unrelated changes while." --------------------------- C113) N) page 77: "...the first class of allows..." -> "...the first class allows..." --=====================_763601380==_-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 14 08:13:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23023 for ; Tue, 14 Dec 2004 08:13:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeCFR-000OHB-Qo for netconf-data@psg.com; Tue, 14 Dec 2004 12:57:49 +0000 Received: from [62.24.64.34] (helo=smtp.dkm.cz) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CeCFF-000OFI-64 for netconf@ops.ietf.org; Tue, 14 Dec 2004 12:57:37 +0000 Received: (qmail 20165 invoked by uid 0); 14 Dec 2004 12:57:35 -0000 Received: from r2ay85.chello.upc.cz (HELO ?192.168.1.2?) (62.245.114.85) by smtp.dkm.cz with SMTP; 14 Dec 2004 12:57:35 -0000 Message-ID: <41BEE33F.6040503@fi.muni.cz> Date: Tue, 14 Dec 2004 13:57:35 +0100 From: Ondrej Zlosky User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: RELAX NG Schema for NETCONF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I'm sorry that this is not "true" reply but I subscribed now and can use only messages from web archive. > Here is a RELAX NG schema for the NETCONF protocol. > It's not any shorter than the XSD that appears in the draft, > but it's somewhat easier to understand at first glance (imho). > The protocol examples in the -04 draft have all been validated > against this schema. I was testing this Relax NG scheme and it looks ok. I propose few improvements because I think that next changes better cover ietf netconf draft. Please, let me know if I am wrong. Add element to config type. + + Therefore next example looks like valid (which obviously is not): ---- This is missing in xsd schema as well: + rollback-on-error stop-on-error ignore-error ---- And previously discussed multiple errors: + + ---- And I have one question. Is this example correct? It is in draft (rollback-on-error capability), but neither xsd schema nor Relax NG can't validate it (due to bad order). rollback-on-error Ethernet0/0 100000 It is supposed to be interleaved or it is mistake in draft? Thanks. -- Bc. Ondrej Zlosky xzlosky@fi.muni.cz xzlosky@liberouter.org www.liberouter.org/netopeer/ -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 14 08:25:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23795 for ; Tue, 14 Dec 2004 08:25:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeCOu-000Pdc-UX for netconf-data@psg.com; Tue, 14 Dec 2004 13:07:36 +0000 Received: from [147.251.4.35] (helo=anor.ics.muni.cz) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeCOq-000Pd3-CB for netconf@ops.ietf.org; Tue, 14 Dec 2004 13:07:32 +0000 Received: from anxur.fi.muni.cz (IDENT:0@anxur.fi.muni.cz [147.251.48.3]) by anor.ics.muni.cz (8.12.1/8.12.1) with ESMTP id iBED7Vf8008946 for ; Tue, 14 Dec 2004 14:07:31 +0100 Received: from aisa.fi.muni.cz (IDENT:0@aisa [147.251.48.1]) by anxur.fi.muni.cz (8.12.10/8.12.8) with ESMTP id iBED7TXp003473 for ; Tue, 14 Dec 2004 14:07:30 +0100 (MET) Received: from aisa.fi.muni.cz (IDENT:10401@localhost [127.0.0.1]) by aisa.fi.muni.cz (8.12.10/8.12.8) with ESMTP id iBED7T7K343181 for ; Tue, 14 Dec 2004 14:07:29 +0100 (MET) Received: from localhost (xzlosky@localhost) by aisa.fi.muni.cz (8.12.10/8.12.5/Submit) with ESMTP id iBED7TM2436717 for ; Tue, 14 Dec 2004 14:07:29 +0100 (MET) Date: Tue, 14 Dec 2004 14:07:28 +0100 From: Ondrej Zlosky To: netconf@ops.ietf.org Subject: Re: RELAX NG Schema for NETCONF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Virus-Test: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hello, I'm sorry that this is not "true" reply but I subscribed now and can use only messages from web archive. > Here is a RELAX NG schema for the NETCONF protocol. > It's not any shorter than the XSD that appears in the draft, > but it's somewhat easier to understand at first glance (imho). > The protocol examples in the -04 draft have all been validated > against this schema. I was testing this Relax NG scheme and it looks ok. I propose few improvements because I think that next changes better cover ietf netconf draft. Please, let me know if I am wrong. Add element to config type. + + Therefore next example looks like valid (which obviously is not): ---- This is missing in xsd schema as well: + rollback-on-error stop-on-error ignore-error ---- And previously discussed multiple errors: + + ---- And I have one question. Is this example correct? It is in draft (rollback-on-error capability), but neither xsd schema nor Relax NG can't validate it (due to bad order). rollback-on-error Ethernet0/0 100000 It is supposed to be interleaved or it is mistake in draft? Thanks. -- Bc. Ondrej Zlosky xzlosky@fi.muni.cz xzlosky@liberouter.org www.liberouter.org/netopeer/ -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 14 12:38:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24686 for ; Tue, 14 Dec 2004 12:38:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeGOz-000A9a-PI for netconf-data@psg.com; Tue, 14 Dec 2004 17:23:57 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeGOm-000A8N-Sg for netconf@ops.ietf.org; Tue, 14 Dec 2004 17:23:45 +0000 Received: from [157.159.100.241] (MCI-050eb301d36.int-evry.fr [157.159.100.241]) by smtp2.int-evry.fr (Postfix) with ESMTP id 144D8309A5; Tue, 14 Dec 2004 18:23:38 +0100 (CET) Message-ID: <41BF20F5.5080307@int-evry.fr> Date: Tue, 14 Dec 2004 18:20:53 +0100 From: noe User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?GB2312?B?zfW6sQ==?= Cc: netconf@ops.ietf.org Subject: Re: edit-config References: <303010187.30989@njupt.edu.cn> In-Reply-To: <303010187.30989@njupt.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: nejat_onay.erkose@int-evry.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hello Han, Yeah the result will be always setting the MTU to 1500 but in the case you say we are either replacing or creating but not merging? I am still confused on that. Thank you, Noe Íõº± wrote: > noe£¬ > ¡¡¡¡I think if there HAS been an interface named "ethernet0/0" in the > target configuration, the operation > will set its MTU to 1500, if not, the operation will create a Element > named "Ethernet0/0" in the target > configuration, and then set its MTU to 1500. > so, it's result will always be to setting the MTU value to 1500 in the > configuration, just as what the prop has said. > Best Regards > Wang Han > ======== 2004-12-14 01:21:28 noe said£º ===== > > Hello All, > I couldn't understand something about "operation" attribute in > edit-config request,revision 4 page 28. That is, when there is no > "operation" attrb. we should merge the data with the "target file" > from the > corresponding level. That is a default behaviour. However in the > example after the explanation , if i am not wrong ,we are again > replacing the value of "mtu" under the interface element. > Shouldn't we > here add a new interface into the taget configuration ? > "If the operation attribute is not specified, the configuration > is merged into the configuration datastore. > The operation attribute has one of the following values: > merge: The configuration data identified by the element > containing this attribute is merged with the configuration > at the corresponding level in the configuration datastore > identified by the target parameter. This is the default > behavior. > " > Example: > Set the MTU to 1500 on an interface named "Ethernet0/0" in the > running configuration: > < 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> 1500< /mtu> > < /interface> > < /top> > < /config> > < /edit-config> > < /rpc> > < rpc-reply message-id="101" > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > < ok/> > < /rpc-reply> > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: < http://ops.ietf.org/lists/netconf/> > > ------------------------------------------------------------ > Wang Han > y030737@njupt.edu.cn > Research Center of Network Technology > Nanjing University of Posts and Telecommunications > ¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 14 13:19:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00876 for ; Tue, 14 Dec 2004 13:19:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeGut-000Emm-1C for netconf-data@psg.com; Tue, 14 Dec 2004 17:56:55 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeGuh-000Ekm-I6 for netconf@ops.ietf.org; Tue, 14 Dec 2004 17:56:43 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2004 09:56:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iBEHuU6r005108; Tue, 14 Dec 2004 09:56:35 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn2-668.cisco.com [10.21.114.156]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBX63274; Tue, 14 Dec 2004 09:55:31 -0800 (PST) Message-Id: <4.3.2.7.2.20041214093854.0201c8f8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Dec 2004 09:55:31 -0800 To: noe From: Andy Bierman Subject: Re: edit-config Cc: , netconf@ops.ietf.org In-Reply-To: <41BF20F5.5080307@int-evry.fr> References: <303010187.30989@njupt.edu.cn> <303010187.30989@njupt.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 09:20 AM 12/14/2004, noe wrote: >Hello Han, > >Yeah the result will be always setting the MTU to 1500 but in the case >you say we are either replacing or creating but not merging? I am still >confused on that. The default operation is merge. In your example, interface "Ethernet0/0" would be created if it didn't already exist. In this derivative case, merge and replace have the same result (i.e., "merge X with nothing" is equivalent to "replace nothing with X"). If interface "Ethernet0/0" already existed, then only the "mtu" attribute would be affected by this merge operation. Since this attribute is a scalar, the behavior is the same for merge or replace (i.e., replace). Whether the "mtu" attribute existed or not, after the merge succeeds, it exists and has the specified value "1500". The difference between merge and replace is only apparent for non-scalar attributes, such as an ACL list. Merge will add entries that don't already exist and modify entries which do exist. Replace will remove all existing entries before adding the new ones (if any). The merge order is dependent on the data model. The NETCONF Data Modeling= =20 Language (TBD) will need to provide mechanisms to specify merge behavior. = =20 >Thank you, > >Noe Andy >=CD=F5=BA=B1 wrote: > >> noe=A3=AC >> =A1=A1=A1=A1I think if there HAS been an interface named "ethernet0/0" in= the >> target configuration, the operation >> will set its MTU to 1500, if not, the operation will create a Element >> named "Ethernet0/0" in the target >> configuration, and then set its MTU to 1500. >> so, it's result will always be to setting the MTU value to 1500 in the >> configuration, just as what the prop has said. >> Best Regards >> Wang Han >> =3D=3D=3D=3D=3D=3D=3D=3D 2004-12-14 01:21:28 noe said=A3=BA =3D=3D=3D=3D= =3D >> >> Hello All, >> I couldn't understand something about "operation" attribute in >> edit-config request,revision 4 page 28. That is, when there is no >> "operation" attrb. we should merge the data with the "target file" >> from the >> corresponding level. That is a default behaviour. However in the >> example after the explanation , if i am not wrong ,we are again >> replacing the value of "mtu" under the interface element. >> Shouldn't we >> here add a new interface into the taget configuration ? >> "If the operation attribute is not specified, the configuration >> is merged into the configuration datastore. >> The operation attribute has one of the following values: >> merge: The configuration data identified by the element >> containing this attribute is merged with the configuration >> at the corresponding level in the configuration datastore >> identified by the target parameter. This is the default >> behavior. >> " >> Example: >> Set the MTU to 1500 on an interface named "Ethernet0/0" in the >> running configuration: >> < rpc message-id=3D"101" >> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >> < edit-config> >> < target> >> < running/> >> < /target> >> < config> >> < top xmlns=3D"http://example.com/schema/1.2/config"> >> < interface> >> < name> Ethernet0/0< /name> >> < mtu> 1500< /mtu> >> < /interface> >> < /top> >> < /config> >> < /edit-config> >> < /rpc> >> < rpc-reply message-id=3D"101" >> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >> < ok/> >> < /rpc-reply> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: < http://ops.ietf.org/lists/netconf/> >> >> ------------------------------------------------------------ >> Wang Han >> y030737@njupt.edu.cn >> Research Center of Network Technology >> Nanjing University of Posts and Telecommunications >> =A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA= =A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1= =AA=A1=AA >> > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 14 20:55:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14119 for ; Tue, 14 Dec 2004 20:55:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeO94-00014p-26 for netconf-data@psg.com; Wed, 15 Dec 2004 01:40:02 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CeO91-000141-M9 for netconf@ops.ietf.org; Wed, 15 Dec 2004 01:40:01 +0000 Received: (eyou send program); Wed, 15 Dec 2004 09:59:22 +0800 Message-ID: <303075962.08068@njupt.edu.cn> X-EYOUMAIL-SMTPAUTH: y030737@njupt.edu.cn Received: from unknown (HELO nupt-d83898b16f) (10.10.136.120) by 202.119.230.11 with SMTP; Wed, 15 Dec 2004 09:59:22 +0800 Date: Wed, 15 Dec 2004 09:10:01 +0800 From: "=?gb2312?B?zfW6sQ==?=" To: "netconf" Subject: Re: Re: edit-config X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon677321704751_=====" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, HTML_FONT_FACE_BAD,HTML_MESSAGE,HTML_TAG_EXIST_TBODY,MIME_BASE64_TEXT, MSGID_FROM_MTA_HEADER,RCVD_BY_IP autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --=====003_Dragon677321704751_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 bm9lo6wgDQoNCiAgSSB0aGluayBBbmR5IGhhcyBnaXZlIGEgZ29vZCBhbnN3ZXIuIG1lcmdpbmcg cmVzdWx0IGluIGVpdGhlciByZXBsYWNpbmcgb3IgY3JlYXRpbmcuIKGhoaENCg0KQmVzdCBSZWdh cmRzDQpXYW5nIEhhbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCldhbmcgSGFuDQoNCnkwMzA3MzdAbmp1cHQuZWR1LmNuDQpS ZXNlYXJjaCBDZW50ZXIgb2YgTmV0d29yayBUZWNobm9sb2d5DQpOYW5qaW5nIFVuaXZlcnNpdHkg b2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGq oaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqg0KPT09PT09PT0gMjAwNC0xMi0xNSAwMToyMDo1 MyAgbm9lIHNhaWSjuiA9PT09PQ0KDQoNCkhlbGxvIEhhbiwNCg0KWWVhaCB0aGUgcmVzdWx0IHdp bGwgYmUgYWx3YXlzIHNldHRpbmcgdGhlIE1UVSB0byAxNTAwIGJ1dCBpbiB0aGUgY2FzZQ0KeW91 IHNheSB3ZSBhcmUgZWl0aGVyIHJlcGxhY2luZyBvciBjcmVhdGluZyBidXQgbm90IG1lcmdpbmc/ IEkgYW0gc3RpbGwNCmNvbmZ1c2VkIG9uIHRoYXQuDQoNClRoYW5rIHlvdSwNCg0KTm9lDQoNCg0K zfW6sSB3cm90ZToNCg0KPiAgbm9lo6wNCj4gIKGhoaFJIHRoaW5rIGlmIHRoZXJlIEhBUyBiZWVu IGFuIGludGVyZmFjZSBuYW1lZCAiZXRoZXJuZXQwLzAiIGluIHRoZQ0KPiAgdGFyZ2V0IGNvbmZp Z3VyYXRpb24sIHRoZSBvcGVyYXRpb24NCj4gIHdpbGwgc2V0IGl0cyBNVFUgdG8gMTUwMCwgaWYg bm90LCB0aGUgb3BlcmF0aW9uIHdpbGwgY3JlYXRlIGEgRWxlbWVudA0KPiAgbmFtZWQgIkV0aGVy bmV0MC8wIiBpbiB0aGUgdGFyZ2V0DQo+ICBjb25maWd1cmF0aW9uLCBhbmQgdGhlbiBzZXQgaXRz IE1UVSB0byAxNTAwLg0KPiAgc28sIGl0J3MgcmVzdWx0IHdpbGwgYWx3YXlzIGJlIHRvIHNldHRp bmcgdGhlIE1UVSB2YWx1ZSB0byAxNTAwIGluIHRoZQ0KPiAgY29uZmlndXJhdGlvbiwganVzdCBh cyB3aGF0IHRoZSBwcm9wIGhhcyBzYWlkLg0KPiAgQmVzdCBSZWdhcmRzDQo+ICBXYW5nIEhhbg0K PiAgPT09PT09PT0gMjAwNC0xMi0xNCAwMToyMToyOCBub2Ugc2FpZKO6ID09PT09DQo+IA0KPiAg ICAgIEhlbGxvIEFsbCwNCj4gICAgICBJIGNvdWxkbid0IHVuZGVyc3RhbmQgc29tZXRoaW5nIGFi b3V0ICJvcGVyYXRpb24iIGF0dHJpYnV0ZSBpbg0KPiAgICAgIGVkaXQtY29uZmlnIHJlcXVlc3Qs cmV2aXNpb24gNCBwYWdlIDI4LiBUaGF0IGlzLCB3aGVuIHRoZXJlIGlzIG5vDQo+ICAgICAgIm9w ZXJhdGlvbiIgYXR0cmIuIHdlIHNob3VsZCBtZXJnZSB0aGUgZGF0YSB3aXRoIHRoZSAidGFyZ2V0 IGZpbGUiDQo+ICAgICAgZnJvbSB0aGUNCj4gICAgICBjb3JyZXNwb25kaW5nIGxldmVsLiBUaGF0 IGlzIGEgZGVmYXVsdCBiZWhhdmlvdXIuIEhvd2V2ZXIgaW4gdGhlDQo+ICAgICAgZXhhbXBsZSBh ZnRlciB0aGUgZXhwbGFuYXRpb24gLCBpZiBpIGFtIG5vdCB3cm9uZyAsd2UgYXJlIGFnYWluDQo+ ICAgICAgcmVwbGFjaW5nIHRoZSB2YWx1ZSBvZiAibXR1IiB1bmRlciB0aGUgaW50ZXJmYWNlIGVs ZW1lbnQuDQo+ICAgICAgU2hvdWxkbid0IHdlDQo+ICAgICAgaGVyZSBhZGQgYSBuZXcgaW50ZXJm YWNlIGludG8gdGhlIHRhZ2V0IGNvbmZpZ3VyYXRpb24gPw0KPiAgICAgICJJZiB0aGUgb3BlcmF0 aW9uIGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkLCB0aGUgY29uZmlndXJhdGlvbg0KPiAgICAg IGlzIG1lcmdlZCBpbnRvIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4NCj4gICAgICBUaGUg b3BlcmF0aW9uIGF0dHJpYnV0ZSBoYXMgb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzOg0KPiAg ICAgIG1lcmdlOiBUaGUgY29uZmlndXJhdGlvbiBkYXRhIGlkZW50aWZpZWQgYnkgdGhlIGVsZW1l bnQNCj4gICAgICBjb250YWluaW5nIHRoaXMgYXR0cmlidXRlIGlzIG1lcmdlZCB3aXRoIHRoZSBj b25maWd1cmF0aW9uDQo+ICAgICAgYXQgdGhlIGNvcnJlc3BvbmRpbmcgbGV2ZWwgaW4gdGhlIGNv bmZpZ3VyYXRpb24gZGF0YXN0b3JlDQo+ICAgICAgaWRlbnRpZmllZCBieSB0aGUgdGFyZ2V0IHBh cmFtZXRlci4gVGhpcyBpcyB0aGUgZGVmYXVsdA0KPiAgICAgIGJlaGF2aW9yLg0KPiAgICAgICIN Cj4gICAgICBFeGFtcGxlOg0KPiAgICAgIFNldCB0aGUgTVRVIHRvIDE1MDAgb24gYW4gaW50ZXJm YWNlIG5hbWVkICJFdGhlcm5ldDAvMCIgaW4gdGhlDQo+ICAgICAgcnVubmluZyBjb25maWd1cmF0 aW9uOg0KPiAgICAgIDwgIHJwYyBtZXNzYWdlLWlkPSIxMDEiDQo+ICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+IA0KPiAgICAgIDwgIGVkaXQtY29u ZmlnPiANCj4gICAgICA8ICB0YXJnZXQ+IA0KPiAgICAgIDwgIHJ1bm5pbmcvPiANCj4gICAgICA8 ICAvdGFyZ2V0PiANCj4gICAgICA8ICBjb25maWc+IA0KPiAgICAgIDwgIHRvcCB4bWxucz0iaHR0 cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4gDQo+ICAgICAgPCAgaW50ZXJmYWNl PiANCj4gICAgICA8ICBuYW1lPiAgRXRoZXJuZXQwLzA8ICAvbmFtZT4gDQo+ICAgICAgPCAgbXR1 PiAgMTUwMDwgIC9tdHU+IA0KPiAgICAgIDwgIC9pbnRlcmZhY2U+IA0KPiAgICAgIDwgIC90b3A+ IA0KPiAgICAgIDwgIC9jb25maWc+IA0KPiAgICAgIDwgIC9lZGl0LWNvbmZpZz4gDQo+ICAgICAg PCAgL3JwYz4gDQo+ICAgICAgPCAgcnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4gICAgICB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4gDQo+ICAgICAg PCAgb2svPiANCj4gICAgICA8ICAvcnBjLXJlcGx5PiANCj4gICAgICAtLQ0KPiAgICAgIHRvIHVu c3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdlIHRvIG5ldGNvbmYtcmVxdWVzdEBvcHMuaWV0Zi5vcmcg d2l0aA0KPiAgICAgIHRoZSB3b3JkICd1bnN1YnNjcmliZScgaW4gYSBzaW5nbGUgbGluZSBhcyB0 aGUgbWVzc2FnZSB0ZXh0IGJvZHkuDQo+ICAgICAgYXJjaGl2ZTogPCAgaHR0cDovL29wcy5pZXRm Lm9yZy9saXN0cy9uZXRjb25mLz4gDQo+IA0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBXYW5nIEhhbg0KPiAgeTAzMDcz N0BuanVwdC5lZHUuY24gPCBtYWlsdG86eTAzMDczN0BuanVwdC5lZHUuY24+IA0KPiAgUmVzZWFy Y2ggQ2VudGVyIG9mIE5ldHdvcmsgVGVjaG5vbG9neQ0KPiAgTmFuamluZyBVbml2ZXJzaXR5IG9m IFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCj4gIKGqoaqhqqGqoaqhqqGqoaqhqqGqoaqh qqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaoNCj4gDQo= --=====003_Dragon677321704751_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjEyNjQiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2VhZWFl YT48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT3LzszlPm5vZaOsPC9GT05UPiA8L0ZPTlQ+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsgSSB0aGluayBBbmR5IGhhcyBnaXZlIGEgZ29vZCBh bnN3ZXIuIG1lcmdpbmcmbmJzcDtyZXN1bHQgDQppbiZuYnNwO2VpdGhlciByZXBsYWNpbmcgb3Ig Y3JlYXRpbmcuIDxGT05UIGZhY2U9y87M5SBzaXplPTI+oaGhoTwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBzaXplPTI+QmVzdCBSZWdhcmRzPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2FuZyBIYW48L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIA0Kc2l6ZT0yPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9O VD48L0RJVj4NCjxESVY+V2FuZyBIYW48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnkw MzA3MzdAPEEgaHJlZj0ibWFpbHRvOnkwMzA3MzdAbmp1cHQuZWR1LmNuIj5uanVwdC5lZHUuY248 L0E+PC9ESVY+DQo8RElWPlJlc2VhcmNoIENlbnRlciBvZiBOZXR3b3JrIFRlY2hub2xvZ3k8QlI+ TmFuamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCANClRlbGVjb21tdW5pY2F0aW9uczxCUj6h qqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqPC9ESVY+ PC9ESVY+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+PT09PT09PT0gMjAwNC0x Mi0xNSZuYnNwOzAxOjIwOjUzJm5ic3A7IG5vZSZuYnNwO3NhaWSjuiANCj09PT09PC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFRBQkxFIHdpZHRo PSIxMDAlIj4NCiAgPFRCT0RZPg0KICA8VFI+DQogICAgPFREIHdpZHRoPSIxMDAlIj4NCiAgICAg IDxCTE9DS1FVT1RFIA0KICAgICAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAg ICA8RElWPkhlbGxvJm5ic3A7SGFuLDwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0K ICAgICAgICA8RElWPlllYWgmbmJzcDt0aGUmbmJzcDtyZXN1bHQmbmJzcDt3aWxsJm5ic3A7YmUm bmJzcDthbHdheXMmbmJzcDtzZXR0aW5nJm5ic3A7dGhlJm5ic3A7TVRVJm5ic3A7dG8mbmJzcDsx NTAwJm5ic3A7YnV0Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtjYXNlPC9ESVY+DQogICAgICAgIDxE SVY+eW91Jm5ic3A7c2F5Jm5ic3A7d2UmbmJzcDthcmUmbmJzcDtlaXRoZXImbmJzcDtyZXBsYWNp bmcmbmJzcDtvciZuYnNwO2NyZWF0aW5nJm5ic3A7YnV0Jm5ic3A7bm90Jm5ic3A7bWVyZ2luZz8m bmJzcDtJJm5ic3A7YW0mbmJzcDtzdGlsbDwvRElWPg0KICAgICAgICA8RElWPmNvbmZ1c2VkJm5i c3A7b24mbmJzcDt0aGF0LjwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAg ICA8RElWPlRoYW5rJm5ic3A7eW91LDwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0K ICAgICAgICA8RElWPk5vZTwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAg ICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgICA8RElWPs31urEmbmJzcDt3cm90ZTo8L0RJVj4N CiAgICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwO25vZaOs PC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyANCiAgICAgICAgJm5ic3A7oaGhoUkmbmJzcDt0aGlu ayZuYnNwO2lmJm5ic3A7dGhlcmUmbmJzcDtIQVMmbmJzcDtiZWVuJm5ic3A7YW4mbmJzcDtpbnRl cmZhY2UmbmJzcDtuYW1lZCZuYnNwOyJldGhlcm5ldDAvMCImbmJzcDtpbiZuYnNwO3RoZTwvRElW Pg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7dGFyZ2V0Jm5ic3A7Y29uZmlndXJhdGlvbiwmbmJz cDt0aGUmbmJzcDtvcGVyYXRpb248L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAm bmJzcDt3aWxsJm5ic3A7c2V0Jm5ic3A7aXRzJm5ic3A7TVRVJm5ic3A7dG8mbmJzcDsxNTAwLCZu YnNwO2lmJm5ic3A7bm90LCZuYnNwO3RoZSZuYnNwO29wZXJhdGlvbiZuYnNwO3dpbGwmbmJzcDtj cmVhdGUmbmJzcDthJm5ic3A7RWxlbWVudDwvRElWPg0KICAgICAgICA8RElWPiZndDsgDQogICAg ICAgICZuYnNwO25hbWVkJm5ic3A7IkV0aGVybmV0MC8wIiZuYnNwO2luJm5ic3A7dGhlJm5ic3A7 dGFyZ2V0PC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyANCiAgICAgICAgJm5ic3A7Y29uZmlndXJh dGlvbiwmbmJzcDthbmQmbmJzcDt0aGVuJm5ic3A7c2V0Jm5ic3A7aXRzJm5ic3A7TVRVJm5ic3A7 dG8mbmJzcDsxNTAwLjwvRElWPg0KICAgICAgICA8RElWPiZndDsgDQogICAgICAgICZuYnNwO3Nv LCZuYnNwO2l0J3MmbmJzcDtyZXN1bHQmbmJzcDt3aWxsJm5ic3A7YWx3YXlzJm5ic3A7YmUmbmJz cDt0byZuYnNwO3NldHRpbmcmbmJzcDt0aGUmbmJzcDtNVFUmbmJzcDt2YWx1ZSZuYnNwO3RvJm5i c3A7MTUwMCZuYnNwO2luJm5ic3A7dGhlPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyANCiAgICAg ICAgJm5ic3A7Y29uZmlndXJhdGlvbiwmbmJzcDtqdXN0Jm5ic3A7YXMmbmJzcDt3aGF0Jm5ic3A7 dGhlJm5ic3A7cHJvcCZuYnNwO2hhcyZuYnNwO3NhaWQuPC9ESVY+DQogICAgICAgIDxESVY+Jmd0 OyAmbmJzcDtCZXN0Jm5ic3A7UmVnYXJkczwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7 V2FuZyZuYnNwO0hhbjwvRElWPg0KICAgICAgICA8RElWPiZndDsgDQogICAgICAgICZuYnNwOz09 PT09PT09Jm5ic3A7MjAwNC0xMi0xNCZuYnNwOzAxOjIxOjI4Jm5ic3A7bm9lJm5ic3A7c2FpZKO6 Jm5ic3A7PT09PT08L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IDwvRElWPg0KICAgICAgICA8RElW PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SGVsbG8mbmJzcDtBbGwsPC9ESVY+ DQogICAgICAgIDxESVY+Jmd0OyANCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7SSZuYnNwO2NvdWxkbid0Jm5ic3A7dW5kZXJzdGFuZCZuYnNwO3NvbWV0aGluZyZuYnNwO2Fi b3V0Jm5ic3A7Im9wZXJhdGlvbiImbmJzcDthdHRyaWJ1dGUmbmJzcDtpbjwvRElWPg0KICAgICAg ICA8RElWPiZndDsgDQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VkaXQt Y29uZmlnJm5ic3A7cmVxdWVzdCxyZXZpc2lvbiZuYnNwOzQmbmJzcDtwYWdlJm5ic3A7MjguJm5i c3A7VGhhdCZuYnNwO2lzLCZuYnNwO3doZW4mbmJzcDt0aGVyZSZuYnNwO2lzJm5ic3A7bm88L0RJ Vj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsib3BlcmF0aW9uIiZuYnNwO2F0dHJiLiZuYnNwO3dlJm5ic3A7c2hvdWxkJm5ic3A7bWVy Z2UmbmJzcDt0aGUmbmJzcDtkYXRhJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwOyJ0YXJnZXQmbmJz cDtmaWxlIjwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ZnJvbSZuYnNwO3RoZTwvRElWPg0KICAgICAgICA8RElWPiZndDsgDQogICAgICAgICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvcnJlc3BvbmRpbmcmbmJzcDtsZXZlbC4mbmJz cDtUaGF0Jm5ic3A7aXMmbmJzcDthJm5ic3A7ZGVmYXVsdCZuYnNwO2JlaGF2aW91ci4mbmJzcDtI b3dldmVyJm5ic3A7aW4mbmJzcDt0aGU8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAg ICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleGFtcGxlJm5ic3A7YWZ0ZXImbmJzcDt0 aGUmbmJzcDtleHBsYW5hdGlvbiZuYnNwOywmbmJzcDtpZiZuYnNwO2kmbmJzcDthbSZuYnNwO25v dCZuYnNwO3dyb25nJm5ic3A7LHdlJm5ic3A7YXJlJm5ic3A7YWdhaW48L0RJVj4NCiAgICAgICAg PERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXBsYWNp bmcmbmJzcDt0aGUmbmJzcDt2YWx1ZSZuYnNwO29mJm5ic3A7Im10dSImbmJzcDt1bmRlciZuYnNw O3RoZSZuYnNwO2ludGVyZmFjZSZuYnNwO2VsZW1lbnQuPC9ESVY+DQogICAgICAgIDxESVY+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTaG91bGRuJ3QmbmJzcDt3ZTwvRElWPg0K ICAgICAgICA8RElWPiZndDsgDQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2hlcmUmbmJzcDthZGQmbmJzcDthJm5ic3A7bmV3Jm5ic3A7aW50ZXJmYWNlJm5ic3A7aW50byZu YnNwO3RoZSZuYnNwO3RhZ2V0Jm5ic3A7Y29uZmlndXJhdGlvbiZuYnNwOz88L0RJVj4NCiAgICAg ICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsiSWYm bmJzcDt0aGUmbmJzcDtvcGVyYXRpb24mbmJzcDthdHRyaWJ1dGUmbmJzcDtpcyZuYnNwO25vdCZu YnNwO3NwZWNpZmllZCwmbmJzcDt0aGUmbmJzcDtjb25maWd1cmF0aW9uPC9ESVY+DQogICAgICAg IDxESVY+Jmd0OyANCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXMmbmJz cDttZXJnZWQmbmJzcDtpbnRvJm5ic3A7dGhlJm5ic3A7Y29uZmlndXJhdGlvbiZuYnNwO2RhdGFz dG9yZS48L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtUaGUmbmJzcDtvcGVyYXRpb24mbmJzcDthdHRyaWJ1dGUmbmJzcDtoYXMm bmJzcDtvbmUmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO3ZhbHVlczo8L0RJ Vj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDttZXJnZTombmJzcDtUaGUmbmJzcDtjb25maWd1cmF0aW9uJm5ic3A7ZGF0YSZuYnNwO2lk ZW50aWZpZWQmbmJzcDtieSZuYnNwO3RoZSZuYnNwO2VsZW1lbnQ8L0RJVj4NCiAgICAgICAgPERJ Vj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb250YWluaW5n Jm5ic3A7dGhpcyZuYnNwO2F0dHJpYnV0ZSZuYnNwO2lzJm5ic3A7bWVyZ2VkJm5ic3A7d2l0aCZu YnNwO3RoZSZuYnNwO2NvbmZpZ3VyYXRpb248L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAg ICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthdCZuYnNwO3RoZSZuYnNwO2NvcnJl c3BvbmRpbmcmbmJzcDtsZXZlbCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7Y29uZmlndXJhdGlvbiZu YnNwO2RhdGFzdG9yZTwvRElWPg0KICAgICAgICA8RElWPiZndDsgDQogICAgICAgICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2lkZW50aWZpZWQmbmJzcDtieSZuYnNwO3RoZSZuYnNwO3Rh cmdldCZuYnNwO3BhcmFtZXRlci4mbmJzcDtUaGlzJm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtkZWZh dWx0PC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtiZWhhdmlvci48L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyI8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0V4YW1wbGU6PC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyANCiAgICAgICAgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2V0Jm5ic3A7dGhlJm5ic3A7TVRVJm5ic3A7dG8m bmJzcDsxNTAwJm5ic3A7b24mbmJzcDthbiZuYnNwO2ludGVyZmFjZSZuYnNwO25hbWVkJm5ic3A7 IkV0aGVybmV0MC8wIiZuYnNwO2luJm5ic3A7dGhlPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyAN CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3J1bm5pbmcmbmJzcDtjb25maWd1cmF0aW9u OjwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmx0OyANCiAgICAgICAgJm5ic3A7cnBjJm5ic3A7bWVzc2FnZS1pZD0iMTAxIjwvRElWPg0KICAg ICAgICA8RElWPiZndDsgDQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3ht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiJmd0OyANCiAgICAg ICAgPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbHQ7ICZuYnNwO2VkaXQtY29uZmlnJmd0OyANCjwvRElWPg0KICAgICAgICA8RElWPiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJzcDt0YXJnZXQmZ3Q7IDwvRElW Pg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAm bmJzcDtydW5uaW5nLyZndDsgPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbHQ7ICZuYnNwOy90YXJnZXQmZ3Q7IDwvRElWPg0KICAgICAgICA8 RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJzcDtjb25maWcm Z3Q7IDwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jmx0OyANCiAgICAgICAgJm5ic3A7dG9wJm5ic3A7eG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv bS9zY2hlbWEvMS4yL2NvbmZpZyImZ3Q7IDwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJzcDtpbnRlcmZhY2UmZ3Q7IDwvRElWPg0K ICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJz cDtuYW1lJmd0OyANCiAgICAgICAgJm5ic3A7RXRoZXJuZXQwLzAmbHQ7ICZuYnNwOy9uYW1lJmd0 OyA8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZsdDsgJm5ic3A7bXR1Jmd0OyANCiAgICAgICAgJm5ic3A7MTUwMCZsdDsgJm5ic3A7L210dSZn dDsgPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbHQ7ICZuYnNwOy9pbnRlcmZhY2UmZ3Q7IDwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJzcDsvdG9wJmd0OyA8L0RJVj4NCiAg ICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsgJm5ic3A7 L2NvbmZpZyZndDsgPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbHQ7ICZuYnNwOy9lZGl0LWNvbmZpZyZndDsgDQogICAgICAgIDwvRElWPg0K ICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJz cDsvcnBjJmd0OyA8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZsdDsgDQogICAgICAgICZuYnNwO3JwYy1yZXBseSZuYnNwO21lc3NhZ2UtaWQ9 IjEwMSI8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6 MS4wIiZndDsgDQogICAgICAgIDwvRElWPg0KICAgICAgICA8RElWPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJzcDtvay8mZ3Q7IDwvRElWPg0KICAgICAgICA8RElW PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyAmbmJzcDsvcnBjLXJlcGx5 Jmd0OyA8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOy0tPC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyANCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7dG8mbmJzcDt1bnN1YnNjcmliZSZuYnNwO3NlbmQmbmJzcDthJm5ic3A7 bWVzc2FnZSZuYnNwO3RvJm5ic3A7bmV0Y29uZi1yZXF1ZXN0QG9wcy5pZXRmLm9yZyZuYnNwO3dp dGg8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt0aGUmbmJzcDt3b3JkJm5ic3A7J3Vuc3Vic2NyaWJlJyZuYnNwO2luJm5ic3A7 YSZuYnNwO3NpbmdsZSZuYnNwO2xpbmUmbmJzcDthcyZuYnNwO3RoZSZuYnNwO21lc3NhZ2UmbmJz cDt0ZXh0Jm5ic3A7Ym9keS48L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2FyY2hpdmU6Jm5ic3A7Jmx0OyANCiAgICAgICAgJm5ic3A7aHR0cDov L29wcy5pZXRmLm9yZy9saXN0cy9uZXRjb25mLyZndDsgPC9ESVY+DQogICAgICAgIDxESVY+Jmd0 OyA8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCiAg ICAgICAgPERJVj4mZ3Q7ICZuYnNwO1dhbmcmbmJzcDtIYW48L0RJVj4NCiAgICAgICAgPERJVj4m Z3Q7ICZuYnNwO3kwMzA3MzdAbmp1cHQuZWR1LmNuJm5ic3A7Jmx0OyANCiAgICAgICAgbWFpbHRv OnkwMzA3MzdAbmp1cHQuZWR1LmNuJmd0OyA8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAg ICAgICAmbmJzcDtSZXNlYXJjaCZuYnNwO0NlbnRlciZuYnNwO29mJm5ic3A7TmV0d29yayZuYnNw O1RlY2hub2xvZ3k8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7IA0KICAgICAgICAmbmJzcDtOYW5q aW5nJm5ic3A7VW5pdmVyc2l0eSZuYnNwO29mJm5ic3A7UG9zdHMmbmJzcDthbmQmbmJzcDtUZWxl Y29tbXVuaWNhdGlvbnM8L0RJVj4NCiAgICAgICAgPERJVj4mZ3Q7ICZuYnNwO6GqoaqhqqGqoaqh qqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoao8L0RJVj4NCiAgICAgICAg PERJVj4mZ3Q7IDwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT48 L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPFA+Jm5ic3A7PC9QPjwvRElWPjwvQk9EWT48 L0hUTUw+DQo= --=====003_Dragon677321704751_=====-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 15 05:57:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19948 for ; Wed, 15 Dec 2004 05:57:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CeWVm-000PMa-RX for netconf-data@psg.com; Wed, 15 Dec 2004 10:36:02 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeWVl-000PKT-Lg for netconf@ops.ietf.org; Wed, 15 Dec 2004 10:36:02 +0000 Received: from [157.159.100.241] (MCI-050eb301d36.int-evry.fr [157.159.100.241]) by smtp2.int-evry.fr (Postfix) with ESMTP id 8DED630D0B; Wed, 15 Dec 2004 11:35:50 +0100 (CET) Message-ID: <41C012E2.7030104@int-evry.fr> Date: Wed, 15 Dec 2004 11:33:06 +0100 From: noe User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: edit-config References: <303010187.30989@njupt.edu.cn> <303010187.30989@njupt.edu.cn> <4.3.2.7.2.20041214093854.0201c8f8@fedex.cisco.com> In-Reply-To: <4.3.2.7.2.20041214093854.0201c8f8@fedex.cisco.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: nejat_onay.erkose@int-evry.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thanks ,it is much clearer now. Andy Bierman wrote: >At 09:20 AM 12/14/2004, noe wrote: > > > >>Hello Han, >> >>Yeah the result will be always setting the MTU to 1500 but in the case >>you say we are either replacing or creating but not merging? I am still >>confused on that. >> >> > >The default operation is merge. In your example, interface "Ethernet0/0" >would be created if it didn't already exist. In this derivative case, >merge and replace have the same result (i.e., "merge X with nothing" >is equivalent to "replace nothing with X"). > >If interface "Ethernet0/0" already existed, then only the "mtu" attribute >would be affected by this merge operation. Since this attribute >is a scalar, the behavior is the same for merge or replace (i.e., replace). >Whether the "mtu" attribute existed or not, after the merge succeeds, >it exists and has the specified value "1500". > >The difference between merge and replace is only apparent for non-scalar >attributes, such as an ACL list. Merge will add entries that don't >already exist and modify entries which do exist. Replace will remove >all existing entries before adding the new ones (if any). >The merge order is dependent on the data model. The NETCONF Data Modeling >Language (TBD) will need to provide mechanisms to specify merge behavior. > > > > >>Thank you, >> >>Noe >> >> > >Andy > > > > > > >>Íõº± wrote: >> >> >> >>>noe£¬ >>>¡¡¡¡I think if there HAS been an interface named "ethernet0/0" in the >>>target configuration, the operation >>>will set its MTU to 1500, if not, the operation will create a Element >>>named "Ethernet0/0" in the target >>>configuration, and then set its MTU to 1500. >>>so, it's result will always be to setting the MTU value to 1500 in the >>>configuration, just as what the prop has said. >>>Best Regards >>>Wang Han >>>======== 2004-12-14 01:21:28 noe said£º ===== >>> >>> Hello All, >>> I couldn't understand something about "operation" attribute in >>> edit-config request,revision 4 page 28. That is, when there is no >>> "operation" attrb. we should merge the data with the "target file" >>> from the >>> corresponding level. That is a default behaviour. However in the >>> example after the explanation , if i am not wrong ,we are again >>> replacing the value of "mtu" under the interface element. >>> Shouldn't we >>> here add a new interface into the taget configuration ? >>> "If the operation attribute is not specified, the configuration >>> is merged into the configuration datastore. >>> The operation attribute has one of the following values: >>> merge: The configuration data identified by the element >>> containing this attribute is merged with the configuration >>> at the corresponding level in the configuration datastore >>> identified by the target parameter. This is the default >>> behavior. >>> " >>> Example: >>> Set the MTU to 1500 on an interface named "Ethernet0/0" in the >>> running configuration: >>> < 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> 1500< /mtu> >>> < /interface> >>> < /top> >>> < /config> >>> < /edit-config> >>> < /rpc> >>> < rpc-reply message-id="101" >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >>> < ok/> >>> < /rpc-reply> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: < http://ops.ietf.org/lists/netconf/> >>> >>>------------------------------------------------------------ >>>Wang Han >>>y030737@njupt.edu.cn >>>Research Center of Network Technology >>>Nanjing University of Posts and Telecommunications >>>¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª >>> >>> >>> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 15 11:48:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15922 for ; Wed, 15 Dec 2004 11:48:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cebrq-000NR0-Ew for netconf-data@psg.com; Wed, 15 Dec 2004 16:19:10 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cebrp-000NQj-6N for netconf@ops.ietf.org; Wed, 15 Dec 2004 16:19:09 +0000 Received: from [157.159.100.241] (MCI-050eb301d36.int-evry.fr [157.159.100.241]) by smtp2.int-evry.fr (Postfix) with ESMTP id 715613102A for ; Wed, 15 Dec 2004 17:16:14 +0100 (CET) Message-ID: <41C062A9.8000104@int-evry.fr> Date: Wed, 15 Dec 2004 17:13:29 +0100 From: noe User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: edit-config References: <303010187.30989@njupt.edu.cn> <303010187.30989@njupt.edu.cn> <4.3.2.7.2.20041214093854.0201c8f8@fedex.cisco.com> <41C012E2.7030104@int-evry.fr> In-Reply-To: <41C012E2.7030104@int-evry.fr> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: nejat_onay.erkose@int-evry.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Another question about edit-config: What about the difference between a "create" and "merge" , is it just that we send back an information encapsulated in an "rpc-error"? Page 28 , paragraph about create: "If the configuration data exists, an element is returned with an value of DATA_EXISTS." From what Andy says below ,I interpret it this way. So why do we have both "merge" and "create" if they are doing the same job? thanks. noe wrote: > Thanks ,it is much clearer now. > > > Andy Bierman wrote: > >> At 09:20 AM 12/14/2004, noe wrote: >> >> >> >>> Hello Han, >>> >>> Yeah the result will be always setting the MTU to 1500 but in the case >>> you say we are either replacing or creating but not merging? I am still >>> confused on that. >>> >> >> Andy : >> >> The default operation is merge. In your example, interface >> "Ethernet0/0" >> would be created if it didn't already exist. In this derivative case, >> merge and replace have the same result (i.e., "merge X with nothing" >> is equivalent to "replace nothing with X"). >> >> If interface "Ethernet0/0" already existed, then only the "mtu" >> attribute >> would be affected by this merge operation. Since this attribute >> is a scalar, the behavior is the same for merge or replace (i.e., >> replace). >> Whether the "mtu" attribute existed or not, after the merge succeeds, >> it exists and has the specified value "1500". >> >> The difference between merge and replace is only apparent for non-scalar >> attributes, such as an ACL list. Merge will add entries that don't >> already exist and modify entries which do exist. Replace will remove >> all existing entries before adding the new ones (if any). >> The merge order is dependent on the data model. The NETCONF Data >> Modeling Language (TBD) will need to provide mechanisms to specify >> merge behavior. >> >> >> >>> Thank you, >>> >>> Noe >>> >> >> >> Andy >> >> >> >> >> >> >>> Íõº± wrote: >>> >>> >>> >>>> noe£¬ >>>> ¡¡¡¡I think if there HAS been an interface named "ethernet0/0" in the >>>> target configuration, the operation >>>> will set its MTU to 1500, if not, the operation will create a Element >>>> named "Ethernet0/0" in the target >>>> configuration, and then set its MTU to 1500. >>>> so, it's result will always be to setting the MTU value to 1500 in the >>>> configuration, just as what the prop has said. >>>> Best Regards >>>> Wang Han >>>> ======== 2004-12-14 01:21:28 noe said£º ===== >>>> >>>> Hello All, >>>> I couldn't understand something about "operation" attribute in >>>> edit-config request,revision 4 page 28. That is, when there is no >>>> "operation" attrb. we should merge the data with the "target file" >>>> from the >>>> corresponding level. That is a default behaviour. However in the >>>> example after the explanation , if i am not wrong ,we are again >>>> replacing the value of "mtu" under the interface element. >>>> Shouldn't we >>>> here add a new interface into the taget configuration ? >>>> "If the operation attribute is not specified, the configuration >>>> is merged into the configuration datastore. >>>> The operation attribute has one of the following values: >>>> merge: The configuration data identified by the element >>>> containing this attribute is merged with the configuration >>>> at the corresponding level in the configuration datastore >>>> identified by the target parameter. This is the default >>>> behavior. >>>> " >>>> Example: >>>> Set the MTU to 1500 on an interface named "Ethernet0/0" in the >>>> running configuration: >>>> < 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> 1500< /mtu> >>>> < /interface> >>>> < /top> >>>> < /config> >>>> < /edit-config> >>>> < /rpc> >>>> < rpc-reply message-id="101" >>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >>>> < ok/> >>>> < /rpc-reply> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: < http://ops.ietf.org/lists/netconf/> >>>> >>>> ------------------------------------------------------------ >>>> Wang Han >>>> y030737@njupt.edu.cn >>>> Research Center of Network Technology >>>> Nanjing University of Posts and Telecommunications >>>> ¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª >>>> >>>> >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> >> >> > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 15 11:49:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16001 for ; Wed, 15 Dec 2004 11:49:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cec0y-000PF3-5U for netconf-data@psg.com; Wed, 15 Dec 2004 16:28:36 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cec0x-000PEb-3n for netconf@ops.ietf.org; Wed, 15 Dec 2004 16:28:35 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Dec 2004 09:35:19 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBFGSRMI014909; Wed, 15 Dec 2004 08:28:28 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn2-668.cisco.com [10.21.114.156]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBY61195; Wed, 15 Dec 2004 08:28:32 -0800 (PST) Message-Id: <4.3.2.7.2.20041215082716.02a2c9e0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Dec 2004 08:28:32 -0800 To: noe From: Andy Bierman Subject: Re: edit-config Cc: netconf@ops.ietf.org In-Reply-To: <41C062A9.8000104@int-evry.fr> References: <41C012E2.7030104@int-evry.fr> <303010187.30989@njupt.edu.cn> <303010187.30989@njupt.edu.cn> <4.3.2.7.2.20041214093854.0201c8f8@fedex.cisco.com> <41C012E2.7030104@int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:13 AM 12/15/2004, noe wrote: >Another question about edit-config: > What about the difference between a "create" and "merge" , is it >just that we send back an information encapsulated in an "rpc-error"? > > Page 28 , paragraph about create: > "If the configuration data exists, an element is returned= with an value of DATA_EXISTS." > > From what Andy says below ,I interpret it this way. So why do we >have both "merge" and "create" if they are doing the same job? they don't -- it just looks that way for the derivative case in your example. Create fails if the data already exists. Merge does not. >thanks. Andy >noe wrote: > >>Thanks ,it is much clearer now. >> >> >>Andy Bierman wrote: >> >>>At 09:20 AM 12/14/2004, noe wrote: >>> >>>=20 >>> >>>>Hello Han, >>>> >>>>Yeah the result will be always setting the MTU to 1500 but in the case >>>>you say we are either replacing or creating but not merging? I am still >>>>confused on that. >>>> =20 >>> >>>Andy : >>> >>>The default operation is merge. In your example, interface "Ethernet0/0" >>>would be created if it didn't already exist. In this derivative case, >>>merge and replace have the same result (i.e., "merge X with nothing" >>>is equivalent to "replace nothing with X"). >>> >>>If interface "Ethernet0/0" already existed, then only the "mtu" attribute >>>would be affected by this merge operation. Since this attribute >>>is a scalar, the behavior is the same for merge or replace (i.e.,= replace). >>>Whether the "mtu" attribute existed or not, after the merge succeeds, >>>it exists and has the specified value "1500". >>> >>>The difference between merge and replace is only apparent for non-scalar >>>attributes, such as an ACL list. Merge will add entries that don't >>>already exist and modify entries which do exist. Replace will remove >>>all existing entries before adding the new ones (if any). >>>The merge order is dependent on the data model. The NETCONF Data= Modeling Language (TBD) will need to provide mechanisms to specify merge= behavior.=20 >>>=20 >>> >>>>Thank you, >>>> >>>>Noe >>>> =20 >>> >>> >>>Andy >>> >>> >>> >>> >>>=20 >>> >>>>=CD=F5=BA=B1 wrote: >>>> >>>> =20 >>>> >>>>>noe=A3=AC >>>>>=A1=A1=A1=A1I think if there HAS been an interface named "ethernet0/0"= in the >>>>>target configuration, the operation >>>>>will set its MTU to 1500, if not, the operation will create a Element >>>>>named "Ethernet0/0" in the target >>>>>configuration, and then set its MTU to 1500. >>>>>so, it's result will always be to setting the MTU value to 1500 in the >>>>>configuration, just as what the prop has said. >>>>>Best Regards >>>>>Wang Han >>>>>=3D=3D=3D=3D=3D=3D=3D=3D 2004-12-14 01:21:28 noe said=A3=BA =3D=3D=3D= =3D=3D >>>>> >>>>> Hello All, >>>>> I couldn't understand something about "operation" attribute in >>>>> edit-config request,revision 4 page 28. That is, when there is no >>>>> "operation" attrb. we should merge the data with the "target file" >>>>> from the >>>>> corresponding level. That is a default behaviour. However in the >>>>> example after the explanation , if i am not wrong ,we are again >>>>> replacing the value of "mtu" under the interface element. >>>>> Shouldn't we >>>>> here add a new interface into the taget configuration ? >>>>> "If the operation attribute is not specified, the configuration >>>>> is merged into the configuration datastore. >>>>> The operation attribute has one of the following values: >>>>> merge: The configuration data identified by the element >>>>> containing this attribute is merged with the configuration >>>>> at the corresponding level in the configuration datastore >>>>> identified by the target parameter. This is the default >>>>> behavior. >>>>> " >>>>> Example: >>>>> Set the MTU to 1500 on an interface named "Ethernet0/0" in the >>>>> running configuration: >>>>> < rpc message-id=3D"101" >>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >>>>> < edit-config> >>>>> < target> >>>>> < running/> >>>>> < /target> >>>>> < config> >>>>> < top xmlns=3D"http://example.com/schema/1.2/config"> >>>>> < interface> >>>>> < name> Ethernet0/0< /name> >>>>> < mtu> 1500< /mtu> >>>>> < /interface> >>>>> < /top> >>>>> < /config> >>>>> < /edit-config> >>>>> < /rpc> >>>>> < rpc-reply message-id=3D"101" >>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >>>>> < ok/> >>>>> < /rpc-reply> >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>> the word 'unsubscribe' in a single line as the message text body. >>>>> archive: < http://ops.ietf.org/lists/netconf/> >>>>> >>>>>------------------------------------------------------------ >>>>>Wang Han >>>>>y030737@njupt.edu.cn >>>>>Research Center of Network Technology >>>>>Nanjing University of Posts and Telecommunications >>>>>=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1= =AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA= =A1=AA=A1=AA >>>>> >>>>> =20 >>>> >>>>--=20 >>>>to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: =20 >>> >>> >>>=20 >> >> >>--=20 >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 22 09:27:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26256 for ; Wed, 22 Dec 2004 09:27:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ch7E1-000KFN-Bl for netconf-data@psg.com; Wed, 22 Dec 2004 14:12:25 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ch7Dx-000KF3-1o for netconf@ops.ietf.org; Wed, 22 Dec 2004 14:12:21 +0000 Received: from [157.159.100.241] (MCI-050eb301d36.int-evry.fr [157.159.100.241]) by smtp2.int-evry.fr (Postfix) with ESMTP id E12452FE43 for ; Wed, 22 Dec 2004 15:12:18 +0100 (CET) Message-ID: <41C98014.6090809@int-evry.fr> Date: Wed, 22 Dec 2004 15:09:24 +0100 From: noe User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Lock operation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: nejat_onay.erkose@int-evry.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a question considering the lock operation. A lock operation should be used before all operations or just before edit and copy-config ones? If the latter is the case and another client wants to make a get-config on a previously locked and currently under process configuration file what will be the behaviour of the system? -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 22 18:20:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16349 for ; Wed, 22 Dec 2004 18:20:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ChFd0-000Ivk-U0 for netconf-data@psg.com; Wed, 22 Dec 2004 23:10:46 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ChFcn-000Iu8-SV for netconf@ops.ietf.org; Wed, 22 Dec 2004 23:10:33 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Dec 2004 15:16:01 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBMNATHn012654; Wed, 22 Dec 2004 15:10:29 -0800 (PST) Received: from sberl-w2k01.cisco.com (rtp-vpn1-600.cisco.com [10.82.226.88]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAB07609; Wed, 22 Dec 2004 15:21:16 -0800 (PST) Message-Id: <4.3.2.7.2.20041222123200.03939528@mira-sjcm-1.cisco.com> X-Sender: sberl@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Dec 2004 12:33:11 -0800 To: noe , netconf@ops.ietf.org From: Steve Berl Subject: Re: Lock operation In-Reply-To: <41C98014.6090809@int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Seems like you might want to also use a lock before doing a get to make sure that nobody changes anything in the middle of your get. This would be particularly important if you need to perform multiple get operations to get all the info you want. -steve At 06:09 AM 12/22/2004, noe wrote: >Hello, > > I have a question considering the lock operation. A lock operation should be used before all operations or just before edit and copy-config ones? If the latter is the case and another client wants to make a get-config on a previously locked and currently under process configuration file what will be the behaviour of the system? > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: