Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h1SIDhnG020084 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Feb 2003 19:13:44 +0100 Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1SIDaS33504; Fri, 28 Feb 2003 10:13:37 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id h1SIHoci003102; Fri, 28 Feb 2003 13:17:50 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200302281817.h1SIHoci003102@idle.juniper.net> To: Juergen Schoenwaelder cc: Network Management Research Group Subject: Re: [nmrg] 12th nmrg meeting details In-Reply-To: Your message of "Fri, 28 Feb 2003 16:04:30 +0100." <200302281504.h1SF4UDQ002937@hansa.ibr.cs.tu-bs.de> Date: Fri, 28 Feb 2003 13:17:50 -0500 From: Phil Shafer X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder writes: >Let me know what is missing or needs corrections. Looking forward to >see you folks in Colorado, I'm plannning on attended, but have one question. How late will the meeting run on the 23rd? I'm trying to figure out flights back home. Thanks, Phil Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h1SF4UnG022046 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 28 Feb 2003 16:04:30 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h1SF4UuO002940 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 28 Feb 2003 16:04:30 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h1SF4UDQ002937; Fri, 28 Feb 2003 16:04:30 +0100 Date: Fri, 28 Feb 2003 16:04:30 +0100 Message-Id: <200302281504.h1SF4UDQ002937@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] 12th nmrg meeting details Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: The 12th NMRG meeting in Colorado Springs will be hosted by Intelliden (many thanks to John Strassner for his help). We will meet on Saturday afternoon and on Sunday (whole day). There will also be a BOF at IM 2003 with the intention to communicate more with IM 2003 participants that might be interested or convinced to join the NMRG. ;-) I have created a web page for this meeting which as additional information such as the hotel information and an initial agenda. I have already booked a room in the Adam's Mark hotel where I will stay over the weekend before I move to the Broadmoor on Monday. https://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2003/colorado/ Let me know what is missing or needs corrections. Looking forward to see you folks in Colorado, /js -- Juergen Schoenwaelder Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h1RGSBnF004436; Thu, 27 Feb 2003 17:28:12 +0100 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1RGS0m23453; Thu, 27 Feb 2003 11:28:00 -0500 (EST) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FSL70WRL; Thu, 27 Feb 2003 11:28:00 -0500 Received: from americasm01.nt.com (DJSIDOR-3 [47.102.194.48]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3HK6CQ; Thu, 27 Feb 2003 11:28:01 -0500 Message-ID: <3E5E3CE0.DE47E7DD@americasm01.nt.com> Date: Thu, 27 Feb 2003 11:29:20 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Sidor" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: bwijnen@lucent.com, randy@psg.com, young-han.choe@itu.int, lraman@teraburst.com, dlmatthews@att.com, Network Management Research Group , "*List, Q 18/4" References: <3E59F00F.4441780D@americasm01.nt.com> <200302271243.h1RCho4p026260@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] Re: SG 4 re RFC 3430 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen, Thanks for your comments. In response I offer 2 points: - First a minor point: I have removed 2 addresses from my email (Mrs. Mc Grath and the IETF liaison address) and added the address of the mailing list of Q 18/4, the group responsible for this liaison and also Q.811/Q.812. - Second, I wish to reiterate that Lakshmi Raman, identified as SG 4 contact in the liaison, supported by Dave Matthews, the Q 18/4 rapporteur, is the SG 4 technical lead in responding to your points, issues, and questions. Dave Juergen Schoenwaelder wrote: > > >>>>> Dave Sidor writes: > > Dave> Below and attached as a Word file is a SG 4 liaison regarding > Dave> RFC 3430. Please forward it to the appropriate IETF persons and > Dave> WGs. As you suggested, I have also copied Juergen as the author > Dave> of that RFC. > > Thanks for sharing the information. I will respond to the comments > below inline (and keep the rest of the text so that others can follow > what is going on). Note that I have added the NMRG to the CC: list. > > Dave> Based on email discussions with the Operations and Management > Dave> Area Directors, we are incorporating a reference to RFC 3430 in > Dave> the revision of Q.812 in progress. > > Dave> In addition, at the ITU-T Study Group 4 meeting in February > Dave> 2003, we received a contribution on the implementation > Dave> experience of running SNMP over TCP and SNMP over UDP. This > Dave> experience may prove useful to the IETF in its evaluation of > Dave> RFC3430 and its potential evolution. We would appreciate if the > Dave> IETF make a similar call for implementation report of RFC 3430 > Dave> and share the results with us. > > Dave> In response to the email suggestion from one of the Area > Dave> Directors, we offer the following summary of one implementation > Dave> experience. In the event the IETF does offer an official call at > Dave> a later date, we would be pleased to provide any additional > Dave> information required. > > Dave> In general, we would be grateful if you would keep us informed > Dave> of your progress on this topic. > > Dave> Implementation Experience -------------------------- > > Dave> MII/BUPT TMN R&D Center (Beijing, China) has developed an SNMP > Dave> (v2) over TCP implementation. The combined SNMP over TCP/UDP > Dave> approach provided in this work is still under development. > > Dave> Workstations: one SNMP manager runs on a Sun Sparc Ultra2 WS, > Dave> one SNMP agent runs on a Sun Sparc Ultra1 WS. Operation System: > Dave> Sun Solaris 2.6 (Unix) Software platforms: some parts of > Dave> SNMP(v2) PDU APIs are based on SNMP++, while the transport > Dave> protocol control module, and the SNMP agent and manager toolkit > Dave> are developed by MII/BUPT. The max SNMP message over UDP is > Dave> allowed: 4096 Bytes The max SNMP message over TCP that is sent > Dave> during test: 64K Bytes > > Dave> Network environment: The SNMP manager and the SNMP agent are > Dave> located in separate workstations in different Ethernet LANs, > Dave> which are connected via a radio network bridge. Both the manager > Dave> and the agent are simulators, and no real network devices are > Dave> actually managed by the manager or the agent during the > Dave> experiments. > > Dave> MII/BUPT have compared the transfer efficiency for SNMP over TCP > Dave> and SNMP over UDP. MII/BUPT captured all the packets between > Dave> these two SNMP entities, and calculated the transfer efficiency > Dave> for different sizes of SNMP messages to be transferred over the > Dave> two different transport protocols. When no packet is lost, and > Dave> the amount of data to be transferred is less than 64K, the SNMP > Dave> over UDP is more efficient. Otherwise TCP is more > Dave> efficient. Details can be provided if desired. > > It looks like they measured efficiency of individual messages, which > is to some extend missing the point. SNMP over TCP allows to > > (a) stream flows of SNMP messages while taking advantage of TCP's flow > control and congestion avoidance mechanisms > > (b) significantly reduce the number of request/response interactions > due to larger message sizes without causing fragmentation > (assuming TCP does proper MTU path discovery, which most > implementations do these days) > > So in order to measure the benefits, it is crucial to look at larger > transactions such as the complete retrieval of a potentially large > table. Note that there was a paper at a previous IM or NOMS which > showed some measured numbers (although the intention of the paper was > to look at SNMP over TLS over TCP efficiency compared to other > security approaches. > > Dave> Deltas from RFC3430 ------------------- > > Dave> The main part of the research is similar to what has been > Dave> described in RFC 3430. But there are still some differences that > Dave> may need consideration. > > Dave> 1) It was noticed that RFC 3430 does not provide a default > Dave> policy for closing a TCP connection. One proposal for the > Dave> default behaviour is that: > > Dave> The SNMP engine maintains a predefined number of TCP connections > Dave> even if some of the connections have not been used for a period > Dave> of time. The normal trigger point to close a connection is when > Dave> a new connection establishment is requested, but no free > Dave> resource is available for this connection. LRU(Least Recent > Dave> Usage) is considered as the rule for closing inactive TCP > Dave> connections. This proposal is also to avoid the extra costs for > Dave> connection establishment. > > While the described strategy makes sense in some environments, I do > not think it is wise to require such an implementation strategy. I can > very well consider situations where other factors might be strong > reasons to close TCP connections at other points in time. > > Dave> 2) A combined SNMP over TCP/UDP schema is proposed in the > Dave> research. This requires that SNMP engine provides both SNMP over > Dave> TCP and UDP implementations at the same time, and RFC 3430 also > Dave> indicates this. The default policy used is for the originator to > Dave> choose transport according to the size of the SNMP message. For > Dave> both efficiency and convenience considerations, when an SNMP > Dave> message is larger than a predefined size, then the SNMP engine > Dave> chooses TCP as the transport protocol, otherwise it chooses > Dave> UDP. (The predefined size is 4096 in the experiment, which is > Dave> the max size allowed over UDP in the experiment, but this value > Dave> may be adjusted.) This proposal tries to make use of the > Dave> benefits of TCP and UDP in different situations. > > If you look at getbulk, then the manager often does not know what the > size of the response will be. Again, I believe that the transport > selection must be controlled by the application since only the > application understands the trade-offs. I personally would not > implement an automatic transport selection scheme. > > Dave> 3) The minimum for the size of an SNMP message over TCP defined > Dave> in RFC 3430 seems relatively small. It is suggested that the > Dave> SNMP over TCP engine should support the size of at least 64K or > Dave> 32K bytes. The larger the size of an SNMP message is, the more > Dave> benefit SNMP over TCP may provide. > > RFC 3430 requires that every engine supports 8K and encourages engines > to support bigger message sizes. I believe this basically OK and with > SNMPv3, you have the fields in the messages to communicate the size > limitations to peers. The trade-off is that you need to have a buffer > for each TCP endpoint supported by an engine. Increasing the minimum > required size to say 64K implies that you need to have 640K buffer > space to support TCP concurrent connections, which might be hard in > some environments. I guess that in memory constraint environments, > implementations might actually adjust buffer sizes based on the number > of open connections (and this might lead to reasons to close idle > connections, which brings us nicely back to the comments above). > > /js > > -- > Juergen Schoenwaelder Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h1RChqnG030038 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 27 Feb 2003 13:43:52 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h1RChquO026263 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 27 Feb 2003 13:43:52 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h1RCho4p026260; Thu, 27 Feb 2003 13:43:50 +0100 Date: Thu, 27 Feb 2003 13:43:50 +0100 Message-Id: <200302271243.h1RCho4p026260@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: djsidor@nortelnetworks.com CC: bwijnen@lucent.com, randy@psg.com, statements@ietf.org, young-han.choe@itu.int, margaret.mcgrath@itu.int, lraman@teraburst.com, dlmatthews@att.com, Network Management Research Group In-reply-to: <3E59F00F.4441780D@americasm01.nt.com> (djsidor@nortelnetworks.com) References: <3E59F00F.4441780D@americasm01.nt.com> X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Subject: [nmrg] Re: SG 4 re RFC 3430 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Dave Sidor writes: Dave> Below and attached as a Word file is a SG 4 liaison regarding Dave> RFC 3430. Please forward it to the appropriate IETF persons and Dave> WGs. As you suggested, I have also copied Juergen as the author Dave> of that RFC. Thanks for sharing the information. I will respond to the comments below inline (and keep the rest of the text so that others can follow what is going on). Note that I have added the NMRG to the CC: list. Dave> Based on email discussions with the Operations and Management Dave> Area Directors, we are incorporating a reference to RFC 3430 in Dave> the revision of Q.812 in progress. Dave> In addition, at the ITU-T Study Group 4 meeting in February Dave> 2003, we received a contribution on the implementation Dave> experience of running SNMP over TCP and SNMP over UDP. This Dave> experience may prove useful to the IETF in its evaluation of Dave> RFC3430 and its potential evolution. We would appreciate if the Dave> IETF make a similar call for implementation report of RFC 3430 Dave> and share the results with us. Dave> In response to the email suggestion from one of the Area Dave> Directors, we offer the following summary of one implementation Dave> experience. In the event the IETF does offer an official call at Dave> a later date, we would be pleased to provide any additional Dave> information required. Dave> In general, we would be grateful if you would keep us informed Dave> of your progress on this topic. Dave> Implementation Experience -------------------------- Dave> MII/BUPT TMN R&D Center (Beijing, China) has developed an SNMP Dave> (v2) over TCP implementation. The combined SNMP over TCP/UDP Dave> approach provided in this work is still under development. Dave> Workstations: one SNMP manager runs on a Sun Sparc Ultra2 WS, Dave> one SNMP agent runs on a Sun Sparc Ultra1 WS. Operation System: Dave> Sun Solaris 2.6 (Unix) Software platforms: some parts of Dave> SNMP(v2) PDU APIs are based on SNMP++, while the transport Dave> protocol control module, and the SNMP agent and manager toolkit Dave> are developed by MII/BUPT. The max SNMP message over UDP is Dave> allowed: 4096 Bytes The max SNMP message over TCP that is sent Dave> during test: 64K Bytes Dave> Network environment: The SNMP manager and the SNMP agent are Dave> located in separate workstations in different Ethernet LANs, Dave> which are connected via a radio network bridge. Both the manager Dave> and the agent are simulators, and no real network devices are Dave> actually managed by the manager or the agent during the Dave> experiments. Dave> MII/BUPT have compared the transfer efficiency for SNMP over TCP Dave> and SNMP over UDP. MII/BUPT captured all the packets between Dave> these two SNMP entities, and calculated the transfer efficiency Dave> for different sizes of SNMP messages to be transferred over the Dave> two different transport protocols. When no packet is lost, and Dave> the amount of data to be transferred is less than 64K, the SNMP Dave> over UDP is more efficient. Otherwise TCP is more Dave> efficient. Details can be provided if desired. It looks like they measured efficiency of individual messages, which is to some extend missing the point. SNMP over TCP allows to (a) stream flows of SNMP messages while taking advantage of TCP's flow control and congestion avoidance mechanisms (b) significantly reduce the number of request/response interactions due to larger message sizes without causing fragmentation (assuming TCP does proper MTU path discovery, which most implementations do these days) So in order to measure the benefits, it is crucial to look at larger transactions such as the complete retrieval of a potentially large table. Note that there was a paper at a previous IM or NOMS which showed some measured numbers (although the intention of the paper was to look at SNMP over TLS over TCP efficiency compared to other security approaches. Dave> Deltas from RFC3430 ------------------- Dave> The main part of the research is similar to what has been Dave> described in RFC 3430. But there are still some differences that Dave> may need consideration. Dave> 1) It was noticed that RFC 3430 does not provide a default Dave> policy for closing a TCP connection. One proposal for the Dave> default behaviour is that: Dave> The SNMP engine maintains a predefined number of TCP connections Dave> even if some of the connections have not been used for a period Dave> of time. The normal trigger point to close a connection is when Dave> a new connection establishment is requested, but no free Dave> resource is available for this connection. LRU(Least Recent Dave> Usage) is considered as the rule for closing inactive TCP Dave> connections. This proposal is also to avoid the extra costs for Dave> connection establishment. While the described strategy makes sense in some environments, I do not think it is wise to require such an implementation strategy. I can very well consider situations where other factors might be strong reasons to close TCP connections at other points in time. Dave> 2) A combined SNMP over TCP/UDP schema is proposed in the Dave> research. This requires that SNMP engine provides both SNMP over Dave> TCP and UDP implementations at the same time, and RFC 3430 also Dave> indicates this. The default policy used is for the originator to Dave> choose transport according to the size of the SNMP message. For Dave> both efficiency and convenience considerations, when an SNMP Dave> message is larger than a predefined size, then the SNMP engine Dave> chooses TCP as the transport protocol, otherwise it chooses Dave> UDP. (The predefined size is 4096 in the experiment, which is Dave> the max size allowed over UDP in the experiment, but this value Dave> may be adjusted.) This proposal tries to make use of the Dave> benefits of TCP and UDP in different situations. If you look at getbulk, then the manager often does not know what the size of the response will be. Again, I believe that the transport selection must be controlled by the application since only the application understands the trade-offs. I personally would not implement an automatic transport selection scheme. Dave> 3) The minimum for the size of an SNMP message over TCP defined Dave> in RFC 3430 seems relatively small. It is suggested that the Dave> SNMP over TCP engine should support the size of at least 64K or Dave> 32K bytes. The larger the size of an SNMP message is, the more Dave> benefit SNMP over TCP may provide. RFC 3430 requires that every engine supports 8K and encourages engines to support bigger message sizes. I believe this basically OK and with SNMPv3, you have the fields in the messages to communicate the size limitations to peers. The trade-off is that you need to have a buffer for each TCP endpoint supported by an engine. Increasing the minimum required size to say 64K implies that you need to have 640K buffer space to support TCP concurrent connections, which might be hard in some environments. I guess that in memory constraint environments, implementations might actually adjust buffer sizes based on the number of open connections (and this might lead to reasons to close idle connections, which brings us nicely back to the comments above). /js -- Juergen Schoenwaelder Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h1PIF8nG024725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 25 Feb 2003 19:15:08 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h1PIF7uO005869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 25 Feb 2003 19:15:07 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h1PIF7Sl005866; Tue, 25 Feb 2003 19:15:07 +0100 Date: Tue, 25 Feb 2003 19:15:07 +0100 Message-Id: <200302251815.h1PIF7Sl005866@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] please check out draft-iab-research-funding-00.txt Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: The IAB just posted a document which I think deserves some attention: : Title : IAB Concerns & Recommendations Regarding : Internet Research & Evolution : Author(s) : R. Atkinson, S. Floyd : Filename : draft-iab-research-funding-00.txt,.ps : Pages : 20 : Date : 2003-2-20 : : This document discusses IAB concerns that ongoing research is needed : to further the evolution of the Internet infrastructure, and that : consistent, sufficient non-commercial funding is needed to enable : : http://www.ietf.org/internet-drafts/draft-iab-research-funding-00.txt Please send comments either to this list or directly to the IAB. Perhaps we might also want to suggest specific changes/additions regarding the network management portions of the document. /js -- Juergen Schoenwaelder Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h1HFOd7Y009048 for ; Mon, 17 Feb 2003 16:24:40 +0100 Received: from IDLEWYLDE.windriver.com ([147.11.233.30]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA07984; Mon, 17 Feb 2003 07:23:17 -0800 (PST) Message-Id: <5.1.0.14.2.20030217100313.03682e70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Feb 2003 10:13:52 -0500 To: ops-area@ietf.org, ops-nm@ietf.org, ietf@ietf.org, nmrg@ibr.cs.tu-bs.de From: Margaret Wasserman Cc: xmlconf@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] XMLCONF Proposal Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi All, We have a proposal available for a new configuration protocol that may be of interest to folks on these lists. The proposal has been published an an I-D, and can be found at: http://www.ietf.org/internet-drafts/draft-enns-xmlconf-spec-00.txt We believe that this proposal addresses many of the operator and vendor requirements for a configuration protocol that have been gathered and analyzed over the past couple of years. We will be requesting a BOF to discuss this proposal in San Francisco, but before a BOF can be scheduled, we will need to demonstrate sufficient community interest in this proposal. So, if you believe that this proposal warrants further work within the IETF, please send your feedback ASAP to xmlconf@ops.ietf.org. Please DO NOT cross-post replies to all of the groups cc:ed on this message. Thanks, Margaret