From rserpool-bounces@ietf.org Fri Mar 03 13:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFElg-0003BW-Am; Fri, 03 Mar 2006 13:12:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFElf-0003BR-9l for rserpool@ietf.org; Fri, 03 Mar 2006 13:12:43 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFEld-0007M3-Pm for rserpool@ietf.org; Fri, 03 Mar 2006 13:12:43 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k23ICdt6019835 for ; Fri, 3 Mar 2006 20:12:40 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 20:12:36 +0200 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:12:04 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Mar 2006 12:12:03 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rserpool agenda items for Dallas Thread-Index: AcY+7fkpqV4YmoC0QIafEUiETYjLlw== From: To: X-OriginalArrivalTime: 03 Mar 2006 18:12:04.0126 (UTC) FILETIME=[F9882BE0:01C63EED] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Rserpool] Rserpool agenda items for Dallas 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: , Content-Type: multipart/mixed; boundary="===============0521780552==" Errors-To: rserpool-bounces@ietf.org This is a multi-part message in MIME format. --===============0521780552== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63EED.F95D21CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63EED.F95D21CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IETF will be held in Dallas in 3 weeks and I wanted suggestions for agenda items. -- Maureen Maureen Stillman Nokia Enterprise Solutions Acting Director SMC Systems Architecture ------_=_NextPart_001_01C63EED.F95D21CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rserpool agenda items for Dallas

The IETF will be held in Dallas in 3 = weeks and I wanted suggestions for agenda items.

-- Maureen
Maureen Stillman
Nokia Enterprise Solutions
Acting Director SMC Systems = Architecture

------_=_NextPart_001_01C63EED.F95D21CE-- --===============0521780552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool --===============0521780552==-- From rserpool-bounces@ietf.org Tue Mar 07 13:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgxn-0004nm-5Z; Tue, 07 Mar 2006 13:31:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgxl-0004nh-36 for rserpool@ietf.org; Tue, 07 Mar 2006 13:31:13 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgxj-0005o6-Ko for rserpool@ietf.org; Tue, 07 Mar 2006 13:31:13 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27IVA7Q013867 for ; Tue, 7 Mar 2006 20:31:10 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 20:31:08 +0200 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:30:56 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Mar 2006 12:30:56 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please send comments on the draft agenda for Dallas Thread-Index: AcZCFUXZMalpVYdfSh2AknVfmuZ9cg== From: To: X-OriginalArrivalTime: 07 Mar 2006 18:30:56.0961 (UTC) FILETIME=[46681310:01C64215] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Rserpool] Please send comments on the draft agenda for Dallas 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: , Content-Type: multipart/mixed; boundary="===============1321943275==" Errors-To: rserpool-bounces@ietf.org This is a multi-part message in MIME format. --===============1321943275== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64215.46312988" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64215.46312988 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the draft agenda for our Thursday slot. Let me know soon if you have corrections or comments. I need to upload it tomorrow. Rserpool Agenda for IETF #65 =20 Opening remarks: co-chairs Lyndon Ong and Maureen Stillman Discussion of IPFix and Rserpool draft-bclaise-ipfix-reliability-01.txt Peter Lei and Benoit Claise DTLS/SCTP draft-tuexen-dtls-for-sctp-00.txt Michael Tuexen Closing remarks: co-chairs -- Maureen Maureen Stillman Nokia Enterprise Solutions Acting Director SMC Systems Architecture ------_=_NextPart_001_01C64215.46312988 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please send comments on the draft agenda for Dallas

Here is the draft agenda for our = Thursday slot.  Let me know soon if you have corrections or = comments.  I need to upload it tomorrow.

Rserpool Agenda for IETF = #65
 
Opening remarks: = co-chairs
Lyndon Ong and Maureen = Stillman

Discussion of IPFix and = Rserpool
draft-bclaise-ipfix-reliability-01.txt
Peter Lei and Benoit = Claise

DTLS/SCTP
draft-tuexen-dtls-for-sctp-00.txt
Michael Tuexen

Closing remarks: co-chairs


-- Maureen
Maureen Stillman
Nokia Enterprise Solutions
Acting Director SMC Systems = Architecture

------_=_NextPart_001_01C64215.46312988-- --===============1321943275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool --===============1321943275==-- From rserpool-bounces@ietf.org Mon Mar 20 10:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMT9-0007kz-Dt; Mon, 20 Mar 2006 10:38:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMT7-0007ku-Hc for rserpool@ietf.org; Mon, 20 Mar 2006 10:38:53 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMT6-0006up-BU for rserpool@ietf.org; Mon, 20 Mar 2006 10:38:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Mar 2006 10:38:51 -0500 Message-ID: <0901D1988E815341A0103206A834DA07C463F2@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: drafting during meeting period thursday morning Thread-Index: AcZMNGNXdaPGvm+PQtCNhhk5ZK8V8A== From: "Ong, Lyndon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Rserpool] drafting during meeting period thursday morning 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: , Content-Type: multipart/mixed; boundary="===============1804904089==" Errors-To: rserpool-bounces@ietf.org This is a multi-part message in MIME format. --===============1804904089== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64C34.63CB49D9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64C34.63CB49D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 As there appears to be some extra time after we complete our agenda for Thursday morning's WG session, I'd like to see if we can use that time to take another pass over the architecture draft and see if we can clean it up a bit further. Let's get together in the meeting room following the wrap up of the WG meeting. =20 Cheers, =20 Lyndon ------_=_NextPart_001_01C64C34.63CB49D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
As = there appears to=20 be some extra time after we complete our agenda for
Thursday morning's=20 WG session, I'd like to see if we can use that time = to
take = another pass=20 over the architecture draft and see if we can clean it = up
a bit = further. =20 Let's get together in the meeting room following the wrap = up
of the = WG=20 meeting.
 
Cheers,
 
Lyndon
------_=_NextPart_001_01C64C34.63CB49D9-- --===============1804904089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool --===============1804904089==-- From rserpool-bounces@ietf.org Wed Mar 29 20:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlcF-0000Pz-Nr; Wed, 29 Mar 2006 20:06:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlcE-0000PX-Bu for rserpool@ietf.org; Wed, 29 Mar 2006 20:06:22 -0500 Received: from adsl-070-155-160-098.sip.cae.bellsouth.net ([70.155.160.98] helo=lakerest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOlcD-0004Ds-S3 for rserpool@ietf.org; Wed, 29 Mar 2006 20:06:22 -0500 Received: from [IPv6:::1] (localhost [IPv6:::1]) by lakerest.net (8.13.6/8.13.4) with ESMTP id k2U16Lmb003637 for ; Wed, 29 Mar 2006 20:06:21 -0500 (EST) (envelope-from randall@lakerest.net) Message-ID: <442B2F0D.104@lakerest.net> Date: Wed, 29 Mar 2006 20:06:21 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'rserpool@ietf.org'" References: <442B26DD.9030207@lakerest.net> In-Reply-To: <442B26DD.9030207@lakerest.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Rserpool] Re: Updated architecture 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: , Errors-To: rserpool-bounces@ietf.org Ok, Let me try sending this again since I first had to unsubscribe my old domain name.. and re-subscribe my new one (even though they still lead to the same place :-D) .... Randall Stewart wrote: > Hi all: > > I just submitted draft-11 of the architecture.. the main > changes are the addtions of this in the intro section: > 999999999999999999999999999999999999999999999999999999999999999999 > 1.1. The Problem Space > > Fault tolerance is a difficult and challenging problem space. Most > of the solutions in this space involve an extensive effort on the > part of an application programmer and oftentimes the result is a > proprietary solution. There are a number of issues concerning > developers of fault tolerant applications including: > > 1. How to find a server that provides the service desired? > > 2. If the server that is providing me the service dies, how do I > find another one? > > 3. What type of redundancy model will I use, 2N or N+K? > > 4. How does a server providing a service share state with potential > peer servers in case of a failure? > > 5. How does a server assure that when it fails (or dies), the > clients will access the "best" server that is able to handle the > failure (or if you will take over for the departed server)? > > 6. From an operations and maintenance standpoint how do we add or > subtract capacity dynamically without reconfiguring our network? > > A fault tolerant application needs to deal with these issues and many > more. Often an application is developed and then later, it is > realized that the application needs to be fault tolerant. The > response to this new requirement mandates either a hack or re-write > of the application. > > So how can application writers solves these issues and makes it easy > for the application designer to add fault tolerance without hacking > or rewriting the application code? We use layering to solve this > problem. A session layer is inserted below the application layer to > provide a framework for fault tolerance. This removes some of the > complexity from the application writers hands thus freeing the > application writter to concentrate on the application. Note that not > all of the issues listed above can be solved by the session layer > framework alone, in particular the application will still need to > deal with state sharing, however the session layer framework will > also provide small tools when it can to help make even this job > easier for the application writer. > > A second important point is that this layering no longer requires > each application to custom programmed for fault tolerance. By > > > > Tuexen, et al. Expires September 30, 2006 [Page 3] > > Internet-Draft RSerPool Architecture March 2006 > > > running an application on top of the session layer fault tolerant > services, there is no longer the need to design and implement fault > tolerance one application at a time. There are several benefits to > this approach: > > 1. Time and cost savings for the developers of the application > > 2. Experts in the area have developed the session layer fault > tolerance mechanism > > 3. An application can be developed without a fault tolerant > requirement and later in the life cycle, if this requirement > emerges, it can be met with Rserpool without a costly redesign. > > 4. Rserpool provides a set of APIs and hooks for the application > developer to implement fault tolerance > > 5. Rserpool provides a simple building block to the application for > rudimentary state sharing. > > The above summary is the overall goal of Rserpool. We strive to > remove the details and complexity of fault tolerance from the > application writer and, when the session layer cannot solve the issue > (such as state sharing), give the application writer some small > building blocks on which they can solve the problem with minimal > effort. > > In this document you will be introduced to a set of concepts for > solving a number of these problems. Often times the document will > refer to a named element (e.g Pool User) in the architecture sending > or receiving a message. When seeing this, please note that this is > NOT the application sending or receiving the query, but the session > layer below. Envision if you will the application opening up a > special form of socket. This socket will allow reading and writing > of data, but underneath will have special properties that allow it to > send and receive additional messages when the upper layer user > requests some service such as sending a message or binding a name. > Note again, the goal of RSERPOOL is NOT to solve all of the problems, > but to instead solve a subset of the fault tolerant issues and at the > same time provide a toolkit of standard utilities that will help an > application solve the remaining items in an easier way. > > 1.2. Overview > 9999999999999999999999999999999999999999999999999999999999999999999999 > > > This, as discussed at the wg meeting, gives a better understanding (I > think) to the reader as to what we are up to. > > I also fixed a few typos and such.. but most of the rest of > the document stayed the same... I did take out > one extraneous paragraph.. that did not belong... but all in > all the above is the main changes.. > > Comments would be welcome before I send this off to Fred... > > R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-bounces@ietf.org Thu Mar 30 13:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2L9-0007uO-BL; Thu, 30 Mar 2006 13:57:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Ky-0007s1-TM for rserpool@ietf.org; Thu, 30 Mar 2006 13:57:40 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2Ku-0003Bl-Ha for rserpool@ietf.org; Thu, 30 Mar 2006 13:57:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rserpool] Re: Updated architecture Date: Thu, 30 Mar 2006 13:57:06 -0500 Message-ID: <0901D1988E815341A0103206A834DA07C46BD6@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rserpool] Re: Updated architecture Thread-Index: AcZTlkmemF2VHVAvS++cte4F27xVlQAkxmvw From: "Ong, Lyndon" To: "Randall Stewart" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: 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: , Errors-To: rserpool-bounces@ietf.org Hi Randy, This looks great, hopefully getting the basic idea out front will help people to understand the goal of the work better. I haven't seen version 11 out on the server yet, could you also send the file out on the mailing list? Thanks, Lyndon=20 -----Original Message----- From: Randall Stewart [mailto:randall@lakerest.net]=20 Sent: Wednesday, March 29, 2006 5:06 PM To: 'rserpool@ietf.org' Subject: [Rserpool] Re: Updated architecture Ok, Let me try sending this again since I first had to unsubscribe my old domain name.. and re-subscribe my new one (even though they still lead to the same place :-D) .... Randall Stewart wrote: > Hi all: >=20 > I just submitted draft-11 of the architecture.. the main changes are=20 > the addtions of this in the intro section: > 999999999999999999999999999999999999999999999999999999999999999999 > 1.1. The Problem Space >=20 > Fault tolerance is a difficult and challenging problem space. Most > of the solutions in this space involve an extensive effort on the > part of an application programmer and oftentimes the result is a > proprietary solution. There are a number of issues concerning > developers of fault tolerant applications including: >=20 > 1. How to find a server that provides the service desired? >=20 > 2. If the server that is providing me the service dies, how do I > find another one? >=20 > 3. What type of redundancy model will I use, 2N or N+K? >=20 > 4. How does a server providing a service share state with potential > peer servers in case of a failure? >=20 > 5. How does a server assure that when it fails (or dies), the > clients will access the "best" server that is able to handle the > failure (or if you will take over for the departed server)? >=20 > 6. From an operations and maintenance standpoint how do we add or > subtract capacity dynamically without reconfiguring our network? >=20 > A fault tolerant application needs to deal with these issues and many > more. Often an application is developed and then later, it is > realized that the application needs to be fault tolerant. The > response to this new requirement mandates either a hack or re-write > of the application. >=20 > So how can application writers solves these issues and makes it easy > for the application designer to add fault tolerance without hacking > or rewriting the application code? We use layering to solve this > problem. A session layer is inserted below the application layer to > provide a framework for fault tolerance. This removes some of the > complexity from the application writers hands thus freeing the > application writter to concentrate on the application. Note that not > all of the issues listed above can be solved by the session layer > framework alone, in particular the application will still need to > deal with state sharing, however the session layer framework will > also provide small tools when it can to help make even this job > easier for the application writer. >=20 > A second important point is that this layering no longer requires > each application to custom programmed for fault tolerance. By >=20 >=20 >=20 > Tuexen, et al. Expires September 30, 2006 [Page 3] > =0C > Internet-Draft RSerPool Architecture March 2006 >=20 >=20 > running an application on top of the session layer fault tolerant > services, there is no longer the need to design and implement fault > tolerance one application at a time. There are several benefits to > this approach: >=20 > 1. Time and cost savings for the developers of the application >=20 > 2. Experts in the area have developed the session layer fault > tolerance mechanism >=20 > 3. An application can be developed without a fault tolerant > requirement and later in the life cycle, if this requirement > emerges, it can be met with Rserpool without a costly redesign. >=20 > 4. Rserpool provides a set of APIs and hooks for the application > developer to implement fault tolerance >=20 > 5. Rserpool provides a simple building block to the application for > rudimentary state sharing. >=20 > The above summary is the overall goal of Rserpool. We strive to > remove the details and complexity of fault tolerance from the > application writer and, when the session layer cannot solve the issue > (such as state sharing), give the application writer some small > building blocks on which they can solve the problem with minimal > effort. >=20 > In this document you will be introduced to a set of concepts for > solving a number of these problems. Often times the document will > refer to a named element (e.g Pool User) in the architecture sending > or receiving a message. When seeing this, please note that this is > NOT the application sending or receiving the query, but the session > layer below. Envision if you will the application opening up a > special form of socket. This socket will allow reading and writing > of data, but underneath will have special properties that allow it to > send and receive additional messages when the upper layer user > requests some service such as sending a message or binding a name. > Note again, the goal of RSERPOOL is NOT to solve all of the problems, > but to instead solve a subset of the fault tolerant issues and at the > same time provide a toolkit of standard utilities that will help an > application solve the remaining items in an easier way. >=20 > 1.2. Overview > 9999999999999999999999999999999999999999999999999999999999999999999999 >=20 >=20 > This, as discussed at the wg meeting, gives a better understanding (I > think) to the reader as to what we are up to. >=20 > I also fixed a few typos and such.. but most of the rest of the=20 > document stayed the same... I did take out one extraneous paragraph..=20 > that did not belong... but all in all the above is the main changes.. >=20 > Comments would be welcome before I send this off to Fred... >=20 > R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ 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 Mar 30 18:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6u3-0001rl-QR; Thu, 30 Mar 2006 18:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6tu-0001nY-Bf; Thu, 30 Mar 2006 18:50:02 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP6tt-0006pM-SV; Thu, 30 Mar 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2UNo1vP002384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Mar 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FP6tt-00005y-Fg; Thu, 30 Mar 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 30 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rserpool@ietf.org Subject: [Rserpool] I-D ACTION:draft-ietf-rserpool-arch-11.txt 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: , Errors-To: rserpool-bounces@ietf.org --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 : Architecture for Reliable Server Pooling Author(s) : M. Tuexen, et al. Filename : draft-ietf-rserpool-arch-11.txt Pages : 27 Date : 2006-3-30 This document describes an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rserpool-arch-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-arch-11.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-arch-11.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: <2006-3-30152835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rserpool-arch-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rserpool-arch-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-30152835.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool --NextPart-- From rserpool-bounces@ietf.org Fri Mar 31 06:15:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPHbK-0004TZ-Rd; Fri, 31 Mar 2006 06:15:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPHbI-0004TU-NC for rserpool@ietf.org; Fri, 31 Mar 2006 06:15:32 -0500 Received: from mailout2.uni-essen.de ([132.252.184.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPHbH-0003sV-Cu for rserpool@ietf.org; Fri, 31 Mar 2006 06:15:32 -0500 Received: from kappes.iem.uni-due.de ([132.252.150.151]:60685 helo=kappes.exp-math.uni-essen.de) by mailout2.uni-essen.de with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1FPHbD-005G6W-b4 for rserpool@ietf.org; Fri, 31 Mar 2006 13:15:30 +0200 From: Thomas Dreibholz To: rserpool@ietf.org Date: Fri, 31 Mar 2006 13:15:21 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Message-Id: <200603311315.26030.dreibh@iem.uni-due.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Rserpool] Question about draft-ietf-rserpool-applic-02.txt 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: , Content-Type: multipart/mixed; boundary="===============1066281122==" Errors-To: rserpool-bounces@ietf.org --===============1066281122== Content-Type: multipart/signed; boundary="nextPart1925321.QkKEKtoeOS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1925321.QkKEKtoeOS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! Is the draft draft-ietf-rserpool-applic-02.txt going to be updated? The lat= est=20 version 02 is dated July 18, 2004 and therefore has expired about 15 months= =20 ago. I am interested in creating an updated version (e.g. updating old=20 terminology like "namespace", etc.). Is this okay for you? 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 --nextPart1925321.QkKEKtoeOS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBELQ9N32BbsHYPLWURAqKTAJsH9YP6K4m+zN4Smxv49Vx62N1S+gCggCX+ bYOXRd4Hdo18p0oB61CM+GA= =zG0Y -----END PGP SIGNATURE----- --nextPart1925321.QkKEKtoeOS-- --===============1066281122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool --===============1066281122==--