From mailman-admin@ietf.org Fri Aug 1 09:32:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14185 for ; Fri, 1 Aug 2003 09:18:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZcy-0001oC-Ag for rserpool-archive@lists.ietf.org; Fri, 01 Aug 2003 09:07:24 -0400 Date: Fri, 01 Aug 2003 09:07:24 -0400 Message-ID: <20030801130724.29120.15108.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 exim@www1.ietf.org Tue Aug 5 14:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23115 for ; Tue, 5 Aug 2003 14:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6xf-0003Y8-Ka for rserpool-archive@odin.ietf.org; Tue, 05 Aug 2003 14:55:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75It7XV013640 for rserpool-archive@odin.ietf.org; Tue, 5 Aug 2003 14:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6xZ-0003Xk-Ek; Tue, 05 Aug 2003 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6xO-0003XS-2g for rserpool@optimus.ietf.org; Tue, 05 Aug 2003 14:54:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23092 for ; Tue, 5 Aug 2003 14:54:44 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6xL-0004sm-00 for rserpool@ietf.org; Tue, 05 Aug 2003 14:54:47 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19k6xK-0004si-00 for rserpool@ietf.org; Tue, 05 Aug 2003 14:54:46 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h75Isk123902 for ; Tue, 5 Aug 2003 13:54:46 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Aug 2003 13:54:46 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 13:54:22 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Aug 2003 13:54:20 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811021CFE7B@daebe007.americas.nokia.com> Thread-Topic: [Rserpool] Two security issues from IETF #57 Thread-Index: AcNRL+5QIGrMEPEjS1+/ZdaLH7XeQAKUqmTA To: , X-OriginalArrivalTime: 05 Aug 2003 18:54:22.0042 (UTC) FILETIME=[FB88ABA0:01C35B82] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Security design team conference call 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: quoted-printable The security design team will have a conference call to discuss this = issue and other security related issues. I'm suggesting either Aug. 14 = or Aug. 18 as possible dates at 10AM EST USA. Please send me e-mail if you wish to join us and indicate what date = would be good for you. Or you can suggest another time. -- maureen -----Original Message----- From: ext Silverton Aron-C1710C [mailto:Aron.J.Silverton@motorola.com] Sent: Wednesday, July 23, 2003 11:26 AM To: Stillman Maureen (NVO-NIC/Ithaca); 'rserpool@ietf.org' Subject: RE: [Rserpool] Two security issues from IETF #57 Hi Maureen, Comments inline. Maureen.Stillman@nokia.com wrote: > The security discussion at IETF #57 raised two issues that we agreed > would be brought to the list for comment.=20 >=20 > Issue #1 > TLS or IPsec mandatory to implement? >=20 > The security design team consensus was that the network designer > could either use TLS or IPsec as mandatory to implement for ENRP-PE > and ENRP-ENRP communication. The PU-ENRP was previously decided to > be mandatory to implement TLS for reasons of interoperability. =20 > Direction from the ADs and consensus in the meeting was that one > security mechanism should be made mandatory to implement for all. It > was agreed to select TLS as mandatory to implement by those attending > the meeting. Do the people on the list agree?=20 Agree. =20 =20 >=20 > Issue #2 > Security of ENRP server registrations and ENRP to ENRP communications >=20 It was agreed to > restrict the ENRP database to secure registrations only and secure > communications between ENRP servers OR insecure registrations only by > those attending the meeting. Do the people on the list agree? =20 I'm not sure that I understand what was agreed upon. Are we talking = about two modes of operation: (1) Secure registrations only and secure ENRP-ENRP traffic, and (2) Insecure registrations only and insecure ENRP-ENRP traffic? My feeling is that ENRP-ENRP should be secured in any case, but this may = not be practical. This will have an affect on the use of multicast between = ENRP servers and I believe that we should discuss this during the next = security design team meeting. (I have previously sent an email regarding this to = the design team members.) My thought would be to disallow use of multicast = in ENRPv1, but leave a section in the draft explaining how it could be used properly with secure multicast. Perhaps by ENRPv2, there will be a = secure IGMP or something similar. Developing our own custom secure multicast option should not be an option in my opinion.=20 In all likelihood, an operator with a closed system (not traversing the Internet) will probably choose to do whatever they want in terms of ENRP-ENRP security and multicast. =20 >=20 > Comments? >=20 > -- maureen >=20 Regards, Aron _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Aug 5 15:41:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23114 for ; Tue, 5 Aug 2003 14:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6xZ-0003Xk-Ek; Tue, 05 Aug 2003 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6xO-0003XS-2g for rserpool@optimus.ietf.org; Tue, 05 Aug 2003 14:54:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23092 for ; Tue, 5 Aug 2003 14:54:44 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6xL-0004sm-00 for rserpool@ietf.org; Tue, 05 Aug 2003 14:54:47 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19k6xK-0004si-00 for rserpool@ietf.org; Tue, 05 Aug 2003 14:54:46 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h75Isk123902 for ; Tue, 5 Aug 2003 13:54:46 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Aug 2003 13:54:46 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 13:54:22 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Aug 2003 13:54:20 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811021CFE7B@daebe007.americas.nokia.com> Thread-Topic: [Rserpool] Two security issues from IETF #57 Thread-Index: AcNRL+5QIGrMEPEjS1+/ZdaLH7XeQAKUqmTA To: , X-OriginalArrivalTime: 05 Aug 2003 18:54:22.0042 (UTC) FILETIME=[FB88ABA0:01C35B82] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Security design team conference call 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: quoted-printable The security design team will have a conference call to discuss this = issue and other security related issues. I'm suggesting either Aug. 14 = or Aug. 18 as possible dates at 10AM EST USA. Please send me e-mail if you wish to join us and indicate what date = would be good for you. Or you can suggest another time. -- maureen -----Original Message----- From: ext Silverton Aron-C1710C [mailto:Aron.J.Silverton@motorola.com] Sent: Wednesday, July 23, 2003 11:26 AM To: Stillman Maureen (NVO-NIC/Ithaca); 'rserpool@ietf.org' Subject: RE: [Rserpool] Two security issues from IETF #57 Hi Maureen, Comments inline. Maureen.Stillman@nokia.com wrote: > The security discussion at IETF #57 raised two issues that we agreed > would be brought to the list for comment.=20 >=20 > Issue #1 > TLS or IPsec mandatory to implement? >=20 > The security design team consensus was that the network designer > could either use TLS or IPsec as mandatory to implement for ENRP-PE > and ENRP-ENRP communication. The PU-ENRP was previously decided to > be mandatory to implement TLS for reasons of interoperability. =20 > Direction from the ADs and consensus in the meeting was that one > security mechanism should be made mandatory to implement for all. It > was agreed to select TLS as mandatory to implement by those attending > the meeting. Do the people on the list agree?=20 Agree. =20 =20 >=20 > Issue #2 > Security of ENRP server registrations and ENRP to ENRP communications >=20 It was agreed to > restrict the ENRP database to secure registrations only and secure > communications between ENRP servers OR insecure registrations only by > those attending the meeting. Do the people on the list agree? =20 I'm not sure that I understand what was agreed upon. Are we talking = about two modes of operation: (1) Secure registrations only and secure ENRP-ENRP traffic, and (2) Insecure registrations only and insecure ENRP-ENRP traffic? My feeling is that ENRP-ENRP should be secured in any case, but this may = not be practical. This will have an affect on the use of multicast between = ENRP servers and I believe that we should discuss this during the next = security design team meeting. (I have previously sent an email regarding this to = the design team members.) My thought would be to disallow use of multicast = in ENRPv1, but leave a section in the draft explaining how it could be used properly with secure multicast. Perhaps by ENRPv2, there will be a = secure IGMP or something similar. Developing our own custom secure multicast option should not be an option in my opinion.=20 In all likelihood, an operator with a closed system (not traversing the Internet) will probably choose to do whatever they want in terms of ENRP-ENRP security and multicast. =20 >=20 > Comments? >=20 > -- maureen >=20 Regards, Aron _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Aug 6 08:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14029 for ; Wed, 6 Aug 2003 08:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNPZ-0002nP-52; Wed, 06 Aug 2003 08:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNOu-0002mt-Ub for rserpool@optimus.ietf.org; Wed, 06 Aug 2003 08:28:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14002 for ; Wed, 6 Aug 2003 08:28:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kNOt-0002Ou-00 for rserpool@ietf.org; Wed, 06 Aug 2003 08:28:19 -0400 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 19kNOs-0002Ob-00 for rserpool@ietf.org; Wed, 06 Aug 2003 08:28:18 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DAE2743165 for ; Wed, 6 Aug 2003 14:27:43 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id CC96E99FCA for ; Wed, 6 Aug 2003 14:27:43 +0200 (CEST) Received: from requiem.it.uc3m.es (requiem.it.uc3m.es [163.117.139.166]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA27218 for ; Wed, 6 Aug 2003 14:27:43 +0200 From: Manuel =?ISO-8859-1?Q?Urue=F1a?= To: rserpool@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-prmeW1YpLssCR41oMCyG" Organization: Universidad Carlos III de Madrid Message-Id: <1060172597.2179.108.camel@requiem.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 06 Aug 2003 14:23:17 +0200 Subject: [Rserpool] Some comments about "draft-ietf-rserpool-applic-00.txt" 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: , --=-prmeW1YpLssCR41oMCyG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I've just read the draft-ietf-rserpool-applic-00.txt and several other Rserpool docs and I've found some typos and there are some paragraphs that I don't understand. Draft draft-ietf-rserpool-applic-00.txt says: Page 4: "The PU's may try to find out via the endpoint resolution protocol(ENRP) which PE's are active" As I have understood after reading draft-ietf-rserpool-arch-06.txt, (although the "Endpoint Name RESOLUTION Protocol" name is a bit misleading) ENRP is not employed by PUs to resolve the pool handle into the list of PEs belonging to the pool, but ASAP.NAME_RESOLUTION is used instead. ENRP servers (NS) speak ENRP among them to maintain a consistent view of the pools namespace.=20 IMHO this paragraph and some others later in the same page about this issue are misleading, aren't they? or is my view of Rserpool wrong? Some typos: Page 1: "...to applications which want to have High avialebility services." s/avialebility/availability/ Page 3: "Reliable server pooling provides protocols for providing higly=20 available services." s/higly/highly/ Page 3: "Transport and network level redundancy are handle by the transport and network layer protcols." s/handle/handled/ s/protcols/protocols/ Page 3: "The terms are commonly identified in related work and can be found in the Aggregate Server Access Protocol and Endpoint Name Resolution Protocol Common Parameters documentRFC COMM [5]." This document does not define any terminology, maybe reference [2]=20 "Architecture for Reliable Server Pooling" is better. Page 5: "May be used by allready existing applications which do not want to change the interface between PU and PE." s/allready/already/ Page 5: "All entities wil use Rspool protocols for communication withs their respective peers" s/wil/will/ s/Rspool/Rserpool/ s/withs/with/ Page 7: "No conegstion control is done..." s/conegstion/congestion/ Page 7: "Only the ENRP server responsible for that particular server pool will have a up to date view of the load distribution in the pool." s/a up/an up/ Page 10: "Rserpool protocols(ENRP and ASAP) do NOT provide any service for transfering state information of a application from one Processing Element(PE) to another" s/Processing Element/Pool Element/ Maybe the ASAP-Cookie mechanism should be cited here? Regards, --Manuel --=20 Manuel Uruen~a - Universidad Carlos III de Madrid GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75 --=-prmeW1YpLssCR41oMCyG Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/MPM1+rynn1U1WnURAuIzAJ4qMh6k5RdVK1n3HnJJwjo5TeC+MACgoFzm Wj8bnbbPaTDn6HzSOGnCN5g= =Xp70 -----END PGP SIGNATURE----- --=-prmeW1YpLssCR41oMCyG-- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Wed Aug 6 08:29:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14044 for ; Wed, 6 Aug 2003 08:29:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNPZ-0002nf-Ht for rserpool-archive@odin.ietf.org; Wed, 06 Aug 2003 08:29:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76CT1cf010762 for rserpool-archive@odin.ietf.org; Wed, 6 Aug 2003 08:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNPZ-0002nP-52; Wed, 06 Aug 2003 08:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNOu-0002mt-Ub for rserpool@optimus.ietf.org; Wed, 06 Aug 2003 08:28:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14002 for ; Wed, 6 Aug 2003 08:28:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kNOt-0002Ou-00 for rserpool@ietf.org; Wed, 06 Aug 2003 08:28:19 -0400 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 19kNOs-0002Ob-00 for rserpool@ietf.org; Wed, 06 Aug 2003 08:28:18 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DAE2743165 for ; Wed, 6 Aug 2003 14:27:43 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id CC96E99FCA for ; Wed, 6 Aug 2003 14:27:43 +0200 (CEST) Received: from requiem.it.uc3m.es (requiem.it.uc3m.es [163.117.139.166]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA27218 for ; Wed, 6 Aug 2003 14:27:43 +0200 From: Manuel =?ISO-8859-1?Q?Urue=F1a?= To: rserpool@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-prmeW1YpLssCR41oMCyG" Organization: Universidad Carlos III de Madrid Message-Id: <1060172597.2179.108.camel@requiem.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 06 Aug 2003 14:23:17 +0200 Subject: [Rserpool] Some comments about "draft-ietf-rserpool-applic-00.txt" 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: , --=-prmeW1YpLssCR41oMCyG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I've just read the draft-ietf-rserpool-applic-00.txt and several other Rserpool docs and I've found some typos and there are some paragraphs that I don't understand. Draft draft-ietf-rserpool-applic-00.txt says: Page 4: "The PU's may try to find out via the endpoint resolution protocol(ENRP) which PE's are active" As I have understood after reading draft-ietf-rserpool-arch-06.txt, (although the "Endpoint Name RESOLUTION Protocol" name is a bit misleading) ENRP is not employed by PUs to resolve the pool handle into the list of PEs belonging to the pool, but ASAP.NAME_RESOLUTION is used instead. ENRP servers (NS) speak ENRP among them to maintain a consistent view of the pools namespace.=20 IMHO this paragraph and some others later in the same page about this issue are misleading, aren't they? or is my view of Rserpool wrong? Some typos: Page 1: "...to applications which want to have High avialebility services." s/avialebility/availability/ Page 3: "Reliable server pooling provides protocols for providing higly=20 available services." s/higly/highly/ Page 3: "Transport and network level redundancy are handle by the transport and network layer protcols." s/handle/handled/ s/protcols/protocols/ Page 3: "The terms are commonly identified in related work and can be found in the Aggregate Server Access Protocol and Endpoint Name Resolution Protocol Common Parameters documentRFC COMM [5]." This document does not define any terminology, maybe reference [2]=20 "Architecture for Reliable Server Pooling" is better. Page 5: "May be used by allready existing applications which do not want to change the interface between PU and PE." s/allready/already/ Page 5: "All entities wil use Rspool protocols for communication withs their respective peers" s/wil/will/ s/Rspool/Rserpool/ s/withs/with/ Page 7: "No conegstion control is done..." s/conegstion/congestion/ Page 7: "Only the ENRP server responsible for that particular server pool will have a up to date view of the load distribution in the pool." s/a up/an up/ Page 10: "Rserpool protocols(ENRP and ASAP) do NOT provide any service for transfering state information of a application from one Processing Element(PE) to another" s/Processing Element/Pool Element/ Maybe the ASAP-Cookie mechanism should be cited here? Regards, --Manuel --=20 Manuel Uruen~a - Universidad Carlos III de Madrid GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75 --=-prmeW1YpLssCR41oMCyG Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/MPM1+rynn1U1WnURAuIzAJ4qMh6k5RdVK1n3HnJJwjo5TeC+MACgoFzm Wj8bnbbPaTDn6HzSOGnCN5g= =Xp70 -----END PGP SIGNATURE----- --=-prmeW1YpLssCR41oMCyG-- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Aug 14 16:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25505 for ; Thu, 14 Aug 2003 16:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOWr-0006cN-Vn; Thu, 14 Aug 2003 16:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOWX-0006bp-2Z for rserpool@optimus.ietf.org; Thu, 14 Aug 2003 16:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25490 for ; Thu, 14 Aug 2003 16:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nOWV-0005gf-00 for rserpool@ietf.org; Thu, 14 Aug 2003 16:16:39 -0400 Received: from sjmail.ciena.com ([12.7.169.25] helo=w2ksjexg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19nOWU-0005gW-00 for rserpool@ietf.org; Thu, 14 Aug 2003 16:16:38 -0400 Received: by w2ksjexg01.oni.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 13:16:27 -0700 Message-ID: <829F074A10F98943A218DC363D09C92AAE5F34@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'rserpool@ietf.org'" Date: Thu, 14 Aug 2003 13:16:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rserpool] WG Last Call on Rserpool Comparisons and Architecture documents 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: , Hi Folks, Sorry for the delay, both of your co-chairs were out of the office for a bit. We'd like to start WG Last Call on the Comparisons document (http://ietf.org/internet-drafts/draft-ietf-rserpool-comp-06.txt) and the Architecture document, as discussed at the Vienna meeting (http://ietf.org/internet-drafts/draft-ietf-rserpool-arch-06.txt). WG Last Call on the Comparisons document will be one week, since the document is an update to the previous one which already passed last call. Last Call will end on Friday, August 22nd. WG Last Call on the Architecture document will be two weeks, as we have not last called it before. Last Call will end on Friday, August 29th. If you have comments, please add the document title in the subject line, e.g., "Comparison Last Call Comment" or "Architecture Last Call Comment". Thanks, Lyndon & Maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Thu Aug 14 17:03:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25507 for ; Thu, 14 Aug 2003 16:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOWs-0006d9-G2 for rserpool-archive@odin.ietf.org; Thu, 14 Aug 2003 16:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EKH2QF025473 for rserpool-archive@odin.ietf.org; Thu, 14 Aug 2003 16:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOWr-0006cN-Vn; Thu, 14 Aug 2003 16:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOWX-0006bp-2Z for rserpool@optimus.ietf.org; Thu, 14 Aug 2003 16:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25490 for ; Thu, 14 Aug 2003 16:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nOWV-0005gf-00 for rserpool@ietf.org; Thu, 14 Aug 2003 16:16:39 -0400 Received: from sjmail.ciena.com ([12.7.169.25] helo=w2ksjexg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19nOWU-0005gW-00 for rserpool@ietf.org; Thu, 14 Aug 2003 16:16:38 -0400 Received: by w2ksjexg01.oni.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 13:16:27 -0700 Message-ID: <829F074A10F98943A218DC363D09C92AAE5F34@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'rserpool@ietf.org'" Date: Thu, 14 Aug 2003 13:16:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rserpool] WG Last Call on Rserpool Comparisons and Architecture documents 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: , Hi Folks, Sorry for the delay, both of your co-chairs were out of the office for a bit. We'd like to start WG Last Call on the Comparisons document (http://ietf.org/internet-drafts/draft-ietf-rserpool-comp-06.txt) and the Architecture document, as discussed at the Vienna meeting (http://ietf.org/internet-drafts/draft-ietf-rserpool-arch-06.txt). WG Last Call on the Comparisons document will be one week, since the document is an update to the previous one which already passed last call. Last Call will end on Friday, August 22nd. WG Last Call on the Architecture document will be two weeks, as we have not last called it before. Last Call will end on Friday, August 29th. If you have comments, please add the document title in the subject line, e.g., "Comparison Last Call Comment" or "Architecture Last Call Comment". Thanks, Lyndon & Maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Fri Aug 15 13:43:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06218 for ; Fri, 15 Aug 2003 13:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nib4-0007nV-LZ for rserpool-archive@odin.ietf.org; Fri, 15 Aug 2003 13:42:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHggbZ029969 for rserpool-archive@odin.ietf.org; Fri, 15 Aug 2003 13:42:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaQ-0007gZ-40; Fri, 15 Aug 2003 13:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaN-0007gE-LF for rserpool@optimus.ietf.org; Fri, 15 Aug 2003 13:41:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06183 for ; Fri, 15 Aug 2003 13:41:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niaL-0004ao-00 for rserpool@ietf.org; Fri, 15 Aug 2003 13:41:57 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19niaK-0004al-00 for rserpool@ietf.org; Fri, 15 Aug 2003 13:41:56 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7FHfuAD012651 for ; Fri, 15 Aug 2003 10:41:56 -0700 (MST) Received: from il02exm02.corp.mot.com (il02exm02.corp.mot.com [10.0.100.55]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h7FHfs85004209 for ; Fri, 15 Aug 2003 12:41:54 -0500 Received: by il02exm02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 15 Aug 2003 12:41:53 -0500 Message-ID: <4D87884B6A6D4E438A8592BCC9C85DCA0B32F69F@il02exm06.corp.mot.com> From: Silverton Aron-C1710C To: "'rserpool@ietf.org'" Date: Fri, 15 Aug 2003 12:41:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Subject: [Rserpool] ENRP server takeover procedure 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: , Hello, I have the following suggested changes to the procedure for taking-over a failed peer server. In particular, the Take-over Target Peer Server procedure in Section 4.10.2. I believe that this change will simplify the procedure by removing at least one message and eliminating a possible race condition that exists when the aggressor, i.e., the server initiating the take-over, fails between the PEER_TAKEOVER_SERVER message and the PEER_OWNERSHIP_CHANGE message(s). As the procedure is written today, a peer server will remove the failed peer from it's peer list upon receiving the PEER_TAKEOVER_SERVER message from the initiating server, but it will not update it's PE list until one or more PEER_OWNERSHIP_CHANGE messages are received. This creates a period of time when an ENRP server has PEs marked as being owned by another server which is no longer a peer. These orphaned PEs will not be resolved until an audit takes place or the PE realizes that its home server is no longer alive and looks for a new one. I think that we can avoid the delay and simplify the entire exchange as follows: 4.10.2 Take-over Target Peer Server The initiating ENRP server SHOULD first send, via an announcement, a PEER_TAKEOVER_SERVER message to inform all its active peers that the take-over is enforced. The target server's ID MUST be filled in the message. The initiating server SHOULD then remove the target server from its internal peer list. Then it SHOULD examine its local copy of the namespace and claim ownership of each of the PEs originally owned by the target server, by following these steps: 1. mark itself as the home ENRP server of each of the PEs originally owned by the target server; 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the PEs. This will trigger the PE to adopt the initiating server as its new home ENRP server; When a peer receives the PEER_TAKEOVER_SERVER message from the initiating server, it SHOULD update its local peer list and PE cache by following these steps: 1. remove the target server from its internal peer list; 2. update the home ENRP server of each PE in its local copy of the namespace to be the sender of the message, i.e., the initiating server. The PEER_OWNERSHIP_CHANGE exchanges are not needed in this procedure. Regards, Aron Aron J. Silverton Senior Staff Research Engineer Motorola Labs, Networks and Infrastructure Research Motorola, Inc. Telephone: 847-576-8747 Fax: 847-576-3240 mailto:Aron.J.Silverton@motorola.com _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Fri Aug 15 14:28:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06217 for ; Fri, 15 Aug 2003 13:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaQ-0007gZ-40; Fri, 15 Aug 2003 13:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaN-0007gE-LF for rserpool@optimus.ietf.org; Fri, 15 Aug 2003 13:41:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06183 for ; Fri, 15 Aug 2003 13:41:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niaL-0004ao-00 for rserpool@ietf.org; Fri, 15 Aug 2003 13:41:57 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19niaK-0004al-00 for rserpool@ietf.org; Fri, 15 Aug 2003 13:41:56 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7FHfuAD012651 for ; Fri, 15 Aug 2003 10:41:56 -0700 (MST) Received: from il02exm02.corp.mot.com (il02exm02.corp.mot.com [10.0.100.55]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h7FHfs85004209 for ; Fri, 15 Aug 2003 12:41:54 -0500 Received: by il02exm02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 15 Aug 2003 12:41:53 -0500 Message-ID: <4D87884B6A6D4E438A8592BCC9C85DCA0B32F69F@il02exm06.corp.mot.com> From: Silverton Aron-C1710C To: "'rserpool@ietf.org'" Date: Fri, 15 Aug 2003 12:41:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Subject: [Rserpool] ENRP server takeover procedure 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: , Hello, I have the following suggested changes to the procedure for taking-over a failed peer server. In particular, the Take-over Target Peer Server procedure in Section 4.10.2. I believe that this change will simplify the procedure by removing at least one message and eliminating a possible race condition that exists when the aggressor, i.e., the server initiating the take-over, fails between the PEER_TAKEOVER_SERVER message and the PEER_OWNERSHIP_CHANGE message(s). As the procedure is written today, a peer server will remove the failed peer from it's peer list upon receiving the PEER_TAKEOVER_SERVER message from the initiating server, but it will not update it's PE list until one or more PEER_OWNERSHIP_CHANGE messages are received. This creates a period of time when an ENRP server has PEs marked as being owned by another server which is no longer a peer. These orphaned PEs will not be resolved until an audit takes place or the PE realizes that its home server is no longer alive and looks for a new one. I think that we can avoid the delay and simplify the entire exchange as follows: 4.10.2 Take-over Target Peer Server The initiating ENRP server SHOULD first send, via an announcement, a PEER_TAKEOVER_SERVER message to inform all its active peers that the take-over is enforced. The target server's ID MUST be filled in the message. The initiating server SHOULD then remove the target server from its internal peer list. Then it SHOULD examine its local copy of the namespace and claim ownership of each of the PEs originally owned by the target server, by following these steps: 1. mark itself as the home ENRP server of each of the PEs originally owned by the target server; 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the PEs. This will trigger the PE to adopt the initiating server as its new home ENRP server; When a peer receives the PEER_TAKEOVER_SERVER message from the initiating server, it SHOULD update its local peer list and PE cache by following these steps: 1. remove the target server from its internal peer list; 2. update the home ENRP server of each PE in its local copy of the namespace to be the sender of the message, i.e., the initiating server. The PEER_OWNERSHIP_CHANGE exchanges are not needed in this procedure. Regards, Aron Aron J. Silverton Senior Staff Research Engineer Motorola Labs, Networks and Infrastructure Research Motorola, Inc. Telephone: 847-576-8747 Fax: 847-576-3240 mailto:Aron.J.Silverton@motorola.com _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Mon Aug 18 16:50:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04096 for ; Mon, 18 Aug 2003 16:50:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqwz-0004mn-FT; Mon, 18 Aug 2003 16:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqwo-0004mL-Ht for rserpool@optimus.ietf.org; Mon, 18 Aug 2003 16:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04076 for ; Mon, 18 Aug 2003 16:49:45 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqwm-0002US-00 for rserpool@ietf.org; Mon, 18 Aug 2003 16:49:48 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19oqwl-0002UP-00 for rserpool@ietf.org; Mon, 18 Aug 2003 16:49:47 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7IKnkG13059 for ; Mon, 18 Aug 2003 15:49:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 18 Aug 2003 15:49:44 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 18 Aug 2003 13:49:05 -0700 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" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Aug 2003 15:49:05 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81101222F27@daebe007.americas.nokia.com> Thread-Topic: Comments on the Rserpool architecture internet draft -- last call Thread-Index: AcNlyilEKG6uTI+ARr6cEtdINCIhkQ== To: X-OriginalArrivalTime: 18 Aug 2003 20:49:05.0908 (UTC) FILETIME=[2A020340:01C365CA] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Comments on the Rserpool architecture internet draft -- last call 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: quoted-printable There is no security considerations section in the architecture draft. = I should have caught this earlier -- my bad! Here is a suggestion: The Rserpool protocol must allow us to secure the Rserpool = infrastructure. There are security and privacy issues that relate to = the namespace, pool element registration and user queries of the = namespace. In [1] a complete threat analysis of Rserpool components is = presented. [1] Threats Introduced by Rserpool and Requirements for Security in = response to Threats, draft-ietf-rserpool-threats-00.txt, work in = progress. This is how it is handled in the OPES architecture document = http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-04.txt. I have some nits, but I'll send them tomorrow. =20 Of course, other suggestions are welcome. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Mon Aug 18 17:38:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04098 for ; Mon, 18 Aug 2003 16:50:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqx0-0004nM-Lg for rserpool-archive@odin.ietf.org; Mon, 18 Aug 2003 16:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IKo2QV018416 for rserpool-archive@odin.ietf.org; Mon, 18 Aug 2003 16:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqwz-0004mn-FT; Mon, 18 Aug 2003 16:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqwo-0004mL-Ht for rserpool@optimus.ietf.org; Mon, 18 Aug 2003 16:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04076 for ; Mon, 18 Aug 2003 16:49:45 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqwm-0002US-00 for rserpool@ietf.org; Mon, 18 Aug 2003 16:49:48 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19oqwl-0002UP-00 for rserpool@ietf.org; Mon, 18 Aug 2003 16:49:47 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7IKnkG13059 for ; Mon, 18 Aug 2003 15:49:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 18 Aug 2003 15:49:44 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 18 Aug 2003 13:49:05 -0700 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" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Aug 2003 15:49:05 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81101222F27@daebe007.americas.nokia.com> Thread-Topic: Comments on the Rserpool architecture internet draft -- last call Thread-Index: AcNlyilEKG6uTI+ARr6cEtdINCIhkQ== To: X-OriginalArrivalTime: 18 Aug 2003 20:49:05.0908 (UTC) FILETIME=[2A020340:01C365CA] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Comments on the Rserpool architecture internet draft -- last call 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: quoted-printable There is no security considerations section in the architecture draft. = I should have caught this earlier -- my bad! Here is a suggestion: The Rserpool protocol must allow us to secure the Rserpool = infrastructure. There are security and privacy issues that relate to = the namespace, pool element registration and user queries of the = namespace. In [1] a complete threat analysis of Rserpool components is = presented. [1] Threats Introduced by Rserpool and Requirements for Security in = response to Threats, draft-ietf-rserpool-threats-00.txt, work in = progress. This is how it is handled in the OPES architecture document = http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-04.txt. I have some nits, but I'll send them tomorrow. =20 Of course, other suggestions are welcome. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Aug 19 03:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00885 for ; Tue, 19 Aug 2003 03:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p1Ib-00028F-AV; Tue, 19 Aug 2003 03:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p1Hs-00027X-DN for rserpool@optimus.ietf.org; Tue, 19 Aug 2003 03:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00837 for ; Tue, 19 Aug 2003 03:52:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p1Hp-0005hU-00 for rserpool@ietf.org; Tue, 19 Aug 2003 03:52:13 -0400 Received: from viap100.atea.be ([194.78.143.100] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 19p1Hn-0005hK-00 for rserpool@ietf.org; Tue, 19 Aug 2003 03:52:12 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QY8RRYST; Tue, 19 Aug 2003 09:51:35 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 09:51:34 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F428@hrtades7.atea.be> From: Coene Lode To: =?iso-8859-1?Q?=27Manuel_Urue=F1a=27?= , rserpool@ietf.org Subject: RE: [Rserpool] Some comments about "draft-ietf-rserpool-applic-00 .txt" Date: Tue, 19 Aug 2003 09:51:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable sorry for the delay in answering. See below for comments. > -----Original Message----- > From: Manuel Urue=F1a [mailto:muruenya@it.uc3m.es] > Sent: Wednesday, August 06, 2003 2:23 PM > To: rserpool@ietf.org > Subject: [Rserpool] Some comments about > "draft-ietf-rserpool-applic-00.txt" >=20 >=20 > Hello, >=20 > I've just read the draft-ietf-rserpool-applic-00.txt and several = other > Rserpool docs and I've found some typos and there are some paragraphs > that I don't understand. >=20 > Draft draft-ietf-rserpool-applic-00.txt says: >=20 > Page 4: "The PU's may try to find out via the endpoint resolution > protocol(ENRP) which PE's are active" >=20 > As I have understood after reading draft-ietf-rserpool-arch-06.txt, > (although the "Endpoint Name RESOLUTION Protocol" name is a bit > misleading) ENRP is not employed by PUs to resolve the pool=20 > handle into > the list of PEs belonging to the pool, but=20 > ASAP.NAME_RESOLUTION is used > instead. ENRP servers (NS) speak ENRP among them to maintain a > consistent view of the pools namespace.=20 >=20 > IMHO this paragraph and some others later in the same page about this > issue are misleading, aren't they? or is my view of Rserpool wrong? Yep, they are. I'll try to come up with something more correct. Must = have been confused... Does happen from time to time... >=20 >=20 > Some typos: >=20 > Page 1: "...to applications which want to have High avialebility > services." >=20 > s/avialebility/availability/ >=20 > Page 3: "Reliable server pooling provides protocols for=20 > providing higly=20 > available services." >=20 > s/higly/highly/ >=20 > Page 3: "Transport and network level redundancy are handle by the > transport and network layer protcols." >=20 > s/handle/handled/ > s/protcols/protocols/ >=20 > Page 3: "The terms are commonly identified in related work and can be > found in the Aggregate Server Access Protocol and Endpoint Name > Resolution Protocol Common Parameters documentRFC COMM [5]." >=20 > This document does not define any terminology, maybe reference [2]=20 > "Architecture for Reliable Server Pooling" is better. >=20 > Page 5: "May be used by allready existing applications which=20 > do not want > to change the interface between PU and PE." >=20 > s/allready/already/ >=20 > Page 5: "All entities wil use Rspool protocols for communication = withs > their respective peers" >=20 > s/wil/will/ > s/Rspool/Rserpool/ > s/withs/with/ >=20 > Page 7: "No conegstion control is done..." >=20 > s/conegstion/congestion/ >=20 > Page 7: "Only the ENRP server responsible for that particular server > pool will have a up to date view of the load distribution in=20 > the pool." >=20 > s/a up/an up/ >=20 All typos fixed... Thanks > Page 10: "Rserpool protocols(ENRP and ASAP) do NOT provide any = service > for transfering state information of a application from one = Processing > Element(PE) to another" >=20 > s/Processing Element/Pool Element/ >=20 > Maybe the ASAP-Cookie mechanism should be cited here? Put something extra here. It is true that the protocol does not have provisions for the direct state transfer between 2 PE(meaning from one = PE directly to another PE) but the ASAP cookie mechanism can be used to do = some state sharing via the PU(more or less indirect..PE -> PU -> PE..) Will try to make it clearer. >=20 > Regards, > --Manuel >=20 > --=20 > Manuel Uruen~a - Universidad Carlos III de Madrid > GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75 >=20 I've also put in some stuff from the service draft(more particular the chapter 4 of the services draft) I'm going to let it pass by Petere and Phil so they can check it out first.(and add or/and remove some stuff...) Thanks Manuel for the comments. your sincerly, Lode Siemens atea atealaan 34 2200 Herentals, Belgium E-mail: lode.coene@siemens.com Tel: +32-14-252081 Fax: +32-14-253212 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Tue Aug 19 03:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00913 for ; Tue, 19 Aug 2003 03:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p1Ie-00029f-PI for rserpool-archive@odin.ietf.org; Tue, 19 Aug 2003 03:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J7r4Lm008215 for rserpool-archive@odin.ietf.org; Tue, 19 Aug 2003 03:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p1Ib-00028F-AV; Tue, 19 Aug 2003 03:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p1Hs-00027X-DN for rserpool@optimus.ietf.org; Tue, 19 Aug 2003 03:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00837 for ; Tue, 19 Aug 2003 03:52:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p1Hp-0005hU-00 for rserpool@ietf.org; Tue, 19 Aug 2003 03:52:13 -0400 Received: from viap100.atea.be ([194.78.143.100] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 19p1Hn-0005hK-00 for rserpool@ietf.org; Tue, 19 Aug 2003 03:52:12 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QY8RRYST; Tue, 19 Aug 2003 09:51:35 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 09:51:34 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F428@hrtades7.atea.be> From: Coene Lode To: =?iso-8859-1?Q?=27Manuel_Urue=F1a=27?= , rserpool@ietf.org Subject: RE: [Rserpool] Some comments about "draft-ietf-rserpool-applic-00 .txt" Date: Tue, 19 Aug 2003 09:51:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable sorry for the delay in answering. See below for comments. > -----Original Message----- > From: Manuel Urue=F1a [mailto:muruenya@it.uc3m.es] > Sent: Wednesday, August 06, 2003 2:23 PM > To: rserpool@ietf.org > Subject: [Rserpool] Some comments about > "draft-ietf-rserpool-applic-00.txt" >=20 >=20 > Hello, >=20 > I've just read the draft-ietf-rserpool-applic-00.txt and several = other > Rserpool docs and I've found some typos and there are some paragraphs > that I don't understand. >=20 > Draft draft-ietf-rserpool-applic-00.txt says: >=20 > Page 4: "The PU's may try to find out via the endpoint resolution > protocol(ENRP) which PE's are active" >=20 > As I have understood after reading draft-ietf-rserpool-arch-06.txt, > (although the "Endpoint Name RESOLUTION Protocol" name is a bit > misleading) ENRP is not employed by PUs to resolve the pool=20 > handle into > the list of PEs belonging to the pool, but=20 > ASAP.NAME_RESOLUTION is used > instead. ENRP servers (NS) speak ENRP among them to maintain a > consistent view of the pools namespace.=20 >=20 > IMHO this paragraph and some others later in the same page about this > issue are misleading, aren't they? or is my view of Rserpool wrong? Yep, they are. I'll try to come up with something more correct. Must = have been confused... Does happen from time to time... >=20 >=20 > Some typos: >=20 > Page 1: "...to applications which want to have High avialebility > services." >=20 > s/avialebility/availability/ >=20 > Page 3: "Reliable server pooling provides protocols for=20 > providing higly=20 > available services." >=20 > s/higly/highly/ >=20 > Page 3: "Transport and network level redundancy are handle by the > transport and network layer protcols." >=20 > s/handle/handled/ > s/protcols/protocols/ >=20 > Page 3: "The terms are commonly identified in related work and can be > found in the Aggregate Server Access Protocol and Endpoint Name > Resolution Protocol Common Parameters documentRFC COMM [5]." >=20 > This document does not define any terminology, maybe reference [2]=20 > "Architecture for Reliable Server Pooling" is better. >=20 > Page 5: "May be used by allready existing applications which=20 > do not want > to change the interface between PU and PE." >=20 > s/allready/already/ >=20 > Page 5: "All entities wil use Rspool protocols for communication = withs > their respective peers" >=20 > s/wil/will/ > s/Rspool/Rserpool/ > s/withs/with/ >=20 > Page 7: "No conegstion control is done..." >=20 > s/conegstion/congestion/ >=20 > Page 7: "Only the ENRP server responsible for that particular server > pool will have a up to date view of the load distribution in=20 > the pool." >=20 > s/a up/an up/ >=20 All typos fixed... Thanks > Page 10: "Rserpool protocols(ENRP and ASAP) do NOT provide any = service > for transfering state information of a application from one = Processing > Element(PE) to another" >=20 > s/Processing Element/Pool Element/ >=20 > Maybe the ASAP-Cookie mechanism should be cited here? Put something extra here. It is true that the protocol does not have provisions for the direct state transfer between 2 PE(meaning from one = PE directly to another PE) but the ASAP cookie mechanism can be used to do = some state sharing via the PU(more or less indirect..PE -> PU -> PE..) Will try to make it clearer. >=20 > Regards, > --Manuel >=20 > --=20 > Manuel Uruen~a - Universidad Carlos III de Madrid > GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75 >=20 I've also put in some stuff from the service draft(more particular the chapter 4 of the services draft) I'm going to let it pass by Petere and Phil so they can check it out first.(and add or/and remove some stuff...) Thanks Manuel for the comments. your sincerly, Lode Siemens atea atealaan 34 2200 Herentals, Belgium E-mail: lode.coene@siemens.com Tel: +32-14-252081 Fax: +32-14-253212 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Tue Aug 19 16:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08104 for ; Tue, 19 Aug 2003 16:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDGs-00023k-2N for rserpool-archive@odin.ietf.org; Tue, 19 Aug 2003 16:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JKe2IK007912 for rserpool-archive@odin.ietf.org; Tue, 19 Aug 2003 16:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDGr-00023K-8B; Tue, 19 Aug 2003 16:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDGi-00021u-F3 for rserpool@optimus.ietf.org; Tue, 19 Aug 2003 16:39:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08072 for ; Tue, 19 Aug 2003 16:39:47 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pDGg-0007jo-00 for rserpool@ietf.org; Tue, 19 Aug 2003 16:39:50 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19pDGf-0007ji-00 for rserpool@ietf.org; Tue, 19 Aug 2003 16:39:49 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7JKdmG00282 for ; Tue, 19 Aug 2003 15:39:48 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Aug 2003 15:39:38 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 13:38:44 -0700 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2003 15:38:44 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81101222F34@daebe007.americas.nokia.com> Thread-Topic: Comments on architecture document -- last call Thread-Index: AcNmkeGiJxa64wx9R2+YHnqGehGF3g== To: X-OriginalArrivalTime: 19 Aug 2003 20:38:44.0761 (UTC) FILETIME=[E2304090:01C36691] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Comments on architecture document -- last call 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: quoted-printable I read this carefully. Here are my comments. Non-nits: 2.2.1 Endpoint Name Resolution Protocol The name servers use a protocol called Endpoint Name Resolution Protocol (ENRP) for communication with each other to make sure that all have the same information about the server pools. I'm concerned that this will spark a lengthy debate about = synchronization of ENRP databases. We can't guarantee instantaneous = updates of the database and a perfectly synchronized name space. How = about something like: The name servers use a protocol called Endpoint Name Resolution Protocol (ENRP) for communication with each other to exchange = information and updates about the server pools. 2.2.2 Aggregate Server Access Protocol ASAP in conjunction with ENRP provides a fault tolerant data transfer mechanism over IP networks.=20 I'm concerned that this will be interpreted as a general feature with = some sort of guarantee. It is only offered by use of specific services = described in services document. In other words, this will imply that it = offers transparent fail-over in all cases which is not true. Even with = that, there is no guarantee of uninterrupted service. It is best = effort. I would delete this sentence or talk about services and = different possibilities. These are discussed in the services document. In addition, ASAP defines each logical communication destination as a server pool, providing full transparent support for server-pooling and load sharing. I don't understand this statement. What is a logical communication = destination? =20 ASAP is also used by a server to join or leave a server pool. It registers or deregisters itself by communicating with a name server, which will normally the home NS. =20 see changes below: ASAP is also used by a PE to join or leave a server pool. It registers or deregisters itself by communicating with a name server, which will normally be the home NS. =20 ASAP allows dynamic system scalability, allowing the pool membership to change at any time without interruption of the service. Same concern as above. This is only offered by use of specific services = described in services document. Even with that, there is no guarantee = of uninterrupted service. It is best effort. Nits: 1.1 Overview This document defines an architecture, for providinge a highly available reliable server function in support of some service. The way this is achieved is by forming a pool of servers, each of which is capable of supporting the desired service, and providing a name service that=20 see changes below, misspelled words: This document defines an architecture, for *providing* a highly available reliable server function in support of a service or set of = services.=20 This is achieved by forming a pool of servers, each of which is capable of supporting the desired service(s), and providing a name service that... 2.1 RSerPool Functional Components Each server pool will be identifiable by a unique name which is simply a byte string, called the pool handle.=20 see changes below: Each server pool is identified by a unique name which is simply a byte string, called the pool handle.=20 o A protocol field of the IP header specifying the transport layer protocol or protocols. see changes below: o A protocol field specifying the transport layer protocol or protocols. Please note that the RSerPool architecture supports both IPv4 and IPv6 addressing. A PE can also support multiple transport layers. see changes below: Note that the RSerPool architecture supports both IPv4 and IPv6 addressing. A PE can also support multiple transport protocols. 2.2.1 ENRP employs a client-server model with which an name server will respond to the name translation service requests from endpoint clients running on the same host or running on different hosts. see changes below: ENRP employs a client-server model in which a name server will respond to the name translation service requests from endpoint clients. 2.2.3 PU <-> NS Communication The PU <-> NS communication is used for doing name queries.=20 see changes below: The PU <-> NS communication is used for performing name queries. 2.2.4 PE <-> NS Communication The PE <-> NS communication is used for registration and deregistration of the PE in one ore more pools and for the misspelled word: The PE <-> NS communication is used for registration and deregistration of the PE in one *or* more pools and for the o Multiplexed data and control channel. Both channels are transported over one transport connection. This can either be an SCTP association, with data and control channel are seperated by the PPID, or an TCP connection, with data and control channel being handled by a TCP mapping layer. misspelled word: o Multiplexed data and control channel. Both channels are transported over one transport connection. This can either be an SCTP association, with data and control channel are *separated* by the PPID, or an TCP connection, with data and control channel being handled by a TCP mapping layer. When a name server boots up a UDP multicast message may be sent out for initial detection of other name servers in the operational scope. The other name servers send an answer using a unicast UDP message. Aren't we addressing multicast at a later time? If so, delete this = paragraph. Otherwise, some nits: When a name server initializes a UDP multicast message may be = transmitted for initial detection of other name servers in the operational scope. The other name servers send a response using a unicast UDP message. 2.3.1 communication may not be know by the peer. Providing information to which PE the OU should failover can also be very important. Consider the scenario given in the following figure. misspelled words: communication may not be *known* by the peer. Providing information to which PE the *PU* should failover can also = be very important. Consider the scenario *presented* in the following = figure. Figure 4 Two PE accessing the same PE Should be: Two PUs accessing the same PE 2.3.2 Cookies Cookies may be sent from the PE to the PU if the PE wants to do this. The PU only stores the last received cookie. In case of a fail over it sends this last received cookie to the new PE.=20 some changes: Cookies may optionally be sent from the PE to the PU. The PU only stores the last received cookie. In case of fail over the PU sends this last received cookie to the new PE.=20 [Editors note] This section has not been updated. The examples will be updated after the architecture has been finalized. Please delete this. 3.1 After figure 8: 1. the Signaling Gateway (SG) receives an incoming signaling message to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP request to its "local" NS to request the list of pool elements (PE's) of GWC (using (a)). The key used for this query is the pool handle of the GWC. The ASAP layer queues the data to be sent in local buffers until the NS responds. Don't use the word "key" for this as it sounds like some security key. = Use bit string or some other phrase. some change: The bit string used for this query is the pool handle of the GWC. The ASAP layer queues the data to be sent = to the GWC in local buffers until the NS responds. OK, I think that is it for now. -- maureen=20 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Aug 19 17:29:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08103 for ; Tue, 19 Aug 2003 16:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDGr-00023K-8B; Tue, 19 Aug 2003 16:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDGi-00021u-F3 for rserpool@optimus.ietf.org; Tue, 19 Aug 2003 16:39:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08072 for ; Tue, 19 Aug 2003 16:39:47 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pDGg-0007jo-00 for rserpool@ietf.org; Tue, 19 Aug 2003 16:39:50 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19pDGf-0007ji-00 for rserpool@ietf.org; Tue, 19 Aug 2003 16:39:49 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7JKdmG00282 for ; Tue, 19 Aug 2003 15:39:48 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Aug 2003 15:39:38 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 13:38:44 -0700 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2003 15:38:44 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81101222F34@daebe007.americas.nokia.com> Thread-Topic: Comments on architecture document -- last call Thread-Index: AcNmkeGiJxa64wx9R2+YHnqGehGF3g== To: X-OriginalArrivalTime: 19 Aug 2003 20:38:44.0761 (UTC) FILETIME=[E2304090:01C36691] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Comments on architecture document -- last call 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: quoted-printable I read this carefully. Here are my comments. Non-nits: 2.2.1 Endpoint Name Resolution Protocol The name servers use a protocol called Endpoint Name Resolution Protocol (ENRP) for communication with each other to make sure that all have the same information about the server pools. I'm concerned that this will spark a lengthy debate about = synchronization of ENRP databases. We can't guarantee instantaneous = updates of the database and a perfectly synchronized name space. How = about something like: The name servers use a protocol called Endpoint Name Resolution Protocol (ENRP) for communication with each other to exchange = information and updates about the server pools. 2.2.2 Aggregate Server Access Protocol ASAP in conjunction with ENRP provides a fault tolerant data transfer mechanism over IP networks.=20 I'm concerned that this will be interpreted as a general feature with = some sort of guarantee. It is only offered by use of specific services = described in services document. In other words, this will imply that it = offers transparent fail-over in all cases which is not true. Even with = that, there is no guarantee of uninterrupted service. It is best = effort. I would delete this sentence or talk about services and = different possibilities. These are discussed in the services document. In addition, ASAP defines each logical communication destination as a server pool, providing full transparent support for server-pooling and load sharing. I don't understand this statement. What is a logical communication = destination? =20 ASAP is also used by a server to join or leave a server pool. It registers or deregisters itself by communicating with a name server, which will normally the home NS. =20 see changes below: ASAP is also used by a PE to join or leave a server pool. It registers or deregisters itself by communicating with a name server, which will normally be the home NS. =20 ASAP allows dynamic system scalability, allowing the pool membership to change at any time without interruption of the service. Same concern as above. This is only offered by use of specific services = described in services document. Even with that, there is no guarantee = of uninterrupted service. It is best effort. Nits: 1.1 Overview This document defines an architecture, for providinge a highly available reliable server function in support of some service. The way this is achieved is by forming a pool of servers, each of which is capable of supporting the desired service, and providing a name service that=20 see changes below, misspelled words: This document defines an architecture, for *providing* a highly available reliable server function in support of a service or set of = services.=20 This is achieved by forming a pool of servers, each of which is capable of supporting the desired service(s), and providing a name service that... 2.1 RSerPool Functional Components Each server pool will be identifiable by a unique name which is simply a byte string, called the pool handle.=20 see changes below: Each server pool is identified by a unique name which is simply a byte string, called the pool handle.=20 o A protocol field of the IP header specifying the transport layer protocol or protocols. see changes below: o A protocol field specifying the transport layer protocol or protocols. Please note that the RSerPool architecture supports both IPv4 and IPv6 addressing. A PE can also support multiple transport layers. see changes below: Note that the RSerPool architecture supports both IPv4 and IPv6 addressing. A PE can also support multiple transport protocols. 2.2.1 ENRP employs a client-server model with which an name server will respond to the name translation service requests from endpoint clients running on the same host or running on different hosts. see changes below: ENRP employs a client-server model in which a name server will respond to the name translation service requests from endpoint clients. 2.2.3 PU <-> NS Communication The PU <-> NS communication is used for doing name queries.=20 see changes below: The PU <-> NS communication is used for performing name queries. 2.2.4 PE <-> NS Communication The PE <-> NS communication is used for registration and deregistration of the PE in one ore more pools and for the misspelled word: The PE <-> NS communication is used for registration and deregistration of the PE in one *or* more pools and for the o Multiplexed data and control channel. Both channels are transported over one transport connection. This can either be an SCTP association, with data and control channel are seperated by the PPID, or an TCP connection, with data and control channel being handled by a TCP mapping layer. misspelled word: o Multiplexed data and control channel. Both channels are transported over one transport connection. This can either be an SCTP association, with data and control channel are *separated* by the PPID, or an TCP connection, with data and control channel being handled by a TCP mapping layer. When a name server boots up a UDP multicast message may be sent out for initial detection of other name servers in the operational scope. The other name servers send an answer using a unicast UDP message. Aren't we addressing multicast at a later time? If so, delete this = paragraph. Otherwise, some nits: When a name server initializes a UDP multicast message may be = transmitted for initial detection of other name servers in the operational scope. The other name servers send a response using a unicast UDP message. 2.3.1 communication may not be know by the peer. Providing information to which PE the OU should failover can also be very important. Consider the scenario given in the following figure. misspelled words: communication may not be *known* by the peer. Providing information to which PE the *PU* should failover can also = be very important. Consider the scenario *presented* in the following = figure. Figure 4 Two PE accessing the same PE Should be: Two PUs accessing the same PE 2.3.2 Cookies Cookies may be sent from the PE to the PU if the PE wants to do this. The PU only stores the last received cookie. In case of a fail over it sends this last received cookie to the new PE.=20 some changes: Cookies may optionally be sent from the PE to the PU. The PU only stores the last received cookie. In case of fail over the PU sends this last received cookie to the new PE.=20 [Editors note] This section has not been updated. The examples will be updated after the architecture has been finalized. Please delete this. 3.1 After figure 8: 1. the Signaling Gateway (SG) receives an incoming signaling message to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP request to its "local" NS to request the list of pool elements (PE's) of GWC (using (a)). The key used for this query is the pool handle of the GWC. The ASAP layer queues the data to be sent in local buffers until the NS responds. Don't use the word "key" for this as it sounds like some security key. = Use bit string or some other phrase. some change: The bit string used for this query is the pool handle of the GWC. The ASAP layer queues the data to be sent = to the GWC in local buffers until the NS responds. OK, I think that is it for now. -- maureen=20 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Wed Aug 20 16:34:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08762 for ; Wed, 20 Aug 2003 16:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZee-0003cA-Bl for rserpool-archive@odin.ietf.org; Wed, 20 Aug 2003 16:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KKY4Tw013894 for rserpool-archive@odin.ietf.org; Wed, 20 Aug 2003 16:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZeb-0003bk-69; Wed, 20 Aug 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZdf-0003ay-Qw for rserpool@optimus.ietf.org; Wed, 20 Aug 2003 16:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08698 for ; Wed, 20 Aug 2003 16:32:57 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZdd-0007Rd-00 for rserpool@ietf.org; Wed, 20 Aug 2003 16:33:01 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19pZdd-0007RS-00 for rserpool@ietf.org; Wed, 20 Aug 2003 16:33:01 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7KKWxG13537 for ; Wed, 20 Aug 2003 15:32:59 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Aug 2003 15:32:59 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 20 Aug 2003 15:32:49 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Aug 2003 15:32:49 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811021CFE9A@daebe007.americas.nokia.com> Thread-Topic: Comments on the comparison document Thread-Index: AcNnWji1JMsTFzGuRqOeSzfdw69sCg== To: X-OriginalArrivalTime: 20 Aug 2003 20:32:49.0619 (UTC) FILETIME=[38EBA230:01C3675A] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Comments on the comparison document 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: quoted-printable I have mostly nits which are optional. Non-nits are first. Non-nits: 2.3.3 Summary of SLP Issues 4th paragraph SLP security makes no attempt to address the confidentiality of data transmitted between SLP agents. To properly address this concern, SLP agents would need to establish secure communication with each other. This would be achieved through the use of IPSec Encapsulating Security Payload. I know from David Black that they changed some of the security in SLP to = accommodate IP Storage. So I'm not sure if this is still an issue. I = can ask David what they changed or we can delete this, your choice. = This single point does not change the our conclusion, however. 3.2.2 Technical Issues Most of the extended features of ASAP [6] and ENRP [7] are not met by a device employing L4 switching techniques. The use of the word "extended" has potential for confusion. They might = think that ASAP and ENRP have a set of extensions that L4 switches don't = support. In fact, ASAP and ENRP don't have any extensions defined right = now. I have two suggestions: 1) delete the word extended and 2) add to = the end of the sentence (see comparison table in section 5) OR you could = list some of the requirements that L4 switches don't meet. 4.2 ENRP Another important aspect of ENRP is that itself is fully distributed and replicated. This is to avoid the name service itself becoming a single point of failure in the system. This wording has the potential for the reader erroneously concluding = that ENRP servers have perfectly synchronized databases. Also "fully = distributed" might cause confusion as it leaves out the operational = scope which is technically what ENRP is limited to. How about this excellent wording taken directly from the ENRP internet = draft abstract. Then put your last sentence at the end.: Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This is to avoid the name service itself = becoming a single point of failure in the system. Nits: Name Server: Entity which the responsible for managing and maintaining the name space within the RSERPOOL operation scope. change to (* to help you find the word(s) to change): Name Server: Entity which *is* responsible for managing and maintaining the name space within the RSERPOOL operation scope. 2.2 One requirement to any solution proposed by RSERPOOL would be to =20 change to (* to help you find the word(s) to change): One requirement *of* any solution proposed by RSERPOOL would be to =20 2.2.1 These requirements are related to DNS. confusing. How about: These requirements are discussed below in relation to DNS. 2.2.2.6 Without significant extensions, the current DNS would have difficulty to achieve this type of name mapping. change to (* to help you find the word(s) to change): Without significant extensions, the current DNS would have difficulty *achieving* this type of name mapping. 2.2.2.7 These models basically define how a PE is going to behave when another PE=20 change to (* to help you find the word(s) to change): These models basically define how a PE *behaves* when another PE 3.1 Introduction Since these technologies are highly proprietary, it is difficult to detail these techniques in a thorough manner. change to (* to help you find the word(s) to change): Since these technologies are highly proprietary, it is difficult to *discuss* these techniques = in a thorough manner.=20 4.1 ASAP And ASAP allows extensions to be made in the future to accommodate new load delete the And.... ASAP allows extensions to be made in the future to accommodate new load ASAP supports the "keepalive" monitoring of PEs by the name server and session failover, in which a set of application messages are defined as a "session" and ASAP provides best-effort transmission of all the messages in the "session" to the same PE in the destination pool, and failover the remaining message in the "session" to the same alternate PE if the first PE fails. Failover is not provided for all classes of service. Need to fix one = word as well. How about: and for some classes of service can provide failover *for* the = remaining message in the "session" to *an* alternate PE if the first PE fails. 4.2 ENRP ENRP itself is dynamically scalable, meaning that new ENRP servers can be added and existing servers be removed as needed. This feature can be used to achieve zero planned downtime upgrade of a system - an often found requirement in many mission critical applications. change to (* to help you find the word(s) to change): ENRP itself is dynamically scalable, meaning that new ENRP servers can be added and existing servers *can* be removed as needed. This = feature can be used to achieve zero planned downtime upgrade of a system - an *common* requirement *for* many mission critical applications. I think this is it. Thanks. =20 -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Aug 20 17:29:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08760 for ; Wed, 20 Aug 2003 16:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZeb-0003bk-69; Wed, 20 Aug 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZdf-0003ay-Qw for rserpool@optimus.ietf.org; Wed, 20 Aug 2003 16:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08698 for ; Wed, 20 Aug 2003 16:32:57 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZdd-0007Rd-00 for rserpool@ietf.org; Wed, 20 Aug 2003 16:33:01 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19pZdd-0007RS-00 for rserpool@ietf.org; Wed, 20 Aug 2003 16:33:01 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7KKWxG13537 for ; Wed, 20 Aug 2003 15:32:59 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Aug 2003 15:32:59 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 20 Aug 2003 15:32:49 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Aug 2003 15:32:49 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811021CFE9A@daebe007.americas.nokia.com> Thread-Topic: Comments on the comparison document Thread-Index: AcNnWji1JMsTFzGuRqOeSzfdw69sCg== To: X-OriginalArrivalTime: 20 Aug 2003 20:32:49.0619 (UTC) FILETIME=[38EBA230:01C3675A] Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] Comments on the comparison document 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: quoted-printable I have mostly nits which are optional. Non-nits are first. Non-nits: 2.3.3 Summary of SLP Issues 4th paragraph SLP security makes no attempt to address the confidentiality of data transmitted between SLP agents. To properly address this concern, SLP agents would need to establish secure communication with each other. This would be achieved through the use of IPSec Encapsulating Security Payload. I know from David Black that they changed some of the security in SLP to = accommodate IP Storage. So I'm not sure if this is still an issue. I = can ask David what they changed or we can delete this, your choice. = This single point does not change the our conclusion, however. 3.2.2 Technical Issues Most of the extended features of ASAP [6] and ENRP [7] are not met by a device employing L4 switching techniques. The use of the word "extended" has potential for confusion. They might = think that ASAP and ENRP have a set of extensions that L4 switches don't = support. In fact, ASAP and ENRP don't have any extensions defined right = now. I have two suggestions: 1) delete the word extended and 2) add to = the end of the sentence (see comparison table in section 5) OR you could = list some of the requirements that L4 switches don't meet. 4.2 ENRP Another important aspect of ENRP is that itself is fully distributed and replicated. This is to avoid the name service itself becoming a single point of failure in the system. This wording has the potential for the reader erroneously concluding = that ENRP servers have perfectly synchronized databases. Also "fully = distributed" might cause confusion as it leaves out the operational = scope which is technically what ENRP is limited to. How about this excellent wording taken directly from the ENRP internet = draft abstract. Then put your last sentence at the end.: Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This is to avoid the name service itself = becoming a single point of failure in the system. Nits: Name Server: Entity which the responsible for managing and maintaining the name space within the RSERPOOL operation scope. change to (* to help you find the word(s) to change): Name Server: Entity which *is* responsible for managing and maintaining the name space within the RSERPOOL operation scope. 2.2 One requirement to any solution proposed by RSERPOOL would be to =20 change to (* to help you find the word(s) to change): One requirement *of* any solution proposed by RSERPOOL would be to =20 2.2.1 These requirements are related to DNS. confusing. How about: These requirements are discussed below in relation to DNS. 2.2.2.6 Without significant extensions, the current DNS would have difficulty to achieve this type of name mapping. change to (* to help you find the word(s) to change): Without significant extensions, the current DNS would have difficulty *achieving* this type of name mapping. 2.2.2.7 These models basically define how a PE is going to behave when another PE=20 change to (* to help you find the word(s) to change): These models basically define how a PE *behaves* when another PE 3.1 Introduction Since these technologies are highly proprietary, it is difficult to detail these techniques in a thorough manner. change to (* to help you find the word(s) to change): Since these technologies are highly proprietary, it is difficult to *discuss* these techniques = in a thorough manner.=20 4.1 ASAP And ASAP allows extensions to be made in the future to accommodate new load delete the And.... ASAP allows extensions to be made in the future to accommodate new load ASAP supports the "keepalive" monitoring of PEs by the name server and session failover, in which a set of application messages are defined as a "session" and ASAP provides best-effort transmission of all the messages in the "session" to the same PE in the destination pool, and failover the remaining message in the "session" to the same alternate PE if the first PE fails. Failover is not provided for all classes of service. Need to fix one = word as well. How about: and for some classes of service can provide failover *for* the = remaining message in the "session" to *an* alternate PE if the first PE fails. 4.2 ENRP ENRP itself is dynamically scalable, meaning that new ENRP servers can be added and existing servers be removed as needed. This feature can be used to achieve zero planned downtime upgrade of a system - an often found requirement in many mission critical applications. change to (* to help you find the word(s) to change): ENRP itself is dynamically scalable, meaning that new ENRP servers can be added and existing servers *can* be removed as needed. This = feature can be used to achieve zero planned downtime upgrade of a system - an *common* requirement *for* many mission critical applications. I think this is it. Thanks. =20 -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Aug 21 12:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14171 for ; Thu, 21 Aug 2003 12:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psfK-0000ED-Ae; Thu, 21 Aug 2003 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psel-0000DB-9L for rserpool@optimus.ietf.org; Thu, 21 Aug 2003 12:51:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14137 for ; Thu, 21 Aug 2003 12:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19psej-0005hk-00 for rserpool@ietf.org; Thu, 21 Aug 2003 12:51:25 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19psei-0005hh-00 for rserpool@ietf.org; Thu, 21 Aug 2003 12:51:24 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h7LGpNbh026908 for ; Thu, 21 Aug 2003 09:51:23 -0700 (MST) Received: from il02exb02.corp.mot.com (il02exb02.corp.mot.com [10.0.100.67]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h7LGpLtI025619 for ; Thu, 21 Aug 2003 11:51:21 -0500 Received: by il02exb02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 21 Aug 2003 11:51:20 -0500 Message-ID: <4D87884B6A6D4E438A8592BCC9C85DCA0B50AE05@il02exm06.corp.mot.com> From: Silverton Aron-C1710C To: "'rserpool@ietf.org'" Cc: "'Maureen.Stillman@nokia.com'" Subject: RE: [Rserpool] Comments on the comparison document Date: Thu, 21 Aug 2003 11:51:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain 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: , Hi Maureen, I think that we should also add a subsection to the DNS section on the differences between the DNS and RSERPOOL security models. I'll volunteer to do this. Other comments related to the sections I wrote are below. I do, however, agree with the rest of your nits and non-nits. John, if you'd like me to make the edits to the draft, let me know. I should have the cycles to do so. Maureen.Stillman@nokia.com wrote: > I have mostly nits which are optional. Non-nits are first. > > Non-nits: > [snip] > > 3.2.2 Technical Issues > > Most of the extended features of ASAP [6] and ENRP [7] are not met by > a device employing L4 switching techniques. > > The use of the word "extended" has potential for confusion. They > might think that ASAP and ENRP have a set of extensions that L4 > switches don't support. In fact, ASAP and ENRP don't have any > extensions defined right now. I have two suggestions: 1) delete the > word extended and 2) add to the end of the sentence (see comparison > table in section 5) OR you could list some of the requirements that > L4 switches don't meet. > I think that deleting the word and referncing the table is the way to go. I was trying to say that only a subset of the ASAP and ENRP features could be met by L4 switching. Your wording is better. > > 3.1 Introduction > > Since these technologies > are highly proprietary, it is difficult to detail these techniques > in a thorough manner. > > change to (* to help you find the word(s) to change): > > Since these technologies > are highly proprietary, it is difficult to *discuss* these > techniques in a thorough manner. > [snip] Agreed. [snip] > > I think this is it. Thanks. > > -- maureen > Aron _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Thu Aug 21 12:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14173 for ; Thu, 21 Aug 2003 12:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psfL-0000Ee-2x for rserpool-archive@odin.ietf.org; Thu, 21 Aug 2003 12:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LGq33W000900 for rserpool-archive@odin.ietf.org; Thu, 21 Aug 2003 12:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psfK-0000ED-Ae; Thu, 21 Aug 2003 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psel-0000DB-9L for rserpool@optimus.ietf.org; Thu, 21 Aug 2003 12:51:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14137 for ; Thu, 21 Aug 2003 12:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19psej-0005hk-00 for rserpool@ietf.org; Thu, 21 Aug 2003 12:51:25 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19psei-0005hh-00 for rserpool@ietf.org; Thu, 21 Aug 2003 12:51:24 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h7LGpNbh026908 for ; Thu, 21 Aug 2003 09:51:23 -0700 (MST) Received: from il02exb02.corp.mot.com (il02exb02.corp.mot.com [10.0.100.67]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h7LGpLtI025619 for ; Thu, 21 Aug 2003 11:51:21 -0500 Received: by il02exb02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 21 Aug 2003 11:51:20 -0500 Message-ID: <4D87884B6A6D4E438A8592BCC9C85DCA0B50AE05@il02exm06.corp.mot.com> From: Silverton Aron-C1710C To: "'rserpool@ietf.org'" Cc: "'Maureen.Stillman@nokia.com'" Subject: RE: [Rserpool] Comments on the comparison document Date: Thu, 21 Aug 2003 11:51:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain 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: , Hi Maureen, I think that we should also add a subsection to the DNS section on the differences between the DNS and RSERPOOL security models. I'll volunteer to do this. Other comments related to the sections I wrote are below. I do, however, agree with the rest of your nits and non-nits. John, if you'd like me to make the edits to the draft, let me know. I should have the cycles to do so. Maureen.Stillman@nokia.com wrote: > I have mostly nits which are optional. Non-nits are first. > > Non-nits: > [snip] > > 3.2.2 Technical Issues > > Most of the extended features of ASAP [6] and ENRP [7] are not met by > a device employing L4 switching techniques. > > The use of the word "extended" has potential for confusion. They > might think that ASAP and ENRP have a set of extensions that L4 > switches don't support. In fact, ASAP and ENRP don't have any > extensions defined right now. I have two suggestions: 1) delete the > word extended and 2) add to the end of the sentence (see comparison > table in section 5) OR you could list some of the requirements that > L4 switches don't meet. > I think that deleting the word and referncing the table is the way to go. I was trying to say that only a subset of the ASAP and ENRP features could be met by L4 switching. Your wording is better. > > 3.1 Introduction > > Since these technologies > are highly proprietary, it is difficult to detail these techniques > in a thorough manner. > > change to (* to help you find the word(s) to change): > > Since these technologies > are highly proprietary, it is difficult to *discuss* these > techniques in a thorough manner. > [snip] Agreed. [snip] > > I think this is it. Thanks. > > -- maureen > Aron _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Aug 21 14:20:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19073 for ; Thu, 21 Aug 2003 14:20:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pu2W-0002cm-RS; Thu, 21 Aug 2003 14:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptwf-0001NK-LP for rserpool@optimus.ietf.org; Thu, 21 Aug 2003 14:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15827 for ; Thu, 21 Aug 2003 13:30:42 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ptGn-00065r-00 for rserpool@ietf.org; Thu, 21 Aug 2003 13:30:45 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ptGm-00065n-00 for rserpool@ietf.org; Thu, 21 Aug 2003 13:30:44 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7LHUcB29684 for ; Thu, 21 Aug 2003 20:30:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Aug 2003 20:30:38 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 20:30:38 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 20:30:38 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rserpool] Comments on the comparison document Date: Thu, 21 Aug 2003 20:30:36 +0300 Message-ID: Thread-Topic: [Rserpool] Comments on the comparison document Thread-Index: AcNoBKTELzUyo+1iT+ub4FcgEEJCxwABUc9Q To: , Cc: X-OriginalArrivalTime: 21 Aug 2003 17:30:38.0390 (UTC) FILETIME=[EFD03560:01C36809] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Aron, You have the XML source, so feel free to do so. thanks, John > -----Original Message----- > From: ext Silverton Aron-C1710C [mailto:Aron.J.Silverton@motorola.com] > Sent: 21 August, 2003 19:51 > To: 'rserpool@ietf.org' > Cc: Stillman Maureen (NVO-NIC/Ithaca) > Subject: RE: [Rserpool] Comments on the comparison document >=20 >=20 > Hi Maureen, >=20 > I think that we should also add a subsection to the DNS section on the > differences between the DNS and RSERPOOL security models. =20 > I'll volunteer to > do this. Other comments related to the sections I wrote are=20 > below. I do, > however, agree with the rest of your nits and non-nits. >=20 > John, if you'd like me to make the edits to the draft, let me know. I > should have the cycles to do so. > =20 > Maureen.Stillman@nokia.com wrote: > > I have mostly nits which are optional. Non-nits are first. > >=20 > > Non-nits: > >=20 >=20 > [snip] > =20 > >=20 > > 3.2.2 Technical Issues > >=20 > > Most of the extended features of ASAP [6] and ENRP [7] are=20 > not met by > > a device employing L4 switching techniques. > >=20 > > The use of the word "extended" has potential for confusion. They > > might think that ASAP and ENRP have a set of extensions that L4 > > switches don't support. In fact, ASAP and ENRP don't have any > > extensions defined right now. I have two suggestions: 1) delete the > > word extended and 2) add to the end of the sentence (see comparison > > table in section 5) OR you could list some of the requirements that > > L4 switches don't meet. =20 > >=20 >=20 > I think that deleting the word and referncing the table is=20 > the way to go. I > was trying to say that only a subset of the ASAP and ENRP=20 > features could be > met by L4 switching. Your wording is better. >=20 > >=20 > > 3.1 Introduction > >=20 > > Since these technologies > > are highly proprietary, it is difficult to detail these=20 > techniques > > in a thorough manner. > >=20 > > change to (* to help you find the word(s) to change): > >=20 > > Since these technologies > > are highly proprietary, it is difficult to *discuss* these > > techniques in a thorough manner. > >=20 >=20 > [snip] >=20 > Agreed. >=20 > [snip] >=20 > >=20 > > I think this is it. Thanks. > >=20 > > -- maureen > >=20 >=20 > Aron >=20 > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool >=20 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Thu Aug 21 14:20:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19090 for ; Thu, 21 Aug 2003 14:20:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pu2b-0002di-IR for rserpool-archive@odin.ietf.org; Thu, 21 Aug 2003 14:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LIK870010129 for rserpool-archive@odin.ietf.org; Thu, 21 Aug 2003 14:20:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pu2W-0002cm-RS; Thu, 21 Aug 2003 14:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptwf-0001NK-LP for rserpool@optimus.ietf.org; Thu, 21 Aug 2003 14:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15827 for ; Thu, 21 Aug 2003 13:30:42 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ptGn-00065r-00 for rserpool@ietf.org; Thu, 21 Aug 2003 13:30:45 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ptGm-00065n-00 for rserpool@ietf.org; Thu, 21 Aug 2003 13:30:44 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7LHUcB29684 for ; Thu, 21 Aug 2003 20:30:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Aug 2003 20:30:38 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 20:30:38 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 21 Aug 2003 20:30:38 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rserpool] Comments on the comparison document Date: Thu, 21 Aug 2003 20:30:36 +0300 Message-ID: Thread-Topic: [Rserpool] Comments on the comparison document Thread-Index: AcNoBKTELzUyo+1iT+ub4FcgEEJCxwABUc9Q To: , Cc: X-OriginalArrivalTime: 21 Aug 2003 17:30:38.0390 (UTC) FILETIME=[EFD03560:01C36809] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Aron, You have the XML source, so feel free to do so. thanks, John > -----Original Message----- > From: ext Silverton Aron-C1710C [mailto:Aron.J.Silverton@motorola.com] > Sent: 21 August, 2003 19:51 > To: 'rserpool@ietf.org' > Cc: Stillman Maureen (NVO-NIC/Ithaca) > Subject: RE: [Rserpool] Comments on the comparison document >=20 >=20 > Hi Maureen, >=20 > I think that we should also add a subsection to the DNS section on the > differences between the DNS and RSERPOOL security models. =20 > I'll volunteer to > do this. Other comments related to the sections I wrote are=20 > below. I do, > however, agree with the rest of your nits and non-nits. >=20 > John, if you'd like me to make the edits to the draft, let me know. I > should have the cycles to do so. > =20 > Maureen.Stillman@nokia.com wrote: > > I have mostly nits which are optional. Non-nits are first. > >=20 > > Non-nits: > >=20 >=20 > [snip] > =20 > >=20 > > 3.2.2 Technical Issues > >=20 > > Most of the extended features of ASAP [6] and ENRP [7] are=20 > not met by > > a device employing L4 switching techniques. > >=20 > > The use of the word "extended" has potential for confusion. They > > might think that ASAP and ENRP have a set of extensions that L4 > > switches don't support. In fact, ASAP and ENRP don't have any > > extensions defined right now. I have two suggestions: 1) delete the > > word extended and 2) add to the end of the sentence (see comparison > > table in section 5) OR you could list some of the requirements that > > L4 switches don't meet. =20 > >=20 >=20 > I think that deleting the word and referncing the table is=20 > the way to go. I > was trying to say that only a subset of the ASAP and ENRP=20 > features could be > met by L4 switching. Your wording is better. >=20 > >=20 > > 3.1 Introduction > >=20 > > Since these technologies > > are highly proprietary, it is difficult to detail these=20 > techniques > > in a thorough manner. > >=20 > > change to (* to help you find the word(s) to change): > >=20 > > Since these technologies > > are highly proprietary, it is difficult to *discuss* these > > techniques in a thorough manner. > >=20 >=20 > [snip] >=20 > Agreed. >=20 > [snip] >=20 > >=20 > > I think this is it. Thanks. > >=20 > > -- maureen > >=20 >=20 > Aron >=20 > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool >=20 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Aug 21 16:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29765 for ; Thu, 21 Aug 2003 16:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwTR-00012T-8b; Thu, 21 Aug 2003 16:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwSr-000120-QC for rserpool@optimus.ietf.org; Thu, 21 Aug 2003 16:55:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29726 for ; Thu, 21 Aug 2003 16:55:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pwSp-0001eF-00 for rserpool@ietf.org; Thu, 21 Aug 2003 16:55:23 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19pwSo-0001eC-00 for rserpool@ietf.org; Thu, 21 Aug 2003 16:55:22 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7LKtLMZ026859; Thu, 21 Aug 2003 13:55:21 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7LKtGLR011684; Thu, 21 Aug 2003 15:55:17 -0500 Message-ID: <3F453205.DB160875@motorola.com> Date: Thu, 21 Aug 2003 15:56:37 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maureen.Stillman@nokia.com CC: rserpool@ietf.org Subject: Re: [Rserpool] Comments on the comparison document References: <57A26D272F67A743952F6B4371B8F811021CFE9A@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii 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 Hi, Maureen, Maureen.Stillman@nokia.com wrote: ... > 4.2 ENRP > > Another important aspect of ENRP is that itself is fully distributed > and replicated. This is to avoid the name service itself becoming a > single point of failure in the system. > > This wording has the potential for the reader erroneously concluding that ENRP servers have perfectly synchronized databases. Also "fully distributed" might cause confusion as it leaves out the operational scope which is technically what ENRP is limited to. > > How about this excellent wording taken directly from the ENRP internet draft abstract. Then put your last sentence at the end.: > > Within the operational > scope of Rserpool, ENRP defines the procedures and message formats of > a distributed, fault-tolerant registry service for storing, > bookkeeping, retrieving, and distributing pool operation and > membership information. This is to avoid the name service itself becoming a > single point of failure in the system. Agreed. .... > ASAP supports the "keepalive" monitoring of PEs by the name server > and session failover, in which a set of application messages are > defined as a "session" and ASAP provides best-effort transmission of > all the messages in the "session" to the same PE in the destination > pool, and failover the remaining message in the "session" to the same > alternate PE if the first PE fails. > > Failover is not provided for all classes of service. Need to fix one word as well. How about: > > and for some classes of service can provide failover *for* the remaining > message in the "session" to *an* alternate PE if the first PE fails. agreed. > > 4.2 ENRP > > ENRP itself is dynamically scalable, meaning that new ENRP servers > can be added and existing servers be removed as needed. This feature > can be used to achieve zero planned downtime upgrade of a system - an > often found requirement in many mission critical applications. > > change to (* to help you find the word(s) to change): > > ENRP itself is dynamically scalable, meaning that new ENRP servers > can be added and existing servers *can* be removed as needed. This feature > can be used to achieve zero planned downtime upgrade of a system - an > *common* requirement *for* many mission critical applications. > agreed. > I think this is it. Thanks. Thanks for the comments. Aron, please make these changes as well when you update the draft. regards, -Qiaobing > > -- maureen > > _______________________________________________ > 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 From exim@www1.ietf.org Thu Aug 21 16:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29767 for ; Thu, 21 Aug 2003 16:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwTS-00012z-1A for rserpool-archive@odin.ietf.org; Thu, 21 Aug 2003 16:56:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LKu1Sg004019 for rserpool-archive@odin.ietf.org; Thu, 21 Aug 2003 16:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwTR-00012T-8b; Thu, 21 Aug 2003 16:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwSr-000120-QC for rserpool@optimus.ietf.org; Thu, 21 Aug 2003 16:55:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29726 for ; Thu, 21 Aug 2003 16:55:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pwSp-0001eF-00 for rserpool@ietf.org; Thu, 21 Aug 2003 16:55:23 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19pwSo-0001eC-00 for rserpool@ietf.org; Thu, 21 Aug 2003 16:55:22 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7LKtLMZ026859; Thu, 21 Aug 2003 13:55:21 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7LKtGLR011684; Thu, 21 Aug 2003 15:55:17 -0500 Message-ID: <3F453205.DB160875@motorola.com> Date: Thu, 21 Aug 2003 15:56:37 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maureen.Stillman@nokia.com CC: rserpool@ietf.org Subject: Re: [Rserpool] Comments on the comparison document References: <57A26D272F67A743952F6B4371B8F811021CFE9A@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii 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 Hi, Maureen, Maureen.Stillman@nokia.com wrote: ... > 4.2 ENRP > > Another important aspect of ENRP is that itself is fully distributed > and replicated. This is to avoid the name service itself becoming a > single point of failure in the system. > > This wording has the potential for the reader erroneously concluding that ENRP servers have perfectly synchronized databases. Also "fully distributed" might cause confusion as it leaves out the operational scope which is technically what ENRP is limited to. > > How about this excellent wording taken directly from the ENRP internet draft abstract. Then put your last sentence at the end.: > > Within the operational > scope of Rserpool, ENRP defines the procedures and message formats of > a distributed, fault-tolerant registry service for storing, > bookkeeping, retrieving, and distributing pool operation and > membership information. This is to avoid the name service itself becoming a > single point of failure in the system. Agreed. .... > ASAP supports the "keepalive" monitoring of PEs by the name server > and session failover, in which a set of application messages are > defined as a "session" and ASAP provides best-effort transmission of > all the messages in the "session" to the same PE in the destination > pool, and failover the remaining message in the "session" to the same > alternate PE if the first PE fails. > > Failover is not provided for all classes of service. Need to fix one word as well. How about: > > and for some classes of service can provide failover *for* the remaining > message in the "session" to *an* alternate PE if the first PE fails. agreed. > > 4.2 ENRP > > ENRP itself is dynamically scalable, meaning that new ENRP servers > can be added and existing servers be removed as needed. This feature > can be used to achieve zero planned downtime upgrade of a system - an > often found requirement in many mission critical applications. > > change to (* to help you find the word(s) to change): > > ENRP itself is dynamically scalable, meaning that new ENRP servers > can be added and existing servers *can* be removed as needed. This feature > can be used to achieve zero planned downtime upgrade of a system - an > *common* requirement *for* many mission critical applications. > agreed. > I think this is it. Thanks. Thanks for the comments. Aron, please make these changes as well when you update the draft. regards, -Qiaobing > > -- maureen > > _______________________________________________ > 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 From exim@www1.ietf.org Tue Aug 26 15:05:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23389 for ; Tue, 26 Aug 2003 15:05:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj7T-000695-0e for rserpool-archive@odin.ietf.org; Tue, 26 Aug 2003 15:04:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJ4g7d023623 for rserpool-archive@odin.ietf.org; Tue, 26 Aug 2003 15:04:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj7O-00067j-RX; Tue, 26 Aug 2003 15:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKFm-0005on-8F for rserpool@optimus.ietf.org; Mon, 25 Aug 2003 12:31:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27133; Mon, 25 Aug 2003 12:31:31 -0400 (EDT) Message-Id: <200308251631.MAA27133@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rserpool@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Aug 2003 12:31:31 -0400 Subject: [Rserpool] I-D ACTION:draft-ietf-rserpool-threats-01.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Server Pooling Working Group of the IETF. Title : Threats Introduced by Rserpool and Requirements for Security in response to Threats Author(s) : M. Stillman et al. Filename : draft-ietf-rserpool-threats-01.txt Pages : 15 Date : 2003-8-25 Rserpool is an architecture and protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This Internet draft describes security threats to the Rserpool architecture and presents requirements for security to thwart these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rserpool-threats-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rserpool-threats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rserpool-threats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rserpool-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rserpool-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124337.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Aug 26 15:06:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23673 for ; Tue, 26 Aug 2003 15:06:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj8V-0006KJ-Pr; Tue, 26 Aug 2003 15:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rPrI-0003Vn-U9 for rserpool@optimus.ietf.org; Mon, 25 Aug 2003 18:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20799 for ; Mon, 25 Aug 2003 18:30:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rPrF-0000Qm-00 for rserpool@ietf.org; Mon, 25 Aug 2003 18:30:41 -0400 Received: from sjmail.ciena.com ([12.7.169.25] helo=w2ksjexg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19rPrF-0000Qj-00 for rserpool@ietf.org; Mon, 25 Aug 2003 18:30:41 -0400 Received: by w2ksjexg01.oni.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 15:30:33 -0700 Message-ID: <829F074A10F98943A218DC363D09C92AAE5F78@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'rserpool@ietf.org'" Date: Mon, 25 Aug 2003 15:30:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rserpool] New WG Last Call on the Threats Assessment 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: , Hi Folks, Maureen and I would like to start WG Last Call on the new version of the threats assessment (http://ietf.org/internet-drafts/draft-ietf-rserpool-threats-01.txt) that has now been posted on the server. This would address comments on the architecture draft that a security section is needed - the security section would then reference the threats assessment for detailed discussion of security considerations. Last Call will start today and and end on Monday, September 8th (I know it's over Labor Day weekend, but it's not a long document). Cheers, L. Ong _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From exim@www1.ietf.org Tue Aug 26 15:06:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23675 for ; Tue, 26 Aug 2003 15:06:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj8W-0006LZ-BE for rserpool-archive@odin.ietf.org; Tue, 26 Aug 2003 15:05:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJ5lhU024330 for rserpool-archive@odin.ietf.org; Tue, 26 Aug 2003 15:05:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj8V-0006KJ-Pr; Tue, 26 Aug 2003 15:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rPrI-0003Vn-U9 for rserpool@optimus.ietf.org; Mon, 25 Aug 2003 18:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20799 for ; Mon, 25 Aug 2003 18:30:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rPrF-0000Qm-00 for rserpool@ietf.org; Mon, 25 Aug 2003 18:30:41 -0400 Received: from sjmail.ciena.com ([12.7.169.25] helo=w2ksjexg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19rPrF-0000Qj-00 for rserpool@ietf.org; Mon, 25 Aug 2003 18:30:41 -0400 Received: by w2ksjexg01.oni.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 15:30:33 -0700 Message-ID: <829F074A10F98943A218DC363D09C92AAE5F78@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'rserpool@ietf.org'" Date: Mon, 25 Aug 2003 15:30:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rserpool] New WG Last Call on the Threats Assessment 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: , Hi Folks, Maureen and I would like to start WG Last Call on the new version of the threats assessment (http://ietf.org/internet-drafts/draft-ietf-rserpool-threats-01.txt) that has now been posted on the server. This would address comments on the architecture draft that a security section is needed - the security section would then reference the threats assessment for detailed discussion of security considerations. Last Call will start today and and end on Monday, September 8th (I know it's over Labor Day weekend, but it's not a long document). Cheers, L. Ong _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Aug 26 15:57:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23388 for ; Tue, 26 Aug 2003 15:05:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj7O-00067j-RX; Tue, 26 Aug 2003 15:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKFm-0005on-8F for rserpool@optimus.ietf.org; Mon, 25 Aug 2003 12:31:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27133; Mon, 25 Aug 2003 12:31:31 -0400 (EDT) Message-Id: <200308251631.MAA27133@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rserpool@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Aug 2003 12:31:31 -0400 Subject: [Rserpool] I-D ACTION:draft-ietf-rserpool-threats-01.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Server Pooling Working Group of the IETF. Title : Threats Introduced by Rserpool and Requirements for Security in response to Threats Author(s) : M. Stillman et al. Filename : draft-ietf-rserpool-threats-01.txt Pages : 15 Date : 2003-8-25 Rserpool is an architecture and protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This Internet draft describes security threats to the Rserpool architecture and presents requirements for security to thwart these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rserpool-threats-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rserpool-threats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rserpool-threats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rserpool-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rserpool-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124337.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool