From mailman-admin@ietf.org Sat Feb 1 12:02:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10983 for ; Sat, 1 Feb 2003 12:02:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11H6PJ00653 for ; Sat, 1 Feb 2003 12:06:25 -0500 Date: Sat, 01 Feb 2003 12:06:25 -0500 Message-ID: <20030201170625.8821.43674.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rserpool-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rserpool-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rserpool-archive@lists.ietf.org: List Password // URL ---- -------- rserpool@ietf.org RVOD https://www1.ietf.org/mailman/options/rserpool/rserpool-archive%40lists.ietf.org From rserpool-admin@ietf.org Thu Feb 6 10:41:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22776 for ; Thu, 6 Feb 2003 10:41:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Fm9p09256; Thu, 6 Feb 2003 10:48:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FlMp09176 for ; Thu, 6 Feb 2003 10:47:22 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22691 for ; Thu, 6 Feb 2003 10:40:20 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16Fhxq17421 for ; Thu, 6 Feb 2003 09:43:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 09:43:57 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:43:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Feb 2003 09:43:00 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E68058@daebe007.americas.nokia.com> Thread-Topic: Security Design Team for Rserpool Thread-Index: AcLN9m10NFQjNFonSwakSR0FZomioA== To: X-OriginalArrivalTime: 06 Feb 2003 15:43:00.0957 (UTC) FILETIME=[6DEB20D0:01C2CDF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16FlMp09177 Subject: [Rserpool] Security Design Team for Rserpool Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We invite anyone who is interested to join the security design team for Rserpool. The team will have a conference call to get organized. Please send me an e-mail if you are interested in joining this group. Based on a number of changes over the last year to Reliable Server Pooling the design team needs to: 1) update the internet draft threat document Title: Threats Introduced by Rserpool and Requirements for Security in response to Threats: draft-ietf-rserpool-threats-00.txt 2) review the Rserpool security sections with updates in mind and make appropriate changes 3) respond to AD input on security -- that is add a mechanism to authenticate the ENRP server to the client during a client -- ENRP server exchange 4) any other topics? I propose to have a conference call the week of February 17 to kick off this effort. If you have any preferences for a day or time that week, or when you can't be available, please let me know. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Feb 6 10:42:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22815 for ; Thu, 6 Feb 2003 10:42:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Fmm809314 for rserpool-archive@odin.ietf.org; Thu, 6 Feb 2003 10:48:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Fm9p09256; Thu, 6 Feb 2003 10:48:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FlMp09176 for ; Thu, 6 Feb 2003 10:47:22 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22691 for ; Thu, 6 Feb 2003 10:40:20 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16Fhxq17421 for ; Thu, 6 Feb 2003 09:43:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 09:43:57 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:43:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Feb 2003 09:43:00 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E68058@daebe007.americas.nokia.com> Thread-Topic: Security Design Team for Rserpool Thread-Index: AcLN9m10NFQjNFonSwakSR0FZomioA== To: X-OriginalArrivalTime: 06 Feb 2003 15:43:00.0957 (UTC) FILETIME=[6DEB20D0:01C2CDF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16FlMp09177 Subject: [Rserpool] Security Design Team for Rserpool Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We invite anyone who is interested to join the security design team for Rserpool. The team will have a conference call to get organized. Please send me an e-mail if you are interested in joining this group. Based on a number of changes over the last year to Reliable Server Pooling the design team needs to: 1) update the internet draft threat document Title: Threats Introduced by Rserpool and Requirements for Security in response to Threats: draft-ietf-rserpool-threats-00.txt 2) review the Rserpool security sections with updates in mind and make appropriate changes 3) respond to AD input on security -- that is add a mechanism to authenticate the ENRP server to the client during a client -- ENRP server exchange 4) any other topics? I propose to have a conference call the week of February 17 to kick off this effort. If you have any preferences for a day or time that week, or when you can't be available, please let me know. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Feb 12 07:17:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00300 for ; Wed, 12 Feb 2003 07:17:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCR6p10083; Wed, 12 Feb 2003 07:27:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCQbp10058 for ; Wed, 12 Feb 2003 07:26:37 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00253 for ; Wed, 12 Feb 2003 07:16:43 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CCKIu6003561; Wed, 12 Feb 2003 06:20:19 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A3C02.4090207@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 06:20:18 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Tuexen Michael , "'Phillip Conrad'" , Rserpool list Subject: Re: [Rserpool] Clarification regarding RSerPool support for non-SCTP transports References: <3DE41088.C2769737@Motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, Finally, in a quest to catch up on email (and find what small simple thing I pledged to do in asap :->) I respond late... Comments below... Qiaobing Xie wrote: > Tuexen Michael wrote: > .... > >>>I would like to ask the working group for clarification of >>>some points regarding support for transports other than SCTP. >>> >>>As I understood it, a key motivator was to allow for the >>>possibility of PUs that supported TCP but not SCTP. The >>>example of such a requirement was some device for which an >>>SCTP implementation is not yet available; perhaps some >>>particular model of cell phone, PDA, or whatnot. >> >>To be more precise: >>- Support of PUs not running TCP. This means that we need >> to provide a method for PU <-> NS communication based on >> TCP. The data channel between PU <-> PE can be everything. >> The control channel between PU <-> PE can be TCP. > > > You must mean "PUs not running SCTP" :-) > > >>>As a result, I think we reached something like "rough >>>consensus" on the following direction: >>> >>>* to provide a way to send ASAP messages >>> between a PU and a PE over either SCTP or TCP >> >>This means the control channel can be SCTP or TCP based. > > > yes > > >>>* to provide a way to send ASAP message between >>> an PU and a Name Server over either SCTP or TCP >> >>Correct. We do NOT need a mapping here, since all ASAP >>messages are TLV. > > > yes > > >>>* to require that ENRP messages among PEs must use SCTP only. >>> >> >>I think you mean ENRP messages between NSs. Then it is correct. > > > yes > > >>>Three questions: >>> >>>(1) Is that the correct sense of the working group? Is there >>>any significant dissent from that point of view? If so, >>>please say so. >>> >> >>I provided my view to the above questions. > > > The above was "decided" about a year ago and _I_ haven't heard any objection so far. > > >>>(2) There might be one additional goal: >>> >>>* to specify how RSerPool is used when the application >>>prefers to use RSerPool only for server selection (i.e. to >>>resolve a pool handle to a transport address) and to handle >>>the sending/receiving of data outside the RSerPool framework. >>> The application also has the responsibility to detect and >>>report server failures in this case. >>> >>>Is there working group consensus about this goal... yes or >>>no? If any doubts whether this should be a goal, please speak up. >> > > This goal is about using a subset of what available in RSERPOOL and thus is achievable by > default (i.e., the app can always choose only to use a subset of features built in ASAP). > Or, are you asking group consensus on prohibiting this particular way of using RSERPOOL? > > >>>I know there is still not full working group consensus that >>>the "mapping" approach taken in the current drafts is the >>>right way to go (in fact, I am aware of some particular >>>doubts). But before we debate the "how", I want to be sure >>>we at least have rough consensus on what the goal(s) is/are. >> > > Mapping is not our goal. Mapping is part of "how" :-) I think we have consensus to > support the PU <-> PE control messages already but we don't have consensus on whether > "mapping" is the best way to do it. > > >>I think we agree on the NS <-> NS communication (SCTP only), >>PU <-> NS communication (TCP or SCTP communication, no 'mapping'). >> >>The open point was the PE <-> PU communication. We have the notion >>of control and data channel. To be more precise type one and type two >>data channel. >> >>At Thursday evening (Peter, Qiaobing and myself having dinner) we started >>(again) the discussion how this will work. The results of the discussion are >>- UDP based data channels with a control channel should be supported. >>- The way of using the same transport connection for data and control channel >> is not sufficient because of the support of UDP. >>- Old applications running UDP and/or TCP should be supported without >> modifying their protocol. > > > Considering 3GPP, if they are told that they have to change their GTP in order to use > RSERPOOL among their nodes, the whole industry will by-pass RSERPOOL in a heartbeat. > > >>So we came up with the following suggestion: >>- If SCTP is used mulitplex the data and control channel based on the PPID. >>- If TCP is used and ASAP send calls you can use the mapping document to >> multiplex the data and control channel on one TCP connection. >>- If TCP, UDP (or DCP) is used for the data channel used a seperate >> SCTP or TCP based control channel to a port at the PE. This port number >> could be a well known ASAP port or be part of the name resolution message. >> This solution works for that type of channel were the send call is not >> a ASAP send-call. You can call that support of 'old' applications. > All of the above looks good with one exception... Using a well-known ASAP port will not work for you.. well it will work with the first PE but what if I want to run 6 PE's on a box.. maybe of different appliation servers... how can all 6 (potentially different applications) grap the same port (Yes I know about REUSE-ADDRESS... but this does not work with different apps).. I am thinking it would be better to have two ports in the registration [control]:[proto-type] [data]:[proto-type]. And optionally [data] can be set to 0 indicating the control and the data go on the same port/protocol. This would: a) eliminate sending addresses etc in the control stream (good for the ugly devices in the network). b) Provide a simple way to find out if the PE I am going to talk to has a seperate control and data channel. c) One would also know very easily that I need a SCTP type socket as well as a UDP type socket (for example) to talk to this app. My 2 cents... Now if I could only find some clue as to what simple change to asap I need to make.. Oh, by the way Phil.. I liked your text for asap on "best effort" resending.. and I put it in... for the most part un changed... so at least that will go in the update :> R > > Yes. This is the basic idea. But we probably should not distinguish mapping from > non-mapping based on whether the app uses an ASAP send-call or not because that is not > fundamental. For example, an implementation may build a convenient ASAP "socket" that > manages two TCP sockets underneath - one for un-alternated/un-mapped use data transmission > and the other for sending control messages. This way, the ASAP can perform failover etc. > by moving the data transmission from one TCP socket to another, while the app gets the > convenience of only needing to deal with a single ASAP "socket" to send data. And there is > no mapping on the data channel. For one, I most likely will build my implementation this > way. So if you think I shouldn't do that, please tell me why now :-) > > >>How is the information provided which control channel belongs to which >>data channel: The first message on the control channel is send by the PU >>and contains the information about protocol, local IP address, remote IP address, >>local port number, remote port number. >> >>This would be an easy solution, but we transport IP addresses in the payload >>making the RSerPool deployment hard in networks with NATs. > > > Yes, this is a potential issue. > > >>I hope that Qiaobing and Peter share this view on the result of the dinner. >>Any comments from them or others? > > > Yes. We need to write it down in detail. > > regards, > -Qiaobing > > >>>Thanks, >>>Phill Conrad >>> >>>_______________________________________________ >>>rserpool mailing list >>>rserpool@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rserpool >>> >> >>_______________________________________________ >>rserpool mailing list >>rserpool@ietf.org >>https://www1.ietf.org/mailman/listinfo/rserpool > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Feb 12 07:18:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00314 for ; Wed, 12 Feb 2003 07:18:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCRpM10126 for rserpool-archive@odin.ietf.org; Wed, 12 Feb 2003 07:27:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCR6p10083; Wed, 12 Feb 2003 07:27:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCQbp10058 for ; Wed, 12 Feb 2003 07:26:37 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00253 for ; Wed, 12 Feb 2003 07:16:43 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CCKIu6003561; Wed, 12 Feb 2003 06:20:19 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A3C02.4090207@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 06:20:18 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Tuexen Michael , "'Phillip Conrad'" , Rserpool list Subject: Re: [Rserpool] Clarification regarding RSerPool support for non-SCTP transports References: <3DE41088.C2769737@Motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, Finally, in a quest to catch up on email (and find what small simple thing I pledged to do in asap :->) I respond late... Comments below... Qiaobing Xie wrote: > Tuexen Michael wrote: > .... > >>>I would like to ask the working group for clarification of >>>some points regarding support for transports other than SCTP. >>> >>>As I understood it, a key motivator was to allow for the >>>possibility of PUs that supported TCP but not SCTP. The >>>example of such a requirement was some device for which an >>>SCTP implementation is not yet available; perhaps some >>>particular model of cell phone, PDA, or whatnot. >> >>To be more precise: >>- Support of PUs not running TCP. This means that we need >> to provide a method for PU <-> NS communication based on >> TCP. The data channel between PU <-> PE can be everything. >> The control channel between PU <-> PE can be TCP. > > > You must mean "PUs not running SCTP" :-) > > >>>As a result, I think we reached something like "rough >>>consensus" on the following direction: >>> >>>* to provide a way to send ASAP messages >>> between a PU and a PE over either SCTP or TCP >> >>This means the control channel can be SCTP or TCP based. > > > yes > > >>>* to provide a way to send ASAP message between >>> an PU and a Name Server over either SCTP or TCP >> >>Correct. We do NOT need a mapping here, since all ASAP >>messages are TLV. > > > yes > > >>>* to require that ENRP messages among PEs must use SCTP only. >>> >> >>I think you mean ENRP messages between NSs. Then it is correct. > > > yes > > >>>Three questions: >>> >>>(1) Is that the correct sense of the working group? Is there >>>any significant dissent from that point of view? If so, >>>please say so. >>> >> >>I provided my view to the above questions. > > > The above was "decided" about a year ago and _I_ haven't heard any objection so far. > > >>>(2) There might be one additional goal: >>> >>>* to specify how RSerPool is used when the application >>>prefers to use RSerPool only for server selection (i.e. to >>>resolve a pool handle to a transport address) and to handle >>>the sending/receiving of data outside the RSerPool framework. >>> The application also has the responsibility to detect and >>>report server failures in this case. >>> >>>Is there working group consensus about this goal... yes or >>>no? If any doubts whether this should be a goal, please speak up. >> > > This goal is about using a subset of what available in RSERPOOL and thus is achievable by > default (i.e., the app can always choose only to use a subset of features built in ASAP). > Or, are you asking group consensus on prohibiting this particular way of using RSERPOOL? > > >>>I know there is still not full working group consensus that >>>the "mapping" approach taken in the current drafts is the >>>right way to go (in fact, I am aware of some particular >>>doubts). But before we debate the "how", I want to be sure >>>we at least have rough consensus on what the goal(s) is/are. >> > > Mapping is not our goal. Mapping is part of "how" :-) I think we have consensus to > support the PU <-> PE control messages already but we don't have consensus on whether > "mapping" is the best way to do it. > > >>I think we agree on the NS <-> NS communication (SCTP only), >>PU <-> NS communication (TCP or SCTP communication, no 'mapping'). >> >>The open point was the PE <-> PU communication. We have the notion >>of control and data channel. To be more precise type one and type two >>data channel. >> >>At Thursday evening (Peter, Qiaobing and myself having dinner) we started >>(again) the discussion how this will work. The results of the discussion are >>- UDP based data channels with a control channel should be supported. >>- The way of using the same transport connection for data and control channel >> is not sufficient because of the support of UDP. >>- Old applications running UDP and/or TCP should be supported without >> modifying their protocol. > > > Considering 3GPP, if they are told that they have to change their GTP in order to use > RSERPOOL among their nodes, the whole industry will by-pass RSERPOOL in a heartbeat. > > >>So we came up with the following suggestion: >>- If SCTP is used mulitplex the data and control channel based on the PPID. >>- If TCP is used and ASAP send calls you can use the mapping document to >> multiplex the data and control channel on one TCP connection. >>- If TCP, UDP (or DCP) is used for the data channel used a seperate >> SCTP or TCP based control channel to a port at the PE. This port number >> could be a well known ASAP port or be part of the name resolution message. >> This solution works for that type of channel were the send call is not >> a ASAP send-call. You can call that support of 'old' applications. > All of the above looks good with one exception... Using a well-known ASAP port will not work for you.. well it will work with the first PE but what if I want to run 6 PE's on a box.. maybe of different appliation servers... how can all 6 (potentially different applications) grap the same port (Yes I know about REUSE-ADDRESS... but this does not work with different apps).. I am thinking it would be better to have two ports in the registration [control]:[proto-type] [data]:[proto-type]. And optionally [data] can be set to 0 indicating the control and the data go on the same port/protocol. This would: a) eliminate sending addresses etc in the control stream (good for the ugly devices in the network). b) Provide a simple way to find out if the PE I am going to talk to has a seperate control and data channel. c) One would also know very easily that I need a SCTP type socket as well as a UDP type socket (for example) to talk to this app. My 2 cents... Now if I could only find some clue as to what simple change to asap I need to make.. Oh, by the way Phil.. I liked your text for asap on "best effort" resending.. and I put it in... for the most part un changed... so at least that will go in the update :> R > > Yes. This is the basic idea. But we probably should not distinguish mapping from > non-mapping based on whether the app uses an ASAP send-call or not because that is not > fundamental. For example, an implementation may build a convenient ASAP "socket" that > manages two TCP sockets underneath - one for un-alternated/un-mapped use data transmission > and the other for sending control messages. This way, the ASAP can perform failover etc. > by moving the data transmission from one TCP socket to another, while the app gets the > convenience of only needing to deal with a single ASAP "socket" to send data. And there is > no mapping on the data channel. For one, I most likely will build my implementation this > way. So if you think I shouldn't do that, please tell me why now :-) > > >>How is the information provided which control channel belongs to which >>data channel: The first message on the control channel is send by the PU >>and contains the information about protocol, local IP address, remote IP address, >>local port number, remote port number. >> >>This would be an easy solution, but we transport IP addresses in the payload >>making the RSerPool deployment hard in networks with NATs. > > > Yes, this is a potential issue. > > >>I hope that Qiaobing and Peter share this view on the result of the dinner. >>Any comments from them or others? > > > Yes. We need to write it down in detail. > > regards, > -Qiaobing > > >>>Thanks, >>>Phill Conrad >>> >>>_______________________________________________ >>>rserpool mailing list >>>rserpool@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rserpool >>> >> >>_______________________________________________ >>rserpool mailing list >>rserpool@ietf.org >>https://www1.ietf.org/mailman/listinfo/rserpool > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Mon Feb 24 10:41:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17058 for ; Mon, 24 Feb 2003 10:41:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFnep01357; Mon, 24 Feb 2003 10:49:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFm4p01221 for ; Mon, 24 Feb 2003 10:48:04 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17010 for ; Mon, 24 Feb 2003 10:38:57 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1OFgrq08753 for ; Mon, 24 Feb 2003 09:42:53 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Feb 2003 09:42:51 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Feb 2003 07:42:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 24 Feb 2003 09:42:51 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F81101222B81@daebe007.americas.nokia.com> Thread-Topic: Security Design team conference call -- Tuesday, Feb. 25 at 10AM EST Thread-Index: AcLcG2M2Zf+1OiCDTr2EK/8SIoij5Q== To: X-OriginalArrivalTime: 24 Feb 2003 15:42:51.0220 (UTC) FILETIME=[638CE140:01C2DC1B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1OFm4p01222 Subject: [Rserpool] Security Design team conference call -- Tuesday, Feb. 25 at 10AM EST Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We will have a conference call for the Rserpool security design team at 10AM tomorrow, Tues. Feb. 25 at 10AM EST USA. 10:00 AM EST-for 1 hour and a 1/2. Domestic 888-658-3075-Passcode 19235 International 484-630-0183 Passcode 19235 We will discuss the following: 1) update the internet draft threat document Title: Threats Introduced by Rserpool and Requirements for Security in response to Threats: draft-ietf-rserpool-threats-00.txt 2) review the Rserpool security sections with updates in mind and make appropriate changes 3) respond to AD input on security -- that is add a mechanism to authenticate the ENRP server to the client during a client -- ENRP server exchange If you want to join, it is not too late to drop me an e-mail. Participation is open to all. Please join us. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Mon Feb 24 10:41:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17081 for ; Mon, 24 Feb 2003 10:41:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OFoJx01426 for rserpool-archive@odin.ietf.org; Mon, 24 Feb 2003 10:50:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFnep01357; Mon, 24 Feb 2003 10:49:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFm4p01221 for ; Mon, 24 Feb 2003 10:48:04 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17010 for ; Mon, 24 Feb 2003 10:38:57 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1OFgrq08753 for ; Mon, 24 Feb 2003 09:42:53 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Feb 2003 09:42:51 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Feb 2003 07:42:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 24 Feb 2003 09:42:51 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F81101222B81@daebe007.americas.nokia.com> Thread-Topic: Security Design team conference call -- Tuesday, Feb. 25 at 10AM EST Thread-Index: AcLcG2M2Zf+1OiCDTr2EK/8SIoij5Q== To: X-OriginalArrivalTime: 24 Feb 2003 15:42:51.0220 (UTC) FILETIME=[638CE140:01C2DC1B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1OFm4p01222 Subject: [Rserpool] Security Design team conference call -- Tuesday, Feb. 25 at 10AM EST Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We will have a conference call for the Rserpool security design team at 10AM tomorrow, Tues. Feb. 25 at 10AM EST USA. 10:00 AM EST-for 1 hour and a 1/2. Domestic 888-658-3075-Passcode 19235 International 484-630-0183 Passcode 19235 We will discuss the following: 1) update the internet draft threat document Title: Threats Introduced by Rserpool and Requirements for Security in response to Threats: draft-ietf-rserpool-threats-00.txt 2) review the Rserpool security sections with updates in mind and make appropriate changes 3) respond to AD input on security -- that is add a mechanism to authenticate the ENRP server to the client during a client -- ENRP server exchange If you want to join, it is not too late to drop me an e-mail. Participation is open to all. Please join us. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Feb 27 15:20:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20326 for ; Thu, 27 Feb 2003 15:20:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKUTp18593; Thu, 27 Feb 2003 15:30:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKTBp18498 for ; Thu, 27 Feb 2003 15:29:11 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20287 for ; Thu, 27 Feb 2003 15:18:33 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RKMdO11745 for ; Thu, 27 Feb 2003 14:22:39 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Feb 2003 14:22:26 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 14:21:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 27 Feb 2003 14:21:34 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E6808A@daebe007.americas.nokia.com> Thread-Topic: Summary of security design team and next conference call - Tuesday, March 4 Thread-Index: AcLendJ+gyH7OY+QRxWiJyE3vohuxg== To: X-OriginalArrivalTime: 27 Feb 2003 20:21:34.0866 (UTC) FILETIME=[D2DBFF20:01C2DE9D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RKTBp18499 Subject: [Rserpool] Summary of security design team and next conference call - Tuesday, March 4 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, The security design team had a conference call on Tues. Feb. 25. at 10AM EST USA. Our next call will be Tues. March 4 at 10AM EST USA Call in details will follow shortly. Attending on 2/25 were: Aron Silverton Maureen Stillman Michael Tuexen Qioabing Xie 1) On the subject of the PU (client) authenticating the ENRP server we reached consensus that TLS would be a good mechanism. We suggest that it be mandatory to implement. Other authentication mechanisms could be used as well, but they would be optional. The reason to choose one (namely TLS) for mandatory to implement would be for reasons of interoperability. Recall that the ADs requested that we add this authentication to prevent a rogue ENRP server from responding to the client. 2) We discussed the Rserpool data and control channels. Control channel is ASAP messages between the PU and PE and data channel is everything else. It was generally agreed that the control channel would (optionally) need to be secured. However, the configuration of the data and control channel is still under discussion. For example, are the data and control channels required to use the same SCTP association or can they be different. What happens when you use TCP? After we sort this out, then we can decide on the security. Those at the teleconference, please comment on my summary and correct any errors. Please comment on #1 and #2. We will discuss this further on our next telecon and at IETF #56. Please send me e-mail if you wish to participate next Tuesday. All are welcome. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Feb 27 15:21:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20359 for ; Thu, 27 Feb 2003 15:21:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RKVAG18622 for rserpool-archive@odin.ietf.org; Thu, 27 Feb 2003 15:31:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKUTp18593; Thu, 27 Feb 2003 15:30:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKTBp18498 for ; Thu, 27 Feb 2003 15:29:11 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20287 for ; Thu, 27 Feb 2003 15:18:33 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RKMdO11745 for ; Thu, 27 Feb 2003 14:22:39 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Feb 2003 14:22:26 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 14:21:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 27 Feb 2003 14:21:34 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E6808A@daebe007.americas.nokia.com> Thread-Topic: Summary of security design team and next conference call - Tuesday, March 4 Thread-Index: AcLendJ+gyH7OY+QRxWiJyE3vohuxg== To: X-OriginalArrivalTime: 27 Feb 2003 20:21:34.0866 (UTC) FILETIME=[D2DBFF20:01C2DE9D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RKTBp18499 Subject: [Rserpool] Summary of security design team and next conference call - Tuesday, March 4 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, The security design team had a conference call on Tues. Feb. 25. at 10AM EST USA. Our next call will be Tues. March 4 at 10AM EST USA Call in details will follow shortly. Attending on 2/25 were: Aron Silverton Maureen Stillman Michael Tuexen Qioabing Xie 1) On the subject of the PU (client) authenticating the ENRP server we reached consensus that TLS would be a good mechanism. We suggest that it be mandatory to implement. Other authentication mechanisms could be used as well, but they would be optional. The reason to choose one (namely TLS) for mandatory to implement would be for reasons of interoperability. Recall that the ADs requested that we add this authentication to prevent a rogue ENRP server from responding to the client. 2) We discussed the Rserpool data and control channels. Control channel is ASAP messages between the PU and PE and data channel is everything else. It was generally agreed that the control channel would (optionally) need to be secured. However, the configuration of the data and control channel is still under discussion. For example, are the data and control channels required to use the same SCTP association or can they be different. What happens when you use TCP? After we sort this out, then we can decide on the security. Those at the teleconference, please comment on my summary and correct any errors. Please comment on #1 and #2. We will discuss this further on our next telecon and at IETF #56. Please send me e-mail if you wish to participate next Tuesday. All are welcome. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Feb 27 15:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20502 for ; Thu, 27 Feb 2003 15:24:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKY2p18769; Thu, 27 Feb 2003 15:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKXbp18735 for ; Thu, 27 Feb 2003 15:33:37 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20440 for ; Thu, 27 Feb 2003 15:22:59 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RKQuq21596 for ; Thu, 27 Feb 2003 14:26:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Feb 2003 14:26:53 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 12:26:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 27 Feb 2003 14:26:29 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E6808C@daebe007.americas.nokia.com> Thread-Topic: Please send agenda items for IETF #56 Thread-Index: AcLenoKmjcGxczhQT8aVg7ldMUpYWQ== To: X-OriginalArrivalTime: 27 Feb 2003 20:26:30.0600 (UTC) FILETIME=[83216C80:01C2DE9E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RKXcp18736 Subject: [Rserpool] Please send agenda items for IETF #56 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Lyndon and I will be working on an agenda. Please send any items to me. Our tentative time slot is Monday, March 17 15:30 to 17:30. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Feb 27 15:24:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20525 for ; Thu, 27 Feb 2003 15:24:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RKYgM18803 for rserpool-archive@odin.ietf.org; Thu, 27 Feb 2003 15:34:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKY2p18769; Thu, 27 Feb 2003 15:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKXbp18735 for ; Thu, 27 Feb 2003 15:33:37 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20440 for ; Thu, 27 Feb 2003 15:22:59 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RKQuq21596 for ; Thu, 27 Feb 2003 14:26:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Feb 2003 14:26:53 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 12:26:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 27 Feb 2003 14:26:29 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E6808C@daebe007.americas.nokia.com> Thread-Topic: Please send agenda items for IETF #56 Thread-Index: AcLenoKmjcGxczhQT8aVg7ldMUpYWQ== To: X-OriginalArrivalTime: 27 Feb 2003 20:26:30.0600 (UTC) FILETIME=[83216C80:01C2DE9E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RKXcp18736 Subject: [Rserpool] Please send agenda items for IETF #56 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Lyndon and I will be working on an agenda. Please send any items to me. Our tentative time slot is Monday, March 17 15:30 to 17:30. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool