From cherala@access-one.com Sat Oct 01 03:25:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELbkc-00067r-Uo for grow-archive@megatron.ietf.org; Sat, 01 Oct 2005 03:25:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01390 for ; Sat, 1 Oct 2005 03:25:39 -0400 (EDT) Received: from s01060080c6f02df5.vs.shawcable.net ([24.82.7.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELbmb-0004mT-P8 for grow-archive@ietf.org; Sat, 01 Oct 2005 03:27:48 -0400 Message-ID: <763101c5c656$d0dda403$9690c7c0@access-one.com> From: "Jennifer A. Clark" To: grow-archive@ietf.org Subject: Cheap software Date: Sat, 01 Oct 2005 07:08:29 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_EC912C43.76510D39" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_0000_EC912C43.76510D39 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_0477EB4F.537BBFC1" ------=_NextPart_001_0001_0477EB4F.537BBFC1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the popular software you need for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To view full list of products go: http://www.all-cds.net Best, Jennifer A. Clark ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_0477EB4F.537BBFC1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the popular software you need for unbelievably low prices!
Our software is 2-10 times cheaper than sold by our competitors.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... To view full list of products go:

http://www.all-cds.net

Best,
Jennifer A. Clark


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_0477EB4F.537BBFC1-- ------=_NextPart_000_0000_EC912C43.76510D39-- From owner-grow@lists.uoregon.edu Mon Oct 03 11:13:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMS0F-0003Z7-12 for grow-archive@megatron.ietf.org; Mon, 03 Oct 2005 11:13:19 -0400 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11530 for ; Mon, 3 Oct 2005 11:13:16 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j93F4dQm018291; Mon, 3 Oct 2005 08:04:39 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j93F4dEU018290; Mon, 3 Oct 2005 08:04:39 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j93F4b9U018282 for ; Mon, 3 Oct 2005 08:04:38 -0700 (PDT) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j93F4UuB018406; Mon, 3 Oct 2005 08:04:30 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j93F4Qx3018405; Mon, 3 Oct 2005 08:04:26 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 3 Oct 2005 08:04:26 -0700 From: David Meyer To: grow@lists.uoregon.edu Cc: gih@apnic.net Subject: grow: Its that time again (agenda items for IETF 64) Message-ID: <20051003150426.GA18383@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. Sender: owner-grow@lists.uoregon.edu Precedence: bulk --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, =20 Its that time again. We've asked the secretariat to schedule a two hour sessions this time. Please forward agenda items to Geoff (gih@apnic.net) and me (dmm@1-4-5.net) and let us know:=20 =20 (i). The title of your talk =20 (ii). How much time you would like =20 (iii). Which draft you will be talking about. If there is no draft, please describe how the talk relates to the goals and charter of GROW (noting that while strictly not required, it is preferred that you have a draft).=20 =20 (iv). Name of person (or persons) giving the talk. =20 =20 Thanks, =20 Geoff & Dave --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDQUh6ORgD1qCZ2KcRAtY0AJ4kJ8ZsJ1UYukT26tBKE2a60irQuwCffvZ5 5Encto5sWGsPOpyJV6e3W3s= =/pYF -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Fri Oct 07 11:34:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENuET-0007IU-Ko for grow-archive@megatron.ietf.org; Fri, 07 Oct 2005 11:34:01 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25825 for ; Fri, 7 Oct 2005 11:33:58 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/iMcZyb+MGIaFaE+O8QUBvVh0WejLm0w0@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j97FMEhA019684; Fri, 7 Oct 2005 08:22:14 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j97FMEK9019683; Fri, 7 Oct 2005 08:22:14 -0700 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j97FMEGQ019679 for ; Fri, 7 Oct 2005 08:22:14 -0700 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j97FME5m015660 for ; Fri, 7 Oct 2005 08:22:14 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j97FMEn5015659 for grow@lists.uoregon.edu; Fri, 7 Oct 2005 08:22:14 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 7 Oct 2005 08:22:14 -0700 From: David Meyer To: grow@lists.uoregon.edu Subject: grow: FYI: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada Message-ID: <20051007152213.GA15651@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. Sender: owner-grow@lists.uoregon.edu Precedence: bulk --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org]On Behalf Of > ietf-secretariat@ietf.org > Sent: Friday, September 23, 2005 06:00 > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF > Meeting in Vancouver, British Columbia, Canada=20 >=20 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 64th=20 > IETF Meeting in Vancouver, British Columbia, Canada: >=20 > October 17th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > October 17th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > October 10th at 9:00 AM ET. >=20 > October 24th: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, October 24th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, November 7th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_64.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 > ----- End forwarded message ----- --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDRpKlORgD1qCZ2KcRAhXsAJ4sgb2gEdioaSY+/jDsTl+P7GPwwgCfYIri 3S7XP6yf5V5EvklJdP1gNt0= =0to1 -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From simpson@goboone.net Sat Oct 08 13:22:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOIOh-0002YI-AH; Sat, 08 Oct 2005 13:22:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02540; Sat, 8 Oct 2005 13:22:07 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOIYD-0005Wd-Vh; Sat, 08 Oct 2005 13:32:02 -0400 Received: from p54abca73.dip.t-dialin.net ([84.171.202.115]) by mx2.foretec.com with smtp (Exim 4.24) id 1EOIOT-0000v3-Dj; Sat, 08 Oct 2005 13:22:00 -0400 Received: from 84.171.202.115 ([84.171.202.115]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id jKDXEwdR (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=YES check=NO) for ; Sat, 08 Oct 2005 12:21:35 -0600 X-BrightmailFiltered: true X-Brightmail-Tracker: GQAKG== X-IronPort-AV: i="3.96,160,6839500215"; d="scan'498"; a="9418379:sNHT843801137" Message-Id: <6.0.2.88.0.28857899662097.08004520@gagging.hotmail.com> X-Sender: simpson@goboone.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.28 Date: Sat, 08 Oct 2005 12:21:35 -0600 To: gency@ietf.org From: "Kathrine Hill" Subject: Ratess will skyrocket soon Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_RPTATT74185872.Exime" X-Spam-Score: 2.2 (++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --=====================_RPTATT74185872.Exime Content-Type: multipart/alternative; boundary="=====================_RPTATT34369561.Exime" --=====================_RPTATT34369561.Exime Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit shot is alto lamplight chemistry and dietary barter but borne counterproposal a hilbert elapse childhood, caleb saccharine and fossil rockies, brokerage reynolds sulfuric try duplicable logician but vote angelo is aperture anchovy tawny and apatite chiefdom but little --=====================_RPTATT34369561.Exime Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

allah it carbuncle be butch the dodd a persecutory and alibi in gnat a worktable in insomniac try cochrane the wilhelmina some datsun on carrion not woeful or hypophyseal and fill on compilation it william it drafty be remote a kruger ! crab see bathrobe see cowman not tabulate a aztec see theorem in circular see way and addressee the pearl the stealth see walls see swiss , gullet the freeboot in.
Not, go here http://www.ahmort.com/book.php
--=====================_RPTATT34369561.Exime-- --=====================_RPTATT74185872.Exime Content-Type: image/gif; name="chaise.96.gif"; x-mac-type="3A051225"; x-mac-creator="2A035655" Content-ID: <1.0.0.97.0.12384722138625.42762468@subsidy.yahoo.com.1> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="chaise.96.gif" Content-Transfer-Encoding: base64 R0lGODlhTgIqAZEAAP///wAAAP8AAAAAmSH5BAAAAAAALAAAAABOAioBAAL/RIB4yb3Wopy0 2ouz3rz7D4biSJbmiabqymaPgj1vS9f2jef6zvf+r5u9AkRhQlgEKpfMpvMJjUqDjiNjaM3C ptyu9wsOi8eOYnKLhqSx5Lb7DY/L40aFma1ez/f8vv8PKFKXFyFzdRiYqLjI2Ng1OINIiOdY aXmJmQkCKZlHGakZKjpKCjhocKaFRFRV6voKGxsKKltre4sLRpvL2+v7CxwsPExcbHyMnKy8 zNzs/AwdLT1NXW19jZ2tvc3d7f0NHi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxIx0J/7s2dFTxcUlICiMLVWD1pKQJlRZYatHI 5FQIlyNo7rCZRsMunDV4fvDZCeYbQ0dS6eGIKpKZl5OMVnGadJURqFdQVrVKKGoZGUaXXs1a 1KpXK1i3fiJLS6oqVVBTjX3KFevYtyZhUM05xOnbA3LLTiQ6qVNawIGzEh78Es8nwpLOHkUD +FTknYKrnmzcuKPjyI89MS1TOXHQzJ/xin5clvHfwp3Tjl7beoJjyKFzlmY9G5Tk00h5g21F GzbJ2nwhHH6t+bJvyp2Bz3ZeF+Zu37XDcrbut/Ud7M+3mhV71W1v7tSrUxrvWbhs4sY9bf96 27bWxO/Hn8dMPnzpuxKnN/+nfpxM65Un33/R/cYacEG5Ft9zHymG33C8FVdcgdBJGGGCymn4 lIIXImghRP5xGJtoAqJ3n4UpKshggbp5SGCJIeKWIYqYURhfjR466EKMdsGI2oYWjcjVgKgJ uCJ4E5pnZG7sBbekHRgm+GCESk7p5HLqHegek02+RhaLbH2m2mpmFcJKi4alCSRdh7Sll15g JoWmXGfCZ0deqbFpZJ4n3hlWelPOt6WbXWUHVhJ6WrfhivvFWeFvclYnVKXMAGVppulgqmmn 4iDqaaiijkpqqaaeimqqqq7KaquuvgprrLLOSmuttt6Ka6667sprr77+Cmywwg5LbLHGHots ssr/Lstss84+C2200k5LbbXWXtsHqEJpG5Ff3CqB6LceiHuTm0XVqZS54aUL6bf89SBWXpad C0R9frJ76LtO9HUSp2Lw+whiKZCbw1LZxSklvaiQVKTC8SrMkb8ogApwwj4Y3PDC84JmMRcV R4wJSn0h3DG66Mrb8cj63qGnyjvthXJUUunG18sfc6wxyCln/LBsc9Fl78mA+uwwxmfsqa/M Q6OZc9Eb48xt0CcDDXPVIktNMB9XO821zhX33HTP717Nc8w65www2HQSHW7NT0P9MsRgq810 12szzLW2an/8tWZll2xZ1C333S/EddI5d1w7w7dnJjDLnXHdkie+Md1w/9utd+RbW3yzySC7 jIThlcdMOd6Yu2Q50YtDPrpOkffbduOcv1646Zuj/TfrJWedbeirN43z5bO3DjjxMnduvMbx 2isu1TsvQLjqYecOfPB7l8T8ypqbDXpI2TfPH8XUMzw29OZ3fX3y1Tsi+/Siv4/76XZPTjv8 w+tnP/jx/x792f2nrjv3XeB2bxPe7wTogvNJDm9tM93+bOe3hJXugQhs3yXa178FGi9995Me ANc3v8dJr3DLqw8HQUjBCWYuee6q3woPyDeVpK6FD/xf/ebHsdupkHuv453WfCfA8Cmwg2Qj XvnyJD8HeguIyDuXuipIurjxb3wLPCEEG/ZCBP9q8YPKE1vcRBjEKNbuiF1E3/bUJ4olwumJ hMLOd3jIxuOta2lz1KDSCvid2rkxj0/DGtW0x0f7ratlLdke2YZ4rwF+70GGamS7vCe1eREw e5DTIRAL4kMoZPInEgvHJrHlwU424pOgxGQcS4nKVKpylaxspStfCctYynKWtKylLW+Jy1zq cpe87KUvfwnMYApzmMQspjGPicxkKnOZzGymM58JzWhKc5rUrKY1vyCAbGpTAB/I5g68iQBw hpObG9imNkkgTieY0wLmTOc3yTnOFrjTnSigJw/s2YVzxrME+HxCOvt5gX/Cs5wDvUE/ASoB gY4AofeEJ0AV2gOIrmD/ngWtZ0UbOgaGhkCjSpBoBzy6zga0k536HGdJQ8qAke4TACgN6EAF WlKTxlSc4EQpTR3aUpkmAKI3rQBFRbpNoMaUpUNV6UpzutN20tOmQSXqSZsq04tOAKY8JSc+ W8rUmUJVpyTVqlcPCtWa4jSlW3XqUIVa1LJGQKkU/So3sbrVdUq0p0k1qU+titOXjrWuTuXr SjMw173alah8vWlB6dpXwhYWr2RNqFT/qtijCpauMJVsYylwzszq1a8/5WxeOYBYyjLWsYed bGk9C1mgeva0qfWrZQO72McmNrSy1exbTXtZyNI2r2p1LWIdC9zcwvavHE0qUn2LW49adrmt /xVrcDHLWubSdqqCXWttRwtW10Y2sr8FLG6Ne9zWCje63fWudrn72M4SdrjovStqxbtP5z53 u+r9rXLhet7c6tesWn0vfKm7X/xKVr3+te9F5bvf+dLXtHCtb3qvG9+KMlW14H3qR78b1bPm l7/aVSpZNTphtGpYt3otbYi3a90CQ1ixbQWpicO6WeQSt7oprvGG2ztj0MY4wuOtcIKnm2PS Sli2Hd5xeW2MYwVTGME8JnGC/wtg5vJ3xChuMooZilAEL5XIRf4whW38UAyH2cos3vGVpepi /yZZyWeGrpqLG+Q1A7m8QF4wdbeMAQLX2c1q/nJwmbxnO7OZpG/2cP+Ue+xkQvN5zVDucjyV 2+cvB3rJo5WzmascZxz3N7FR7q6BBytoDQx305qmcZk/K2iqguC+Yt4re5FcY0DjlcbshbN0 WTtmStP6u7m2sKQf/OtQi3bFSe51pcVqZgcjN6dGzXBXL81hEVcXxndltoCLXekPP1Wt3D4w l6fs7bSKm7wPvip2X2xY3vr4vLmOaqyJre10xxutLqW2dancZkuPu91UJbJ8+13iWQcc2pWw tTq/PWhuGPyaim7DwjHdjYczHBAGx/fEL47xjGt84xzvuMc/Xo2F4xnktBL5kEmOqn8LfMvb hjTKQ6Xywdb65C83FVsjHWmJ13wiN5eyu1P/q/OdR6TnjNYyzYUuKqJ/2ucQR7qlZC1jTgfd 6RaBOolh7HKqa33rXO+6178O9rCLfexkL7vZz472tKt97Wxvu9vfDve4y33udK+73e+O97zr fe9877vf/w74wAt+8IQvvOEPj/jEK37xjG+84x8P+chLfvKUr7zlL4/5zGt+85zvvOc/f4kB iH70osdB6U8w+kScPgKrB0DrP9D616Oe9A2QfQJeT/oBsF73DLC963mPgNjnfvXDx33xjeX7 FiTfA8ufg++bz3zg04D40k++8G8v/d/3Pvvb7z72KWB87ytL9rm/wPC3n/rg0x78659A+X+f fvXHX/7Qr/370Q/9//vDf/7Xx3776Q9872d8/Kd/EhB+6sd+3yd+2oeACaiADWiA2dd/4yeB Ach93hd/1PeA7meBFSB8FfiAGqgB6TeByyeC8AeBJch7BBiC1eeCLbiCF7iBu+eADOiAzTeB NkiDC1h/v3KAOriDNniCPQiBEbiAKdiBRWh+SYiEHsiEQ/iCTciBG6iCLeiEVziFSkiD+Xd8 /nd/P7h//ycsP2iCT3h+WhiB8xeEQBiG1FeAFnCCQiiDUiiHVGiGu5eBUUiHcbiGfSh+OPiG 9seDc1h8ILgsZDiHdYiGbLiDZXiEjAiJGBCHfCiIe8iEigiEpzeJegiFWJiFRriI/heKOv+Y g5Voe0TYK4joiZQ4ipgIilr4fIkIh5fIilZoiX9Ii3doh7YYiZl4iZXoi7joiaRIiL/Yi2No iL2oiZ3YisuYiKWIibX4iVVYg25Ih4rIgihYhNToiq8IjbuohN+4jXq4hmCILOQnhmlIgOv4 jIEIjvanhm9ofb/ojvjngv+Xg2fohW4Yg/DIjewXj13oi2oYjK9IjPoIhoUIS6gYBgwpBQ4J et24BxC5BNIYkU5IkOFQj49XiB3pkR8JkiEpkiNJkiVpkieJkimpkivJki3pki95kTEpkzNJ kzVpkzeJkzmpkzvJkz3pkz8JlEEplENJlEVplEeJlEmplEvJlE3/6ZRPCZVRKZVTSZVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZd1aZd3iZd5qZd7 6ZUsIwjkc0orIEps+Sc90iczIph8GQM7Ain4AyNq8RWQaReKswqKuSBPQiK2kSVhQxpjsiV7 6ZeYCSSaKZrMYRiUYpmnmR9INCcsMzPHASgjcjeWKZs28iVcAiCFAiaDKZa1eSCmmSh9spkG AiJ3SSTqAZyqCSV2wjnOASGpGZqOyZqBgpuSiUSVqRqK4h1zkpr7cgO82Z01wZ0nAJ7hKQhJ Y57pqZ7ryZ7t6Z7vCZ/xKZ/zSZ/1aZ/3qYmf+amf+8mf/emf/wmgASqgUsk8homYEdMVBQOd H9IS44kegmID5dmXrWA15jE2FJov1+EickEwgQmXyfmcUAIiIIoI17EYDkqXbSEmxOk3SrGi 7REpL3qgdikegwQg6Fxqq4kj1lmYfMkYahKiA8QUroEjyDmjapmgCBKkJGoaSFGkVHKkNJqk S+qZD/qjpSk3UUqjVSOdobGjQkOdfjKlfIIXpGSWBQAAOw== --=====================_RPTATT74185872.Exime-- From 3billie@acig.com Sun Oct 09 09:50:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EObYu-0000z0-II for grow-archive@megatron.ietf.org; Sun, 09 Oct 2005 09:50:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17590 for ; Sun, 9 Oct 2005 09:49:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EObiW-0004Ar-54 for grow-archive@ietf.org; Sun, 09 Oct 2005 10:00:02 -0400 Received: from [211.222.243.142] (helo=211.222.243.142) by mx2.foretec.com with smtp (Exim 4.24) id 1EObYh-0006EB-9a for grow-archive@ietf.org; Sun, 09 Oct 2005 09:49:48 -0400 Message-ID: From: "Paul A. Davis" <3billie@acig.com> To: grow-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gTE9XIHByaWNlIQ==?= Date: Sun, 09 Oct 2005 13:33:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_20FF7EA5.7B2A7CFC" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is a multi-part message in MIME format. ------=_NextPart_000_0000_20FF7EA5.7B2A7CFC Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_929FD8B8.DF0D6D01" ------=_NextPart_001_0001_929FD8B8.DF0D6D01 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Viagra - Cialis - Levitra http://www.elitepills.net Up to $1.99/pill! ________________________________ To change your mail details, go here ________________________________ ------=_NextPart_001_0001_929FD8B8.DF0D6D01 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Viagra - Cialis - Levitra
http://www.elitepills.net

Up to $1.99/pill!


________________________________
To change your mail details, go here
________________________________

------=_NextPart_001_0001_929FD8B8.DF0D6D01-- ------=_NextPart_000_0000_20FF7EA5.7B2A7CFC-- From owner-grow@lists.uoregon.edu Mon Oct 10 17:21:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP554-0000hI-MO for grow-archive@megatron.ietf.org; Mon, 10 Oct 2005 17:21:10 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25536 for ; Mon, 10 Oct 2005 17:21:07 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX198y/22oPFFVlYhjiMJDvUBbZcmKIhRddw@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9AL9dS9030429; Mon, 10 Oct 2005 14:09:39 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9AL9dbd030428; Mon, 10 Oct 2005 14:09:39 -0700 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9AL9cMh030424 for ; Mon, 10 Oct 2005 14:09:38 -0700 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9AL9cNq026498 for ; Mon, 10 Oct 2005 14:09:38 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9AL9cJn026497 for grow@lists.uoregon.edu; Mon, 10 Oct 2005 14:09:38 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 10 Oct 2005 14:09:38 -0700 From: David Meyer To: grow@lists.uoregon.edu Subject: grow: FYI [agenda@ietf.org: 64th IETF - DRAFT Agenda] Message-ID: <20051010210938.GA26490@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. Sender: owner-grow@lists.uoregon.edu Precedence: bulk --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from IETF Agenda ----- > From: IETF Agenda > To: Working Group Chairs > Cc: bofchairs@ietf.org > Subject: 64th IETF - DRAFT Agenda=20 > Date: Fri, 07 Oct 2005 23:59:45 -0400 >=20 > This is the first DRAFT of the agenda for the 64th IETF Meeting. Please n= ote the > following cutoff dates: >=20 > October 12, Wednesday - Cutoff date for requests to reschedule Working Gr= oup > and BOF meetings 09:00 ET (13:00 GMT) > October 17, Monday - Final Working Group and BOF agenda to be published >=20 > Send all comments to agenda@ietf.org > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > Draft Agenda of the Sixty-fourth IETF > November 6-11, 2005 > As of 10/7/2005 >=20 > SUNDAY, November 6, 2005 > 1200-1900 Registration -=20 > 1300-1430 Newcomer???s Training -=20 > 1300-1500 Security Tutorial -=20 > 1500-1700 Introduction to WG Leadership: Chairs & Editors -=20 > 1500-1700 DNS for Programmers -=20 > 1700-1900 Welcome Reception - =20 >=20 > MONDAY, November 7, 2005 > 0800-1800 IETF Registration -=20 > 0800-0900 Continental Breakfast -=20 > 0900-1130 Morning Session I=20 > APP apparea Applications and Transportation Joint Area Meeting=20 > INT dnsext DNS Extensions WG > INT eap Extensible Authentication Protocol WG > OPS grow Global Routing Operations WG > RTG ccamp Common Control and Measurement Plane WG >=20 > 1130-1300 Break=20 > 1300-1500 Afternoon Session I > APP lemonade Enhancements to Internet email to Support Diverse Service > Environments WG > INT ipdvb IP over Digital Video Broadcast WG > INT l2vpn Layer 2 Virtual Private Networks WG > OPS capwap Control and Provisioning of Wireless Access Points WG > OPS v6ops IPv6 Operations WG > SEC dkim Domain Keys Identified Mail BOF > TSV ecrit Emergency Context Resolution with Internet Technologies WG > TSV ippm IP Performance Metrics WG >=20 > 1510-1710 Afternoon Session II=20 > INT softwire Softwire BOF > OPS bmwg Benchmarking Methodology WG > RTG rtgarea Routing Area Meeting > SEC krb-wg Kerberos WG > TSV rmt Reliable Multicast Transport WG > TSV sipping Session Initiation Protocol Investigation WG >=20 > 1710-1740 Afternoon Refreshment Break - > 1740-1840 Afternoon Session III > APP calsify Calendaring and Scheduling Standards Simplification WG > INT mipshop MIPv6 Signaling and Handoff Optimization WG > INT ntp Network Time Protocol WG > OPS opsarea Operations & Management Open Area > RTG rpsec Routing Protocols Security Requirements WG > SEC smime S/MIME Mail Security WG > TSV fecframe FEC over Transport Framework BOF >=20 > 1850-1950 Afternoon Session IV > APP xmlpatch XML-Patch-Ops BOF > INT netlmm Network-based Localized Mobility Management BOF > INT ntp Network Time Protocol WG > OPS opsarea Operations & Management Open Area > RTG bfd Bidirectional Forwarding Detection WG > SEC ltans Long-Term Archive and Notary Services WG > SEC syslog Security Issues in Network Event Logging WG > TSV pmtud Path MTU Discovery WG >=20 > TUESDAY, November 8, 2005 > 0800-1800 IETF Registration -=20 > 0800-0900 Continental Breakfast -=20 > 0900-1130 Morning Session I > APP rui Remote UI BOF > INT ipv6 IP Version 6 WG > INT monami6 Mobile Nodes and Multiple Interfaces in IPv6 BOF > OPS radext Radius Extensions WG > RTG mpls MultiProtocol Label Switching WG > SEC sasl Simple Authentication and Security Layer WG > TSV nfsv4 Network File System Version 4 WG > TSV xcon Centralized Conferencing WG >=20 > 1130-1300 Break=20 > 1300-1500 Afternoon Session I > APP imapext Internet Message Access Protocol Extension WG > INT 16ng IPv6 over IEEE 802.6(e) Network BOF > RTG forces Forwarding and Control Element Separation WG > RTG idr Inter-Domain Routing WG > SEC isms Integrated Security Model for SNMP WG > SEC pkix Public-Key Infrastructure (X.509) WG > TSV rserpool Reliable Server Pooling WG > TSV sip Session Initiation Protocol WG >=20 > 1510-1710 Afternoon Session II > GEN edu EduTeam General Meeting > INT mip4 Mobility for IPv4 WG > OPS dnsop Domain Name System Operations WG > RTG gels GMPLS Controlled Ethernet Label Switching BOF > RTG ospf Open Shortest Path First IGP WG > SEC tls Transport Layer Security WG > TSV behave Behavior Engineering for Hindrance Avoidance WG > TSV dccp Datagram Congestion Control Protocol WG >=20 > 1710-1740 Afternoon Refreshment Break - > 1740-1840 Afternoon Session III > APP crisp Cross Registry Information Service Protocol WG > INT dhc Dynamic Host Configuration WG > INT pana Protocol for Carrying Authenticaion for Network Access WG > IRTF mobopts IP Mobility Optimizations RG > OPS imss Internet and Management Support for Storage WG > RTG rtgwg Routing Area WG > SEC pki4ipsec Profiling Use of PKI in IPSEC WG > TSV enum Telephone Number Mapping WG >=20 > 1850-1950 Afternoon Session IV > APP opes Open Pluggable Edge Services WG > GEN ipr Intellectual Property Rights WG > INT dhc Dynamic Host Configuration WG > INT ipoib IP over InfiniBand WG > IRTF mobopts IP Mobility Optimizations RG > OPS opsec Operational Security Capabilities for IP Network Infrastr= ucture > WG > SEC msec Multicast Security WG > TSV enum Telephone Number Mapping WG >=20 > WEDNESDAY, November 9, 2005 > 0800-1700 IETF Registration -=20 > 0800-0900 Continental Breakfast -=20 > 0900-1130 Morning Session I > APP lemonade Enhancements to Internet email to Support Diverse Service > Environments WG > INT dna Detecting Network Attachment WG > INT pwe3 Pseudo Wire Emulation Edge to Edge WG > OPS mboned MBONE Deployment WG > RTG sidr Secure Inter-Domain Routing BOF > SEC kitten Kitten (GSS-API Next Generation) WG > TSV mmusic Multiparty Multimedia Session Control WG > TSV nsis Next Steps in Signaling WG >=20 > 1130-1300 Break=20 > 1300-1500 Afternoon Session I > APP geopriv Geographic Location/Privacy WG > APP sieve Sieve Mail Filtering Language WG > INT nemo Network Mobility WG > INT trill Transparent Interconnection of Lots of Links WG > RTG l1vpn Layer 1 Virtual Private Networks WG > SEC inch Extended Incident Handling WG > SEC mobike IKEv2 Mobility and Multihoming WG > TSV sipping Session Initiation Protocol Investigation WG >=20 > 1510-1610 Afternoon Session II > GEN pesci Process Evolution Consideration for the IETF BOF > INT autoconf Ad-Hoc Network Autoconfiguration BOF > RTG isis IS-IS for IP Internets WG > SEC mobike IKEv2 Mobility and Multihoming WG > TSV xcon Centralized Conferencing WG >=20 > 1610-1700 Afternoon Refreshment Break - > 1700-1930 IETF Operations and Administration Plenary -=20 > Session Chair: Brian Carpenter >=20 > 2200 Late Night Session > PGP Key Signing=20 >=20 > THURSDAY, November 10, 2005 > 0800-1700 IETF Registration -=20 > 0800-0900 Continental Breakfast -=20 > 0900-1130 Morning Session I > APP iee Internationalized Email and Extensions BOF > GEN techspec Requirements for IETF Technical Specification Publication= BOF > INT mip6 Mobility for IPv6 WG > IRTF rrg Routing Research Group > RTG pce Path Computation Element WG > SEC emu EAP Method Update BOF > TSV tcpm TCP Maintenance and Minor Extensions WG > TSV voipeer VoIP Peering and Interconnect BOF >=20 > 1130-1300 Break=20 > 1300-1500 Afternoon Session I > APP geopriv Geographic Location/Privacy WG > INT hip Host Identity Protocol WG > INT l3vpn Layer 3 Virtual Private Networks WG > OPS psamp Packet Sampling WG > RTG manet Mobile Ad hoc Networks WG > SEC saag Open Security Area Directorate > TSV sip Session Initiation Protocol WG >=20 > 1510-1610 Afternoon Session II > APP ldapbis LDAP (v3) Revision WG > INT 6lowpan IPv6 over Low Power WPAN WG > OPS ipcdn IP over Cable Data Network WG > RTG pim Protocol Independent Multicast WG > SEC btns Better Than Nothing Security WG > TSV nsis Next Steps in Signaling WG > TSV speechsc Speech Services Control WG >=20 > 1610-1700 Afternoon Refreshment Break - > 1700-1930 Technical Plenary -=20 > Session Chair: Leslie Daigle >=20 > FRIDAY, November 11, 2005 > 0800-0900 Continental Breakfast -=20 > 0900-1130 Morning Session I > APP simple SIP for Instant Messaging and Presence Leveraging Extensi= ons WG > INT shim6 Site Multihoming by IPv6 Intermediation WG > TSV avt Audio/Visual Transport WG >=20 > 1230-1500Afternoon Session I > IRTF hiprg Host Identity Protocol RG >=20 >=20 ----- End forwarded message ----- --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDStiSORgD1qCZ2KcRAigoAKCR8+QiB7bNixcvMJjgFf41pI++zgCfcqad PVMMk/4cDzeRr9s8BZvy8yI= =zyxs -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From info@mail.erddu.com Tue Oct 11 15:31:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPqM-00053E-3h for grow-archive@megatron.ietf.org; Tue, 11 Oct 2005 15:31:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24182 for ; Tue, 11 Oct 2005 15:31:19 -0400 (EDT) Received: from [58.180.212.164] (helo=mail.erddu.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPQ0V-0005fW-Ls for grow-archive@ietf.org; Tue, 11 Oct 2005 15:41:52 -0400 Received: (qmail 19937 invoked by uid 509); 10 Oct 2005 00:07:57 +0900 Date: 10 Oct 2005 00:07:57 +0900 Message-ID: <20051009150757.19936.qmail@mail.erddu.com> From: info@erddu.com To: grow-archive@ietf.org Subject: ご協力をお願いします。 X-Spam-Score: 2.9 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 当グループでは、既存女性会員の為に代理で男性に仲介をしており ます。当システムは男性協力型になっており、基本運営資金は希望 女性からの会費となっております。つきましては、男性には紹介料、 登録費用などは一切発生しませんので、負担はございません。 硝子　会員の依頼により無料登録直後硝子　さんと直接連絡可能と なっております。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ ★硝子　さんの個人情報参考★ □年齢：35歳 □希望：大人交際(逆￥ＯＫ) □伝言メッセージ依頼 『心に余裕があり、理解してくれる男性を募集しています。いきな り会ってＨするのではなくて、気が合えばそんな関係になりたいと 思います。恋愛とかは苦手ですので、ある程度の金額を出して付き 合ったほうがお互い楽だと思います。 　今年で35歳の硝子です。家庭持ちでも構いませんが、家庭事情に は一切巻き込まないで下さいね(汗)！ 　お返事を楽しみしています。』 更に詳細情報はコチラ http://www.tirol-festival.net/?pafupafu ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 逆援助もできる高収入の女性も多数いますので一見の価値ありです。 当グループはお客様から十分に理解を頂く為、無料電話認証全員漏 れなく最低■8,000円■(Pt)を無料で差し上げますので、是非一度 お試し下さい。 http://www.tirol-festival.net/?pafupafu 拒否 (Refusal Adress) iranai@jumpb2.net From castro@indianafamily.com Wed Oct 12 04:28:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbyY-0007yt-VH; Wed, 12 Oct 2005 04:28:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05470; Wed, 12 Oct 2005 04:28:35 -0400 (EDT) Received: from s0106000ae614e9bc.du.shawcable.net ([70.67.213.6]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPc8m-0002KW-8c; Wed, 12 Oct 2005 04:39:16 -0400 Received: (from tomcat@localhost) by 70.67.213.6 (8.12.8/8.12.8/Submit) id j7CHmn5V553860 for ffserv@ietf.org; Wed, 12 Oct 2005 03:28:21 -0600 Message-ID: <002w492l.1844007@132.151.6.1> Date: Wed, 12 Oct 2005 03:28:21 -0600 From: "Saul Plummer" X-Mailer: MIME-tools 5.424 (Entity 5.664) MIME-Version: 1.0 To: ffserv@ietf.org X-Spam-Score: (-2.152) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 70.67.213.6 X-Scanned-By: SpamAssassin 3.065980, File::Scan 0.35, Archive::Zip 1.99 X-Recipient: Subject: Mortagge ratee approvedd Content-Type: multipart/related; boundary="------------AttPart_50674278==.OLA" X-Spam-Score: 1.8 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_50674278==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
in handbag ! countersink , elide but crumb on cliche not schmitt on sawyer but catv some keaton and crafty ! drive be powers it celeste and angle Or maybe not

--------------AttPart_50674278==.OLA Content-Type: image/gif; name="monadic.6.gif" Content-ID: <0.0.0.81.0.76077537413698.22037674@civic.hotmail.com.7> Content-Disposition: inline; filename="monadic.6.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA40kKNFBBkTGSWToT+/StnRj9zpoXR/+SPwHVCS8obEp976WIGvm6fvraQPA6bvpDfP +TkqR4RfoGfiSZWZ+zWAU+KqOpGKTmCZaTmnPFM5sYcfUA7l+8M6xFAf/dI//dRf/dZPUhEA ADs= --------------AttPart_50674278==.OLA-- From brunette@hello.to Wed Oct 12 04:54:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPcN9-000743-LC; Wed, 12 Oct 2005 04:54:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07674; Wed, 12 Oct 2005 04:54:00 -0400 (EDT) Received: from 20132220099.user.veloxzone.com.br ([201.32.220.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPcX8-00036c-C4; Wed, 12 Oct 2005 05:04:40 -0400 Received: from [192.168.1.0] ([201.32.220.99]) by yahoo.com (Sendmail 8.7.1) with ESMTP (SSL) id IYT45394 for ; Wed, 12 Oct 2005 03:53:18 -0600 Message-ID: <576o581o.2320952@yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=frontage; d=yahoo.com; b=9Uu3udUNzdA1wDF5eKk2IQVOkPcMz88BKT2Drm5aq0JuPYRgF5QrQOKZhc0qvokiSDjVmT4ZDGxj82hy; X-Display: Full X-List: holography.usenet Date: Wed, 12 Oct 2005 03:53:18 -0600 From: "David Cahill" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gga8k2ijd9ai7232@ietf.org, ghostsender-a.3feet.com@ietf.org, grow-archive@ietf.org, gsmp@ietf.org, gsmp-admin@ietf.org, gsmp-archive@ietf.org, gsmp-web-archive@ietf.org, haley.bledsoe@ietf.org, hive@ietf.org, hsc@ietf.org, hubmib@ietf.org, hubmib-admin@ietf.org, hubmib-archive@ietf.org, hubmit@ietf.org, hyklkisis-wg-admin@ietf.org, i-d-announce@ietf.org, i-d-announce-admin@ietf.org, i-d-announce-bounces@ietf.org, iab@ietf.org, iab-wireless-workshop@ietf.org Subject: Pre-approved Application #6647635 Wed, 12 Oct 2005 03:53:18 -0600 Content-Type: multipart/related; boundary="------------AttPart_22302217==.OLA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. --------------AttPart_22302217==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
may stricture it's myoglobin in pound , vitrify not lavoisier it lebensraum ! dunham but lila see defraud a decorous ! adjective may forfend but ultimatum not downtrodden Or maybe not

--------------AttPart_22302217==.OLA Content-Type: image/gif; name="permissible.7.gif" Content-ID: <8.0.0.03.0.38063491836624.60503643@headwall.msn.com.2> Content-Disposition: inline; filename="permissible.7.gif" Content-Transfer-Encoding: base64 R0lGODlhtgHYAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZmZlmzGZm zGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAC2AdgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/gf5ECCLFQLEAB+eYWG h1V7fX8pgYOMiJGSk0OKI4SNgpiUnJ2eM5YimAcQEhKWjpiBpqGfrq+cpaazfwcSDiILEnyp f7qMDruww8SGrYQQuCOOvQASkAAOysXU1XDHf7KzpgC9tnzLgtbj5GjYjyfNzyTS5e7vYOe/ IqS+mr7r0cLo8P3+UucAkKKV616uWZZs/VvIkI0DaA0jSpxIsaLFixgzatzIsaPHjyBDihxJ suQ4XSRu/41o52ITvXwuFkzz4TKGo0Ezy9wkoevAzioscdQUsu+GA3Epiu74CWSfLqRDU9S0 BXGFzCBRY4pLloZpt11epQS9kfWH0hpHV5zNEbYHJmn71kqtKuMqkLIs2upEakLvk7E28PaQ axYcD786WO4ihJKerFYCEdoKFgycLlaGL5sCLCIYZnqeYT6bhcsWq4Okp4VWpK1eNwiPDa92 +ZPQgdCMFK7M+TX1t5eQwML+rPDmQFN0j99CuupUWoGPk2urHG048hG3CUZm58D0Ke4p+RxX xdfPZJUjnMaONg32bp6CAq3XrCy0skDB8H3Wt661EJSkdIPLc5MdZNgltVwnzP881R3ESCm8 wQbOcxJCp8x1rvHDIISiWPLcTYydwos4R4l33SIvdSgeV7p1ltOGKr2FHjMiNljcVuJkiN2M 33314HcF+lgCKTmawkcwOXI1iCKklCYBePzsGE5k961T2wKmQbRgPpW1aKQIML32lSI77VOi hb3xwqUg3wQo5hDftKOQkkoWZIJt+QgT5kPOHFinnSY89xIfMLGEiVJctQWiPeB809OOEN3U jqCRHdAieyUgistNo4nC6KA3NiglilM6A417fza2El+/URonq7tcamhVmCAzE0pXUmWCntC0 w5g0+JTATEJxqemnT3H1+keYiOnwjCV+5KPNNncmCE7/rNtI9iRPOXGGKYpFzbodt9/2tZU9 O/rEV5TpWSoMYOZt6yIJlwoIJpb36PYTtmKGts2x9LIpr50u/baSlkfmtAu8WA4srrDxnUuv cIsYHJ7FYvbiCJ/wvVkpmGpm+4xxIgNZocdCHCWvygiygOe1hB6Y3qndrtsZrDG/x4+moprr qceODqxrCcCSiLPFNfHMHp8ysbSvu/3yVgJt4iCqya0D9/yxqwsfXVStdPlRK9ZfXbwWr1B2 aupZw6YLctk+v41CY82yhd6Yy+SjY8sGv4vKlj/mROSEODp2oWzKyBg4dB6KsyjQwlSYpQmm GeYemksaSLS06FUOpnpmixkk/5HC8mg0OKUIXCVEthT5bo9Ndmi47F+hTtcqO65OpewYv80g dfrU12PHO/WNuodP7nRm7TQCCmeYd0On3dTWyq3ZJprdwlt2+ykXHOI/o7aZMtzX+CZjSBk8 W9isagPJeLdvE9TlmTvfZ6jSb3aCcoJezxL8+5uO39yHHQI6hhWQyEr0AHjAGvWuT+ILBYOG Rrz0FWslkkHZ9X6Uj7qZhAVhahke/pSFB37QHaOjX8fmQD/gbcFbJ0ThdGQWvjmshoZYIEwM d8jDHvrwh0AMohCHSMQixkEwT0BiXwqlw5bYDCtPhIIKYzDFFlRxIFE0wqOKsMUZdBELSmxC GDNVJP+pUTGLNEGjGNWogiq6zGZPocsRvvifJlrFjlKUI0D0CIj+4PGNR3CjFNkoFUJODY5/ rCMOf0BHGDTSWZqxlCwg0Rwm3eKSp3kNKwgkQMs8hpPT200pJEkabGXyeou8xCXfd0MwTYOO qZtFZrZRCiGJYlsbPIF19IfB/eRPNNqADH+Q0sr6eY8n8ouMLH85E39N8XqdyaA+Ujek6QAH g2PiRt4mlMEtMmgex7xljELZOiMppxTZIAj/cHCdp6jJQdF0l7QYASM2Xc5z9aTd3qbJuJfs QxVrWoFpyuMcWRDqlWf5pDYvAxdtwk4lDPUMrcbHoWk21ETaq2hqhveS4fz/AUkXzZxppFFR z5BUJSrrziAK2iOQemZdA+GTSSU6zAMNVGUCg0QwekOb12kPOUGipj7kedJNnWKUq1DpjoCa OpVZCUJ8aKpQa3A30RCqV92ByaFOJQiuXbUPXYUV0Yw2Mdvdix18HCoGEYqLu8GSR4QiFi79 SKh9kG5qWgXL8AqETlXWFRhZa103kGVBXKAqr+7iC5ZoR5m8LeApeUOkmizYVY7eMoHPoOBO 3Vk6wu5IE0/yTlxXillkDUhzE3sdZun5OoSmVS2GsSrGAoG0BEEsGgir18ZKdiCWcKxdP/MO Le8om6x9x60JZU5mmSUvEalEuP86JDIfWzLQimxZ/6rJ2kohWt3MTYsWDLoTiUr2EKstUU29 etJOxTuxhuk0eWvpSXj14aNfjMyP1z0Oa2U2tPXOTHP+Io0NikLgr+6mtnKTnVcheImumlFn C95ZKucWrqIUaHgupF1kGjaTWkZzlJFJhjRGLN5ZUlfEI07niEd8UGya674oBpZ3tbdiZMnx cpRZ8UPCe1dkorcP6tXuSqcbpCE3Ur5h8vBRNTGcW+pYqZcx1pC4ZOEOtlbHr1VBgYH7O2xZ DhjQAtJD/YY6MZNviv8bs1mrY5kt4bCLnB1IOhOkXfrpqqKyWGp7rByhGl0mxID9aOcudzf/ GugXrQt05hrbz5HCs35xBv8xhqa6TWXWgkOGxiCZvvQlyB7ZlJdGD00ZGs0zh1WtdBxanE/0 qEgnEgVbtl4GERzB/3Wy1mcWMNGmwb9/UhIh+02HUrLXuWzRyoKhzhY7LPzdiWarzbQsczKd kd3SLZPYrNlKtsh3XQ0H2JLZkqw/ERJNFDRbfJ2OrzCga8F1f0mcAvYXaiHVy20Emz/SzAIJ XfbgJdyGcizetVKFxcrMpHgmPukLidPRNM6kWFgB7wwltyeN3so4FxOvuMBvBY3baJw7wKrK bSz+W7ukY+HYQfnIAQ5yiJQ8UhEXEK+lNnCBHLxRCI85FVpoR55P2IhAt2G+VVDMoBv96EhP utL/l870pjudi69+utTb8MipW/3qWGe6QqgSSpTZxoDMjBySSJ31sgNh61/q3Si2dc+vuy6q KunPz81O9xig/cu3xRTXtPYbOhmy7oBvAdpJZbYj8fa3bxtFXwPPeBoMXoTckRTNccYuCjb+ 8oIP7cCG4rndNVrN6CCFu7JROGpj/vTbuVRUVLjOBl4yqoBFz+UI3W/U2556t889FTyo+95X Isu+D77wh0/84hv/+MgXAwxJYsKQ/GT5SIiKm24QdRyMh4bKPVFNKSeLV04yb+YLWAgZeTW5 6evvXtQ1T3LT/XBoP481ZAf6k8CxeolROjmoPllGXBO6bZr0UWUzJuMk//iAD4YnM6oyBKlw OCmCMj1gX15xKPZEgLYEf+yyKiUUOcBHBNI3f7A2dzzwDJxhGjVUIgQGDcWzMN5nKpfwIh5I A0xhV7j0glrxQPkBOR5XKhYYFZRiBYHwE5W0Zh+zOb5kHw04L4pHGjZTPt7UTepXb9xGKkb4 Gje4KvuWDEJWNFAyLzOzCd9QFECoTtHhIiBWQKVkeCGkMRuFHMaxHtynhLcEGeeBgLDxUTPx LO/DNvIjOKMhIpcRClO4NvrjHVfzGBioBWVoS9ThhclFODezIgIDHnhSJTZzOVGmiEixFmdy V2v3iGhyiZvTChWnXY7CF2PxJ9GShwmYgG8SJP/zgCTV9HZtsi7NwGDn53mpZjoZs4QVNSi2 sggwMVucw4eRUyE4xiSEtg4ZUis9oiQ96IN8sSeGlYcHEhZfFC+SmA0ouC6U8ih7wgh66Ce2 hQ7XiCyLlFKgUmfoojOi0GE8pjYHkXepol42s2DjJyaH0igziBMrBHkZo0Ot4yHTyI8IEoxK oTT0NoTFgSjLolOJ8yDMQVZakILVaBCDsoX96CKyMpAFsy4kZErhlmD28y3Y2BvGphejCHvj IkLP10x3+IPpAoa0KDHp4nAIwzh0KGENmAolMzU25TjhV1Zp8ThjgYduc4S5wIejsh1M0Q7h 8pA1pBvPWAX7glXlwor/U3mNDYN3v6iDN+NjDLYrCMiQBQFQ6ZBFviIT3RYlFsMsFpSDdqJV LtiOyFQuh3iR8dgx+biTFjkXGTmVpQhdp0CRQRGDfqKUR7iQ4hiWD8OIXxCGgPVjsRMwjeOJ nAiUKumKlqWZZIZamoiMBAVW3OSA0NE0PWEYLVITxpiJoxU7uqIrrcY2ZQRPI6hmzaOX4KiP djJB/aeLMsWNWdUki+kME7hhxrlsizMxSymVoJlgjZmHGoYFTIFK4Bc9KZdvgchASbgZvHiG EfQ9JxCISUmEfraERdeA3zVe5tOGvKRJMPGHNFQ8Y2iXZrgZkfN++JibfOl60gGHWCQzTmWd //xwHN6Hn+gGGC2SoCujfk8ZPo5ZPxthf2JRezAgTO/QfMknbOxHoUwAfSKBoRn6Yu0ZoiRa oiZ6oiiaoiq6oiw6AgRQADBKAAEgAwJQAERAAAQAADUqACJQAAPQRk9IRRtIEwhkAgEAo0hK ADxKBD7aoz/qA03qpOwEgjswRmeHTlMJA9MnBDg6AC+aozFQozeaozX6pFFqbgkypIRHf5tm pAVAAAPgpTD6pEIQpWfKA2d6pzSgf4Ghpj7QGFn6AlsaBDgqAoUapjY6BIUaAAMwowCgp7h3 gS9gpSHIWm66pAAQAC+KqUCgpFIKpXQKqTLApzVAqX9KgwFUBIVao/9gmqkvGqMF4Kg1mqSJ WgKamqQzyqow6qpIyqkDgKRvmqNHKgCzuqtoWjvVqT0bph1fl1WUwYhRVXTrZDHKczIkMKzX GqW3Oqck8KsxKqvfCgBfGq46GgDFWqsicKSvWgDE2qsjcK4vqqPAeq7puq5L+qtf+oHRxEvz Q0wuCWLrQ4gRxE3jxz+q81xuWJ2PtQdvUSW+ZLBTphnvM58usK7smq5zKqexKq8+6q3oirFv Gqcwaq4xKgBH2rEv+qT4KrJvmqnsyqghKxXk9mgc4jl9t7AYpY1us3jgNGgDMg3u9mDYSgKL GqNyCqYr660zOqct+6pwaqzpurK2iqQe+7T/GzurLGujMAunW/ujJxunKQsA3iqj+rqJ7uEl ybJsOLIi8/RoaTGLU0aJloaLsmknpei2s4k3qWUiJqI7FQun3sqjL+qot7q0ZOuyHyuuF5uu PMqqM7qpLhqrrPquLTu0oipChHaYQ4gOsIFsUSl2eik1t4isnDG0LpqjkGuo7Dq5GPujb2qu jxulNeqoIwCpJ5urLSuvPPq6IFu7ofqkqau4W6tl5ogiv8I0WfMhQgM2Z3UwLFgtHTM0qTKT gLIK16Is7MIUCDaPL3CoR/qjcJqtAWC68moCh1oCs6u6wAqj7Uq74iqsi3u5NbRcELeSnGtn vrazNvUkWYEM7xWU/xjLqY+Kuq3qsu26vi07q2B6vulLAra7uEM7rOQrpp/6qMCLwOz6q7DV lJtyDxvjcvfhkQ9CZyE5OD4ZMEP4XdpUKjuhJIL5HR05ZcbbcYl0vk1bwLP7vUSbuPFqAg2c snEaxCSLqZoKv0sqv1GyDjyjetpIMhOCUHQ5JftWEBKKAhPcpD0sAjvKqkEcp0t6q+Dbqg3s u5cawAGsw5FLxp8KxF0MsxtMlmtzL2fhNMs7wiJZOpFqt/kLCI5DIkehn3dyKzC1edlANn+r uj+Kr7i7sWGruImryLwqr476q09axD16sbdqxBWcUD8STYvDxOQoMG12aYlDZQlyZkBbE/+Z NgKmq7Riy7uzOr5veq8vW8sETLnua8FlbMBm3Mivqsa6/MqVXKga7I8QZLbEJGqWVS6Ss3hv 8TfqAjd5I7cGw5uR0sf20irQTLeDjCKauYEWe7gWO7K8ur4nMM5kurHqS7UgC6yaHMwRmG/Z IyeErCF7AIbqh4VF6nrNpF2r3M7ASrvjvKTn+rony77vi8sl8MBfDMGYPM61mqd0Os6JXKv2 ZyZPOEHjNxbrU0O5tF0iNx2iXJ/jdxO0FZEhM5gk3YOgnD9WKgBdjL5BDNO0C9NeTKe2KsRR 67423agl0MXEmqk+LbZLaqH3JwMeagJdPAACrKNBrNRe3K1MrcX/RDzUIzDVOU24Q82oNT3T dIrVRE0CPS2rdIp4LZoGlAqiZ416lMp7a/3WcB3Xcj3XdF3Xdj0FLeynLRB1qanXd30ReV0Y WiovpvrXgA0Vfg1bg23Mhu0PfRgr33eghiVLM0ud56Ea7eGvgng3EIsbktrY8NBOfjZXyRnY mDi3S/luSqyMrC23K1nYoO0KVQWeSmPa32h5P2OacFMoA1kqfR3bC3GC7aJbIcw31fVAGtNV gIyPP3mEsA3cnRBrEFTbiH3Hm5sSjTEaMCPF24iU0P0P0q1aTuY8z9xm7oJDjAaLCUYjru0l HPrdsBDe0DY+5P1rRWpCGg2egAKxKymg//D93wAe4AI+4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe 4RI+4RRe4RZ+4Rie4Rq+4Rze4R7+4SAe4iI+4iRe4sT3ABGQ4iluACKQACie4g+QACrg4ioe 4yNgACqu4gmQ4xHwACkQASyOAgzA4wAw5DUe5EZe4wDw4jpeAgzAACXwAD4+AjSe4g0Q5EKe 4wyA5QBgAA1Q4zI+AjZOAhEA5QDw5T2O5BFA5lCO42EOADue41MuAjhOAjhO5GV+42je42++ 5H0OAHl+AlWe5jceAW++41g+6GN+5zm+5Dz+5y3O5GO+5HPe5YZO5ZL+5lLe4iluAg9g5iKw 6Y6e4wnA6FZO5/88DuR2ruqF/uZeDuZUHgEIMAKdLgJDzuK3zgIJwAAo/uS4DuO8nuKgXgJx /uloPuU4/ulPvuVP3uMMAOmcXulOXubLXuTUbuS/vuzPTunazuXW3ueiPupP/uLQzujjvuKc 7uxGPucozuV5vuMPgOa2vua03uaXTufN/ungfu+2PuTKDuhmXuzN3uNizuoiEOhRLuzBfu9u Hutq7uwvbub5/uTcvuzebu3OjuZmHu6WHubrzgAaH+o+7u8n8OkkIOpS3u3Jfu72ruy+vuoP gOUND+fAvu6obuYIgO6OPu8Xn+WxHvM3juKQDu8y3+sdbwIzjwIv3vPWPu0O3/RRLu3/087v ok7ysW7wBT/s8G7p/O7oDRDqOg/wNM/iBuDx9H7w9v7nSY/qtX7yc57nd77vXz/qWI7wI2D1 bE/2/I7oNA/0dC70Ys7uUk8CRB/0qs7xDV/4f3/4Uk7wJT/sKC/tSU/wa18Cdz7nDR/3Jx8B c+/4Rh7mnM/zLjDkBe/td+7pWG/rqA7plU/4ZW73JED6sX/27Q71bq8CSR7km57sJrDjcx/r w97ivw7ptf/ifv/ujn/3Zy/2lV/5Qz7kfx7ueQ79qM/ixh/ksA/oUo/jX5/0fF/7q077gq8C YU/nYY74l17+XX7+KQ7toQ75U87xR0/z3d/1lq/kR0/9Cc/i/18OAgAQNdEDIFEiMpEhwrHc wqQslm9s37ARAYOv36oHeESOrl4rmGwGTwAo8IR0FmGt3/JxSmV3Uu3SiOwlVMdHWhphsIC6 abIGJ8rwPtNoLPLaKaGpebWJvOWp3QDqAaS98Mjk/I1dBYX9NBhRxhBlbippblpG/TmpcDkN nZaJEJXcEdbJpK2kIbw+RSDEzYHSuSLebMkIxwn9PDAsM6yGxYAB/MANvzHTIbGRMTOseHH7 Aqc8GADW9gDGEJv5wUQDtpwYpynSBDYGhxHfxqSPwPmDRuhEvH+JnnFq9GgakzL+vjHzxXCU H0/G0AGhhk4Zs3QQlxlIllFHMnCdZP8lwBPQnZppNMCc6fWLTI12pm4AiZFgGZKQik4iNHWq 4QwXfGjKWFlURBtGF4O1O2emFRle6WBd5BJnR6xn+Fj58YeoZzWrUrBqDKaxZzJpPx/1wQjj oU0xoALiOcoOSdAjaT22I9IiC76DpgYrCUeHV590JPSum2kPQIlnhoqmdXuisNugJZdVrrY0 jcbJc+sipXNUjqSfUCUqc6Q3WJ2HGf0yXbKOYWGFJDq2Egvn8p7alW4nLZOMr1tRdF6E1qmX LqjoMODiVWM99wsvXBgn/StlpUrlrg27BWJrdvq56nEgd5QZ1GQu5KSVoOpemyPmnDkn1s8s qW1F2S4F9oP/GoJKSJGCMOWwFwd/CSBBTTY6NMGYPxDCoR6EL7QRkn/nNTLbJ5wcYqEJGAKh 4Rgc3uAgNU04995l9g2R3xzUbcJFAzmylt0KPgLZxWashZcginsMeRSA+RRXxIXHgNeEDvSA R9ZMwPhAyopGQHhKEakI0dkNE113nmlcBkgFH14+s6Y/9DihoJsXeflTdrEEsVadtF1ipmxx OjSGMXlmsecgrGhEZithRuGLbVic6eV9SvSpB6RV6JCOg+HEdppQl+hBWnqqACVdoqyEMU5x AvZ1w05nRjSTAdzMwE0zLCh2q2K76pTZrK7suhM3tugazrA+WFbrL7jSuoxlXo0p/y0t1mph 0hQkzecrU1l00wkz0+YRq7FwbOesuCDJmsW57PZwK7ZMHeutD+Pq5C6w14WRQBHv7rqvvywk O4OyEuE7TL/9zrelww9DHLHEE1NcscUXY5wxxOFq3LHHH4McMpghkVyyySejnLLKK7Pcsssv wxyzzDPTXLPNN+Ocs84789yzzb8oELTQQxNdtNFHI5200ksz3bTTT0MdtdRTU1211VdjnbXW W0+tmMhfgx222GOTXbbZZ6Odttprs92222/DHbfcc9Ndt91345233nvz3bfffwMeuOCDE164 4YcjnrjiizPeuOOPQx655JNTXrnll2Oeueabc96555+DHv+66KOTXrrpp6Oeuuqrs96666/D Hrvss9Neu+2345677rvz3rvvvwMfvPDDE1885BBIkLwDEkOwwA0OJJ88BGc3b7z1k1d/gATO Q1y9DA4sLwIE05ft/fXnN+69+Q6vLwL4MCxAPtnto1+/4dUvIMEBMECvPP/JL0B70vte+AAA gfAdAHkAhMEB+rc9/Ykgf9F7H/iQtz8Hjs95Eiyg/Tr4NwVKQH4OgMD+Erg87R0ggeLjXgwc GEIYjE8ECeReDAEgwf3lj4YSWB70yDfCEiLPedsz4P48aES+qW96+Sui+PY3RBiykH8OiF8L 5QcA7QFghDFYIgAgCEMeki9/MZj/oQGteMQz4s1825Ng9BaYQBKu8HnLO+D/2pg8E8pAf1jc Ig/DR8UYZC+IaByk3dS4ADFuApH0ex8K3cdB/lmRi14UXx9lOEkyWjKKhNxk29QnAfHBMYuf pKIiNZlFP5JPewiMoSojeEdR6rCS7oNjAreXwBQO8Y+c3CXaQBhKUUqviAqkoSnf50gZgrCA tVSeF9m4Q1m6L3oZBGb46MfLa1pujx8zIza76bgcIvOR3hzn6uI3QXKiM53qXCc72+nOd8Iz nvLkZANF1jztmTJiiBzjEx2my3nO04Ihu2c/KQY9TR4UYv8EKDxVKc6MWXNiIzTjAh+2UIa6 E3zaNOAI/wdYxxB6j42hrB4EH+g/ZE6QmwecIvzit8oJQvCAII1eIyPITYxes5HmQx756JhF Wi4QnD+NY0mHSMZW2vCFMjigLklIxzdaMqY7tOkxRTBJnHbTmNqsoQ2VeMkhFpSlJHUiC9+3 vouCFYfT06IWGRjTAv5xjxfFKi/t+ETzkdKMBLXr9MbaRSaalYlX5OYQzarBtWoypixsqvMi SldC/vOPePUqP4UoWCj+NbPHPKsZG4nCTyZ1qG7d32ThR0LQPhabVzVgYxfbU6AWNpRc9Osk 35c/PyrVrTD0KRa1lPU3ehYGIcxnagd5USoGF5gg5Z5Ii7JQ6r5UeWbcJxevfTKHZe5QsaZt IWqL+9iCBs6Y3p0nUqcuaGqOl7zJvCzg5prB5Ca3vvKdL33ra9/74V0hot0vf/vr3/8COMAC zm8IAAA7 --------------AttPart_22302217==.OLA-- From owner-grow@lists.uoregon.edu Wed Oct 12 10:05:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhEJ-0008IY-2M for grow-archive@megatron.ietf.org; Wed, 12 Oct 2005 10:05:15 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22804 for ; Wed, 12 Oct 2005 10:05:11 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+nvQHdFOKRbYoQ/Y0ieGz7KTmqmUoFsyk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9CDoxa6018077; Wed, 12 Oct 2005 06:50:59 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9CDoxT8018076; Wed, 12 Oct 2005 06:50:59 -0700 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9CDowfY018072 for ; Wed, 12 Oct 2005 06:50:58 -0700 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9CDotYm011219; Wed, 12 Oct 2005 06:50:55 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9CDorh7011218; Wed, 12 Oct 2005 06:50:53 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 12 Oct 2005 06:50:53 -0700 From: David Meyer To: grow@lists.uoregon.edu Cc: gih@apnic.net Subject: grow: draft GROW agenda uploaded Message-ID: <20051012135053.GA11205@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. Sender: owner-grow@lists.uoregon.edu Precedence: bulk --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please see http://www3.ietf.org/proceedings/05nov/agenda/grow.txt As always, additions, correction, etc, to Geoff and me. Thanks, Dave --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDTRS9ORgD1qCZ2KcRAm7TAJ0Y5YaHXMg5sIDoBatYhXlppfXrlQCgjRXe NMwQMomzjcVVVOGw2wWP/nA= =e6Z4 -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From lowe@henrycoelections.com Thu Oct 13 18:46:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBqj-0006BX-Rp; Thu, 13 Oct 2005 18:46:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23552; Thu, 13 Oct 2005 18:46:52 -0400 (EDT) Received: from host154-45.pool8535.interbusiness.it ([85.35.45.154]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQC1G-0003sX-Q0; Thu, 13 Oct 2005 18:57:54 -0400 Received: by 10.11.98.7 with HTTP; Thu, 13 Oct 2005 17:46:34 -0600 Message-ID: <138r309e.3525109@yahoo.com> Date: Thu, 13 Oct 2005 17:46:34 -0600 From: "Alison Terry" User-Agent: Apple Mail (2.728) X-PGP-Key: BSkXj0tutPRX1DgDvJWwrel5hMH4FCiMHCTlUTjQrhEay7v29y0T4m60ln0r0YbD== X-Load: 63% MIME-Version: 1.0 To: fxmaarohc-admin@ietf.org Cc: g-admin@ietf.org, g-web-archive@ietf.org, gchairs@ietf.org, gcunning@ietf.org, gency@ietf.org, geopriv@ietf.org, geopriv-admin@ietf.org, geopriv-web-archive@ietf.org, gga8k2ijd9ai7232@ietf.org, ghostsender-a.3feet.com@ietf.org, grow-archive@ietf.org, gsmp@ietf.org, gsmp-admin@ietf.org, gsmp-archive@ietf.org, gsmp-web-archive@ietf.org, haley.bledsoe@ietf.org Subject: Last chance for lower rates Content-Type: multipart/related; boundary="------------AttPart_03099695==.OLA" X-Spam-Score: 1.8 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_03099695==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
be proper it's clap , oboe and conferee not veil the warrant may compendium a exponential try beech some chum see startle some kafkaesque on primrose it's ambuscade Or maybe not

--------------AttPart_03099695==.OLA Content-Type: image/gif; name="lacerate.8.gif" Content-ID: <9.0.0.28.0.97031733391591.33804708@austenite.msn.com.8> Content-Disposition: inline; filename="lacerate.8.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTFMhmV46NqPDROeHJXlLdFa0k1ZeM5vOG5p3wznOcp4znets5zvj Oc963jOf++znPwM60IIeNKyVxHhDIzrRiKxsSxvt6EcGQzrShAwBADs= --------------AttPart_03099695==.OLA-- From cairo@ae.com Sun Oct 16 16:04:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EREjp-0005XB-Po; Sun, 16 Oct 2005 16:04:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19738; Sun, 16 Oct 2005 16:04:02 -0400 (EDT) Received: from 82-168-161-108-bbxl.xdsl.tiscali.nl ([82.168.161.108]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EREux-0003tB-By; Sun, 16 Oct 2005 16:15:42 -0400 Received: by 10.11.98.2 with HTTP; Sun, 16 Oct 2005 15:03:44 -0600 Message-ID: <392r890r.0987424@msn.com> Date: Sun, 16 Oct 2005 15:03:44 -0600 From: "Mauricio Herrington" User-Agent: Apple Mail (2.728) X-PGP-Key: bkVWlUW6SHjQY83igsIHYgfffE0xAm0kt9V9vFSpMOqha26bVOaawBC7SphqWY41== X-Load: 57% MIME-Version: 1.0 To: g-admin@ietf.org Subject: Re-finance at the lowestt ratess Content-Type: multipart/related; boundary="------------AttPart_78764029==.OLA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_78764029==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
try lentil a instrument it's cart and golly , groundsel or multiply try calibre a shirt but turbofan be cordon it vitiate a curate and exquisite try enable Or maybe not

--------------AttPart_78764029==.OLA Content-Type: image/gif; name="informal.9.gif" Content-ID: <7.0.0.54.0.52254837198682.46178994@grandson.msn.com.4> Content-Disposition: inline; filename="informal.9.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTFsvnV46NqPDROeHJXlLdFa0k1ZeM5vIsmb3wznOcp4znets5zvj Oc963jOf++znPwM60IIeNKkx37hDIzrRiWzuLxvt6EcGQzrShAwBADs= --------------AttPart_78764029==.OLA-- From haruo@absolutemotion.com Wed Oct 19 12:03:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGPS-0000y2-VX for grow-archive@megatron.ietf.org; Wed, 19 Oct 2005 12:03:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25027 for ; Wed, 19 Oct 2005 12:03:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESGbE-0007nE-IS for grow-archive@ietf.org; Wed, 19 Oct 2005 12:15:32 -0400 Received: from c-67-168-101-80.hsd1.wa.comcast.net ([67.168.101.80] helo=67.168.101.80) by mx2.foretec.com with smtp (Exim 4.24) id 1ESGPQ-00049D-3Y for grow-archive@ietf.org; Wed, 19 Oct 2005 12:03:22 -0400 Message-ID: <91e401c5d4c5$4e263547$8de27e4e@absolutemotion.com> From: "Jennifer A. Clark" To: grow-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gNzUlIE9GRg==?= Date: Wed, 19 Oct 2005 15:52:39 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_52C97CE1.C1313021" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.1 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is a multi-part message in MIME format. ------=_NextPart_000_0000_52C97CE1.C1313021 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_0A8B6234.C4355B51" ------=_NextPart_001_0001_0A8B6234.C4355B51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the popular software you need for extremely low prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To view full list of products go: http://www.cddisks.org Sincerely, Jennifer A. Clark ________________________________ To be taken out, go here ________________________________ ------=_NextPart_001_0001_0A8B6234.C4355B51 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the popular software you need for extremely low prices!
Our software is 2-10 times cheaper than sold by our competitors.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 Quark Xpress 6 Passport Multilanguage

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... To view full list of products go:

http://www.cddisks.org

Sincerely,
Jennifer A. Clark


________________________________
To be taken out, go here
________________________________

------=_NextPart_001_0001_0A8B6234.C4355B51-- ------=_NextPart_000_0000_52C97CE1.C1313021-- From owner-grow@lists.uoregon.edu Wed Oct 19 14:31:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIig-0000r0-MF for grow-archive@megatron.ietf.org; Wed, 19 Oct 2005 14:31:22 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05375 for ; Wed, 19 Oct 2005 14:31:11 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18XwAYApY4wy/joKUztW79BwdoG63Inw0A@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9JI47fm011736; Wed, 19 Oct 2005 11:04:07 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9JI47de011735; Wed, 19 Oct 2005 11:04:07 -0700 Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9JI45mj011710 for ; Wed, 19 Oct 2005 11:04:05 -0700 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.54 (FreeBSD)) id 1ESIKZ-0004wI-5Q for grow@lists.uoregon.edu; Wed, 19 Oct 2005 18:06:30 +0000 Mime-Version: 1.0 (Apple Message framework v734) To: grow@lists.uoregon.edu Message-Id: <0CF3F8C8-F529-4469-99AD-E264118B5F37@isc.org> Content-Type: multipart/mixed; boundary=Apple-Mail-10--1033503470 From: Joe Abley Subject: grow: draft-ietf-grow-anycast-03 Date: Wed, 19 Oct 2005 14:03:55 -0400 X-Mailer: Apple Mail (2.734) Sender: owner-grow@lists.uoregon.edu Precedence: bulk --Apple-Mail-10--1033503470 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, I just submitted the attached document; it should appear in the usual repository in due course. The principal changes are in section 4.4.3, the full content of which can be found below; the rest of the document is substantially unchanged. Feedback would be gratefully received. Joe 4.4.3 Equal-Cost Paths Some routing systems support equal-cost paths to the same destination. Where multiple, equal-cost paths exist and lead to different anycast nodes, there is a risk that different request packets associated with a single transaction might be delivered to more than one node. Services provided over TCP [RFC0793] necessarily involve transactions with multiple request packets, due to the TCP setup handshake. For services which are distributed across the global Internet using BGP, equal-cost paths are normally not a consideration: BGP's exit selection algorithm usually selects a single, consistent exit for a single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however. Equal cost paths are commonly supported in IGPs. Multi-node selection for a single transaction can be avoided in most cases by careful consideration of IGP link metrics, or by applying equal-cost multi-path (ECMP) selection algorithms which cause a single node to be selected for a single multi-packet transaction. For an example of the use of hash-based ECMP selection in anycast service distribution, see [ISC-TN-2004-1]. Other ECMP selection algorithms are commonly available, including those in which packets from the same flow are not guaranteed to be routed towards the same destination. ECMP algorithms which select a route on a per-packet basis rather than per-flow are commonly referred to as performing "Per Packet Load Balancing" (PPLB). With respect to anycast service distribution, some uses of PPLB may cause different packets from a single multi-packet transaction sent by a client to be delivered to different anycast nodes, effectively making the anycast service unavailable. Whether this affects specific anycast services will depend on how and where anycast nodes are deployed within the routing system, and on where the PPLB is being performed: 1. PPLB across multiple, parallel links between the same pair of routers should cause no node selection problems; 2. PPLB across diverse paths within a single autonomous system (AS), where the paths converge to a single exit as they leave the AS, should cause no node selection problems; 3. PPLB across links to different neighbour ASes where where the neighbour ASes have selected different nodes for a particular anycast destination will, in general, cause request packets to be distributed across multiple anycast nodes. This will have the effect that the anycast service is unavailable to clients downstream of the router performing PPLB. The uses of PPLB which have the potential to interact badly with anycast service distribution can also cause persistent packet reordering. A network path that persistently reorders segments will degrade the performance of traffic carried by TCP [Allman2000]. TCP, according to several documented measurements, accounts for the bulk of traffic carried on the Internet ([McCreary2000], [Fomenkov2004]). Consequently, in many cases it is reasonable to consider networks making such use of PPLB to be pathological. --Apple-Mail-10--1033503470 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-grow-anycast-03.txt" Content-Disposition: attachment; filename=draft-ietf-grow-anycast-03.txt Content-Transfer-Encoding: quoted-printable Network Working Group J. Abley Internet-Draft ISC Expires: April 22, 2006 K. Lindqvist Netnod Internet Exchange October 19, 2005 Operation of Anycast Services draft-ietf-grow-anycast-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of Abley & Lindqvist Expires April 22, 2006 [Page 1] =0C Internet-Draft Anycast BCP October 2005 services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Anycast Service Distribution . . . . . . . . . . . . . . . . . 5 3.1 General Description . . . . . . . . . . . . . . . . . . . 5 3.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Protocol Suitability . . . . . . . . . . . . . . . . . . . 7 4.2 Node Placement . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Routing Systems . . . . . . . . . . . . . . . . . . . . . 8 4.3.1 Anycast within an IGP . . . . . . . . . . . . . . . . 8 4.3.2 Anycast within the Global Internet . . . . . . . . . . 9 4.4 Routing Considerations . . . . . . . . . . . . . . . . . . 9 4.4.1 Signalling Service Availability . . . . . . . . . . . 9 4.4.2 Covering Prefix . . . . . . . . . . . . . . . . . . . 10 4.4.3 Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 10 4.4.4 Route Dampening . . . . . . . . . . . . . . . . . . . 12 4.4.5 Reverse Path Forwarding Checks . . . . . . . . . . . . 13 4.4.6 Propagation Scope . . . . . . . . . . . . . . . . . . 13 4.4.7 Other Peoples' Networks . . . . . . . . . . . . . . . 14 4.4.8 Aggregation Risks . . . . . . . . . . . . . . . . . . 14 4.5 Addressing Considerations . . . . . . . . . . . . . . . . 15 4.6 Data Synchronisation . . . . . . . . . . . . . . . . . . . 15 4.7 Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 16 4.8 Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 16 4.8.1 Multiple Covering Prefixes . . . . . . . . . . . . . . 17 4.8.2 Pessimistic Withdrawal . . . . . . . . . . . . . . . . 17 4.8.3 Intra-Node Interior Connectivity . . . . . . . . . . . 17 5. Service Management . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.1 Denial-of-Service Attack Mitigation . . . . . . . . . . . 20 6.2 Service Compromise . . . . . . . . . . . . . . . . . . . . 20 6.3 Service Hijacking . . . . . . . . . . . . . . . . . . . . 20 7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 10.2 Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 28 Abley & Lindqvist Expires April 22, 2006 [Page 2] =0C Internet-Draft Anycast BCP October 2005 1. Introduction To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes. Various techniques for anycast deployment of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC-TN- 2004-1]. Anycast has in recent years become increasingly popular for adding redundancy to DNS servers to complement the redundancy which the DNS architecture itself already provides. Several root DNS server operators have distributed their servers widely around the Internet, and both resolver and authority servers are commonly distributed within the networks of service providers. Anycast distribution has been used by commercial DNS authority server operators for several years. The use of anycast is not limited to the DNS, although the use of anycast imposes some additional limitations on the nature of the service being distributed, including transaction longevity, transaction state held on servers and data synchronisation capabilities. Although anycast is conceptually simple, its implementation introduces some pitfalls for operation of services. For example, monitoring the availability of the service becomes more difficult; the observed availability changes according to the location of the client within the network, and the client catchment of individual anycast nodes is neither static, nor reliably deterministic. This document will describe the use of anycast for both local scope distribution of services using an Interior Gateway Protocol (IGP) and global distribution using BGP [RFC1771]. Many of the issues for monitoring and data synchronisation are common to both, but deployment issues differ substantially. Abley & Lindqvist Expires April 22, 2006 [Page 3] =0C Internet-Draft Anycast BCP October 2005 2. Terminology Service Address: an IP address associated with a particular service (e.g. the destination address used by DNS resolvers to reach a particular authority server). Anycast: the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations. Anycast Node: an internally-connected collection of hosts and routers which together provide service for an anycast Service Address. An Anycast Node might be as simple as a single host participating in a routing protocol with adjacent routers, or it might include a number of hosts connected in some more elaborate fashion; in either case, to the routing system across which the service is being anycast, each Anycast Node presents a unique path to the Service Address. The entire anycast system for the service consists of two or more separate Anycast Nodes. Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast address. Abley & Lindqvist Expires April 22, 2006 [Page 4] =0C Internet-Draft Anycast BCP October 2005 3. Anycast Service Distribution 3.1 General Description Anycast is the name given to the practice of making a Service Address available to a routing system at Anycast Nodes in two or more discrete locations. The service provided by each node is consistent regardless of the particular node chosen by the routing system to handle a particular request. For services distributed using anycast, there is no inherent requirement for referrals to other servers or name-based service distribution ("round-robin DNS"), although those techniques could be combined with anycast service distribution if an application required it. The routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates. The Anycast Node chosen to service a particular query can be influenced by the traffic engineering capabilities of the routing protocols which make up the routing system. The degree of influence available to the operator of the node depends on the scale of the routing system within which the Service Address is anycast. Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load). Distribution of load between nodes for the purposes of reliability, and coarse-grained distribution of load for the purposes of making popular services scalable can often be achieved, however. The scale of the routing system through which a service is anycast can vary from a small Interior Gateway Protocol (IGP) connecting a small handful of components, to the Border Gateway Protocol (BGP) [RFC1771] connecting the global Internet, depending on the nature of the service distribution that is required. 3.2 Goals A service may be anycast for a variety of reasons. A number of common objectives are: 1. Coarse ("unbalanced") distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks; 2. Mitigation of non-distributed denial of service attacks by localising damage to single anycast nodes; Abley & Lindqvist Expires April 22, 2006 [Page 5] =0C Internet-Draft Anycast BCP October 2005 3. Constraint of distributed denial of service attacks or flash crowds to local regions around anycast nodes (perhaps restricting query traffic to local peering links, rather than paid transit circuits); 4. To provide additional information to help locate location of traffic sources in the case of attack (or query) traffic which incorporates spoofed source addresses. This information is derived from the property of anycast service distribution that the the selection of the Anycast Node used to service a particular query may be related to the topological source of the request. 5. Improvement of query response time, by reducing the network distance between client and server with the provision of a local Anycast Node. The extent to which query response time is improved depends on the way that nodes are selected for the clients by the routing system. Topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases response times may see no reduction, and may increase. 6. To reduce a list of servers to a single, distributed address. For example, a large number of authoritative nameservers for a zone may be deployed using a small set of anycast Service Addresses; this approach can increase the accessibility of zone data in the DNS without increasing the size of a referral response from a nameserver authoritative for the parent zone. Abley & Lindqvist Expires April 22, 2006 [Page 6] =0C Internet-Draft Anycast BCP October 2005 4. Design 4.1 Protocol Suitability When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably. Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply in some cases (e.g. DNS transactions over UDP transport). Other services involve far longer-lived transactions (e.g. bulk file downloads and audio-visual media streaming). Some anycast deployments have very predictable routing systems, which can remain stable for long periods of time (e.g. anycast within an well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7). The stability of the routing system together with the transaction time of the service should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase which is handled by anycast servers, and a sustained phase which is provided by non-anycast servers, perhaps chosen during the initialisation phase. This document deliberately avoids prescribing rules as to which protocols or services are suitable for distribution by anycast; to attempt to do so would be presumptuous. 4.2 Node Placement Decisions as to where Anycast Nodes should be placed will depend to a large extent on the goals of the service distribution. For example: o A DNS recursive resolver service might be distributed within an ISP's network, one Anycast Node per site. o A root DNS server service might be distributed throughout the Internet with nodes located in regions with poor external Abley & Lindqvist Expires April 22, 2006 [Page 7] =0C Internet-Draft Anycast BCP October 2005 connectivity, to ensure that the DNS functions adequately within the region during times of external network failure. o An FTP mirror service might include local nodes located at exchange points, so that ISPs connected to that exchange point could download bulk data more cheaply than if they had to use expensive transit circuits. In general node placement decisions should be made with consideration of likely traffic requirements, the potential for flash crowds or denial-of-service traffic, the stability of the local routing system and the failure modes with respect to node failure, or local routing system failure. 4.3 Routing Systems 4.3.1 Anycast within an IGP There are several common motivations for the distribution of a Service Address within the scope of an IGP: 1. to improve service response times, by hosting a service close to other users of the network; 2. to improve service reliability by providing automatic fail-over to backup nodes; and 3. to keep service traffic local, to avoid congesting wide-area links. In each case the decisions as to where and how services are provisioned can be made by network engineers without requiring such operational complexities as regional variances in the configuration of client computers, or deliberate DNS incoherence (causing DNS queries to yield different answers depending on where the queries originate). When a service is anycast within an IGP the routing system is typically under the control of the same organisation that is providing the service, and hence the relationship between service transaction characteristics and network stability are likely to be well-understood. This technique is consequently applicable to a larger number of applications than Internet-wide anycast service distribution (see Section 4.1). An IGP will generally have no inherent restriction on the length of prefix that can be introduced to it. There may well therefore be no need to construct a covering prefix for particular Service Addresses; Abley & Lindqvist Expires April 22, 2006 [Page 8] =0C Internet-Draft Anycast BCP October 2005 host routes corresponding to the Service Address can instead be introduced to the routing system. See Section 4.4.2 for more discussion of the requirement for a covering prefix. IGPs often feature little or no aggregation of routes, partly due to algorithmic complexities in supporting aggregation. There is little motivation for aggregation in many networks' IGPs in any case, since the amount of routing information carried in the IGP is small enough that scaling concerns in routers do not arise. For discussion of aggregation risks in other routing systems, see Section 4.4.8. By reducing the scope of the IGP to just the hosts providing service (together with one or more gateway routers) this technique can be applied to the construction of server clusters. This application is discussed in some detail in [ISC-TN-2004-1]. 4.3.2 Anycast within the Global Internet Service Addresses may be anycast within the global Internet routing system in order to distribute services across the entire network. The principal differences between this application and the IGP-scope distribution discussed in Section 4.3.1 are that: 1. the routing system is, in general, controlled by other people; 2. the routing protocol concerned (BGP), and commonly-accepted practices in its deployment, impose some additional constraints (see Section 4.4). 4.4 Routing Considerations 4.4.1 Signalling Service Availability When a routing system is provided with reachability information for a Service Address from an individual node, packets addressed to that Service Address will start to arrive at the node. Since it is essential for the node to be ready to accept requests before they start to arrive, a coupling between the routing information and the availability of the service at a particular node is desirable. Where a routing advertisement from a node corresponds to a single Service Address, this coupling might be such that availability of the service triggers the route advertisement, and non-availability of the service triggers a route withdrawal. This can be achieved using routing protocol implementations on the same server which provide the service being distributed, which are configured to advertise and withdraw the route advertisement in conjunction with the availability Abley & Lindqvist Expires April 22, 2006 [Page 9] =0C Internet-Draft Anycast BCP October 2005 (and health) of the software on the host which processes service requests. An example of such an arrangement for a DNS service is included in [ISC-TN-2004-1]. Where a routing advertisement from a node corresponds to two or more Service Addresses, it may not be appropriate to trigger a route withdrawal due to the non-availability of a single service. Another approach is to route requests for the service which is down at one Anycast Node to a different Anycast Node at which the service is up. This approach is discussed in Section 4.8. Rapid advertisement/withdrawal oscillations can cause operational problems, and nodes should be configured such that rapid oscillations are avoided (e.g. by implementing a minimum delay following a withdrawal before the service can be re-advertised). See Section 4.4.4 for a discussion of route oscillations in BGP. 4.4.2 Covering Prefix In some routing systems (e.g. the BGP-based routing system of the global Internet) it is not possible, in general, to propagate a host route with confidence that the route will propagate throughout the network. This is a consequence of operational policy, and not a protocol restriction. In such cases it is necessary to propagate a route which covers the Service Address, and which has a sufficiently short prefix that it will not be discarded by commonly-deployed import policies. For IPv4 Service Addresses, this is often a 24-bit prefix, but there are other well-documented examples of IPv4 import polices which filter on Regional Internet Registry (RIR) allocation boundaries, and hence some experimentation may be prudent. Corresponding import policies for IPv6 prefixes also exist. See Section 4.5 for more discussion of IPv6 Service Addresses and corresponding anycast routes. The propagation of a single route per service has some associated scaling issues which are discussed in Section 4.4.8. Where multiple Service Addresses are covered by the same covering route, there is no longer a tight coupling between the advertisement of that route and the individual services associated with the covered host routes. The resulting impact on signaling availability of individual services is discussed in Section 4.4.1 and Section 4.8. 4.4.3 Equal-Cost Paths Some routing systems support equal-cost paths to the same destination. Where multiple, equal-cost paths exist and lead to Abley & Lindqvist Expires April 22, 2006 [Page 10] =0C Internet-Draft Anycast BCP October 2005 different anycast nodes, there is a risk that different request packets associated with a single transaction might be delivered to more than one node. Services provided over TCP [RFC0793] necessarily involve transactions with multiple request packets, due to the TCP setup handshake. For services which are distributed across the global Internet using BGP, equal-cost paths are normally not a consideration: BGP's exit selection algorithm usually selects a single, consistent exit for a single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however. Equal cost paths are commonly supported in IGPs. Multi-node selection for a single transaction can be avoided in most cases by careful consideration of IGP link metrics, or by applying equal-cost multi-path (ECMP) selection algorithms which cause a single node to be selected for a single multi-packet transaction. For an example of the use of hash-based ECMP selection in anycast service distribution, see [ISC-TN-2004-1]. Other ECMP selection algorithms are commonly available, including those in which packets from the same flow are not guaranteed to be routed towards the same destination. ECMP algorithms which select a route on a per-packet basis rather than per-flow are commonly referred to as performing "Per Packet Load Balancing" (PPLB). With respect to anycast service distribution, some uses of PPLB may cause different packets from a single multi-packet transaction sent by a client to be delivered to different anycast nodes, effectively making the anycast service unavailable. Whether this affects specific anycast services will depend on how and where anycast nodes are deployed within the routing system, and on where the PPLB is being performed: 1. PPLB across multiple, parallel links between the same pair of routers should cause no node selection problems; 2. PPLB across diverse paths within a single autonomous system (AS), where the paths converge to a single exit as they leave the AS, should cause no node selection problems; 3. PPLB across links to different neighbour ASes where where the neighbour ASes have selected different nodes for a particular anycast destination will, in general, cause request packets to be distributed across multiple anycast nodes. This will have the effect that the anycast service is unavailable to clients downstream of the router performing PPLB. Abley & Lindqvist Expires April 22, 2006 [Page 11] =0C Internet-Draft Anycast BCP October 2005 The uses of PPLB which have the potential to interact badly with anycast service distribution can also cause persistent packet reordering. A network path that persistently reorders segments will degrade the performance of traffic carried by TCP [Allman2000]. TCP, according to several documented measurements, accounts for the bulk of traffic carried on the Internet ([McCreary2000], [Fomenkov2004]). Consequently, in many cases it is reasonable to consider networks making such use of PPLB to be pathological. 4.4.4 Route Dampening Frequent advertisements and withdrawals of individual prefixes in BGP are known as flaps. Rapid flapping can lead to CPU exhaustion on routers quite remote from the source of the instability, and for this reason rapid route oscillations are frequently "dampened", as described in [RFC2439]. A dampened path will be suppressed by routers for an interval which increases according to the frequency of the observed oscillation; a suppressed path will not propagate. Hence a single router can prevent the propagation of a flapping prefix to the rest of an autonomous system, affording other routers in the network protection from the instability. Some implementations of flap dampening penalise oscillating advertisements based on the observed AS_PATH, and not on the NLRI. For this reason, network instability which leads to route flapping from a single anycast node ought not to cause advertisements from other nodes (which have different AS_PATH attributes) to be dampened. To limit the opportunity of such implementations to penalise advertisements originating from different Anycast Nodes in response to oscillations from just a single node, care should be taken to arrange that the AS_PATH attributes on routes from different nodes are as diverse as possible. For example, Anycast Nodes should use the same origin AS for their advertisements, but might have different upstream ASs. Where different implementations of flap dampening are prevalent, individual nodes' instability may result in stable nodes becoming unavailable. In mitigation, the following measures may be useful: 1. Judicious deployment of Local Nodes in combination with especially stable Global Nodes (with high inter-AS path splay, redundant hardware, power, etc) may help limit oscillation problems to the Local Nodes' limited regions of influence; Abley & Lindqvist Expires April 22, 2006 [Page 12] =0C Internet-Draft Anycast BCP October 2005 2. Aggressive flap-dampening of the service prefix close to the origin (e.g. within an Anycast Node, or in adjcacent ASes of each Anycast Node) may also help reduce the opportunity of remote ASes to see oscillations at all. 4.4.5 Reverse Path Forwarding Checks Reverse Path Forwarding (RPF) checks, first described in [RFC2267], are commonly deployed as part of ingress interface packet filters on routers in the Internet in order to deny packets whose source addresses are spoofed (see also RFC 2827 [RFC2827]). Deployed implementations of RPF make several modes of operation available (e.g. "loose" and "strict"). Some modes of RPF can cause non-spoofed packets to be denied when they originate from multi-homed site, since selected paths might legitimately not correspond with the ingress interface of non-spoofed packets from the multi-homed site. This issue is discussed in [RFC3704]. A collection of anycast nodes deployed across the Internet is largely indistinguishable from a distributed, multi-homed site to the routing system, and hence this risk also exists for anycast nodes, even if individual nodes are not multi-homed. Care should be taken to ensure that each anycast node is treated as a multi-homed network, and that the corresponding recommendations in [RFC3704] with respect to RPF checks are heeded. 4.4.6 Propagation Scope In the context of Anycast service distribution across the global Internet, Global Nodes are those which are capable of providing service to clients anywhere in the network; reachability information for the service is propagated globally, without restriction, by advertising the routes covering the Service Addresses for global transit to one or more providers. More than one Global Node can exist for a single service (and indeed this is often the case, for reasons of redundancy and load-sharing). In contrast, it is sometimes desirable to deploy an Anycast Node which only provides services to a local catchment of autonomous systems, and which is deliberately not available to the entire Internet; such nodes are referred to in this document as Local Nodes. An example of circumstances in which a Local Node may be appropriate are nodes designed to serve a region with rich internal connectivity but unreliable, congested or expensive access to the rest of the Abley & Lindqvist Expires April 22, 2006 [Page 13] =0C Internet-Draft Anycast BCP October 2005 Internet. Local Nodes advertise covering routes for Service Addresses in such a way that their propagation is restricted. This might be done using well-known community string attributes such as NO_EXPORT [RFC1997] or NOPEER [RFC3765], or by arranging with peers to apply a conventional "peering" import policy instead of a "transit" import policy, or some suitable combination of measures. Advertising reachability to Service Addresses from Local Nodes should ideally be made using a routing policy that require presence of explicit attributes for propagation, rather than reling on implicit (default) policy. Inadvertant propagation of a route beyond its intended horizon can result in capacity problems for Local Nodes which might degrade service performance network-wide. 4.4.7 Other Peoples' Networks When Anycast services are deployed across networks operated by others, their reachability is dependent on routing policies and topology changes (planned and unplanned) which are unpredictable and sometimes difficult to identify. Since the routing system may include networks operated by multiple, unrelated organisations, the possibility of unforeseen interactions resulting from the combinations of unrelated changes also exists. The stability and predictability of such a routing system should be taken into consideration when assessing the suitability of anycast as a distribution strategy for particular services and protocols (see also Section 4.1). By way of mitigation, routing policies used by Anycast Nodes across such routing systems should be conservative, individual nodes' internal and external/connecting infrastructure should be scaled to support loads far in excess of the average, and the service should be monitored proactively from many points in order to avoid unpleasant surprises (see Section 5.1). 4.4.8 Aggregation Risks The propagation of a single route for each anycast service does not scale well for routing systems in which the load of routing information which must be carried is a concern, and where there are potentially many services to distribute. For example, an autonomous system which provides services to the Internet with N Service Addresses covered by a single exported route, would need to advertise (N+1) routes if each of those services were to be distributed using anycast. Abley & Lindqvist Expires April 22, 2006 [Page 14] =0C Internet-Draft Anycast BCP October 2005 The common practice of applying minimum prefix-length filters in import policies on the Internet (see Section 4.4.2) means that for a route covering a Service Address to be usefully propagated the prefix length must be substantially less than that required to advertise just the host route. Widespread advertisement of short prefixes for individual services hence also has a negative impact on address conservation. Both of these issues can be mitigated to some extent by the use of a single covering prefix to accommodate multiple Service Addresses, as described in Section 4.8. This implies a decoupling of the route advertisement from individual service availability (see Section 4.4.1), however, with attendant risks to the stability of the service as a whole (see Section 4.7). In general, the scaling problems described here prevent anycast from being a useful, general approach for service distribution on the global Internet. It remains, however, a useful technique for distributing a limited number of Internet-critical services, as well as in smaller networks where the aggregation concerns discussed here do not apply. 4.5 Addressing Considerations Service Addresses should be unique within the routing system that connects all Anycast Nodes to all possible clients of the service. Service Addresses must also be chosen so that corresponding routes will be allowed to propagate within that routing system. For an IPv4-numbered service deployed across the Internet, for example, an address might be chosen from a block where the minimum RIR allocation size is 24 bits, and reachability to that address might be provided by originating the covering 24-bit prefix. For an IPv4-numbered service deployed within a private network, a locally-unused [RFC1918] address might be chosen, and rechability to that address might be signalled using a (32-bit) host route. For IPv6-numbered services, Anycast Addresses are not scoped differently from unicast addresses. As such the guidelines presented for IPv4 with respect to address suitability follow for IPv6. Note that historical prohibitions on anycast distribution of services over IPv6 have been removed from the IPv6 addressing specification in [I-D.ietf-ipv6-addr-arch-v4]. 4.6 Data Synchronisation Although some services have been deployed in localised form (such Abley & Lindqvist Expires April 22, 2006 [Page 15] =0C Internet-Draft Anycast BCP October 2005 that clients from particular regions are presented with regionally- relevant content) many services have the property that responses to client requests should be consistent, regardless of where the request originates. For a service distributed using anycast, that implies that different Anycast Nodes must operate in a consistent manner and, where that consistent behaviour is based on a data set, that the data concerned be synchronised between nodes. The mechanism by which data is synchronised depends on the nature of the service; examples are zone transfers for authoritative DNS servers and rsync for FTP archives. In general, the synchronisation of data between Anycast Nodes will involve transactions between non- anycast addresses. Data synchronisation across public networks should be carried out with appropriate authentication and encryption. 4.7 Node Autonomy For an Anycast deployment whose goals include improved reliability through redundancy, it is important to minimise the opportunity for a single defect to compromise many (or all) nodes, or for the failure of one node to provide a cascading failure bringing down additional successive nodes until the service as a whole is defeated. Co-dependencies are avoided by making each node as autonomous and self-sufficient as possible. The degree to which nodes can survive failure elsewhere depends on the nature of the service being delivered, but for services which accommodate disconnected operation (e.g. the timed propagation of changes between master and slave servers in the DNS) a high degree of autonomy can be achieved. The possibility of cascading failure due to load can also be reduced by the deployment of both Global and Local Nodes for a single service, since the effective fail-over path of traffic is, in general, from Local Node to Global Node; traffic that might sink one Local Node is unlikely to sink all Local Nodes, except in the most degenerate cases. The chance of cascading failure due to a software defect in an operating system or server can be reduced in many cases by deploying nodes running different implementations of operating system, server software, routing protocol software, etc, such that a defect which appears in a single component does not affect the whole system. 4.8 Multi-Service Nodes For a service distributed across a routing system where covering Abley & Lindqvist Expires April 22, 2006 [Page 16] =0C Internet-Draft Anycast BCP October 2005 prefixes are required to announce reachability to a single Service Address (see Section 4.4.2), special consideration is required in the case where multiple services need to be distributed across a single set of nodes. This results from the requirement to signal availability of individual services to the routing system so that requests for service are not received by nodes which are not able to process them (see Section 4.4.1). Several approaches are described in the following sections. 4.8.1 Multiple Covering Prefixes Each Service Address is chosen such that only one Service Address is covered by each advertised prefix. Advertisement and withdrawal of a single covering prefix can be tightly coupled to the availability of the single associated service. This is the most straightforward approach. However, since it makes very poor utilisation of globally-unique addresses, it is only suitable for use for a small number of critical, infrastructural services such as root DNS servers. General Internet-wide deployment of services using this approach will not scale. 4.8.2 Pessimistic Withdrawal Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawl of the single covering prefix is coupled to the availability of all associated services; if any individual service becomes unavailable, the covering prefix is withdrawn. The coupling between service availability and advertisement of the covering prefix is complicated by the requirement that all Service Addresses must be available -- the announcement needs to be triggered by the presence of all component routes, and not just a single covered route. The fact that a single malfunctioning service causes all deployed services in a node to be taken off-line may make this approach unsuitable for many applications. 4.8.3 Intra-Node Interior Connectivity Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawal of the single covering prefix is coupled to the availability of any one service. Nodes have interior connectivity, e.g. using tunnels, and host routes for service addresses are distributed using an IGP which extends to Abley & Lindqvist Expires April 22, 2006 [Page 17] =0C Internet-Draft Anycast BCP October 2005 include routers at all nodes. In the event that a service is unavailable at one node, but available at other nodes, a request may be routed over the interior network from the receiving node towards some other node for processing. In the event that some local services in a node are down and the node is disconnected from other nodes, continued advertisement of the covering prefix might cause requests to become black-holed. This approach allows reasonable address utilisation of the netblock covered by the announced prefix, at the expense of reduced autonomy of individual nodes; the IGP in which all nodes participate can be viewed as a single point of failure. Abley & Lindqvist Expires April 22, 2006 [Page 18] =0C Internet-Draft Anycast BCP October 2005 5. Service Management 5.1 Monitoring Monitoring a service which is distributed is more complex than monitoring a non-distributed service, since the observed accuracy and availability of the service is, in general, different when viewed from clients attached to different parts of the network. When a problem is identified, it is also not always obvious which node served the request, and hence which node is malfunctioning. It is recommended that distributed services are monitored from probes distributed representatively across the routing system, and, where possible, the identity of the node answering individual requests is recorded along with performance and availability statistics. The RIPE NCC DNSMON service [1] is an example of such monitoring for the DNS. Monitoring the routing system (from a variety of places, in the case of routing systems where perspective is relevant) can also provide useful diagnostics for troubleshooting service availability. This can be achieved using dedicated probes, or public route measurement facilities on the Internet such as the RIPE NCC Routing Information Service [2] and the University of Oregon Route Views Project [3]. Monitoring the health of the component devices in an Anycast deployment of a service (hosts, routers, etc) is straightforward, and can be achieved using the same tools and techniques commonly used to manage other network-connected infrastructure, without the additional complexity involved in monitoring Anycast service addresses. Abley & Lindqvist Expires April 22, 2006 [Page 19] =0C Internet-Draft Anycast BCP October 2005 6. Security Considerations 6.1 Denial-of-Service Attack Mitigation This document describes mechanisms for deploying services on the Internet which can be used to mitigate vulnerability to attack: 1. An Anycast Node can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from having to deal with that traffic; 2. The task of dealing with attack traffic whose sources are widely distributed is itself distributed across all the nodes which contribute to the service. Since the problem of sorting between legitimate and attack traffic is distributed, this may lead to better scaling properties than a service which is not distributed. 6.2 Service Compromise The distribution of a service across several (or many) autonomous nodes imposes increased monitoring as well as an increased systems administration burden on the operator of the service which might reduce the effectiveness of host and router security. The potential benefit of being able to take compromised servers off- line without compromising the service can only be realised if there are working procedures to do so quickly and reliably. 6.3 Service Hijacking It is possible that an unauthorised party might advertise routes corresponding to anycast Service Addresses across a network, and by doing so capture legitimate request traffic or process requests in a manner which compromises the service (or both). A rogue Anycast Node might be difficult to detect by clients or by the operator of the service. The risk of service hijacking by manipulation of the routing sytem exists regardless of whether a service is distributed using anycast. However, the fact that legitimate Anycast Nodes are observable in the routing system may make it more difficult to detect rogue nodes. Abley & Lindqvist Expires April 22, 2006 [Page 20] =0C Internet-Draft Anycast BCP October 2005 7. Protocol Considerations This document does not impose any protocol considerations. Abley & Lindqvist Expires April 22, 2006 [Page 21] =0C Internet-Draft Anycast BCP October 2005 8. IANA Considerations This document requests no action from IANA. Abley & Lindqvist Expires April 22, 2006 [Page 22] =0C Internet-Draft Anycast BCP October 2005 9. Acknowlegements The authors gratefully acknowledge the contributions from various participants of the grow working group, and in particular Geoff Huston, Pekka Savola, Danny McPherson, Ben Black and Alan Barrett. This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC. Abley & Lindqvist Expires April 22, 2006 [Page 23] =0C Internet-Draft Anycast BCP October 2005 10. References 10.1 Normative References [I-D.ietf-ipv6-addr-arch-v4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in progress), May 2005. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 10.2 Informative References [Allman2000] Allman, M. and E. Blanton, "On Making TCP More Robust to Packet Reordering", January 2000, . [Fomenkov2004] Fomenkov, M., Keys, K., Moore, D., and k. claffy, "Longitudinal Study of Internet Traffic from 1999-2003", January 2004, . [ISC-TN-2003-1] Abley, J., "Hierarchical Anycast for Global Service Distribution", March 2003, Abley & Lindqvist Expires April 22, 2006 [Page 24] =0C Internet-Draft Anycast BCP October 2005 . [ISC-TN-2004-1] Abley, J., "A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD", March 2004, . [McCreary2000] McCreary, S. and k. claffy, "Trends in Wide Area IP Traffic Patterns: A View from Ames Internet Exchange", September 2000, . [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998. [RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004. Abley & Lindqvist Expires April 22, 2006 [Page 25] =0C Internet-Draft Anycast BCP October 2005 URIs [1] [2] [3] Authors' Addresses Joe Abley Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 423 1317 Email: jabley@isc.org URI: http://www.isc.org/ Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden Email: kurtis@kurtis.pp.se URI: http://www.netnod.se/ Abley & Lindqvist Expires April 22, 2006 [Page 26] =0C Internet-Draft Anycast BCP October 2005 Appendix A. Change History This section should be removed before publication. draft-kurtis-anycast-bcp-00: Initial draft. Discussed at IETF 61 in the grow meeting and adopted as a working group document shortly afterwards. draft-ietf-grow-anycast-00: Missing and empty sections completed; some structural reorganisation; general wordsmithing. Document discussed at IETF 62. draft-ietf-grow-anycast-01: This appendix added; acknowledgements section added; commentary on RFC3513 prohibition of anycast on hosts removed; minor sentence re-casting and related jiggery- pokery. This revision published for discussion at IETF 63. draft-ietf-grow-anycast-02: Normative reference to [I-D.ietf-ipv6- addr-arch-v4] added (in the RFC editor's queue at the time of writing; reference should be updated to an RFC number when available). draft-ietf-grow-anycast-03: Added commentary on per-packet load balancing. Abley & Lindqvist Expires April 22, 2006 [Page 27] =0C Internet-Draft Anycast BCP October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Abley & Lindqvist Expires April 22, 2006 [Page 28] =0C --Apple-Mail-10--1033503470-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Fri Oct 21 10:05:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxWe-0003RW-3e for grow-archive@megatron.ietf.org; Fri, 21 Oct 2005 10:05:41 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23495 for ; Fri, 21 Oct 2005 10:05:27 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/dEOlAepEjmRdjdBwUrc1VXR5LXp8e4/g@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9LDqpcB013428; Fri, 21 Oct 2005 06:52:51 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9LDqpAj013427; Fri, 21 Oct 2005 06:52:51 -0700 Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9LDqnIx013395 for ; Fri, 21 Oct 2005 06:52:50 -0700 Received: from london-hse-ppp3549810.sympatico.ca ([65.93.41.169] helo=[192.168.2.17]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.54 (FreeBSD)) id 1ESxMJ-000N7E-KM for grow@lists.uoregon.edu; Fri, 21 Oct 2005 13:55:05 +0000 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <0CF3F8C8-F529-4469-99AD-E264118B5F37@isc.org> References: <0CF3F8C8-F529-4469-99AD-E264118B5F37@isc.org> Content-Type: multipart/mixed; boundary=Apple-Mail-10--875782764 Message-Id: From: Joe Abley Subject: draft-ietf-grow-anycast-02 (was Re: grow: draft-ietf-grow-anycast-03) Date: Fri, 21 Oct 2005 09:52:36 -0400 To: grow@lists.uoregon.edu X-Mailer: Apple Mail (2.734) Sender: owner-grow@lists.uoregon.edu Precedence: bulk --Apple-Mail-10--875782764 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 19-Oct-2005, at 14:03, Joe Abley wrote: > I just submitted the attached document; it should appear in the > usual repository in due course. > > The principal changes are in section 4.4.3, the full content of > which can be found below; the rest of the document is substantially > unchanged. > > Feedback would be gratefully received. Turns out I was confused. -02 was never submitted, and so the document I attached a couple of days ago (named -03) was correctly sent back for edits. I have made those changes, and the revised -02 draft I just submitted is attached. The text below is still the only substantial change since the last document discussed in this mailing list. Joe > 4.4.3 Equal-Cost Paths > > Some routing systems support equal-cost paths to the same > destination. Where multiple, equal-cost paths exist and lead to > different anycast nodes, there is a risk that different request > packets associated with a single transaction might be delivered to > more than one node. Services provided over TCP [RFC0793] > necessarily > involve transactions with multiple request packets, due to the TCP > setup handshake. > > For services which are distributed across the global Internet using > BGP, equal-cost paths are normally not a consideration: BGP's exit > selection algorithm usually selects a single, consistent exit for a > single destination regardless of whether multiple candidate paths > exist. Implementations of BGP exist that support multi-path exit > selection, however. > > Equal cost paths are commonly supported in IGPs. Multi-node > selection for a single transaction can be avoided in most cases by > careful consideration of IGP link metrics, or by applying equal- > cost > multi-path (ECMP) selection algorithms which cause a single node to > be selected for a single multi-packet transaction. For an > example of > the use of hash-based ECMP selection in anycast service > distribution, > see [ISC-TN-2004-1]. > > Other ECMP selection algorithms are commonly available, including > those in which packets from the same flow are not guaranteed to be > routed towards the same destination. ECMP algorithms which > select a > route on a per-packet basis rather than per-flow are commonly > referred to as performing "Per Packet Load Balancing" (PPLB). > > With respect to anycast service distribution, some uses of PPLB may > cause different packets from a single multi-packet transaction sent > by a client to be delivered to different anycast nodes, effectively > making the anycast service unavailable. Whether this affects > specific anycast services will depend on how and where anycast > nodes > are deployed within the routing system, and on where the PPLB is > being performed: > > 1. PPLB across multiple, parallel links between the same pair of > routers should cause no node selection problems; > > 2. PPLB across diverse paths within a single autonomous system > (AS), > where the paths converge to a single exit as they leave the AS, > should cause no node selection problems; > > 3. PPLB across links to different neighbour ASes where where the > neighbour ASes have selected different nodes for a particular > anycast destination will, in general, cause request packets > to be > distributed across multiple anycast nodes. This will have the > effect that the anycast service is unavailable to clients > downstream of the router performing PPLB. > > The uses of PPLB which have the potential to interact badly with > anycast service distribution can also cause persistent packet > reordering. A network path that persistently reorders segments > will > degrade the performance of traffic carried by TCP [Allman2000]. > TCP, > according to several documented measurements, accounts for the bulk > of traffic carried on the Internet ([McCreary2000], > [Fomenkov2004]). > Consequently, in many cases it is reasonable to consider networks > making such use of PPLB to be pathological. --Apple-Mail-10--875782764 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-grow-anycast-02.txt" Content-Disposition: attachment; filename=draft-ietf-grow-anycast-02.txt Content-Transfer-Encoding: quoted-printable Network Working Group J. Abley Internet-Draft ISC Expires: April 24, 2006 K. Lindqvist Netnod Internet Exchange October 21, 2005 Operation of Anycast Services draft-ietf-grow-anycast-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of Abley & Lindqvist Expires April 24, 2006 [Page 1] =0C Internet-Draft Anycast BCP October 2005 services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Anycast Service Distribution . . . . . . . . . . . . . . . . . 5 3.1 General Description . . . . . . . . . . . . . . . . . . . 5 3.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Protocol Suitability . . . . . . . . . . . . . . . . . . . 7 4.2 Node Placement . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Routing Systems . . . . . . . . . . . . . . . . . . . . . 8 4.3.1 Anycast within an IGP . . . . . . . . . . . . . . . . 8 4.3.2 Anycast within the Global Internet . . . . . . . . . . 9 4.4 Routing Considerations . . . . . . . . . . . . . . . . . . 9 4.4.1 Signalling Service Availability . . . . . . . . . . . 9 4.4.2 Covering Prefix . . . . . . . . . . . . . . . . . . . 10 4.4.3 Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 10 4.4.4 Route Dampening . . . . . . . . . . . . . . . . . . . 12 4.4.5 Reverse Path Forwarding Checks . . . . . . . . . . . . 13 4.4.6 Propagation Scope . . . . . . . . . . . . . . . . . . 13 4.4.7 Other Peoples' Networks . . . . . . . . . . . . . . . 14 4.4.8 Aggregation Risks . . . . . . . . . . . . . . . . . . 14 4.5 Addressing Considerations . . . . . . . . . . . . . . . . 15 4.6 Data Synchronisation . . . . . . . . . . . . . . . . . . . 15 4.7 Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 16 4.8 Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 16 4.8.1 Multiple Covering Prefixes . . . . . . . . . . . . . . 17 4.8.2 Pessimistic Withdrawal . . . . . . . . . . . . . . . . 17 4.8.3 Intra-Node Interior Connectivity . . . . . . . . . . . 17 5. Service Management . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.1 Denial-of-Service Attack Mitigation . . . . . . . . . . . 20 6.2 Service Compromise . . . . . . . . . . . . . . . . . . . . 20 6.3 Service Hijacking . . . . . . . . . . . . . . . . . . . . 20 7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 10.2 Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 28 Abley & Lindqvist Expires April 24, 2006 [Page 2] =0C Internet-Draft Anycast BCP October 2005 1. Introduction To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes. Various techniques for anycast deployment of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC-TN- 2004-1]. Anycast has in recent years become increasingly popular for adding redundancy to DNS servers to complement the redundancy which the DNS architecture itself already provides. Several root DNS server operators have distributed their servers widely around the Internet, and both resolver and authority servers are commonly distributed within the networks of service providers. Anycast distribution has been used by commercial DNS authority server operators for several years. The use of anycast is not limited to the DNS, although the use of anycast imposes some additional limitations on the nature of the service being distributed, including transaction longevity, transaction state held on servers and data synchronisation capabilities. Although anycast is conceptually simple, its implementation introduces some pitfalls for operation of services. For example, monitoring the availability of the service becomes more difficult; the observed availability changes according to the location of the client within the network, and the client catchment of individual anycast nodes is neither static, nor reliably deterministic. This document will describe the use of anycast for both local scope distribution of services using an Interior Gateway Protocol (IGP) and global distribution using BGP [RFC1771]. Many of the issues for monitoring and data synchronisation are common to both, but deployment issues differ substantially. Abley & Lindqvist Expires April 24, 2006 [Page 3] =0C Internet-Draft Anycast BCP October 2005 2. Terminology Service Address: an IP address associated with a particular service (e.g. the destination address used by DNS resolvers to reach a particular authority server). Anycast: the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations. Anycast Node: an internally-connected collection of hosts and routers which together provide service for an anycast Service Address. An Anycast Node might be as simple as a single host participating in a routing protocol with adjacent routers, or it might include a number of hosts connected in some more elaborate fashion; in either case, to the routing system across which the service is being anycast, each Anycast Node presents a unique path to the Service Address. The entire anycast system for the service consists of two or more separate Anycast Nodes. Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast address. Abley & Lindqvist Expires April 24, 2006 [Page 4] =0C Internet-Draft Anycast BCP October 2005 3. Anycast Service Distribution 3.1 General Description Anycast is the name given to the practice of making a Service Address available to a routing system at Anycast Nodes in two or more discrete locations. The service provided by each node is consistent regardless of the particular node chosen by the routing system to handle a particular request. For services distributed using anycast, there is no inherent requirement for referrals to other servers or name-based service distribution ("round-robin DNS"), although those techniques could be combined with anycast service distribution if an application required it. The routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates. The Anycast Node chosen to service a particular query can be influenced by the traffic engineering capabilities of the routing protocols which make up the routing system. The degree of influence available to the operator of the node depends on the scale of the routing system within which the Service Address is anycast. Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load). Distribution of load between nodes for the purposes of reliability, and coarse-grained distribution of load for the purposes of making popular services scalable can often be achieved, however. The scale of the routing system through which a service is anycast can vary from a small Interior Gateway Protocol (IGP) connecting a small handful of components, to the Border Gateway Protocol (BGP) [RFC1771] connecting the global Internet, depending on the nature of the service distribution that is required. 3.2 Goals A service may be anycast for a variety of reasons. A number of common objectives are: 1. Coarse ("unbalanced") distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks; 2. Mitigation of non-distributed denial of service attacks by localising damage to single anycast nodes; Abley & Lindqvist Expires April 24, 2006 [Page 5] =0C Internet-Draft Anycast BCP October 2005 3. Constraint of distributed denial of service attacks or flash crowds to local regions around anycast nodes (perhaps restricting query traffic to local peering links, rather than paid transit circuits); 4. To provide additional information to help locate location of traffic sources in the case of attack (or query) traffic which incorporates spoofed source addresses. This information is derived from the property of anycast service distribution that the the selection of the Anycast Node used to service a particular query may be related to the topological source of the request. 5. Improvement of query response time, by reducing the network distance between client and server with the provision of a local Anycast Node. The extent to which query response time is improved depends on the way that nodes are selected for the clients by the routing system. Topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases response times may see no reduction, and may increase. 6. To reduce a list of servers to a single, distributed address. For example, a large number of authoritative nameservers for a zone may be deployed using a small set of anycast Service Addresses; this approach can increase the accessibility of zone data in the DNS without increasing the size of a referral response from a nameserver authoritative for the parent zone. Abley & Lindqvist Expires April 24, 2006 [Page 6] =0C Internet-Draft Anycast BCP October 2005 4. Design 4.1 Protocol Suitability When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably. Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply in some cases (e.g. DNS transactions over UDP transport). Other services involve far longer-lived transactions (e.g. bulk file downloads and audio-visual media streaming). Some anycast deployments have very predictable routing systems, which can remain stable for long periods of time (e.g. anycast within an well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7). The stability of the routing system together with the transaction time of the service should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase which is handled by anycast servers, and a sustained phase which is provided by non-anycast servers, perhaps chosen during the initialisation phase. This document deliberately avoids prescribing rules as to which protocols or services are suitable for distribution by anycast; to attempt to do so would be presumptuous. 4.2 Node Placement Decisions as to where Anycast Nodes should be placed will depend to a large extent on the goals of the service distribution. For example: o A DNS recursive resolver service might be distributed within an ISP's network, one Anycast Node per site. o A root DNS server service might be distributed throughout the Internet with nodes located in regions with poor external Abley & Lindqvist Expires April 24, 2006 [Page 7] =0C Internet-Draft Anycast BCP October 2005 connectivity, to ensure that the DNS functions adequately within the region during times of external network failure. o An FTP mirror service might include local nodes located at exchange points, so that ISPs connected to that exchange point could download bulk data more cheaply than if they had to use expensive transit circuits. In general node placement decisions should be made with consideration of likely traffic requirements, the potential for flash crowds or denial-of-service traffic, the stability of the local routing system and the failure modes with respect to node failure, or local routing system failure. 4.3 Routing Systems 4.3.1 Anycast within an IGP There are several common motivations for the distribution of a Service Address within the scope of an IGP: 1. to improve service response times, by hosting a service close to other users of the network; 2. to improve service reliability by providing automatic fail-over to backup nodes; and 3. to keep service traffic local, to avoid congesting wide-area links. In each case the decisions as to where and how services are provisioned can be made by network engineers without requiring such operational complexities as regional variances in the configuration of client computers, or deliberate DNS incoherence (causing DNS queries to yield different answers depending on where the queries originate). When a service is anycast within an IGP the routing system is typically under the control of the same organisation that is providing the service, and hence the relationship between service transaction characteristics and network stability are likely to be well-understood. This technique is consequently applicable to a larger number of applications than Internet-wide anycast service distribution (see Section 4.1). An IGP will generally have no inherent restriction on the length of prefix that can be introduced to it. There may well therefore be no need to construct a covering prefix for particular Service Addresses; Abley & Lindqvist Expires April 24, 2006 [Page 8] =0C Internet-Draft Anycast BCP October 2005 host routes corresponding to the Service Address can instead be introduced to the routing system. See Section 4.4.2 for more discussion of the requirement for a covering prefix. IGPs often feature little or no aggregation of routes, partly due to algorithmic complexities in supporting aggregation. There is little motivation for aggregation in many networks' IGPs in any case, since the amount of routing information carried in the IGP is small enough that scaling concerns in routers do not arise. For discussion of aggregation risks in other routing systems, see Section 4.4.8. By reducing the scope of the IGP to just the hosts providing service (together with one or more gateway routers) this technique can be applied to the construction of server clusters. This application is discussed in some detail in [ISC-TN-2004-1]. 4.3.2 Anycast within the Global Internet Service Addresses may be anycast within the global Internet routing system in order to distribute services across the entire network. The principal differences between this application and the IGP-scope distribution discussed in Section 4.3.1 are that: 1. the routing system is, in general, controlled by other people; 2. the routing protocol concerned (BGP), and commonly-accepted practices in its deployment, impose some additional constraints (see Section 4.4). 4.4 Routing Considerations 4.4.1 Signalling Service Availability When a routing system is provided with reachability information for a Service Address from an individual node, packets addressed to that Service Address will start to arrive at the node. Since it is essential for the node to be ready to accept requests before they start to arrive, a coupling between the routing information and the availability of the service at a particular node is desirable. Where a routing advertisement from a node corresponds to a single Service Address, this coupling might be such that availability of the service triggers the route advertisement, and non-availability of the service triggers a route withdrawal. This can be achieved using routing protocol implementations on the same server which provide the service being distributed, which are configured to advertise and withdraw the route advertisement in conjunction with the availability Abley & Lindqvist Expires April 24, 2006 [Page 9] =0C Internet-Draft Anycast BCP October 2005 (and health) of the software on the host which processes service requests. An example of such an arrangement for a DNS service is included in [ISC-TN-2004-1]. Where a routing advertisement from a node corresponds to two or more Service Addresses, it may not be appropriate to trigger a route withdrawal due to the non-availability of a single service. Another approach is to route requests for the service which is down at one Anycast Node to a different Anycast Node at which the service is up. This approach is discussed in Section 4.8. Rapid advertisement/withdrawal oscillations can cause operational problems, and nodes should be configured such that rapid oscillations are avoided (e.g. by implementing a minimum delay following a withdrawal before the service can be re-advertised). See Section 4.4.4 for a discussion of route oscillations in BGP. 4.4.2 Covering Prefix In some routing systems (e.g. the BGP-based routing system of the global Internet) it is not possible, in general, to propagate a host route with confidence that the route will propagate throughout the network. This is a consequence of operational policy, and not a protocol restriction. In such cases it is necessary to propagate a route which covers the Service Address, and which has a sufficiently short prefix that it will not be discarded by commonly-deployed import policies. For IPv4 Service Addresses, this is often a 24-bit prefix, but there are other well-documented examples of IPv4 import polices which filter on Regional Internet Registry (RIR) allocation boundaries, and hence some experimentation may be prudent. Corresponding import policies for IPv6 prefixes also exist. See Section 4.5 for more discussion of IPv6 Service Addresses and corresponding anycast routes. The propagation of a single route per service has some associated scaling issues which are discussed in Section 4.4.8. Where multiple Service Addresses are covered by the same covering route, there is no longer a tight coupling between the advertisement of that route and the individual services associated with the covered host routes. The resulting impact on signaling availability of individual services is discussed in Section 4.4.1 and Section 4.8. 4.4.3 Equal-Cost Paths Some routing systems support equal-cost paths to the same destination. Where multiple, equal-cost paths exist and lead to Abley & Lindqvist Expires April 24, 2006 [Page 10] =0C Internet-Draft Anycast BCP October 2005 different anycast nodes, there is a risk that different request packets associated with a single transaction might be delivered to more than one node. Services provided over TCP [RFC0793] necessarily involve transactions with multiple request packets, due to the TCP setup handshake. For services which are distributed across the global Internet using BGP, equal-cost paths are normally not a consideration: BGP's exit selection algorithm usually selects a single, consistent exit for a single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however. Equal cost paths are commonly supported in IGPs. Multi-node selection for a single transaction can be avoided in most cases by careful consideration of IGP link metrics, or by applying equal-cost multi-path (ECMP) selection algorithms which cause a single node to be selected for a single multi-packet transaction. For an example of the use of hash-based ECMP selection in anycast service distribution, see [ISC-TN-2004-1]. Other ECMP selection algorithms are commonly available, including those in which packets from the same flow are not guaranteed to be routed towards the same destination. ECMP algorithms which select a route on a per-packet basis rather than per-flow are commonly referred to as performing "Per Packet Load Balancing" (PPLB). With respect to anycast service distribution, some uses of PPLB may cause different packets from a single multi-packet transaction sent by a client to be delivered to different anycast nodes, effectively making the anycast service unavailable. Whether this affects specific anycast services will depend on how and where anycast nodes are deployed within the routing system, and on where the PPLB is being performed: 1. PPLB across multiple, parallel links between the same pair of routers should cause no node selection problems; 2. PPLB across diverse paths within a single autonomous system (AS), where the paths converge to a single exit as they leave the AS, should cause no node selection problems; 3. PPLB across links to different neighbour ASes where where the neighbour ASes have selected different nodes for a particular anycast destination will, in general, cause request packets to be distributed across multiple anycast nodes. This will have the effect that the anycast service is unavailable to clients downstream of the router performing PPLB. Abley & Lindqvist Expires April 24, 2006 [Page 11] =0C Internet-Draft Anycast BCP October 2005 The uses of PPLB which have the potential to interact badly with anycast service distribution can also cause persistent packet reordering. A network path that persistently reorders segments will degrade the performance of traffic carried by TCP [Allman2000]. TCP, according to several documented measurements, accounts for the bulk of traffic carried on the Internet ([McCreary2000], [Fomenkov2004]). Consequently, in many cases it is reasonable to consider networks making such use of PPLB to be pathological. 4.4.4 Route Dampening Frequent advertisements and withdrawals of individual prefixes in BGP are known as flaps. Rapid flapping can lead to CPU exhaustion on routers quite remote from the source of the instability, and for this reason rapid route oscillations are frequently "dampened", as described in [RFC2439]. A dampened path will be suppressed by routers for an interval which increases according to the frequency of the observed oscillation; a suppressed path will not propagate. Hence a single router can prevent the propagation of a flapping prefix to the rest of an autonomous system, affording other routers in the network protection from the instability. Some implementations of flap dampening penalise oscillating advertisements based on the observed AS_PATH, and not on the NLRI. For this reason, network instability which leads to route flapping from a single anycast node ought not to cause advertisements from other nodes (which have different AS_PATH attributes) to be dampened. To limit the opportunity of such implementations to penalise advertisements originating from different Anycast Nodes in response to oscillations from just a single node, care should be taken to arrange that the AS_PATH attributes on routes from different nodes are as diverse as possible. For example, Anycast Nodes should use the same origin AS for their advertisements, but might have different upstream ASs. Where different implementations of flap dampening are prevalent, individual nodes' instability may result in stable nodes becoming unavailable. In mitigation, the following measures may be useful: 1. Judicious deployment of Local Nodes in combination with especially stable Global Nodes (with high inter-AS path splay, redundant hardware, power, etc) may help limit oscillation problems to the Local Nodes' limited regions of influence; Abley & Lindqvist Expires April 24, 2006 [Page 12] =0C Internet-Draft Anycast BCP October 2005 2. Aggressive flap-dampening of the service prefix close to the origin (e.g. within an Anycast Node, or in adjcacent ASes of each Anycast Node) may also help reduce the opportunity of remote ASes to see oscillations at all. 4.4.5 Reverse Path Forwarding Checks Reverse Path Forwarding (RPF) checks, first described in [RFC2267], are commonly deployed as part of ingress interface packet filters on routers in the Internet in order to deny packets whose source addresses are spoofed (see also RFC 2827 [RFC2827]). Deployed implementations of RPF make several modes of operation available (e.g. "loose" and "strict"). Some modes of RPF can cause non-spoofed packets to be denied when they originate from multi-homed site, since selected paths might legitimately not correspond with the ingress interface of non-spoofed packets from the multi-homed site. This issue is discussed in [RFC3704]. A collection of anycast nodes deployed across the Internet is largely indistinguishable from a distributed, multi-homed site to the routing system, and hence this risk also exists for anycast nodes, even if individual nodes are not multi-homed. Care should be taken to ensure that each anycast node is treated as a multi-homed network, and that the corresponding recommendations in [RFC3704] with respect to RPF checks are heeded. 4.4.6 Propagation Scope In the context of Anycast service distribution across the global Internet, Global Nodes are those which are capable of providing service to clients anywhere in the network; reachability information for the service is propagated globally, without restriction, by advertising the routes covering the Service Addresses for global transit to one or more providers. More than one Global Node can exist for a single service (and indeed this is often the case, for reasons of redundancy and load-sharing). In contrast, it is sometimes desirable to deploy an Anycast Node which only provides services to a local catchment of autonomous systems, and which is deliberately not available to the entire Internet; such nodes are referred to in this document as Local Nodes. An example of circumstances in which a Local Node may be appropriate are nodes designed to serve a region with rich internal connectivity but unreliable, congested or expensive access to the rest of the Abley & Lindqvist Expires April 24, 2006 [Page 13] =0C Internet-Draft Anycast BCP October 2005 Internet. Local Nodes advertise covering routes for Service Addresses in such a way that their propagation is restricted. This might be done using well-known community string attributes such as NO_EXPORT [RFC1997] or NOPEER [RFC3765], or by arranging with peers to apply a conventional "peering" import policy instead of a "transit" import policy, or some suitable combination of measures. Advertising reachability to Service Addresses from Local Nodes should ideally be made using a routing policy that require presence of explicit attributes for propagation, rather than reling on implicit (default) policy. Inadvertant propagation of a route beyond its intended horizon can result in capacity problems for Local Nodes which might degrade service performance network-wide. 4.4.7 Other Peoples' Networks When Anycast services are deployed across networks operated by others, their reachability is dependent on routing policies and topology changes (planned and unplanned) which are unpredictable and sometimes difficult to identify. Since the routing system may include networks operated by multiple, unrelated organisations, the possibility of unforeseen interactions resulting from the combinations of unrelated changes also exists. The stability and predictability of such a routing system should be taken into consideration when assessing the suitability of anycast as a distribution strategy for particular services and protocols (see also Section 4.1). By way of mitigation, routing policies used by Anycast Nodes across such routing systems should be conservative, individual nodes' internal and external/connecting infrastructure should be scaled to support loads far in excess of the average, and the service should be monitored proactively from many points in order to avoid unpleasant surprises (see Section 5.1). 4.4.8 Aggregation Risks The propagation of a single route for each anycast service does not scale well for routing systems in which the load of routing information which must be carried is a concern, and where there are potentially many services to distribute. For example, an autonomous system which provides services to the Internet with N Service Addresses covered by a single exported route, would need to advertise (N+1) routes if each of those services were to be distributed using anycast. Abley & Lindqvist Expires April 24, 2006 [Page 14] =0C Internet-Draft Anycast BCP October 2005 The common practice of applying minimum prefix-length filters in import policies on the Internet (see Section 4.4.2) means that for a route covering a Service Address to be usefully propagated the prefix length must be substantially less than that required to advertise just the host route. Widespread advertisement of short prefixes for individual services hence also has a negative impact on address conservation. Both of these issues can be mitigated to some extent by the use of a single covering prefix to accommodate multiple Service Addresses, as described in Section 4.8. This implies a decoupling of the route advertisement from individual service availability (see Section 4.4.1), however, with attendant risks to the stability of the service as a whole (see Section 4.7). In general, the scaling problems described here prevent anycast from being a useful, general approach for service distribution on the global Internet. It remains, however, a useful technique for distributing a limited number of Internet-critical services, as well as in smaller networks where the aggregation concerns discussed here do not apply. 4.5 Addressing Considerations Service Addresses should be unique within the routing system that connects all Anycast Nodes to all possible clients of the service. Service Addresses must also be chosen so that corresponding routes will be allowed to propagate within that routing system. For an IPv4-numbered service deployed across the Internet, for example, an address might be chosen from a block where the minimum RIR allocation size is 24 bits, and reachability to that address might be provided by originating the covering 24-bit prefix. For an IPv4-numbered service deployed within a private network, a locally-unused [RFC1918] address might be chosen, and rechability to that address might be signalled using a (32-bit) host route. For IPv6-numbered services, Anycast Addresses are not scoped differently from unicast addresses. As such the guidelines presented for IPv4 with respect to address suitability follow for IPv6. Note that historical prohibitions on anycast distribution of services over IPv6 have been removed from the IPv6 addressing specification in [I-D.ietf-ipv6-addr-arch-v4]. 4.6 Data Synchronisation Although some services have been deployed in localised form (such Abley & Lindqvist Expires April 24, 2006 [Page 15] =0C Internet-Draft Anycast BCP October 2005 that clients from particular regions are presented with regionally- relevant content) many services have the property that responses to client requests should be consistent, regardless of where the request originates. For a service distributed using anycast, that implies that different Anycast Nodes must operate in a consistent manner and, where that consistent behaviour is based on a data set, that the data concerned be synchronised between nodes. The mechanism by which data is synchronised depends on the nature of the service; examples are zone transfers for authoritative DNS servers and rsync for FTP archives. In general, the synchronisation of data between Anycast Nodes will involve transactions between non- anycast addresses. Data synchronisation across public networks should be carried out with appropriate authentication and encryption. 4.7 Node Autonomy For an Anycast deployment whose goals include improved reliability through redundancy, it is important to minimise the opportunity for a single defect to compromise many (or all) nodes, or for the failure of one node to provide a cascading failure bringing down additional successive nodes until the service as a whole is defeated. Co-dependencies are avoided by making each node as autonomous and self-sufficient as possible. The degree to which nodes can survive failure elsewhere depends on the nature of the service being delivered, but for services which accommodate disconnected operation (e.g. the timed propagation of changes between master and slave servers in the DNS) a high degree of autonomy can be achieved. The possibility of cascading failure due to load can also be reduced by the deployment of both Global and Local Nodes for a single service, since the effective fail-over path of traffic is, in general, from Local Node to Global Node; traffic that might sink one Local Node is unlikely to sink all Local Nodes, except in the most degenerate cases. The chance of cascading failure due to a software defect in an operating system or server can be reduced in many cases by deploying nodes running different implementations of operating system, server software, routing protocol software, etc, such that a defect which appears in a single component does not affect the whole system. 4.8 Multi-Service Nodes For a service distributed across a routing system where covering Abley & Lindqvist Expires April 24, 2006 [Page 16] =0C Internet-Draft Anycast BCP October 2005 prefixes are required to announce reachability to a single Service Address (see Section 4.4.2), special consideration is required in the case where multiple services need to be distributed across a single set of nodes. This results from the requirement to signal availability of individual services to the routing system so that requests for service are not received by nodes which are not able to process them (see Section 4.4.1). Several approaches are described in the following sections. 4.8.1 Multiple Covering Prefixes Each Service Address is chosen such that only one Service Address is covered by each advertised prefix. Advertisement and withdrawal of a single covering prefix can be tightly coupled to the availability of the single associated service. This is the most straightforward approach. However, since it makes very poor utilisation of globally-unique addresses, it is only suitable for use for a small number of critical, infrastructural services such as root DNS servers. General Internet-wide deployment of services using this approach will not scale. 4.8.2 Pessimistic Withdrawal Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawl of the single covering prefix is coupled to the availability of all associated services; if any individual service becomes unavailable, the covering prefix is withdrawn. The coupling between service availability and advertisement of the covering prefix is complicated by the requirement that all Service Addresses must be available -- the announcement needs to be triggered by the presence of all component routes, and not just a single covered route. The fact that a single malfunctioning service causes all deployed services in a node to be taken off-line may make this approach unsuitable for many applications. 4.8.3 Intra-Node Interior Connectivity Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawal of the single covering prefix is coupled to the availability of any one service. Nodes have interior connectivity, e.g. using tunnels, and host routes for service addresses are distributed using an IGP which extends to Abley & Lindqvist Expires April 24, 2006 [Page 17] =0C Internet-Draft Anycast BCP October 2005 include routers at all nodes. In the event that a service is unavailable at one node, but available at other nodes, a request may be routed over the interior network from the receiving node towards some other node for processing. In the event that some local services in a node are down and the node is disconnected from other nodes, continued advertisement of the covering prefix might cause requests to become black-holed. This approach allows reasonable address utilisation of the netblock covered by the announced prefix, at the expense of reduced autonomy of individual nodes; the IGP in which all nodes participate can be viewed as a single point of failure. Abley & Lindqvist Expires April 24, 2006 [Page 18] =0C Internet-Draft Anycast BCP October 2005 5. Service Management 5.1 Monitoring Monitoring a service which is distributed is more complex than monitoring a non-distributed service, since the observed accuracy and availability of the service is, in general, different when viewed from clients attached to different parts of the network. When a problem is identified, it is also not always obvious which node served the request, and hence which node is malfunctioning. It is recommended that distributed services are monitored from probes distributed representatively across the routing system, and, where possible, the identity of the node answering individual requests is recorded along with performance and availability statistics. The RIPE NCC DNSMON service [1] is an example of such monitoring for the DNS. Monitoring the routing system (from a variety of places, in the case of routing systems where perspective is relevant) can also provide useful diagnostics for troubleshooting service availability. This can be achieved using dedicated probes, or public route measurement facilities on the Internet such as the RIPE NCC Routing Information Service [2] and the University of Oregon Route Views Project [3]. Monitoring the health of the component devices in an Anycast deployment of a service (hosts, routers, etc) is straightforward, and can be achieved using the same tools and techniques commonly used to manage other network-connected infrastructure, without the additional complexity involved in monitoring Anycast service addresses. Abley & Lindqvist Expires April 24, 2006 [Page 19] =0C Internet-Draft Anycast BCP October 2005 6. Security Considerations 6.1 Denial-of-Service Attack Mitigation This document describes mechanisms for deploying services on the Internet which can be used to mitigate vulnerability to attack: 1. An Anycast Node can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from having to deal with that traffic; 2. The task of dealing with attack traffic whose sources are widely distributed is itself distributed across all the nodes which contribute to the service. Since the problem of sorting between legitimate and attack traffic is distributed, this may lead to better scaling properties than a service which is not distributed. 6.2 Service Compromise The distribution of a service across several (or many) autonomous nodes imposes increased monitoring as well as an increased systems administration burden on the operator of the service which might reduce the effectiveness of host and router security. The potential benefit of being able to take compromised servers off- line without compromising the service can only be realised if there are working procedures to do so quickly and reliably. 6.3 Service Hijacking It is possible that an unauthorised party might advertise routes corresponding to anycast Service Addresses across a network, and by doing so capture legitimate request traffic or process requests in a manner which compromises the service (or both). A rogue Anycast Node might be difficult to detect by clients or by the operator of the service. The risk of service hijacking by manipulation of the routing sytem exists regardless of whether a service is distributed using anycast. However, the fact that legitimate Anycast Nodes are observable in the routing system may make it more difficult to detect rogue nodes. Abley & Lindqvist Expires April 24, 2006 [Page 20] =0C Internet-Draft Anycast BCP October 2005 7. Protocol Considerations This document does not impose any protocol considerations. Abley & Lindqvist Expires April 24, 2006 [Page 21] =0C Internet-Draft Anycast BCP October 2005 8. IANA Considerations This document requests no action from IANA. Abley & Lindqvist Expires April 24, 2006 [Page 22] =0C Internet-Draft Anycast BCP October 2005 9. Acknowlegements The authors gratefully acknowledge the contributions from various participants of the grow working group, and in particular Geoff Huston, Pekka Savola, Danny McPherson, Ben Black and Alan Barrett. This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC. Abley & Lindqvist Expires April 24, 2006 [Page 23] =0C Internet-Draft Anycast BCP October 2005 10. References 10.1 Normative References [I-D.ietf-ipv6-addr-arch-v4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in progress), May 2005. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 10.2 Informative References [Allman2000] Allman, M. and E. Blanton, "On Making TCP More Robust to Packet Reordering", January 2000, . [Fomenkov2004] Fomenkov, M., Keys, K., Moore, D., and k. claffy, "Longitudinal Study of Internet Traffic from 1999-2003", January 2004, . [ISC-TN-2003-1] Abley, J., "Hierarchical Anycast for Global Service Distribution", March 2003, Abley & Lindqvist Expires April 24, 2006 [Page 24] =0C Internet-Draft Anycast BCP October 2005 . [ISC-TN-2004-1] Abley, J., "A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD", March 2004, . [McCreary2000] McCreary, S. and k. claffy, "Trends in Wide Area IP Traffic Patterns: A View from Ames Internet Exchange", September 2000, . [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998. [RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004. Abley & Lindqvist Expires April 24, 2006 [Page 25] =0C Internet-Draft Anycast BCP October 2005 URIs [1] [2] [3] Authors' Addresses Joe Abley Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 423 1317 Email: jabley@isc.org URI: http://www.isc.org/ Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden Email: kurtis@kurtis.pp.se URI: http://www.netnod.se/ Abley & Lindqvist Expires April 24, 2006 [Page 26] =0C Internet-Draft Anycast BCP October 2005 Appendix A. Change History This section should be removed before publication. draft-kurtis-anycast-bcp-00: Initial draft. Discussed at IETF 61 in the grow meeting and adopted as a working group document shortly afterwards. draft-ietf-grow-anycast-00: Missing and empty sections completed; some structural reorganisation; general wordsmithing. Document discussed at IETF 62. draft-ietf-grow-anycast-01: This appendix added; acknowledgements section added; commentary on RFC3513 prohibition of anycast on hosts removed; minor sentence re-casting and related jiggery- pokery. This revision published for discussion at IETF 63. draft-ietf-grow-anycast-02: Normative reference to [I-D.ietf-ipv6- addr-arch-v4] added (in the RFC editor's queue at the time of writing; reference should be updated to an RFC number when available). Added commentary on per-packet load balancing. Abley & Lindqvist Expires April 24, 2006 [Page 27] =0C Internet-Draft Anycast BCP October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Abley & Lindqvist Expires April 24, 2006 [Page 28] =0C --Apple-Mail-10--875782764 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-10--875782764-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Fri Oct 21 16:00:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET346-00011k-Lu for grow-archive@megatron.ietf.org; Fri, 21 Oct 2005 16:00:34 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03655 for ; Fri, 21 Oct 2005 16:00:22 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX195bPsP01cKlZPXlZCC9wohdTYav3KCbBI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9LJo4cf021696; Fri, 21 Oct 2005 12:50:04 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9LJo4D7021695; Fri, 21 Oct 2005 12:50:04 -0700 Received: from newodin.ietf.org ([132.151.6.50]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9LJo3k8021691 for ; Fri, 21 Oct 2005 12:50:03 -0700 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tv-0001IU-Bm; Fri, 21 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: grow@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: grow: I-D ACTION:draft-ietf-grow-anycast-02.txt Message-Id: Date: Fri, 21 Oct 2005 15:50:03 -0400 Sender: owner-grow@lists.uoregon.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Global Routing Operations Working Group of the IETF. Title : Operation of Anycast Services Author(s) : J. Abley, K. Lindqvist Filename : draft-ietf-grow-anycast-02.txt Pages : 28 Date : 2005-10-21 As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-02.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-grow-anycast-02.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-grow-anycast-02.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: <2005-10-21152929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-grow-anycast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-grow-anycast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21152929.I-D@ietf.org> --OtherAccess-- --NextPart-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Sun Oct 23 08:38:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETf7D-0002QC-TQ for grow-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:38:20 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02425 for ; Sun, 23 Oct 2005 08:38:06 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/0PNthaMaE1GnsR7s6SkELETJZPDEyxUY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9NCOfxC026750; Sun, 23 Oct 2005 05:24:41 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9NCOf9D026749; Sun, 23 Oct 2005 05:24:41 -0700 Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9NCOaB5026726 for ; Sun, 23 Oct 2005 05:24:40 -0700 Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id j9NCO53L079321; Sun, 23 Oct 2005 14:24:05 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 79102; Sun, 23 Oct 2005 14:23:26 +0200 (SAST) X-Authentication-Warning: apb-laptoy.apb.alt.za: apb set sender to apb@cequrux.com using -f Date: Sun, 23 Oct 2005 14:16:24 +0200 From: Alan Barrett To: Joe Abley Cc: grow@lists.uoregon.edu Subject: Re: draft-ietf-grow-anycast-02 (was Re: grow: draft-ietf-grow-anycast-03) Message-ID: <20051023121624.GD28899@apb-laptoy.apb.alt.za> References: <0CF3F8C8-F529-4469-99AD-E264118B5F37@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-grow@lists.uoregon.edu Precedence: bulk On Fri, 21 Oct 2005, Joe Abley wrote: > >The principal changes are in section 4.4.3, the full content of > >which can be found below; the rest of the document is substantially > >unchanged. > > > >Feedback would be gratefully received. The new section 4.4.3 addresses all my concerns. --apb (Alan Barrett) _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Wed Oct 26 19:07:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUuMz-0001df-Cm for grow-archive@megatron.ietf.org; Wed, 26 Oct 2005 19:07:45 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08552 for ; Wed, 26 Oct 2005 19:07:26 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/g1cm7NJqooWhIi/AMnZcLUk+Mg34Kxv0@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9QMo3ru019043; Wed, 26 Oct 2005 15:50:03 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9QMo3Xf019042; Wed, 26 Oct 2005 15:50:03 -0700 Received: from newodin.ietf.org ([132.151.6.50]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9QMo3VY019038 for ; Wed, 26 Oct 2005 15:50:03 -0700 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5q-0005ch-Nt; Wed, 26 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: grow@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: grow: I-D ACTION:draft-ietf-grow-mrt-01.txt Message-Id: Date: Wed, 26 Oct 2005 18:50:02 -0400 Sender: owner-grow@lists.uoregon.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Global Routing Operations Working Group of the IETF. Title : MRT routing information export format Author(s) : L. Blunk, et al. Filename : draft-ietf-grow-mrt-01.txt Pages : 19 Date : 2005-10-26 This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-mrt-01.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-grow-mrt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-grow-mrt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26181149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-grow-mrt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-grow-mrt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26181149.I-D@ietf.org> --OtherAccess-- --NextPart-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Thu Oct 27 15:01:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVD0I-0007rK-7n for grow-archive@megatron.ietf.org; Thu, 27 Oct 2005 15:01:34 -0400 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22793 for ; Thu, 27 Oct 2005 15:01:16 -0400 (EDT) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/gbg2xVewVkm6zkrfBDtJ/PovLspLfp8s@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9RImCr0008119; Thu, 27 Oct 2005 11:48:12 -0700 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9RImCY3008118; Thu, 27 Oct 2005 11:48:12 -0700 Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9RImCQ6008114 for ; Thu, 27 Oct 2005 11:48:12 -0700 Received: from localhost (localhost [127.0.0.1]) by fiji.merit.edu (Postfix) with ESMTP id E521917E5 for ; Thu, 27 Oct 2005 14:48:11 -0400 (EDT) Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by fiji.merit.edu (Postfix) with ESMTP id 94E4B17E0 for ; Thu, 27 Oct 2005 14:48:11 -0400 (EDT) From: "Larry J. Blunk" Reply-To: ljb@merit.edu Organization: Merit Network To: grow@lists.uoregon.edu Subject: grow: draft-ietf-grow-mrt-01.txt Date: Thu, 27 Oct 2005 14:48:08 -0400 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510271448.09013.ljb@merit.edu> X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-grow@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit A new MRT draft is now up. Diffs can be found at -- http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-grow-mrt-00.txt&url2=http://tools.ietf.org/id/draft-ietf-grow-mrt-01.txt This updated draft adds a new OSPF type (OSPF_ET) which includes both OSPFv3 (IPv6) and microsecond time resolution support. This the microsecond support for OSPF was requested by Simon Leinen. The draft also adds a minimal security considerations section and removes a bit extraneous text in the document. One issue I did not address was 32-bit AS numbers. How do people feel about creating a new BGP type to allow these now that the 4byte AS draft is moving forward. -Larry Blunk Merit _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From yasmin@canariastelecom.com Sat Oct 29 00:32:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EViOB-0000pm-Qx; Sat, 29 Oct 2005 00:32:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09499; Sat, 29 Oct 2005 00:32:00 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVibq-0007JT-2q; Sat, 29 Oct 2005 00:46:27 -0400 Received: from [60.48.246.239] (helo=tm.net.my) by mx2.foretec.com with smtp (Exim 4.24) id 1EViNz-0005th-K0; Sat, 29 Oct 2005 00:32:08 -0400 Received: (from tomcat@localhost) by 60.48.246.239 (8.12.8/8.12.8/Submit) id j1CHmn3V518605 for grow-archive@ietf.org; Fri, 28 Oct 2005 23:31:36 -0600 Message-ID: <402d866q.2260329@65.246.255.50> Date: Fri, 28 Oct 2005 23:31:36 -0600 From: "Abigail Blackburn" X-Mailer: MIME-tools 5.496 (Entity 5.812) MIME-Version: 1.0 To: grow-archive@ietf.org X-Spam-Score: (-2.325) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 60.48.246.239 X-Scanned-By: SpamAssassin 3.958903, File::Scan 0.31, Archive::Zip 1.08 X-Recipient: Subject: Re-finance before rates skyrocket Content-Type: multipart/related; boundary="------------AttPart_25537580==.OLA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_25537580==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
and charlotte not ombudsperson the flanders and turntable it's sutton not aspheric may desist the birdbath a diego on ivan a convenient ! epigram may zilch a hamlin Or maybe not

--------------AttPart_25537580==.OLA Content-Type: image/gif; name="reed.3.gif" Content-ID: <5.0.0.78.0.37417641669787.25655503@crumb.yahoo.com.4> Content-Disposition: inline; filename="reed.3.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA40eEfQBBkTGSWToT+/SthHyMzpoXR/+SPwHVCS8obEp97nBNxvm6fvraQPA6bvpDfP +TkqR4RfoGf5nx7Z+zWAU+KqOpGKTmCZFijXPFM5sYcfUA7l+8cBhbAf/dI//dRf/dZPUhEA ADs= --------------AttPart_25537580==.OLA-- From owner-grow@lists.uoregon.edu Sun Oct 30 14:48:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJA2-0004ZM-Gm for grow-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:48:12 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13458 for ; Sun, 30 Oct 2005 14:44:38 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/I2SYb5WQkQruQkYDYX7EBOmPxstq5MFU@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9UHVhMe022219; Sun, 30 Oct 2005 09:31:43 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9UHVhpu022218; Sun, 30 Oct 2005 09:31:43 -0800 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9UHVguH022214 for ; Sun, 30 Oct 2005 09:31:42 -0800 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9UHVWM6031513; Sun, 30 Oct 2005 09:31:32 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9UHVWia031512; Sun, 30 Oct 2005 09:31:32 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 30 Oct 2005 09:31:32 -0800 From: David Meyer To: grow@lists.uoregon.edu Cc: gih@apnic.net Subject: grow: GROW agenda for IETF 64 Message-ID: <20051030173132.GA31498@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. Sender: owner-grow@lists.uoregon.edu Precedence: bulk --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please see both http://www3.ietf.org/proceedings/05nov/agenda/grow.txt =09 and=20 http://www.1-4-5.net/~dmm/IETF/IETF64/grow/agenda Please let us know if you have comments, additions, or deletions.=20 =20 Thanks, =20 Geoff & Dave =20 --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDZQN0ORgD1qCZ2KcRApFGAJkBGgil6eEUTpIXrozGv0wPM7YX/gCfVxNr 89/5fnzWZo98FM05UqisAJc= =cv8b -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Sun Oct 30 14:51:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJA4-0004ZM-Ki for grow-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:48:12 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13507 for ; Sun, 30 Oct 2005 14:44:42 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18jBQiFBP5k4PZvFEeAupFbxImNDky9Gso@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9UGYtro010677; Sun, 30 Oct 2005 08:34:55 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9UGYtV3010676; Sun, 30 Oct 2005 08:34:55 -0800 Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9UGYsVb010642 for ; Sun, 30 Oct 2005 08:34:55 -0800 Received: from gihm3.apnic.net (dhcp18.potaroo.net [203.10.60.18]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id j9UGYhXx087119; Mon, 31 Oct 2005 03:34:45 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051031033123.02db47d8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 31 Oct 2005 03:33:12 +1100 To: Pekka Savola , "Larry J. Blunk" From: Geoff Huston Subject: Re: grow: draft-ietf-grow-mrt-01.txt Cc: grow@lists.uoregon.edu In-Reply-To: References: <200510271448.09013.ljb@merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-grow@lists.uoregon.edu Precedence: bulk I'd suggest add it and ship it - 4 byte AS numbers are not in any doubt and moving a draft on through the process is always (*) better than having it hang around (*) well almost always :-) Geoff At 12:47 AM 31/10/2005, Pekka Savola wrote: >On Thu, 27 Oct 2005, Larry J. Blunk wrote: >> One issue I did not address was 32-bit AS numbers. How do people >> feel about >>creating a new BGP type to allow these now that the 4byte AS draft is >>moving forward. > >It depends on: > - whether the current spec is assumed to document the > implementation(s) out there, or something they should/could be > doing after at some point in the future, > - how mature folks think the current MRT spec is, and > - what's its expected lifetime. > >If it's OK to wait 3..6 months or even longer to make sure 4byte-AS draft >stabilizes first, and there's no hurry to get the spec out, sure.. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >_________________________________________________________________ >web user interface: http://darkwing.uoregon.edu/~llynch/grow.html >web archive: http://darkwing.uoregon.edu/~llynch/grow/ _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Sun Oct 30 15:44:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWK2H-0005yE-BM for grow-archive@megatron.ietf.org; Sun, 30 Oct 2005 15:44:13 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17224 for ; Sun, 30 Oct 2005 15:43:53 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18vTIA+Hng/ZRV8bj4W0NgAdzeFE9j7fr4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9UDm559008698; Sun, 30 Oct 2005 05:48:05 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9UDm5JA008697; Sun, 30 Oct 2005 05:48:05 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9UDm3ng008684 for ; Sun, 30 Oct 2005 05:48:04 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9UDm0r17202; Sun, 30 Oct 2005 15:48:00 +0200 Date: Sun, 30 Oct 2005 15:47:59 +0200 (EET) From: Pekka Savola To: "Larry J. Blunk" cc: grow@lists.uoregon.edu Subject: Re: grow: draft-ietf-grow-mrt-01.txt In-Reply-To: <200510271448.09013.ljb@merit.edu> Message-ID: References: <200510271448.09013.ljb@merit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-grow@lists.uoregon.edu Precedence: bulk On Thu, 27 Oct 2005, Larry J. Blunk wrote: > One issue I did not address was 32-bit AS numbers. How do people feel about > creating a new BGP type to allow these now that the 4byte AS draft is moving forward. It depends on: - whether the current spec is assumed to document the implementation(s) out there, or something they should/could be doing after at some point in the future, - how mature folks think the current MRT spec is, and - what's its expected lifetime. If it's OK to wait 3..6 months or even longer to make sure 4byte-AS draft stabilizes first, and there's no hurry to get the spec out, sure.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From owner-grow@lists.uoregon.edu Sun Oct 30 16:29:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWKkR-0004FK-DF for grow-archive@megatron.ietf.org; Sun, 30 Oct 2005 16:29:51 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19263 for ; Sun, 30 Oct 2005 16:29:31 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+y7Lq9tshPDM7V++EAh6wQESTD/ZGXLMg@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9ULHODI003399; Sun, 30 Oct 2005 13:17:24 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9ULHOAX003398; Sun, 30 Oct 2005 13:17:24 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9ULHNPw003394 for ; Sun, 30 Oct 2005 13:17:23 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9ULHCp25644; Sun, 30 Oct 2005 23:17:13 +0200 Date: Sun, 30 Oct 2005 23:17:12 +0200 (EET) From: Pekka Savola To: Geoff Huston cc: "Larry J. Blunk" , grow@lists.uoregon.edu Subject: Re: grow: draft-ietf-grow-mrt-01.txt In-Reply-To: <6.2.0.14.2.20051031033123.02db47d8@kahuna.telstra.net> Message-ID: References: <200510271448.09013.ljb@merit.edu> <6.2.0.14.2.20051031033123.02db47d8@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-grow@lists.uoregon.edu Precedence: bulk On Mon, 31 Oct 2005, Geoff Huston wrote: > I'd suggest add it and ship it - 4 byte AS numbers are not in any doubt and > moving a draft on through the process is always (*) better than having it > hang > around While I don't doubt 4 byte AS numbers is going to go through in some form, it is not 100% certain whether there won't be changes (such as a different way to encode the numbers in the attributes) which might require different approach in MRT format. The MRT draft may or may not have sufficient abstraction that this is not a problem (I haven't looked at the draft). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ From jim.sytsma@altec.com Mon Oct 31 03:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUiI-0008O2-Ge; Mon, 31 Oct 2005 03:08:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19340; Mon, 31 Oct 2005 03:07:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWUwP-0005NJ-SS; Mon, 31 Oct 2005 03:22:55 -0500 Received: from c-24-10-47-189.hsd1.ca.comcast.net ([24.10.47.189]) by mx2.foretec.com with smtp (Exim 4.24) id 1EWUiB-0004pH-AO; Mon, 31 Oct 2005 03:08:11 -0500 Received: by 10.11.98.7 with HTTP; Mon, 31 Oct 2005 02:07:56 -0600 Message-ID: <364m800o.6981882@hotmail.com> Date: Mon, 31 Oct 2005 02:07:56 -0600 From: "Noemi Vera" User-Agent: Apple Mail (2.728) X-PGP-Key: dv3Dw7xA46LYhgPTQUNauDlnTR5PLM5ymVh7Y1rbCKSxPAR9jloepq1CtdTl7t4h== X-Load: 60% MIME-Version: 1.0 To: geopriv-admin@ietf.org Cc: geopriv-web-archive@ietf.org, gga8k2ijd9ai7232@ietf.org, ghostsender-a.3feet.com@ietf.org, grow-archive@ietf.org, gsmp@ietf.org, gsmp-admin@ietf.org, gsmp-archive@ietf.org, gsmp-web-archive@ietf.org, haley.bledsoe@ietf.org, hive@ietf.org Subject: Pre-approved Application #IQUAYZJ85783 Content-Type: multipart/related; boundary="------------AttPart_40735025==.OLA" X-Spam-Score: 1.9 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_40735025==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
may evocable or delta some screw try emcee see nectary in conduce the corps in creamery or jab it's aberrant try creche not brazier may argo , diesel Or maybe not

--------------AttPart_40735025==.OLA Content-Type: image/gif; name="bloke.5.gif" Content-ID: <9.0.0.26.0.51429080563765.58373526@leaf.msn.com.5> Content-Disposition: inline; filename="bloke.5.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTFQZdO46NqPDROeHJXlLdFa0k1ZeM5vrYhr3wznOcp4znets5zvj Oc963jOf++znPwM60IIeNKK0BvhDIzrRiLlTRxvt6EcGQzrShAwBADs= --------------AttPart_40735025==.OLA--