From owner-netconf@ops.ietf.org Thu Sep 2 06:05:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17950 for ; Thu, 2 Sep 2004 06:05:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2oHD-000PC4-Bs for netconf-data@psg.com; Thu, 02 Sep 2004 09:53:07 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2oH2-000PAP-P2 for netconf@ops.ietf.org; Thu, 02 Sep 2004 09:52:56 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2004 02:56:48 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i829mxYG017378; Thu, 2 Sep 2004 02:48:59 -0700 (PDT) Received: from [192.168.1.4] (sjc-vpn4-1136.cisco.com [10.21.84.111]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA24495; Thu, 2 Sep 2004 02:47:27 -0700 (PDT) Message-ID: <4136EC00.8020304@cisco.com> Date: Thu, 02 Sep 2004 11:46:40 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: j.schoenwaelder@iu-bremen.de, Margaret Wasserman , netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> <20040823120427.GA3281@james> <4129EAB4.104@cisco.com> In-Reply-To: <4129EAB4.104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'd like to put a new draft out, but I can't right now because I'm blocked on . As it stands right now, we are blocked because Margaret is concerned about CLOSE_WAIT state consuming resources on the manager. This concern arises from the case where one will want to make a change across a large number of devices in a short period of time. The concern is mitigated by because this forces the CLOSE_WAIT state to the agent. On the other hand, cannot currently be used by the agent because the agent doesn't send commands. So, what's a poor agent to do when it wants to gracefully shutdown the connection? Our options are as follows: - simply close the connection. There's no pretty symmetry there but it will do the job. However, it poses a problem for BEEP in as much as I would have to violate the BEEP->TCP transport mapping. - Remove from the base protocol and deal with this level of signaling in the mapping below. - Retain *AND* do something in the mapping below to allow the agent to close the connection. Not pretty because we're actually now beyond MAPPING. If we did this we should have some text in the base protocol about this possibility such as the following: "The agent may initiate session termination in a way specified by the appropriate application mapping." Comments? Eliot -- 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 Sep 2 09:47:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03516 for ; Thu, 2 Sep 2004 09:47:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2rkL-0006yB-C8 for netconf-data@psg.com; Thu, 02 Sep 2004 13:35:25 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2rkA-0006vo-GV for netconf@ops.ietf.org; Thu, 02 Sep 2004 13:35:14 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DA34A96E5; Thu, 2 Sep 2004 15:35:13 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29931-04; Thu, 2 Sep 2004 15:35:13 +0200 (CEST) Received: from james (unknown [212.201.49.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 124A696D5; Thu, 2 Sep 2004 15:35:13 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1C2rk9-0001dK-Ax; Thu, 02 Sep 2004 15:35:13 +0200 Date: Thu, 2 Sep 2004 15:35:13 +0200 From: Juergen Schoenwaelder To: Eliot Lear Cc: Margaret Wasserman , netconf Subject: Re: little problem with Message-ID: <20040902133513.GA6245@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Eliot Lear , Margaret Wasserman , netconf References: <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> <20040823120427.GA3281@james> <4129EAB4.104@cisco.com> <4136EC00.8020304@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4136EC00.8020304@cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Thu, Sep 02, 2004 at 11:46:40AM +0200, Eliot Lear wrote: > I'd like to put a new draft out, but I can't right now because I'm > blocked on . As it stands right now, we are blocked > because Margaret is concerned about CLOSE_WAIT state consuming resources > on the manager. This concern arises from the case where one will want > to make a change across a large number of devices in a short period of > time. The concern is mitigated by because this forces > the CLOSE_WAIT state to the agent. > > On the other hand, cannot currently be used by the agent > because the agent doesn't send commands. So, what's a poor agent to do > when it wants to gracefully shutdown the connection? [...] > Comments? I am still not sure how serious the problem is we are trying to cure. How many TCP connections do you have to close per second in order to run into problems on today's operating systems? Do operators have any insights to share whether this is a problem with existing CLI scripts? How many TCP connections do they close per second these days? /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 Thu Sep 2 21:49: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 VAA00264 for ; Thu, 2 Sep 2004 21:49:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C332w-0000j1-Iq for netconf-data@psg.com; Fri, 03 Sep 2004 01:39:22 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C332d-0000dG-Ob for netconf@ops.ietf.org; Fri, 03 Sep 2004 01:39:03 +0000 Received: from [68.64.253.86] (account margaret HELO [192.168.1.103]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 151740; Thu, 02 Sep 2004 21:35:04 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <20040902133513.GA6245@james> References: <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> <20040823120427.GA3281@james> <4129EAB4.104@cisco.com> <4136EC00.8020304@cisco.com> <20040902133513.GA6245@james> Date: Thu, 2 Sep 2004 21:34:03 -0400 To: j.schoenwaelder@iu-bremen.de, Eliot Lear From: Margaret Wasserman Subject: Re: little problem with Cc: netconf Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Juergen, At 3:35 PM +0200 9/2/04, Juergen Schoenwaelder wrote: >I am still not sure how serious the problem is we are trying to cure. >How many TCP connections do you have to close per second in order to >run into problems on today's operating systems? Do operators have any >insights to share whether this is a problem with existing CLI scripts? >How many TCP connections do they close per second these days? These are all interesting questions, and I would like to know the answers (but I don't). I do know that there were real-life problems with this in the mid-1990s, but I have no more recent data. The other reason that I cited for wanting a command is that it removes any ambiguity about when the session has been cleanly closed on both sides, so that all resources and state can be freed. This is really a question of whether we want any concept of a session to exist at the NETCONF layer, or whether we want NETCONF to assume that the graceful close of a lower layer session indicates that the NETCONF session completed successfully. I don't have religion about this, so if no one else sees any advantages to having a command, please just remove it. If that is the choice of the WG, I will put a caveat in the SSH mapping about connections being left in TIME-WAIT state on the manger, and we can move on... Margaret -- 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 Sep 3 12:37:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09832 for ; Fri, 3 Sep 2004 12:37:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C3Gps-000522-Cl for netconf-data@psg.com; Fri, 03 Sep 2004 16:22:48 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C3GpZ-00050E-BU for netconf@ops.ietf.org; Fri, 03 Sep 2004 16:22:29 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2004 09:29:19 -0700 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 i83GMP8J028190; Fri, 3 Sep 2004 09:22:25 -0700 (PDT) Received: from abierman-w2k01.cisco.com (sjc-vpn4-1187.cisco.com [10.21.84.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AYR69057; Fri, 3 Sep 2004 09:22:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20040903091613.024f0478@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Sep 2004 09:22:26 -0700 To: proceedings@ietf.org From: Andy Bierman Subject: NETCONF WG minutes for IETF #60 Cc: netconf@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk OPS Area NETCONF WG Meeting Minutes IETF #60 August 5, 2004 Minutes by Sharon Chisolm, Eliot Lear, and Andy Bierman Chairs ------ Andy Bierman Simon Leinen Review Material --------------- NETCONF Configuration Protocol BEEP Application Protocol Mapping for NETCONF NETCONF Over SOAP Using the NETCONF Configuration Protocol over Secure Shell (SSH) Agenda ------ - Report on NETMOD BOF (Sharon Chisholm, 15 min) - Security Issues (Wes Hardaker, 15 min) - Discussion of WG Documents (50 min) - Next Steps (10 min) Minutes ------- 0) Agenda bashing There was some minor agenda bashing, and as a result, the Security Issues discussion was held first. 1) Netconf Protocol: Security Considerations Wes Hardaker presented some issues related to authentication and access control. Refer to the slides and the jabber logs for more details. 1.1) Access Control Requirements There is language in the protocol document that implies (or requires) that the access control must be the same for CLI and NETCONF. The Editor needs to clarify the relevant text. The WG must decide how strong a requirement is needed (MUST be the same, SHOULD be the same, MUST be mappable, etc.,). 1.2) Global Locking A lesser-privileged user can obtain a lock and hold it, which can be a denial-of-service attack against higher-priveleged users. The WG has already discussed this issue in the past and decided that partial locking requires canonical object and instance naming across all access modes (SNMP, CLI, etc.), and this is an issue the NETMOD WG should address. 1.3) Netconf Protocol Chaining Some NETCONF protocol operations work on remote datasets (e.g., copy-config and URL based edit-config). This is not a new issue, but the Editors need to make sure acceptable protocol type values (e.g., ftp, http) for URL based operations are documented in the Security Considerations section. 1.4) Exposure Through Error Messages There is a concern that error messages produced for operations such as should not expose any configuration details for portions of the data model that the user invoking the operation does not have access rights to view. 1.5) NETCONF Usage Proposal There was a proposal that "Netconf 1.0 MUST NOT be used in restricted-role environments". The WG did not agree to this proposal. Security considerations should explain the potential risks for various types of usage. Granular locking will be considered in the future. 2) NETMOD BOF Report Sharon Chisholm presented a summary of the NETCONF Data Modelling BOF (NETMOD). Refer to the slides and the jabber logs for more details. NETMOD web page is http://standards.nortelnetworks.com/netconf Mailing list is netconfmodel@lyris.nortelnetworks.com to subscribe, lyris@lists.nortelnetworks.com The NETCONF WG is not chartered to standardize a data modelling language or domain-specific data models. The proposed NETMOD WG charter would address this "content" layer. Some of the issues in the problem statement: - what are common ways of specifying compliance? - backwards compatibility - how do we deal with access control? - how do we describe relationships? The NETMOD WG will look at W3C XML schema two initial drafts one is SMI for NETCONF some sort of meta model or abstract data model will drive There were four presentations and lots of discussion at the NETMOD BOF. Refer to the proceedings for details. There is strong interest in leveraging existing technologies, but not so much agreement on which technologies. Some evaluation needs to be done in this area. The group refined the proposed charter text and also discussed the need for volunteers in various areas of expertise. People interested in participating should contact Sharon Chisholm (see NETMOD WEB page above). There is some potential impact on the NETCONF protocol document, related to the NETMOD work: - Removal of Section 7 of the protocol draft (move the XML usage restrictions into another place) - syntactic naming and identification - move netconf-state data model to a different document To put this stuff in the protocol draft would be presumptuous, but would otherwise delay the protocol The WG needs to decide what changes to make to the protocol draft related to the proposed NETMOD work. It is proposed that these sections are not removed. Instead, a warning in each section will be added to explain that a NETCONF data modelling standard document is expected to supercede this text at some time in the future. 3) Protocol Document Open Issues Andy Bierman presented a list of open issues with the NETCONF protocol document. Refer to the slides and the jabber logs for more details. 3.1) Retrieval filtering The group discussed the need for a mandatory-to-implement retrieval filtering mechanism. The WG is considering either "subtree filtering" (currently in the protocol specification examples) and "Xpath subset" (currently in an email proposal). The operator requirements document requires the ability to manage both full and partial configuration files, so some choice has to be made. The group discussed the pros and cons of each approach (again), and then made some decisions: - full (but optional) implementation of Xpath will be supported in NETCONF, indicated by the #xpath capability - the "subtree filtering" will be the mandatory-to-implement retrieval filtering mechanism (show of hands: none - 0; subtree 18 - 20; XPATH subset 4) 3.2) Rollback The WG agreed to address rollback and retrieval filtering at IETF 59. There is a need to sometimes undo edits or commits to the running configuration. The email proposal from Andy Bierman was explained (see slides for details) and discussed by the group. The rollback proposal includes an optional "per session ring buffer", although each private snapshot (ring buffer entry) is a copy of the entire configuration. The operation restores the entire configuration to previous state. This is not a per-session restore operation. The group discussed issues related to locking, shared databases, transactions, access control, error reporting, and feature complexity. Afterwards, some decisions were made: - The rollback feature will not be added to the protocol document (show of hands: yes - 10; no - 6; No consensus to change the document - leave it out) - The issue will go back to the WG mailing list for new proposals. (However, time is running out on additions; the document updates will not be held up for this feature.) 3.3) Default Edit Operation The protocol draft does not properly support scoped edit-config operations, because "merge" is always the default edit operation. The possible values for a default operation are "merge", "none", and "replace". Sometimes the default operation needs to be "none": - modify a node in the data model without touching any of its ancestors - tells the agent that I better find an exact match or this operation should fail Sometimes the default operation needs to be "replace": - useful for loading previously saved configuration data as an opaque XML block The email proposal from Andy Bierman was discussed (see slides for details). This includes a new parameter for the operation that specifies the default operation in the event the "operation" attribute is not present within a data model element. The group then made some decisions: - the operation will be changed to support a user-specified default operation - the new parameter will be called "operation" - the document needs to be clarified to indicate exactly how the default operation is applied to the parameter, and how the "operation" attribute within a data model element overrides the default operation. 3.4) Default Configuration Target The XSD does not support different default values, depending on the presence of the #candidate capability. Therefore, instead of as a default value, affected operations (e.g., ) should have no default specified. There were no objections to this change. 4) Application Mapping Documents: Open Issues Andy Bierman presented a list of open issues with the application mapping documents. Refer to the slides and the jabber logs for more details. 4.1) General Issues The titles of the application mapping documents need to be more consistent. The authors will work out the details between themselves and propose new document titles (2 of the 3 will need to change). The new document titles will be proposed to the WG. Also, all acronyms need to be spelled out in the titles (e.g., SOAP). 4.2) NETCONF over SOAP There is concern that this document is too HTTP-centric. The intent is that the document define how NETCONF maps to SOAP, and different SOAP documents define how SOAP maps to the substrate protocol (e.g., HTTP, BEEP). There is interest is running NETCONF over SOAP over BEEP, which is not directly supported by the NETCONF over SOAP document. The WG discussed these issues and made some decisions: - The document should be made as SOAP-generic as possible - SOAP over BEEP should be supported - Any HTTP or BEEP specific text should be identified and put in separate sections 5) Next Steps The authors have been asked to produce "final updates" as soon as possible (2 week deadline already past!). After these documents are posted, WG Last Calls can begin. -- 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 Sep 3 16:28: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 QAA12168 for ; Fri, 3 Sep 2004 16:28:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C3KV3-000KL7-EX for netconf-data@psg.com; Fri, 03 Sep 2004 20:17:33 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C3KUs-000KF9-JH for netconf@ops.ietf.org; Fri, 03 Sep 2004 20:17:22 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i83KHKm07657 for ; Fri, 3 Sep 2004 16:17:20 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Sep 2004 16:17:18 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B401480D0A@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf@ops.ietf.org Subject: RE: NETCONF WG minutes for IETF #60 Date: Fri, 3 Sep 2004 16:17:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk hi The minutes say that instead of removing the stuff in section 7 of the protocol draft since we (netmod) want to include it in our content discussion "Instead, a warning in each section will be added to explain that a NETCONF data modelling standard document is expected to supercede this text at some time in the future." I don't remember that. Was this just until our stuff progressed to be working group documents? That almost sounds familiar. This protocol draft wouldn't go to RFC with the duplicated text would it? Sharon -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, September 03, 2004 12:22 PM To: proceedings@ietf.org Cc: netconf@ops.ietf.org Subject: NETCONF WG minutes for IETF #60 -- 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 Sep 3 17:36:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16490 for ; Fri, 3 Sep 2004 17:36:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C3Lau-0006Nz-7R for netconf-data@psg.com; Fri, 03 Sep 2004 21:27:40 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C3Laj-0006Ma-Lt for netconf@ops.ietf.org; Fri, 03 Sep 2004 21:27:29 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Sep 2004 14:29:23 -0700 X-BrightmailFiltered: true 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 i83LRL8N008680; Fri, 3 Sep 2004 14:27:24 -0700 (PDT) Received: from abierman-w2k01.cisco.com (sjc-vpn4-1187.cisco.com [10.21.84.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AYS06272; Fri, 3 Sep 2004 14:23:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20040903142119.024b4248@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Sep 2004 14:23:58 -0700 To: "Sharon Chisholm" From: Andy Bierman Subject: RE: NETCONF WG minutes for IETF #60 Cc: netconf@ops.ietf.org In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B401480D0A@zcarhxm2.corp.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 01:17 PM 9/3/2004, Sharon Chisholm wrote: >hi > >The minutes say that instead of removing the stuff in section 7 of the >protocol draft since we (netmod) want to include it in our content >discussion > >"Instead, a warning in each section >will be added to explain that a NETCONF data modelling standard document is >expected to supercede this text at some time in the future." > >I don't remember that. Was this just until our stuff progressed to be >working group documents? That almost sounds familiar. This protocol draft >wouldn't go to RFC with the duplicated text would it? We did discuss this a little bit -- we don't want the data model stuff to disappear until (if and when) a NETMOD WG is formed and produces a document to replace this text. I think these sections should remain in the NETCONF protocol document as non-normative appendices. >Sharon Andy >-----Original Message----- >From: Andy Bierman [mailto:abierman@cisco.com] >Sent: Friday, September 03, 2004 12:22 PM >To: proceedings@ietf.org >Cc: netconf@ops.ietf.org >Subject: NETCONF WG minutes for IETF #60 > > > >-- >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 Sep 6 05:31:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17176 for ; Mon, 6 Sep 2004 05:31:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4Fgt-000D28-0g for netconf-data@psg.com; Mon, 06 Sep 2004 09:21:35 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4Fgi-000Cxv-C1 for netconf@ops.ietf.org; Mon, 06 Sep 2004 09:21:24 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 Sep 2004 02:28:46 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i869LMUt016554; Mon, 6 Sep 2004 02:21:22 -0700 (PDT) Received: from [192.168.1.4] (sjc-vpn5-82.cisco.com [10.21.88.82]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA21940; Mon, 6 Sep 2004 02:21:19 -0700 (PDT) Message-ID: <413C2C0A.7040104@cisco.com> Date: Mon, 06 Sep 2004 11:21:14 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: j.schoenwaelder@iu-bremen.de, netconf Subject: Re: little problem with References: <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> <20040823120427.GA3281@james> <4129EAB4.104@cisco.com> <4136EC00.8020304@cisco.com> <20040902133513.GA6245@james> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Margaret Wasserman wrote: > These are all interesting questions, and I would like to know the > answers (but I don't). I do know that there were real-life problems > with this in the mid-1990s, but I have no more recent data. Fair enough, but I would like the transport concern to be handled in the mapping document. > > The other reason that I cited for wanting a command is > that it removes any ambiguity about when the session has been cleanly > closed on both sides, so that all resources and state can be freed. > This is really a question of whether we want any concept of a session to > exist at the NETCONF layer, or whether we want NETCONF to assume that > the graceful close of a lower layer session indicates that the NETCONF > session completed successfully. The state of a session is something that needs to be determined in the mapping document. In some cases it will need to be explicit and in other cases explicit. Nothing prevents the ends from communicating session state - in a combined L4/L5 view of the world that happens all the time with TCP. > > I don't have religion about this, so if no one else sees any advantages > to having a command, please just remove it. If that is > the choice of the WG, I will put a caveat in the SSH mapping about > connections being left in TIME-WAIT state on the manger, and we can move > on... Again, I'm not suggesting that it be removed entirely but that it be moved into the mappings (of the alternative that's my favorite). One way or the other, you need to update your draft. Eliot -- 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 Sep 8 09:15:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10170 for ; Wed, 8 Sep 2004 09:15:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C527t-0007sY-M6 for netconf-data@psg.com; Wed, 08 Sep 2004 13:04:41 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C527i-0007rC-Pt for netconf@ops.ietf.org; Wed, 08 Sep 2004 13:04:30 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i88D4S723808 for ; Wed, 8 Sep 2004 09:04:28 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Sep 2004 09:04:23 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4014F6388@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf@ops.ietf.org Subject: RE: NETCONF WG minutes for IETF #60 Date: Wed, 8 Sep 2004 09:04:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk hi I agree it should be kept in the protocol draft until we are sure what's going on with netmod, but I would have some concerns if the document was published with the content. My main concern is the risk for contradictory requirements. We could make it a non-normative appendix with a big old disclaimer for now and worry about it when we get closer to publication. Perhaps an editor's note to remind us to revist the issue? Sharon -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, September 03, 2004 5:24 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: RE: NETCONF WG minutes for IETF #60 At 01:17 PM 9/3/2004, Sharon Chisholm wrote: >hi > >The minutes say that instead of removing the stuff in section 7 of the >protocol draft since we (netmod) want to include it in our content >discussion > >"Instead, a warning in each section >will be added to explain that a NETCONF data modelling standard document is >expected to supercede this text at some time in the future." > >I don't remember that. Was this just until our stuff progressed to be >working group documents? That almost sounds familiar. This protocol >draft wouldn't go to RFC with the duplicated text would it? We did discuss this a little bit -- we don't want the data model stuff to disappear until (if and when) a NETMOD WG is formed and produces a document to replace this text. I think these sections should remain in the NETCONF protocol document as non-normative appendices. >Sharon Andy >-----Original Message----- >From: Andy Bierman [mailto:abierman@cisco.com] >Sent: Friday, September 03, 2004 12:22 PM >To: proceedings@ietf.org >Cc: netconf@ops.ietf.org >Subject: NETCONF WG minutes for IETF #60 > > > >-- >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 Sep 8 15:24:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08928 for ; Wed, 8 Sep 2004 15:24:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C57oL-000K8D-Fd for netconf-data@psg.com; Wed, 08 Sep 2004 19:08:53 +0000 Received: from [207.17.137.105] (helo=juniper.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C57oA-000K6s-TV for netconf@ops.ietf.org; Wed, 08 Sep 2004 19:08:42 +0000 Received: from ([172.24.18.126]) by jaffa.juniper.net with ESMTP ; Wed, 08 Sep 2004 12:07:58 -0700 Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 12:07:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NETCONF WG minutes for IETF #60 Date: Wed, 8 Sep 2004 12:08:00 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440636EF5D@photon.jnpr.net> Thread-Topic: NETCONF WG minutes for IETF #60 Thread-Index: AcSVpRkpdPHJWeg1QJu/fJ6iJEabDAAMfIcw From: "Rob Enns" To: "Sharon Chisholm" , X-OriginalArrivalTime: 08 Sep 2004 19:07:58.0599 (UTC) FILETIME=[27796170:01C495D7] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable It sounds like a reasonable approach to me. Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Wednesday, September 08, 2004 6:04 AM > To: netconf@ops.ietf.org > Subject: RE: NETCONF WG minutes for IETF #60 >=20 > hi >=20 > I agree it should be kept in the protocol draft until we are=20 > sure what's > going on with netmod, but I would have some concerns if the=20 > document was > published with the content. My main concern is the risk for=20 > contradictory > requirements. We could make it a non-normative appendix with a big old > disclaimer for now and worry about it when we get closer to=20 > publication. > Perhaps an editor's note to remind us to revist the issue? >=20 > Sharon >=20 > -----Original Message----- > From: Andy Bierman [mailto:abierman@cisco.com]=20 > Sent: Friday, September 03, 2004 5:24 PM > To: Chisholm, Sharon [CAR:5K50:EXCH] > Cc: netconf@ops.ietf.org > Subject: RE: NETCONF WG minutes for IETF #60 >=20 >=20 > At 01:17 PM 9/3/2004, Sharon Chisholm wrote: > >hi > > > >The minutes say that instead of removing the stuff in=20 > section 7 of the=20 > >protocol draft since we (netmod) want to include it in our content=20 > >discussion > > > >"Instead, a warning in each section > >will be added to explain that a NETCONF data modelling=20 > standard document is > >expected to supercede this text at some time in the future." > > > >I don't remember that. Was this just until our stuff=20 > progressed to be=20 > >working group documents? That almost sounds familiar. This protocol=20 > >draft wouldn't go to RFC with the duplicated text would it? >=20 > We did discuss this a little bit -- we don't want the data=20 > model stuff to > disappear until (if and when) a NETMOD WG is formed and=20 > produces a document > to replace this text. I think these sections should remain=20 > in the NETCONF > protocol document as non-normative appendices. =20 >=20 >=20 > >Sharon >=20 > Andy >=20 >=20 >=20 > >-----Original Message----- > >From: Andy Bierman [mailto:abierman@cisco.com] > >Sent: Friday, September 03, 2004 12:22 PM > >To: proceedings@ietf.org > >Cc: netconf@ops.ietf.org > >Subject: NETCONF WG minutes for IETF #60 > > > > > > > >-- > >to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > >word 'unsubscribe' in a single line as the message text body. > >archive: >=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 -- 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 Sep 9 06:06:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03207 for ; Thu, 9 Sep 2004 06:06:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5LYr-0003p4-3p for netconf-data@psg.com; Thu, 09 Sep 2004 09:49:49 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C58FA-000MaX-0u for netconf@ops.ietf.org; Wed, 08 Sep 2004 19:36:37 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09836; Wed, 8 Sep 2004 15:36:33 -0400 (EDT) Message-Id: <200409081936.PAA09836@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-soap-03.txt Date: Wed, 08 Sep 2004 15:36:33 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) Author(s) : T. Goddard Filename : draft-ietf-netconf-soap-03.txt Pages : 19 Date : 2004-9-8 The device management protocol NETCONF is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of SOAP over HTTP. NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe a SOAP over HTTP binding that, when used with persistent HTTP connections, yields an application protocol sufficient for NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-03.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-ietf-netconf-soap-03.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-ietf-netconf-soap-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-8154345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-soap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-soap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154345.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Sep 9 11:34: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 LAA27008 for ; Thu, 9 Sep 2004 11:34:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5Qco-000EMC-Ho for netconf-data@psg.com; Thu, 09 Sep 2004 15:14:14 +0000 Received: from [64.40.109.159] (helo=mail.icesoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5Qcd-000EKW-Nt for netconf@ops.ietf.org; Thu, 09 Sep 2004 15:14:03 +0000 Received: from [10.18.39.60] ([68.146.161.194]) by mail.icesoft.com (Kerio MailServer 5.7.6) for netconf@ops.ietf.org; Thu, 9 Sep 2004 08:13:54 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200409081936.PAA09836@ietf.org> References: <200409081936.PAA09836@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: I-D ACTION:draft-ietf-netconf-soap-03.txt Date: Thu, 9 Sep 2004 09:14:00 -0600 To: netconf@ops.ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Note that the abstract of the draft has been updated as follows (the change was not reflected in the I-D Action message): The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over BEEP bindings that yield application protocols sufficient for NETCONF. Ted. On 8-Sep-04, at 1:36 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Configuration Working Group > of the IETF. > > Title : Using the Network Configuration Protocol (NETCONF) Over > the Simple Object Access Protocol (SOAP) > Author(s) : T. Goddard > Filename : draft-ietf-netconf-soap-03.txt > Pages : 19 > Date : 2004-9-8 > > The device management protocol NETCONF is applicable to a wide range > of devices in a variety of environments. The emergence of Web > Services gives one such environment, and is presently characterized > by the use of SOAP over HTTP. NETCONF finds many benefits in this > environment: from the re-use of existing standards, to ease of > software development, to integration with deployed systems. Herein, > we describe a SOAP over HTTP binding that, when used with persistent > HTTP connections, yields an application protocol sufficient for > NETCONF. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-03.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-ietf-netconf-soap-03.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-ietf-netconf-soap-03.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. > Content-Type: text/plain > Content-ID: <2004-9-8154345.I-D@ietf.org> -- 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 Sep 9 11:54:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29196 for ; Thu, 9 Sep 2004 11:54:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5R4Q-000HAo-6f for netconf-data@psg.com; Thu, 09 Sep 2004 15:42:46 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5R4F-000H9f-9i for netconf@ops.ietf.org; Thu, 09 Sep 2004 15:42:35 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id i89FgVqA015779 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Sep 2004 17:42:31 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.12.11/8.12.11/Submit) id i89FgVY1015778; Thu, 9 Sep 2004 17:42:31 +0200 (CEST) To: Ted Goddard Cc: netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-netconf-soap-03.txt X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: (Ted Goddard's message of "Thu, 9 Sep 2004 09:14:00 -0600") References: <200409081936.PAA09836@ietf.org> Date: Thu, 09 Sep 2004 17:42:31 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Thanks for the revised draft, Ted! As a short reminder to everyone, Henrik Levkowetz has put up an overview page for the NETCONF WG documents on http://ietf.levkowetz.com/drafts/netconf/ So Ted's new I-D, and a side-by-side comparison against the previous (-02) revision have magically appeared here: http://ietf.levkowetz.com/drafts/netconf/soap/ http://ietf.levkowetz.com/drafts/netconf/soap/draft-ietf-netconf-soap-03-from-02.diff.html -- 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: From owner-netconf@ops.ietf.org Tue Sep 14 14:15:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01457 for ; Tue, 14 Sep 2004 14:15:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C7HeJ-0009R3-FU for netconf-data@psg.com; Tue, 14 Sep 2004 18:03:27 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C7He8-0009Pn-OH for netconf@ops.ietf.org; Tue, 14 Sep 2004 18:03:16 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2004 11:05:26 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8EI38xk020384; Tue, 14 Sep 2004 11:03:09 -0700 (PDT) Received: from sberl-w2k.cisco.com ([128.107.169.20]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXC42214; Tue, 14 Sep 2004 11:01:56 -0700 (PDT) Message-Id: <4.3.2.7.2.20040914110122.03395008@mira-sjcm-1.cisco.com> X-Sender: sberl@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Sep 2004 11:03:23 -0700 To: Simon Leinen , Ted Goddard From: Steve Berl Subject: Re: I-D ACTION:draft-ietf-netconf-soap-03.txt Cc: netconf@ops.ietf.org In-Reply-To: References: <200409081936.PAA09836@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk You might want to update the informative reference [18] to point at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss or more specifically http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss This page points at the more recent version of the standard for SOAP security headers. -steve At 08:42 AM 9/9/2004, Simon Leinen wrote: >Thanks for the revised draft, Ted! > >As a short reminder to everyone, Henrik Levkowetz has put up an >overview page for the NETCONF WG documents on > >http://ietf.levkowetz.com/drafts/netconf/ > >So Ted's new I-D, and a side-by-side comparison against the previous >(-02) revision have magically appeared here: > >http://ietf.levkowetz.com/drafts/netconf/soap/ >http://ietf.levkowetz.com/drafts/netconf/soap/draft-ietf-netconf-soap-03-from-02.diff.html >-- >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: