From owner-netconf@ops.ietf.org Fri Jan 7 05:52:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03587 for ; Fri, 7 Jan 2005 05:52:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CmrY1-000Pes-I1 for netconf-data@psg.com; Fri, 07 Jan 2005 10:40:49 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CmrY0-000Pea-Ib for netconf@ops.ietf.org; Fri, 07 Jan 2005 10:40:48 +0000 Received: from [157.159.100.240] (MCI-050eb301d36.int-evry.fr [157.159.100.240]) by smtp2.int-evry.fr (Postfix) with ESMTP id C37052FD11 for ; Fri, 7 Jan 2005 11:40:44 +0100 (CET) Message-ID: <41DE667E.5050107@int-evry.fr> Date: Fri, 07 Jan 2005 11:37:50 +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: kill-session operation & netconf state data 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 All, I am using beep as an underlying protocol and as far as I know ,it doesn't give ids to its sessions. Does anybody know if there is a way to kill a specific session than the current one, in beep? Or should session-ids be assigned by the programmer ? Secondly, I could't find any sample of netconf sate data, does anybody know where can I find it ? Thanks, Onay. -- 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 Jan 7 08:09:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11653 for ; Fri, 7 Jan 2005 08:09:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cmtck-000B3a-0F for netconf-data@psg.com; Fri, 07 Jan 2005 12:53:50 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cmtcg-000B38-1Q for netconf@ops.ietf.org; Fri, 07 Jan 2005 12:53:46 +0000 Received: from [157.159.100.240] (MCI-050eb301d36.int-evry.fr [157.159.100.240]) by smtp2.int-evry.fr (Postfix) with ESMTP id DBAB72FD8A; Fri, 7 Jan 2005 13:53:43 +0100 (CET) Message-ID: <41DE85A9.9090602@int-evry.fr> Date: Fri, 07 Jan 2005 13:50:49 +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==?= , netconf@ops.ietf.org Subject: Re: kill-session operation & netconf state data References: <305104086.01343@njupt.edu.cn> In-Reply-To: <305104086.01343@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 Íõº± wrote: > noe£¬ > ======== 2005-01-07 18:37:50 noe said£º ===== > > Hello All, > I am using beep as an underlying protocol and as far as I know > ,it doesn't give ids to its sessions. Does anybody know if there is a > way to kill a specific session than the current one, in beep? Or > should > session-ids be assigned by the programmer ? > Secondly, I could't find any sample of netconf sate data, does > ~~~~ > what does the "sate data" mean? > Thanks, > Onay. > -- > 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/> > > ¡¡¡¡ > Regards > Wang Han > ------------------------------------------------------------ > Wang Han > y030737@njupt.edu.cn > Research Center of Network Technology > Nanjing University of Posts and Telecommunications > ¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª > Sorry for that it is state data.... -- 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 Jan 7 11:22:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24092 for ; Fri, 7 Jan 2005 11:22:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CmwiD-0009XZ-Vf for netconf-data@psg.com; Fri, 07 Jan 2005 16:11:41 +0000 Received: from [157.159.10.45] (helo=smtp2.int-evry.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cmwi4-0009VP-I5 for netconf@ops.ietf.org; Fri, 07 Jan 2005 16:11:32 +0000 Received: from [157.159.100.240] (MCI-050eb301d36.int-evry.fr [157.159.100.240]) by smtp2.int-evry.fr (Postfix) with ESMTP id 54DF52FD94 for ; Fri, 7 Jan 2005 17:11:23 +0100 (CET) Message-ID: <41DEB3FB.2040700@int-evry.fr> Date: Fri, 07 Jan 2005 17:08:27 +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: close-session 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, I am a bit confused about the operation. Is there a significance for the initiator to not to close the session itself but instead assign this job to the peer? It can send a close-session to the peer and trigger it to release the locks and resources associated to that connection and then when it gets the "ok" it can itself close the session. Do you think this would lead to any problems ? -- 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 Jan 12 18:09:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26899 for ; Wed, 12 Jan 2005 18:09:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CorQ3-000PtI-Qm for netconf-data@psg.com; Wed, 12 Jan 2005 22:56:51 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CorQ2-000Psy-Nl for netconf@ops.ietf.org; Wed, 12 Jan 2005 22:56:50 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by rtp-iport-2.cisco.com with ESMTP; 12 Jan 2005 17:56:49 -0500 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 j0CMuljw013849 for ; Wed, 12 Jan 2005 14:56:48 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn1-595.cisco.com [10.21.98.83]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BCR50096; Wed, 12 Jan 2005 14:56:45 -0800 (PST) Message-Id: <4.3.2.7.2.20050112144649.02821b98@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jan 2005 14:56:45 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: Clarification List: Proposed status Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1534512792==_" 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 --=====================_1534512792==_ Content-Type: text/plain; charset="us-ascii" Hi, The attached list contains a status (accept, hold, reject) for each of the 113 clarification items (see my 'Enf WG Last Call' email posted on 12/13/04). Please examine the list (especially the authors and design team!) and post comments: - if you don't agree with a status I've given an item - if you want to discuss any issue with a status of 'Hold', provide replacement text, support or opposition, etc. The WG needs to resolve the Issues list and the Clarifications list quickly, and publish a (hopefully) final update. thanks, Andy --=====================_1534512792==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="status_list_1.txt" ID DOC Status Comment ---------------------------------------------------------------------------- C001 BEEP Accept Typo C002 PROT Accept add short deferred features list appendix C003 PROT Accept remove the netconf-state data model C004 PROT Accept Clarification C005 PROT Accept Clarification C006 PROT Hold Clarification C007 PROT Accept Clarification C008 PROT Accept Clarification C009 PROT Accept Clarification C010 PROT Hold Clarification C011 PROT Accept Clarification C012 PROT Hold Clarification C013 PROT Hold Clarification C014 PROT Accept Clarification C015 PROT Accept Clarification C016 PROT Accept Clarification C017 PROT Accept Clarification C018 PROT Accept Typo C019 PROT Hold Clarification C020 PROT Accept Typo C021 PROT Hold Clarification C022 PROT Accept Typo C023 PROT Accept Clarification C024 PROT Accept Typo C025 PROT Hold Clarification C026 PROT Accept Clarification C027 PROT Hold Clarification C028 PROT Hold Clarification C029 PROT Accept Clarification C030 PROT Accept Clarification C031 PROT Hold Clarification C032 PROT Accept Clarification C033 PROT Accept Clarification C034 PROT Hold Clarification C035 PROT Accept Typo C036 PROT Accept Typo C037 PROT Accept Clarification C038 PROT Accept Clarification C039 PROT Hold Clarification C040 PROT Accept Clarification C041 PROT Accept Clarification C042 PROT Accept Clarification C043 PROT Accept Clarification C044 PROT Accept Clarification C045 PROT Accept Clarification C046 PROT Hold Clarification C047 PROT Hold Clarification C048 PROT Hold Clarification C049 PROT Accept Clarification C050 PROT Accept Clarification C051 PROT Accept Clarification C052 PROT Hold Clarification C053 PROT Hold Clarification C054 PROT Accept Clarification C055 PROT Accept Clarification C056 PROT Accept Clarification C057 PROT Accept Clarification C058 PROT Accept Clarification C059 PROT Hold Clarification C060 PROT Reject Clarification C061 PROT Accept Typo C062 PROT Accept Clarification C063 PROT Accept Clarification C064 PROT Accept Clarification C065 PROT Accept Clarification C066 PROT Hold Units change from minutes to seconds C067 PROT Hold Clarification C068 PROT Hold Clarification C069 PROT Accept Clarification C070 PROT Accept Clarification C071 PROT Accept Clarification C072 PROT Accept Clarification C073 PROT Accept Clarification C074 PROT Accept Clarification; duplicate C075 PROT Reject Clarification; misunderstanding C076 PROT Accept Clarification; Expect -> CLI C077 PROT Accept Typo C078 PROT Hold Clarification C079 PROT Reject Terminology change C080 PROT Accept Clarification; duplicate C081 PROT Accept Clarification C082 PROT Hold Clarification C083 PROT Accept Clarification C084 PROT Accept Clarification C085 PROT Accept Clarification C086 PROT Accept Typo C087 PROT Accept Typo C088 PROT Accept Clarification C089 PROT Accept Clarification; duplicate C090 PROT Accept Clarification; duplicate C091 PROT Accept Typo C092 PROT Accept Clarification C093 PROT Accept Clarification C094 PROT Accept Clarification C095 PROT Accept Clarification C096 PROT Hold Clarification C097 PROT Accept Page format C098 PROT Accept Clarification C099 PROT Accept Typo C100 PROT Accept Clarification C101 PROT Accept Clarification C102 PROT Hold Clarification C103 PROT Accept Clarification C104 PROT Accept Clarification C105 PROT Accept Clarification C106 PROT Accept Typo C107 PROT Accept Clarification C108 PROT Hold URN registration rules C109 PROT Accept Clarification C110 PROT Accept Clarification C111 PROT Hold Clarification C112 PROT Accept Typo C113 PROT Accept Typo --=====================_1534512792==_-- -- 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 Jan 19 18:39:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09918 for ; Wed, 19 Jan 2005 18:39:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrPEh-000K8M-9K for netconf-data@psg.com; Wed, 19 Jan 2005 23:27:39 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrPEc-000K79-UH for netconf@ops.ietf.org; Wed, 19 Jan 2005 23:27:35 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DC080E8A2 for ; Thu, 20 Jan 2005 00:27:33 +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 23060-02; Thu, 20 Jan 2005 00:27:32 +0100 (CET) Received: from james (Ib370.i.pppool.de [85.73.179.112]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 843E59C32; Thu, 20 Jan 2005 00:27:31 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CrPEX-0000l8-VC; Thu, 20 Jan 2005 00:27:30 +0100 Date: Thu, 20 Jan 2005 00:27:29 +0100 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: last call comments on the mapping documents Message-ID: <20050119232729.GA2908@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: netconf@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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=-1.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk I finally managed to write down my last call review comments for the NETCONF mappings documents. The documents seem to be of different quality and it looks like almost nobody is reading them because there are rather obvious things to report (at least in some of the mapping documents) and I have not seen anything on the WG mailing list. Perhaps the WG has lost interest in some of these documents after the decision to require SSH had been taken? I guess the chair will have a hard time to determine support for these documents to going forward if there is just silence... draft-ietf-netconf-ssh-02.txt: 1) The abstracts says: This document describes a simple method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. I suggest to remove the word "simple" as it does not add value and the IETF has some history to label rather complex protocols as "simple". 2) I think sections 2, 3, and 4 stress too much the interactive start of the ssh subsystem. I would prefer that the text really just explains how NETCONF runs over ssh. In other words, I suggest to show the capability exchange currently shown in section 2 in section 3 where it is discussed. All the material specific to typical ssh clients should IMHO go into section 5. If people prefer to keep the command line to start an ssh conversation in the document, then it should at least be changed to accomodate the netconf specific port since I understand that NETCONF over ssh uses a new well-known port to be assigned by IANA. 3) I personally prefer the more traditional notation for message exchanges where lines are prefixed with C: and S:. So I would write down the capabilities exchange in the following notation: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: urn:ietf:params:xml:ns:netconf:base:1.0#lock S: S: S: ]]>]]> C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: ]]>]]> I think this format is easier to read and it works for all the mapping documents in the same way. (But if the editors feel strongly about the XML-stylish way of writing examples down, I am not going to make a big deal out of this.) 4) Section 2.1: replace "user's expect script" with "user's script". 5) Section 2.1: replace $lt; with @lt; in the XML source of the ID. 6) Section 4: some typos in the following text: An agend will processed RPC messages from the manager in the order in which the are received. When the agent processes a command is, the agent shall respond, terminate the SSH session, and close the TCP connection. Replace with: An agent will process RPC messages from the manager in the order in which the are received. When the agent processes a operation, the agent shall respond, terminate the SSH session, and close the TCP connection. 7) Section 4: [user@server]$ exit [user@client]$ I don't think that this part of the example is really needed. 8) Section 5: The techniques described in this document could be used to access the NETCONF protocol over the SSH shell session, or from other shell types such as a console session or a Telnet [RFC0854] connection. I do not really understand what this sentence tries to tell me. Why are "other shell types" or "telnet" relevent in this document? This is the NETCONF over SSH mapping, no more no less. 9) Section 6: I think some nouns in the last sentence should be put into plural form, i.e. configurations and subsystems. Despite the notes listed above (and which can be easily addressed), I think this document looks very reasonable. draft-ietf-netconf-beep-03.txt: a) This document uses the "application protocol" terminology which I dislike (see also my comments on the NETCONF protocol definition). b) Section 1.1: This "bidirectionality" allows for either side to play the role of the manager with no protocol changes. Either side can open a channel. Either size could initiate an RPC. I think the text confuses BEEP's capability to initiate a session from either side with the manager/agent roles actually being used. Perhaps the text simply wanted to say: This "bidirectionality" allows for either side to open a channel. The rationale here is that NETCONF clearly assumes manager/agent roles and it is rather clear who initiates NETCONF transactions. c) Section 1.1: This is particularly important to support operational models that involve small devices connecting to a manager, and those devices that must reverse the management connection in the face of firewalls and NATs. I suggest to remove the work "small" as it does not really add value - I might actually have a big device that prefers to take the initiative (and how decides what small is anyway?). d) Section 1.1: The SASL profile used by BEEP allows for a simple and direct mapping to the existing security model for CLI, while TLS provides a strong well tested encryption mechanism with either server or server and client-side authentication. I learned in the ISMS WG that SASL over TLS is not necessarily secure. Has beep fixed this problem or do we better explain the issue here and/or in the security considerations section? e) Section 2.1: Is the "should" in this section actually a SHOULD? f) Section 2.2: The manager now establishes an NETCONF a new channel. Replace with: The manager now establishes a new channel. g) Section 2.3: I suggest to write NETCONF XML elements exactly as defined in the NETCONF specification. Thus, should be written in lowercase as . h) Section 2.3: There is an odd line break in the last sentence of this section. i) Section 2.5: There are two commands in the BEEP profile. and . I am not a BEEP expert, but I am wondering how the messages are mapped to BEEP. Should the DTD not specify something for them? Note that I did not check the DTD as I am not a BEEP expert. Perhaps /mtr should take a look at it. Note that there are some minor indentation oddities in the DTD part. j) What is really missing in the whole document is an example. Ideally, one would simply use the example contained in the ssh mapping document and show the same example in the BEEP mapping. This would add quite much clarity and allows people to better understand how NETCONF over BEEP messages will actually look like on the wire. k) Section 4: I think it is important to tell IANA precisely that a port number for NETCONF over BEEP/TCP is requested. Or do we assume that all NETCONF over xxxx/TCP mappings share the same port number? In summary, I think the BEEP mapping document still needs some work. Especially an example is missing in my view and the DTD stuff probably needs a bit more work and proof checking. draft-ietf-netconf-soap-03.txt: !) Abstract: Herein, we describe SOAP over HTTP and SOAP over BEEP bindings that yield application protocols sufficient for NETCONF. I suggest to reduce this to the following: Herein, we describe SOAP over HTTP and SOAP over BEEP bindings for NETCONF. @) Introduction: In general, SOAP is a natural application protocol for NETCONF, essentially because of the remote procedure call character of both. This is plain wrong since SOAP is not an RPC protocol. To quote from the W3C SOAP 1.2 primer section 1.1: SOAP is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. Note that section 2 of the mapping document more precisely says that "SOAP is fundamentally an XML messaging scheme" which I can live with. #) Introduction: In some sense, the most important part of the document is the brief WSDL document presented in the Appendix. I agree with this statement and hence I propose to move the WSDL definition from the appendix into the main document (like we have the DTD definition for the BEEP mapping in the main document). $) The writing style in some places seems more appropriate for a white paper instead of a technical specifications. I think the document should not try to "sell" the mapping but rather try to explain concisely how the mapping works. %) Section 2.1: This section talks about "the great innovation found with many XML-based definition languages" but it leaves it totally unclear whether it tries to tell IANA to put schema and/or WSDL definitions into a prominent place or not or whether this is just a discussion of a nice idea which can be safely ignored. ^) Section 2.4: This section discusses several ways to deal with HTTP caches when one uses NETCONF over SOAP over HTTP. It does not say which one is the suggested mechanism to actually deploy. From a specification, I would expect that it gives clear guidance to implementors. So SHOULD/MUST HTTP cache control mechanisms be used for NETCONF over SOAP over HTTP? In a similar vein, the discussion on port numbers explains how flexible WSDL is but it does not clearly say that a special well-know port should be used nor are there any IANA considerations to this effect. &) Section 2.5: Like in the previous section, there is quite some discussion about how to use persistent connections and perhaps HTTP chunking with SOAP over HTTP. I again miss a clear conclusion and concrete hints for implementors what they should/must do. *) Section 2.7.1 uses the old term "substrate" - whatever we end up using, we should try to be consistent in all documents. :) Section 7.3 explains how elements are mapped to SOAP faults. Note that there is a pending issue on the protocol document whether it allows multiple responses or even embedded elements. Depending on the resolution of this issue in the protocol specification, this mapping may or may not work. ;) The example shown in section 7.3 does not match the current NETCONF protocol specification. ') Section 3.3 says the following: Capabilities exchange, if defined through a NETCONF RPC operation, can easily be accommodated in the SOAP binding. This is plain wrong. See section 8.1 in the NETCONF specification. Mapping the capabilities exchange to SOAP/HTTP might actually not be trivial. ,) Section 3.5 probably needs to discuss the operation and how it maps to SOAP/HTTP and SOAP/BEEP. .) I like the example in section 3.6. Like I said before, I would prefer a notation using C: and S: for all the mapping documents. -) The examples shown in section 3.6 and not consistent with the current definition of the NETCONF protocol. The namespace URIs have changed and the element has been removed from . Also the response does not seem to be inline with the current protocol definition. +) The example shown in section 3.6 does not use the Content-Length HTTP header so the end of the message must be indicated by closing the connection. This is probably not a good example since section 2.5 explains to some detail why you want to use persistent connections. ?) Section 4.1 talks about security options and lists a couple of them without saying which must be implemented. Without a strong recommendation, I fail to see how one can reach interoperability. =) As noted before, the document needs to have an IANA considerations section. Summary: The SOAP/HTTP and SOAP/BEEP mapping document has not been updated for a while and misses necessary recommendation what to implement in order to achieve interoperability. /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 Jan 21 12:49:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01050 for ; Fri, 21 Jan 2005 12:49:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cs2jz-000K41-MT for netconf-data@psg.com; Fri, 21 Jan 2005 17:38:35 +0000 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cs2jo-000K0a-Bx for netconf@ops.ietf.org; Fri, 21 Jan 2005 17:38:24 +0000 Received: from az33mta02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j0LHiTKL006225 for ; Fri, 21 Jan 2005 10:44:29 -0700 (MST) Received: from motorola.com (dhcp-173-23-235-140.labs.mot.com [173.23.235.140] (may be forged)) by az33mta02.mot.com (8.13.1/8.13.0) with ESMTP id j0LHcNUM006689 for ; Fri, 21 Jan 2005 11:38:23 -0600 (CST) Message-ID: <41F13E0D.55122417@motorola.com> Date: Fri, 21 Jan 2005 11:38:21 -0600 From: Sandeep Adwankar Organization: Motorola Labs X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: simple prototype Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, I created a simple prototype to access a sample (book!) configuration using NetConf. The prototype allows invoking few NetConf commands through a webapp that connects to NetConf implementation over SOAP. Its pretty early stage for the prototype, I just wanted to put it out there to get some discussion started. Please check that out at http://mobiman.motlabs.com and please send your comments. thanks, Sandeep -- 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 Jan 21 17:34:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29359 for ; Fri, 21 Jan 2005 17:34:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cs77h-0000yp-S0 for netconf-data@psg.com; Fri, 21 Jan 2005 22:19:21 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cs77h-0000yc-0g for netconf@ops.ietf.org; Fri, 21 Jan 2005 22:19:21 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 006B811D9FE; Fri, 21 Jan 2005 14:19:15 -0800 (PST) From: Wes Hardaker To: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents Organization: Sparta References: <20050119232729.GA2908@james> Date: Fri, 21 Jan 2005 14:19:15 -0800 In-Reply-To: <20050119232729.GA2908@james> (Juergen Schoenwaelder's message of "Thu, 20 Jan 2005 00:27:29 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) 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 Juergen> I finally managed to write down my last call review comments Juergen> for the NETCONF mappings documents. Can we get an official chair response on comments about the documents which are now after last call? Being beyond last call means that comments are supposed to be ignored. But if this is not the case, I'd like to write some down as well. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- 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 Jan 21 17:50:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00240 for ; Fri, 21 Jan 2005 17:50:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cs7Ug-0005tV-BK for netconf-data@psg.com; Fri, 21 Jan 2005 22:43:06 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cs7Ue-0005tI-8T for netconf@ops.ietf.org; Fri, 21 Jan 2005 22:43:04 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 15:51:07 +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 j0LMgTl2022029; Fri, 21 Jan 2005 14:42:30 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn6-267.cisco.com [10.21.121.11]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BCZ16587; Fri, 21 Jan 2005 14:43:01 -0800 (PST) Message-Id: <4.3.2.7.2.20050121144202.02014680@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jan 2005 14:43:00 -0800 To: Wes Hardaker From: Andy Bierman Subject: Re: last call comments on the mapping documents Cc: netconf@ops.ietf.org In-Reply-To: References: <20050119232729.GA2908@james> <20050119232729.GA2908@james> 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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 02:19 PM 1/21/2005, Wes Hardaker wrote: >Juergen> I finally managed to write down my last call review comments >Juergen> for the NETCONF mappings documents. > >Can we get an official chair response on comments about the documents >which are now after last call? Being beyond last call means that >comments are supposed to be ignored. But if this is not the case, I'd >like to write some down as well. I don't think we should ignore relevant comments. They will likely come up during IETF Last Call if they don't get addressed now. >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett > >-- >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: 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 Fri Jan 21 18:34:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03882 for ; Fri, 21 Jan 2005 18:34:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cs89u-000Eun-9P for netconf-data@psg.com; Fri, 21 Jan 2005 23:25:42 +0000 Received: from [207.217.121.252] (helo=pop-a065d14.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cs89r-000EuK-BR for netconf@ops.ietf.org; Fri, 21 Jan 2005 23:25:39 +0000 Received: from h-69-3-28-223.snvacaid.dynamic.covad.net ([69.3.28.223] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cs89q-0006Kf-00 for netconf@ops.ietf.org; Fri, 21 Jan 2005 15:25:38 -0800 Message-ID: <001d01c50010$88af6540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050119232729.GA2908@james> Subject: Re: last call comments on the mapping documents Date: Fri, 21 Jan 2005 15:25:21 -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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Wes Hardaker" > To: > Sent: Friday, January 21, 2005 2:19 PM > Subject: Re: last call comments on the mapping documents ... > Can we get an official chair response on comments about the documents > which are now after last call? Being beyond last call means that > comments are supposed to be ignored. But if this is not the case, I'd > like to write some down as well. ... If something is truly broken, beyond beyond last call would be a rather poor reason for failing to fix it. Randy -- 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 Sat Jan 22 02:43:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14485 for ; Sat, 22 Jan 2005 02:43:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsFlb-000Mhk-7r for netconf-data@psg.com; Sat, 22 Jan 2005 07:33:07 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsFlX-000Mgg-Gt for netconf@ops.ietf.org; Sat, 22 Jan 2005 07:33:03 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C57FBE8A3; Sat, 22 Jan 2005 08:33:02 +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 02871-06; Sat, 22 Jan 2005 08:33:01 +0100 (CET) Received: from james (I8417.i.pppool.de [85.73.132.23]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id ADC45E8A1; Sat, 22 Jan 2005 08:33:01 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CsFlU-0000ux-3Y; Sat, 22 Jan 2005 08:33:00 +0100 Date: Sat, 22 Jan 2005 08:33:00 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Cc: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents Message-ID: <20050122073259.GA2449@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Wes Hardaker , netconf@ops.ietf.org References: <20050119232729.GA2908@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jan 21, 2005 at 02:19:15PM -0800, Wes Hardaker wrote: > > Juergen> I finally managed to write down my last call review comments > Juergen> for the NETCONF mappings documents. > > Can we get an official chair response on comments about the documents > which are now after last call? Being beyond last call means that > comments are supposed to be ignored. But if this is not the case, I'd > like to write some down as well. Any wrote on Mon, 13 Dec 2004 20:13:09 -0800: : 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. I have not seen an official announcement that the WGLC for the mappings document has been closed. You might have noticed that my comments on the protocol document came in just before the deadline and I actually removed the the mapping documents from my agenda. It was the message above which put the review of the mapping documents back on my agenda again. If we talk about formal things here, then I would be more concerned about the lack of comments rather the timing of the comments. As you know, documents going to the IESG need to demonstrate a significant level of community interest. So I can only encourage people to provide feedback if they want all these mapping documents to move forward. /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: