From owner-netconf@ops.ietf.org Fri Aug 05 03:43:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wry-000624-O9 for netconf-archive@megatron.ietf.org; Fri, 05 Aug 2005 03:43:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22765 for ; Fri, 5 Aug 2005 03:43:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0wlH-0007jq-B3 for netconf-data@psg.com; Fri, 05 Aug 2005 07:36:59 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0wlF-0007jS-0o for netconf@ops.ietf.org; Fri, 05 Aug 2005 07:36:57 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j757asN9010868; Fri, 5 Aug 2005 09:36:55 +0200 (CEST) From: Simon Leinen Message-ID: <17139.5910.974990.514652@diotima.switch.ch> Date: Fri, 5 Aug 2005 09:36:54 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1fO7pV4eQ2" Content-Transfer-Encoding: 7bit To: netconf@ops.ietf.org Subject: Forward: Notes from NETCONF interop tests X-Mailer: VM 7.18 under Emacs 21.3.1 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` X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --1fO7pV4eQ2 Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Radu State from the MOME team, who coordinated last week's NETCONF interop event, allowed me to forward his notes to the list. Enjoy! -- Simon. --1fO7pV4eQ2 Content-Type: message/rfc822 Content-Description: forwarded message MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Received: from zinal.switch.ch ([130.59.108.21]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1DyUd4-0006kJ-00 for simon.leinen@switch.ch; Fri, 29 Jul 2005 15:10:22 +0200 Received: from localhost ([::1] helo=zinal.switch.ch) by zinal.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DyUd4-0005O1-DL for simon.leinen@switch.ch; Fri, 29 Jul 2005 15:10:22 +0200 Received: from localhost ([::1] helo=zinal.switch.ch) by zinal.switch.ch with esmtp (Exim 4.43) id 1DyUWH-00038V-9M for simon.leinen@switch.ch; Fri, 29 Jul 2005 15:03:21 +0200 Received: from [152.81.1.70] (helo=macker.loria.fr) by zinal.switch.ch with esmtp (Exim 4.43) id 1DyUWH-00038N-6T for simon@switch.ch; Fri, 29 Jul 2005 15:03:21 +0200 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5B83C51677 for ; Fri, 29 Jul 2005 15:03:20 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from webloria.loria.fr (webloria.loria.fr [152.81.144.22]) by macker.loria.fr (Postfix) with ESMTP id B0AAE4F36A for ; Fri, 29 Jul 2005 15:03:19 +0200 (CEST) Received: from open-30-251.ietf63.ietf.org (open-30-251.ietf63.ietf.org [86.255.30.251]) by www.loria.fr (IMP) with HTTP for ; Fri, 29 Jul 2005 15:03:19 +0200 Message-ID: <1122642199.42ea2917ab5f9@www.loria.fr> User-Agent: Internet Messaging Program (IMP) 3.2.4 X-SWITCH-MailScanner: Found to be clean X-SWITCH-SCANNER: scanned X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on diotima.switch.ch X-Spam-Level: From: Radu.State@loria.fr To: simon@switch.ch Subject: MOME notes Date: Fri, 29 Jul 2005 15:03:19 +0200 X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.3 X-SWITCH-MailScanner-SpamCheck: spam, SpamAssassin (score=0.008, required 0, BAYES_50 0.00, NO_REAL_NAME 0.01) Content-Transfer-Encoding: quoted-printable Please find the report of the MOME meeting for NetConf Radu State MOME Interoperability Notes 28-29 July, Paris, FRANCE Participants: NEC Labs, Germany WIPRO, Germany LORIA, France POSTECH, Korea 1)=09Partners tested their managers and agents with respect to a series= of predefined test cases specified on the MOME website. Each partner teste= d its manager /agent solution with every other partner. 2)=09Implementation languages: a.=09One partner used Python for development b.=09Three partners used C for development 3)=09The four major problems identified during the testing were: a.=09SSH support for NetConf was initially difficult due to the differe= nt authentication types allowed by SSH (interactive password, public key e= tc.) and some offline agreement had to be done. Finally however, these issues we= re solved. b.=09SSH subsystem for Netconf. Some implementations use it exclusively= , while others work with/without it. Event for those implementations that use i= t, the name of the subsystem was not consistent among all the implementations.= c.=09Message separator. Messages are separated with a special character= string in Netconf/SSH draft. Some implementations use it, while others don=92t re= ly on this mechanism. d.=09Common data model. Although a basic data model (related to the int= erfaces) was specified for the MOME event, some implementations did not effectiv= ely implement it. This issue was solved on a case per case basis, where man= ager applications were customized to fit a specific agent. 4)=09The interoperability results are rather positive. All 4 manager ap= plications succeed to connect and perform requests on two out of the four tested a= gents. Two agents could not be connected to, due to missing SSH support and de= limiter problem (mentioned earlier). Suggestions for the IETF working group 1)=09Better SSH descriptions and use cases 2)=09Common data model proposal --1fO7pV4eQ2-- -- 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 Aug 05 15:41:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E184b-0000CD-23 for netconf-archive@megatron.ietf.org; Fri, 05 Aug 2005 15:41:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28388 for ; Fri, 5 Aug 2005 15:41:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E17uk-000BxZ-FE for netconf-data@psg.com; Fri, 05 Aug 2005 19:31:30 +0000 Received: from [85.73.188.116] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E17uh-000BxE-Ce for netconf@ops.ietf.org; Fri, 05 Aug 2005 19:31:27 +0000 Received: by boskop.local (Postfix, from userid 501) id E34DD3A71EC; Fri, 5 Aug 2005 21:31:25 +0200 (CEST) Date: Fri, 5 Aug 2005 21:31:25 +0200 From: Juergen Schoenwaelder To: Radu State Cc: netconf@ops.ietf.org Subject: Re: Forward: Notes from NETCONF interop tests Message-ID: <20050805193125.GA26755@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Radu State , netconf@ops.ietf.org References: <17139.5910.974990.514652@diotima.switch.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17139.5910.974990.514652@diotima.switch.ch> User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Aug 05, 2005 at 09:36:54AM +0200, Simon Leinen / Radu State wrote: > c. Message separator. Messages are separated with a special > character string in Netconf/SSH draft. Some implementations use it, > while others don?t rely on this mechanism. I doubt very much that you can write a correct implementation without the separator mechanism. > Suggestions for the IETF working group > > 1) Better SSH descriptions and use cases It would be extremely useful to know what is lacking in the ID. To me, it sounds a bit like everything is indeed correctly written down but the implementors either used a pretty old ID for the implementation work or they glanced over some important paragraphs. If my feeling is right, there is nothing that can be fixed. If I am wrong, I think it would be extremely helpful if the interoperability testers can come up with a proposal for the changes that would have helped them to not run into this problem. /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 Tue Aug 09 16:25:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2af7-0000qq-0d for netconf-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:25:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12380 for ; Tue, 9 Aug 2005 16:25:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2aSr-000Al1-PZ for netconf-data@psg.com; Tue, 09 Aug 2005 20:12:45 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2aSo-000Ake-Hs for netconf@ops.ietf.org; Tue, 09 Aug 2005 20:12:42 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j79KCewI007860; Tue, 9 Aug 2005 22:12:40 +0200 (CEST) From: Simon Leinen Message-ID: <17145.3640.586010.259108@diotima.switch.ch> Date: Tue, 9 Aug 2005 22:12:40 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="e/+kZnCIsU" Content-Transfer-Encoding: 7bit To: netconf@ops.ietf.org Subject: Summary from MOME interoperability testing event X-Mailer: VM 7.18 under Emacs 21.3.1 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` X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --e/+kZnCIsU Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Here's a more comprehensive summary of the results of the NETCONF interoperability tests from the week before IETF. Contributors include Radu State and Prof. James W. Hong. The final version will be integrated into a MOME deliverable which should eventually show up on http://www.ist-mome.org/publications/ -- Simon. --e/+kZnCIsU Content-Type: text/plain Content-Disposition: inline; filename="netconf_interop_result.txt" Content-Transfer-Encoding: 7bit Netconf Interoperability Testing Summary (July 28-29, 2005, Paris, France) Participants: 1. NEC Labs, Germany 2. WIPRO, Germany 3. LORIA, France 4. POSTECH, Korea 1) Partners tested their Netconf managers and agents using SSH as their transport mechanism with respect to a series of predefined test cases specified on the MOME website. Each partner tested its manager /agent solution with every other partner. 2) Implementation languages: a. One partner used Python for development (LORIA) b. Two partners used C for development (NEC, POSTECH) c. One partner used Java for development (WIPRO) - verification is needed. 3) The four major problems were identified during the testing were: A. SSH subsystem for Netconf. There exist different types of SSH subsystems. Some implementations used 1) command subsystem, while others used 2) port forwarding subsystem or 3) custom subsystem (see http://wwww.eldos.com/sbb/articles/1945.php for categorization). Using different subsystems by different implementations has made it difficult to test each other of their Netconf functionalities. B. Lack of common data model. There were two problems with the common data model. Although a basic data model (related to the interfaces) was specified for the MOME event, some implementations did not properly implement it. This issue was solved on a case by case basis, where manager applications were customized to fit to a specific agent. The specified common data model was network interface. When an operation was performed on this, the network interface in the device being tested was not accessible any more. Thus, we could not test the operation. C. Message separator. Messages are separated with a special character string(]]>]]>) in the Netconf/SSH draft. Some implementations used it, while others did not use this. D. Different authentication types in SSH. Implementations used different types allowed by SSH (interactive/non-interactive password, public key, etc.) and some offline agreement had to be done. Finally however, these issues were solved. E. Pipelined Requests. One implementation allowed multiple requests from a manager. How to process this kind of multiple requests were not clearly specified in the draft. 4) Summary A. The interoperability testing event was useful to discover who has been implementing the Netconf draft and to discover areas to be improved in the draft. B. The results were not too disappointing. All 4 manager applications succeeded to connect and perform requests on two out of the four tested agents. Two agents could not be connected due to missing SSH support and delimiter problem (mentioned earlier). C. Because of different ways of implementing and spending most of the time in adjusting to the other implementation, we could not really test the Netconf functions or the test scenarios as specified in the test spec. 5) Suggestions for the IETF working group A. Better SSH descriptions and use cases B. Common data model proposal C. Better operation descriptions and use cases 6) Suggestions for the developers A. Continuous exchange of implementation information B. Remote testing if possible --e/+kZnCIsU-- -- 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 Aug 10 09:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qRv-0002Tm-VG for netconf-archive@megatron.ietf.org; Wed, 10 Aug 2005 09:16:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26555 for ; Wed, 10 Aug 2005 09:16:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2qGm-0009pM-9l for netconf-data@psg.com; Wed, 10 Aug 2005 13:05:20 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2qGg-0009oM-PO for netconf@ops.ietf.org; Wed, 10 Aug 2005 13:05:14 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7AD3TH29786 for ; Wed, 10 Aug 2005 09:03:29 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Notes from Offline Netconf Data Model Discussion Date: Wed, 10 Aug 2005 09:04:53 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B404613D5E@zcarhxm2.corp.nortel.com> Thread-Topic: Notes from Offline Netconf Data Model Discussion thread-index: AcWdrBlOGBGQLn6GQxW9uB9cccbSfA== From: "Sharon Chisholm" To: Cc: "Netconf Data Model Discussion" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Here are my notes from the offline netconf data model discussion from the Monday in Paris. We also talked about some of the other specifications, but I will send some thoughts on of that separately. 1. It was noted we may want to reorganize the document. The current division into 'considerations for ...' is more geared towards someone writing the specification rather than someone trying to implement it. 2. There are typos in the examples in section 2.2.2 3. There was discussion about whether we really needed the element status described in section 2.2.3. Maybe. Maybe not. 4. It was noted that the schema-level conformance defined in section 2.2.4, while machine readable without requiring an superfluous construct did not cover conditional conformance. If this is BGP, then this object is mandatory, for example. Is this a requirement? 5. Section 2.3 describes access control and it was noted there is a proposal to spin this out as a separate work item. It was observed that the concept of a resource category was powerful. It was suggested that people read about SAML. 6. There was a lot of discussion around what was required for backwards compatibility. 6.1 Here is the use case discussed. =20 V3 (upgrade) =20 V3 V2 V1 [NE-1] [NE-2] [NE-3] \------------- ------------------/ \-----/ | Manager/Operator The scenarios depicted are a management application being able to communicate with and configure different versions of a schema on different network elements. In addition, at some point NE-2 upgrades its version and now supports V3. 6.2 It was suggested that whether or not one could write an XSLT function to transform from one version to the next was an interesting test for backwards compatibility. 6.3 The 'isRequired' flag used in some XML-based solutions could be used to flag when a version 3 of a Schema cannot accept version 2 of a schema and auto-fill in a particular field. This way either defaults can be provided or the request can fail in a predictable way. It would get added to those elements that are can't be defaulted. 6.4 It was observed that enumerated lists are sometimes just lists that one can add new values to but other times they are state machines which some felt should not be changed between versions. This is a case of the same syntax with two different semantics? Can 'isRequired' be applied to enumerated lists to solve this so we can tell the difference? 7. There was discussion about whether version information should also be available in other languages or whether the header of the XML Schema should identify the language used within the Schema. 8. There was discussion about IANA namespace management. It was suggested that the 'no document required' method with one big namespace was one option. There was not general agreement on that though.=20 9. It was suggested that we work with w3C to address any gaps we see in what they have produced. 10. There was a lot of discussion around the recommendation on containers for lists in section 4.5. Consider the following content on a bookshelf shelf 1: book, book, book, book shelf 2: book, book, cd, book, book, cd, cd, snow globe In both cases the shelves themselves act as a natural container for the content. The suggestion to wrap plural books with a tag is in the first case superfluous in the second case, it actually provides a couple of options which loses the order of the items on the shelf or Which has the singular cd not wrapped and the plural one wrapped and puts more emphasis on the grouping of items than likely makes sense for items sitting on a bookshelf. Note that the shelf is a naturally occurring item in system, while the wrappers of and are mere artefacts of modeling. While these artefacts are useful in some cases, in this one, they seem to be getting in the way. Some ways to improve this section, would be to suggest that the artificial wrapper is only recommended when no natural wrapper exists. Also, an attribute that indicates when something is only a container could help. We could also not talk about naming of these wrappers, which would allow the to become the wrapper for all the books, cds and snow globes. The idea of a 'compound document' might be applicable here. TBD. 11. The document needs to discuss accessing instance information. 12. Proper tag names as described in section 5.2.1 was discussed. The current text, which had its beginnings in the netconf protocol specification, indicates only ASCII (7-bit). It would be good to understand why that is. While this would be necessary for IETF published Schema, it potentially does not need to be the case for proprietary Schema and those published by other organizations. It was noted that a better explanation of 'lower Camel' is needed since while this is what SNMP used for naming, not everyone is familiar with the term. 13. Error messages as defined in section 5.3 were discussed. While there was some wish for more format for the error messages, the framework we shall need to fit into has already been defined by the netconf protocol. There was discussion on whether the error messages were static, or contained instance information. For example, does the error message say 'Unable to read book' or does it say 'unable to read 'War and Peace''? Does this instance information require something like syslog SD-params or is something more like C printf statements sufficient? Option 1. "I can't read this book"=20 Option 2. "I can't read ", ->=20 "I can't read 'War and Peace'";=20 "I can't read 'Ulysses'" Option 3: "I can't read this book" -> "I can't read this book War and Peace EnglishVery Small "I can't read this book Ulysses Very Hard Note that in option 3 I have shown no predefinition of what additional information would be supplied. An option 4 could be a combination of option 2 where the information is predefined and option 3 where the information is formatted in xml. This might run into some problems with the fact that technically the tag we are cramming all this into is expecting a string. The syntax for option 3 and 4 could also be more syslog-like, creating I guess option 5 and 6. 14. In discussion of item 5.5 'Granularity of a data model', Dan has agreed to provide some explanation and examples. 15. In section 6.1 and 6.2, it was noted that we still need examples and to confirm that keyref is useable for us. 16. For section 7.1 which talks about Schema Identity, it was suggested that we should look at Dublin Core and use that instead. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- 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 Aug 15 15:04:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kG2-00051H-2D for netconf-archive@megatron.ietf.org; Mon, 15 Aug 2005 15:04:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19910 for ; Mon, 15 Aug 2005 15:04:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4k6O-0004hw-67 for netconf-data@psg.com; Mon, 15 Aug 2005 18:54:28 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4k6M-0004he-Gm for netconf@ops.ietf.org; Mon, 15 Aug 2005 18:54:26 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7FIsNC02159 for ; Mon, 15 Aug 2005 14:54:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Netconf: New Work: Asynchronous Notifications Date: Mon, 15 Aug 2005 14:54:00 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4046FC449@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf: New Work: Asynchronous Notifications thread-index: AcWhyrMESwLd1019TxWb9EQGmXX1Xg== From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I head off for holidays in couple days, but just wanted to get some discussion started beforehand. Following up on the discussion we had in Paris. I propose: 1. That the "Netconf Event Message" work falls within the current version of the charter as identified by the following text 'Provides support for asynchronous notifications' 2. That we accept the "Netconf Event Message" internet draft as a working group document and the starting point of such a solution. =09 http://ftp.ietf.org/internet-drafts/draft-chisholm-netconf-event-00.txt Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- 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 Aug 15 21:26:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4qDw-0001Ed-9z for netconf-archive@megatron.ietf.org; Mon, 15 Aug 2005 21:26:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18143 for ; Mon, 15 Aug 2005 21:26:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4q5D-000BhD-Ke for netconf-data@psg.com; Tue, 16 Aug 2005 01:17:39 +0000 Received: from [205.152.59.67] (helo=imf19aec.mail.bellsouth.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4q59-000Bgw-Jt for netconf@ops.ietf.org; Tue, 16 Aug 2005 01:17:35 +0000 Received: from ibm60aec.bellsouth.net ([68.214.179.11]) by imf19aec.mail.bellsouth.net with ESMTP id <20050816011734.TYI28108.imf19aec.mail.bellsouth.net@ibm60aec.bellsouth.net> for ; Mon, 15 Aug 2005 21:17:34 -0400 Received: from localHost ([68.214.179.11]) by ibm60aec.bellsouth.net with ESMTP id <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost>; Mon, 15 Aug 2005 21:17:33 -0400 Date: Mon, 15 Aug 2005 21:21 -0400 (EDT) From: Len Nieman X-Mailer: MailRoom for Internet v3.3d (www.SierraSol.com) To: netconf@ops.ietf.org CC: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de, Eliot Lear Subject: Re: Scalability of Netconf Message-Id: <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk More likely a single NMS trying to manage 800 - 1,200 routers. Len >Date: Wed, 06 Jul 2005 12:15 -0400 (EDT) >From: Eliot Lear >To: j.schoenwaelder@iu-bremen.de >CC: netconf@ops.ietf.org, > nmrg@ibr.cs.tu-bs.de >Subject: Re: Scalability of Netconf > >Yeah, I just had this funny thought of 1200 NMSes trying to configure a >router. That's the sort of locking contention we certainly did NOT >optimize for! > >Eliot > > >Juergen Schoenwaelder wrote: >> On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen Schoenwaelder wrote: >> >> >>>I am running this script on a 3GHz Pentium with 512 MB Ram (so really >>>nothing high end for a management system) running Linux 2.6.10. I >>>keep 300 connections open and the funny thing is that this box does >>>not at really get stressed by this. The load never went above 0.1% >>>and was most of the time significantly below. The memory used excluding >>>buffers was ~235 MB. >> >> >> Today I was running 1200 ssh connections using the same basic script >> on the same box. The load again never went above 0.1 while the memory >> usage went up to ~494 MB. Shall I try 10.000 tomorrow? With 2GB of >> memory this should be possible. The two Linux XEON servers that play >> the remote end for 600 connections each do not seem to bother much >> about all this. >> >> /js >> > >-- >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 Tue Aug 16 12:17:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E548V-0004Bu-Fb for netconf-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:17:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20987 for ; Tue, 16 Aug 2005 12:17:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E53zo-0004dI-Od for netconf-data@psg.com; Tue, 16 Aug 2005 16:09:00 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E53zl-0004cr-4X for netconf@ops.ietf.org; Tue, 16 Aug 2005 16:08:57 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Aug 2005 09:08:57 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GG8mQM020843; Tue, 16 Aug 2005 09:08:48 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp468.cisco.com [10.61.65.212]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7GG5P5S019055; Tue, 16 Aug 2005 09:05:25 -0700 Message-ID: <43020F93.9090209@cisco.com> Date: Tue, 16 Aug 2005 18:08:51 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Len Nieman CC: netconf@ops.ietf.org, j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: Re: Scalability of Netconf References: <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost> In-Reply-To: <20050816011733.CUGB3347.ibm60aec.bellsouth.net@localHost> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=95; t=1124208327; x=1124640527; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20Scalability=20of=20Netconf| From:Eliot=20Lear=20| Date:Tue,=2016=20Aug=202005=2018=3A08=3A51=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=evkYaPY5ZnQLDOU+Rudwy7eo0pN48mV8SH2y8/pUUf5hfl03xoqO5bp4U8RGyOPUKXX/2DzA CJOYFS4RSNdpPNZo/THIkxDCzTRumdQG2UByPcitiSD/Q1TNRJZXiJ8UQ7OjUjVSpBYLi7yErBw hbusQw01/b5LJkU15pqM2mok= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Len Nieman wrote: > More likely a single NMS trying to manage 800 - 1,200 routers. We'd like to aim for higher. 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 Tue Aug 16 13:44:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55Ua-0002yi-0L for netconf-archive@megatron.ietf.org; Tue, 16 Aug 2005 13:44:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25238 for ; Tue, 16 Aug 2005 13:44:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E55PC-000BPJ-8Z for netconf-data@psg.com; Tue, 16 Aug 2005 17:39:18 +0000 Received: from [12.104.153.35] (helo=mail.packeteer.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E55P9-000BP3-BO for netconf@ops.ietf.org; Tue, 16 Aug 2005 17:39:15 +0000 Received: from mailcup1.packeteer.com ([10.100.99.30]) by mail.packeteer.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Aug 2005 10:39:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Scalability of Netconf Date: Tue, 16 Aug 2005 10:39:13 -0700 Message-ID: <3F8201EE931AD34E90B4564631A2A9689E9D54@mailcup1.packeteer.com> Thread-Topic: Scalability of Netconf Thread-Index: AcWiAZRmQ57B6yPhTQyFGQG87LGUugAhu3iQ From: "Branislav Meandzija" To: "Len Nieman" , Cc: , , "Eliot Lear" X-OriginalArrivalTime: 16 Aug 2005 17:39:14.0420 (UTC) FILETIME=[6B4AA340:01C5A289] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes. How about the case where devices update their config autonomously = and communicate this back to the NMSs which need to reconcile the = updates and re-distribute them? Branislav > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Len Nieman > Sent: Monday, August 15, 2005 6:21 PM > To: netconf@ops.ietf.org > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de; Eliot Lear > Subject: Re: Scalability of Netconf >=20 >=20 > More likely a single NMS trying to manage 800 - 1,200 routers. >=20 > Len >=20 > >Date: Wed, 06 Jul 2005 12:15 -0400 (EDT) > >From: Eliot Lear > >To: j.schoenwaelder@iu-bremen.de > >CC: netconf@ops.ietf.org, > > nmrg@ibr.cs.tu-bs.de > >Subject: Re: Scalability of Netconf > > > >Yeah, I just had this funny thought of 1200 NMSes trying to=20 > configure a > >router. That's the sort of locking contention we certainly did NOT > >optimize for! > > > >Eliot > > > > > >Juergen Schoenwaelder wrote: > >> On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen=20 > Schoenwaelder wrote: > >>=20 > >>=20 > >>>I am running this script on a 3GHz Pentium with 512 MB Ram=20 > (so really > >>>nothing high end for a management system) running Linux 2.6.10. I=20 > >>>keep 300 connections open and the funny thing is that this=20 > box does=20 > >>>not at really get stressed by this. The load never went above 0.1%=20 > >>>and was most of the time significantly below. The memory=20 > used excluding > >>>buffers was ~235 MB. > >>=20 > >>=20 > >> Today I was running 1200 ssh connections using the same=20 > basic script > >> on the same box. The load again never went above 0.1 while=20 > the memory=20 > >> usage went up to ~494 MB. Shall I try 10.000 tomorrow? With 2GB of > >> memory this should be possible. The two Linux XEON servers=20 > that play=20 > >> the remote end for 600 connections each do not seem to bother much=20 > >> about all this. > >>=20 > >> /js > >>=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 > -- > 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 Thu Aug 18 11:46:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mbZ-0005Zj-U0 for netconf-archive@megatron.ietf.org; Thu, 18 Aug 2005 11:46:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13369 for ; Thu, 18 Aug 2005 11:46:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5mSF-000MBZ-Gs for netconf-data@psg.com; Thu, 18 Aug 2005 15:37:19 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5mSD-000MBL-6D for netconf@ops.ietf.org; Thu, 18 Aug 2005 15:37:17 +0000 Received: (qmail 14324 invoked by uid 78); 18 Aug 2005 15:37:01 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by 10.49.34.62 with SMTP; 18 Aug 2005 15:37:01 -0000 Message-ID: <4304AB17.7030508@andybierman.com> Date: Thu, 18 Aug 2005 08:36:55 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: Decision on NETCONF charter extensions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_BY_IP autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Simon and I have been discussing the status of the WG with our ADs. The four of us do not believe that the charter extension proposals presented to date are sufficiently complete, or widely accepted by the WG, to justify new NETCONF work at this time. As Bert stated at the WG meeting in Paris, the following goals have much higher priority: - getting more implementations of the current document set - getting a show of buy-in from operators that they are indeed playing/testing with implementations - getting a nod/ack from operators that the protocol makes sense and will be used We need to see operator buy-in before we go too far down this path, and end up in the same situation as we ended up with SNMP. W.r.t. new work by this WG, the ADs would like to see the proponents of such new work: - work hard on implementations of the current specs - show prototypes of implementations of the suggested enhancements - work hard on initial data modeling specs and show that there is convergence in thinking before we charter it. (remember the SMIng efforts? we do not want to end up in the same deadlock) - show prototype implementations of such data modeling work so we get a feel of what it is. For all of the above, get operators to show interest and buy-in. 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: From owner-netconf@ops.ietf.org Thu Aug 18 13:12:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nwZ-0005rb-SM for netconf-archive@megatron.ietf.org; Thu, 18 Aug 2005 13:12:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18206 for ; Thu, 18 Aug 2005 13:12:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5nog-0005wm-Ct for netconf-data@psg.com; Thu, 18 Aug 2005 17:04:34 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5nod-0005w4-P7 for netconf@ops.ietf.org; Thu, 18 Aug 2005 17:04:31 +0000 Received: (qmail 6766 invoked by uid 78); 18 Aug 2005 16:19:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail7.netsol.inquent.com with SMTP; 18 Aug 2005 16:19:16 -0000 Message-ID: <4304B503.1060308@andybierman.com> Date: Thu, 18 Aug 2005 09:19:15 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: "Wijnen, Bert (Bert)" , isms@ietf.org, Margaret Wasserman , netconf Subject: Re: [Isms] RE: Call for consensus and a proposal References: <7D5D48D2CAA3D84C813F5B154F43B15507D32583@nl0006exch001u.nl.lucent.com> <43047060.6050806@cisco.com> In-Reply-To: <43047060.6050806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eliot, I cc:ed the NETCONF WG because you are proposing changes to NETCONF over SSH to the ISMS WG. In theory, I agree with your goal of a single transport for both NETCONF and ISMS, and I like your proposal. If it had been on the table at the interim meeting where this was all worked out, I think it would have been selected the one and only NETCONF transport. However, the NETCONF WG took a long time to decide on 3 different transports. I don't really know how useful NETCONF over SOAP is going to be, but I bet a few people would complain if we told them (at the last minute) that NETCONF over BEEP is being removed. (It's not!) Any new NETCONF features need to be done as proprietary extensions first, shown to be useful in real operator environments, and then gain wide acceptance from the WG. I would support new NETCONF work today that met this criteria. Andy >Bert, > >Forgive me but I'm frustrated. I won't just complain, however. I have >a proposal (I've been chewing on it for a bit). See below. > >How could call home functionality possibly have ended up in the charter? > Nobody knew we would come close to using a TCP-based approach until >March when an WG-shaking event occurred. Every approach submitted and >envisioned prior to that was a new security model using the existing UDP >transport. > >But we are here now, and we are positioned to either take advantage of >or miss a huge opportunity or create a mess. Anyone who thinks that >firewalls or NATs routinely implement the proxy function of RFC 3413 >hasn't taken a good look at the market lately. Let's at least make the >best of the position we find ourselves and take corrective action. I >hate to say it, but take a look at Windows. Most of the time management >connections are issued by clients. Really this is no different. > >Let me refresh your and Dave's memory on the matter of NETCONF. The >initial authors of the base spec ALWAYS envisioned a call home function. > We got it for free with BEEP, which was part of the core specification >until the working group forced us to separate out protocol mappings. We >even had it in an early draft of the SSH specification, but cut it out >[too much channel cruft as you may recall]. What's more, I claim it's >easier than ever to do now. > >In the netconf ssh draft, what I propose is that we add some text around >the following idea: > > - when the manager contacts the agent, it will request the "netconf" > SSH service. > - when the agent contacts the manager, it will request the > "netconf-turn" service (or "netconf-callhome" if you prefer - I > would like to reuse the SMTP term since they invented the concept, > so far as I can recall). > - Add text in security considerations about how to handle identity > for the call home approach. I claim it's No Big Deal. It just > says that the client process for callhome should probably tie to > an appropriately authorized user for the function being managed. > >This mechanism has the added benefit of not requiring pre-existing >implementations to change their code. The reason I want it in round one >of netconf is that I would if I could nuke all other transport options >including BEEP. Options are a necessary evil. Transport options are an >UNnecessary evil. > >Rinse and repeat. The same process can be applied to SNMP. There is no >difference. Presto. Yes, it took me a few days to come up with this in >a simple way. And yes, there are a few issues surrounding the mapping >for traps, but I claim we can solve those as well to peoples' >satisfaction. What do people think? > >The result is a single mandatory transport for both NETCONF AND BEEP. >Similar call home functionality for both. > >This is NOT Eliot's "would be nice" for a protocol. It's really >important for our customers. We've always envisioned having call home >functionality in our products. In fact we've had proprietary solutions >for years (which is how we know it's important to our customers). The >other option - and they're already talking about it - is SNMP over SIP. > I kid you not. Sort of makes me think of running IP over a DHCP >option, but heck anything's possible. > >In summary, please let's be elegant. Let's kill two birds with one >stone. Let's make it easier on all of our customers in the future. And >let's codify something that everyone else has been doing for years. > >My connectivity will be sketchy for the next few days, but will continue >as best I can (although I don't want to beat a dead horse). > >Eliot >ps: yes, I've offered to put this into real draft words for Dave. > > > > -- 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 Aug 18 23:22:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5xSM-0002CI-Kw for netconf-archive@megatron.ietf.org; Thu, 18 Aug 2005 23:22:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25413 for ; Thu, 18 Aug 2005 23:22:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5xJF-0008hb-Le for netconf-data@psg.com; Fri, 19 Aug 2005 03:12:45 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5xJF-0008hO-0u for netconf@ops.ietf.org; Fri, 19 Aug 2005 03:12:45 +0000 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 491312; Thu, 18 Aug 2005 22:16:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507A50926@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15507A50926@nl0006exch001u.nl.lucent.com> Date: Thu, 18 Aug 2005 23:11:47 -0400 To: "Wijnen, Bert (Bert)" , ted.goddard@icesoft.com From: Margaret Wasserman Subject: Re: AD review for: draft-ietf-netconf-ssh-04.txt Cc: "Netconf (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi All, A few comments on Bert's AD review: At 9:19 PM +0200 7/29/05, Wijnen, Bert (Bert) wrote: >- I believe we discussed that netconf over ssh was going > to be mandatory to implement. But I cannot find a statement > about that. Neither in this doc, not in the protocol doc. I think that the best way to handle this would be to put a statement in the base NETCONF protocol document with a normative reference to the NETCONF over SSH document, but I'm open to other choices. Thoughts? Bert, I'll be submitting a new version later this week that should have the new boilerplate. I'll also address your other comments, and the comments that others have made about the need for IANA to register the "netconf" SSH subsystem name. 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 Aug 19 07:06:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64hQ-00071h-3M for netconf-archive@megatron.ietf.org; Fri, 19 Aug 2005 07:06:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26388 for ; Fri, 19 Aug 2005 07:06:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E64ap-000Lxj-2g for netconf-data@psg.com; Fri, 19 Aug 2005 10:59:23 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E64am-000Lx4-F2 for netconf@ops.ietf.org; Fri, 19 Aug 2005 10:59:20 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7JAx6qf021447; Fri, 19 Aug 2005 05:59:07 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Aug 2005 12:59:06 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D3286C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Margaret Wasserman , ted.goddard@icesoft.com Cc: "Netconf (E-mail)" Subject: RE: AD review for: draft-ietf-netconf-ssh-04.txt Date: Fri, 19 Aug 2005 12:59:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk OK, looking forward to it. WG chairs, is the proposed solution for the "SSH is mandatory" for you and your WG? Bert > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Friday, August 19, 2005 05:12 > To: Wijnen, Bert (Bert); ted.goddard@icesoft.com > Cc: Netconf (E-mail) > Subject: Re: AD review for: draft-ietf-netconf-ssh-04.txt > > > > Hi All, > > A few comments on Bert's AD review: > > At 9:19 PM +0200 7/29/05, Wijnen, Bert (Bert) wrote: > >- I believe we discussed that netconf over ssh was going > > to be mandatory to implement. But I cannot find a statement > > about that. Neither in this doc, not in the protocol doc. > > I think that the best way to handle this would be to put a statement > in the base NETCONF protocol document with a normative reference to > the NETCONF over SSH document, but I'm open to other choices. > Thoughts? > > Bert, I'll be submitting a new version later this week that should > have the new boilerplate. I'll also address your other comments, and > the comments that others have made about the need for IANA to > register the "netconf" SSH subsystem name. > > 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 Aug 19 13:20:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AXY-0000X1-NW for netconf-archive@megatron.ietf.org; Fri, 19 Aug 2005 13:20:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17660 for ; Fri, 19 Aug 2005 13:20:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6AP1-000B4P-VI for netconf-data@psg.com; Fri, 19 Aug 2005 17:11:35 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E6AOw-000B46-ND for netconf@ops.ietf.org; Fri, 19 Aug 2005 17:11:31 +0000 Received: (qmail 10717 invoked by uid 78); 19 Aug 2005 17:11:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail7.netsol.inquent.com with SMTP; 19 Aug 2005 17:11:29 -0000 Message-ID: <430612C1.1020702@andybierman.com> Date: Fri, 19 Aug 2005 10:11:29 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: Margaret Wasserman , ted.goddard@icesoft.com, "Netconf (E-mail)" Subject: Re: AD review for: draft-ietf-netconf-ssh-04.txt References: <7D5D48D2CAA3D84C813F5B154F43B15507D3286C@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D3286C@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Wijnen, Bert (Bert) wrote: >OK, looking forward to it. > >WG chairs, is the proposed solution for the "SSH is mandatory" >for you and your WG? > > This is fine. The WG agreed over a year ago on the mandatory mapping, but never put the right words in the documents to support it. >Bert > > > Andy >>-----Original Message----- >>From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>Sent: Friday, August 19, 2005 05:12 >>To: Wijnen, Bert (Bert); ted.goddard@icesoft.com >>Cc: Netconf (E-mail) >>Subject: Re: AD review for: draft-ietf-netconf-ssh-04.txt >> >> >> >>Hi All, >> >>A few comments on Bert's AD review: >> >>At 9:19 PM +0200 7/29/05, Wijnen, Bert (Bert) wrote: >> >> >>>- I believe we discussed that netconf over ssh was going >>> to be mandatory to implement. But I cannot find a statement >>> about that. Neither in this doc, not in the protocol doc. >>> >>> >>I think that the best way to handle this would be to put a statement >>in the base NETCONF protocol document with a normative reference to >>the NETCONF over SSH document, but I'm open to other choices. >>Thoughts? >> >>Bert, I'll be submitting a new version later this week that should >>have the new boilerplate. I'll also address your other comments, and >>the comments that others have made about the need for IANA to >>register the "netconf" SSH subsystem name. >> >>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: > > > > -- 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 Aug 30 18:51:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEx0-0000cG-Tf for netconf-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:51:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15074 for ; Tue, 30 Aug 2005 18:51:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAErH-000LKn-Fc for netconf-data@psg.com; Tue, 30 Aug 2005 22:45:35 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EAErG-000LKO-Q9 for netconf@ops.ietf.org; Tue, 30 Aug 2005 22:45:34 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)) for netconf@ops.ietf.org; Tue, 30 Aug 2005 15:45:54 -0700 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <6A3CAC2F-04B3-4069-8359-464152E21294@icesoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: netconf From: Ted Goddard Subject: proposed changes for draft-ietf-netconf-soap-06 Date: Tue, 30 Aug 2005 16:45:30 -0600 X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I would like to propose the following changes for the NETCONF SOAP draft in the indicated sections: Section 0 RFC 3978 boilerplate Section 2.4 BCP56: On the Use of HTTP as a Substrate It is also possible to respond to the concern on the re-use of port 80. A NETCONF SOAP service SHOULD be offered over a new standard port for NETCONF over SOAP (over HTTP) to be defined as requested in the IANA considerations of this document. Section 4 Security Considerations The IANA requested port SHOULD be used, as this provides a means for efficient firewall filtering during possible denial-of-service attacks. Section 5 IANA Considerations The IANA is requested to assign TCP ports for NETCONF for SOAP over HTTP and SOAP over BEEP. The IANA is requested to place netconf-soap_1.0.wsdl in the IANA XML registry. The following indicated ID-nits appear to be in error (xml2rfc output checked with "od -c"): tmp/draft-ietf-netconf-soap-05.txt(452): Line is too long: the offending characters are 'elope"' tmp/draft-ietf-netconf-soap-05.txt(464): Line is too long: the offending characters are 's:netconf:base:1.0">' Thanks, Ted. -- 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 Aug 31 12:57:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAVu5-0006UZ-1b for netconf-archive@megatron.ietf.org; Wed, 31 Aug 2005 12:57:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00445 for ; Wed, 31 Aug 2005 12:57:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAVj7-000II5-3d for netconf-data@psg.com; Wed, 31 Aug 2005 16:46:17 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAVj4-000IHp-ES for netconf@ops.ietf.org; Wed, 31 Aug 2005 16:46:14 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 31 Aug 2005 09:46:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,158,1122879600"; d="scan'208"; a="498241301:sNHT23199756" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 09:46:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: AD review for: draft-ietf-netconf-prot-07.txt Date: Wed, 31 Aug 2005 09:46:09 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440BC4B38C@photon.jnpr.net> Thread-Topic: AD review for: draft-ietf-netconf-prot-07.txt Thread-Index: AcWUcn1qRW3GHqJiRPiql53yZByFTQZKu8Lw From: "Rob Enns" To: "Wijnen, Bert \(Bert\)" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 31 Aug 2005 16:46:13.0770 (UTC) FILETIME=[7FAC36A0:01C5AE4B] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thank you for the thorough review, Bert. Unless otherwise noted, all edits and clarifications you raise have been made to the protocol draft. > - what is the real difference between the examples > in sections 6.2.3 and 6.2.4? > I think I understand the differences between containment > and seclection nodes, but the examples confuse me instead > of helping me, because they are exactly the same and > even the descritive text directly following each example > is exactly the same. I agree, it doesn't help much as currently written. Given that=20 the filtering rules and role of the containment, selection, and=20 content match nodes are laid out in detail in section 6.2.5, and=20 6.3, I think we can clean this up a little by trimming section=20 6.2.3 down and limiting it to defining what a containment=20 node is. The descriptive text for the example in 6.2.3 is a=20 bit misleading, because the selection node also controls what=20 is included in the output, and that's not discussed until 6.2.4=20 and 6.2.5. I will clean this up.=20 > - not sure I understand (1st para sect 8) what "must be able to=20 > process and ignore..." means. Maybe you can explain to me, maybe > it needs clarfication? The peer should ignore capabilities it does not understand. I think it would be clearer to rewrite this as "... and MUST ignore any capability received from the other peer that it=20 does not require or does not understand." =20 > - sect 8.9.5.1 example > Am I missing something? I do not understand "top" in that > example. Could be me. In the fictional data model used in the draft, "top" is the uppermost (or outermost) element. > - sect 10. IANA Considerations. > I see just: TBD > Well I think there are IANA considerations. > Like a description of the registries (namespaces) to > be created and to be maintained by IANA. Also rules about how > new entries/assignments can be made (see RFC2434). > Further I think that this document makes a set of registartions > and so they should be listed here for IANA as the initial set > of registrations to be administered/recorded. I will post proposed text for the IANA Considerations section to the WG list. > - I think I would change "Author's Address" into "Editor's Address" > on page 68. Specifically cause I get the impression that=20 > Rob is editor > and that there are quite a set of contributing authors, which you=20 > have listed separately (good). Agreed, although I haven't yet figured out how to make xml2rfc do this. > - Has the XML Schema been validated for correct SYNTAX? > Can you tell me which tool you used to do so? XMLSpy (http://www.altova.com) was used to validate the schema and all examples against the schema. thanks, Rob -- 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: