From mailman-bounces@ietf.org Sun Aug 1 08:09:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16103 for ; Sun, 1 Aug 2004 08:09:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCf1-0000aQ-Sn for rserpool-archive@lists.ietf.org; Sun, 01 Aug 2004 05:29:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rserpool-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:08:14 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rserpool-archive@lists.ietf.org: List Password // URL ---- -------- rserpool@ietf.org RVOD https://www1.ietf.org/mailman/options/rserpool/rserpool-archive%40lists.ietf.org From rserpool-bounces@ietf.org Mon Aug 2 20:04:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16366 for ; Mon, 2 Aug 2004 20:04:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrmfM-0001yd-Ni; Mon, 02 Aug 2004 19:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrmRw-0003RP-Sb for rserpool@megatron.ietf.org; Mon, 02 Aug 2004 19:42:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15098 for ; Mon, 2 Aug 2004 19:42:36 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrmUt-00077p-Fk for rserpool@ietf.org; Mon, 02 Aug 2004 19:45:40 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i72NcHQO028878 for ; Mon, 2 Aug 2004 16:38:18 -0700 (MST) Received: from il02exm11.corp.mot.com (il02exm11.corp.mot.com [10.0.111.22]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i72NYtdW015351 for ; Mon, 2 Aug 2004 18:34:56 -0500 Received: by il02exm11 with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Aug 2004 18:42:31 -0500 Message-ID: <6F8DFFA2C996D711945800065BFC9E4A0DBF9EB4@il02exm11> From: Johnson Walter-CWJ002 To: "'rserpool@ietf.org'" Date: Mon, 2 Aug 2004 18:42:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Rserpool] Inconsistencies of ASAP and ENRP drafts X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org There are many inconsistencies between the two drafts that seemed to surface when the protocols were separated into there own drafts. Will these be merged back together? Or does work need to be done to clean up the separation. I would lobby to combine both into a single consistent document but wanted to see what the group was thinking. Here are a few of the several problems I have seen. 1) The same action is described differently between documents. For instance, Registration is described in both the ENRP and ASAP document differently. The question here should be whether Registration should even be mentioned in ENRP draft since it is a ASAP message. 2) Definitions are inconsistent. For instance, Home ENRP server is defined as follows in the two drafts. This is a noticeable difference in definitions with using "SHOULD only have one" and "MUST only have one". [ASAP] Home ENRP server: The ENRP server to which a Pool Element currently uses. A PU or PE normally chooses the ENRP server on their local host as the home ENRP server (if one exists). A PU or PE should only have one home ENRP server at any given time. Having a "home" ENRP server helps provide a mechanism to minimize the number of associations a given PE will have. [ENRP] Home ENRP server: The ENRP server to which a PE or PU currently belongs. A PE MUST only have one home ENRP server at any given time and both the PE and its home ENRP server MUST keep track of this master/slave relationship between them. A PU SHOULD select one of the available ENRP servers as its home ENRP server, but the ENRP server does not need to know, nor does it need to keep track of this relationship. _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Wed Aug 4 03:26:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15844 for ; Wed, 4 Aug 2004 03:26:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsG8c-0006Be-O1; Wed, 04 Aug 2004 03:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsG8V-00066U-5S for rserpool@megatron.ietf.org; Wed, 04 Aug 2004 03:24:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15689 for ; Wed, 4 Aug 2004 03:24:29 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsGBX-0002mm-Eq for rserpool@ietf.org; Wed, 04 Aug 2004 03:27:51 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i747OAtk000382; Wed, 4 Aug 2004 00:24:10 -0700 (MST) Received: from motorola.com ([163.14.20.103]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i747GVUe017034; Wed, 4 Aug 2004 02:16:32 -0500 Message-ID: <41108F68.9060207@motorola.com> Date: Wed, 04 Aug 2004 00:25:28 -0700 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Dreibholz Subject: Re: [Rserpool] ENRP Port Number References: <200407261031.47581.dreibh@exp-math.uni-essen.de> In-Reply-To: <200407261031.47581.dreibh@exp-math.uni-essen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate6.mot.com id i747OAtk000382 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thomas, Yes, you are correct, we need to clarify these issues with IANA. regards, -Qiaobing Thomas Dreibholz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Dear all, >=20 > is there a reserved port number for ENRP, especially ENRP via UDP? The=20 > reserved port number for ASAP is 3863, for ASAP TLS via UDP (this does = not=20 > make any sense, TLS does not work with UDP!) it is 3864. What about usi= ng=20 > 3864 for ENRP via UDP? >=20 >=20 > Best regards > - --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dipl.-Inform. Thomas Dreibholz >=20 > University of Duisburg-Essen Room ES210 > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > - ---------------------------------------------------------------------= -- > E-Mail: dreibh@exp-math.uni-essen.de > Homepage: http://www.exp-math.uni-essen.de/~dreibh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFBBMFy32BbsHYPLWURAq+eAJ0RDI0Hdc3/4LfhLt7ELdYeCjCUkACffXNS > SxxfzHr5c3M10wmImZ7CDYM=3D > =3Drm1f > -----END PGP SIGNATURE----- >=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-bounces@ietf.org Wed Aug 4 03:44:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16464 for ; Wed, 4 Aug 2004 03:44:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsGQG-0007lM-Ay; Wed, 04 Aug 2004 03:42:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsGPo-0007eu-5A for rserpool@megatron.ietf.org; Wed, 04 Aug 2004 03:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16378 for ; Wed, 4 Aug 2004 03:42:21 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsGSq-0002zu-Py for rserpool@ietf.org; Wed, 04 Aug 2004 03:45:44 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i747h2RC012375; Wed, 4 Aug 2004 00:43:02 -0700 (MST) Received: from motorola.com ([163.14.20.103]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i747YUUe006841; Wed, 4 Aug 2004 02:34:30 -0500 Message-ID: <4110939F.5050201@motorola.com> Date: Wed, 04 Aug 2004 00:43:27 -0700 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Dreibholz Subject: Re: [Rserpool] ENRP Peer Name Update References: <200407271122.06681.dreibh@exp-math.uni-essen.de> In-Reply-To: <200407271122.06681.dreibh@exp-math.uni-essen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id i747h2RC012375 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thomas, Thomas Dreibholz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Dear all, >=20 > ENRP PEER_NAME_UPDATE contains the full Pool Element Parameter even in = case of=20 > deregistrations. ASAP DEREGISTRATION only uses a PE Identifier Paramete= r to=20 > identify the PE. This is sufficient to identify and remove the PE. So, = what=20 > about defining to also use a PE Identifier parameter for deregistration= s in=20 > the PEER_NAME_UPDATE? That is, in case of registrations PEER_NAME_UPDAT= E=20 > would contain a Pool Element Parameter and in case of deregistrations a= PE=20 > Identifier Parameter. The advantage of using a single format for PEER_NAME_UPDATE is to make th= e implementation=20 easier and to keep the number of messages small (remember we also have PE= update in addition=20 to add and remove). In the case of removal (I wouldn't call it de-reg, se= e below), we may=20 allow the sender to only fill in the PE-id and leave other fields blank a= nd allow the=20 receiver to ignore the other fields. But I do not see the value of using = different formats. >=20 > May be, it would be a good idea to split up PEER_NAME_UPDATE into a=20 > PEER_NAME_REGISTRATION and PEER_NAME_DEREGISTRATION. Then, it would be= =20 > consistent to ASAP's message types. I think there is never an intention to match ASAP types here. Calling Pee= r-name-reg and=20 peer-name-dereg is IMO misleading since the sending ENRP server is not do= ing a reg or de-reg=20 with the receiving server. they are really updating each other. regards, -Qiaobing >=20 >=20 > Best regards > - --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dipl.-Inform. Thomas Dreibholz >=20 > University of Duisburg-Essen Room ES210 > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > - ---------------------------------------------------------------------= -- > E-Mail: dreibh@exp-math.uni-essen.de > Homepage: http://www.exp-math.uni-essen.de/~dreibh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFBBh6932BbsHYPLWURAg7UAKC4k1L1fC4kyMB/1cxkLeksxePL+QCePM78 > uDbdR+0wptVWbmoGNv5v60c=3D > =3Dg//Z > -----END PGP SIGNATURE----- >=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-bounces@ietf.org Wed Aug 4 04:13:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17514 for ; Wed, 4 Aug 2004 04:13:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsGs4-000207-FV; Wed, 04 Aug 2004 04:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsGpO-0001jw-1R for rserpool@megatron.ietf.org; Wed, 04 Aug 2004 04:08:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17388 for ; Wed, 4 Aug 2004 04:08:48 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsGsT-0003TS-62 for rserpool@ietf.org; Wed, 04 Aug 2004 04:12:11 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i7484LBP024085 for ; Wed, 4 Aug 2004 01:04:21 -0700 (MST) Received: from motorola.com ([163.14.20.103]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7480wUe008758; Wed, 4 Aug 2004 03:00:59 -0500 Message-ID: <411099D3.7030109@motorola.com> Date: Wed, 04 Aug 2004 01:09:55 -0700 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johnson Walter-CWJ002 Subject: Re: [Rserpool] Inconsistencies of ASAP and ENRP drafts References: <6F8DFFA2C996D711945800065BFC9E4A0DBF9EB4@il02exm11> In-Reply-To: <6F8DFFA2C996D711945800065BFC9E4A0DBF9EB4@il02exm11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: 7bit Walter, Thanks for the comments. Johnson Walter-CWJ002 wrote: > There are many inconsistencies between the two drafts that seemed to surface when the protocols were separated into there own drafts. Will these be merged back together? Or does work need to be done to clean up the separation. I would lobby to combine both into a single consistent document but wanted to see what the group was thinking. The reason to have separate documents is to better manage the complexity. It was a working group decision made a long time ago and I think it worked well. I personally do not have a problem with multiple documents (DDDS is published in 4 separate RFCs, for example). As a coauthor I will do my best to fix any inconsistencies whenever they are noted and I believe other coauthors will do the same. And the text quality will only improve with more comments like yours. > > Here are a few of the several problems I have seen. > > 1) The same action is described differently between documents. For instance, Registration is described in both the ENRP and ASAP document differently. The question here should be whether Registration should even be mentioned in ENRP draft since it is a ASAP message. As you can guess, one place is normative and the other is informative. We will make this more clear. But I disagree that only one document should be allowed to have the description since doing that will obviously impair the readability of the document without the description. > > 2) Definitions are inconsistent. For instance, Home ENRP server is defined as follows in the two drafts. This is a noticeable difference in definitions with using "SHOULD only have one" and "MUST only have one". > > [ASAP] > Home ENRP server: The ENRP server to which a Pool Element currently > uses. A PU or PE normally chooses the ENRP server on their local > host as the home ENRP server (if one exists). A PU or PE should > only have one home ENRP server at any given time. Having a "home" > ENRP server helps provide a mechanism to minimize the number of > associations a given PE will have. > > [ENRP] > Home ENRP server: The ENRP server to which a PE or PU currently > belongs. A PE MUST only have one home ENRP server at any given > time and both the PE and its home ENRP server MUST keep track of > this master/slave relationship between them. A PU SHOULD select > one of the available ENRP servers as its home ENRP server, but the > ENRP server does not need to know, nor does it need to keep track > of this relationship. Good catch. Will have this fixed. regards, -Qiaobing > > _______________________________________________ > 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 rserpool-bounces@ietf.org Thu Aug 5 16:49:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13694 for ; Thu, 5 Aug 2004 16:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsp9A-0004rG-Ra; Thu, 05 Aug 2004 16:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsp7f-0004YJ-0v for rserpool@megatron.ietf.org; Thu, 05 Aug 2004 16:45:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13470 for ; Thu, 5 Aug 2004 16:45:56 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BspBA-0004Z2-UZ for rserpool@ietf.org; Thu, 05 Aug 2004 16:49:40 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i75Kkmxl003415 for ; Thu, 5 Aug 2004 13:46:48 -0700 (MST) Received: from il02exm12.corp.mot.com (il02exm12.corp.mot.com [10.0.111.23]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i75KjrRi010053 for ; Thu, 5 Aug 2004 15:45:53 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Aug 2004 15:45:52 -0500 Message-ID: From: Silverton Aron-C1710C To: "'Rserpool list'" Date: Thu, 5 Aug 2004 15:45:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Rserpool] ASAP document structure X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Hello, I see ASAP as having the following logical functions: PU <-> Pool Registrar communications PU <-> PE communications PE <-> PE communications (cookies and business cards) If I were king, I might split out the PE <-> PE portion into a new document and leave the other two portions together in the ASAP draft. At the very least, I suggest reorganizing the document so that whatever is included, is grouped into the three categories listed above. Regards, Aron Aron J. Silverton Principal 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-bounces@ietf.org Thu Aug 12 14:58:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23013 for ; Thu, 12 Aug 2004 14:58:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKkd-0003yj-Pu; Thu, 12 Aug 2004 14:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKfK-0008B8-Jz for rserpool@megatron.ietf.org; Thu, 12 Aug 2004 14:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22425; Thu, 12 Aug 2004 14:51:04 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKkK-0001ju-2J; Thu, 12 Aug 2004 14:56:17 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CIp2B23640; Thu, 12 Aug 2004 21:51:02 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 21:50:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7CIotBL032002; Thu, 12 Aug 2004 21:50:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 0002Tmaf; Thu, 12 Aug 2004 21:50:52 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CIoon11947; Thu, 12 Aug 2004 21:50:50 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 13:49:50 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2004 13:49:50 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81102496E50@daebe007.americas.nokia.com> Thread-Topic: Rserpool minutes from IETF #60 Thread-Index: AcSAnSU/epERjHRKSXauFwFNPCkmDw== To: X-OriginalArrivalTime: 12 Aug 2004 18:49:50.0781 (UTC) FILETIME=[25EE46D0:01C4809D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: proceedings@ietf.org Subject: [Rserpool] Rserpool minutes from IETF #60 X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Comments anyone? -- maureen Rserpool report from IETF #60 Approximately 30 people attended the WG meeting held on 8/5/2004. A policies draft was presented (draft-tuexen-rserpool-policies-00.txt). = This draft presents new policies for reliable server pooling. The = proposal was to take the pool policies currently included in the ASAP = draft and separate them into a separate policies draft. This allows the = stable base ASAP protocol specification to be separated from the pool = policies which are subject to further investigation and more substantial = changes. Consensus was reached in the meeting to make this change. We = will take the proposal to the mailing list. The SASP Server Application State protocol was presented = (draft-bivens-sasp-00.txt). SASP is focused on a specific application = which is load balancing among a group of servers. The architecture of = SASP was presented and it was compared to Rserpool. This protocol has = some overlap with Rserpool and many of the same goals and requirements. = The meeting participants reached consensus to work with the author of = SASP on a collaborative effort as SASP brings an important application's = set of requirements, namely load balancers, into the protocol = development process. An offline discussion followed the agreement. =20 A brief update was presented on the following documents with minor = changes since the last draft: These documents are currently in AD review. Rserpool comparison draft-ietf-rserpool-comp-07.txt Rserpool Architecture=20 draft-ietf-rserpool-arch-07.txt Security Threats draft-ietf-rserpool-threats-03.txt These documents are under construction: Rserpool services draft-ietf-rserpool-service-01.txt ASAP draft-ietf-rserpool-asap-09.txt ENRP draft-ietf-rserpool-enrp-09.txt Rserpool applicability=20 draft-ietf-rserpool-applic-02.txt The group was encouraged to read the latest drafts and send comments to = the mailing list. The ASAP and ENRP protocols are fairly stable at this time. Rserpool = implementations are being discussed on the mailing list since IETF #59 = and changes have been suggested to the protocols as a result. These = changes were made to the latest drafts. A presentation on the current = status of the implementations gave details of how to get open source and = tools such as Ethereal which has been updated to dissect ENRP and ASAP = packets. We feel that the WG is moving ahead and making good progress. =20 -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Mon Aug 23 08:56:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05978 for ; Mon, 23 Aug 2004 08:56:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzDvg-0008H4-Ic; Mon, 23 Aug 2004 08:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzDfP-00062a-EH for rserpool@megatron.ietf.org; Mon, 23 Aug 2004 08:11:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02708 for ; Mon, 23 Aug 2004 08:11:09 -0400 (EDT) Received: from ms.exp-math.uni-essen.de ([132.252.150.1] helo=pilz.exp-math.uni-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzDfc-0003Z2-8V for rserpool@ietf.org; Mon, 23 Aug 2004 08:11:29 -0400 Received: from kappes.exp-math.uni-essen.de (kappes.exp-math.uni-essen.de [132.252.150.151]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id i7NCB6gG031610 for ; Mon, 23 Aug 2004 14:11:06 +0200 From: Thomas Dreibholz To: Date: Mon, 23 Aug 2004 14:11:02 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408231411.06156.dreibh@exp-math.uni-essen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: [Rserpool] ENRP Name Server Takeover Problem X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, when a NS takes over the ownership of PEs owned by a failed NS, it sends an= =20 ENDPOINT_KEEP_ALIVE message to each of the PEs which change their ownership= =2E=20 As defined in KA2.4 of section 3.4 of the ASAP draft, the PE should adapt t= he=20 sender of an ENDPOINT_KEEP_ALIVE message as its new NS. But, how does the new NS know the PEs' ASAP endpoint, that is especially th= e=20 SCTP port number the PE is listening on for ASAP ENDPOINT_KEEP_ALIVES? The= =20 old (failed) NS has this information, because the PE established an=20 association to it. But the new NS does not know. Therefore, a specification= =20 of the PE's ASAP endpoint must be added to the Pool Element Parameter. Simp= ly=20 adding a field for the SCTP port number should already be sufficient. The=20 addresses to be used can be assumed to be the same as specified in the User= =20 Transport parameter. Best regards =2D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dipl.-Inform. Thomas Dreibholz University of Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D ----------------------------------------------------------------------- E-Mail: dreibh@exp-math.uni-essen.de Homepage: http://www.exp-math.uni-essen.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBKd7Z32BbsHYPLWURAtToAKCrnGWS5cBOmqv/PNXPvkxKxVhWEACeNaM2 rLi5vLWX8fIYJ9py+2iO1MA=3D =3DT53y =2D----END PGP SIGNATURE----- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Thu Aug 26 02:25:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10603 for ; Thu, 26 Aug 2004 02:25:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0DX1-0004kt-Nx; Thu, 26 Aug 2004 02:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0DR1-00023l-Tv for rserpool@megatron.ietf.org; Thu, 26 Aug 2004 02:08:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04101 for ; Thu, 26 Aug 2004 02:08:25 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0DRY-00057Y-T6 for rserpool@ietf.org; Thu, 26 Aug 2004 02:09:21 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i7Q63g94012195; Wed, 25 Aug 2004 23:03:42 -0700 (MST) Received: from motorola.com ([163.14.20.44]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7Q603Q1009661; Thu, 26 Aug 2004 01:00:05 -0500 Message-ID: <412D7E9A.9080208@motorola.com> Date: Thu, 26 Aug 2004 14:09:30 +0800 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Dreibholz Subject: Re: [Rserpool] ENRP Name Server Takeover Problem References: <200408231411.06156.dreibh@exp-math.uni-essen.de> In-Reply-To: <200408231411.06156.dreibh@exp-math.uni-essen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate2.mot.com id i7Q63g94012195 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thomas, This makes a lot of sense to me. My recommendation is to add a "ASAP Tran= sport Param" field=20 to the PE parameter that is a full SCTP transport TLV. Simply adding a SC= TP port number=20 field may be too restrictive since some PEs may want to use a separate NI= C for its ASAP=20 communications. regards, -Qiaobing Thomas Dreibholz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Dear all, >=20 > when a NS takes over the ownership of PEs owned by a failed NS, it send= s an=20 > ENDPOINT_KEEP_ALIVE message to each of the PEs which change their owner= ship.=20 > As defined in KA2.4 of section 3.4 of the ASAP draft, the PE should ada= pt the=20 > sender of an ENDPOINT_KEEP_ALIVE message as its new NS. >=20 > But, how does the new NS know the PEs' ASAP endpoint, that is especiall= y the=20 > SCTP port number the PE is listening on for ASAP ENDPOINT_KEEP_ALIVES? = The=20 > old (failed) NS has this information, because the PE established an=20 > association to it. But the new NS does not know. Therefore, a specifica= tion=20 > of the PE's ASAP endpoint must be added to the Pool Element Parameter. = Simply=20 > adding a field for the SCTP port number should already be sufficient. T= he=20 > addresses to be used can be assumed to be the same as specified in the = User=20 > Transport parameter. >=20 >=20 > Best regards > - --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dipl.-Inform. Thomas Dreibholz >=20 > University of Essen, Room ES210 > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > - ---------------------------------------------------------------------= -- > E-Mail: dreibh@exp-math.uni-essen.de > Homepage: http://www.exp-math.uni-essen.de/~dreibh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFBKd7Z32BbsHYPLWURAtToAKCrnGWS5cBOmqv/PNXPvkxKxVhWEACeNaM2 > rLi5vLWX8fIYJ9py+2iO1MA=3D > =3DT53y > -----END PGP SIGNATURE----- >=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-bounces@ietf.org Thu Aug 26 10:44:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06540 for ; Thu, 26 Aug 2004 10:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LC3-0003RX-D0; Thu, 26 Aug 2004 10:25:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L4R-0007hs-5f for rserpool@megatron.ietf.org; Thu, 26 Aug 2004 10:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18680 for ; Thu, 26 Aug 2004 06:12:58 -0400 (EDT) Received: from ms.exp-math.uni-essen.de ([132.252.150.1] helo=pilz.exp-math.uni-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0HGX-0000cb-JG for rserpool@ietf.org; Thu, 26 Aug 2004 06:13:58 -0400 Received: from kappes.exp-math.uni-essen.de (kappes.exp-math.uni-essen.de [132.252.150.151]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id i7Q9ROgG030348; Thu, 26 Aug 2004 11:27:24 +0200 From: Thomas Dreibholz To: rserpool@ietf.org Subject: Re: [Rserpool] ENRP Name Server Takeover Problem Date: Thu, 26 Aug 2004 11:27:20 +0200 User-Agent: KMail/1.6.2 References: <200408231411.06156.dreibh@exp-math.uni-essen.de> <412D7E9A.9080208@motorola.com> In-Reply-To: <412D7E9A.9080208@motorola.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408261127.24232.dreibh@exp-math.uni-essen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: Qiaobing Xie X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 26. August 2004 08:09 schrieb Qiaobing Xie: > Thomas, > > This makes a lot of sense to me. My recommendation is to add a "ASAP > Transport Param" field to the PE parameter that is a full SCTP transport > TLV. Simply adding a SCTP port number field may be too restrictive since > some PEs may want to use a separate NIC for its ASAP communications. Yes, this is the best solution. The "ASAP Transport Parameter" should be an optional SCTP Transport Paramet= er,=20 to be appended to the end of the "Pool Element Parameter" in the common=20 parameters draft. For ASAP (Registration), there should be no such paramete= r=20 (the home NS has to find out the peer addresses anyway, therefore the NS=20 itself can fill this information into the namespace). For ENRP=20 (PeerNameUpdate and PeerNameTableResponse), this parameter has to be=20 mandatory. Best regards =2D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dipl.-Inform. Thomas Dreibholz University of Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D ----------------------------------------------------------------------- E-Mail: dreibh@exp-math.uni-essen.de Homepage: http://www.exp-math.uni-essen.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBLaz732BbsHYPLWURAqK7AKC1iqoRcUjSXNw2oPRycxYncmAHfQCfYPLs KlC7D5bAuEU+QlcCMecUg2s=3D =3D5DJB =2D----END PGP SIGNATURE----- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Thu Aug 26 10:47:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06802 for ; Thu, 26 Aug 2004 10:47:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LC6-0003Tv-12; Thu, 26 Aug 2004 10:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L4a-0007hs-8b for rserpool@megatron.ietf.org; Thu, 26 Aug 2004 10:17:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18675 for ; Thu, 26 Aug 2004 06:12:57 -0400 (EDT) Received: from ms.exp-math.uni-essen.de ([132.252.150.1] helo=pilz.exp-math.uni-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0HGV-0000cb-C8 for rserpool@ietf.org; Thu, 26 Aug 2004 06:13:57 -0400 Received: from kappes.exp-math.uni-essen.de (kappes.exp-math.uni-essen.de [132.252.150.151]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id i7Q9gwgG024136; Thu, 26 Aug 2004 11:42:58 +0200 From: Thomas Dreibholz To: rserpool@ietf.org Subject: Re: [Rserpool] ENRP Peer Name Update Date: Thu, 26 Aug 2004 11:42:56 +0200 User-Agent: KMail/1.6.2 References: <200407271122.06681.dreibh@exp-math.uni-essen.de> <4110939F.5050201@motorola.com> In-Reply-To: <4110939F.5050201@motorola.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408261142.57469.dreibh@exp-math.uni-essen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: Qiaobing Xie X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 4. August 2004 09:43 schrieb Qiaobing Xie: > Thomas, > > Thomas Dreibholz wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Dear all, > > > > ENRP PEER_NAME_UPDATE contains the full Pool Element Parameter even in > > case of deregistrations. ASAP DEREGISTRATION only uses a PE Identifier > > Parameter to identify the PE. This is sufficient to identify and remove > > the PE. So, what about defining to also use a PE Identifier parameter f= or > > deregistrations in the PEER_NAME_UPDATE? That is, in case of > > registrations PEER_NAME_UPDATE would contain a Pool Element Parameter a= nd > > in case of deregistrations a PE Identifier Parameter. > > The advantage of using a single format for PEER_NAME_UPDATE is to make the > implementation easier and to keep the number of messages small (remember = we > also have PE update in addition to add and remove). In the case of removal > (I wouldn't call it de-reg, see below), we may allow the sender to only > fill in the PE-id and leave other fields blank and allow the receiver to > ignore the other fields. But I do not see the value of using different > formats. When a NS applies a deregistration from the namespace, it first calls a=20 function to delete the NS from the namespace. Then, the information about t= he=20 PE is gone (memory is deallocated). This implies, that the PE information h= as=20 to be duplicated (including malloc()/new calls -> error handling becomes=20 necessary) before the deregistration to be able to fill out the=20 PeerNameUpdate message. It is not recommended to send PeerNameUpdates befor= e=20 deregistering the element itself from the namespace, since a deregistration= =20 may fail (permissions, etc.). Using only a PE ID, it is simply necessary to= =20 remember a 32-bit integer value (fixed-size, no malloc()/new necessary). When parsing a Pool Element Parameter having fields set blank and things li= ke=20 pool policy and user transport missing, all procedures requiring a complete= =20 Pool Element Parameter have to check if the parsed parameter is valid. If w= e=20 do *not* allow to leave fields blank and skip user transport/policy=20 parameter, a pool element parameter scanner procedure can directly verify i= f=20 it is complete. No special cases are necessary. And finally, a Pool Element= =20 Parameter having all fields except the ID set blank, is nothing more than a= =20 degenerated Pool Element Identifier Parameter. Conclusion: Using Pool Element Parameter for ADD_PE and Pool Element=20 Identifier Parameter for DEL_PE decreases the complexity of the=20 implementation and is IMHO useful. Best regards =2D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dipl.-Inform. Thomas Dreibholz University of Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D ----------------------------------------------------------------------- E-Mail: dreibh@exp-math.uni-essen.de Homepage: http://www.exp-math.uni-essen.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBLbCg32BbsHYPLWURAsGhAJ9fiMHPIJkhby16G6eETpTAD6oL/ACg2E1b //mzvhxT1ha19O9AfYzpXXQ=3D =3Du2dq =2D----END PGP SIGNATURE----- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Thu Aug 26 10:48:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06904 for ; Thu, 26 Aug 2004 10:48:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LC6-0003U8-8q; Thu, 26 Aug 2004 10:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L4a-0007hs-S9 for rserpool@megatron.ietf.org; Thu, 26 Aug 2004 10:17:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18786 for ; Thu, 26 Aug 2004 06:15:34 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0HIz-0000fe-HP for rserpool@ietf.org; Thu, 26 Aug 2004 06:16:34 -0400 Received: from [194.95.73.179] (unknown [194.95.73.179]) by ilsa.franken.de (Postfix) with ESMTP id A5B87245DB; Thu, 26 Aug 2004 12:14:33 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <412D7E9A.9080208@motorola.com> References: <200408231411.06156.dreibh@exp-math.uni-essen.de> <412D7E9A.9080208@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Rserpool] ENRP Name Server Takeover Problem Date: Thu, 26 Aug 2004 12:14:20 +0200 To: Qiaobing Xie X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Dreibholz , rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Qiaobing, I discussed this with Thomas yesterday on the phone and we came to the same conclusion. Since this ASAP Transport Param is not required for registration it should be an optional parameter, I think. So I'm suggesting to modify the PE parameter to 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 0x8 | Length=3Dvariable = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home ENRP Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Life | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : User Transport param : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Member Selection Policy param : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ASAP Transport param : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and the ASAP transport parameter - MUST be an SCTP transport parameter - is optional. Do you agree on that? If yes, I can update the common parameter doc. Another point came up on the discussion with Thomas. It is regarding the sequence of TLV fields in parameters/messages. Is the sequence required to be the one shown in the documents or are other sequences also acceptable? I would argue that they should be sent like they are shown, but the receiver should accepts them also in other orderings. But we have to state that somewhere ... after agreeing on a way to handle that. Best regards Michael On Aug 26, 2004, at 8:09 AM, Qiaobing Xie wrote: > Thomas, > > This makes a lot of sense to me. My recommendation is to add a "ASAP =20= > Transport Param" field to the PE parameter that is a full SCTP =20 > transport TLV. Simply adding a SCTP port number field may be too =20 > restrictive since some PEs may want to use a separate NIC for its ASAP = =20 > communications. > > regards, > -Qiaobing > > Thomas Dreibholz wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Dear all, >> when a NS takes over the ownership of PEs owned by a failed NS, it =20= >> sends an ENDPOINT_KEEP_ALIVE message to each of the PEs which change =20= >> their ownership. As defined in KA2.4 of section 3.4 of the ASAP =20 >> draft, the PE should adapt the sender of an ENDPOINT_KEEP_ALIVE =20 >> message as its new NS. >> But, how does the new NS know the PEs' ASAP endpoint, that is =20 >> especially the SCTP port number the PE is listening on for ASAP =20 >> ENDPOINT_KEEP_ALIVES? The old (failed) NS has this information, =20 >> because the PE established an association to it. But the new NS does =20= >> not know. Therefore, a specification of the PE's ASAP endpoint must =20= >> be added to the Pool Element Parameter. Simply adding a field for the = =20 >> SCTP port number should already be sufficient. The addresses to be =20= >> used can be assumed to be the same as specified in the User Transport = =20 >> parameter. >> Best regards >> - -- =20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >> =3D >> Dipl.-Inform. Thomas Dreibholz >> University of Essen, Room ES210 >> Inst. for Experimental Mathematics Ellernstra=DFe 29 >> Computer Networking Technology Group D-45326 = Essen/Germany >> - =20 >> = ----------------------------------------------------------------------=20= >> - >> E-Mail: dreibh@exp-math.uni-essen.de >> Homepage: http://www.exp-math.uni-essen.de/~dreibh >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >> =3D >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.2.4 (GNU/Linux) >> iD8DBQFBKd7Z32BbsHYPLWURAtToAKCrnGWS5cBOmqv/PNXPvkxKxVhWEACeNaM2 >> rLi5vLWX8fIYJ9py+2iO1MA=3D >> =3DT53y >> -----END PGP SIGNATURE----- >> _______________________________________________ >> rserpool mailing list >> rserpool@ietf.org >> https://www1.ietf.org/mailman/listinfo/rserpool > > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Fri Aug 27 11:57:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11582 for ; Fri, 27 Aug 2004 11:57:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ixP-0000rR-Qt; Fri, 27 Aug 2004 11:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ioI-0007aV-7e for rserpool@megatron.ietf.org; Fri, 27 Aug 2004 11:38:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10411 for ; Fri, 27 Aug 2004 11:38:35 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ipD-0004TA-Ot for rserpool@ietf.org; Fri, 27 Aug 2004 11:39:51 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7RFdKGU003755; Fri, 27 Aug 2004 08:39:20 -0700 (MST) Received: from motorola.com ([163.14.20.74]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7RFUGbK030757; Fri, 27 Aug 2004 10:30:19 -0500 Message-ID: <412F55C1.4040103@motorola.com> Date: Fri, 27 Aug 2004 23:39:45 +0800 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Dreibholz Subject: Re: [Rserpool] ENRP Peer Name Update References: <200407271122.06681.dreibh@exp-math.uni-essen.de> <4110939F.5050201@motorola.com> <200408261142.57469.dreibh@exp-math.uni-essen.de> In-Reply-To: <200408261142.57469.dreibh@exp-math.uni-essen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id i7RFdKGU003755 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thomas, Please see below... Thomas Dreibholz wrote: >>>ENRP PEER_NAME_UPDATE contains the full Pool Element Parameter even in >>>case of deregistrations. ASAP DEREGISTRATION only uses a PE Identifier >>>Parameter to identify the PE. This is sufficient to identify and remov= e >>>the PE. So, what about defining to also use a PE Identifier parameter = for >>>deregistrations in the PEER_NAME_UPDATE? That is, in case of >>>registrations PEER_NAME_UPDATE would contain a Pool Element Parameter = and >>>in case of deregistrations a PE Identifier Parameter. >> >>The advantage of using a single format for PEER_NAME_UPDATE is to make = the >>implementation easier and to keep the number of messages small (remembe= r we >>also have PE update in addition to add and remove). In the case of remo= val >>(I wouldn't call it de-reg, see below), we may allow the sender to only >>fill in the PE-id and leave other fields blank and allow the receiver t= o >>ignore the other fields. But I do not see the value of using different >>formats. >=20 > When a NS applies a deregistration from the namespace, it first calls a= =20 > function to delete the NS from the namespace. Then, the information abo= ut the=20 > PE is gone (memory is deallocated). This implies, that the PE informati= on has=20 > to be duplicated (including malloc()/new calls -> error handling become= s=20 > necessary) before the deregistration to be able to fill out the=20 > PeerNameUpdate message. It is not recommended to send PeerNameUpdates b= efore=20 > deregistering the element itself from the namespace, since a deregistra= tion=20 > may fail (permissions, etc.). Using only a PE ID, it is simply necessar= y to=20 > remember a 32-bit integer value (fixed-size, no malloc()/new necessary). This argument is rather implementation specific. There are another ways o= f implementing it=20 without facing such difficulties. in fact, I didn't have this difficulty = in my impl (Randy=20 can testify :-). >=20 > When parsing a Pool Element Parameter having fields set blank and thing= s like=20 > pool policy and user transport missing, all procedures requiring a comp= lete=20 > Pool Element Parameter have to check if the parsed parameter is valid. = If we=20 > do *not* allow to leave fields blank and skip user transport/policy=20 > parameter, a pool element parameter scanner procedure can directly veri= fy if=20 > it is complete. No special cases are necessary. And finally, a Pool Ele= ment=20 > Parameter having all fields except the ID set blank, is nothing more th= an a=20 > degenerated Pool Element Identifier Parameter. Again, this is not a strong argument IMO. E.g., my parser allows me to ge= t a particular TLV=20 while ignoring others, so I did not have this problem. So, when I find th= e action is a=20 deletion, I would call the parser and ask it to return me the PE Id TLV, = and after that I=20 may choose not to check any other TLV at all. > Conclusion: Using Pool Element Parameter for ADD_PE and Pool Element=20 > Identifier Parameter for DEL_PE decreases the complexity of the=20 > implementation and is IMHO useful. To be frank, I am not convinced that there is an implementation advantage= for your proposed=20 change but I do not have a strong position here and can go with either wa= y. What do others=20 think? regards, -Qiaobing >=20 >=20 > Best regards > - --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dipl.-Inform. Thomas Dreibholz >=20 > University of Essen, Room ES210 > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > - ---------------------------------------------------------------------= -- > E-Mail: dreibh@exp-math.uni-essen.de > Homepage: http://www.exp-math.uni-essen.de/~dreibh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFBLbCg32BbsHYPLWURAsGhAJ9fiMHPIJkhby16G6eETpTAD6oL/ACg2E1b > //mzvhxT1ha19O9AfYzpXXQ=3D > =3Du2dq > -----END PGP SIGNATURE----- >=20 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Fri Aug 27 12:01:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11850 for ; Fri, 27 Aug 2004 12:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0j6r-0003Cx-Vu; Fri, 27 Aug 2004 11:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ixn-000146-1W for rserpool@megatron.ietf.org; Fri, 27 Aug 2004 11:48:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11048 for ; Fri, 27 Aug 2004 11:48:24 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0iyl-0004hZ-Az for rserpool@ietf.org; Fri, 27 Aug 2004 11:49:40 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i7RFm9ck023750; Fri, 27 Aug 2004 08:48:10 -0700 (MST) Received: from motorola.com ([163.14.20.74]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7RFe5bK014224; Fri, 27 Aug 2004 10:40:08 -0500 Message-ID: <412F580D.2010609@motorola.com> Date: Fri, 27 Aug 2004 23:49:33 +0800 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Rserpool] ENRP Name Server Takeover Problem References: <200408231411.06156.dreibh@exp-math.uni-essen.de> <412D7E9A.9080208@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate4.mot.com id i7RFm9ck023750 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: Thomas Dreibholz , rserpool@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Michael, Michael Tuexen wrote: > Qiaobing, >=20 > I discussed this with Thomas yesterday on the phone and we came to > the same conclusion. Since this ASAP Transport Param is not required > for registration it should be an optional parameter, I think. >=20 > So I'm suggesting to modify the PE parameter to >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D 0x8 | Length=3Dvariable = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PE Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home ENRP Server Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Registration Life | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : User Transport param : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : Member Selection Policy param : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ASAP Transport param : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > and the ASAP transport parameter > - MUST be an SCTP transport parameter > - is optional. >=20 > Do you agree on that? If yes, I can update the common parameter doc. Yes, I agree. But the ASAP Trans Param probably need to have its own type= /length with its=20 data an SCTP trans param. Otherwise you won't be able to receive it if th= e order is allowed=20 to be flexible (as you suggest below). >=20 > Another point came up on the discussion with Thomas. It is regarding > the sequence of TLV fields in parameters/messages. Is the sequence > required to be the one shown in the documents or are other > sequences also acceptable? > I would argue that they should be sent like they are shown, but the > receiver should accepts them also in other orderings. But we have > to state that somewhere ... after agreeing on a way to handle that. This makes sense to me. regards, -Qiaobing >=20 > Best regards > Michael >=20 >=20 > On Aug 26, 2004, at 8:09 AM, Qiaobing Xie wrote: >=20 >> Thomas, >> >> This makes a lot of sense to me. My recommendation is to add a "ASAP =20 >> Transport Param" field to the PE parameter that is a full SCTP =20 >> transport TLV. Simply adding a SCTP port number field may be too =20 >> restrictive since some PEs may want to use a separate NIC for its=20 >> ASAP communications. >> >> regards, >> -Qiaobing >> >> Thomas Dreibholz wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> Dear all, >>> when a NS takes over the ownership of PEs owned by a failed NS, it =20 >>> sends an ENDPOINT_KEEP_ALIVE message to each of the PEs which change = =20 >>> their ownership. As defined in KA2.4 of section 3.4 of the ASAP =20 >>> draft, the PE should adapt the sender of an ENDPOINT_KEEP_ALIVE =20 >>> message as its new NS. >>> But, how does the new NS know the PEs' ASAP endpoint, that is =20 >>> especially the SCTP port number the PE is listening on for ASAP =20 >>> ENDPOINT_KEEP_ALIVES? The old (failed) NS has this information, =20 >>> because the PE established an association to it. But the new NS does = =20 >>> not know. Therefore, a specification of the PE's ASAP endpoint must =20 >>> be added to the Pool Element Parameter. Simply adding a field for=20 >>> the SCTP port number should already be sufficient. The addresses to=20 >>> be used can be assumed to be the same as specified in the User=20 >>> Transport parameter. >>> Best regards >>> - -- =20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D >>> Dipl.-Inform. Thomas Dreibholz >>> University of Essen, Room ES210 >>> Inst. for Experimental Mathematics Ellernstra=DFe 29 >>> Computer Networking Technology Group D-45326 Essen/German= y >>> - =20 >>> ---------------------------------------------------------------------= - - >>> E-Mail: dreibh@exp-math.uni-essen.de >>> Homepage: http://www.exp-math.uni-essen.de/~dreibh >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.2.4 (GNU/Linux) >>> iD8DBQFBKd7Z32BbsHYPLWURAtToAKCrnGWS5cBOmqv/PNXPvkxKxVhWEACeNaM2 >>> rLi5vLWX8fIYJ9py+2iO1MA=3D >>> =3DT53y >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 >> >=20 >=20 _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Fri Aug 27 12:31:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14157 for ; Fri, 27 Aug 2004 12:31:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jUT-0002O7-Hs; Fri, 27 Aug 2004 12:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jQJ-0000Rs-6F for rserpool@megatron.ietf.org; Fri, 27 Aug 2004 12:17:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13002 for ; Fri, 27 Aug 2004 12:17:52 -0400 (EDT) Received: from ns.exp-math.uni-essen.de ([132.252.150.1] helo=pilz.exp-math.uni-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0jRQ-0005I0-Ti for rserpool@ietf.org; Fri, 27 Aug 2004 12:19:08 -0400 Received: from kappes.exp-math.uni-essen.de (kappes.exp-math.uni-essen.de [132.252.150.151]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id i7RGHmgG015866; Fri, 27 Aug 2004 18:17:48 +0200 From: Thomas Dreibholz To: rserpool@ietf.org Subject: Re: [Rserpool] ENRP Name Server Takeover Problem Date: Fri, 27 Aug 2004 18:17:43 +0200 User-Agent: KMail/1.6.2 References: <200408231411.06156.dreibh@exp-math.uni-essen.de> <412D7E9A.9080208@motorola.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408271817.48462.dreibh@exp-math.uni-essen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: Michael Tuexen , Qiaobing Xie X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 26. August 2004 12:14 schrieb Michael Tuexen: > Another point came up on the discussion with Thomas. It is regarding > the sequence of TLV fields in parameters/messages. Is the sequence > required to be the one shown in the documents or are other > sequences also acceptable? PeerOwnershipChange for example requires a sequence (PE Identifier Paramete= r=20 belong to the pool specified by the latest Pool Handle Parameter). Therefor= e, it is consistent to make the order mandatory. Best regards =2D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dipl.-Inform. Thomas Dreibholz University of Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D ----------------------------------------------------------------------- E-Mail: dreibh@exp-math.uni-essen.de Homepage: http://www.exp-math.uni-essen.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBL16r32BbsHYPLWURAsD+AKClX9AJEQG61hxOkWd8oXPYwfr/iwCdF/RV mzh+ggZmZGHYIjDa0f0yEzw=3D =3DOPsT =2D----END PGP SIGNATURE----- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Fri Aug 27 12:40:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14751 for ; Fri, 27 Aug 2004 12:40:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jgR-0005mY-8j; Fri, 27 Aug 2004 12:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jeC-0004zM-RR for rserpool@megatron.ietf.org; Fri, 27 Aug 2004 12:32:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14257 for ; Fri, 27 Aug 2004 12:32:13 -0400 (EDT) Received: from ns.exp-math.uni-essen.de ([132.252.150.1] helo=pilz.exp-math.uni-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0jfN-0005bf-Id for rserpool@ietf.org; Fri, 27 Aug 2004 12:33:30 -0400 Received: from kappes.exp-math.uni-essen.de (kappes.exp-math.uni-essen.de [132.252.150.151]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id i7RGWEgG034326; Fri, 27 Aug 2004 18:32:14 +0200 From: Thomas Dreibholz To: rserpool@ietf.org Subject: Re: [Rserpool] ENRP Peer Name Update Date: Fri, 27 Aug 2004 18:32:13 +0200 User-Agent: KMail/1.6.2 References: <200407271122.06681.dreibh@exp-math.uni-essen.de> <200408261142.57469.dreibh@exp-math.uni-essen.de> <412F55C1.4040103@motorola.com> In-Reply-To: <412F55C1.4040103@motorola.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408271832.14566.dreibh@exp-math.uni-essen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: Qiaobing Xie X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Reliable Server Pooling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rserpool-bounces@ietf.org Errors-To: rserpool-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Freitag, 27. August 2004 17:39 schrieb Qiaobing Xie: > > When a NS applies a deregistration from the namespace, it first calls a > > function to delete the NS from the namespace. Then, the information abo= ut > > the PE is gone (memory is deallocated). This implies, that the PE > > information has to be duplicated (including malloc()/new calls -> error > > handling becomes necessary) before the deregistration to be able to fill > > out the > > PeerNameUpdate message. It is not recommended to send PeerNameUpdates > > before deregistering the element itself from the namespace, since a > > deregistration may fail (permissions, etc.). Using only a PE ID, it is > > simply necessary to remember a 32-bit integer value (fixed-size, no > > malloc()/new necessary). > > This argument is rather implementation specific. There are another ways of > implementing it without facing such difficulties. in fact, I didn't have > this difficulty in my impl (Randy can testify :-). Yes, it is possible. But IMHO, it requires more effort than simply using a = PE=20 Identifier parameter. In this case, you would simply scan for the PE=20 Identifier Parameter instead of scanning for the Pool Element Parameter and= =20 looking there for the PE ID itself. > > When parsing a Pool Element Parameter having fields set blank and things > > like pool policy and user transport missing, all procedures requiring a > > complete Pool Element Parameter have to check if the parsed parameter is > > valid. If we do *not* allow to leave fields blank and skip user > > transport/policy parameter, a pool element parameter scanner procedure > > can directly verify if it is complete. No special cases are necessary. > > And finally, a Pool Element Parameter having all fields except the ID s= et > > blank, is nothing more than a degenerated Pool Element Identifier > > Parameter. > > Again, this is not a strong argument IMO. E.g., my parser allows me to get > a particular TLV while ignoring others, so I did not have this problem. S= o, > when I find the action is a deletion, I would call the parser and ask it = to > return me the PE Id TLV, and after that I may choose not to check any oth= er > TLV at all. But a parser should check if the complete message is valid and not malforme= d.=20 =46or example a Pool Element Paramter is defined in the common parameters d= raft=20 to be containing e.g. a user transport parameter and a policy parameter. Wh= en=20 e.g. there is no user transport parameter or it contains no addresses etc.,= =20 the message is IMHO malformed and should not be processed. When only a PE identifier has to be specified, a Pool Element Identifier=20 Parameter should be used. This parameter encapsulates the information=20 necessary and requires nothing more, therefore it also more consistent. Why= =20 using a full Pool Element Parameter when a PE Identifier Parameter is=20 sufficient? Best regards =2D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dipl.-Inform. Thomas Dreibholz University of Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D ----------------------------------------------------------------------- E-Mail: dreibh@exp-math.uni-essen.de Homepage: http://www.exp-math.uni-essen.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBL2IN32BbsHYPLWURAnLlAKC2KL47KDztXwegr1S/1Z3uq4E9awCeKmyW M6KyyzyGQaJoFOiJnE2QyDs=3D =3DIRq6 =2D----END PGP SIGNATURE----- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool