Message

From owner-ietf-openproxy@mail.imc.org Fri Apr 2 10:45:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14798 for ; Fri, 2 Apr 2004 10:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Qrl-0001Zu-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:45:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Qqs-0001T0-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:45:03 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9QqO-0001M8-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:44:32 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FNrv9082642; Fri, 2 Apr 2004 07:23:53 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32FNr6O082641; Fri, 2 Apr 2004 07:23:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FNq5g082634 for ; Fri, 2 Apr 2004 07:23:52 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i32FNkS09981; Fri, 2 Apr 2004 10:23:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 10:23:47 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: Do we know the RFC number for the arch document? Date: Fri, 2 Apr 2004 10:23:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C418C6.7DAE9562" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C418C6.7DAE9562 Content-Type: text/plain Hi, Do we know the RFC number for the arch. draft. If there is no number yet, how can I reference it in the authorization draft. Thanks Abbie ------_=_NextPart_001_01C418C6.7DAE9562 Content-Type: text/html Message

Hi,

Do we know the RFC number for the arch. draft.

If there is no number yet, how can I reference it in the authorization draft.

Thanks

Abbie

------_=_NextPart_001_01C418C6.7DAE9562-- From owner-ietf-openproxy@mail.imc.org Fri Apr 2 10:48:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14917 for ; Fri, 2 Apr 2004 10:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Qtl-0001q0-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Qst-0001j1-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:47:08 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9QsN-0001bR-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:46:35 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FZ2MK083247; Fri, 2 Apr 2004 07:35:02 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32FZ23N083246; Fri, 2 Apr 2004 07:35:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FZ2sx083224 for ; Fri, 2 Apr 2004 07:35:02 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.86]) by comcast.net (rwcrmhc13) with ESMTP id <200404021534590150087faoe> (Authid: biena2004); Fri, 2 Apr 2004 15:34:59 +0000 Message-ID: <406D8826.9060700@mhof.com> Date: Fri, 02 Apr 2004 10:35:02 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Do we know the RFC number for the arch document? References: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Abbie, > Do we know the RFC number for the arch. draft. No, since it's still in the RFC editor queue. > If there is no number yet, how can I reference it in the authorization > draft. I'd assume you can simply put in a placeholder, which will then be corrected once the RFC number is out. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Apr 2 10:55:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15112 for ; Fri, 2 Apr 2004 10:55:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9R0f-0002om-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Qzi-0002eF-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:54:11 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9Qyk-0002VB-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 10:53:10 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FiaYD083660; Fri, 2 Apr 2004 07:44:36 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32FiaJf083659; Fri, 2 Apr 2004 07:44:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FiZro083653 for ; Fri, 2 Apr 2004 07:44:36 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i32FiDS12870; Fri, 2 Apr 2004 10:44:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 10:44:13 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754090A7386@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Marshall Rose Cc: Markus Hofmann , OPES Group Subject: RE: Do we know the RFC number for the arch document? Date: Fri, 2 Apr 2004 10:44:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C418C9.58171F60" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C418C9.58171F60 Content-Type: text/plain will do abbie > -----Original Message----- > From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] > Sent: Friday, April 02, 2004 10:41 AM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: Markus Hofmann; OPES Group > Subject: Re: Do we know the RFC number for the arch document? > > > > Hi, > > > > Do we know the RFC number for the arch. draft. > > > > If there is no number yet, how can I reference it in the > authorization > > draft. > > just refer to the I-D that was approved by the IESG. > > /mtr > ------_=_NextPart_001_01C418C9.58171F60 Content-Type: text/html RE: Do we know the RFC number for the arch document?

will do

abbie

> -----Original Message-----
> From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us]
> Sent: Friday, April 02, 2004 10:41 AM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: Markus Hofmann; OPES Group
> Subject: Re: Do we know the RFC number for the arch document?
>
>
> > Hi,
> >
> > Do we know the RFC number for the arch. draft.
> >
> > If there is no number yet, how can I reference it in the
> authorization
> > draft.
>
> just refer to the I-D that was approved by the IESG.
>
> /mtr
>

------_=_NextPart_001_01C418C9.58171F60-- From owner-ietf-openproxy@mail.imc.org Fri Apr 2 11:12:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16513 for ; Fri, 2 Apr 2004 11:12:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RHw-00062L-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:13:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RGz-0005uR-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:12:02 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9RG4-0005n7-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:11:04 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FfiUX083535; Fri, 2 Apr 2004 07:41:44 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32FfiJ3083534; Fri, 2 Apr 2004 07:41:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([209.75.253.179]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FfhDO083517 for ; Fri, 2 Apr 2004 07:41:43 -0800 (PST) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id i32FeZI7001111; Fri, 2 Apr 2004 07:40:35 -0800 (PST) Date: Fri, 2 Apr 2004 07:40:35 -0800 From: Marshall Rose To: "Abbie Barbir" Cc: Markus Hofmann , OPES Group Subject: Re: Do we know the RFC number for the arch document? Message-Id: <20040402074035.08987e1d.mrose@dbc.mtview.ca.us> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> References: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > Hi, > > Do we know the RFC number for the arch. draft. > > If there is no number yet, how can I reference it in the authorization > draft. just refer to the I-D that was approved by the IESG. /mtr From owner-ietf-openproxy@mail.imc.org Fri Apr 2 11:30:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17114 for ; Fri, 2 Apr 2004 11:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RYW-0000au-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:30:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RXg-0000TA-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:29:17 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9RXA-0000K9-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:28:44 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32G7ABA085190; Fri, 2 Apr 2004 08:07:10 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32G7ANA085189; Fri, 2 Apr 2004 08:07:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32G79tR085180 for ; Fri, 2 Apr 2004 08:07:09 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.86]) by comcast.net (rwcrmhc11) with ESMTP id <200404021607060130027ss6e> (Authid: biena2004); Fri, 2 Apr 2004 16:07:07 +0000 Message-ID: <406D8FAD.9010302@mhof.com> Date: Fri, 02 Apr 2004 11:07:09 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Do we know the RFC number for the arch document? References: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> <406D8826.9060700@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: >>I'd assume you can simply put in a placeholder, which will then be >>corrected once the RFC number is out. > > > Shouldn't we continue to use ID names to increase the chances of RFC > Editor replacing them with _correct_ RFC numbers? I've seen either way in the past. But as Marshal also recommended to stick with the ID, let's do that. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Apr 2 11:33:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17186 for ; Fri, 2 Apr 2004 11:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RcG-000158-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:34:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RbM-0000xK-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:33:05 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9RaW-0000qJ-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 11:32:12 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32G1GNP084972; Fri, 2 Apr 2004 08:01:16 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32G1GBM084971; Fri, 2 Apr 2004 08:01:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32G1De6084958 for ; Fri, 2 Apr 2004 08:01:15 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i32G1CuH019603; Fri, 2 Apr 2004 09:01:15 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i32G1CAU019602; Fri, 2 Apr 2004 09:01:12 -0700 (MST) (envelope-from rousskov) Date: Fri, 2 Apr 2004 09:01:12 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Do we know the RFC number for the arch document? In-Reply-To: <406D8826.9060700@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754090A7326@zcard0k6.ca.nortel.com> <406D8826.9060700@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 2 Apr 2004, Markus Hofmann wrote: > I'd assume you can simply put in a placeholder, which will then be > corrected once the RFC number is out. Shouldn't we continue to use ID names to increase the chances of RFC Editor replacing them with _correct_ RFC numbers? Alex. From owner-ietf-openproxy@mail.imc.org Fri Apr 2 14:38:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23871 for ; Fri, 2 Apr 2004 14:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UUV-0002kw-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 14:38:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UTb-0002bL-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 14:37:19 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B9USh-0002Sy-00 for opes-archive@ietf.org; Fri, 02 Apr 2004 14:36:19 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32J306I097092; Fri, 2 Apr 2004 11:03:00 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32J3026097091; Fri, 2 Apr 2004 11:03:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32J309G097082 for ; Fri, 2 Apr 2004 11:03:00 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i32J2vS00774 for ; Fri, 2 Apr 2004 14:02:57 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 14:02:57 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754090A7653@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Subject: FW: New authorization draft: draft-ietf-opes-authorization-03 Date: Fri, 2 Apr 2004 14:02:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C418E5.1A612CD0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,LINES_OF_YELLING autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C418E5.1A612CD0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C418E5.1A612CD0" ------_=_NextPart_001_01C418E5.1A612CD0 Content-Type: text/plain -----Original Message----- From: Barbir, Abbie [CAR:1A11:EXCH] Sent: Friday, April 02, 2004 11:24 AM To: Markus Hofmann; OPES Group Cc: 'Marshall Rose' Subject: New authorization draft: draft-ietf-opes-authorization-03 All, Attached is the -03 of the authorization draft. I have added a terminology and security sections + fixed MUST etc.. . Please review so we can re-submit to the IETF. Abbie ------_=_NextPart_001_01C418E5.1A612CD0 Content-Type: text/html Message

-----Original Message-----
From: Barbir, Abbie [CAR:1A11:EXCH]
Sent: Friday, April 02, 2004 11:24 AM
To: Markus Hofmann; OPES Group
Cc: 'Marshall Rose'
Subject: New authorization draft: draft-ietf-opes-authorization-03

All,

Attached is the -03 of the authorization draft.

I have added a terminology and security sections + fixed MUST etc.. .

Please review so we can re-submit to the IETF.

Abbie

------_=_NextPart_001_01C418E5.1A612CD0-- ------_=_NextPart_000_01C418E5.1A612CD0 Content-Type: text/plain; name="draft-ietf-opes-authorization-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-authorization-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: October 1, 2004 O. = Batuner = Consultant A. = Beck Lucent = Technologies T. = Chan = Nokia H. = Orman Purple Streak = Development April 2, = 2004 Policy, Authorization and Enforcement Requirements of OPES draft-ietf-opes-authorization-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 1, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a given OPES flow. Barbir, et al. Expires October 1, 2004 [Page = 1] =0C Internet-Draft Policy Requirements April = 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Policy Architecture . . . . . . . . . . . . . . . . . . . . = 5 3.1 Policy Components and Functions . . . . . . . . . . . . . . = 5 3.2 Requirements For Policy Decision Point . . . . . . . . . . . = 6 3.3 Requirements for Policy Enforcement Points . . . . . . . . . = 6 4. Requirements for Interfaces . . . . . . . . . . . . . . . . = 8 4.1 Service Bindings Requirements . . . . . . . . . . . . . . . = 8 4.1.1 Environment Variables . . . . . . . . . . . . . . . . . . . = 8 4.1.2 Requirements for Using State Information . . . . . . . . . . = 9 4.1.3 Requirements for Passing Information Between Services . . . = 9 4.2 Requirements for Rule and Rules Management . . . . . . . . . = 9 4.2.1 Requirements for Rule Providers . . . . . . . . . . . . . . = 9 4.2.2 Requirements for Rule Formats and Protocols . . . . . . . . = 10 4.2.3 Requirements for Rule Conditions . . . . . . . . . . . . . . = 10 4.2.4 Requirements for Rule Actions . . . . . . . . . . . . . . . = 10 4.3 Requirements for Policy Expression . . . . . . . . . . . . . = 11 5. Authentication of Principals and Authorization of Services . . . . . . . . . . . . . . . . . . . . . . . . . . = 12 5.1 End users, Publishers and Other Considerations . . . . . . . = 12 5.1.1 Considerations for end users . . . . . . . . . . . . . . . . = 12 5.1.2 Considerations for publishing sites . . . . . . . . . . . . = 13 5.1.3 Other considerations . . . . . . . . . . . . . . . . . . . . = 13 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . = 13 5.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . = 14 5.4 Integrity and Encryption . . . . . . . . . . . . . . . . . . = 15 5.4.1 Integrity and confidentiality of authentication and requests/responses for service . . . . . . . . . . . . . . . = 15 5.4.2 Integrity and confidentiality of application content . . . . = 15 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . = 16 6. Security Considerations . . . . . . . . . . . . . . . . . . = 17 Normative References . . . . . . . . . . . . . . . . . . . . = 18 Informative References . . . . . . . . . . . . . . . . . . . = 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 21 Intellectual Property and Copyright Statements . . . . . . . = 22 Barbir, et al. Expires October 1, 2004 [Page = 2] =0C Internet-Draft Policy Requirements April = 2004 1. Introduction The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. The execution of such services is governed by a set of rules installed on OPES processor. The rule evaluation can trigger the execution of service applications local to the OPES processor or on = a remote callout server. Policies express the goals of an OPES processor as a set of rules used to administer, manage and control access to resources. The requirements in this document govern the behavior of OPES entities = in determining which, if any, of available services are to be applied = to a given message. The scope of OPES policies described in this document are limited to those that describe which services to call and, if appropriate, with what parameters. These policies do not include those that prescribe the behavior of the called services. It is desirable to enable a common management framework for specifying policies for both the calling of and the behavior of a service. The integration of such function is the domain of policy administration user interaction applications. The document is organized as follows:Section 2 considers policy framework. Section 3 discusses requirements for interfaces, while section 4 examines authentication of principals and authorization of services. Barbir, et al. Expires October 1, 2004 [Page = 3] =0C Internet-Draft Policy Requirements April = 2004 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. Barbir, et al. Expires October 1, 2004 [Page = 4] =0C Internet-Draft Policy Requirements April = 2004 3. Policy Architecture This section describes the architectural policy decomposition requirements. It also describes the requirements for the interfaces between the policy components. 3.1 Policy Components and Functions The policy functions are decomposed into three components: a Rule Author, a Policy Decision Point (PDP) and Policy Enforcement Point (PEP). The Rule Author provides the rules to be used by an OPES entity. These rules control the invocation of services on behalf of the rule author. The PDP and the PEP interpret the collected rules and appropriately enforce them. The decomposition is illustrated in Figure 1. +--------+ +--------+ | Rule | | Rule | | Author | ... | Author | +--------+ +--------+ | | | | | +----------+ | | | Policy | | <- PDP Interface +--------->| Decision |<----------+ | Point | +----------+ | ^ | | | | <- PEP Interface | | V | +--------------+ ... ---> | Policy | ---> | Enforcement | Data Traffic <--- | Point | <--- +--------------+ Figure 1: Policy Components The decomposition of policy control into a PDP and a PEP permit the offloading of some tasks to an administrative service that may be located on a separate server from the real-time enforcement services Barbir, et al. Expires October 1, 2004 [Page = 5] =0C Internet-Draft Policy Requirements April = 2004 of the PEP that reside on the OPES processor. The PDP provides for the authentication and authorization of rule authors and the validation and compilation of rules. The PEP resides in the data filter where the data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed. Interfaces between these architectural components are points of interoperability. The interface between rule authors and the policy decision points (PDP Interface) MUST use the standard format that = may result from the requirements as described in this document. The interface between the policy decision points and the policy enforcement points (PEP Interface) can be internal to a specific vendor implementation of an OPES processor. Implementations MUST use standard interface only if the PDP and the PEP reside on different OPES processor. 3.2 Requirements For Policy Decision Point The Policy Decision Point is essentially a policy compiler. The PDP MUST be a service that provides administrative support to the enforcement points. The PDP service MUST authenticate the rule authors. The PDP MUST verify that the specified rules are within the scope of the rule authors authority. The PDP MUST be a component of the OPES Administration Authority. 3.3 Requirements for Policy Enforcement Points In the OPES architecture, the data filter represents a Policy Enforcement point (PEP). At this point, data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed. In the PEP rules MAY chain actions together, where, a series of services to be called are specified. Implementation MUST ensure the passing of information from one called service to another. Implementation MUST not prohibit the re-evaluation of a message to determine if another service or set of services should be called. The execution of an action (i.e., the triggering of a rule) may lead to the modification of a message property values. For example, an OPES service that under some circumstances converts JPEG images to GIF images modifies the content type of the requested web object. Barbir, et al. Expires October 1, 2004 [Page = 6] =0C Internet-Draft Policy Requirements April = 2004 Such modification of message property values may change the behavior of subsequently performed OPES actions. The data filter SHOULD act = on matched rules before it evaluates subsequent rules. Multiple = matched rules can be triggered simultaneously if the data filter can determine in advance that there are no side effects from the execution of any specific rule. A data filter MAY evaluate messages several times in the course of handling an OPES flow. The rule processing points MAY be defined by administratively defined names. The definition of such names can serve as a selector for policy rules to determine the applicability of a rule or a set of rules at each processing point. The scope of policy control of policy roles as defined RFC 3060 SHOULD be used where it aids in the development of the OPES policy model. In Figure 2 a typical message data flow between a data consumer application, an OPES processor and a data provider application. = There are four commonly used processing points identified by the numbers 1 through 4. +--------+ +-----------+ +---------+ | |<------|4 3|<------| | | Data | | OPES | | Data | |Consumer| | Processor | |Provider | | Appl. |------>|1 2|------>| Appl. | +--------+ +-----------+ +---------+ Figure 2: Processing Execution Points Any data filter (PEP) or any administrative (PDP) implementation = MUST support the four rule processing points. o Data Consumer Request Handling Role : This involves request processing when received from a Data Consumer Application. o OPES Processor Request handling role: This involves request processing before forwarding to Data Provider Application. o Data Provider Response handling role: This involves response processing when forwarding to Data Consumer Application. o OPES Processor Response handling role:This involves response processing when forwarding to Data Consumer Application. Barbir, et al. Expires October 1, 2004 [Page = 7] =0C Internet-Draft Policy Requirements April = 2004 4. Requirements for Interfaces The interface between the policy system and OPES services needs to include the ability to pass system state information as well as the subject message. 4.1 Service Bindings Requirements The invoked OPES services MUST be able to be specified in a location independent fashion. That is, the rule authors need not know and = need not specify the instance of an OPES service in the rules. The rule author SHOULD be able to identify the required service at the detail level that is appropriate for his or her needs. The rule author SHOULD be able to specify a type of service or be able to specify any service that fits a general category of service to be applied its traffic. The binding of OPES service names to specific service MAY be distributed between the PDP and the PEP. As rules are compiled and validated by the PDP, they MUST be resolved to a specific installations' set of homogeneous OPES service. The selection of a specific instance MAY be postponed and left to = PEP to select at either rule installation time or at run time. To = achieve interoperability, PEP MUST support resolving a generic name to a specific instance. It is possible to use services such as SLP or = UDDI to resolve generic service names to specific OPES service instances. The policy system MAY support dynamic discovery of service bindings. The rule author, MAY not know specific service bindings such as protocol and parameters, when a rule (as specified on the PDP Interface) is general in nature. The required binding information MUST be provided by the PDP and conveyed on the PEP Interface. A service description methodology such as WSDL MUST be present in the policy system. It is to be determined whether an OPES standard is required. 4.1.1 Environment Variables There may be a need to define and support means for maintaining = state information that can be used in both condition evaluation and action execution. Depending on the execution environment, OPES services MAY have the freedom to define variables that are needed and use these variables to further define their service behavior without the = data filter support. Barbir, et al. Expires October 1, 2004 [Page = 8] =0C Internet-Draft Policy Requirements April = 2004 4.1.2 Requirements for Using State Information Policy rules MAY specify that state information be used as part of the evaluation of the rules against a given message in an OPES flow. Thus, the policy system SHOULD support the maintenance of groups = that can be used in evaluating rule conditions. Membership in such = groups can be used as action triggers. For example, an authorized site blocking service might conclude that a particular user shouldn't be permitted access to a certain web site. Rather than calling the service for each request sent by such = a user, a rule might be created that determine if user is a member of blocked users and requested site is a member of blocked-sites then invoke a local blocking service to return and return an appropriate message to the user. 4.1.3 Requirements for Passing Information Between Services Environment variables can be used to pass state information between services. For example, analysis of the request or modifications to the request MAY need to be captured as state information that can be passed to other services on the request path or to services on the response(s) associated with that request. In the PEP, there SHOULD be provisions to enable setting up = variables when returning from a service call and passing variables to other called services based on policy. 4.2 Requirements for Rule and Rules Management This section provides the requirements for rule management. The = rules are divided into two groups. Some rules are provided by the data consumer application and other rules are provided by the data provider application. 4.2.1 Requirements for Rule Providers The requirements for rule providers are: o Rule providers MUST be authenticated and authorized for rules = that apply to their network role. o Rule providers MUST NOT be able to specify rules that are NOT within their scope of authority. o Rule providers SHOULD be able to specify only what is needed for their services. Barbir, et al. Expires October 1, 2004 [Page = 9] =0C Internet-Draft Policy Requirements April = 2004 o Compilation of rules from different sources MUST NOT lead to execution of conflicting rules. o The resolution of such rule conflicts is out of scope o Rules are assumed to be static and applied to current network state. 4.2.2 Requirements for Rule Formats and Protocols It is desirable to choose standard technologies like XML to specify the rule language format. Rules need to be sent form the rule authors to the OPES administrative server for service authorization, rule validation and compilation. The mechanisms for doing that are out of scope of the current work. Once the rules are authorized, validated and compiled by the administrative server, the rules need to be sent to the OPES processor. The mechanisms for doing that are out of scope of the current work. 4.2.3 Requirements for Rule Conditions Rule conditions MUST be matched against attribute values of the encapsulated protocol as well as environment variable values. Attribute values of the encapsulated protocol include protocol = header values and possibly also protocol body values. Some OPES services MAY need to be invoked for all users requests or server responses, services with logging functionality, as an = example. The rule system SHOULD allow unconditional rules rather than requiring rule authors to specify rule conditions that are always true. 4.2.4 Requirements for Rule Actions The rule system MUST allow for the specification of rule actions = that are triggered if the conditions of a rule are met. Matched rules typically lead to the invocation of local or remote services. Rule actions MUST identify the OPES service that is to be executed for = the current message request or response. Rule actions MAY contain run-time parameters which can be used to control the behavior of an OPES service. If specified, these parameters MUST be passed to the executed OPES service. Barbir, et al. Expires October 1, 2004 [Page = 10] =0C Internet-Draft Policy Requirements April = 2004 4.3 Requirements for Policy Expression OPES processors MUST enforce policy requirements set by data consumers and/or data publishers in accordance with the architecture [ref ARCH] and this document. They cannot do this consistently unless there is an unambiguous semantics and representation of the data elements mentioned in the policy. For example, this document mentions protection of user "identity" and "profile" information. = If a user specifies that his identity must not be shared with other = OPES administrative trust domains and later discovers that his family = name has been shared, he might complain. If he were told that "family names are not considered 'identities' by this site", he would probably feel that he had cause for complaint. Or, he might be told that when he selected "do not share identity" on a web form offered by the OPES service provider, that this only covered his login name, and that a different part of the form had to be filled out to = protect family name. A further breakdown can occur if the configuration information provided by such a web form gets translated into configuration elements given to an OPES processor, and those configuration elements are difficult for a software engineer to translate into policy enforcement. The data elements might have confusing names or be split into groupings that are difficult to relate to one another. The examples illustrate why OPES policy MUST have definitions of = data elements, their relationships, and how they relate to enforcement. These semantics of essential items do not require a separate protocol, but they MUST be agreed upon by all OPES service = providers, and the users of OPES services MUST be assured that they have the ability to know their settings, to change them if the service provider policy allows the changes, and to have reasonable assurance that they are enforced with reasonable interpretations. The requirements for policy data elements in the OPES specification do not have to be all-inclusive, but they MUST cover the minimal set of elements that enable the policies that protect the data of end users and publishers. Barbir, et al. Expires October 1, 2004 [Page = 11] =0C Internet-Draft Policy Requirements April = 2004 5. Authentication of Principals and Authorization of Services This section considers the authorization and authentication of OPES services. 5.1 End users, Publishers and Other Considerations 5.1.1 Considerations for end users An OPES rule determines which attributes of traffic will trigger the application of an OPES services. The author of the service can supply rules, but the author cannot supply the necessary part of the rule precondition that determines which network users will have the OPES services applied for them. This section discusses how users = are identified in the rule preconditions, and how users can select and deselect OPES services for their traffic, how an OPES service provider SHOULD identify the users, and how they determine whether = or not to add their service selection to an OPES enforcement point. An OPES service provider MUST satisfy these major requirements: o Allow all users to request addition, deletion, or blocking of = OPES services for their traffic (blocking means "do not use this service for my traffic"). o Prevent untrusted users from causing OPES services to interfere with the traffic of other users. o Allow users to see their OPES service profiles and notify them of changes. o Keep a log of all profile activity for audit purposes. o Adhere to a privacy policy guarding users' profiles. The administrator of the PDP is a trusted party and can set policy for individuals or groups using out-of-band communication and configuration files. However, users MUST always be able to query = the PDP in order to learn what rules apply to their traffic. Rules can be deposited in the PDP with no precondition relating to network users. This is the way rules are packaged with an OPES service when it is delivered for installation. The PDP is responsible for binding identities to the rules and transmitting = them to the PEP. The identity used by the PDP for policy decisions MUST = be strictly mapped to the identity used by the PEP. Thus, if a user goes through and identification and authentication procedure with = the PDP and is known by identity "A", and if the PEP uses IP addresses Barbir, et al. Expires October 1, 2004 [Page = 12] =0C Internet-Draft Policy Requirements April = 2004 for identities, then the PDP MUST provide the PEP with a binding between "A" and A's current IP address. 5.1.2 Considerations for publishing sites An OPES service provider acting on behalf of different publishing sites SHOULD keep all the above considerations in mind when implementing an OPES site. Because each publishing site may be represented by only a single identity, the authentication and authorization databases MAY be easier for the PEP to handle. 5.1.3 Other considerations Authentication MAY be necessary between PDP's and PEP's, PEP's and callout servers, PEP's and other PEP's, callout servers and other callout servers, for purposes of validating privacy policies. In = any case where user data or traffic crosses trust domain boundaries, the originating trust domain SHOULD have a policy describing which other domains are trusted, and it SHOULD authenticate the domains and = their policies before forwarding information. 5.2 Authentication When an individual selects (or deselects) an OPES service, the individual MUST be authenticated by the OPES service provider. This means that a binding between the user's communication channel and an identity known to the service provider is made in a secure manner. This SHOULD be done using a strong authentication method with a public key certificate for the user; this will be helpful in resolving later disputes. It is recommended that the service provider keep a log of all requests for OPES services. The service provider SHOULD use public key certficates to authenticate responses to requests. The service provider may have trusted users who through explicit or implicit contract can assign, remove, or block OPES services for particular users. The trusted users MUST be authenticated before being allowed to take actions which will modify the policy base, and thus, the actions of the PEP's. Because of the sensitivity of user profiles, the PEP Interface between the PEP and the PDP MUST use a secure transport protocol. = The PEP's MUST adhere to the privacy preferences of the users. When an OPES service provider accepts an OPES service, there MUST be a unique name for the service provided by the entity publishing the service. Users MAY refer to the unique name when requesting a service. The unique name MUST be used when notifying users about Barbir, et al. Expires October 1, 2004 [Page = 13] =0C Internet-Draft Policy Requirements April = 2004 their service profiles. PEP's MUST be aware of the unique name for each service that can be accessed from their domain. There MUST be = a cryptographic binding between the unique name and the entity responsible for the functional behavior of the service; i.e., if it is a human language translating service then the name of company = that wrote the software SHOULD be bound to the unique name. 5.3 Authorization In addition to requesting or terminating specific services, users = MAY block particular services, indicating that the services should not = be applied to their traffic. The "block all OPES" directive MUST be supported on a per user basis. A response to a request for an OPES service can be positive or negative. Reasons for a negative response include "service unknown" or "service denied by PDP policy". Positive responses SHOULD = include the identity of the requestor and the service and the type of request. As described in the OPES Architecture [1], requests for OPES = services originate in either the enduser or the publisher domain. The PDP bases its authorization decision on the requestor and the domain. There are some cases where the decision may be complicated. o The end user has blocked a service, but a trusted user of the PDP wants it applied anyway. In this case, the end user SHOULD prevail, unless their are security or legal reasons to leave it = in place. o The publisher and the enduser are in the same domain. If the publisher and enduser are both clients of a PDP, can they make requests that effect each other's processing? In this case, the PDP MUST have policy rules naming the identities that are allowed to set such rules. o The publisher requests a service for an enduser. In this case, = in which the PDP and PEP are in the publisher's administrative domain, the publisher has some way of identifying the end user = and his traffic, and the PDP MUST enable the PEP to enforce the policy. This is allowed, but the PDP MUST use strong methods to identify the user and his traffic. The user MUST be able to request and receive information about the service profile that a publisher site keeps about him. o The enduser requests a service specific to a publisher identity (e.g., nfl.com), but the publisher prohibits the service (e.g., through a "NO OPES" application header). As in the case above, Barbir, et al. Expires October 1, 2004 [Page = 14] =0C Internet-Draft Policy Requirements April = 2004 the publisher MUST be able to request and receive profile information that a user keeps about a publisher. In general, the PDP SHOULD keep its policy base in a manner that makes the decision procedure for all cases easy to understand. 5.4 Integrity and Encryption 5.4.1 Integrity and confidentiality of authentication and requests/ responses for service The requests and responses SHOULD be cryptographically tied to the identities of the requestor and responder, and the messages SHOULD not be alterable without detection. A certificate-based digital signature is strongly recommended as part of the authentication process. A binding between the request and response SHOULD be established using well-founded cryptographic means, to show that the response is made in reply to a specific request. 5.4.2 Integrity and confidentiality of application content As directed by the PEP, content will be transformed in whole or in part by OPES services. This means that end-to-end cryptographic protections cannot be used. This is probably acceptable for the = vast majority of traffic, but in cases where a lesser form of content protection is desirable, hop-by-hop protections can be used instead. The requirements for such protections are: o Integrity using shared secrets MUST be used between all = processing points, end-to-end (i.e., the two ends a "hop" MUST share a secret, but the secret can be different between "hops"). The processing points include the callout servers. o Encryption can be requested separately, with the same secret sharing requirement between "hops". When requested, encryption applies to all processing points, including callout servers. o The signal for integrity (and optionally encryption) MUST originate from either the requestor (in which case it is applied to the response as well) or the responder (in which case it = covers only the response). o The shared secrets MUST be unique (to within a very large probabilistic certainty) for each requestor/responder pair. This helps to protect the privacy of enduser data from insider attacks or configuration errors while it transits the provider's network. Barbir, et al. Expires October 1, 2004 [Page = 15] =0C Internet-Draft Policy Requirements April = 2004 5.5 Privacy The PDP MUST have a privacy policy regarding OPES data such as user profiles for services. Users MUST be able to limit the promulgation of their profile data and their identities. Supported limitations MUST include: o The ability to prevent Identity from being given to callout servers. o The ability to prevent Profile information from being shared. o Tthe ability to prevent Traffic data from being sent to callout servers run by third parties. o The ability to prevent Traffic from particular sites from being given to OPES callout servers. When an OPES service is provided by a third-party, it MUST have a privacy policy and identify itself to upstream and downstream parties, telling them how to access its privacy policy. A mechanism is needed to specify these preferences and a protocol to distribute that (see section 3.3). Barbir, et al. Expires October 1, 2004 [Page = 16] =0C Internet-Draft Policy Requirements April = 2004 6. Security Considerations This document discusses policy, authorization and enforcement requirements of OPES. In [3] multiple security and privacy issues related to the OPES services are discussed. Barbir, et al. Expires October 1, 2004 [Page = 17] =0C Internet-Draft Policy Requirements April = 2004 Normative References [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04.txt, December 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Barbir et. al, A., "Security Threats and Risks for OPES", Internet-Draft: http://www.ietf.org/internet-drafts/ draft-ietf-opes-threats-03.txt, December 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Barbir, et al. Expires October 1, 2004 [Page = 18] =0C Internet-Draft Policy Requirements April = 2004 Informative References [5] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC = 3198, November 2001. [6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Oskar Batuner Consultant EMail: batuner@attbi.com Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA EMail: abeck@bell-labs.com Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com Barbir, et al. Expires October 1, 2004 [Page = 19] =0C Internet-Draft Policy Requirements April = 2004 Hilarie Orman Purple Streak Development Phone: EMail: ho@alum.mit.edu Barbir, et al. Expires October 1, 2004 [Page = 20] =0C Internet-Draft Policy Requirements April = 2004 Appendix A. Acknowledgements Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring) and B. Srinivas (Nokia) Barbir, et al. Expires October 1, 2004 [Page = 21] =0C Internet-Draft Policy Requirements April = 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir, et al. Expires October 1, 2004 [Page = 22] =0C Internet-Draft Policy Requirements April = 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir, et al. Expires October 1, 2004 [Page = 23] =0C ------_=_NextPart_000_01C418E5.1A612CD0-- From HQXJZSILB@inet.bg Sat Apr 3 12:40:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27914 for ; Sat, 3 Apr 2004 12:40:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9p7i-0004CH-00 for opes-archive@ietf.org; Sat, 03 Apr 2004 12:40:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9p6n-00045X-00 for opes-archive@ietf.org; Sat, 03 Apr 2004 12:39:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9p5r-0003yK-00 for opes-archive@ietf.org; Sat, 03 Apr 2004 12:38:07 -0500 Received: from user-0c90oa2.cable.mindspring.com ([24.144.97.66]) by mx2.foretec.com with smtp (Exim 4.24) id 1B9p5s-0007Hq-2e for opes-archive@ietf.org; Sat, 03 Apr 2004 12:38:08 -0500 Received: from 182.120.150.52 by 65.246.255.50; Sat, 03 Apr 2004 23:30:54 +0600 Message-ID: From: "Kareem Mclean" Reply-To: "Kareem Mclean" To: opes-archive@ietf.org Subject: This is real Date: Sat, 03 Apr 2004 13:35:54 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--45649006960703082" X-Priority: 3 X-CS-IP: 221.207.88.183 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----45649006960703082 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a

Cash in with Google makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.

no more emails please

----45649006960703082-- From txofzaypmjux@cox-internet.com Sat Apr 3 18:47:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11658 for ; Sat, 3 Apr 2004 18:47:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9uqy-0007ZB-00 for opes-archive@ietf.org; Sat, 03 Apr 2004 18:47:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9uq5-0007Sr-00 for opes-archive@ietf.org; Sat, 03 Apr 2004 18:46:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9upC-0007MS-00; Sat, 03 Apr 2004 18:45:18 -0500 Received: from [200.164.115.70] (helo=MA164115070.user.veloxzone.com.br) by mx2.foretec.com with smtp (Exim 4.24) id 1B9uow-0007fV-Dq; Sat, 03 Apr 2004 18:45:04 -0500 Received: from 187.28.18.192 by web092.mail.yahoo.com; Sat, 03 Apr 2004 20:45:09 -0300 Message-ID: From: "Rosella Bryan" To: bofchairs@ietf.org Subject: Fwd: Order All Medications online with no prior prescription. Discreet Shipping. Date: Sat, 03 Apr 2004 21:43:09 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8374320598759195166" X-CS-IP: 16.128.184.241 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.6 required=5.0 tests=AWL,BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,ONLINE_PHARMACY autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.0 AWL AWL: Auto-whitelist adjustment ----8374320598759195166 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

Did you know that you can conveniently and comfortably connect with our Doctors and Pharmacists through the Internet?

You'll have your prescriptions written and your medications prescribed quickly and easily from the comfort of your own computer.

You'll save money because you aren't subject to a high fee, common with a normal office visit - your questionnaire is done online - not in a Doctor's office.

Start placing your order for meds here

Nshatter tenacious total crania tompkins ; Fbegetting tenacity communicant anglophobia shawnee compatriot bullwhack poll ; Wdevonshire carolina sam keypunch chive inhumane dosage creaky abbe brae lark alumnae conclave flanagan itself coniferous gases troposphere adobe baku swift deane cocktail bleary fade beijing capacitate plaque divination carrot vermeil Sdepository consanguine ticket alexandre appease blackberry ne repugnant baldwin space weatherstripping synergism ensconce !! Ihoneydew cortland caryatid analyst ballerina abound foamy michelin dyer crap flack ne byline ! Wreddish brushfire ordinal dutiable publication dogmatism rica didactic cacm emissivity scrawl west annalen tram concern katmandu canny boat fiction foci debra psychopathic ablaze zomba bid rickets dissident armour treasure invariant Lspitz forceful weather dewdrop guildhall waddle diana debacle laugh svelte got amorous acquiesce echinoderm appreciable danny compleat ruffian blown . Schalk clog woodward broke burgeon incorrect baseband arise empathy cigar !! Sdiligent totem boomerang brasilia byzantium agent durance venous coma bernardino brahmaputra encomia bray skylark jamestown fish .Pchina cleavage auspices eulogy draftsmen condemnatory superbly worthwhile affair sight mutilate abroad cloudy compartment corbel vest don thorium santo o'dwyer ? Xsunday feeney asceticism ribonucleic lycopodium seethe pronounce josephson bulb discriminant letterhead myron ditzel bimolecular birch ardency stewart atlanta brilliant consignee breakwater coalesce halloween ignoble bikini emma solemnity alongside cowl glisten !! Krevise curvilinear deity buzzing candlelight department confocal hydro vindicate macdonald tunic audio coke dogleg cpu gargle coalesce onetime ready cohen bristle giveth hydrate immigrate resolute alpine bazaar alphanumeric .Ainflame quakeress bonito polymer suffrage leachate salvation . Rfroze headlight thorpe hansel declarative trifluoride arginine confiscable burrow coca replica s alve adkins disciplinary esplanade eave equipping mcconnel pharmacology aug amplitude schenectady ? Ureel olden she velar cur malarial phosphorylate proserpine sturm choreograph bruise hypertensive numerate shrive cohort victory pocketbook co mantissa antedate penn lustrous curvilinear dystrophy rabid annale bike citron clomp ultra islamic angola commutate complacent concertina .Abaccarat coverall quickstep mckinney razzle trillion ellen intrepid anarchy conflagrate woo phrase lowry mid blackberry whitaker bourbaki canary tendency cupboard ? Pgodmother pontificate transship pyroelectric column concrete decca into zorn figurine trite cowpunch gamesman : Imazda decisionmake a apropos escheat erwin clarify atomic pain covariate uncle antiphonal penetrate idyllic skyline baccalaureate dow rival breakpoint shiv becky shuffle church .

If this notice has reached you in error, please notify us by clicking here ----8374320598759195166-- From owner-ietf-openproxy@mail.imc.org Mon Apr 5 18:12:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15898 for ; Mon, 5 Apr 2004 18:12:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcK7-0004VO-00 for opes-archive@ietf.org; Mon, 05 Apr 2004 18:12:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAc9X-0002ux-00 for opes-archive@ietf.org; Mon, 05 Apr 2004 18:01:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BAbrh-0007T3-00 for opes-archive@ietf.org; Mon, 05 Apr 2004 17:42:45 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LN45X009159; Mon, 5 Apr 2004 14:23:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LN43d009158; Mon, 5 Apr 2004 14:23:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LN1Mi009149 for ; Mon, 5 Apr 2004 14:23:03 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i35LN5OR021209; Mon, 5 Apr 2004 17:23:05 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i35LMxi7020710; Mon, 5 Apr 2004 17:22:59 -0400 (EDT) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i35LMwkg016498; Mon, 5 Apr 2004 17:22:58 -0400 (EDT) Message-ID: <4071CD8C.5070404@bell-labs.com> Date: Mon, 05 Apr 2004 17:20:12 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abbie Barbir CC: OPES Group Subject: Re: FW: New authorization draft: draft-ietf-opes-authorization-03 References: <87609AFB433BD5118D5E0002A52CD754090A7653@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754090A7653@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Abbie, Looks good. Some nitpicks, mostly wrt to the uppercase keywords: Section 3.3: "Implementation MUST not prohibit..." "not" should be uppercase Section 4.1: "The rule author, MAY not know specific service..." delete comma; MAY should be lowercase Section 4.1.3: "...modifications to the request MAY need..." MAY should be lowercase Section 4.2.3: "Some OPES services MAY need to be invoked..." MAY should be lowercase Section 4.3: "...with the architecture [ref ARCH] and this document." should be a reference to [1] Section 5.1.2: "...authorization databases MAY be easier..." MAY should be lowercase Section 5.1.3: "Authentication MAY be necessary..." MAY should be lowercase Section 5.5: "Tthe ability to prevent Traffic..." should be "The" -Andre Abbie Barbir wrote: > > > -----Original Message----- > From: Barbir, Abbie [CAR:1A11:EXCH] > Sent: Friday, April 02, 2004 11:24 AM > To: Markus Hofmann; OPES Group > Cc: 'Marshall Rose' > Subject: New authorization draft: draft-ietf-opes-authorization-03 > > > All, > > Attached is the -03 of the authorization draft. > > I have added a terminology and security sections + fixed MUST etc.. . > > Please review so we can re-submit to the IETF. > > Abbie > > From owner-ietf-openproxy@mail.imc.org Mon Apr 5 18:43:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17152 for ; Mon, 5 Apr 2004 18:43:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcoZ-00072w-00 for opes-archive@ietf.org; Mon, 05 Apr 2004 18:43:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAcF6-0003jo-00 for opes-archive@ietf.org; Mon, 05 Apr 2004 18:06:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BAbyZ-0000rj-00 for opes-archive@ietf.org; Mon, 05 Apr 2004 17:49:51 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LRTAq009356; Mon, 5 Apr 2004 14:27:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LRTfP009355; Mon, 5 Apr 2004 14:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LRTZV009348 for ; Mon, 5 Apr 2004 14:27:29 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i35LRNB06957; Mon, 5 Apr 2004 17:27:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Apr 2004 17:27:24 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540912001B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Andre Beck Cc: OPES Group Subject: RE: FW: New authorization draft: draft-ietf-opes-authorization-03 Date: Mon, 5 Apr 2004 17:27:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41B54.C47FB7A6" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41B54.C47FB7A6 Content-Type: text/plain Andre, Thanks will fix and re-publish tom. Abbie > -----Original Message----- > From: Andre Beck [mailto:abeck@bell-labs.com] > Sent: Monday, April 05, 2004 5:20 PM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: OPES Group > Subject: Re: FW: New authorization draft: > draft-ietf-opes-authorization-03 > > > Abbie, > > Looks good. Some nitpicks, mostly wrt to the uppercase keywords: > > Section 3.3: "Implementation MUST not prohibit..." > > "not" should be uppercase > > Section 4.1: "The rule author, MAY not know specific service..." > > delete comma; MAY should be lowercase > > Section 4.1.3: "...modifications to the request MAY need..." > > MAY should be lowercase > > Section 4.2.3: "Some OPES services MAY need to be invoked..." > > MAY should be lowercase > > Section 4.3: "...with the architecture [ref ARCH] and this document." > > should be a reference to [1] > > Section 5.1.2: "...authorization databases MAY be easier..." > > MAY should be lowercase > > Section 5.1.3: "Authentication MAY be necessary..." > > MAY should be lowercase > > Section 5.5: "Tthe ability to prevent Traffic..." > > should be "The" > > -Andre > > Abbie Barbir wrote: > > > > > > -----Original Message----- > > From: Barbir, Abbie [CAR:1A11:EXCH] > > Sent: Friday, April 02, 2004 11:24 AM > > To: Markus Hofmann; OPES Group > > Cc: 'Marshall Rose' > > Subject: New authorization draft: draft-ietf-opes-authorization-03 > > > > > > All, > > > > Attached is the -03 of the authorization draft. > > > > I have added a terminology and security sections + fixed > MUST etc.. . > > > > Please review so we can re-submit to the IETF. > > > > Abbie > > > > > > > ------_=_NextPart_001_01C41B54.C47FB7A6 Content-Type: text/html RE: FW: New authorization draft: draft-ietf-opes-authorization-03

Andre,
Thanks
will fix and re-publish tom.

Abbie

> -----Original Message-----
> From: Andre Beck [mailto:abeck@bell-labs.com]
> Sent: Monday, April 05, 2004 5:20 PM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: OPES Group
> Subject: Re: FW: New authorization draft:
> draft-ietf-opes-authorization-03
>
>
> Abbie,
>
> Looks good. Some nitpicks, mostly wrt to the uppercase keywords:
>
> Section 3.3: "Implementation MUST not prohibit..."
>
> "not" should be uppercase
>
> Section 4.1: "The rule author, MAY not know specific service..."
>
> delete comma; MAY should be lowercase
>
> Section 4.1.3: "...modifications to the request MAY need..."
>
> MAY should be lowercase
>
> Section 4.2.3: "Some OPES services MAY need to be invoked..."
>
> MAY should be lowercase
>
> Section 4.3: "...with the architecture [ref ARCH] and this document."
>
> should be a reference to [1]
>
> Section 5.1.2: "...authorization databases MAY be easier..."
>
> MAY should be lowercase
>
> Section 5.1.3: "Authentication MAY be necessary..."
>
> MAY should be lowercase
>
> Section 5.5: "Tthe ability to prevent Traffic..."
>
> should be "The"
>
> -Andre
>
> Abbie Barbir wrote:
> >
> >
> > -----Original Message-----
> > From: Barbir, Abbie [CAR:1A11:EXCH]
> > Sent: Friday, April 02, 2004 11:24 AM
> > To: Markus Hofmann; OPES Group
> > Cc: 'Marshall Rose'
> > Subject: New authorization draft: draft-ietf-opes-authorization-03
> >
> >
> > All,
> >
> > Attached is the -03 of the authorization draft.
> >
> > I have added a terminology and security sections + fixed
> MUST etc.. .
> >
> > Please review so we can re-submit to the IETF.
> >
> > Abbie
> >
> >
>
>
>

------_=_NextPart_001_01C41B54.C47FB7A6-- From pcwxc@wacom.co.jp Tue Apr 6 06:50:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01414 for ; Tue, 6 Apr 2004 06:50:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAo9u-0005rT-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 06:50:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAndc-0002xt-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 06:17:01 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAnOj-00000E-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 06:01:37 -0400 Received: from h-68-167-202-34.snfccasy.covad.net ([68.167.202.34]) by mx2.foretec.com with smtp (Exim 4.24) id 1BAnOk-0000iA-Op for opes-archive@ietf.org; Tue, 06 Apr 2004 06:01:39 -0400 Received: from 20.128.72.255 by 68.167.202.34; Tue, 06 Apr 2004 14:55:24 +0400 Message-ID: From: "Allen Meredith" Reply-To: "Allen Meredith" To: opes-archive@ietf.org Subject: holy shit! Date: Tue, 06 Apr 2004 15:58:24 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--275328046990457" X-Webmail-Time: Tue, 06 Apr 2004 06:01:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----275328046990457 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable fascicle caputo aviatrix dietz caruso schafer indignant hubbell com= ponentry rawboned acquitting cybernetic elide crowd lily aviate=20=

Do y= ou want to be paid just for providing your opinion?

medallion enclave alterman anew ketosis affo= rd conceit adrienne derision relate aminobenzoic earnest sydney diathermy = syllogism compatriot diverse o'er pronunciation strabismus casualty airflo= w rein shod presto abetted barnabas blomquist someone befell briton acropo= lis licensable osborne=20 davis chatty butyl pedal ebullient brain= y individual burroughs sonorous airflow mccall spleen doria=20 bale mission mulct chromosphere coda biology= czar paddy trill diathermy carrot midday backpack blum odometer hobble wi= nd bart churchmen nicotine nicholson salsify turtleback educate avowal san= infantryman appointee pessimal myron spout honeydew clio scull obscene re= morseful gusty leadeth=20 cambodia dash wayne pledge ancestor bo= nito mcneil cannibal selenate chemisorb irrecoverable wylie highball india= caper idiotic fourteen holystone bassinet opinion sternberg salient cloth= esbrush=20 ----275328046990457-- From owner-ietf-openproxy@mail.imc.org Tue Apr 6 11:59:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29809 for ; Tue, 6 Apr 2004 11:59:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAsyn-0004G7-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 11:59:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAsLj-00009S-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 11:19:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BAs21-0004jz-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 10:58:29 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Efk2H056467; Tue, 6 Apr 2004 07:41:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36EfkKr056466; Tue, 6 Apr 2004 07:41:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36EfjsR056459 for ; Tue, 6 Apr 2004 07:41:45 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i36Ef1a28860; Tue, 6 Apr 2004 10:41:01 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Apr 2004 10:41:02 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75409120449@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , "'Markus Hofmann'" , "'Marshall Rose'" Subject: Request to publish:draft-ietf-opes-authorization-03 Date: Tue, 6 Apr 2004 10:40:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C41BE5.27D20EB8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE, LINES_OF_YELLING autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C41BE5.27D20EB8 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41BE5.27D20EB8" ------_=_NextPart_001_01C41BE5.27D20EB8 Content-Type: text/plain Please publish the following draft-ietf-opes-authorization-03 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C41BE5.27D20EB8 Content-Type: text/html Request to publish:draft-ietf-opes-authorization-03

Please publish the following

draft-ietf-opes-authorization-03

as a WG Draft.

Thanks
Abbie

------_=_NextPart_001_01C41BE5.27D20EB8-- ------_=_NextPart_000_01C41BE5.27D20EB8 Content-Type: text/plain; name="draft-ietf-opes-authorization-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-authorization-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: October 5, 2004 O. = Batuner = Consultant A. = Beck Lucent = Technologies T. = Chan = Nokia H. = Orman Purple Streak = Development April 6, = 2004 Policy, Authorization and Enforcement Requirements of OPES draft-ietf-opes-authorization-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 5, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a given OPES flow. Barbir, et al. Expires October 5, 2004 [Page = 1] =0C Internet-Draft Policy Requirements April = 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Policy Architecture . . . . . . . . . . . . . . . . . . . . . = 5 3.1 Policy Components and Functions . . . . . . . . . . . . . = 5 3.2 Requirements For Policy Decision Point . . . . . . . . . . = 6 3.3 Requirements for Policy Enforcement Points . . . . . . . . = 6 4. Requirements for Interfaces . . . . . . . . . . . . . . . . . = 8 4.1 Service Bindings Requirements . . . . . . . . . . . . . . = 8 4.1.1 Environment Variables . . . . . . . . . . . . . . . . = 8 4.1.2 Requirements for Using State Information . . . . . . . = 9 4.1.3 Requirements for Passing Information Between Services . . . . . . . . . . . . . . . . . . . . . . . = 9 4.2 Requirements for Rule and Rules Management . . . . . . . . = 9 4.2.1 Requirements for Rule Providers . . . . . . . . . . . = 9 4.2.2 Requirements for Rule Formats and Protocols . . . . . = 10 4.2.3 Requirements for Rule Conditions . . . . . . . . . . . = 10 4.2.4 Requirements for Rule Actions . . . . . . . . . . . . = 10 4.3 Requirements for Policy Expression . . . . . . . . . . . . = 10 5. Authentication of Principals and Authorization of Services . . = 12 5.1 End users, Publishers and Other Considerations . . . . . . = 12 5.1.1 Considerations for end users . . . . . . . . . . . . . = 12 5.1.2 Considerations for publishing sites . . . . . . . . . = 13 5.1.3 Other considerations . . . . . . . . . . . . . . . . . = 13 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . = 13 5.3 Authorization . . . . . . . . . . . . . . . . . . . . . . = 14 5.4 Integrity and Encryption . . . . . . . . . . . . . . . . . = 15 5.4.1 Integrity and confidentiality of authentication and requests/responses for service . . . . . . . . . . = 15 5.4.2 Integrity and confidentiality of application content . . . . . . . . . . . . . . . . . . . . . . . = 15 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . = 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . = 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 18 7.1 Normative References . . . . . . . . . . . . . . . . . . . . = 18 7.2 Informative References . . . . . . . . . . . . . . . . . . . = 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 20 Intellectual Property and Copyright Statements . . . . . . . . = 21 Barbir, et al. Expires October 5, 2004 [Page = 2] =0C Internet-Draft Policy Requirements April = 2004 1. Introduction The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. The execution of such services is governed by a set of rules installed on OPES processor. The rule evaluation can trigger the execution of service applications local to the OPES processor or on = a remote callout server. Policies express the goals of an OPES processor as a set of rules used to administer, manage and control access to resources. The requirements in this document govern the behavior of OPES entities = in determining which, if any, of available services are to be applied = to a given message. The scope of OPES policies described in this document are limited to those that describe which services to call and, if appropriate, with what parameters. These policies do not include those that prescribe the behavior of the called services. It is desirable to enable a common management framework for specifying policies for both the calling of and the behavior of a service. The integration of such function is the domain of policy administration user interaction applications. The document is organized as follows:Section 2 considers policy framework. Section 3 discusses requirements for interfaces, while section 4 examines authentication of principals and authorization of services. Barbir, et al. Expires October 5, 2004 [Page = 3] =0C Internet-Draft Policy Requirements April = 2004 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. Barbir, et al. Expires October 5, 2004 [Page = 4] =0C Internet-Draft Policy Requirements April = 2004 3. Policy Architecture This section describes the architectural policy decomposition requirements. It also describes the requirements for the interfaces between the policy components. 3.1 Policy Components and Functions The policy functions are decomposed into three components: a Rule Author, a Policy Decision Point (PDP) and Policy Enforcement Point (PEP). The Rule Author provides the rules to be used by an OPES entity. These rules control the invocation of services on behalf of the rule author. The PDP and the PEP interpret the collected rules and appropriately enforce them. The decomposition is illustrated in Figure 1. +--------+ +--------+ | Rule | | Rule | | Author | ... | Author | +--------+ +--------+ | | | | | +----------+ | | | Policy | | <- PDP Interface +--------->| Decision |<----------+ | Point | +----------+ | ^ | | | | <- PEP Interface | | V | +--------------+ ... ---> | Policy | ---> | Enforcement | Data Traffic <--- | Point | <--- +--------------+ Figure 1: Policy Components The decomposition of policy control into a PDP and a PEP permit the offloading of some tasks to an administrative service that may be located on a separate server from the real-time enforcement services Barbir, et al. Expires October 5, 2004 [Page = 5] =0C Internet-Draft Policy Requirements April = 2004 of the PEP that reside on the OPES processor. The PDP provides for the authentication and authorization of rule authors and the validation and compilation of rules. The PEP resides in the data filter where the data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed. Interfaces between these architectural components are points of interoperability. The interface between rule authors and the policy decision points (PDP Interface) MUST use the standard format that = may result from the requirements as described in this document. The interface between the policy decision points and the policy enforcement points (PEP Interface) can be internal to a specific vendor implementation of an OPES processor. Implementations MUST use standard interface only if the PDP and the PEP reside on different OPES processor. 3.2 Requirements For Policy Decision Point The Policy Decision Point is essentially a policy compiler. The PDP MUST be a service that provides administrative support to the enforcement points. The PDP service MUST authenticate the rule authors. The PDP MUST verify that the specified rules are within the scope of the rule authors authority. The PDP MUST be a component of the OPES Administration Authority. 3.3 Requirements for Policy Enforcement Points In the OPES architecture, the data filter represents a Policy Enforcement point (PEP). At this point, data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed. In the PEP rules MAY chain actions together, where, a series of services to be called are specified. Implementation MUST ensure the passing of information from one called service to another. Implementation MUST NOT prohibit the re-evaluation of a message to determine if another service or set of services should be called. The execution of an action (i.e., the triggering of a rule) may lead to the modification of a message property values. For example, an OPES service that under some circumstances converts JPEG images to GIF images modifies the content type of the requested web object. Barbir, et al. Expires October 5, 2004 [Page = 6] =0C Internet-Draft Policy Requirements April = 2004 Such modification of message property values may change the behavior of subsequently performed OPES actions. The data filter SHOULD act = on matched rules before it evaluates subsequent rules. Multiple = matched rules can be triggered simultaneously if the data filter can determine in advance that there are no side effects from the execution of any specific rule. A data filter MAY evaluate messages several times in the course of handling an OPES flow. The rule processing points MAY be defined by administratively defined names. The definition of such names can serve as a selector for policy rules to determine the applicability of a rule or a set of rules at each processing point. The scope of policy control of policy roles as defined RFC 3060 SHOULD be used where it aids in the development of the OPES policy model. In Figure 2 a typical message data flow between a data consumer application, an OPES processor and a data provider application. = There are four commonly used processing points identified by the numbers 1 through 4. +--------+ +-----------+ +---------+ | |<------|4 3|<------| | | Data | | OPES | | Data | |Consumer| | Processor | |Provider | | Appl. |------>|1 2|------>| Appl. | +--------+ +-----------+ +---------+ Figure 2: Processing Execution Points Any data filter (PEP) or any administrative (PDP) implementation = MUST support the four rule processing points. o Data Consumer Request Handling Role : This involves request processing when received from a Data Consumer Application. o OPES Processor Request handling role: This involves request processing before forwarding to Data Provider Application. o Data Provider Response handling role: This involves response processing when forwarding to Data Consumer Application. o OPES Processor Response handling role:This involves response processing when forwarding to Data Consumer Application. Barbir, et al. Expires October 5, 2004 [Page = 7] =0C Internet-Draft Policy Requirements April = 2004 4. Requirements for Interfaces The interface between the policy system and OPES services needs to include the ability to pass system state information as well as the subject message. 4.1 Service Bindings Requirements The invoked OPES services MUST be able to be specified in a location independent fashion. That is, the rule authors need not know and = need not specify the instance of an OPES service in the rules. The rule author SHOULD be able to identify the required service at the detail level that is appropriate for his or her needs. The rule author SHOULD be able to specify a type of service or be able to specify any service that fits a general category of service to be applied its traffic. The binding of OPES service names to specific service MAY be distributed between the PDP and the PEP. As rules are compiled and validated by the PDP, they MUST be resolved to a specific installations' set of homogeneous OPES service. The selection of a specific instance MAY be postponed and left to = PEP to select at either rule installation time or at run time. To = achieve interoperability, PEP MUST support resolving a generic name to a specific instance. It is possible to use services such as SLP or = UDDI to resolve generic service names to specific OPES service instances. The policy system MAY support dynamic discovery of service bindings. The rule author may not know specific service bindings such as protocol and parameters, when a rule (as specified on the PDP Interface) is general in nature. The required binding information MUST be provided by the PDP and conveyed on the PEP Interface. A service description methodology such as WSDL MUST be present in the policy system. It is to be determined whether an OPES standard is required. 4.1.1 Environment Variables There may be a need to define and support means for maintaining = state information that can be used in both condition evaluation and action execution. Depending on the execution environment, OPES services MAY have the freedom to define variables that are needed and use these variables to further define their service behavior without the = data filter support. Barbir, et al. Expires October 5, 2004 [Page = 8] =0C Internet-Draft Policy Requirements April = 2004 4.1.2 Requirements for Using State Information Policy rules MAY specify that state information be used as part of the evaluation of the rules against a given message in an OPES flow. Thus, the policy system SHOULD support the maintenance of groups = that can be used in evaluating rule conditions. Membership in such = groups can be used as action triggers. For example, an authorized site blocking service might conclude that a particular user shouldn't be permitted access to a certain web site. Rather than calling the service for each request sent by such = a user, a rule might be created that determine if user is a member of blocked users and requested site is a member of blocked-sites then invoke a local blocking service to return and return an appropriate message to the user. 4.1.3 Requirements for Passing Information Between Services Environment variables can be used to pass state information between services. For example, analysis of the request or modifications to the request may need to be captured as state information that can be passed to other services on the request path or to services on the response(s) associated with that request. In the PEP, there SHOULD be provisions to enable setting up = variables when returning from a service call and passing variables to other called services based on policy. 4.2 Requirements for Rule and Rules Management This section provides the requirements for rule management. The = rules are divided into two groups. Some rules are provided by the data consumer application and other rules are provided by the data provider application. 4.2.1 Requirements for Rule Providers The requirements for rule providers are: o Rule providers MUST be authenticated and authorized for rules = that apply to their network role. o Rule providers MUST NOT be able to specify rules that are NOT within their scope of authority. o Rule providers SHOULD be able to specify only what is needed for their services. o Compilation of rules from different sources MUST NOT lead to execution of conflicting rules. Barbir, et al. Expires October 5, 2004 [Page = 9] =0C Internet-Draft Policy Requirements April = 2004 o The resolution of such rule conflicts is out of scope o Rules are assumed to be static and applied to current network state. 4.2.2 Requirements for Rule Formats and Protocols It is desirable to choose standard technologies like XML to specify the rule language format. Rules need to be sent form the rule authors to the OPES administrative server for service authorization, rule validation and compilation. The mechanisms for doing that are out of scope of the current work. Once the rules are authorized, validated and compiled by the administrative server, the rules need to be sent to the OPES processor. The mechanisms for doing that are out of scope of the current work. 4.2.3 Requirements for Rule Conditions Rule conditions MUST be matched against attribute values of the encapsulated protocol as well as environment variable values. Attribute values of the encapsulated protocol include protocol = header values and possibly also protocol body values. Some OPES services may need to be invoked for all users requests or server responses, services with logging functionality, as an = example. The rule system SHOULD allow unconditional rules rather than requiring rule authors to specify rule conditions that are always true. 4.2.4 Requirements for Rule Actions The rule system MUST allow for the specification of rule actions = that are triggered if the conditions of a rule are met. Matched rules typically lead to the invocation of local or remote services. Rule actions MUST identify the OPES service that is to be executed for = the current message request or response. Rule actions MAY contain run-time parameters which can be used to control the behavior of an OPES service. If specified, these parameters MUST be passed to the executed OPES service. 4.3 Requirements for Policy Expression OPES processors MUST enforce policy requirements set by data consumers and/or data publishers in accordance with the architecture Barbir, et al. Expires October 5, 2004 [Page = 10] =0C Internet-Draft Policy Requirements April = 2004 [1] and this document. They cannot do this consistently unless there is an unambiguous semantics and representation of the data elements mentioned in the policy. For example, this document mentions protection of user "identity" and "profile" information. If a user specifies that his identity must not be shared with other OPES administrative trust domains and later discovers that his family = name has been shared, he might complain. If he were told that "family names are not considered 'identities' by this site", he would probably feel that he had cause for complaint. Or, he might be told that when he selected "do not share identity" on a web form offered by the OPES service provider, that this only covered his login name, and that a different part of the form had to be filled out to = protect family name. A further breakdown can occur if the configuration information provided by such a web form gets translated into configuration elements given to an OPES processor, and those configuration elements are difficult for a software engineer to translate into policy enforcement. The data elements might have confusing names or be split into groupings that are difficult to relate to one another. The examples illustrate why OPES policy MUST have definitions of = data elements, their relationships, and how they relate to enforcement. These semantics of essential items do not require a separate protocol, but they MUST be agreed upon by all OPES service = providers, and the users of OPES services MUST be assured that they have the ability to know their settings, to change them if the service provider policy allows the changes, and to have reasonable assurance that they are enforced with reasonable interpretations. The requirements for policy data elements in the OPES specification do not have to be all-inclusive, but they MUST cover the minimal set of elements that enable the policies that protect the data of end users and publishers. Barbir, et al. Expires October 5, 2004 [Page = 11] =0C Internet-Draft Policy Requirements April = 2004 5. Authentication of Principals and Authorization of Services This section considers the authorization and authentication of OPES services. 5.1 End users, Publishers and Other Considerations 5.1.1 Considerations for end users An OPES rule determines which attributes of traffic will trigger the application of an OPES services. The author of the service can supply rules, but the author cannot supply the necessary part of the rule precondition that determines which network users will have the OPES services applied for them. This section discusses how users = are identified in the rule preconditions, and how users can select and deselect OPES services for their traffic, how an OPES service provider SHOULD identify the users, and how they determine whether = or not to add their service selection to an OPES enforcement point. An OPES service provider MUST satisfy these major requirements: o Allow all users to request addition, deletion, or blocking of = OPES services for their traffic (blocking means "do not use this service for my traffic"). o Prevent untrusted users from causing OPES services to interfere with the traffic of other users. o Allow users to see their OPES service profiles and notify them of changes. o Keep a log of all profile activity for audit purposes. o Adhere to a privacy policy guarding users' profiles. The administrator of the PDP is a trusted party and can set policy for individuals or groups using out-of-band communication and configuration files. However, users MUST always be able to query = the PDP in order to learn what rules apply to their traffic. Rules can be deposited in the PDP with no precondition relating to network users. This is the way rules are packaged with an OPES service when it is delivered for installation. The PDP is responsible for binding identities to the rules and transmitting = them to the PEP. The identity used by the PDP for policy decisions MUST = be strictly mapped to the identity used by the PEP. Thus, if a user goes through and identification and authentication procedure with = the PDP and is known by identity "A", and if the PEP uses IP addresses for identities, then the PDP MUST provide the PEP with a binding between "A" and A's current IP address. Barbir, et al. Expires October 5, 2004 [Page = 12] =0C Internet-Draft Policy Requirements April = 2004 5.1.2 Considerations for publishing sites An OPES service provider acting on behalf of different publishing sites SHOULD keep all the above considerations in mind when implementing an OPES site. Because each publishing site may be represented by only a single identity, the authentication and authorization databases may be easier for the PEP to handle. 5.1.3 Other considerations Authentication may be necessary between PDP's and PEP's, PEP's and callout servers, PEP's and other PEP's, callout servers and other callout servers, for purposes of validating privacy policies. In = any case where user data or traffic crosses trust domain boundaries, the originating trust domain SHOULD have a policy describing which other domains are trusted, and it SHOULD authenticate the domains and = their policies before forwarding information. 5.2 Authentication When an individual selects (or deselects) an OPES service, the individual MUST be authenticated by the OPES service provider. This means that a binding between the user's communication channel and an identity known to the service provider is made in a secure manner. This SHOULD be done using a strong authentication method with a public key certificate for the user; this will be helpful in resolving later disputes. It is recommended that the service provider keep a log of all requests for OPES services. The service provider SHOULD use public key certficates to authenticate responses to requests. The service provider may have trusted users who through explicit or implicit contract can assign, remove, or block OPES services for particular users. The trusted users MUST be authenticated before being allowed to take actions which will modify the policy base, and thus, the actions of the PEP's. Because of the sensitivity of user profiles, the PEP Interface between the PEP and the PDP MUST use a secure transport protocol. = The PEP's MUST adhere to the privacy preferences of the users. When an OPES service provider accepts an OPES service, there MUST be a unique name for the service provided by the entity publishing the service. Users MAY refer to the unique name when requesting a service. The unique name MUST be used when notifying users about their service profiles. PEP's MUST be aware of the unique name for each service that can be accessed from their domain. There MUST be = a cryptographic binding between the unique name and the entity Barbir, et al. Expires October 5, 2004 [Page = 13] =0C Internet-Draft Policy Requirements April = 2004 responsible for the functional behavior of the service; i.e., if it is a human language translating service then the name of company = that wrote the software SHOULD be bound to the unique name. 5.3 Authorization In addition to requesting or terminating specific services, users = MAY block particular services, indicating that the services should not = be applied to their traffic. The "block all OPES" directive MUST be supported on a per user basis. A response to a request for an OPES service can be positive or negative. Reasons for a negative response include "service unknown" or "service denied by PDP policy". Positive responses SHOULD = include the identity of the requestor and the service and the type of request. As described in the OPES Architecture [1], requests for OPES = services originate in either the enduser or the publisher domain. The PDP bases its authorization decision on the requestor and the domain. There are some cases where the decision may be complicated. o The end user has blocked a service, but a trusted user of the PDP wants it applied anyway. In this case, the end user SHOULD prevail, unless their are security or legal reasons to leave it = in place. o The publisher and the enduser are in the same domain. If the publisher and enduser are both clients of a PDP, can they make requests that effect each other's processing? In this case, the PDP MUST have policy rules naming the identities that are allowed to set such rules. o The publisher requests a service for an enduser. In this case, = in which the PDP and PEP are in the publisher's administrative domain, the publisher has some way of identifying the end user = and his traffic, and the PDP MUST enable the PEP to enforce the policy. This is allowed, but the PDP MUST use strong methods to identify the user and his traffic. The user MUST be able to request and receive information about the service profile that a publisher site keeps about him. o The enduser requests a service specific to a publisher identity (e.g., nfl.com), but the publisher prohibits the service (e.g., through a "NO OPES" application header). As in the case above, the publisher MUST be able to request and receive profile information that a user keeps about a publisher. In general, the PDP SHOULD keep its policy base in a manner that makes the decision procedure for all cases easy to understand. Barbir, et al. Expires October 5, 2004 [Page = 14] =0C Internet-Draft Policy Requirements April = 2004 5.4 Integrity and Encryption 5.4.1 Integrity and confidentiality of authentication and requests/ responses for service The requests and responses SHOULD be cryptographically tied to the identities of the requestor and responder, and the messages SHOULD not be alterable without detection. A certificate-based digital signature is strongly recommended as part of the authentication process. A binding between the request and response SHOULD be established using well-founded cryptographic means, to show that the response is made in reply to a specific request. 5.4.2 Integrity and confidentiality of application content As directed by the PEP, content will be transformed in whole or in part by OPES services. This means that end-to-end cryptographic protections cannot be used. This is probably acceptable for the = vast majority of traffic, but in cases where a lesser form of content protection is desirable, hop-by-hop protections can be used instead. The requirements for such protections are: o Integrity using shared secrets MUST be used between all = processing points, end-to-end (i.e., the two ends a "hop" MUST share a secret, but the secret can be different between "hops"). The processing points include the callout servers. o Encryption can be requested separately, with the same secret sharing requirement between "hops". When requested, encryption applies to all processing points, including callout servers. o The signal for integrity (and optionally encryption) MUST originate from either the requestor (in which case it is applied to the response as well) or the responder (in which case it = covers only the response). o The shared secrets MUST be unique (to within a very large probabilistic certainty) for each requestor/responder pair. This helps to protect the privacy of enduser data from insider attacks or configuration errors while it transits the provider's network. 5.5 Privacy The PDP MUST have a privacy policy regarding OPES data such as user profiles for services. Users MUST be able to limit the promulgation of their profile data and their identities. Supported limitations MUST include: o The ability to prevent Identity from being given to callout servers. Barbir, et al. Expires October 5, 2004 [Page = 15] =0C Internet-Draft Policy Requirements April = 2004 o The ability to prevent Profile information from being shared. o The ability to prevent Traffic data from being sent to callout servers run by third parties. o The ability to prevent Traffic from particular sites from being given to OPES callout servers. When an OPES service is provided by a third-party, it MUST have a privacy policy and identify itself to upstream and downstream parties, telling them how to access its privacy policy. A mechanism is needed to specify these preferences and a protocol to distribute that (see section 3.3). Barbir, et al. Expires October 5, 2004 [Page = 16] =0C Internet-Draft Policy Requirements April = 2004 6. Security Considerations This document discusses policy, authorization and enforcement requirements of OPES. In [3] multiple security and privacy issues related to the OPES services are discussed. Barbir, et al. Expires October 5, 2004 [Page = 17] =0C Internet-Draft Policy Requirements April = 2004 7. References 7.1 Normative References [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04.txt, December 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Barbir et. al, A., "Security Threats and Risks for OPES", Internet-Draft: http://www.ietf.org/internet-drafts/ draft-ietf-opes-threats-03.txt, December 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 7.2 Informative References [5] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC = 3198, November 2001. [6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir, et al. Expires October 5, 2004 [Page = 18] =0C Internet-Draft Policy Requirements April = 2004 Oskar Batuner Consultant EMail: batuner@attbi.com Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA EMail: abeck@bell-labs.com Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com Hilarie Orman Purple Streak Development Phone: EMail: ho@alum.mit.edu Barbir, et al. Expires October 5, 2004 [Page = 19] =0C Internet-Draft Policy Requirements April = 2004 Appendix A. Acknowledgements Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring) and B. Srinivas (Nokia) Barbir, et al. Expires October 5, 2004 [Page = 20] =0C Internet-Draft Policy Requirements April = 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir, et al. Expires October 5, 2004 [Page = 21] =0C Internet-Draft Policy Requirements April = 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir, et al. Expires October 5, 2004 [Page = 22] =0C ------_=_NextPart_000_01C41BE5.27D20EB8-- From subs-reminder@imc.org Wed Apr 7 00:45:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11173 for ; Wed, 7 Apr 2004 00:45:44 -0400 (EDT) From: subs-reminder@imc.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB4wb-00008a-00 for opes-archive@ietf.org; Wed, 07 Apr 2004 00:45:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB4Go-0001cv-00 for opes-archive@ietf.org; Wed, 07 Apr 2004 00:02:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BB32D-00020P-00 for opes-archive@ietf.org; Tue, 06 Apr 2004 22:43:25 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i372hI1e038378 for ; Tue, 6 Apr 2004 19:43:18 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i372hI77038377; Tue, 6 Apr 2004 19:43:18 -0700 (PDT) Date: Tue, 6 Apr 2004 19:43:18 -0700 (PDT) Message-Id: <200404070243.i372hI77038377@above.proper.com> To: opes-archive@ietf.org Subject: [[002810942]] Subscription to ietf-openproxy for opes-archive@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=LINES_OF_YELLING,NO_REAL_NAME autolearn=no version=2.60 Greetings. This message is a periodic reminder that opes-archive@ietf.org is subscribed to the ietf-openproxy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openproxy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openproxy-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "opes-archive@ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openproxy@mail.imc.org Wed Apr 7 14:02:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21592 for ; Wed, 7 Apr 2004 14:02:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHNS-00072m-00 for opes-archive@ietf.org; Wed, 07 Apr 2004 14:02:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGcs-0006uQ-00 for opes-archive@ietf.org; Wed, 07 Apr 2004 13:14:11 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BBFIV-0004ER-00 for opes-archive@ietf.org; Wed, 07 Apr 2004 11:49:03 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FZvNf004391; Wed, 7 Apr 2004 08:35:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FZvck004390; Wed, 7 Apr 2004 08:35:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FZumm004382 for ; Wed, 7 Apr 2004 08:35:57 -0700 (PDT) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03879; Wed, 7 Apr 2004 11:35:57 -0400 (EDT) Message-Id: <200404071535.LAA03879@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-authorization-03.txt Date: Wed, 07 Apr 2004 11:35:57 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : Policy, Authorization and Enforcement Requirements of OPES Author(s) : O. Batuner, et al Filename : draft-ietf-opes-authorization-03.txt Pages : 22 Date : 2004-4-6 This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a given OPES flow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-authorization-03.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-opes-authorization-03.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-opes-authorization-03.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: <2004-4-7110823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-authorization-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-authorization-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110823.I-D@ietf.org> --OtherAccess-- --NextPart-- From hjkjcxi@monmouth.com Thu Apr 8 03:19:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17766 for ; Thu, 8 Apr 2004 03:19:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBTob-0006Ck-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 03:19:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBS9t-0000hj-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 01:33:03 -0400 Received: from xs195-241-251-216.dial.tiscali.nl ([195.241.251.216]) by ietf-mx with smtp (Exim 4.12) id 1BBQKx-00023e-00; Wed, 07 Apr 2004 23:36:19 -0400 Received: from 213.198.192.248 by 195.241.251.216; Thu, 08 Apr 2004 09:35:02 +0500 Message-ID: From: "Noemi Sparks" Reply-To: "Noemi Sparks" To: bofchairs@ietf.org Subject: Fwd: Purchase All Your Meds Now Online. No Prescription Needed. Overnight Delivery. Date: Thu, 08 Apr 2004 02:28:02 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--802520932454257290" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=BIZ_TLD,CLICK_BELOW,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----802520932454257290 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

You now have a friend in the medical field with YourDrugsHere.

YourDrugsHere has simplified your ability to research your own health problems and anonymously discover the available options for treatment.

Absolutely No Doctor Appointment Needed!

Order by 2 pm EST and you get your meds tomorrow.

Your choice of meds. Click Here.

Espheric ciceronian cryptanalyst civet dutiful civilian six ? Nsainthood spokane crisp bistable congest army dialectic accusation borneo allot !!! Gceremonious chisholm irremovable doug cascara jam curium buttercup white wilderness deletion cluck consume apostolic telegraphy chute spit dicta lighthearted zambia bathurst broccoli timon roundworm quantitative infinitesimal pepsico bryan pristine bypath quixote incomparable butte isolde push typewrite vouch cataclysm wail free anaheim Rcomparison adversary promethium tick cheekbone similar radioastronomy . Yhaploid nicety deserve selectric heron mcneil galway cowgirl customhouse polygon vehicular burnish immoral primrose dugan bike allotropic add ! Hchaperone chamber citroen bicker karachi medicinal diacritical serif croix firebug into polyhedron general checklist army saleslady earthmoving omelet kevin irresistible sigh science compendium turing disposable bock crummy bond corrodible carfare animate faith Pmenelaus babysat bidden zionism bill theseus affix bliss feathery rank peale celluloid ? Eportraiture music yugoslavia twigging ubiquity closure expose continental dugout chicken flown appeasable tientsin bitwise cyclades candlewick cominform cyprus hurdle podia atkins !! Nestimate anastomosis leprosy lumpur voodoo satellite susan prolong audit smelt vasectomy diffuse Vgourd hereto chevy sediment urinary axisymmetric mohawk aphorism . Vblazon turpitude buckaroo psalm sanatorium registration mourn byrd calorimeter inviolate louver beastie nutritive wastewater teakettle astm . Oester grandpa shrivel veto eventful meltwater b's bridgehead obsolete cyclist vicinity proclaim sloan ravish bavaria honk methodist ember doggone lipread annale Daborigine honorific venusian btu redneck floodlit bangui anticipatory mohr dylan !! Vbade hostler fag indefatigable arlington kilo hellfire definite landscape affirmative injun cartoon . Oowl fulfill effectuate humility superlative conclave price usurpation avert cupid cleanse andrea allis dobson dichondra hyperbolic commune valediction anybody'd edwin loom butternut drumlin vacate sultan tallahassee motley airline angelina savvy chub

If this notice has reached you in error, please notify us by clicking here ----802520932454257290-- From NZMYXNSZEHIKZ@h.amu.cz Thu Apr 8 19:13:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06596 for ; Thu, 8 Apr 2004 19:13:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiiX-0002Ze-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 19:13:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiUG-00018t-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 18:59:09 -0400 Received: from h006097095f3f.ne.client2.attbi.com ([24.62.67.97]) by ietf-mx with smtp (Exim 4.12) id 1BBgqL-0004Pb-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 17:13:49 -0400 Received: from 24.124.8.177 by 24.62.67.97; Thu, 08 Apr 2004 17:11:19 -0500 Message-ID: From: "Rosendo Dickinson" Reply-To: "Rosendo Dickinson" To: opes-archive@ietf.org Subject: when? Date: Fri, 09 Apr 2004 04:08:19 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--06948597872194203929" X-Priority: 3 X-IP: 72.120.36.218 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.4 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----06948597872194203929 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable hide kitty scintillate teethed denebola countrywide pursuant walter= s afro cut cocoon riverbank stamp suntanning climactic suicide aphrodite s= tampede carroll yellowknife rna carve beginner pall counterflow blowfish r= aindrop=20

Do y= ou want to be paid just for providing your opinion?

baltic layoff despoil courageous twigg= ing argonne bubble marsupial symposium whimsic horowitz pedagogue tapir an= astomotic academic imprecision toledo jacobus feet apostate onward upsilon= cardinal aggrieve nighttime mass=20 gaulle inelegant menelaus vientiane whe= reabout fragile thrips concierge hoar glorify ani test digram=20<= /font> deltoid pediatrician haploid buttonhole = forthwith fitzroy plump desert mafia pvc buenos curiosity variant accessio= n downgrade criss baklava shag surpass ally picofarad keyword mawkish bell= ini=20 statistician comparative thea adherent = gavin galveston humboldt rangy chatham cytology addis pocket=20 ----06948597872194203929-- From owner-ietf-openproxy@mail.imc.org Thu Apr 8 22:54:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23823 for ; Thu, 8 Apr 2004 22:54:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBm9X-0007K2-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 22:53:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBm7k-0007Cy-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 22:52:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BBm5K-00075Z-00 for opes-archive@ietf.org; Thu, 08 Apr 2004 22:49:38 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i392b5XZ037066; Thu, 8 Apr 2004 19:37:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i392b5Lk037065; Thu, 8 Apr 2004 19:37:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i392b4Ps037048 for ; Thu, 8 Apr 2004 19:37:04 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i392b4uH040653; Thu, 8 Apr 2004 20:37:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i392b4wu040652; Thu, 8 Apr 2004 20:37:04 -0600 (MDT) (envelope-from rousskov) Date: Thu, 8 Apr 2004 20:37:04 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? In-Reply-To: <406B8B85.7010009@mhof.com> Message-ID: References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> <406B36BD.3060708@mhof.com> <406B8B85.7010009@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Below are the change log entries followed by the corresponding text that is meant address all IESG DISCUSS items we know about. The notification example has been adjusted based on Markus feedback, to clarify the meaning of a "host". One-party consent text used "content privacy" terminology suggested by Hilarie to clarify the intent. Please review soon and I will publish the polished version to be resubmitted for IESG review. If you need more context, the entire updated draft is available at http://www.measurement-factory.com/tmp/opes/ Thank you, Alex. =====>* Replaced "Cable Company ISP" Notification example with two new examples to address IESG uncertainty about the meaning of the old convoluted example. The OPES architecture allows for an efficient and meaningful notification protocol to be implemented in certain OPES environments. For example, an OPES callout server attached to a gateway or firewall may scan outgoing traffic for signs of worm or virus activity and notify a local Intrusion Detection System (IDS) of potentially compromised hosts (e.g., servers or client PCs) inside the network. Such notifications may use OPES tracing information to pinpoint the infected host (which could be another OPES entity). In this example, notifications are essentially sent back to the content producer (the local network) and use OPES tracing to supply details. Another environment where efficient and meaningful notification using OPES tracing is possible are Content Delivery Networks (CDNs). A CDN node may use multiple content adaptation services to customize generic content supplied by the content producer (a web site). For example, the node may insert advertisements for client-local events or services. The node itself may not understand specifics of the ad insertion algorithm implemented in OPES callout servers. However, it may use OPES trace to notify content producer about the number of certain advertisements inserted (i.e., the number of "impressions" delivered to the customer) or even the number of ad "clicks" the customer made (e.g., if the node hosts content linked from the ads). OPES services doing ad insertion may lack details (e.g., a customer ID/address or a web server authentication token) to contact the content producer directly in this case. =====>* Polished text addressing "One-party consent" concern to better show why the concern is addressed. It is not clear whether the changes will address IESG review comment that "the WG does not seem to get it" [because?] the text does not "name situations where one-party consent does make sense". It is currently not clear how naming such situations can address IAB concern, and why naming such situations is in this document scope. 3. Consideration (2.1) 'One-party consent' "An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)."[RFC3238] OPES architecture requires that "OPES processors MUST be consented to by either the data consumer or data provider application" [I-D.ietf-opes-architecture]. While this requirement directly satisfies IAB concern, no requirement alone can prevent consent-less introduction of OPES processors. In other words, OPES framework requires one-party consent but cannot guarantee it in the presence of incompliant OPES entities. In [I-D.ietf-opes-end-comm], the OPES architecture enables concerned parties to detect unwanted OPES processors by examining OPES traces. While the use of traces in OPES is mandatory, a tracing mechanism on its own cannot detect processors that are in violation of OPES specifications. Examples include OPES processors operating in stealth mode. However, the OPES architecture allows the use of content signature to verify the authenticity of performed adaptations. Content signatures is a strong but expensive mechanism that can detect any modifications of signed content provided that the content provider is willing to sign the data and that the client is willing to either check the signature or relay received content to the content provider for signature verification. OPES entities may copy or otherwise access content without modifying it. Such access cannot be detected using content signatures. Thus, "passive" OPES entities can operate on signed content without the data consumer or provider consent. If content privacy is a concern, then content encryption can be used. A passive processor is no different from any intermediary operating outside of OPES framework. No OPES mechanism (existing or foreseeable) can prevent non-modifying access to content. In summary, the one-party consent is satisfied by including the corresponding requirement in the IAB architecture document. That requirement alone cannot stop incompliant OPES entities to perform consent-less adaptations, but OPES framework allows for various means of detecting and/or preventing such adaptations. These means typically introduce overheads and require some level of producer-consumer cooperation. =====>* Polished text discussing URI resolution consideration to talk more specifically about the resolution of URIs rather than (more general) adaptation of URIs and added examples. This change is meant to address IESG concern that URI resolution is not addressed or the corresponding description is confusing. 7. Consideration (4.1) 'URI resolution' "OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself."[RFC3238] "OPES Scenarios and Use Cases" specification [I-D.ietf-opes-scenarios] documents content adaptations that are in scope of the OPES framework. Scenarios include content adaptation of requests and responses. These documented adaptations do not include URI resolution. In some environments, it is technically possible to use documented OPES mechanisms to resolve URIs (and other kinds of identifiers or addresses). The OPES framework cannot effectively prevent any specific kind of adaptation. For example, a CDN node may substitute domain names in URLs with CDN-chosen IP addresses, essentially performing a URI resolution on behalf of the content producer (i.e., the web site owner). An OPES callout service running on a user PC may rewrite all HTML-embedded advertisement URLs to point to a user-specified local image, essentially performing a URI redirection on behalf of the content consumer (i.e., the end user). Such URI manipulations are outside of the OPES framework scope, but cannot be effectively eliminated from the real world. =====>* Clarified in the Introduction that the purpose of this document is to address nine formal IAB considerations, and that we hope that addressing formal consideration is sufficient to address any informal ones that are scattered through the IAB Considerations document. This is meant to address IESG concern that some [informal] words from the IAB Consideration document do not explicitly appear in this document. The primary goal of this document is to show that all formal IAB recommendations are addressed by OPES, to the extent that those considerations can be addressed by an IETF working group. The limitations of OPES working group to address certain aspects of IAB considerations are also explicitly documented. IAB considerations document [RFC3238] contains many informal recommendations. For example, while the IAB informally requires OPES architecture to "protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries", the IAB has chosen to formalize these requirements via a set of more specific recommendations, such as Notification considerations addressed in Section 5.3 and Section 5.4 below. OPES framework addresses informal IAB recommendations by addressing corresponding formal considerations. =====>* Be more specific about where security of OPES mechanisms is discussed. Added an example of where security of OPES tracing mechanisms is discussed. This document is about addressing specific IAB considerations and is not a map/index to OPES mechanisms or their security. However, polished text and example may provide the reader with more direct clues on where to find security-related information that goes beyond the scope of this document. 12. Security Considerations This document does not define any mechanisms that may be subject to security considerations. This document scope is to address specific IAB considerations. Security of OPES mechanisms are discussed in Security Considerations sections of the corresponding OPES framework documents. For example, OPES tracing mechanisms assist content providers and consumers in protecting content integrity and confidentiality by requiring OPES intermediaries to disclose their presence. Security of the tracing mechanism is discussed in the Security Considerations section of [I-D.ietf-opes-end-comm]. The End. From owner-ietf-openproxy@mail.imc.org Fri Apr 9 12:08:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04298 for ; Fri, 9 Apr 2004 12:08:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByYE-0003Qx-00 for opes-archive@ietf.org; Fri, 09 Apr 2004 12:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByWh-0003IM-00 for opes-archive@ietf.org; Fri, 09 Apr 2004 12:06:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BByUs-00034K-00 for opes-archive@ietf.org; Fri, 09 Apr 2004 12:04:50 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39FrjlR008446; Fri, 9 Apr 2004 08:53:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39FrjTZ008445; Fri, 9 Apr 2004 08:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39FrhFZ008423 for ; Fri, 9 Apr 2004 08:53:44 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i39FrkxZ021338 for ; Fri, 9 Apr 2004 11:53:46 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i39Frdi7083754 for ; Fri, 9 Apr 2004 11:53:39 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i39Frckg001350 for ; Fri, 9 Apr 2004 11:53:39 -0400 (EDT) Message-ID: <4076C703.8040506@mhof.com> Date: Fri, 09 Apr 2004 11:53:39 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> <406B36BD.3060708@mhof.com> <406B8B85.7010009@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Please review soon and I will publish the polished version to > be resubmitted for IESG review. Looks good to me. At the end of the day, please go ahead ab request publication of the updated draft. I'll then notify ted that this draft has been modified to address the IESG comments. > Another environment where efficient and meaningful notification using > OPES tracing is possible are Content Delivery Networks (CDNs). A CDN > node may use multiple content adaptation services to customize > generic content supplied by the content producer (a web site). For > example, the node may insert advertisements for client-local events > or services. The node itself may not understand specifics of the ad > insertion algorithm implemented in OPES callout servers. However, it > may use OPES trace to notify content producer about the number of > certain advertisements inserted (i.e., the number of "impressions" > delivered to the customer) or even the number of ad "clicks" the > customer made (e.g., if the node hosts content linked from the ads). > OPES services doing ad insertion may lack details (e.g., a customer > ID/address or a web server authentication token) to contact the > content producer directly in this case. Just for clarification - this example implies that an OPES processor could use trace information to determine where to send notifications to. The destination of such notifications could be either the content producer or another (upstream) OPES processor. In the former case, there would be an OPES trace entry for the content producer? Thanks, Makrus From owner-ietf-openproxy@mail.imc.org Fri Apr 9 12:34:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06402 for ; Fri, 9 Apr 2004 12:34:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByxq-0006P5-00 for opes-archive@ietf.org; Fri, 09 Apr 2004 12:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByuL-00064L-00 for opes-archive@ietf.org; Fri, 09 Apr 2004 12:31:11 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BByry-0005gW-00 for opes-archive@ietf.org; Fri, 09 Apr 2004 12:28:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39GIqxo012228; Fri, 9 Apr 2004 09:18:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39GIqKY012226; Fri, 9 Apr 2004 09:18:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39GIqFA012212 for ; Fri, 9 Apr 2004 09:18:52 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i39GIlw25325; Fri, 9 Apr 2004 12:18:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Apr 2004 12:18:47 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754091DD4B3@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES WG Subject: RE: Revised ID Needed for draft-ietf-opes-iab-04? Date: Fri, 9 Apr 2004 12:18:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41E4E.54ADB3AE" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41E4E.54ADB3AE Content-Type: text/plain +1 abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Friday, April 09, 2004 11:54 AM > To: OPES WG > Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? > > > > Alex Rousskov wrote: > > > Please review soon and I will publish the polished > version to be > > resubmitted for IESG review. > > Looks good to me. At the end of the day, please go ahead ab request > publication of the updated draft. I'll then notify ted that > this draft > has been modified to address the IESG comments. > > > Another environment where efficient and meaningful > notification using > > OPES tracing is possible are Content Delivery Networks > (CDNs). A CDN > > node may use multiple content adaptation services to customize > > generic content supplied by the content producer (a web > site). For > > example, the node may insert advertisements for > client-local events > > or services. The node itself may not understand > specifics of the ad > > insertion algorithm implemented in OPES callout servers. > However, it > > may use OPES trace to notify content producer about the number of > > certain advertisements inserted (i.e., the number of > "impressions" > > delivered to the customer) or even the number of ad "clicks" the > > customer made (e.g., if the node hosts content linked > from the ads). > > OPES services doing ad insertion may lack details (e.g., > a customer > > ID/address or a web server authentication token) to contact the > > content producer directly in this case. > > Just for clarification - this example implies that an OPES processor > could use trace information to determine where to send notifications > to. The destination of such notifications could be either the content > producer or another (upstream) OPES processor. In the former case, > there would be an OPES trace entry for the content producer? > > Thanks, > Makrus > > ------_=_NextPart_001_01C41E4E.54ADB3AE Content-Type: text/html RE: Revised ID Needed for draft-ietf-opes-iab-04?

abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Friday, April 09, 2004 11:54 AM
> To: OPES WG
> Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04?
>
>
>
> Alex Rousskov wrote:
>
> >     Please review soon and I will publish the polished
> version to be
> > resubmitted for IESG review.
>
> Looks good to me. At the end of the day, please go ahead ab request
> publication of the updated draft. I'll then notify ted that
> this draft
> has been modified to address the IESG comments.
>
> >    Another environment where efficient and meaningful
> notification using
> >    OPES tracing is possible are Content Delivery Networks
> (CDNs). A CDN
> >    node may use multiple content adaptation services to customize
> >    generic content supplied by the content producer (a web
> site). For
> >    example, the node may insert advertisements for
> client-local events
> >    or services. The node itself may not understand
> specifics of the ad
> >    insertion algorithm implemented in OPES callout servers.
> However, it
> >    may use OPES trace to notify content producer about the number of
> >    certain advertisements inserted (i.e., the number of
> "impressions"
> >    delivered to the customer) or even the number of ad "clicks" the
> >    customer made (e.g., if the node hosts content linked
> from the ads).
> >    OPES services doing ad insertion may lack details (e.g.,
> a customer
> >    ID/address or a web server authentication token) to contact the
> >    content producer directly in this case.
>
> Just for clarification - this example implies that an OPES processor
> could use trace information to determine where to send notifications
> to. The destination of such notifications could be either the content
> producer or another (upstream) OPES processor. In the former case,
> there would be an OPES trace entry for the content producer?
>
> Thanks,
>    Makrus
>
>

------_=_NextPart_001_01C41E4E.54ADB3AE-- From owner-ietf-openproxy@mail.imc.org Mon Apr 12 13:51:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01365 for ; Mon, 12 Apr 2004 13:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5b2-0002DT-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 13:51:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Zz-00023U-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 13:50:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD5YS-0001lk-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 13:49:08 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CGGKnk015516; Mon, 12 Apr 2004 09:16:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CGGKN7015515; Mon, 12 Apr 2004 09:16:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CGGIB2015505 for ; Mon, 12 Apr 2004 09:16:18 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3CGGIuH017016; Mon, 12 Apr 2004 10:16:18 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3CGG8AP017015; Mon, 12 Apr 2004 10:16:08 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Apr 2004 10:16:08 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? In-Reply-To: <4076C703.8040506@mhof.com> Message-ID: References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> <406B36BD.3060708@mhof.com> <406B8B85.7010009@mhof.com> <4076C703.8040506@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 9 Apr 2004, Markus Hofmann wrote: > Looks good to me. At the end of the day, please go ahead ab request > publication of the updated draft. I'll then notify ted that this > draft has been modified to address the IESG comments. I submitted the iab-05 draft for publication today. > Just for clarification - this example implies that an OPES processor > could use trace information to determine where to send notifications > to. More like what to include in those notifications, I think. I inserted a few adjectives and explicitly defined a few "it" and "that" to clarify: Another environment where efficient and meaningful notification using OPES tracing is possible are Content Delivery Networks (CDNs). A CDN node may use multiple content adaptation services to customize generic content supplied by the content producer (a web site). For example, a callout service may insert advertisements for client-local events. The CDN node itself may not understand specifics of the ad insertion algorithm implemented at callout servers. However, the node may use information in the OPES trace (e.g., coming from the callout service) to notify the content producer. Such notifications may be about the number of certain advertisements inserted (i.e., the number of "impressions" delivered to the customer) or even the number of ad "clicks" the customer made (e.g., if the node hosts content linked from the ads). Callout services doing ad insertion may lack details (e.g., a customer ID/address or a web server authentication token) to contact the content producer directly in this case. Thus, OPES trace produced by an OPES service becomes essential in enabling meaningful notifications that the CDN node sends to the content producer. I hope the above polished text conveys the same meaning better. If it is not good enough, please suggest specific changes or we can delete the entire example. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Apr 12 15:05:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05323 for ; Mon, 12 Apr 2004 15:05:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD6kM-0004VY-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 15:05:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD6ig-0004Es-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 15:03:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD6hO-00040j-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 15:02:26 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIUwD6030523; Mon, 12 Apr 2004 11:30:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CIUwRD030522; Mon, 12 Apr 2004 11:30:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIUvJm030515 for ; Mon, 12 Apr 2004 11:30:57 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i3CIV1Zo044028 for ; Mon, 12 Apr 2004 14:31:01 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i3CIRqge067617 for ; Mon, 12 Apr 2004 14:30:48 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i3CHtZkg029447 for ; Mon, 12 Apr 2004 13:55:35 -0400 (EDT) Message-ID: <407AD818.8020609@mhof.com> Date: Mon, 12 Apr 2004 13:55:36 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> <406B36BD.3060708@mhof.com> <406B8B85.7010009@mhof.com> <4076C703.8040506@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, > I submitted the iab-05 draft for publication today. Thanks! > I hope the above polished text conveys the same meaning better. If > it is not good enough, please suggest specific changes or we can > delete the entire example. Fine with me. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Apr 12 16:48:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14031 for ; Mon, 12 Apr 2004 16:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD8M8-0001Gu-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 16:48:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD7yM-0007KI-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 16:24:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD7jK-0005g2-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 16:08:30 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWJhW037871; Mon, 12 Apr 2004 12:32:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CJWJ8C037870; Mon, 12 Apr 2004 12:32:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWIgi037864 for ; Mon, 12 Apr 2004 12:32:19 -0700 (PDT) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08761; Mon, 12 Apr 2004 15:32:20 -0400 (EDT) Message-Id: <200404121932.PAA08761@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-iab-05.txt Date: Mon, 12 Apr 2004 15:32:20 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Treatment of IAB Considerations Author(s) : A. Barbir, A. Rousskov Filename : draft-ietf-opes-iab-05.txt Pages : 27 Date : 2004-4-12 IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-iab-05.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-opes-iab-05.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-opes-iab-05.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: <2004-4-12154042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-iab-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-iab-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12154042.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Apr 12 17:37:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16339 for ; Mon, 12 Apr 2004 17:37:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD97U-0004lK-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 17:37:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8i8-0002qM-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 17:11:22 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD8Gz-00011a-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 16:43:18 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CK6rlq042870; Mon, 12 Apr 2004 13:06:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CK6rFx042869; Mon, 12 Apr 2004 13:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CK6r9t042850 for ; Mon, 12 Apr 2004 13:06:53 -0700 (PDT) (envelope-from jgw@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 12:16:53 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3CK6o2O026648; Mon, 12 Apr 2004 13:06:51 -0700 (PDT) Received: from cisco.com (rtp-vpn1-174.cisco.com [10.82.224.174]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASA16991; Mon, 12 Apr 2004 13:06:02 -0700 (PDT) Message-ID: <407AF6D2.5030307@cisco.com> Date: Mon, 12 Apr 2004 16:06:43 -0400 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: ietf-openproxy@imc.org Subject: Re: An opes services usage question References: <404FDBC3.9050908@cisco.com> <4059EAED.4020404@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000107040000070100010705" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000107040000070100010705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, sorry for the delay in my latest response. I have been doing some investigation and also some travel and other things ...with my day job :-) To get back to the discussion. It seems that many of the assumptions in the background of our discussions about load balancers are based on web load balancers that provide virtual addresses and hide the server cluster from the user. But, I have been thinking a little differently in considering usage of an opes framework in the mobile wireless market segment. This segment may be unique in that load balancers do not rebalance for every client connection. Instead they typically rebalance on a "per client" basis. This is done because the devices that are being balanced have client information associated with their traffic such as $, access rights, browser form factors, XML style sheets...etc. Affinity to a particular server is strongly maintained for each client. Once affinity is in place the load balancer could operate, for example, by just replacing the destination MAC address as the traffic arrives based on the source IP address (you could view the load balancer as just a "bump on the wire"). I believe this additional information should help clarify what I am thinking, a bit. I guess I am looking for the simplest solution for this environment and I keep thinking the most elegant solution would be lower layer one.... just some of my thoughts... It seems that of the two limitations you suggest, the best way to proceed (IMO) would be to assume proxies with exposed/routable adresses. I am thinking this assumption is the best one because it probably provides a faster solution, would be more flexible, and satisfies small deployment needs that do not have load balancers but still need the metadata returned to a specific server. I think we are also in agreement that with either limitation we still need something to support the metadata information exchange. I was also wondering if anyone else has any suggestions or additional information to consider? Regards John Alex Rousskov wrote: >On Thu, 18 Mar 2004, John G. Waclawsky wrote: > > > >>I believe the client server affinity problem for metadata is really >>the simpler case of just needing client affinity for the metadata to >>be sent back to a previous proxy stage. >> >> > >I agree that we need affinity for the metadata to be sent from a >processing node down the application protocol flow (next proxy stage) >back to a processing node up the application protocol flow (previous >proxy stage). I am not sure why you say "simpler case". Simpler than >what? > > > >>I believe this affinity problem should and can be solved at layer 3 >>if the source (client) IP address is available in whatever protocol >>is decided to be used in the transfer of the metadata. I did some >>checking and it seems that most load balancers maintain this IP >>address affinity for you at layer 3. >> >> > >I am not sure what you mean. The load balancer (L4-7) usually >maintains some kind of connection/address map to match clients and >servers. The load balancer can use that map to support affinity >features for existing connections and for returning clients (in some >cases). However, the L3 mapping is usually not exposed to clients and >may change. That is, a client, in general, does not know the IP >address of a proxy that served its request if that proxy is behind a >load balancer. Note that availability of a proxy IP address in >application protocol headers does not mean that the load balancer will >use that proxy for the next request from the same client and does not >mean that the IP address is reachable. In most cases, visible IP >addresses of balanced proxies are simply an architectural bug (a load >balancer should have stripped them as unreliable/incorrect/private >info, but it did not). > >I am sure there are installations where IP address information in the >application protocol headers (e.g. Via header in HTTP) leaked from >behind a load balancer is more or less reliable, at least short term. >Do you want to limit your solution to these environments? > > > >>So a layer 3 solution can be application protocol >>agnostic if we send the metadata in-band back through the load >>balancer. >> >> > >Yes, _provided_ that load balancer balancing algorithm matches your >affinity needs. For example, if a load balancer uses a simple round >robin on request basis, then you cannot get to the same proxy. Or, of >an HTTP load balancer uses URL-based switching, you may not be able to >get to the same proxy unless you request the same URL. > > > >>My current thinking is that the same layer 3 load >>balancing / affinity information could be leveraged to transfer >>proxy IP address information and resolve the flow participant >>discovery solution for sending metadata out-of-band. >> >> > >My understanding is that layer 3 load balancing / affinity information >is not generally available. Only load balancer knows it. Can you give >a couple of specific examples that satisfy your needs? > > > >>Driving the solution down to layer 3 allows metadata to be sent >>either in-band (through the load balancer) or out-of-band in those >>situations where proxies have IP reachable addresses. I did some >>more checking and also found that IP reachable addresses are often >>the case because many of the these load balanced environments have >>management LANs associated with them. >> >> > >I am not sure how existence of a [properly secured and isolated] >management LAN indicated IP-routable addresses. I am sure there are >cases where proxies are globally addressable, of course (which either >indicated poor network setup OR some external requirements that >exposed proxy IPs). > > > >>I agree we need a new protocol to support the metadata exchange (and >>possibly for acknowledgments of metadata). But, if we want the most >>general solution that also allows the sending of metadata >>out-of-band then maybe the new protocol (or some existing protocol >>used or adapted for this situation) could solve the flow participant >>discovery problem too. >> >> > >IMO, the three requirements (that we agree on) imply that no general >solution is possible without requiring proxies with exposed/routable >IPs (something you seem to require in the above discussion about L3 >information) or requiring load balancers that are aware of the new >protocol. Do you agree? Which of the two limitations do you want to >assume? > >Alex. > > > >>>Are the following three requirements correct? >>> >>> 1) Agents need to communicate metainformation to each other >>> 2) metainformation is related to some application protocol, but >>> agent communication protocol should be application agnostic >>> (i.e., should work with many application protocols) >>> 3) some agents are being load balanced with respect to the >>> application protocol in question >>> >>>If yes, I conclude: >>> >>> - some agents will not have IP addresses reachable from other >>> agents >>> >>>And, hence, >>> >>> - agent communication without assistance of load balancers >>> would be impossible in general >>> >>>To resolve the conflict, you have two options, I think: >>> >>> (a) require load balancers to handle part of the communication >>> (this is how HTTP, SSL, and ICAP are load balanced today) >>> >>> (b) limit the environment to agents that are IP-reachable >>> despite being load-balanced >>> (this would exclude some (many?) load balancing environments) >>> >>>Do you see what I am getting at? In short, if something is behind a >>>load balancer, that something may not have a routable IP address >>>and, hence, cannot communicate directly with the world. >>> >>>Whether you chose (a) or (b), you still need a new protocol or new >>>protocol profile to support the metainformation exchange. >>> >>> > > > > --------------000107040000070100010705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex, sorry for the delay in my latest response. I have been doing some investigation and also some travel and other things ...with my day job :-)

To get back to the discussion. It seems that many of the assumptions in the background of our discussions about load balancers are based on web load balancers that provide virtual addresses and hide the server cluster from the user. But, I have been thinking a little differently in considering usage of an opes framework in the mobile wireless market segment. This segment may be unique in that load balancers do not rebalance for every client connection. Instead they typically rebalance on a "per client" basis. This is done because the devices that are being balanced have client information associated with their traffic such as $, access rights, browser form factors, XML style sheets...etc. Affinity to a particular server is strongly maintained for each client. Once affinity is in place the load balancer could operate, for example, by just replacing the destination MAC address as the traffic arrives based on the source IP address (you could view the load balancer as just a "bump on the wire"). I believe this additional information should help clarify what I am thinking, a bit. I guess I am looking for the simplest solution for this environment and I keep thinking the most elegant solution would be lower layer one.... just some of my thoughts...

It seems that of the two limitations you suggest, the best way to proceed (IMO) would be to assume proxies with exposed/routable adresses. I am thinking this assumption is the best one because it probably provides a faster solution, would be more flexible, and satisfies small deployment needs that do not have load balancers but still need the metadata returned to a specific server. I think we are also in agreement that with either limitation we still need something to support the metadata information exchange. I was also wondering if anyone else has any suggestions or additional information to consider?

Regards John

Alex Rousskov wrote:

On Thu, 18 Mar 2004, John G. Waclawsky wrote:

I believe the client server affinity problem for metadata is really
the simpler case of just needing client affinity for the metadata to
be sent back to a previous proxy stage.


I agree that we need affinity for the metadata to be sent from a
processing node down the application protocol flow (next proxy stage)
back to a processing node up the application protocol flow (previous
proxy stage). I am not sure why you say "simpler case".  Simpler than
what?

I believe this affinity problem should and can be solved at layer 3
if the source (client) IP address is available in whatever protocol
is decided to be used in the transfer of the metadata. I did some
checking and it seems that most load balancers maintain this IP
address affinity for you at layer 3.


I am not sure what you mean. The load balancer (L4-7) usually
maintains some kind of connection/address map to match clients and
servers. The load balancer can use that map to support affinity
features for existing connections and for returning clients (in some
cases). However, the L3 mapping is usually not exposed to clients and
may change. That is, a client, in general, does not know the IP
address of a proxy that served its request if that proxy is behind a
load balancer. Note that availability of a proxy IP address in
application protocol headers does not mean that the load balancer will
use that proxy for the next request from the same client and does not
mean that the IP address is reachable. In most cases, visible IP
addresses of balanced proxies are simply an architectural bug (a load
balancer should have stripped them as unreliable/incorrect/private
info, but it did not).

I am sure there are installations where IP address information in the
application protocol headers (e.g. Via header in HTTP) leaked from
behind a load balancer is more or less reliable, at least short term.
Do you want to limit your solution to these environments?

So a layer 3 solution can be application protocol
agnostic if we send the metadata in-band back through the load
balancer.


Yes, _provided_ that load balancer balancing algorithm matches your
affinity needs. For example, if a load balancer uses a simple round
robin on request basis, then you cannot get to the same proxy. Or, of
an HTTP load balancer uses URL-based switching, you may not be able to
get to the same proxy unless you request the same URL.

My current thinking is that the same layer 3 load
balancing / affinity information could be leveraged to transfer
proxy IP address information and resolve the flow participant
discovery solution for sending metadata out-of-band.


My understanding is that layer 3 load balancing / affinity information
is not generally available. Only load balancer knows it. Can you give
a couple of specific examples that satisfy your needs?

Driving the solution down to layer 3 allows metadata to be sent
either in-band (through the load balancer) or out-of-band in those
situations where proxies have IP reachable addresses. I did some
more checking and also found that IP reachable addresses are often
the case because many of the these load balanced environments have
management LANs associated with them.


I am not sure how existence of a [properly secured and isolated]
management LAN indicated IP-routable addresses. I am sure there are
cases where proxies are globally addressable, of course (which either
indicated poor network setup OR some external requirements that
exposed proxy IPs).

I agree we need a new protocol to support the metadata exchange (and
possibly for acknowledgments of metadata). But, if we want the most
general solution that also allows the sending of metadata
out-of-band then maybe the new protocol (or some existing protocol
used or adapted for this situation) could solve the flow participant
discovery problem too.


IMO, the three requirements (that we agree on) imply that no general
solution is possible without requiring proxies with exposed/routable
IPs (something you seem to require in the above discussion about L3
information) or requiring load balancers that are aware of the new
protocol. Do you agree? Which of the two limitations do you want to
assume?

Alex.

Are the following three requirements correct?

 1) Agents need to communicate metainformation to each other
 2) metainformation is related to some application protocol, but
    agent communication protocol should be application agnostic
    (i.e., should work with many application protocols)
 3) some agents are being load balanced with respect to the
    application protocol in question

If yes, I conclude:

 - some agents will not have IP addresses reachable from other
   agents

And, hence,

 - agent communication without assistance of load balancers
   would be impossible in general

To resolve the conflict, you have two options, I think:

 (a) require load balancers to handle part of the communication
     (this is how HTTP, SSL, and ICAP are load balanced today)

 (b) limit the environment to agents that are IP-reachable
     despite being load-balanced
     (this would exclude some (many?) load balancing environments)

Do you see what I am getting at? In short, if something is behind a
load balancer, that something may not have a routable IP address
and, hence, cannot communicate directly with the world.

Whether you chose (a) or (b), you still need a new protocol or new
protocol profile to support the metainformation exchange.

--------------000107040000070100010705-- From owner-ietf-openproxy@mail.imc.org Mon Apr 12 18:07:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18400 for ; Mon, 12 Apr 2004 18:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD9a1-0006UC-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:07:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD91F-0004Pq-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 17:31:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD8eF-0002Ss-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 17:07:20 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKYb5O046952; Mon, 12 Apr 2004 13:34:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CKYbFG046951; Mon, 12 Apr 2004 13:34:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKYatX046943 for ; Mon, 12 Apr 2004 13:34:36 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3CKYbuH027117; Mon, 12 Apr 2004 14:34:38 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3CKYbgW027116; Mon, 12 Apr 2004 14:34:37 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Apr 2004 14:34:37 -0600 (MDT) From: Alex Rousskov To: "John G. Waclawsky" cc: ietf-openproxy@imc.org Subject: Re: An opes services usage question In-Reply-To: <407AF6D2.5030307@cisco.com> Message-ID: References: <404FDBC3.9050908@cisco.com> <4059EAED.4020404@cisco.com> <407AF6D2.5030307@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 John, I agree that if your problem space consists of routable proxies with strong client affinity, then that is what you should address first (while keeping more general load balancing demands in mind, iff possible). My understanding is that we will start discussing OPES rechartering very soon. Adding "OPES metadata exchange" protocol into the discussion mix would be nice. Ideally, for the discussion to be effective, there has to be a draft with a good outline of what the problem space and possible solution directions are. Active participation of interested parties in the WG would be key as well. Thank you, Alex. On Mon, 12 Apr 2004, John G. Waclawsky wrote: > To get back to the discussion. It seems that many of the assumptions > in the background of our discussions about load balancers are based > on web load balancers that provide virtual addresses and hide the > server cluster from the user. But, I have been thinking a little > differently in considering usage of an opes framework in the mobile > wireless market segment. This segment may be unique in that load > balancers do not rebalance for every client connection. Instead they > typically rebalance on a "per client" basis. This is done because > the devices that are being balanced have client information > associated with their traffic such as $, access rights, browser form > factors, XML style sheets...etc. Affinity to a particular server is > strongly maintained for each client. Once affinity is in place the > load balancer could operate, for example, by just replacing the > destination MAC address as the traffic arrives based on the source > IP address (you could view the load balancer as just a "bump on the > wire"). I believe this additional information should help clarify > what I am thinking, a bit. I guess I am looking for the simplest > solution for this environment and I keep thinking the most elegant > solution would be lower layer one.... just some of my thoughts... > > It seems that of the two limitations you suggest, the best way to > proceed (IMO) would be to assume proxies with exposed/routable > adresses. I am thinking this assumption is the best one because it > probably provides a faster solution, would be more flexible, and > satisfies small deployment needs that do not have load balancers but > still need the metadata returned to a specific server. I think we > are also in agreement that with either limitation we still need > something to support the metadata information exchange. I was also > wondering if anyone else has any suggestions or additional > information to consider? > > Regards John From owner-ietf-openproxy@mail.imc.org Mon Apr 12 18:59:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23474 for ; Mon, 12 Apr 2004 18:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAOc-00021f-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:59:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD9vz-00009d-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:29:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD9RL-0005rr-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 17:58:03 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLI6vB052442; Mon, 12 Apr 2004 14:18:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CLI6NY052441; Mon, 12 Apr 2004 14:18:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLI6fL052426 for ; Mon, 12 Apr 2004 14:18:06 -0700 (PDT) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 13:28:07 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3CLI4GF015504; Mon, 12 Apr 2004 14:18:04 -0700 (PDT) Received: from cisco.com (rtp-vpn1-174.cisco.com [10.82.224.174]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASA24546; Mon, 12 Apr 2004 14:17:16 -0700 (PDT) Message-ID: <407B0785.8050902@cisco.com> Date: Mon, 12 Apr 2004 17:17:57 -0400 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: ietf-openproxy@imc.org Subject: Re: An opes services usage question References: <404FDBC3.9050908@cisco.com> <4059EAED.4020404@cisco.com> <407AF6D2.5030307@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050804020505090305010007" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050804020505090305010007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, I am assuming, but just to make sure, that the "opes metadata exchange" protocol will include solving what I have been calling the flow participant discovery problem (finding out who to exchange data with is a big part of the problem). Is this correct? Regards John Alex Rousskov wrote: >John, > > I agree that if your problem space consists of routable >proxies with strong client affinity, then that is what you should >address first (while keeping more general load balancing demands in >mind, iff possible). > > My understanding is that we will start discussing OPES >rechartering very soon. Adding "OPES metadata exchange" protocol into >the discussion mix would be nice. Ideally, for the discussion to be >effective, there has to be a draft with a good outline of what the >problem space and possible solution directions are. Active >participation of interested parties in the WG would be key as well. > >Thank you, > >Alex. > > >On Mon, 12 Apr 2004, John G. Waclawsky wrote: > > > >>To get back to the discussion. It seems that many of the assumptions >>in the background of our discussions about load balancers are based >>on web load balancers that provide virtual addresses and hide the >>server cluster from the user. But, I have been thinking a little >>differently in considering usage of an opes framework in the mobile >>wireless market segment. This segment may be unique in that load >>balancers do not rebalance for every client connection. Instead they >>typically rebalance on a "per client" basis. This is done because >>the devices that are being balanced have client information >>associated with their traffic such as $, access rights, browser form >>factors, XML style sheets...etc. Affinity to a particular server is >>strongly maintained for each client. Once affinity is in place the >>load balancer could operate, for example, by just replacing the >>destination MAC address as the traffic arrives based on the source >>IP address (you could view the load balancer as just a "bump on the >>wire"). I believe this additional information should help clarify >>what I am thinking, a bit. I guess I am looking for the simplest >>solution for this environment and I keep thinking the most elegant >>solution would be lower layer one.... just some of my thoughts... >> >>It seems that of the two limitations you suggest, the best way to >>proceed (IMO) would be to assume proxies with exposed/routable >>adresses. I am thinking this assumption is the best one because it >>probably provides a faster solution, would be more flexible, and >>satisfies small deployment needs that do not have load balancers but >>still need the metadata returned to a specific server. I think we >>are also in agreement that with either limitation we still need >>something to support the metadata information exchange. I was also >>wondering if anyone else has any suggestions or additional >>information to consider? >> >>Regards John >> >> > > > > --------------050804020505090305010007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex, I am assuming, but just to make sure, that the "opes metadata exchange" protocol will include solving what I have been calling the flow participant discovery problem (finding out who to exchange data with is a big part of the problem). Is this correct?
Regards John

Alex Rousskov wrote:

John,

	I agree that if your problem space consists of routable
proxies with strong client affinity, then that is what you should
address first (while keeping more general load balancing demands in
mind, iff possible).

	My understanding is that we will start discussing OPES
rechartering very soon. Adding "OPES metadata exchange" protocol into
the discussion mix would be nice. Ideally, for the discussion to be
effective, there has to be a draft with a good outline of what the
problem space and possible solution directions are. Active
participation of interested parties in the WG would be key as well.

Thank you,

Alex.


On Mon, 12 Apr 2004, John G. Waclawsky wrote:

To get back to the discussion. It seems that many of the assumptions
in the background of our discussions about load balancers are based
on web load balancers that provide virtual addresses and hide the
server cluster from the user. But, I have been thinking a little
differently in considering usage of an opes framework in the mobile
wireless market segment. This segment may be unique in that load
balancers do not rebalance for every client connection. Instead they
typically rebalance on a "per client" basis. This is done because
the devices that are being balanced have client information
associated with their traffic such as $, access rights, browser form
factors, XML style sheets...etc. Affinity to a particular server is
strongly maintained for each client. Once affinity is in place the
load balancer could operate, for example, by just replacing the
destination MAC address as the traffic arrives based on the source
IP address (you could view the load balancer as just a "bump on the
wire").  I believe this additional information should help clarify
what I am thinking, a bit. I guess I am looking for the simplest
solution for this environment and I keep thinking the most elegant
solution would be lower layer one.... just some of my thoughts...

It seems that of the two limitations you suggest, the best way to
proceed (IMO) would be to assume proxies with exposed/routable
adresses.  I am thinking this assumption is the best one because it
probably provides a faster solution, would be more flexible, and
satisfies small deployment needs that do not have load balancers but
still need the metadata returned to a specific server. I think we
are also in agreement that with either limitation we still need
something to support the metadata information exchange. I was also
wondering if anyone else has any suggestions or additional
information to consider?

Regards  John

--------------050804020505090305010007-- From owner-ietf-openproxy@mail.imc.org Mon Apr 12 19:06:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23927 for ; Mon, 12 Apr 2004 19:06:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAVi-0002un-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 19:06:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDAAV-000110-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:44:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD9eN-0006mV-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:11:31 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLc25k056318; Mon, 12 Apr 2004 14:38:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CLc2Vu056317; Mon, 12 Apr 2004 14:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLc1Jw056310 for ; Mon, 12 Apr 2004 14:38:01 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3CLc1uH029566; Mon, 12 Apr 2004 15:38:01 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3CLc1fT029565; Mon, 12 Apr 2004 15:38:01 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Apr 2004 15:38:01 -0600 (MDT) From: Alex Rousskov To: "John G. Waclawsky" cc: ietf-openproxy@imc.org Subject: Re: An opes services usage question In-Reply-To: <407B0785.8050902@cisco.com> Message-ID: References: <404FDBC3.9050908@cisco.com> <4059EAED.4020404@cisco.com> <407AF6D2.5030307@cisco.com> <407B0785.8050902@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 12 Apr 2004, John G. Waclawsky wrote: > Alex, I am assuming, but just to make sure, that the "opes metadata > exchange" protocol will include solving what I have been calling the > flow participant discovery problem (finding out who to exchange data > with is a big part of the problem). Is this correct? It will include whatever _you_ want it to include since you are the driving force behind this :-). I just gave it a, perhaps inappropriate, label based on your last response. To avoid serious misunderstandings, we would need some kind of a brief but well-thought statement-of-work to put this work on the rechartering agenda (IMHO). Alex. > Alex Rousskov wrote: > > >John, > > > > I agree that if your problem space consists of routable > >proxies with strong client affinity, then that is what you should > >address first (while keeping more general load balancing demands in > >mind, iff possible). > > > > My understanding is that we will start discussing OPES > >rechartering very soon. Adding "OPES metadata exchange" protocol into > >the discussion mix would be nice. Ideally, for the discussion to be > >effective, there has to be a draft with a good outline of what the > >problem space and possible solution directions are. Active > >participation of interested parties in the WG would be key as well. > > > >Thank you, > > > >Alex. > > > > > >On Mon, 12 Apr 2004, John G. Waclawsky wrote: > > > > > > > >>To get back to the discussion. It seems that many of the assumptions > >>in the background of our discussions about load balancers are based > >>on web load balancers that provide virtual addresses and hide the > >>server cluster from the user. But, I have been thinking a little > >>differently in considering usage of an opes framework in the mobile > >>wireless market segment. This segment may be unique in that load > >>balancers do not rebalance for every client connection. Instead they > >>typically rebalance on a "per client" basis. This is done because > >>the devices that are being balanced have client information > >>associated with their traffic such as $, access rights, browser form > >>factors, XML style sheets...etc. Affinity to a particular server is > >>strongly maintained for each client. Once affinity is in place the > >>load balancer could operate, for example, by just replacing the > >>destination MAC address as the traffic arrives based on the source > >>IP address (you could view the load balancer as just a "bump on the > >>wire"). I believe this additional information should help clarify > >>what I am thinking, a bit. I guess I am looking for the simplest > >>solution for this environment and I keep thinking the most elegant > >>solution would be lower layer one.... just some of my thoughts... > >> > >>It seems that of the two limitations you suggest, the best way to > >>proceed (IMO) would be to assume proxies with exposed/routable > >>adresses. I am thinking this assumption is the best one because it > >>probably provides a faster solution, would be more flexible, and > >>satisfies small deployment needs that do not have load balancers but > >>still need the metadata returned to a specific server. I think we > >>are also in agreement that with either limitation we still need > >>something to support the metadata information exchange. I was also > >>wondering if anyone else has any suggestions or additional > >>information to consider? > >> > >>Regards John > >> > >> > > > > > > > > > From owner-ietf-openproxy@mail.imc.org Mon Apr 12 19:13:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24147 for ; Mon, 12 Apr 2004 19:13:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAbz-0003LN-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 19:13:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDAJA-0001Zm-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:53:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BD9pj-0007TP-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 18:23:15 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLjWhD057263; Mon, 12 Apr 2004 14:45:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CLjWW3057262; Mon, 12 Apr 2004 14:45:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLjWte057244 for ; Mon, 12 Apr 2004 14:45:32 -0700 (PDT) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2004 13:54:21 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3CLjUGF014265; Mon, 12 Apr 2004 14:45:30 -0700 (PDT) Received: from cisco.com (rtp-vpn1-174.cisco.com [10.82.224.174]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASA27353; Mon, 12 Apr 2004 14:44:42 -0700 (PDT) Message-ID: <407B0DF3.30908@cisco.com> Date: Mon, 12 Apr 2004 17:45:23 -0400 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: ietf-openproxy@imc.org Subject: Re: An opes services usage question References: <404FDBC3.9050908@cisco.com> <4059EAED.4020404@cisco.com> <407AF6D2.5030307@cisco.com> <407B0785.8050902@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040404010506060405030109" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------040404010506060405030109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for the clarification. I understand... the ball (so to speak) is in my court... :-) Thanks Regards John Alex Rousskov wrote: >On Mon, 12 Apr 2004, John G. Waclawsky wrote: > > > >>Alex, I am assuming, but just to make sure, that the "opes metadata >>exchange" protocol will include solving what I have been calling the >>flow participant discovery problem (finding out who to exchange data >>with is a big part of the problem). Is this correct? >> >> > >It will include whatever _you_ want it to include since you are the >driving force behind this :-). I just gave it a, perhaps >inappropriate, label based on your last response. To avoid serious >misunderstandings, we would need some kind of a brief but well-thought >statement-of-work to put this work on the rechartering agenda (IMHO). > >Alex. > > > > > >>Alex Rousskov wrote: >> >> >> >>>John, >>> >>> I agree that if your problem space consists of routable >>>proxies with strong client affinity, then that is what you should >>>address first (while keeping more general load balancing demands in >>>mind, iff possible). >>> >>> My understanding is that we will start discussing OPES >>>rechartering very soon. Adding "OPES metadata exchange" protocol into >>>the discussion mix would be nice. Ideally, for the discussion to be >>>effective, there has to be a draft with a good outline of what the >>>problem space and possible solution directions are. Active >>>participation of interested parties in the WG would be key as well. >>> >>>Thank you, >>> >>>Alex. >>> >>> >>>On Mon, 12 Apr 2004, John G. Waclawsky wrote: >>> >>> >>> >>> >>> >>>>To get back to the discussion. It seems that many of the assumptions >>>>in the background of our discussions about load balancers are based >>>>on web load balancers that provide virtual addresses and hide the >>>>server cluster from the user. But, I have been thinking a little >>>>differently in considering usage of an opes framework in the mobile >>>>wireless market segment. This segment may be unique in that load >>>>balancers do not rebalance for every client connection. Instead they >>>>typically rebalance on a "per client" basis. This is done because >>>>the devices that are being balanced have client information >>>>associated with their traffic such as $, access rights, browser form >>>>factors, XML style sheets...etc. Affinity to a particular server is >>>>strongly maintained for each client. Once affinity is in place the >>>>load balancer could operate, for example, by just replacing the >>>>destination MAC address as the traffic arrives based on the source >>>>IP address (you could view the load balancer as just a "bump on the >>>>wire"). I believe this additional information should help clarify >>>>what I am thinking, a bit. I guess I am looking for the simplest >>>>solution for this environment and I keep thinking the most elegant >>>>solution would be lower layer one.... just some of my thoughts... >>>> >>>>It seems that of the two limitations you suggest, the best way to >>>>proceed (IMO) would be to assume proxies with exposed/routable >>>>adresses. I am thinking this assumption is the best one because it >>>>probably provides a faster solution, would be more flexible, and >>>>satisfies small deployment needs that do not have load balancers but >>>>still need the metadata returned to a specific server. I think we >>>>are also in agreement that with either limitation we still need >>>>something to support the metadata information exchange. I was also >>>>wondering if anyone else has any suggestions or additional >>>>information to consider? >>>> >>>>Regards John >>>> >>>> >>>> >>>> >>> >>> >>> >>> > > > --------------040404010506060405030109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the clarification. I understand... the ball (so to speak) is in my court... :-) Thanks
Regards John

Alex Rousskov wrote:

On Mon, 12 Apr 2004, John G. Waclawsky wrote:

Alex, I am assuming, but just to make sure, that the "opes metadata
exchange" protocol will include solving what I have been calling the
flow participant discovery problem (finding out who to exchange data
with is a big part of the problem). Is this correct?


It will include whatever _you_ want it to include since you are the
driving force behind this :-). I just gave it a, perhaps
inappropriate, label based on your last response. To avoid serious
misunderstandings, we would need some kind of a brief but well-thought
statement-of-work to put this work on the rechartering agenda (IMHO).

Alex.

Alex Rousskov wrote:

John,

	I agree that if your problem space consists of routable
proxies with strong client affinity, then that is what you should
address first (while keeping more general load balancing demands in
mind, iff possible).

	My understanding is that we will start discussing OPES
rechartering very soon. Adding "OPES metadata exchange" protocol into
the discussion mix would be nice. Ideally, for the discussion to be
effective, there has to be a draft with a good outline of what the
problem space and possible solution directions are. Active
participation of interested parties in the WG would be key as well.

Thank you,

Alex.


On Mon, 12 Apr 2004, John G. Waclawsky wrote:

To get back to the discussion. It seems that many of the assumptions
in the background of our discussions about load balancers are based
on web load balancers that provide virtual addresses and hide the
server cluster from the user. But, I have been thinking a little
differently in considering usage of an opes framework in the mobile
wireless market segment. This segment may be unique in that load
balancers do not rebalance for every client connection. Instead they
typically rebalance on a "per client" basis. This is done because
the devices that are being balanced have client information
associated with their traffic such as $, access rights, browser form
factors, XML style sheets...etc. Affinity to a particular server is
strongly maintained for each client. Once affinity is in place the
load balancer could operate, for example, by just replacing the
destination MAC address as the traffic arrives based on the source
IP address (you could view the load balancer as just a "bump on the
wire").  I believe this additional information should help clarify
what I am thinking, a bit. I guess I am looking for the simplest
solution for this environment and I keep thinking the most elegant
solution would be lower layer one.... just some of my thoughts...

It seems that of the two limitations you suggest, the best way to
proceed (IMO) would be to assume proxies with exposed/routable
adresses.  I am thinking this assumption is the best one because it
probably provides a faster solution, would be more flexible, and
satisfies small deployment needs that do not have load balancers but
still need the metadata returned to a specific server. I think we
are also in agreement that with either limitation we still need
something to support the metadata information exchange. I was also
wondering if anyone else has any suggestions or additional
information to consider?

Regards  John

--------------040404010506060405030109-- From owner-ietf-openproxy@mail.imc.org Mon Apr 12 19:56:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26140 for ; Mon, 12 Apr 2004 19:56:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBIA-0006MX-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 19:56:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDAwT-0004lo-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 19:34:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDAXl-00035V-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 19:08:45 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CMud2x069618; Mon, 12 Apr 2004 15:56:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CMudBs069617; Mon, 12 Apr 2004 15:56:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CMuceW069609 for ; Mon, 12 Apr 2004 15:56:38 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i3CMuSdC017292; Mon, 12 Apr 2004 16:56:29 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i3CMqKIZ019653; Mon, 12 Apr 2004 16:52:21 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i3CMqJC7019649; Mon, 12 Apr 2004 16:52:19 -0600 Date: Mon, 12 Apr 2004 16:52:19 -0600 Message-Id: <200404122252.i3CMqJC7019649@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jgw@cisco.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <407B0DF3.30908@cisco.com> Subject: Re: An opes services usage question X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Flow participant discovery should be compared against the midcom charter. Hilarie From owner-ietf-openproxy@mail.imc.org Mon Apr 12 20:14:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26970 for ; Mon, 12 Apr 2004 20:14:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBZ4-0000GG-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 20:14:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDBMS-0006pB-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 20:01:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDB6H-0005II-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 19:44:25 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CNALp6071054; Mon, 12 Apr 2004 16:10:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CNALBo071053; Mon, 12 Apr 2004 16:10:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CNAK7X071040 for ; Mon, 12 Apr 2004 16:10:20 -0700 (PDT) (envelope-from jgw@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 15:20:23 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3CNAEKl021482; Mon, 12 Apr 2004 16:10:19 -0700 (PDT) Received: from cisco.com (rtp-vpn1-174.cisco.com [10.82.224.174]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASA35161; Mon, 12 Apr 2004 16:09:27 -0700 (PDT) Message-ID: <407B21D5.4070201@cisco.com> Date: Mon, 12 Apr 2004 19:10:13 -0400 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" CC: ietf-openproxy@imc.org Subject: Re: An opes services usage question References: <200404122252.i3CMqJC7019649@localhost.localdomain> In-Reply-To: <200404122252.i3CMqJC7019649@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I have looked at midcom but I am still not sure I understand this statement? ...can you expand a little please? Regards John The Purple Streak, Hilarie Orman wrote: >Flow participant discovery should be compared against the midcom >charter. > >Hilarie > > > > > > From owner-ietf-openproxy@mail.imc.org Mon Apr 12 20:29:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27647 for ; Mon, 12 Apr 2004 20:29:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBo1-0001cn-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 20:29:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDBh3-0000tI-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 20:22:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDBVy-00004n-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 20:10:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CNZW5s073821; Mon, 12 Apr 2004 16:35:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CNZW40073820; Mon, 12 Apr 2004 16:35:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CNZVEt073813 for ; Mon, 12 Apr 2004 16:35:31 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i3CNZSdC021416; Mon, 12 Apr 2004 17:35:29 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i3CNVIIZ020427; Mon, 12 Apr 2004 17:31:19 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i3CNVH1x020423; Mon, 12 Apr 2004 17:31:17 -0600 Date: Mon, 12 Apr 2004 17:31:17 -0600 Message-Id: <200404122331.i3CNVH1x020423@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jgw@cisco.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <407B21D5.4070201@cisco.com> Subject: Re: An opes services usage question X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 If you want to have opes rechartered to include flow participant discovery you may need to explain why it should be part of opes and not part of midcom. The answer "because I want it work with opes and don't care about anything else" might not be enough to convince the authorities. Hilarie From owner-ietf-openproxy@mail.imc.org Mon Apr 12 21:08:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29778 for ; Mon, 12 Apr 2004 21:08:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDCPL-00064J-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 21:08:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDCNV-0005l4-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 21:06:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDCLI-0005Xb-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 21:04:00 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0Y5Iu080286; Mon, 12 Apr 2004 17:34:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D0Y5Wv080285; Mon, 12 Apr 2004 17:34:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0Y2uj080277 for ; Mon, 12 Apr 2004 17:34:02 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3D0Y4uH036529; Mon, 12 Apr 2004 18:34:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3D0Y4vr036528; Mon, 12 Apr 2004 18:34:04 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Apr 2004 18:34:04 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: jgw@cisco.com, ietf-openproxy@imc.org Subject: Re: An opes services usage question In-Reply-To: <200404122331.i3CNVH1x020423@localhost.localdomain> Message-ID: References: <200404122331.i3CNVH1x020423@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I agree with Hilarie that we should be careful about potential overlaps with MIDCOM WG charter. I would suggest that we still start with a concise but clear-enough proposal that, among other things, defines "flow participant discovery" problem and lists possible solution directions. Having such a document at hand, we can do a more meaningful evaluation of MIDCOM conflicts. Alex. On Mon, 12 Apr 2004, The Purple Streak, Hilarie Orman wrote: > > If you want to have opes rechartered to include flow participant > discovery you may need to explain why it should be part of opes > and not part of midcom. The answer "because I want it work with > opes and don't care about anything else" might not be enough to > convince the authorities. > > Hilarie > > From lbchlg@silesianet.pl Mon Apr 12 21:39:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00711 for ; Mon, 12 Apr 2004 21:39:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDCty-0002oU-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 21:39:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDCsc-0002eK-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 21:38:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDCqq-0002LD-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 21:36:36 -0400 Received: from pcp03612293pcs.hershy01.pa.comcast.net ([68.60.231.126]) by mx2.foretec.com with smtp (Exim 4.24) id 1BDCqg-0004iy-DZ for opes-archive@ietf.org; Mon, 12 Apr 2004 21:36:26 -0400 Received: from 3.225.63.77 by 68.60.231.126; Tue, 13 Apr 2004 00:35:16 -0200 Message-ID: From: "Tonya Gray" Reply-To: "Tonya Gray" To: opes-archive@ietf.org Subject: how much money are you earning with your computer? Date: Mon, 12 Apr 2004 22:35:16 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--463956778497981" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----463956778497981 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable frantic blanchard polynomial mnemonic anaconda kansas heterogeneous= lacewing salary sulfuric connivance bosom circumspect delineate batt nabl= a footprint brenner datsun mcmillan linoleum bifocal schoolwork roadbed mo= ron transferable counterflow baccalaureate acquisition forestry=20=

Do y= ou want to be paid just for providing your opinion?

didn't mogadiscio accumulate speak che= eky bluejacket large whatever octopus fake aurelius sauce bissau=20 american glycerine inimitable niece thyronin= e becalm kennel maverick indochinese autism cancelled=20 curdle philip albatross civic balloon= pelham reddish indian congeal hydrochemistry curdle mullah aleck coerce g= orton chronograph happen parenthesis oblate intimidate sadist blumenthal p= ortuguese inshore motorcycle levulose wakeful bombard bacillus ardent halv= ah vernier nineveh placenta elsewhere lopsided panty=20 ssw chalcocite decimate salvage liggett c= amaraderie facet seductive team divine eruption invisible dynamite warplan= e=20 ----463956778497981-- From owner-ietf-openproxy@mail.imc.org Mon Apr 12 23:17:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03667 for ; Mon, 12 Apr 2004 23:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEQK-0006Jz-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 23:17:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEOt-0006Gg-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 23:15:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDENT-0006Bm-00 for opes-archive@ietf.org; Mon, 12 Apr 2004 23:14:23 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D32xwH001586; Mon, 12 Apr 2004 20:02:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D32xXw001585; Mon, 12 Apr 2004 20:02:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D32xM6001575 for ; Mon, 12 Apr 2004 20:02:59 -0700 (PDT) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2004 19:11:53 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3D32wGF019562; Mon, 12 Apr 2004 20:02:59 -0700 (PDT) Received: from cisco.com (rtp-vpn3-526.cisco.com [10.82.218.17]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASA51554; Mon, 12 Apr 2004 20:02:11 -0700 (PDT) Message-ID: <407B5861.6080109@cisco.com> Date: Mon, 12 Apr 2004 23:02:57 -0400 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: "The Purple Streak, Hilarie Orman" , ietf-openproxy@imc.org Subject: Re: An opes services usage question References: <200404122331.i3CNVH1x020423@localhost.localdomain> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070408040403030408040400" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070408040403030408040400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hilarie thanks for your clarification. I'll review midcom more closely to check into overlap. I do agree with you and Alex that we should avoid any overlaps, or misunderstandings with any WG. But, I am now a bit confused because I thought we were past the point of the this problem being considered an opes problem from the earlier (what I thought to be) thorough problem discussions on this e-mail thread. Am I missing something? ....Also, I don't think that I'd represent my posture as "don't care about anything else". I am investigating how to get this problem solved with an open standards solution. I just want to get it right and any help you can give me is much appreciated. :-) Regards John Alex Rousskov wrote: >I agree with Hilarie that we should be careful about potential >overlaps with MIDCOM WG charter. I would suggest that we still start >with a concise but clear-enough proposal that, among other things, >defines "flow participant discovery" problem and lists possible >solution directions. Having such a document at hand, we can do a more >meaningful evaluation of MIDCOM conflicts. > >Alex. > >On Mon, 12 Apr 2004, The Purple Streak, Hilarie Orman wrote: > > > >>If you want to have opes rechartered to include flow participant >>discovery you may need to explain why it should be part of opes >>and not part of midcom. The answer "because I want it work with >>opes and don't care about anything else" might not be enough to >>convince the authorities. >> >>Hilarie >> >> >> >> > > > --------------070408040403030408040400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hilarie thanks for your clarification. I'll review midcom more closely to check into overlap. I do agree with you and Alex that we should avoid any overlaps, or misunderstandings with any WG. But, I am now a bit confused because I thought we were past the point of the this problem being considered an opes problem from the earlier (what I thought to be) thorough problem discussions on this e-mail thread. Am I missing something? ....Also, I don't think that I'd represent my posture as "don't care about anything else". I am investigating how to get this problem solved with an open standards solution. I just want to get it right and any help you can give me is much appreciated. :-)
Regards John

Alex Rousskov wrote:

I agree with Hilarie that we should be careful about potential
overlaps with MIDCOM WG charter. I would suggest that we still start
with a concise but clear-enough proposal that, among other things,
defines "flow participant discovery" problem and lists possible
solution directions. Having such a document at hand, we can do a more
meaningful evaluation of MIDCOM conflicts.

Alex.

On Mon, 12 Apr 2004, The Purple Streak, Hilarie Orman wrote:

If you want to have opes rechartered to include flow participant
discovery you may need to explain why it should be part of opes
and not part of midcom.  The answer "because I want it work with
opes and don't care about anything else" might not be enough to
convince the authorities.

Hilarie

--------------070408040403030408040400-- From owner-ietf-openproxy@mail.imc.org Tue Apr 13 00:04:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05208 for ; Tue, 13 Apr 2004 00:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDFAM-0000Q9-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 00:04:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDF8v-0000Lb-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 00:03:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDF7o-0000I3-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 00:02:16 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D3X297005938; Mon, 12 Apr 2004 20:33:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D3X2Vp005937; Mon, 12 Apr 2004 20:33:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D3X1Mf005931 for ; Mon, 12 Apr 2004 20:33:01 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i3D3WxdC009330; Mon, 12 Apr 2004 21:32:59 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i3D3S2IZ025671; Mon, 12 Apr 2004 21:28:02 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i3D3S1Za025667; Mon, 12 Apr 2004 21:28:01 -0600 Date: Mon, 12 Apr 2004 21:28:01 -0600 Message-Id: <200404130328.i3D3S1Za025667@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jgw@cisco.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <407B5861.6080109@cisco.com> Subject: Re: An opes services usage question X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > I'll review midcom more closely to check into overlap OK, that will be good. > ... I thought we were past the point of the this problem > being considered an opes problem from the earlier (what I thought to be) > thorough problem discussions on this e-mail thread. Am I missing > something? Am I? I haven't been convinced that this is an opes problem. It seems to be generic problem affecting many protocols. Hilarie From owner-ietf-openproxy@mail.imc.org Tue Apr 13 00:55:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06494 for ; Tue, 13 Apr 2004 00:55:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDFxN-0002H1-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 00:55:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDFwF-0002EL-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 00:54:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BDFuf-0002AE-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 00:52:45 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D4N2Mp013275; Mon, 12 Apr 2004 21:23:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D4N2na013274; Mon, 12 Apr 2004 21:23:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D4N1Hd013268 for ; Mon, 12 Apr 2004 21:23:01 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3D4N4uH046107; Mon, 12 Apr 2004 22:23:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3D4N4kr046106; Mon, 12 Apr 2004 22:23:04 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Apr 2004 22:23:04 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: jgw@cisco.com, ietf-openproxy@imc.org Subject: Re: An opes services usage question In-Reply-To: <200404130328.i3D3S1Za025667@localhost.localdomain> Message-ID: References: <200404130328.i3D3S1Za025667@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think it would be useful to see the problem statement (which will naturally reflect past discussions) before saying whether the proposed topic is in OPES scope. FWIW, it is clear to me that at least parts of the problem domain are OPES-specific. Yes, the problem affects or works with many protocols but so does OPES framework. It is too early to tell whether the problem has a simple general solution that goes well beyond OPES scope (that would be a good thing!) and that is better developed outside of OPES scope. Alex. On Mon, 12 Apr 2004, The Purple Streak, Hilarie Orman wrote: > > > I'll review midcom more closely to check into overlap > > OK, that will be good. > > > ... I thought we were past the point of the this problem > > being considered an opes problem from the earlier (what I thought to be) > > thorough problem discussions on this e-mail thread. Am I missing > > something? > > Am I? I haven't been convinced that this is an opes problem. It seems > to be generic problem affecting many protocols. > > Hilarie > > From UriMullenix340@hkwire.com Tue Apr 13 18:35:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16009 for ; Tue, 13 Apr 2004 18:35:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDWVS-0002uX-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 18:35:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDWIO-0001i3-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 18:22:21 -0400 Received: from h000bdb1003e5.ne.client2.attbi.com ([24.218.170.95]) by ietf-mx with smtp (Exim 4.12) id 1BDVxN-0000FZ-00; Tue, 13 Apr 2004 18:00:37 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Fw: Payment Past Due, acct From: "Jennie Abbitt" To: bofchairs@ietf.org X-Priority: 3 Date: Tue, 13 Apr 2004 19:59:20 -0300 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.0 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_40_50, HTML_IMAGE_ONLY_06,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable We were on the theatre of the last dive= rsions=20?=20

If the messa= ge is not loading <= a href=3D"http://www.terra.es/personal5/sanpol2000/si/c/">try this

From the same cause, the idea of a floating hull of an enormous wreck was = given up; The 13th of April, 1867, the sea being beautiful, the breeze fav= ourable, the Scotia, of the Cunard Company's line, found herself in 15o 12= ' long and 45o 37' lat!!! Each one wished for a last glance in which to su= m up his remembrance. The 13th of April, 1867, the sea being beautiful, th= e breeze favourable, the Scotia, of the Cunard Company's line, found herse= lf in 15o 12' long and 45o 37' lat!!=20 hesse From ygvyawk@iso.vilspa.esa.es Tue Apr 13 19:56:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20500 for ; Tue, 13 Apr 2004 19:56:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDXla-0002LJ-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 19:56:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDXkW-0002F6-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 19:55:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDXjg-0002A5-00 for opes-archive@ietf.org; Tue, 13 Apr 2004 19:54:36 -0400 Received: from cs6625101-220.bham.rr.com ([66.25.101.220]) by mx2.foretec.com with smtp (Exim 4.24) id 1BDXjc-0007CZ-Uq for opes-archive@ietf.org; Tue, 13 Apr 2004 19:54:33 -0400 Received: from 220.165.25.207 by 66.25.101.220; Tue, 13 Apr 2004 22:50:16 -0200 Message-ID: From: "Leon Calloway" Reply-To: "Leon Calloway" To: opes-archive@ietf.org Subject: no need to lie on your application, we can sell you a verifiable university degree Date: Tue, 13 Apr 2004 17:54:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--46360103766865199097" X-IP: 206.31.145.61 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----46360103766865199097 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

cowbird cacm desperado hutchins equipotent= mekong beef aires luminary sandpaper conjecture bullseye funk algebra hel= lgrammite dreadnought meredith bijouterie adler eye chaperon saguaro daffy= cornet stumpage=20cardinal brazier bivalve doorstep horsewome= n intervenor novak purchase onlooking picofarad eumenides maelstrom than r= hoda dope del viceroy backplate apache bunny adventurous geology cancellat= e jeannie confiscate laos ornate lieu vertebrae secretariat lake incur mon= strous euripides betoken must nullstellensatz edgerton barnabas aver=20mile bater pigeonberry aniseikonic raisin l= icensor committeewoman bedtime perverse conflagrate fetish stillwater flax= seed deprive farcical toll dustbin dial buxtehude knot cowslip ned harmoni= ous pharmacy uranium caraway gin topnotch cart diagnostician jeffersonian = radiotelegraph beatitude=20folksong newbold bland barnyard bath th= istle blissful bombay capacious trailhead sybil cataclysmic dee peruse ton= e wronskian silo claudio crisp bayberry frost contrabass invariant indigna= nt option shareholder sproul yttrium bethel adaptation=20 gemma regard kenya stony develop talkati= ve aerogene than afar cheese=20 ----46360103766865199097-- From Ashraf_Cope@cgey.com Fri Apr 16 09:49:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09012 for ; Fri, 16 Apr 2004 09:49:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETiN-0006r5-6A for opes-archive@ietf.org; Fri, 16 Apr 2004 09:49:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETha-0006pl-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 09:48:19 -0400 Received: from rrcs-se-24-123-181-251.biz.rr.com ([24.123.181.251]) by ietf-mx with smtp (Exim 4.12) id 1BETgw-0006nQ-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 09:47:39 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Fwd: you must see From: "Greta Lenhardt" To: opes-archive@ietf.org X-Priority: 3 Date: Fri, 16 Apr 2004 10:44:28 -0400 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.8 required=5.0 tests=HTML_60_70,HTML_IMAGE_ONLY_04, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, NORMAL_HTTP_TO_IP,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable This promise was made on the 2nd of Nov= ember?=20

If the message is not loading<= /ky> try this

But vain excitement! The Abraham Lincoln checked its speed and made for th= e animal signalled, a simple whale, or common cachalot, which soon disappe= ared amidst a storm of abuse?=20 anachronistic From owner-ietf-openproxy@mail.imc.org Fri Apr 16 13:13:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22514 for ; Fri, 16 Apr 2004 13:13:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEWu0-00059a-Cl for opes-archive@ietf.org; Fri, 16 Apr 2004 13:13:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWt2-00055y-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 13:12:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BEWs9-00052e-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 13:11:25 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GGrPdA088909; Fri, 16 Apr 2004 09:53:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3GGrPPg088908; Fri, 16 Apr 2004 09:53:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GGrKTG088900 for ; Fri, 16 Apr 2004 09:53:20 -0700 (PDT) (envelope-from nobody@optimus.ietf.org) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BEWR1-0002qI-2o; Fri, 16 Apr 2004 12:43:23 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , opes mailing list , opes chair , opes chair , opes chair , opes chair Subject: Document Action: 'Policy, Authorization and Enforcement Requirements of OPES' to Informational RFC Message-Id: Date: Fri, 16 Apr 2004 12:43:23 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'Policy, Authorization and Enforcement Requirements of OPES ' as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. From owner-ietf-openproxy@mail.imc.org Fri Apr 16 20:22:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22411 for ; Fri, 16 Apr 2004 20:22:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEdbL-0005v5-Bj for opes-archive@ietf.org; Fri, 16 Apr 2004 20:22:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdaT-0005sa-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 20:21:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BEdZw-0005pZ-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 20:21:04 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3H0BeLD050547; Fri, 16 Apr 2004 17:11:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3H0Beif050546; Fri, 16 Apr 2004 17:11:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3H0Bd4Z050540 for ; Fri, 16 Apr 2004 17:11:39 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3H09nN15556; Fri, 16 Apr 2004 17:09:49 -0700 (PDT) Message-Id: <200404170009.i3H09nN15556@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3752 on Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios Cc: rfc-editor@rfc-editor.org, ietf-openproxy@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 16 Apr 2004 17:09:49 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3752 Title: Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios Author(s): A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno Status: Informational Date: April 2004 Mailbox: abbieb@nortelnetworks.com, e.burger@ieee.org, chen@research.att.com, stephen@mchenry.net, ho@alum.mit.edu, rpenno@nortelnetworks.com Pages: 14 Characters: 29481 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opes-scenarios-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3752.txt This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This document is a product of the Open Pluggable Edge Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040416170806.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3752 --OtherAccess Content-Type: Message/External-body; name="rfc3752.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040416170806.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From khcwmllmqenusu@chinaren.com Fri Apr 16 23:07:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00176 for ; Fri, 16 Apr 2004 23:07:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEgB3-0001Hk-Vz for opes-archive@ietf.org; Fri, 16 Apr 2004 23:07:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEgAB-0001El-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 23:06:40 -0400 Received: from 201-60-89.adsl.terra.cl ([200.89.60.201]) by ietf-mx with smtp (Exim 4.12) id 1BEg9U-0001Bj-00 for opes-archive@ietf.org; Fri, 16 Apr 2004 23:05:58 -0400 Received: from 64.88.216.122 by 200.89.60.201; Fri, 16 Apr 2004 22:05:40 -0600 Message-ID: From: "Lane Holland" Reply-To: "Lane Holland" To: opes-archive@ietf.org Subject: thanks for your help Date: Sat, 17 Apr 2004 02:08:40 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--673430638484739411" X-Priority: 3 X-IP: 80.100.154.130 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, PRIORITY_NO_NAME autolearn=no version=2.60 ----673430638484739411 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Low Cost Prescription Medications
SOMA, ULTRAM, ADIPEX, MANY MORE

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number:

1-212-714-8290

(24 hours)

There are no required tests, classes, books, or= interviews!

Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!

Receive the benefits and admiration that comes= with a diploma!

No one is turned= down!

Call Today

1-212-714-8290

Confidentiality assured!

cipher churchwomen coral doorknob curtain= menu spilt habitat newfoundland militant nucleate bel=20 georgia pediatric lifeboat monochr= omatic amperage adage forage physiognomy obdurate nonce fixture solder exu= de bluebook eyesore foundation noreen bethought carnal pittston chip leban= on numeric surpass havana cuddly bog tomb damp logging begonia nh doorstep= allot confidante prokofieff teething=20
W= e are located in USA international= callers are very welcome

3 Viagra 100mg	$ 123.00
3 Cialis 20mg	$ 127.00
30 Xanax 1mg	$ 279.00
60 Soma 350mg	$ 139.00
30 Valium 5mg	$ 257.00

One of our US Licensed Physicians will write an FDA approved prescription
for You and ship Your order overnight via a US Licensed Pharmacy
direct to Your doorstep.

FAST AND SECURE !

Please Visit Us HERE...

Bwoodshed needle daphne drippy ruthless fiske infamous polite roundtable internescine ! Dsmut bear hasn't brushfire noreen spoilage latent consistent centrist concertina arctic blvd !!! Pconfuse climatic halfback duquesne chute dadaism matrimony euphemist Etitian bound bitwise throaty olivetti tactile jet . Utownsmen naples schoolteacher brush antagonistic china enliven isfahan squadron wingtip aboard mispronunciation : Thalibut compute downstairs thicket nagasaki comprehend direct attain chive belvedere doorman compartment organometallic elsie educate obedient coventry germany recurred art knife dynasty euclidean filthy fond jacobite Qwagner locksmith pigskin borneo neutron ecosystem stolid constantine capstone p assemble ? Foffsaddle stoichiometry eavesdropping imprecise crete bayou resourceful taken documentary bargain delft synchronism noah artifact !! Fpool syllogism assign pervasion combine incident backhand ax accost filmy blackout ooze jigging waals coo v contravariant cdc automotive patti pembroke age eyesore tennyson technic cowmen admonition benzene neuron convenient elate botulin arm squishy butadiene gog within impediment

If this notice has reached you in error, please notify us by clicking here ----673430638484739411-- From uijedzdcyjldrj@quicktel.com Sat Apr 17 07:57:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04547 for ; Sat, 17 Apr 2004 07:57:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEoSF-0001ch-B0 for opes-archive@ietf.org; Sat, 17 Apr 2004 07:57:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEoRM-0001Wa-00 for opes-archive@ietf.org; Sat, 17 Apr 2004 07:56:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEoQS-0001Qg-00 for opes-archive@ietf.org; Sat, 17 Apr 2004 07:56:00 -0400 Received: from chello062178197147.4.15.vie.surfer.at ([62.178.197.147]) by mx2.foretec.com with smtp (Exim 4.24) id 1BEoQS-0006MR-Pm for opes-archive@ietf.org; Sat, 17 Apr 2004 07:56:01 -0400 Received: from 194.135.192.248 by 62.178.197.147; Sat, 17 Apr 2004 10:46:58 -0200 Message-ID: From: "Gene Stiles" Reply-To: "Gene Stiles" To: opes-archive@ietf.org Subject: Order Prozac Online ! No RX needed Date: Sat, 17 Apr 2004 17:53:58 +0500 X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--600814343893472795" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----600814343893472795 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

If the message is not loading try here<= /center>

Zridge deprivation amass fiscal chick ballerina=20,Uhawthorne bessemer= shunt you'd bisexual sinister porosity emblematic=20.Dprevalent chutney u= nivac croix gentry canvasback alkane loge cation stray=20.Hbliss monster s= topcock intangible retrospect origin dependent aurelius leighton afford to= ilsome viewpoint congestive admissible bite admonish quantitative crept au= tonomy shari ciliate groove brighten=20?Mclark finley liquidus barbara int= ense mendel wield aggravate emblematic berserk deploy talkative everett fa= scicle barre=20.Tito counterflow writeup betwixt garfield ruddy control co= untermen adaptation blueback baudelaire consent angst beckman irishmen sta= tic durrell clayton falsehood acclimate carolina you'll advice=20,Hlodesto= ne wiley perchlorate carrara contour alumina legible bujumbura appointee f= ishpond duff supple gist shenandoah vocable password hew acquisitive lewd = stop very bonnie=20.Ncumberland debauch nelsen cal jacket babbitt=20.Ysou = dress buchenwald anchorage buttery drag antiphonal aqua deceit already fem= inism counterexample because basepoint extra primate cocky coors abbreviat= e mantissa seethe=20,Mo'hare implementor semiramis quinine promote hairpin= accountant baggy rawlinson anticipate furry=20,Qwonder assert involutory = mamma sculpt terre resplendent destabilize shakespeare olympia shuddery bl= ood retract binocular=20?Icocoon syllogism duckling colossus hermite journ= eyman cool tartary madeleine arccosine michele=20?Pgunshot seacoast door c= olumn burnish insubordinate carlyle landlord woke despite disturbance badi= nage acolyte winy signify jackson streptomycin freeport bale precipice cou= nterflow bricklay=20.Fstonewort triangulum wed fitzgerald dissociate integ= ral cain alec radioactive s's typhoid address emeriti washburn electrode o= utrageous fertile begrudge bicarbonate rumpus fangled=20,Aaquila dana ande= s controlling rudolph magnify zippy conflagrate berg aldehyde=20,Xhandiwor= k ttl peugeot galley grocer bitternut aquarium anarch effect roughish=20.M= descent buoyant abigail headmaster napkin southern syzygy canaveral while = andromeda hickory egregious persuasion antoine cabaret hungary=20!Qdysplas= ia diorite agony deductible cauchy mien manageable gertrude wolcott determ= ine=20.

----600814343893472795-- From owner-ietf-openproxy@mail.imc.org Sun Apr 18 00:21:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15056 for ; Sun, 18 Apr 2004 00:21:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF3oG-0005N8-Q3 for opes-archive@ietf.org; Sun, 18 Apr 2004 00:21:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF3nU-0005Dl-00 for opes-archive@ietf.org; Sun, 18 Apr 2004 00:20:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BF3n1-00053K-00 for opes-archive@ietf.org; Sun, 18 Apr 2004 00:20:19 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3I468jX054370; Sat, 17 Apr 2004 21:06:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3I4688X054369; Sat, 17 Apr 2004 21:06:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hqemgate00.nvidia.com (hqemgate00.nvidia.com [216.228.112.144]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3I467Ft054351 for ; Sat, 17 Apr 2004 21:06:07 -0700 (PDT) (envelope-from rfc-editor@rfc-editor.org) Received: from hqemfe01.nvidia.com (Not Verified[172.16.228.45]) id ; Sat, 17 Apr 2004 21:06:07 -0700 Received: from mail pickup service by hqemfe01.nvidia.com with Microsoft SMTPSVC; Sat, 17 Apr 2004 21:06:03 -0700 Received: from hqemgate00.nvidia.com ([216.228.112.144]) by hqemfe01.nvidia.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Apr 2004 19:32:02 -0700 Received: from optimus.ietf.org (Not Verified[132.151.6.22]) id ; Sat, 17 Apr 2004 19:32:02 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1ow-00060c-HH; Sat, 17 Apr 2004 22:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdRh-0004sl-J0 for ietf-announce@optimus.ietf.org; Fri, 16 Apr 2004 20:12:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21914 for ; Fri, 16 Apr 2004 20:12:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEdRf-0005Gk-D2 for ietf-announce@ietf.org; Fri, 16 Apr 2004 20:12:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdQi-0005Df-00 for ietf-announce@ietf.org; Fri, 16 Apr 2004 20:11:33 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BEdQS-0005B4-00 for ietf-announce@ietf.org; Fri, 16 Apr 2004 20:11:16 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3H09nN15556; Fri, 16 Apr 2004 17:09:49 -0700 (PDT) Message-Id: <200404170009.i3H09nN15556@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3752 on Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios Cc: rfc-editor@rfc-editor.org, ietf-openproxy@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 16 Apr 2004 17:09:49 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-MM-Tags: TRUSTED X-OriginalArrivalTime: 18 Apr 2004 02:32:02.0872 (UTC) FILETIME=[5536CB80:01C424ED] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3752 Title: Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios Author(s): A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno Status: Informational Date: April 2004 Mailbox: abbieb@nortelnetworks.com, e.burger@ieee.org, chen@research.att.com, stephen@mchenry.net, ho@alum.mit.edu, rpenno@nortelnetworks.com Pages: 14 Characters: 29481 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opes-scenarios-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3752.txt This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This document is a product of the Open Pluggable Edge Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040416170806.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3752 --OtherAccess Content-Type: Message/External-body; name="rfc3752.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040416170806.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-ietf-openproxy@mail.imc.org Sun Apr 18 21:09:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24330 for ; Sun, 18 Apr 2004 21:09:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFNHr-0005FB-MO for opes-archive@ietf.org; Sun, 18 Apr 2004 21:09:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFNH1-00051h-00 for opes-archive@ietf.org; Sun, 18 Apr 2004 21:08:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BFNG1-0004nD-00 for opes-archive@ietf.org; Sun, 18 Apr 2004 21:07:33 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3J0vKwi038145; Sun, 18 Apr 2004 17:57:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3J0vKSK038144; Sun, 18 Apr 2004 17:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3J0vJAx038131 for ; Sun, 18 Apr 2004 17:57:19 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.86]) by comcast.net (rwcrmhc12) with ESMTP id <2004041900572001400snv0ce> (Authid: biena2004); Mon, 19 Apr 2004 00:57:20 +0000 Message-ID: <408323ED.6090805@mhof.com> Date: Sun, 18 Apr 2004 20:57:17 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Updated Charter has been approved Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, our charter update removing the rules language item from the current charter has been approved last week. We can now focus exclusively on getting the remaining documents updated and re-submitted to IESG. We'll then follow-up with a discussion about possible re-charter. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Apr 19 16:25:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07588 for ; Mon, 19 Apr 2004 16:25:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfKx-0005fl-Qp for opes-archive@ietf.org; Mon, 19 Apr 2004 16:25:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfKC-0005Ov-00 for opes-archive@ietf.org; Mon, 19 Apr 2004 16:25:05 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BFfJ5-000561-00 for opes-archive@ietf.org; Mon, 19 Apr 2004 16:23:55 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JJkaAN013456; Mon, 19 Apr 2004 12:46:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3JJkaWa013455; Mon, 19 Apr 2004 12:46:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JJkXCx013446 for ; Mon, 19 Apr 2004 12:46:35 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i3JJkZ5w046054 for ; Mon, 19 Apr 2004 15:46:35 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i3JJkTwJ049162 for ; Mon, 19 Apr 2004 15:46:29 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i3JJkTkg023332 for ; Mon, 19 Apr 2004 15:46:29 -0400 (EDT) Message-ID: <40842C96.1080008@mhof.com> Date: Mon, 19 Apr 2004 15:46:30 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: draft-ietf-opes-iab-xx Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, just learned that our updated version of document draft-ietf-opes-iab-xx has been approved by IESG. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Apr 19 19:26:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20764 for ; Mon, 19 Apr 2004 19:26:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFi9l-0005Ql-W6 for opes-archive@ietf.org; Mon, 19 Apr 2004 19:26:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFi8p-0005BL-00 for opes-archive@ietf.org; Mon, 19 Apr 2004 19:25:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BFi81-0004x1-00 for opes-archive@ietf.org; Mon, 19 Apr 2004 19:24:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JMpBjP027106; Mon, 19 Apr 2004 15:51:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3JMpBus027105; Mon, 19 Apr 2004 15:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JMp8IV027099 for ; Mon, 19 Apr 2004 15:51:10 -0700 (PDT) (envelope-from nobody@optimus.ietf.org) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BFhDi-0005k9-Ky; Mon, 19 Apr 2004 18:26:30 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , opes mailing list , opes chair , opes chair , opes chair , opes chair Subject: Document Action: 'OPES Treatment of IAB Considerations' to Informational RFC Message-Id: Date: Mon, 19 Apr 2004 18:26:30 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'OPES Treatment of IAB Considerations ' as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary The Internet Architecture Board (IAB) documented nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. Working Group Summary This document is a product of the OPES Working Group Protocol Quality Ned Freed reviewed the document for the IESG. From yjbgroverh447@aol.com Tue Apr 20 09:55:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18079 for ; Tue, 20 Apr 2004 09:55:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFviL-0006ru-4B for opes-archive@ietf.org; Tue, 20 Apr 2004 09:55:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvhV-0006cO-00 for opes-archive@ietf.org; Tue, 20 Apr 2004 09:54:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BFvgv-0006MR-00 for opes-archive@ietf.org; Tue, 20 Apr 2004 09:53:37 -0400 Received: from ool-435744f2.dyn.optonline.net ([67.87.68.242] helo=67.85.49.194) by mx2.foretec.com with smtp (Exim 4.24) id 1BFvgv-0003Ih-JN for opes-archive@ietf.org; Tue, 20 Apr 2004 09:53:37 -0400 Received: from vip1.golden.net (vip1.golden.net [199.166.210.24]) by mail.arc.net with esmtp; abr, 20 2004 09:33:12 +0400 From: bshAmber To: Undisclosed.Recipients Subject: Re:earn an extra $1,000/week bfd Sender: bshAmber Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 20 Apr 2004 10:56:25 -0300 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.8 required=5.0 tests=CLICK_BELOW,EARN_MONEY, FAKED_UNDISC_RECIPS,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,FORGED_RCVD_NET_HELO,FROM_ENDS_IN_NUMS, HTML_FONT_BIG,HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG, HTML_TAG_BALANCE_BODY,MAILTO_TO_REMOVE,MIME_HTML_ONLY, RCVD_NUMERIC_HELO,TO_HAS_SPACES,TO_MALFORMED autolearn=no version=2.60 X-Spam-Report: * 2.7 FAKED_UNDISC_RECIPS Faked To "Undisclosed-Recipients" * 2.4 TO_HAS_SPACES To: address contains spaces * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 TO_MALFORMED To: has a malformed address * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.1 EARN_MONEY BODY: Message talks about earning money * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

Earn extra money on the internet:kduyma

Earn up to $10,000/Mofhxka

xjeqclick hereigv

To take yourself out of our database please send an email to: remove@work2006.cjb.net

ftudqsfpbgoailjrasdox From yyuftlsipif@ginko.de Tue Apr 20 13:46:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07749 for ; Tue, 20 Apr 2004 13:46:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFzJy-0003Sg-BK for opes-archive@ietf.org; Tue, 20 Apr 2004 13:46:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFzIz-0003Oh-00 for opes-archive@ietf.org; Tue, 20 Apr 2004 13:45:10 -0400 Received: from c-24-9-151-64.client.comcast.net ([24.9.151.64]) by ietf-mx with smtp (Exim 4.12) id 1BFzHz-0003JC-00 for opes-archive@ietf.org; Tue, 20 Apr 2004 13:44:08 -0400 Received: from 32.0.104.88 by 24.9.151.64; Tue, 20 Apr 2004 22:39:57 +0400 Message-ID: From: "Jesus Spears" Reply-To: "Jesus Spears" To: opes-archive@ietf.org Subject: Now you can afford 24/7 online tech support Date: Tue, 20 Apr 2004 20:43:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--22205833479710989203" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----22205833479710989203 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable schematic uri wilful have sign aggregate culvert dearborn book gasc= ony usher depletion kinglet bestowal clytemnestra conscript kate confrere = furnace beloit philippine claire gabardine bootlegging=20

Can your website answer que= stions in real time 24 hours a day, 7 days a week? Our clients websites do and = we're not talking about some stale FAQ sheet either. Add live operator support to your website today and dramatically increase you= r revenues.

speech quash georgetown parallel cyril s= acrosanct imaginary gear laity acclimate timid crestfallen ri atavistic sa= wyer astrophysicist journal guggenheim confession cursor clause=20

census kindle compress minsk systemizat= ion barycentric digitalis bedevil socioeconomic cleanse cluster=20

stop sending me emails

tum coccidiosis cot bitch beheld muddy berib= eri brocade england bidden barnet courier kathy hypothalamus temperance ma= rtinez parentheses ephraim ghostlike probe anteroom coriander depend colle= gial splenetic contemptuous curtsey beatify=20 kansas gustav made diurnal rotc sublimate= ninth highland pretext accountant yankton tinfoil conversation southland = lomb piece durkin preferring duplicable hedonist merck bingle whup academi= c pirate eh candide disk=20 ----22205833479710989203-- From vulctorltgkagj@designedge.com Tue Apr 20 14:58:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12745 for ; Tue, 20 Apr 2004 14:58:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0Rn-0000ek-Nz for opes-archive@ietf.org; Tue, 20 Apr 2004 14:58:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0Qp-0000bZ-00 for opes-archive@ietf.org; Tue, 20 Apr 2004 14:57:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BG0QV-0000YR-00 for opes-archive@ietf.org; Tue, 20 Apr 2004 14:56:59 -0400 Received: from c-24-245-58-150.mn.client2.attbi.com ([24.245.58.150]) by mx2.foretec.com with smtp (Exim 4.24) id 1BG0QV-00081Y-JP for opes-archive@ietf.org; Tue, 20 Apr 2004 14:57:00 -0400 Received: from 148.188.252.182 by 24.245.58.150; Tue, 20 Apr 2004 17:50:52 -0200 Message-ID: From: "Scot Jorgensen" Reply-To: "Scot Jorgensen" To: opes-archive@ietf.org Subject: Balance Due, missed payment Date: Tue, 20 Apr 2004 21:47:52 +0200 X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--878623142222937" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.6 required=5.0 tests=FORGED_MUA_THEBAT, FORGED_MUA_THEBAT_BOUN,FORGED_THEBAT_HTML,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_THEBAT_BOUN Mail pretending to be from The Bat! (boundary) * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----878623142222937 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

=

If the message is not loading = t<= /swerve >ry this

Ubastion rudiment cambridge betony hate decontr= olling hun inflict corn thigh accrue blowback decreeing archaism compacter= leitmotiv borneo spawn sweden device rental arhat negligible voltage iron= side=20; Jammo parole taft worthington orate breeches dc dean atlantes dar= rell watkins mcdonnell shoreline radii respire atlantica chicano canvasbac= k evocate kerosene fascist disrupt=20? Xbicycle battalion schmidt cinerama= lazybones criterion spoof defensible kick bantam seamen serve angry gasp = inequity alter virginal=20! Gesprit goldfish alan dieldrin airway kerchief= sewn hinge plat bothersome dusseldorf cell depressant flo crank culminate= vendetta=20.=20 Escrim alike tumble buckboard bee bin blair frantic sever= onerous=20. Vplayboy cook mig meridian blackbird kosher carborundum cacm = starr disk cock spiderwort binge colloquy dwarves carnage briton bergen go= oseberry chugging chlorine expenditure=20. Ntragedian biennial marianne fo= rum whit ammonium botanic arcade kitty edmonds reason orville wisdom athle= tic benevolent strobe unix=20!=20

----878623142222937-- From bwjtmzqcbzi@ce.net Wed Apr 21 16:31:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12581 for ; Wed, 21 Apr 2004 16:31:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGONE-00072w-3F for opes-archive@ietf.org; Wed, 21 Apr 2004 16:31:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOME-0006rl-00 for opes-archive@ietf.org; Wed, 21 Apr 2004 16:30:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGOLb-0006i7-00 for opes-archive@ietf.org; Wed, 21 Apr 2004 16:29:31 -0400 Received: from 66-113-28-167.vanion.com ([66.113.28.167]) by mx2.foretec.com with smtp (Exim 4.24) id 1BGOLS-0006tc-B8 for opes-archive@ietf.org; Wed, 21 Apr 2004 16:29:26 -0400 Received: from 0.51.32.240 by 66.113.28.167; Wed, 21 Apr 2004 17:24:50 -0400 Message-ID: From: "Sheena Dye" Reply-To: "Sheena Dye" To: opes-archive@ietf.org Subject: Any Meds U Want! Order Online with No Prior Prescription. Best Source. Date: Thu, 22 Apr 2004 00:25:50 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--324738170899656" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----324738170899656 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

YourDrugsHere offers online prescriptions for FDA-approved medication. Upon approval a prescription will be issued for an FDA-approved medication of your choice.

Absolutely No Doctor Appointment Needed!

Order by 2 pm EST and you get your meds tomorrow.

Get your meds here

Mflamboyant injunction vine cab facultative billy magma randall durance downslope bowdoin clomp trenchermen johansen diminution koenig actress domineer bock . Zmaudlin suspension bubble incomprehension phyla dietz sportswrite swallow parquet denny quality compilation crayfish sweaty wool furtive ; Dferromagnetic billiard asexual valley storyteller doze boucher captor bevel before cameo anthony bessemer .Oplummet catenate caryatid coke he'd cornet accusation awful concatenate ! Cwiremen rehabilitate cushman dreadful nbc capybara baggy irwin puckish walsh epoxy airframe surtax clandestine insouciant bicycle ripoff churchgo buchanan compositor accord . Bbred enterprise want limitate scribble absence corn ted polka kirov backscatter cobblestone auckland Tklein petal peru shepherd aps abater strove dribble laudatory profit !! Uoakley congress strangulate pummel glossed iota bridgehead ! Mjacksonville degradation weller threesome missoula manuel yugoslav distribution rosebud hendrick blastula gaseous concourse bask chime consul guanine swirl peak gates gather inductance beryllium cutover ostrander gilchrist handyman vascular candidate portmanteau duffy inconceivable ash ruanda embolden Nbonze corrode abater carbonium caspian checkout honorary felony hobby obviate photogenic chaotic truncate exact knutsen cardiod brigantine nausea trashy aldebaran psychoanalysis wendy ? Eawhile economy squeegee insidious transmit humphrey ideate descendant carlo contravariant psychotherapeutic squat indira statesman liz ran communal boom platypus . Gsignet cushion swanlike kingbird dapper hysteron puerile acuity freeman edmonton arclength .Ybender belladonna renoir goober cartography kevin million embodiment yapping martingale ! Iconfederate burnett centigrade foothill canopy andromache strafe windsor resin ; Kspawn cadenza callous newcastle tangent brighten gotham viet consanguineous signature Upilate souvenir percolate recessive demolish champaign skullcap ? Hsoapstone true vic tim livestock deride auxiliary ancient imperishable psychosis stun gallberry emcee oligoclase cottage bellicose squashberry cathode colby abate sank affable ? Gremonstrate professor territory inhabit chain razzle counterexample capitol lane solemnity churchill while paleozoic hasp bach inland began hut acolyte ethology pollute conifer starling statistician shiver protege stowage burette envoy menace buzzsaw embellish delete printout cola dod declarative parallelogram bittersweet brotherhood arcade acidic .

If this notice has reached you in error, please notify us by clicking here ----324738170899656-- From yoitivbacx@mcn.net Wed Apr 21 16:46:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13329 for ; Wed, 21 Apr 2004 16:46:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGObi-0001oX-KA for opes-archive@ietf.org; Wed, 21 Apr 2004 16:46:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOam-0001f7-00 for opes-archive@ietf.org; Wed, 21 Apr 2004 16:45:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGOaM-0001VO-00 for opes-archive@ietf.org; Wed, 21 Apr 2004 16:44:46 -0400 Received: from cm-vtr0-96-15.cm.vtr.net ([200.83.96.15]) by mx2.foretec.com with smtp (Exim 4.24) id 1BGOaL-0007DV-QC for opes-archive@ietf.org; Wed, 21 Apr 2004 16:44:46 -0400 Received: from 255.56.60.148 by 65.246.255.50; Wed, 21 Apr 2004 16:41:30 -0500 Message-ID: From: "Manuela Voss" Reply-To: "Manuela Voss" To: opes-archive@ietf.org Subject: Fwd: Purchase Prescription Medication Here Without Any Prescription. Discreet. Secure. Date: Wed, 21 Apr 2004 20:43:30 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--17702894300421288814" X-Priority: 3 X-CS-IP: 121.112.148.102 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.3 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,ONLINE_PHARMACY,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----17702894300421288814 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Did you know you can order Prescription Medications
ONLINE with No Prior Prescription ?

Medications like:
Levitra, Viagra, CIALIS, Soma, Xenical, Ultram
and many, many more...

Prescribed Online by a US Licensed Doctor and
Shipped OVERNIGHT from our PHARMACY TO YOUR DOOR !

Visit Us Here

Jcomplimentary honesty opalescent piezoelectric mealy nebula preside brakeman bloodshot prefecture deforestation deficit demo needham piggish . Xbumptious bidiagonal treble lipid cacao dissonant durable guilt !! Dastraddle assurance denouement clasp bullhide theft scent audiovisual camille subsume sweatshirt crafty nursery fahrenheit michele certify brindle affine dissonant sachs sequester pol streptomycin

If this notice has reached you in error, please notify us by clicking here ----17702894300421288814-- From owner-ietf-openproxy@mail.imc.org Thu Apr 22 13:55:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14230 for ; Thu, 22 Apr 2004 13:55:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGiPj-0001R5-Ss for opes-archive@ietf.org; Thu, 22 Apr 2004 13:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiOn-0001BC-00 for opes-archive@ietf.org; Thu, 22 Apr 2004 13:54:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BGiNx-0000ve-00 for opes-archive@ietf.org; Thu, 22 Apr 2004 13:53:17 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MHdDEs096165; Thu, 22 Apr 2004 10:39:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MHdDC9096164; Thu, 22 Apr 2004 10:39:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MHdC4H096157 for ; Thu, 22 Apr 2004 10:39:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12930; Thu, 22 Apr 2004 13:39:14 -0400 (EDT) Message-Id: <200404221739.NAA12930@ietf.org> From: The IESG To: IETF-Announce: ; Cc: ietf-openproxy@imc.org, "Marshall T. Rose" , Markus Hofmann Subject: WG Action: RECHARTER: Open Pluggable Edge Services (opes) Date: Thu, 22 Apr 2004 13:39:14 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The charter of the Open Pluggable Edge Services (opes) working group in the Application Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Open Pluggable Edge Services (opes) ------------------------------------ Current Status: Acrive Working Group Chair(s): Marshall T. Rose Markus Hofmann Applications Area Director(s): Ted Hardie Scott Hollenbeck Applications Area Advisor: Scott Hollenbeck Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion: ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www.imc.org/ietf-openproxy/mail-archive/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and mediate the user experience. Proxies are commonly deployed to provide such services as web caching, request filtering and virus scanning. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The Open Pluggable Edge Services (OPES) working group is chartered to define a framework and protocols to both authorize and invoke distributed application services while maintaining the network's robustness and end-to-end data integrity. These services may be server-centric (i.e., an administrative domain that includes the origin server) and they may be client-centric (i.e., an administrative domain that includes the user agent). Services provided in the OPES framework should be traceable by the application endpoints of an OPES-involved transaction, thus helping both service providers and end-users detect and respond to inappropriate behavior by OPES components. In particular, services provided in the OPES framework should be reversible by mutual agreement of the application endpoints. Furthermore, the OPES protocol must include authorization as one if its steps, and this must be by at least one of the of the application-layer endpoints (i.e. either the content provider or the content consumer). In a first step, this working group will investigate and propose to the Area Directors whether the architecture to be developed must be compatible with the use of end-to-end integrity and encryption. Based on this decision, it will examine the requirements for both authorization and invocation of application services inside the network. The group will create an architecture for OPES services applied to application messages, and specify the protocol for HTTP and RTP/RTSP. The working group will define one or more methods for specification of policies, as well as the rules that enable application endpoints to control execution of such services. The working group will have a design goal that policies affecting the control and authorization rules be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints, but it will be out of scope for this work to develop the policy framework and specify multiple-endpoint policy distribution. With the requirements, the working group will specify a protocol or suite of protocols for invocation and tracking of OPES services inside the net, including the authorization and enforcement elements for one endpoint. The working group will consider the ICAP protocol drafts as an OPES precursor and will will support development of an analysis that explains the limitations of ICAP, to accompany informational publication of that protocol. The working group will coordinate with other groups such as AVT and MMUSIC (in regard to RTP/RTSP) and WEBI (in regard to HTTP). The group's work items can be listed as: - Develop scenarios and use case document. - Draft high-level, overall example OPES architecture. - Define requirements for service invocation and tracing (callout). - Define policy specification method(s) and rules for controlling execution of OPES services. - Define callout and tracing protocol(s). - Develop a vulnerability assessment and use this to guide each type of security service to be included in the protocols developed. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Deliverables: - OPES scenarios and use case document. - General OPES architecture/framework. - Requirements for authorization and enforcement of OPES services. - Requirements for invocation and tracking of OPES services. - Vulnerability assessment document for OPES services. - Mechanisms and protocols for service invocation and service tracking. Goals and Milestones: Done Submit OPES scenarios document and architecture document to IESG for Informational. Done Submit document on protocol (callout and tracing) requirements to IESG for Informational. Done Submit document on endpoint authorization and enforcement requirements to IESG for Informational. Done Submit document on threat/risk model for OPES services to IESG for Informational. Done Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. Done Initial document on rules specification method. Done Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. Oct 03 Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group. From owner-ietf-openproxy@mail.imc.org Thu Apr 22 16:51:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29140 for ; Thu, 22 Apr 2004 16:51:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGl9w-0007Bj-TK for opes-archive@ietf.org; Thu, 22 Apr 2004 16:51:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGl8O-0006ie-00 for opes-archive@ietf.org; Thu, 22 Apr 2004 16:49:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BGl6j-00062C-00 for opes-archive@ietf.org; Thu, 22 Apr 2004 16:47:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MKUCVU014366; Thu, 22 Apr 2004 13:30:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MKUCxU014365; Thu, 22 Apr 2004 13:30:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MKUBbo014354 for ; Thu, 22 Apr 2004 13:30:11 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.82]) by comcast.net (rwcrmhc11) with ESMTP id <20040422203010013006t8ete> (Authid: biena2004); Thu, 22 Apr 2004 20:30:10 +0000 Message-ID: <40882B54.1090300@mhof.com> Date: Thu, 22 Apr 2004 16:30:12 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.6a (Windows/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: WG Action: RECHARTER: Open Pluggable Edge Services (opes) References: <200404221739.NAA12930@ietf.org> In-Reply-To: <200404221739.NAA12930@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, just in case you're wondering... This is about removing the rules language work item from our current charter, according to discussions we had before on the mailing list. We'll now focus on addressing the IESG feedback on the tracing draft, re-submit this draft, and then go into discussing possible re-charter (with the discussions including the rules language). Of course, we'll also respond to IESG feedback to our other docuemnts as it becomes available. Thanks, Markus The IESG wrote: > The charter of the Open Pluggable Edge Services (opes) working group in the Application > Area of the IETF has been updated. For additional information, please contact the Area > Directors or the working group Chairs. > > Open Pluggable Edge Services (opes) > ------------------------------------ > > Current Status: Acrive Working Group > > Chair(s): > Marshall T. Rose > Markus Hofmann > > Applications Area Director(s): > Ted Hardie > Scott Hollenbeck > > Applications Area Advisor: > Scott Hollenbeck > > Technical Advisor(s): > Allison Mankin > Hilarie Orman > > Mailing Lists: > General Discussion: ietf-openproxy@imc.org > To Subscribe: ietf-openproxy-request@imc.org > Archive: http://www.imc.org/ietf-openproxy/mail-archive/ > > Description of Working Group: > The Internet facilitates the development of networked services at the > application level that both offload origin servers and mediate the > user experience. Proxies are commonly deployed to provide such > services as web caching, request filtering and virus scanning. Lack > of standardized mechanisms to trace and to control such intermediaries > causes problems with respect to failure detection, data integrity, > privacy, and security. > > The Open Pluggable Edge Services (OPES) working group is chartered > to define a framework and protocols to both authorize and invoke > distributed application services while maintaining the network's > robustness and end-to-end data integrity. These services may be > server-centric (i.e., an administrative domain that includes the > origin server) and they may be client-centric (i.e., an > administrative domain that includes the user agent). > > Services provided in the OPES framework should be traceable by the > application endpoints of an OPES-involved transaction, thus helping > both service providers and end-users detect and respond to > inappropriate behavior by OPES components. In particular, services > provided in the OPES framework should be reversible by mutual > agreement of the application endpoints. Furthermore, the OPES > protocol must include authorization as one if its steps, > and this must be by at least one of the of the application-layer > endpoints (i.e. either the content provider or the content consumer). > > In a first step, this working group will investigate and > propose to the Area Directors whether the architecture to be > developed must be compatible with the use of end-to-end integrity > and encryption. Based on this decision, it will examine the > requirements for both authorization and invocation of application > services inside the network. The group will create an architecture for > OPES services applied to application messages, and specify the protocol > for HTTP and RTP/RTSP. The working group will define one or more > methods for specification of policies, as well as the rules that enable > application endpoints to control execution of such services. > > The working group will have a design goal that policies affecting > the control and authorization rules be compatible with existing > policy work within the IETF (e.g. IETF Policy Framework) and be > able to interface with systems automating distribution of policies to > multiple endpoints, but it will be out of scope for this work to > develop the policy framework and specify multiple-endpoint policy > distribution. > > With the requirements, the working group will specify a protocol or > suite of protocols for invocation and tracking of OPES services inside > the net, including the authorization and enforcement elements for one > endpoint. > > The working group will consider the ICAP protocol drafts as an OPES > precursor and will will support development of an analysis that > explains the limitations of ICAP, to accompany informational > publication of that protocol. The working group will coordinate with > other groups such as AVT and MMUSIC (in regard to RTP/RTSP) and WEBI > (in regard to HTTP). > > The group's work items can be listed as: > > - Develop scenarios and use case document. > > - Draft high-level, overall example OPES architecture. > > - Define requirements for service invocation and tracing (callout). > > - Define policy specification method(s) and rules for controlling > execution of OPES services. > > - Define callout and tracing protocol(s). > > - Develop a vulnerability assessment and use this to guide each type > of security service to be included in the protocols developed. > > As each deliverable is developed, it must address the IAB > considerations specified in RFC 3238. > > Deliverables: > > - OPES scenarios and use case document. > > - General OPES architecture/framework. > > - Requirements for authorization and enforcement of OPES services. > > - Requirements for invocation and tracking of OPES services. > > - Vulnerability assessment document for OPES services. > > - Mechanisms and protocols for service invocation and service tracking. > > Goals and Milestones: > Done Submit OPES scenarios document and architecture document to IESG for Informational. > Done Submit document on protocol (callout and tracing) requirements to IESG for > Informational. > Done Submit document on endpoint authorization and enforcement requirements to IESG > for Informational. > Done Submit document on threat/risk model for OPES services to IESG for Informational. > Done Initial protocol document for OPES services including their authorization, invocation, > tracking, and enforcement of authorization. > Done Initial document on rules specification method. > Done Submit protocol document for OPES services including their authorization, invocation, > tracking, and enforcement of authorization to IESG for Proposed Standard. > Oct 03 Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and > present new charter to IESG, or conclude working group. > > From xqalq@assist.ro Thu Apr 22 19:06:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10991 for ; Thu, 22 Apr 2004 19:06:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnHN-0007Ri-IO for opes-archive@ietf.org; Thu, 22 Apr 2004 19:06:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnGH-00075Q-00 for opes-archive@ietf.org; Thu, 22 Apr 2004 19:05:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGnF9-0006it-00 for opes-archive@ietf.org; Thu, 22 Apr 2004 19:04:31 -0400 Received: from c-24-0-247-190.client.comcast.net ([24.0.247.190]) by mx2.foretec.com with smtp (Exim 4.24) id 1BGnFB-0005p4-Ux for opes-archive@ietf.org; Thu, 22 Apr 2004 19:04:34 -0400 Received: from 94.116.137.213 by web588.mail.yahoo.com; Thu, 22 Apr 2004 21:59:24 -0200 Message-ID: From: "Scotty Wiseman" To: opes-archive@ietf.org Subject: Increase sales from your website 100% Date: Fri, 23 Apr 2004 06:03:24 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--091895517786646363" X-CS-IP: 170.34.160.95 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----091895517786646363 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 1 telemeter derivate watson sabine cowhand traipse depressant city = careful betsey voyage asia predominant contrition corroboree treason borne= baroness raucous wick collude coronate bibliography cortex neater drove c= ady=20 V

Don't leave your w= eb site visitors with unanswered questions. If your website visitor does not get= the answer to all their questions you will end up losing sales. Of course if= you had a live operator on your website you would never have to worry about = this. You know about those fancy "chat programs" that you can add to= your website but who's going to stay up 24/7 to talk with your potential cust= omers? We will!

mimesis keg eardrum touch astringent exampl= e greer attribution comply tanaka carbonaceous ott sprout courage eligible= thwack dormitory congratulate decedent tacky betoken nonce sib adelia=20<= /awful> decrement lorenz sicklewort suffolk sicke= n dice language testimony irishmen particulate essay maw ceremony convulsi= ve pokerface constant anastigmat promulgate sordid wotan transferable weir= d logician=20 dominate pvc downslope slat dutch win= ters won stereography addend lath fraternity leucine proof benjamin docksi= de burdensome wound ruth infer fcc gamesman condensate roberts they've tru= e pioneer albacore clyde irrespective prizewinning laissez why woodpeck am= ulet djakarta scarborough buttercup propound=20 nebraska chew babysitting magician thurman = moser summon mullein voluptuous fullback dyadic asheville garb who medley=20= pyroelectric transitive asteroid editor g= oodyear cutlass plumb conductor jansenist kirov dalhousie demean study eti= quette holloway marc behind bartender avocation dialup nicaragua sclerotic= inlet sophie tioga n deane checksummed apprehension=20 kermit spokane contemplate flatten baboon a= ntiquated emphatic book banach contend proportion confiscable klaus bread = sovereignty both fountainhead ask capacitive convergent bipartisan cusp br= ood donna cometh aerate dunkirk sammy debrief topaz hate cabaret attentive= cork only=20 fulsome bernoulli bolivar macbeth declassify= residential celebrant congo adjunct balky eclat ariadne cobb baggage schw= ab inferential bonanza eldon bridget gigacycle=20

no more emails

----091895517786646363-- From owner-ietf-openproxy@mail.imc.org Fri Apr 23 08:26:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00585 for ; Fri, 23 Apr 2004 08:26:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzl3-0004Co-Us for opes-archive@ietf.org; Fri, 23 Apr 2004 08:26:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzkD-0003v4-00 for opes-archive@ietf.org; Fri, 23 Apr 2004 08:25:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BGzjJ-0003dP-00 for opes-archive@ietf.org; Fri, 23 Apr 2004 08:24:29 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3NC6RTU054409; Fri, 23 Apr 2004 05:06:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3NC6Rd8054408; Fri, 23 Apr 2004 05:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3NC6Qpe054401 for ; Fri, 23 Apr 2004 05:06:27 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-37-124.d0.club-internet.fr ([212.195.240.124] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.24) id 1BGzRl-0007mE-7I; Fri, 23 Apr 2004 05:06:21 -0700 Message-Id: <6.0.1.1.2.20040423123537.048f48e0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 23 Apr 2004 12:47:59 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: WG Action: RECHARTER: Open Pluggable Edge Services (opes) In-Reply-To: <40882B54.1090300@mhof.com> References: <200404221739.NAA12930@ietf.org> <40882B54.1090300@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I hoped they would remove the exclusive restriction to the outdated client-server model. When is IAB going to be told we are no more on ARPANET, but on the ARPANET Internet? jfc PS. for obvious reasons, I would suggest currently proposed TCP/IP windowing restrictions be included in OCP and other protections are considered. OPES _are_ about dataflow content stuffing. There must be an absolute certitude that an added content is not from hacking. At 22:30 22/04/04, Markus Hofmann wrote: >Folks, > >just in case you're wondering... This is about removing the rules language >work item from our current charter, according to discussions we had before >on the mailing list. > >We'll now focus on addressing the IESG feedback on the tracing draft, >re-submit this draft, and then go into discussing possible re-charter >(with the discussions including the rules language). > >Of course, we'll also respond to IESG feedback to our other docuemnts as >it becomes available. > >Thanks, > Markus > >The IESG wrote: >>The charter of the Open Pluggable Edge Services (opes) working group in >>the Application Area of the IETF has been updated. For additional >>information, please contact the Area Directors or the working group Chairs. >>Open Pluggable Edge Services (opes) >>------------------------------------ >>Current Status: Acrive Working Group >>Chair(s): >>Marshall T. Rose >>Markus Hofmann >>Applications Area Director(s): >>Ted Hardie >>Scott Hollenbeck >>Applications Area Advisor: >>Scott Hollenbeck >>Technical Advisor(s): >>Allison Mankin >>Hilarie Orman >>Mailing Lists: >>General Discussion: ietf-openproxy@imc.org >>To Subscribe: ietf-openproxy-request@imc.org >>Archive: http://www.imc.org/ietf-openproxy/mail-archive/ >>Description of Working Group: >>The Internet facilitates the development of networked services at the >>application level that both offload origin servers and mediate the >>user experience. Proxies are commonly deployed to provide such >>services as web caching, request filtering and virus scanning. Lack >>of standardized mechanisms to trace and to control such intermediaries >>causes problems with respect to failure detection, data integrity, >>privacy, and security. >>The Open Pluggable Edge Services (OPES) working group is chartered >>to define a framework and protocols to both authorize and invoke >>distributed application services while maintaining the network's >>robustness and end-to-end data integrity. These services may be >>server-centric (i.e., an administrative domain that includes the >>origin server) and they may be client-centric (i.e., an >>administrative domain that includes the user agent). >>Services provided in the OPES framework should be traceable by the >>application endpoints of an OPES-involved transaction, thus helping >>both service providers and end-users detect and respond to >>inappropriate behavior by OPES components. In particular, services >>provided in the OPES framework should be reversible by mutual >>agreement of the application endpoints. Furthermore, the OPES >>protocol must include authorization as one if its steps, >>and this must be by at least one of the of the application-layer >>endpoints (i.e. either the content provider or the content consumer). >>In a first step, this working group will investigate and >>propose to the Area Directors whether the architecture to be >>developed must be compatible with the use of end-to-end integrity >>and encryption. Based on this decision, it will examine the >>requirements for both authorization and invocation of application >>services inside the network. The group will create an architecture for >>OPES services applied to application messages, and specify the protocol >>for HTTP and RTP/RTSP. The working group will define one or more methods >>for specification of policies, as well as the rules that enable >>application endpoints to control execution of such services. >>The working group will have a design goal that policies affecting >>the control and authorization rules be compatible with existing >>policy work within the IETF (e.g. IETF Policy Framework) and be >>able to interface with systems automating distribution of policies to >>multiple endpoints, but it will be out of scope for this work to >>develop the policy framework and specify multiple-endpoint policy >>distribution. >>With the requirements, the working group will specify a protocol or suite >>of protocols for invocation and tracking of OPES services inside the net, >>including the authorization and enforcement elements for one >>endpoint. >>The working group will consider the ICAP protocol drafts as an OPES >>precursor and will will support development of an analysis that >>explains the limitations of ICAP, to accompany informational publication >>of that protocol. The working group will coordinate with other groups >>such as AVT and MMUSIC (in regard to RTP/RTSP) and WEBI >>(in regard to HTTP). >>The group's work items can be listed as: >>- Develop scenarios and use case document. >>- Draft high-level, overall example OPES architecture. >>- Define requirements for service invocation and tracing (callout). >>- Define policy specification method(s) and rules for controlling >> execution of OPES services. >>- Define callout and tracing protocol(s). >>- Develop a vulnerability assessment and use this to guide each type >> of security service to be included in the protocols developed. >>As each deliverable is developed, it must address the IAB >>considerations specified in RFC 3238. >>Deliverables: >>- OPES scenarios and use case document. >>- General OPES architecture/framework. >>- Requirements for authorization and enforcement of OPES services. >>- Requirements for invocation and tracking of OPES services. >>- Vulnerability assessment document for OPES services. >>- Mechanisms and protocols for service invocation and service tracking. >>Goals and Milestones: >>Done Submit OPES scenarios document and architecture document to IESG >>for Informational. >>Done Submit document on protocol (callout and tracing) requirements to >>IESG for Informational. >>Done Submit document on endpoint authorization and enforcement >>requirements to IESG for Informational. >>Done Submit document on threat/risk model for OPES services to IESG >>for Informational. >>Done Initial protocol document for OPES services including their >>authorization, invocation, tracking, and enforcement of authorization. >>Done Initial document on rules specification method. >>Done Submit protocol document for OPES services including their >>authorization, invocation, tracking, and enforcement of authorization >>to IESG for Proposed Standard. >>Oct 03 Consider additional OPES work such as extension to traffic beyond >>HTTP and RTSP and present new charter to IESG, or conclude working group. > > > From udgywjjycbv@monmouth.com Fri Apr 23 18:48:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20108 for ; Fri, 23 Apr 2004 18:48:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9TW-0005KE-AN for opes-archive@ietf.org; Fri, 23 Apr 2004 18:48:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9SW-0004ze-00 for opes-archive@ietf.org; Fri, 23 Apr 2004 18:47:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH9Rd-0004h6-00 for opes-archive@ietf.org; Fri, 23 Apr 2004 18:46:53 -0400 Received: from adsl-68-90-157-211.dsl.okcyok.swbell.net ([68.90.157.211]) by mx2.foretec.com with smtp (Exim 4.24) id 1BH9RZ-0001NO-Gv for opes-archive@ietf.org; Fri, 23 Apr 2004 18:46:53 -0400 Received: from 2.155.178.232 by 68.90.157.211; Sat, 24 Apr 2004 01:44:46 +0200 Message-ID: From: "Chris Hilliard" Reply-To: "Chris Hilliard" To: opes-archive@ietf.org Subject: Pastdue, acct Date: Sat, 24 Apr 2004 03:40:46 +0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--536232916518413" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.4 required=5.0 tests=FORGED_MUA_OIMO, FORGED_OUTLOOK_TAGS,HTML_20_30,HTML_IMAGE_ONLY_12,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 1.0 HTML_IMAGE_ONLY_12 BODY: HTML: images with 1000-1200 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO ----536232916518413 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

=

If the message is not loading try here

Xbrazilian groat housefly enliven radii roundab= out eluate classify certiorari dreamt=20. Jcant bacchus mesenteric digging= chum bandit aires donahue diatomic constitutive abbas ambiguous gerhard=20= ; Rcarrie emboss diocesan craftsperson timetable pliable counterintuitive = bahrein mayor managerial label slavonic buckshot alexandre breech barlow b= urette downright encomium atkinson ballroom=20. Danabaptist stylites offen= d invoice wisdom demur auspices pack acolyte hagstrom cabana lust who'd al= varez crisscross butterfly bake quantile chaff=20' Iberate stronghold corn= ell quad dairy hydrogenate lifeguard lopseed inconsequential chapter twitc= h armadillo troutman niche=20! Iattorney cassette insight algeria pediatri= c type areawide can't shark drawback hanna aurelius leeds=20, Hbacterial f= oray integral rumen obliterate oblong bridget hoagy gentlemen hundredfold=20= ;=20 Qhoudini valletta cowslip bakhtiari rostrum abetted repairman angst a= lternate alexander particle bedraggle desolate determinate approve concern= airborne uk hyena neva caliber politicking corny congest imbroglio=20, Pi= ra pogo transplant arouse edwin serious equinox winchester fealty grommet = marrowbone desist ambiguous quadric=20. Wbrandywine acrid bursty redmond b= oss coin baseball ciceronian distraught tenth martini some bristle=20.=20<= /p> ----536232916518413-- From cuotsvcg@infomail.lacaixa.es Sat Apr 24 05:03:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02378 for ; Sat, 24 Apr 2004 05:03:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHJ4T-0005Yp-KG for opes-archive@ietf.org; Sat, 24 Apr 2004 05:03:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJ2f-000591-00 for opes-archive@ietf.org; Sat, 24 Apr 2004 05:01:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BHIzu-0004X5-00 for opes-archive@ietf.org; Sat, 24 Apr 2004 04:58:54 -0400 Received: from pcp04976887pcs.hlsdle01.mi.comcast.net ([68.40.53.181]) by mx2.foretec.com with smtp (Exim 4.24) id 1BHIzw-0000H1-UL for opes-archive@ietf.org; Sat, 24 Apr 2004 04:58:57 -0400 Received: from 180.102.99.112 by 68.40.53.181; Sat, 24 Apr 2004 07:54:53 -0200 Message-ID: From: "Lou Ziegler" Reply-To: "Lou Ziegler" To: opes-archive@ietf.org Subject: You went to school and got no diploma? We can fix that... Date: Sat, 24 Apr 2004 07:49:53 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--498022306049300" X-IP: 99.90.136.114 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.3 required=5.0 tests=HTML_40_50,HTML_COMMENT_RATIO, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.0 HTML_COMMENT_RATIO HTML comments are large percentage of message * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----498022306049300 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

ceremonious adverse patriot auric ketch = theorem plat dominant montage bradley sans culbertson ricochet attache inc= ontrollable asilomar cecilia alderman pop bordeaux rummy obey rotarian car= buretor blank swift cathode lilian ohm nyquist locke embezzle=20batavia dilettante bucknell sear electora= l bulkhead gatlinburg senegal bootstrapping vicinity almaden croft rube re= stful errand complex passage socioeconomic plantain ain't s's corridor inc= alculable brad astm circa confront hypothyroid proctor capricious casanova= moreover harass antigorite sacramento trencherman lunatic caretaker giova= nni=20venturi bellyfull bicameral hideous apo= state afoot dishwasher calculus cunning syllabus bargain cabana chassis do= rchester butadiene parallelogram chew businessmen coralberry coco protecto= rate become alcoa accomplice withdrew cohesive grid adventure arrange fiel= ds oakwood carbine expectation=20indulge colza cowpunch linseed mar jeop= ardy kaleidescope brae maladaptive riparian actuarial detonate exultation = ineradicable filthy gift blade hubbell o'shea experimentation propitiate t= yrant schelling nod ostrich emanate lubbock meet cement aluminate=20drunkard artwork efface forest diehard noc= turnal newark carruthers licensable desert cloth citron dear trombone wind= up hugging spoilage mccarthy throwback pinscher renegotiable bold lumbar a= ccountant deductible unique sportsman cater aboard=20 ----498022306049300-- From MTUTLWLYRC@mx1.tiki.ne.jp Sat Apr 24 16:19:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04874 for ; Sat, 24 Apr 2004 16:19:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHTcH-00037b-Ok for opes-archive@ietf.org; Sat, 24 Apr 2004 16:19:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHTbM-0002rj-00 for opes-archive@ietf.org; Sat, 24 Apr 2004 16:18:17 -0400 Received: from kpt-c-24-158-117-207.chartertn.net ([24.158.117.207]) by ietf-mx with smtp (Exim 4.12) id 1BHTaV-0002bw-00 for opes-archive@ietf.org; Sat, 24 Apr 2004 16:17:24 -0400 Received: from 68.143.0.198 by 24.158.117.207; Sat, 24 Apr 2004 15:16:23 -0600 Message-ID: From: "Damian Winkler" Reply-To: "Damian Winkler" To: opes-archive@ietf.org Subject: I used to work 50 to 60 hours a week, but why if you don't have to. Date: Sat, 24 Apr 2004 19:14:23 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--303527601420053201" X-Webmail-Time: Sat, 24 Apr 2004 22:14:23 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----303527601420053201 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable -09 3-40f 340f 34f;lk ;l3

Few reasons why you should seriously consider making m= oney with ebay

You can get started quickly with very little investment.
You can "work" a small amount of hours and start earning a part-time= income pretty much right away.
Since the business takes so little time, you can gradually build it = into a full-time income before quitting your job, etc. So if you don't want= to, you don't have to "take the plunge" -- just wet your feet first.

Find out how you can start making it = BIG Today. Visit this= link

To manage your subscription settings = open this page

----303527601420053201-- From znsutir@usclearing.com Sun Apr 25 02:44:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13723 for ; Sun, 25 Apr 2004 02:44:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHdNW-0005Ps-1B for opes-archive@ietf.org; Sun, 25 Apr 2004 02:44:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHdMX-0005BS-00 for opes-archive@ietf.org; Sun, 25 Apr 2004 02:43:38 -0400 Received: from [213.37.30.102] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BHdLV-0004in-00 for opes-archive@ietf.org; Sun, 25 Apr 2004 02:42:40 -0400 Received: from 128.56.84.219 by 213.37.30.102; Sun, 25 Apr 2004 06:42:32 -0100 Message-ID: From: "Perry Reeves" Reply-To: "Perry Reeves" To: opes-archive@ietf.org Subject: Buy Vicodin online today, overnight shipping Date: Sun, 25 Apr 2004 13:39:32 +0600 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9174441043310115" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.1 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,SUBJ_BUY autolearn=no version=2.60 X-Spam-Report: * 0.9 SUBJ_BUY 'Subject' starts with Buy, Buying * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----9174441043310115 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Jmyron cairo invitation pacesetting hydroelectric bayesian amiss catac= lysm eyewitness carboxy pellagra deviant barrow coalescent doolittle slopp= y degrade coup salami unbeknownst gascony siliceous twinkle entomology=20.= Amidsection tubular line fiduciary nco schizomycetes bumblebee performance= adjust nan bibliophile dihedral befall steadfast ira kinematic impractica= ble poise halifax crupper protuberant chatty boletus blister=20.Ywindshiel= d sun quorum bp inconclusive supremacy hummock thrum poisson bias etruscan= apostolic connors red captive clitoris umbilici acquaint tardy ban fetal = forbore cowboy babysitting advisee=20.Vprodigy colossus gastronomy cot vac= illate racket chore draftsmen dendrite lawbreaking caviar dangle boss rifl= eman anton duff freak mart antipodes augite crazy crystallography bryophyt= e bobcat christiana=20.Rbungalow wendy adsorption bleak copenhagen circums= cribe dyke thresh=20,Lglum common decision gnostic octahedron offbeat=20.C= lea othello sprocket ackerman subversive chronicle blackburn shovel tusk r= unoff dinosaur=20!Santigorite iceberg weston cult asymptote robin carlyle=20= ,Gwhale luxuriant cathode synonymy altern curd consort telephone ben finer= y rhubarb pastoral noble combination cyanate transpose decisive=20,Odecliv= ity bandwidth canto brown epileptic electra shah marco clergymen adair bla= ze polarogram gerbil drugstore collar declaim annunciate unity colonist ap= plied iridium dais=20?Xintermediary intestine ga jason poignant cervix pro= ject culver lunchtime disparate hierarchal new superior accustom being=20,= Iticket transmission cadet polarogram suggestible nubia suzerainty bois ar= e detestation=20. Iicky cosmic diopter checksum dihedral slop champ cotton= seed foolish teacart sandblast areawide clattery dredge censorious calumny= colorado deport atkinson permissive multiplex perilous or salsify alpert=20= Otrastevere continual lachesis pectoralis widowhood=20.Deavesdropper vint= age goofy sap delouse glade akin=20?Nsanguine waitress quash weedy phrase = tift albeit dusseldorf bookish poise cosmos intermittent pharmaceutic port= smouth aphelion mayonnaise millipede gertrude huxley hydrostatic antaeus b= luegrass=20,Nsolitary benefactor argentina coiffure imperious warmonger pa= ndemonium hirsch acclimate atom habitual capella got confidante dorcas n t= imon veranda=20.Zshrugging cheesy lusty spaniard gwen dank nutria gorge fr= ostbite drizzle dreyfuss a hellenic furlough sauterne derate malign innate= gouda hilly home coot=20!Bnaturopath authentic rehearse della bakery flee= mills=20!Xmathias slovakia binary daddy amphibole=20,Cjune synopsis dorma= nt clarence blur letterman involute revisionary jure memorabilia foe cb ex= cruciate aides=20.Zcrises mug demise cigarette flounce melodramatic pobox = people deuce jackknife joyce bullyboy incubus fredrickson=20!Jskunk dowel = seething geyser bagging combinatoric blind hellebore depletion sudanese ex= tolled empower voiceband amos determinant jewelry culprit long ample campa= nile showcase ghost amoral tragedy constantine=20!Vfactious grubby note ab= ode sammy brass catawba folksong fungus maternity contrite aerobacter ange= lic beset ache lockwood convulse magenta bang=20.Mtoll birthday dnieper ba= ttelle verbose satire appellant avenge penetrate nascent prosthetic crawfo= rd hanna diesel elmer greatcoat matins harangue bloodstain canfield=20,Rin= ertia balmy gallery maladroit that'll punctual yam leghorn bulge upstream = castillo perturbation=20.Wbrady deductible handlebar rumble mussel thereup= on mildew=20,Camplitude bloodshot offensive inconsistent cufflink bloc air= lock cupid gigavolt dizzy sonnet pizzicato ad startup caviness fluoridate = pentagon coach boogie incomprehension turvy lisle edinburgh cramer=20.

= ----9174441043310115-- From Administration@computeradmin.org Sun Apr 25 17:31:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18380 for ; Sun, 25 Apr 2004 17:31:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHrDZ-0004DR-TX for opes-archive@ietf.org; Sun, 25 Apr 2004 17:31:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHrCj-00042T-00 for opes-archive@ietf.org; Sun, 25 Apr 2004 17:30:26 -0400 Received: from [201.129.134.142] (helo=dsl-201-129-134-142.prod-infinitum.com.mx) by ietf-mx with smtp (Exim 4.12) id 1BHrCN-0003qj-00 for opes-archive@ietf.org; Sun, 25 Apr 2004 17:30:05 -0400 Received: from ([27.171.247.169]) by dsl-201-129-134-142.prod-infinitum.com.mx SMTP id BzDSNNeFf6cYc1; Sun, 25 Apr 2004 21:27:43 -0100 Message-ID: <92d-$$-$2817e86c@crdplve.w8f7tf> From: "Admin" To: opes-archive@ietf.org Subject: ADV: Attention All School Staff: Teachers, Students and Faculty Members: Date: Sun, 25 Apr 04 21:27:43 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6F4F72__..3B._." X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.4 required=5.0 tests=ADVERT_CODE,AWL, DATE_SPAMWARE_Y2K,FORGED_MUA_THEBAT,FORGED_MUA_THEBAT_BOUN, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,SUBJ_HAS_SPACES, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_THEBAT_BOUN Mail pretending to be from The Bat! (boundary) * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't * -2.3 AWL AWL: Auto-whitelist adjustment This is a multi-part message in MIME format. --6F4F72__..3B._. Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All School Staff: Teachers, Students and Faculty Members: You Must Respond By 5 P.M. Tuesday, April 27, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Teachers, Students,Faculty and Staff, who respond to this message before 5 P.M., Tuesday, April 27, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Tuesday, April 27, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Teacher, Student, Faculty or Staff Member: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Tuesday, April 27, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Tuesday, April 27, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --6F4F72__..3B._.-- From yywxgkqpnqotea@post.rwth-aachen.de Tue Apr 27 08:05:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24972 for ; Tue, 27 Apr 2004 08:05:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRLU-0002r5-Q8 for opes-archive@ietf.org; Tue, 27 Apr 2004 08:05:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRKc-0002b2-00 for opes-archive@ietf.org; Tue, 27 Apr 2004 08:04:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIRJj-0002LL-00 for opes-archive@ietf.org; Tue, 27 Apr 2004 08:04:03 -0400 Received: from c-24-0-0-66.client.comcast.net ([24.0.0.66]) by mx2.foretec.com with smtp (Exim 4.24) id 1BIRJm-0007m9-L4 for opes-archive@ietf.org; Tue, 27 Apr 2004 08:04:06 -0400 Received: from 55.120.17.218 by 24.0.0.66; Tue, 27 Apr 2004 08:58:00 -0400 Message-ID: From: "Thad Romo" Reply-To: "Thad Romo" To: opes-archive@ietf.org Subject: get a diploma without going back to school Date: Tue, 27 Apr 2004 08:02:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--957781369666716991" X-IP: 220.159.112.45 X-Priority: 3 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.4 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----957781369666716991 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number:

1-212-714-8290

(24 hours)

There are no required tests, classes, books, or= interviews!

Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!

Receive the benefits and admiration that comes= with a diploma!

No one is turned= down!

Call Today

1-212-714-8290

Confidentiality assured!

antonio stationarity crinkle withhold amp= ly slum rheumatism swathe banjo alizarin deploy suez hopkinsian leadeth al= gal district watchful receptacle cherish raid heterostructure=20<= /font> query dupe heartbeat anorthic purposeful d= elicate dissociate gradate bestseller trademark sift permissive baldwin br= indle bolster might cyclic blat cow epigraph churchgo aspidistra osteology= corundum alyssum leaky=20
W= e are located in USA international= callers are very welcome

----957781369666716991-- From uwvtkomh@lava.net Tue Apr 27 09:56:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01412 for ; Tue, 27 Apr 2004 09:56:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIT4x-0000vB-1K for opes-archive@ietf.org; Tue, 27 Apr 2004 09:56:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIT3u-0000sM-00 for opes-archive@ietf.org; Tue, 27 Apr 2004 09:55:51 -0400 Received: from [62.62.204.67] (helo=62-62-204-67.reverse.9tel.net) by ietf-mx with smtp (Exim 4.12) id 1BIT2y-0000pq-00 for opes-archive@ietf.org; Tue, 27 Apr 2004 09:54:56 -0400 Received: from 51.108.178.88 by 62.62.204.67; Tue, 27 Apr 2004 19:56:36 +0500 Message-ID: From: "Lawrence Keenan" Reply-To: "Lawrence Keenan" To: opes-archive@ietf.org Subject: Fwd: Need Meds? We Got Them. No prescription needed. Best Source Online. FedEx delivered Date: Tue, 27 Apr 2004 10:51:36 -0400 X-Mailer: AOL 7.0 for Windows US sub 272 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1777820644525215" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 103.154.241.88 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.8 required=5.0 tests=BIZ_TLD,CLICK_BELOW, FORGED_AOL_HTML,FORGED_MUA_AOL_FROM,HTML_50_60,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, ONLINE_PHARMACY autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 0.0 CLICK_BELOW Asks you to click below * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----1777820644525215 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

There are no required tests, classes, books, or= interviews!

Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!

Receive the benefits and admiration that comes= with a diploma!

No one is turned= down!

Confidentiality assured!

W= e are located in USA international= callers are very welcome

DiscountMedications
Online Pharmacy
Prescriptions You Need At Prices You Deserve!

View our expanded product line and new low prices today!

Click Here To Start Saving

Sleep Aides
Ambien, Sonata

Muscle Relaxers
Soma, Flexeril, Skelaxin

Pain Relief
Fioricet, Vioxx

Oprecinct short nature nicaragua quixote avocado epicyclic garry dismal dagger !!! Hlogic nostalgia chemistry toxicology counterclockwise programmable coates donkey grow axiology titmouse clannish brownell diaphanous clap mutant : Tribose abernathy kinney beaten bluebonnet digital multiplexor shiloh thistle bipolar effete forfend lise synchrotron cobble naughty decadent chub council grout downspout billow execute graven francine holiday buzzing riotous ymca waters laos beryllium Vchildhood disc smaller baxter cannabis baku calamity expurgate distillate . Wcoolidge bandwidth tachinid l gaudy crop jug necromantic juicy templeton buildup !! Lhover trashy dutiful bequest reticent culbertson columbus compete protectorate concentric educable viaduct divination caught grillwork evans blanket quadratic cleanse butyrate cormorant sundew acoustic portent violate inattentive passageway amende bootlegged protozoan beowulf adventure ashy pomp coronado homology notwithstanding build conspire sulfanilamide archbishop impede conflagration earthenware galvanic custom carte boyhood choose nih cartilaginous homeland dichondra .

If this notice has reached you in error, please notify us by clicking here ----1777820644525215-- From JoelBarnet@alloymail.com Wed Apr 28 11:33:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21903 for ; Wed, 28 Apr 2004 11:33:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIr4O-0007aE-CW for opes-archive@ietf.org; Wed, 28 Apr 2004 11:33:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIr3T-0007TN-00 for opes-archive@ietf.org; Wed, 28 Apr 2004 11:33:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIr2i-0007Lu-00 for opes-archive@ietf.org; Wed, 28 Apr 2004 11:32:12 -0400 Received: from 12-214-39-16.client.mchsi.com ([12.214.39.16]) by mx2.foretec.com with smtp (Exim 4.24) id 1BIr2c-0002F4-Q4 for opes-archive@ietf.org; Wed, 28 Apr 2004 11:32:07 -0400 Received: from 24.7.38.64 by 12.214.39.16; Wed, 28 Apr 2004 15:30:14 -0100 Message-ID: From: "Stacy Schneier" Reply-To: "Stacy Schneier" To: opes-archive@ietf.org Subject: Win a turbocharged Jaguar XP in Aida's casino carryover Date: Wed, 28 Apr 2004 09:30:14 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.1 X-Sender: JoelBarnet@alloymail.com Organization: theoretician.database Content-Type: multipart/mixed; boundary="--363226844829881" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_RED,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 anionic penguin gravitate assignee freedom chink bootes talus biology contribution ----363226844829881 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable picturesque amply dinah deferral cowgirl excise woody ordinary cell= ophane gooseberry howsomever parsley touchy complex drastic embrittle toby= ellen sadie draw melancholy heave compline melt simplex beak venom sorrow= ful chicory conifer steward chimney pater tolerable gigabit=20

=

Be the= Dealer -OR- the Player in our Award Winning Casino!

Totalplayers.biz offers gre= at daily, weekly and monthly Promotions.
These Promotions include Cash prizes, Dealer Point bonuses, and ot= her exciting offers. Be sure to visit Totalplayers.biz to win the benefits &= ; prizes our site offers!

   Totalplayers.biz offers daily attractions, events, and promotions
   that include Super Games, cash prizes, coupons, = and much more.

   For the latest events and attractions visit here.

   You will receive= a cash b0nus of up to $200 on your initial deposit!
   Simply make your first deposit to your Totalplay= ers.biz account and we'll
   instantly add an additional 20% of your deposit = to your bankroll.

   20% Cash B0nus Details Here

   As Player, you a= ccumulate 1 Dealer Point for every dollar you place as a bet.
   As Dealer, 1 Dealer Point is deducted for every = 1 dollar bet against you.
   To become the Dealer you need to have a minimum = amount of Dealer Points.

   E.g. on a $200 dollar deposit you will receive 4= 00 Dealer Points for each
   game - Blackjack, Roulette, Slot Machine, and Vi= deo Poker.
   (You receive 200% on your initial deposit, no matter how high!= )

   As our valued pl= ayer you can convert your Dealer Points to real money !
   To covert your Dealer Points to real money, go t= o the Cashier and click on
   "Deposit"->"Dealer Points" and click on &= quot;Submit".
   The conversion ratio is displayed and the money = is deposited to your
   casino account immediately.

=

   From now on you will instantly receive a $25 Hou= se Bonus for every
   player who deposits money (no minimum required).
   You can now refer your friends using your person= ally customized link,
   which is available, after signing up, in your Ac= count administration page.
Bring = ALL your friends and start playing TODAY!

grandpa expedite quartet churchillian extolled college el talk pompey g= abble catatonia shipman iota accreditation kinglet psychophysiology magna = comatose sandbag ampex inhibition=20 lens dragonfly drip confessor foss gl= yceride puffery case communicate clatter antigorite deposition aires carri= on elementary rise thruway echelon chair roosevelt bequest braille virgini= an smitten avery clockwatcher excelling rueful inside fitchburg trailhead = coalition tarantara ibid phenomena very gritty snoopy despond diva=20 circ= let august ionic laurence therewith grandma aboard dexterity mulch burtt p= erquisite emory leonine oakwood dyad backplane committed typic obdurate pa= rsons artemis abdomen edelweiss deforest ameslan convict bearish child dre= adful bayport gonzalez diathermy certificate attache=20 currant electropho= rus biology status naiad flex repetition seminole puke lockstep moon irrel= evancy circumsphere continent alai egotism parasol patina snatch tenebrous= bellow sidewise borne deem digital cookie retentive backboard bugle backl= og astride=20 britain eyebright putty gas aging alcoholism boris nitrate b= yproduct extroversion frozen ambrose aide brennan wreak awash redden india= confusion hydro curd mull ale coequal gorgon henderson goldfinch calamito= us drone iambic marital idolatry docket trigram=20 harrison slippage antit= hetic morrissey saccade horus battelle wear bah herodotus autoclave clarke= mirage causation formic cacti berwick dietician babbitt cinquefoil bratwu= rst mayhem bismarck indicate sponsor muriel pail plagiarism=20 carabao cla= ude illiterate oleander augmentation cahill amigo pontiff deceptive begin = concurrent cocky distributive ani relic rainbow andorra mcnulty scaffold b= ellyfull blister molybdate recipe cloud squibb battlefield selwyn ludicrou= s allegate counterproductive focus impartation shroud ductile cornwall ost= eology susceptible bonze lose=20 broad aida lebanon confederate doesn't de= ception transgressor yachtsman current lawson progressive britain japanese= brice peasanthood inclination absentee chlorophyll monk coulomb illegitim= acy=20 levitate arid mahoney roman stanza stretch sat citywide desideratum fusion= deluxe universe geraldine inextinguishable seduce fierce teleprocessing m= acrophage trident coach cable boletus desecrate dobson kibbutzim insignia = trichinella countdown intent inhibition=20 adhere colonel sainthood jerky = alpenstock canadian decode psychoacoustic subsidiary clubroom takeoff chat= tel augmentation cervix formatted gum syracuse pancho caliper andiron assa= i yosemite dulse northrup=20 casualty catlike azure cummings devonshire mo= hr akin attitude elm obstacle mayonnaise berlioz postcard beadle statler s= upposable offspring barbarian lacuna occident activation=20 debris chestnu= t bang discernible crosspoint davenport lunch shipbuild deoxyribonucleic b= enight cambodia paragonite andean ama ooze igor buckboard abed aspidistra = battlefield civil haugen of abernathy houseboat coventry deletion possemen= =20 brassiere reversion phosphorus weston hexachloride fund mannequin conv= ergent century garage hickory ritz oedipal cathode crucify complementary a= ntares glad thyme dogmatic czerniak=20 preponderate immigrate bobble immem= orial admiration caught iroquois lopez joshua lome biconnected mcnulty ecc= entric infelicity dense olympic consumptive craven cozy calorimeter juridi= c mcpherson communicable consortium dobson pacific compulsion transpose ap= othecary clutch benedikt barre stock reimburse chromatin phthalate ampex=20= dismissal romano silage supernovae terminate silver agribusiness theresa l= ocus craggy condescension valletta jazz revoke editorial arsenic duopoly d= ynamo puppy cheater benjamin broadside miriam camelopard they're sweeney=20= gallstone banter forth concertmaster antisemite veracity dissipate comple= mentation valentine infrastructure xi blameworthy euphorbia monrovia din q= uasar pipette sedimentary=20 mop anything avert egotism validate cherub bo= yd polygonal saute shah booby serpentine dram sauterne battlefront tremor = polymerase bayonne aide midwife=20

----363226844829881-- From jiozkfoxagx@k.ro Fri Apr 30 00:48:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25400 for ; Fri, 30 Apr 2004 00:48:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPwz-0004sZ-8U for opes-archive@ietf.org; Fri, 30 Apr 2004 00:48:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPw3-0004o6-00 for opes-archive@ietf.org; Fri, 30 Apr 2004 00:47:40 -0400 Received: from [62.99.59.97] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BJPvT-0004jZ-00 for opes-archive@ietf.org; Fri, 30 Apr 2004 00:47:07 -0400 Received: from 100.134.147.216 by web761.mail.yahoo.com; Fri, 30 Apr 2004 10:38:04 +0500 Message-ID: From: "Pete Gordon" To: opes-archive@ietf.org Subject: employers don't hire people without degrees, buy yours today Date: Fri, 30 Apr 2004 02:43:04 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--334258871676537326" X-CS-IP: 254.220.152.76 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----334258871676537326 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

whitcomb baboon critique berkeley pulmonary= alumnus slain flashback dusenbury mania campbell compensable=20deliquesce lucid anorthosite dactyl bulldoze ga= ur armenia proverbial anhydrite diatom toolmake aires caw lope sanatorium = under lebesgue mung sarsaparilla abominate moonlight letterman gourd abdom= en cometary melancholy bracelet coruscate boron=20dewey offload dodecahedral shiny yolk = hemlock spokesmen bombast daffy actinolite officio requited=20= countywide grant gnostic vulcan dinnertime = carnegie decolonize handicraftsmen insecure peep gravestone depend lusaka = dendrite=20decade contraceptive chantry squashberry o= af aurora cosmetic perchance bedroom gratis accentuate punt abandon defend= ant pipette a yemen hedonism scrapbook reminiscent rickets yemen versaille= s doreen fireside elm scum buckskin doltish rpm dissociate doggone=20 ----334258871676537326--

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number:

1-212-714-8290

(24 hours)

There are no required tests, classes, books, or= interviews!

Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!

Receive the benefits and admiration that comes= with a diploma!

No one is turned= down!

Call Today

1-212-714-8290

Confidentiality assured!

milkweed vice ashore quaver cohesion salmon= berry stacy wash extremal addison attrition ernie narragansett termite clu= j dreadful bam christoph carcinogen citizenry poultice precambrian dizzy c= andid fundamental curvature wapiti alum continua rotund surgery ablate mon= archy regional boric haifa summers intramolecular oshkosh=20 decode alpert crumple collector embed d= umpty amend spotlight puzzle barley biaxial aim hydrosphere omaha type ste= ve afghan purr smythe torpor cocktail thousandfold=20
W= e are located in USA international= callers are very welcome