From owner-rap@ops.ietf.org  Mon Jul  1 00:22:53 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21188
	for <rap-archive@lists.ietf.org>; Mon, 1 Jul 2002 00:22:52 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17Osf6-0002Pd-00
	for rap-data@psg.com; Sun, 30 Jun 2002 21:19:40 -0700
Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17Osf1-0002OM-00
	for rap@ops.ietf.org; Sun, 30 Jun 2002 21:19:35 -0700
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g614JW307573
	for <rap@ops.ietf.org>; Mon, 1 Jul 2002 00:19:33 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NFR0ZV12; Mon, 1 Jul 2002 00:19:32 -0400
Received: from tweedy.NortelNetworks.com (artpt5kv.us.nortel.com [47.140.52.14]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NSA9GRMC; Mon, 1 Jul 2002 00:19:31 -0400
Message-Id: <5.0.0.25.0.20020701001259.0210cc10@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 01 Jul 2002 00:18:30 -0400
To: rap@ops.ietf.org
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: 2 updated drafts for Yokohama
Cc: Kwok Ho Chan <khchan@NortelNetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.30
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi:
Two updated drafts:
ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-feedback-fr-pib-03.txt
and
ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-cops-frwk-01.txt

have been submitted to Internet-Drafts@ietf.org.
Available here for your reading prior to IETF announcement.
-- Kwok --




From owner-rap@ops.ietf.org  Tue Jul  2 14:47:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07704
	for <rap-archive@lists.ietf.org>; Tue, 2 Jul 2002 14:47:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17PSdb-000Hkq-00
	for rap-data@psg.com; Tue, 02 Jul 2002 11:44:31 -0700
Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17PSdV-000Hkd-00
	for rap@ops.ietf.org; Tue, 02 Jul 2002 11:44:25 -0700
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g62IiOQ17866
	for <rap@ops.ietf.org>; Tue, 2 Jul 2002 14:44:24 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <NYVB94KB>; Tue, 2 Jul 2002 14:44:23 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C04387B31@zcard031.ca.nortel.com>
From: "Louis-Nicolas Hamer" <nhamer@nortelnetworks.com>
To: rap@ops.ietf.org
Subject: Update to drafts
Date: Tue, 2 Jul 2002 14:44:17 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C221F8.78839310"
X-Spam-Status: No, hits=0.1 required=5.0
	tests=MIME_NULL_BLOCK,MSG_ID_ADDED_BY_MTA_3
	version=2.30
Sender: owner-rap@ops.ietf.org
Precedence: bulk

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_01C221F8.78839310
Content-Type: text/plain;
	charset="iso-8859-1"

Dear RAP community,

The following two drafts have been updated to address comments received from
IESG review.
Until they are posted on the IETF web site, here is a link to them:
<ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-session-auth-04.txt>
<ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-rsvp-authsession-03.t
xt>

Here is a summary of the changes:

Document: Session authorization for RSVP

-Most changes are either related to security issues or to a lack of detailed
guidance. 
So we have added a lot of detailed explanations to make sure implementators
had all the required
information. 
-Added a new section called: 4- Integrity of the AUTH_SESSION policy
element.
-Added lots of details in section 5: framework 
-IANA section was totally re-written to provide detailed information about
the required assignments.
-Provided more details/guidance on the format of the AUTH_SESSION fields. 
-Added the generic IETF IPR section as required per RFC2026.
-Changed the DIGITAL_SIGNATURE field to AUTHENTICATION_DATA. And removed the
subtypes, instead making
the algorithm used to compute the authentication data depend on the
AUTH_ENT_ID SubType field.
-Added subtypes FQDN, ASCII_DN & UNICODE_DN in SOURCE_ADDR & DEST_ADDR
field.
-Merged the AUTH_ENT_CRED & AUTH_ENT_ID Types - guidance provide in section
4.

Document: Framework for Session set-up with media authorization

Most comments were related to the lack of information in the security
considerations section.
We have added guidance on the required security characteristics of the
interfaces described in the draft.
Guidance is also provided on whether or not the tokens must be confidential
as well as integrity protected.
Changed the terminology from "district" to "domain".

To both documents:

Minor editorials were made (e.g. separated the references into
normative/informational.)
Cleanup to ensure consistent terminology.
Provided extra needed references.

Cheers,
Louis-Nicolas




------_=_NextPart_001_01C221F8.78839310
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Update to drafts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Dear RAP community,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">The following two drafts have =
been updated to address comments received from IESG review.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">Until they are posted on the =
IETF web site, here is a link to them:</FONT>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-session-au=
th-04.txt" =
TARGET=3D"_blank">ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-=
session-auth-04.txt</A>&gt;</FONT></U><BR>
<U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-rsvp-auths=
ession-03.txt" =
TARGET=3D"_blank">ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-=
rsvp-authsession-03.txt</A>&gt;</FONT></U>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Here is a summary of the =
changes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Document: Session =
authorization for RSVP</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">-Most changes are either =
related to security issues or to a lack of detailed guidance. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">So we have added a lot of =
detailed explanations to make sure implementators had all the =
required</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">information. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Added a new section called: =
4- Integrity of the AUTH_SESSION policy element.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Added lots of details in =
section 5: framework </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-IANA section was totally =
re-written to provide detailed information about the required =
assignments.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Provided more =
details/guidance on the format of the AUTH_SESSION fields. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Added the generic IETF IPR =
section as required per RFC2026.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Changed the =
DIGITAL_SIGNATURE field to AUTHENTICATION_DATA. And removed the =
subtypes, instead making</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">the algorithm used to =
compute the authentication data depend on the AUTH_ENT_ID SubType =
field.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Added subtypes FQDN, =
ASCII_DN &amp; UNICODE_DN in SOURCE_ADDR &amp; DEST_ADDR field.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">-Merged the AUTH_ENT_CRED =
&amp; AUTH_ENT_ID Types - guidance provide in section 4.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Document: Framework for =
Session set-up with media authorization</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Most comments were related to =
the lack of information in the security considerations section.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">We have added guidance on =
the required security characteristics of the interfaces described in =
the draft.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">Guidance is also provided on =
whether or not the tokens must be confidential as well as integrity =
protected.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">Changed the terminology from =
&quot;district&quot; to &quot;domain&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">To both documents:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Minor editorials were made =
(e.g. separated the references into normative/informational.)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">Cleanup to ensure consistent =
terminology.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">Provided extra needed =
references.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Century Gothic">Cheers,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Century Gothic">Louis-Nicolas</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C221F8.78839310--



From owner-rap@ops.ietf.org  Tue Jul  2 20:30:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24895
	for <rap-archive@lists.ietf.org>; Tue, 2 Jul 2002 20:30:30 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17PY0T-000EQ4-00
	for rap-data@psg.com; Tue, 02 Jul 2002 17:28:29 -0700
Received: from pmesmtp01.wcom.com ([199.249.20.1])
	by psg.com with esmtp (Exim 3.36 #1)
	id 17PY0P-000EPt-00
	for rap@ops.ietf.org; Tue, 02 Jul 2002 17:28:25 -0700
Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837)
 id <0GYN00K01DAOBM@firewall.wcom.com> for rap@ops.ietf.org; Wed,
 3 Jul 2002 00:28:00 +0000 (GMT)
Received: from pmismtp05.wcomnet.com ([166.38.62.53])
 by firewall.wcom.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GYN00K34DAO0Q@firewall.wcom.com>; Wed,
 03 Jul 2002 00:28:00 +0000 (GMT)
Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0GYN00H01DAHE8@pmismtp05.wcomnet.com>; Wed,
 03 Jul 2002 00:27:53 +0000 (GMT)
Received: from dgmexch09.wcomnet.com ([166.38.58.240])
 by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0GYN000BMDAH36@pmismtp05.wcomnet.com>; Wed,
 03 Jul 2002 00:27:53 +0000 (GMT)
Received: by DGMEXCH09.wcomnet.com with Internet Mail Service (5.5.2653.19)
 id <M9BJHC1D>; Wed, 03 Jul 2002 00:27:59 +0000
Content-return: allowed
Date: Wed, 03 Jul 2002 00:27:58 +0000
From: "Rawlins, Diana" <Diana.Rawlins@wcom.com>
Subject: RE: 2 updated drafts for Yokohama
To: "'Kwok Ho Chan'" <khchan@NortelNetworks.com>, rap@ops.ietf.org
Message-id: <6EFD2D8565069542A1029F2D17B546250FCD15@ripexch001.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; CHARSET=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.30
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Kwok,

I'm not able to access the below ftp site pages. - "page cannot be
displayed"

There was no update was made to the feedback framework to my knowledge. I've
attached the url to the March version.
http://search.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt

The feedback pib-03 was, as you said, just submitted to the IETF. Thanks for
posting it to a site (now if I could just read it.)

Thanks,
-Diana




-----Original Message-----
From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com] 
Sent: Sunday, June 30, 2002 11:19 PM
To: rap@ops.ietf.org
Cc: Kwok Ho Chan
Subject: 2 updated drafts for Yokohama

Hi:
Two updated drafts:
ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-feedback-fr-pib-03.txt
and
ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-cops-frwk-01.txt

have been submitted to Internet-Drafts@ietf.org.
Available here for your reading prior to IETF announcement.
-- Kwok --




From owner-rap@ops.ietf.org  Wed Jul  3 06:32:47 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04177
	for <rap-archive@lists.ietf.org>; Wed, 3 Jul 2002 06:32:47 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17PhQp-00005E-00
	for rap-data@psg.com; Wed, 03 Jul 2002 03:32:19 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17PhQh-00003j-00
	for rap@ops.ietf.org; Wed, 03 Jul 2002 03:32:11 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04006;
	Wed, 3 Jul 2002 06:31:21 -0400 (EDT)
Message-Id: <200207031031.GAA04006@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-session-auth-04.txt
Date: Wed, 03 Jul 2002 06:31:21 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6,
	      DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: Framework for session set-up with media authorization
	Author(s)	: L. Hamer, B. Gage, H. Shieh
	Filename	: draft-ietf-rap-session-auth-04.txt
	Pages		: 25
	Date		: 02-Jul-02
	
Establishing multimedia streams must take into account requirements 
for end-to-end QoS, authorization of network resource usage and 
accurate accounting for resources used. During session set up, 
policies may be enforced to ensure that the media streams being 
requested lie within the bounds of the service profile established 
for the requesting host. Similarly, when a host requests resources 
to provide a certain QoS for a packet flow, policies may be enforced 
to ensure that the required resources lie within the bounds of the 
resource profile established for the requesting host. 
To prevent fraud and to ensure accurate billing, we describe various 
scenarios and mechanisms that provide the linkage required to verify 
that the resources being used to provide a requested QoS are in-line 
with the media streams requested (and authorized) for the session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-session-auth-04.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-rap-session-auth-04.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:	<20020702151715.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-session-auth-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-session-auth-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020702151715.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Wed Jul  3 06:32:50 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04193
	for <rap-archive@lists.ietf.org>; Wed, 3 Jul 2002 06:32:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17PhR2-000076-00
	for rap-data@psg.com; Wed, 03 Jul 2002 03:32:32 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17PhQn-00004S-00
	for rap@ops.ietf.org; Wed, 03 Jul 2002 03:32:17 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04024;
	Wed, 3 Jul 2002 06:31:27 -0400 (EDT)
Message-Id: <200207031031.GAA04024@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-rsvp-authsession-03.txt
Date: Wed, 03 Jul 2002 06:31:27 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6,
	      DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: Session Authorization for RSVP
	Author(s)	: L. Hamer, B. Gage, M. Broda, B. Kosinski, H. Shieh
	Filename	: draft-ietf-rap-rsvp-authsession-03.txt
	Pages		: 15
	Date		: 02-Jul-02
	
This document describes the representation of session authorization 
information in the POLICY_DATA object (RFC 2750) for supporting 
policy-based per-session authorization and admission control in 
RSVP.  The goal of session authorization is to allow the exchange of 
information between network elements in order to authorize the use 
of resources for a service and to co-ordinate actions between the 
signaling and transport planes.  This document describes how a 
process on a system authorizes the reservation of resources by a 
host and then provides that host with a session authorization policy 
element which can be inserted into the RSVP PATH message to 
facilitate proper and secure reservation of those resources within 
the network. We describe the encoding of media authorization 
information as RSVP policy elements and provide details relating to 
operations, processing rules and error scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-rsvp-authsession-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-rap-rsvp-authsession-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:	<20020702151728.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-rsvp-authsession-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-rsvp-authsession-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020702151728.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Wed Jul  3 14:04:24 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24541
	for <rap-archive@lists.ietf.org>; Wed, 3 Jul 2002 14:04:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17PnxA-000Nin-00
	for rap-data@psg.com; Wed, 03 Jul 2002 10:30:08 -0700
Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17Pnx0-000Ni2-00
	for rap@ops.ietf.org; Wed, 03 Jul 2002 10:29:58 -0700
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g63HTtZ02428;
	Wed, 3 Jul 2002 13:29:55 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NFR057B4; Wed, 3 Jul 2002 13:29:54 -0400
Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.175]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NSA9GVMT; Wed, 3 Jul 2002 13:29:54 -0400
Message-Id: <5.0.0.25.0.20020703132632.0318ab80@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 03 Jul 2002 13:28:48 -0400
To: "Rawlins, Diana" <Diana.Rawlins@wcom.com>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: RE: 2 updated drafts for Yokohama
Cc: "Kwok-Ho Chan" <khchan@NortelNetworks.com>, rap@ops.ietf.org
In-Reply-To: <6EFD2D8565069542A1029F2D17B546250FCD15@ripexch001.wcomnet.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=-3.4 required=5.0
	tests=IN_REP_TO
	version=2.30
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Diana:
I can access the drafts OK by just clicking on the links below.
Please let me know if you continue to have problem.

The other draft is COPS Framework, not Feedback Framework.
-- Kwok --


At 12:27 AM 7/3/02 +0000, Rawlins, Diana wrote:
>Kwok,
>
>I'm not able to access the below ftp site pages. - "page cannot be
>displayed"
>
>There was no update was made to the feedback framework to my knowledge. I've
>attached the url to the March version.
>http://search.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt
>
>The feedback pib-03 was, as you said, just submitted to the IETF. Thanks for
>posting it to a site (now if I could just read it.)
>
>Thanks,
>-Diana
>
>
>
>
>-----Original Message-----
>From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com]
>Sent: Sunday, June 30, 2002 11:19 PM
>To: rap@ops.ietf.org
>Cc: Kwok Ho Chan
>Subject: 2 updated drafts for Yokohama
>
>Hi:
>Two updated drafts:
>ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-feedback-fr-pib-03.txt
>and
>ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-cops-frwk-01.txt
>
>have been submitted to Internet-Drafts@ietf.org.
>Available here for your reading prior to IETF announcement.
>-- Kwok --




From owner-rap@ops.ietf.org  Wed Jul  3 14:29:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26567
	for <rap-archive@lists.ietf.org>; Wed, 3 Jul 2002 14:29:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17Poso-000Pbe-00
	for rap-data@psg.com; Wed, 03 Jul 2002 11:29:42 -0700
Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.ca.nortel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17Posk-000PbP-00
	for rap@ops.ietf.org; Wed, 03 Jul 2002 11:29:38 -0700
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g63ITZZ06448;
	Wed, 3 Jul 2002 14:29:35 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NFR0583A; Wed, 3 Jul 2002 14:29:35 -0400
Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.175]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NSA9GVQR; Wed, 3 Jul 2002 14:29:34 -0400
Message-Id: <5.0.0.25.0.20020703142341.026264d0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 03 Jul 2002 14:28:25 -0400
To: rap@ops.ietf.org
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Updated COPS-SLS draft for Yokohama
Cc: trnguyen@enst.fr, Kwok Ho Chan <khchan@NortelNetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.30
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi:
The updated draft:
ftp://standards.nortelnetworks.com/rap/draft-nguyen-rap-cops-sls-03.txt

have been submitted to Internet-Drafts@ietf.org.
Available here for your reading prior to IETF announcement.

Please let me know if you have any problem accessing it.
-- Kwok --





From owner-rap@ops.ietf.org  Fri Jul  5 06:38:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17809
	for <rap-archive@lists.ietf.org>; Fri, 5 Jul 2002 06:38:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17QQSw-000CgH-00
	for rap-data@psg.com; Fri, 05 Jul 2002 03:37:30 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17QQSr-000Cg1-00
	for rap@ops.ietf.org; Fri, 05 Jul 2002 03:37:25 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17505;
	Fri, 5 Jul 2002 06:36:35 -0400 (EDT)
Message-Id: <200207051036.GAA17505@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-cops-tls-04.txt
Date: Fri, 05 Jul 2002 06:36:35 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6,
	      DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: COPS Over TLS
	Author(s)	: J. Walker, A. Kulkarni
	Filename	: draft-ietf-rap-cops-tls-04.txt
	Pages		: 11
	Date		: 03-Jul-02
	
This memo describes how to use TLS to secure COPS connections over 
the Internet.  
Please send comments on this document to the rap@ops.ietf.org 
mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-cops-tls-04.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-rap-cops-tls-04.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:	<20020703132351.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-cops-tls-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-cops-tls-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020703132351.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Fri Jul  5 06:38:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17825
	for <rap-archive@lists.ietf.org>; Fri, 5 Jul 2002 06:38:30 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17QQT1-000CgW-00
	for rap-data@psg.com; Fri, 05 Jul 2002 03:37:35 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17QQSw-000CgE-00
	for rap@ops.ietf.org; Fri, 05 Jul 2002 03:37:30 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17531;
	Fri, 5 Jul 2002 06:36:39 -0400 (EDT)
Message-Id: <200207051036.GAA17531@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-feedback-fr-pib-03.txt
Date: Fri, 05 Jul 2002 06:36:39 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,DOUBLE_CAPSWORD,
	      EXCUSE_6
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: Framework of COPS-PR Policy Information Base for 
                          Policy Usage Feedback
	Author(s)	: D. Rawlins et al.
	Filename	: draft-ietf-rap-feedback-fr-pib-03.txt
	Pages		: 27
	Date		: 03-Jul-02
	
Currently there are no policy classes defined for the PEP to convey 
provisioned policy usage feedback to the PDP. The purpose of this 
document is to define the policy usage feedback framework PIB that 
specifies the policy classes common for COPS feedback reports. The 
basic operation and objects for reporting usage information are 
defined in [COPS]. A specific clientSI feedback object named REPORT 
is defined in [COPS-PR]. A framework for approaching solicited and 
periodic usage feedback is described in [COPS-FEED-FRWK]. The COPS-
PR Policy Usage Feedback Policy Information Base document defines 
the policy classes for a feedback framework Policy information base 
(PIB).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-feedback-fr-pib-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-rap-feedback-fr-pib-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:	<20020703132437.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-feedback-fr-pib-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020703132437.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Fri Jul  5 06:39:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17851
	for <rap-archive@lists.ietf.org>; Fri, 5 Jul 2002 06:39:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17QQT7-000ChT-00
	for rap-data@psg.com; Fri, 05 Jul 2002 03:37:41 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17QQT1-000CgV-00
	for rap@ops.ietf.org; Fri, 05 Jul 2002 03:37:35 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17546;
	Fri, 5 Jul 2002 06:36:44 -0400 (EDT)
Message-Id: <200207051036.GAA17546@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-feedback-fr-pib-03.txt
Date: Fri, 05 Jul 2002 06:36:44 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,DOUBLE_CAPSWORD,
	      EXCUSE_6
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: Framework of COPS-PR Policy Information Base for 
                          Policy Usage Feedback
	Author(s)	: D. Rawlins et al.
	Filename	: draft-ietf-rap-feedback-fr-pib-03.txt
	Pages		: 27
	Date		: 03-Jul-02
	
Currently there are no policy classes defined for the PEP to convey 
provisioned policy usage feedback to the PDP. The purpose of this 
document is to define the policy usage feedback framework PIB that 
specifies the policy classes common for COPS feedback reports. The 
basic operation and objects for reporting usage information are 
defined in [COPS]. A specific clientSI feedback object named REPORT 
is defined in [COPS-PR]. A framework for approaching solicited and 
periodic usage feedback is described in [COPS-FEED-FRWK]. The COPS-
PR Policy Usage Feedback Policy Information Base document defines 
the policy classes for a feedback framework Policy information base 
(PIB).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-feedback-fr-pib-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-rap-feedback-fr-pib-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:	<20020703132452.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-feedback-fr-pib-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020703132452.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Fri Jul  5 06:39:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17872
	for <rap-archive@lists.ietf.org>; Fri, 5 Jul 2002 06:39:30 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17QQSm-000Cfo-00
	for rap-data@psg.com; Fri, 05 Jul 2002 03:37:20 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17QQSh-000CfV-00
	for rap@ops.ietf.org; Fri, 05 Jul 2002 03:37:15 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17475;
	Fri, 5 Jul 2002 06:36:24 -0400 (EDT)
Message-Id: <200207051036.GAA17475@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-cops-frwk-01.txt
Date: Fri, 05 Jul 2002 06:36:24 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6,
	      DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: An Architecture for COPS Based Policy Control 
                          Management Framework
	Author(s)	: K. Chan, L. Hamer
	Filename	: draft-ietf-rap-cops-frwk-01.txt
	Pages		: 3
	Date		: 03-Jul-02
	
This document describes an architecture for a COPS based Policy 
Control Management System Framework.  The architecture is designed 
to be modular, allowing future modification and addition to existing 
framework.  The major units of the architecture are the Policy 
Decision Points (PDP), the Access Edge Policy Enforcement Points 
(AE_PEP), the Core Policy Enforcement Points (C_PEP).  With Message 
Processing Subsystem, Security Subsystem, Framework Data Model 
Subsystem, and Application Specific Data Model Subsystem in each PDP 
and PEP. 
This document further provides a high level description of each unit 
and describes the relationship among each unit.  This document also 
describes how the subsystems within each unit interact with each 
other to provide the functionality of a Policy Control Management 
System.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-frwk-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-cops-frwk-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rap-cops-frwk-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020703132340.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-cops-frwk-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-cops-frwk-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020703132340.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Fri Jul  5 06:40:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17938
	for <rap-archive@lists.ietf.org>; Fri, 5 Jul 2002 06:40:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17QQSr-000Cg4-00
	for rap-data@psg.com; Fri, 05 Jul 2002 03:37:25 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17QQSm-000Cfn-00
	for rap@ops.ietf.org; Fri, 05 Jul 2002 03:37:20 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17490;
	Fri, 5 Jul 2002 06:36:30 -0400 (EDT)
Message-Id: <200207051036.GAA17490@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-cops-tls-04.txt
Date: Fri, 05 Jul 2002 06:36:29 -0400
X-Spam-Status: No, hits=1.4 required=5.0
	tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6,
	      DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Allocation Protocol Working Group of the IETF.

	Title		: COPS Over TLS
	Author(s)	: J. Walker, A. Kulkarni
	Filename	: draft-ietf-rap-cops-tls-04.txt
	Pages		: 11
	Date		: 03-Jul-02
	
This memo describes how to use TLS to secure COPS connections over 
the Internet.  
Please send comments on this document to the rap@ops.ietf.org 
mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rap-cops-tls-04.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-rap-cops-tls-04.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:	<20020703132351.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-cops-tls-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-cops-tls-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020703132351.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Mon Jul  8 09:14:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13360
	for <rap-archive@lists.ietf.org>; Mon, 8 Jul 2002 09:14:37 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17RYI5-0002u6-00
	for rap-data@psg.com; Mon, 08 Jul 2002 06:10:57 -0700
Received: from mail2.orchestream.com ([195.153.64.126])
	by psg.com with esmtp (Exim 3.36 #1)
	id 17RYHg-0002td-00
	for rap@ops.ietf.org; Mon, 08 Jul 2002 06:10:32 -0700
Received: from rimmer.orchestream.com (unverified) by mail2.orchestream.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id <T5bf6f723f7c399407e0c5@mail2.orchestream.com> for <rap@ops.ietf.org>;
 Mon, 8 Jul 2002 14:10:15 +0100
Received: from S1000.orchestream.com (s1000.orchestream.com [192.168.0.16])
	by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id OAA03233
	for <rap@ops.ietf.org>; Mon, 8 Jul 2002 14:10:15 +0100
Received: by S1000.orchestream.com with Internet Mail Service (5.5.2653.19)
	id <31D2J77J>; Mon, 8 Jul 2002 14:10:15 +0100
Message-ID: <8AEA6B34A5AF2D4ABECB4E9351DAE69821267D@S1000.orchestream.com>
From: "Da Silva, Pedro" <pdasilva@orchestream.com>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: RE: 2 updated drafts for Yokohama
Date: Mon, 8 Jul 2002 14:10:15 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Status: No, hits=1.1 required=5.0
	tests=DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi,

Reading the framework doc, first thing that popped to mind is that
outsourcing always has to be present because there is no way to provision a
PEP that has not yet contacted the PDP. That is we always need the PEP to
open, to initiate a config session with the PDP; the PDP cannot proactively
contact a PEP to configure it. So, at least, we need the OPEN message from
the outsourcing model in any situation, be it a core or whatever router.
This is somewhat of a problem for the traditional management model. We
circumvented the prob by configuring the device to contact our PDP after
startup, as COPS allows for this. I believe this is a legacy issue stemming
from RSVP.

Pedro

-----Original Message-----
From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com]
Sent: Monday, July 01, 2002 5:19 AM
To: rap@ops.ietf.org
Cc: Kwok Ho Chan
Subject: 2 updated drafts for Yokohama


Hi:
Two updated drafts:
ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-feedback-fr-pib-03.txt
and
ftp://standards.nortelnetworks.com/rap/draft-ietf-rap-cops-frwk-01.txt

have been submitted to Internet-Drafts@ietf.org.
Available here for your reading prior to IETF announcement.
-- Kwok --




From owner-rap@ops.ietf.org  Mon Jul  8 14:31:51 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00360
	for <rap-archive@lists.ietf.org>; Mon, 8 Jul 2002 14:31:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17RdGe-0009sJ-00
	for rap-data@psg.com; Mon, 08 Jul 2002 11:29:48 -0700
Received: from chfdns02.ch.intel.com ([143.182.246.25] helo=melete.ch.intel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17RdGQ-0009s2-00
	for rap@ops.ietf.org; Mon, 08 Jul 2002 11:29:34 -0700
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128])
	by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g68ITX303423
	for <rap@ops.ietf.org>; Mon, 8 Jul 2002 18:29:33 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002070811301104097
 ; Mon, 08 Jul 2002 11:30:11 -0700
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <NWJ6Y8M1>; Mon, 8 Jul 2002 11:29:32 -0700
Message-ID: <59885C5E3098D511AD690002A5072D3C06F745C5@orsmsx111.jf.intel.com>
From: "Hahn, Scott" <scott.hahn@intel.com>
To: rap@ops.ietf.org
Cc: "Mark L. Stevens (E-mail)" <mlstevens@rcn.com>,
        "Bert Wijnen (Bert) (E-mail)" <bwijnen@lucent.com>,
        Louis-Nicolas Hamer
	 <nhamer@nortelnetworks.com>
Subject: Final  WG last call for  draft-ietf-rap-rsvp-authsession-03.txt a
	nd draft-ietf-rap-session-auth-04.txt            
Date: Mon, 8 Jul 2002 11:29:26 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Status: No, hits=4.0 required=5.0
	tests=SUBJ_HAS_SPACES
	version=2.30
X-Spam-Level: ****
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Based on the IESG review, the authors of the
"draft-ietf-rap-session-auth-04" and "draft-ietf-rap-rsvp-authsession-03"
have updated the drafts and posted a summary of the changes to the mailing
list. I would like to issue a short WG last call to insure that all the
changes meet with the WG's approval. Please review the drafts and send any
comments to the list by end of day  (5:00 PM EDT) on the 12th of July.

    -Scott Hahn
    RAP WG co-chair



From owner-rap@ops.ietf.org  Thu Jul 11 14:24:53 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29707
	for <rap-archive@lists.ietf.org>; Thu, 11 Jul 2002 14:24:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17Sibo-0007z6-00
	for rap-data@psg.com; Thu, 11 Jul 2002 11:24:08 -0700
Received: from chfdns02.ch.intel.com ([143.182.246.25] helo=melete.ch.intel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17Sib1-0007x1-00
	for rap@ops.ietf.org; Thu, 11 Jul 2002 11:23:19 -0700
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128])
	by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6BINI505100
	for <rap@ops.ietf.org>; Thu, 11 Jul 2002 18:23:19 GMT
Received: from FMSMSX018.fm.intel.com ([132.233.42.197])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071111235904517
 ; Thu, 11 Jul 2002 11:23:59 -0700
Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <3WZFX5GM>; Thu, 11 Jul 2002 11:23:18 -0700
Message-ID: <59885C5E3098D511AD690002A5072D3C0747F4B2@orsmsx111.jf.intel.com>
From: "Hahn, Scott" <scott.hahn@intel.com>
To: agenda@ietf.org
Cc: rap@ops.ietf.org, "Mark L. Stevens (E-mail)" <mlstevens@rcn.com>,
        "Bert Wijnen (Bert) (E-mail)" <bwijnen@lucent.com>
Subject: Agenda items for RAP meeting in Yokohama
Date: Thu, 11 Jul 2002 11:23:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Status: No, hits=1.1 required=5.0
	tests=DOUBLE_CAPSWORD
	version=2.30
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

All,

Here is a proposed agenda for the Yokohama meeting. RAP will be meeting on
TUESDAY, July 16, 2002 from 1300-1400.

RAP WG Agenda (Preliminary)
---------------------------------------------
0. Agenda Bashing 
1. Draft Status: (5 minutes)
 	
2. Usage Feedback: (5 minutes) - Diana Rawlins
 
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt
	
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt
3. RSVP PIB: (5 minutes) - Diana Rawlins
	
http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvppcc-pib-01.txt
 
4. COPS Framework: (20 minutes)- Kwok Chan
	http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-frwk-01.txt

5. COPS Usage for SLS negotiation (COPS-SLS) (15 minutes) - Yacine El
Mghazli
	
http://search.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-03.txt
   

If you have any items that you would like to present, please let me know and
we will see what we can do.

Thanks,
	-Scott



From owner-rap@ops.ietf.org  Wed Jul 24 10:08:42 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17894
	for <rap-archive@lists.ietf.org>; Wed, 24 Jul 2002 10:08:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17XG7P-000C0Q-00
	for rap-data@psg.com; Tue, 23 Jul 2002 23:59:31 -0700
Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17XG7K-000C0D-00
	for rap@ops.ietf.org; Tue, 23 Jul 2002 23:59:27 -0700
Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1])
	by tparelay.telradnetworks.co.il (8.9.3+Sun/8.9.3) with ESMTP id JAA19005
	for <rap@ops.ietf.org>; Wed, 24 Jul 2002 09:58:28 +0300 (IDT)
Received: from tpa-mail1.telradnetworks.co.il ([141.226.76.57])
	by tparelay.telradnetworks.co.il (8.9.3+Sun/8.9.3) with ESMTP id JAA19001
	for <rap@ops.ietf.org>; Wed, 24 Jul 2002 09:58:28 +0300 (IDT)
Received: by tpa-mail1.telradnetworks.co.il with Internet Mail Service (5.5.2654.89)
	id <PQ0QDANR>; Wed, 24 Jul 2002 09:58:30 +0200
Message-ID: <E20C627AB7F6D4118C4200508BB3C49A034C182B@tpa-mail1.telradnetworks.co.il>
From: Dan Davidson <dan.davidson@commatch.com>
To: rap@ops.ietf.org
Subject: COPS : Clarifications
Date: Wed, 24 Jul 2002 09:58:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="windows-1255"
X-Spam-Status: No, hits=1.1 required=5.0
	tests=MSG_ID_ADDED_BY_MTA_3
	version=2.31
X-Spam-Level: *
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi,

	In section 2.3 "Communication" of the COPS protocol (RFC 2748) the
following
sentences can be encountered:

"The COPS protocol uses a single persistent TCP connection between the PEP
and a remote PDP"

a little later in the same section":

"If a single PEP can support multiple client-types, it may send multiple
Client-Open messages, each specifying a particular client-type to a PDP over
one or more TCP
connections".

The question is: How many TCP connections are there ? A single one or
multiples ?

Thanks for the help,
Best Regards,
Dan



From owner-rap@ops.ietf.org  Wed Jul 24 10:08:43 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17907
	for <rap-archive@lists.ietf.org>; Wed, 24 Jul 2002 10:08:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17XLJE-0001TI-00
	for rap-data@psg.com; Wed, 24 Jul 2002 05:32:04 -0700
Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17XLJ3-0001SU-00
	for rap@ops.ietf.org; Wed, 24 Jul 2002 05:31:53 -0700
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OCVlg08983;
	Wed, 24 Jul 2002 08:31:48 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NFSABX4J; Wed, 24 Jul 2002 08:31:47 -0400
Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.135.155]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NSA9HPCX; Wed, 24 Jul 2002 08:31:45 -0400
Message-Id: <5.0.0.25.0.20020724082738.02a85050@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 24 Jul 2002 08:30:24 -0400
To: Dan Davidson <dan.davidson@commatch.com>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: COPS : Clarifications
Cc: rap@ops.ietf.org
In-Reply-To: <E20C627AB7F6D4118C4200508BB3C49A034C182B@tpa-mail1.telradn
 etworks.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=-2.3 required=5.0
	tests=IN_REP_TO,DOUBLE_CAPSWORD
	version=2.31
Sender: owner-rap@ops.ietf.org
Precedence: bulk

In normal operation, only a single TCP connection is needed, because
multiple COPS Client OPEN can be multiplexed over the same TCP
connection.  But this does not limit the use of multiple TCP connections
if it is necessary.
-- Kwok Ho Chan --

At 09:58 AM 7/24/02 +0200, Dan Davidson wrote:
>Hi,
>
>         In section 2.3 "Communication" of the COPS protocol (RFC 2748) the
>following
>sentences can be encountered:
>
>"The COPS protocol uses a single persistent TCP connection between the PEP
>and a remote PDP"
>
>a little later in the same section":
>
>"If a single PEP can support multiple client-types, it may send multiple
>Client-Open messages, each specifying a particular client-type to a PDP over
>one or more TCP
>connections".
>
>The question is: How many TCP connections are there ? A single one or
>multiples ?
>
>Thanks for the help,
>Best Regards,
>Dan




From owner-rap@ops.ietf.org  Wed Jul 24 10:09:01 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17965
	for <rap-archive@lists.ietf.org>; Wed, 24 Jul 2002 10:09:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17XMKl-0005Mk-00
	for rap-data@psg.com; Wed, 24 Jul 2002 06:37:43 -0700
Received: from [2001:418:1::39] (helo=rip.psg.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17XMKf-0005MU-00
	for rap@ops.ietf.org; Wed, 24 Jul 2002 06:37:37 -0700
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com)
	by rip.psg.com with esmtp (Exim 4.10)
	id 17XMKe-000OIl-00
	for rap@ops.ietf.org; Wed, 24 Jul 2002 06:37:37 -0700
Message-ID: <7319EDDDE0CD7C458023FF64886CB177015E87E5@sgpk001a.sae.siemens.com.sg>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C232ED.094454CA"
From: Bhattacharjya Probal <probal.bhattacharjya@siemens.com>
To: Dan Davidson <dan.davidson@commatch.com>
Cc: rap@ops.ietf.org
Subject: RE: COPS : Clarifications
Date: Wed, 24 Jul 2002 16:35:16 +0800
X-Spam-Status: No, hits=0.2 required=5.0
	tests=MIME_NULL_BLOCK,DOUBLE_CAPSWORD,DEAR_SOMEBODY,MAILTO_LINK
	version=2.31
Sender: owner-rap@ops.ietf.org
Precedence: bulk

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_01C232ED.094454CA
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C232ED.094454CA"


------_=_NextPart_001_01C232ED.094454CA
Content-Type: text/plain;
	charset="windows-1255"

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Please refer to the following reply from David Durham (I hope it's okay with
David to be quoted without permission! ) to the same question a while back.

Regards,
   --Probal.



> -----Original Message-----
> From: Dan Davidson [mailto:dan.davidson@commatch.com]
> Sent: Wednesday, July 24, 2002 3:58 PM
> To: rap@ops.ietf.org
> Subject: COPS : Clarifications
> 
> 
> Hi,
> 
> 	In section 2.3 "Communication" of the COPS protocol 
> (RFC 2748) the
> following
> sentences can be encountered:
> 
> "The COPS protocol uses a single persistent TCP connection 
> between the PEP
> and a remote PDP"
> 
> a little later in the same section":
> 
> "If a single PEP can support multiple client-types, it may 
> send multiple
> Client-Open messages, each specifying a particular 
> client-type to a PDP over
> one or more TCP
> connections".
> 
> The question is: How many TCP connections are there ? A single one or
> multiples ?
> 
> Thanks for the help,
> Best Regards,
> Dan
> 


------_=_NextPart_001_01C232ED.094454CA
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: COPS : Clarifications</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please refer to the following reply from David Durham =
(I hope it's okay with David to be quoted without permission! ) to the =
same question a while back.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; --Probal.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Dan Davidson [<A =
HREF=3D"mailto:dan.davidson@commatch.com">mailto:dan.davidson@commatch.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, July 24, 2002 3:58 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: COPS : Clarifications</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In section 2.3 =
&quot;Communication&quot; of the COPS protocol </FONT>
<BR><FONT SIZE=3D2>&gt; (RFC 2748) the</FONT>
<BR><FONT SIZE=3D2>&gt; following</FONT>
<BR><FONT SIZE=3D2>&gt; sentences can be encountered:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;The COPS protocol uses a single =
persistent TCP connection </FONT>
<BR><FONT SIZE=3D2>&gt; between the PEP</FONT>
<BR><FONT SIZE=3D2>&gt; and a remote PDP&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; a little later in the same =
section&quot;:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;If a single PEP can support multiple =
client-types, it may </FONT>
<BR><FONT SIZE=3D2>&gt; send multiple</FONT>
<BR><FONT SIZE=3D2>&gt; Client-Open messages, each specifying a =
particular </FONT>
<BR><FONT SIZE=3D2>&gt; client-type to a PDP over</FONT>
<BR><FONT SIZE=3D2>&gt; one or more TCP</FONT>
<BR><FONT SIZE=3D2>&gt; connections&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The question is: How many TCP connections are =
there ? A single one or</FONT>
<BR><FONT SIZE=3D2>&gt; multiples ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks for the help,</FONT>
<BR><FONT SIZE=3D2>&gt; Best Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Dan</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C232ED.094454CA--

------_=_NextPart_000_01C232ED.094454CA
Content-Type: message/rfc822
Content-Description: RE: Question about COPS RFC (2748)

Message-ID: <10C8636AE359D4119118009027AE99870DA5DFB1@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: Bhattacharjya Probal <probal.bhattacharjya@siemens.com>
Subject: RE: Question about COPS RFC (2748)
Date: Thu, 18 Apr 2002 23:52:21 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_003_01C232ED.094454CA"


------_=_NextPart_003_01C232ED.094454CA
Content-Type: text/plain;
	charset="windows-1255"

Hi Probal,
The COPS protocol using a single persistent connection between the PEP and
remote PDP serving one or more client-types. Multiple client-types between
the same PEP and PDP may share the same or establish multiple TCP
connections (no more than one per client type, however). There is an
efficiency gain if they all share the same TCP connection, but this is not a
MUST.
 
I agree the RFC is not very clear on this. The answer is one or more TCP
connections, no more than one per client-type, with one being the preferred
arrangement.
 
-Dave

-----Original Message-----
From: Bhattacharjya Probal [mailto:probal.bhattacharjya@siemens.com]
Sent: Wednesday, April 17, 2002 6:15 PM
To: David.Durham@intel.com
Subject: Question about COPS RFC (2748)



Dear Sir, 

I have a possibly silly question about the COPS RFC (RFC 2748) and would
like to have your clarification as the editor of the RFC. In section 2.3
called "Communication" the very first sentence asserts that

"The COPS protocol uses a SINGLE persistent TCP connection between the PEP
and a remote PDP". 

And then in the second paragraph, the first sentence (which spans three
lines) says 

"If a single PEP can support multiple client-types, it may send multiple
Client-Open messages, each specifying a particular client-type to a PDP over
one or MORE TCP connections"

[I have EMPHASISED the parts I want to draw your attention to!] 

My question is if according ot the former sentence there could only be a
"SINGLE" TCP connection between a PEP and a PDP, then how is it according to
the latter sentence that a PEP may send multiple messages to a PDP over
possible "MORE than one" TCP connections?

Is it then possible to have "more than one" TCP connection between a PEP and
a PDP? In that case the former sentence is not correct in asserting that
there could only be a "single" TCP connection between them!!

Please clarify. 

Thanks, 
   --Probal. 

--------------------------------------------------------- 
  
Probal K. Bhattacharjya 
Siemens Pte Ltd 


------_=_NextPart_003_01C232ED.094454CA
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">


<TITLE>Question about COPS RFC (2748)</TITLE>

<META content="MSHTML 5.50.4913.1100" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=201284615-18042002><FONT face=Arial color=#0000ff size=2>Hi 
Probal,</FONT></SPAN></DIV>
<DIV><SPAN class=201284615-18042002><FONT face=Arial color=#0000ff size=2>The 
COPS protocol using a single persistent connection between the PEP and remote 
PDP serving&nbsp;one or more client-types. Multiple client-types between the 
same PEP and PDP may share the same or establish multiple TCP connections (no 
more than one per client type, however). There is an efficiency gain if they all 
share the same TCP connection, but this is not a MUST.</FONT></SPAN></DIV>
<DIV><SPAN class=201284615-18042002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=201284615-18042002><FONT face=Arial color=#0000ff size=2>I 
agree the RFC is not very clear on this. The answer is one or more TCP 
connections, no more than one per client-type, with one being the preferred 
arrangement.</FONT></SPAN></DIV>
<DIV><SPAN class=201284615-18042002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=201284615-18042002><FONT face=Arial color=#0000ff 
size=2>-Dave</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Bhattacharjya Probal 
  [mailto:probal.bhattacharjya@siemens.com]<BR><B>Sent:</B> Wednesday, April 17, 
  2002 6:15 PM<BR><B>To:</B> David.Durham@intel.com<BR><B>Subject:</B> Question 
  about COPS RFC (2748)<BR><BR></FONT></DIV>
  <P><FONT size=2>Dear Sir,</FONT> </P>
  <P><FONT size=2>I have a possibly silly question about the COPS RFC (RFC 2748) 
  and would like to have your clarification as the editor of the RFC. In section 
  2.3 called "Communication" the very first sentence asserts that</FONT></P>
  <P><FONT size=2>"The COPS protocol uses a SINGLE persistent TCP connection 
  between the PEP and a remote PDP".</FONT> </P>
  <P><FONT size=2>And then in the second paragraph, the first sentence (which 
  spans three lines) says </FONT></P>
  <P><FONT size=2>"If a single PEP can support multiple client-types, it may 
  send multiple Client-Open messages, each specifying a particular client-type 
  to a PDP over one or MORE TCP connections"</FONT></P>
  <P><FONT size=2>[I have EMPHASISED the parts I want to draw your attention 
  to!]</FONT> </P>
  <P><FONT size=2>My question is if according ot the former sentence there could 
  only be a "SINGLE" TCP connection between a PEP and a PDP, then how is it 
  according to the latter sentence that a PEP may send multiple messages to a 
  PDP over possible "MORE than one" TCP connections?</FONT></P>
  <P><FONT size=2>Is it then possible to have "more than one" TCP connection 
  between a PEP and a PDP? In that case the former sentence is not correct in 
  asserting that there could only be a "single" TCP connection between 
  them!!</FONT></P>
  <P><FONT size=2>Please clarify.</FONT> </P>
  <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>&nbsp;&nbsp; --Probal.</FONT> 
  </P>
  <P><FONT 
  size=2>---------------------------------------------------------</FONT> 
  <BR><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>Probal K. Bhattacharjya 
  </FONT><BR><FONT size=2>Siemens Pte Ltd</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_003_01C232ED.094454CA--

------_=_NextPart_000_01C232ED.094454CA--





From owner-rap@ops.ietf.org  Fri Jul 26 17:01:25 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08680
	for <rap-archive@lists.ietf.org>; Fri, 26 Jul 2002 17:01:24 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17YCAe-000JbL-00
	for rap-data@psg.com; Fri, 26 Jul 2002 13:58:44 -0700
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17YCAZ-000JbA-00
	for rap@ops.ietf.org; Fri, 26 Jul 2002 13:58:39 -0700
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6QKwbZ07823
	for <rap@ops.ietf.org>; Fri, 26 Jul 2002 16:58:37 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <PQL5KGG5>; Fri, 26 Jul 2002 22:58:36 +0200
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0E937CCC@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Rap-wg (E-mail)" <rap@ops.ietf.org>
Cc: "Steve Bellovin (E-mail)" <smb@research.att.com>,
        "Eric Rescorla (E-mail)" <ekr@rtfm.com>
Subject: FW: draft-ietf-rap-rsvp-authsession documents
Date: Fri, 26 Jul 2002 22:58:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.31
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Authors/WG, 

The documents 
    draft-ietf-rap-rsvp-authsession-03.txt
    draft-ietf-rap-session-auth-04.txt
were on the IESG agenda yesterday. 

I still have to collect some more feedback, so the below is incomplete.

But the security issues are the most serious concern, so here it is
for your response and corrections. I have added Steve Bellovin and
Eric Rescorla on the cc: list, so that when you respond, they can
also see the responses and react immediately/directly. Steve and Eric
(as you can see below) have worked on the comments together.

Here we go:

--- comment from Steve

The new version is a lot better, and goes a long way towards resolving 
my objections.  But I don't think it specifies the authentication 
process clearly enough for people to implement from the spec.  I suspect
we can resolve this by email in the next couple of days.

For shared secret and Kerberos, I *think* that the intent is the key is 
used only for an HMAC or similar algorithm such as a CBC-MAC.  That 
should be stated explicitly.  It should also state that the expected 
length of the authentication data is a preconfigured parameter, and 
MUST match the data length in the message.  (There's an attack if the 
data length is taken from the message; details are left as an exercise 
for the reader.)  

Be more explicit about what HMAC-MD5-96 means -- I don't believe that 
that string is defined in 2104.  Why truncate to 96 bits?  It's secure 
-- but it's done in IPsec because of boundary alignment considerations.

Anyway -- the text should say something like this:


	If AUTH_ENT_ID is of types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR,
	FQDN, ASCII_DN, UNICODE_DN or URI, the receiver should use
	the identity to consult a table keyed by that identity.  The
	table should identify the cryptographic authentication algorithm
	to be used and the expected length of the authentication data.
	At a minimum, all implementations must support HMAC [RFC2104]
	using the MD5 [RFC1321] hash algorithm with an output length of
	16 bytes.  New algorithms may be added by the IETF standards
	process.

	If AUTH_ENT_ID is of type KRB_PRINCIPAL, a similar algorithm
	table is consulted.  In this case, however, the key is taken
	from the Kerberos ticket.  At a minimum, all implementations
	must support the same HMAC hash described above.

	Authentication is done as follows.  The entire message is
	constructed, excluding the length, type, and subtype fields
	of the AUTH DATA field.  Note that the message MUST include
	either a START_TIME or a SESSION_ID (See Section 9), to prevent
	replay attacks.  The output of the authentication algorithm,
	plus appropriate header information, is appended to the message.

	Verification is done by a similar process; however, the receiver
	MUST verify that the indicated length of the authentication data
	is consistent with the configured table entry.


Much more needs to be said about generating signatures to be verified 
via an X.509 certificate.  I'm not 100% certain which RFCs need to be 
cited -- ekr or jis, can you fill in some details? -- but they probably 
include PKCS 1 and 7 (published as RFCs -- btw, there is an obsolete 
RFC cited for PKIX).  I frankly don't recall if the preferred hash 
algorithm is in the X.509 certificate, though the public key algorithm 
used is implicit in the key type in the cert.  Similar concerns apply to
PGP_CERT, but I don't even know what to cite for it.

--- here comes a response to the above from Eric

I agree that this is unsatisfactory, on several fronts:
(1) It only appears to be possible to pass a single certificate.
What about certificate chains?
(2) It doesn't actually SAY that a signature is what is present 
in the authentication data field, though I suppose we're supposed
to intuit that.
(3) It doesn't specify the digest algorithm.

In answer to your questions:
(1) It's necessary to reference PKCS-1 [RFC 2437] since that describes
how to perform RSA signatures. (I'm assuming that they want to use
PKCS-1 rather than PSS or some other newfangled RSA padding
If DSS is to permitted they should also reference FIPS 186-2.

(2) It's not necessary to reference PKCS-7 unless you're using
it as a certificate chain container. (See my comment about
chains above).

(3) In general, X.509v3 certificates do not carry preferred digest 
indicators. Either the digest name should be manually configured
or contained in the message. While it's technically possible
to discover what digest was used from the signature (it's in the
DigestInfo), generally APIs and hardware assume that you already
know. 


Further more:

(1) Section 4.1 talks about "shared private keys". This is confusing
since "private key" is generally used to refer to the private half of
an asymmetric key pair. I think this would be clearer if it talked
about "shared symmetric keys".

(2) The Kerberos authentication mechanism doesn't appear to contain
authentication data but instead merely the principal name. The text
here suggests that the authentication is interactive:

      An authorizing entity is configured to construct the AUTH_SESSION 
   policy element that designates use of the Kerberos authentication 
   method (KRB_PRINCIPAL).  Upon reception of the RSVP request, the 
   router/PDP contacts the local KDC to request a ticket for the 
   authorizing entity (principal@realm). The router/PDP uses the ticket 
   to access the authorizing entity and obtain authentication data for 
   the message. 

That seems unusual. Wouldn't you want the authorizing entity to send a
ticket, thus avoiding a round trip? Is the problem that the
authorizing entity can't guess the principal name of the router/PDP?
If so, how does he know it's right when the router/PDP asks for
authorization? What are the contents of the "authentication data" that
the router/PDP obtains? This all seems quite hairy and underspecified.




From owner-rap@ops.ietf.org  Mon Jul 29 04:27:40 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20904
	for <rap-archive@lists.ietf.org>; Mon, 29 Jul 2002 04:27:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17Z5qG-00088t-00
	for rap-data@psg.com; Mon, 29 Jul 2002 01:25:24 -0700
Received: from rumba.cefriel.it ([131.175.53.6])
	by psg.com with esmtp (Exim 3.36 #1)
	id 17Z5qC-00088H-00
	for rap@ops.ietf.org; Mon, 29 Jul 2002 01:25:20 -0700
content-class: urn:content-classes:message
Subject: COPS-PR performance measurements
Date: Mon, 29 Jul 2002 10:22:26 +0200
Message-ID: <28C92BFE6EB5C943B15743D0E11E6036042310@rumba.cefriel.it>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C236D9.1282C954"
X-MS-Has-Attach: yes
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: COPS-PR performance measurements
Thread-Index: AcI21+yt/kkc1zUFQnKl7cO0TImMzQ==
From: "Marco De Bernardi" <debernar@cefriel.it>
To: <rap@ops.ietf.org>
X-Spam-Status: No, hits=0.2 required=5.0
	tests=PORN_14
	version=2.31
Sender: owner-rap@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C236D9.1282C954
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi to everybody,

My name is Marco De Bernardi and I'm a student of Politecnico di Milano, =
I'm currently working on my master thesis at Cefriel ( a consortium =
between public and private - www.cefriel.it )

I regret in advanced for the length of the mail, I was not able to =
shorten it further.

My thesis is focused on performance measurement of policy provisioning =
protocol (COPS-PR) in a policy based environment. As case study I chosen =
diff-serv configuration provisioning.

This mail would be a public contribution to implementation problem we =
encountered and at the same time we want to know the mailing list =
opinion about the hypothesis of our implementation.=20

I have implemented some PIB, PDP and PEP software prototypes, using C++ =
language on Linux OS.


In the attached file there is the dettailed description of my work. =20

------_=_NextPart_001_01C236D9.1282C954
Content-Type: application/octet-stream;
	name="description.txt"
Content-Description: description.txt
Content-Disposition: attachment;
	filename="description.txt"
Content-Transfer-Encoding: base64

SW1wbGVtZW50YXRpb24NCg0KVGhlIHR3byBQSUJzDQpUaGUgZmlyc3QgcHJvYmxlbSBmYWNlZCBp
biB0aGUgaW1wbGVtZW50YXRpb24gcHJvY2VzcyB3YXMgdGhlIGRldmVsb3BtZW50IG9mIHNvbWUg
ZGF0YSBzdHJ1Y3R1cmUgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBwb2xpY3kgaW5mb3JtYXRp
b24uDQpBcyBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gSSBkZWNpZGVkIHRvIGFkb3B0IFBJQnMg
c29sdXRpb24uIEluIGZhY3QsIHRoZXNlIGFsbG93IHRvIHRoZSBQRFAgdG8gY29tbXVuaWNhdGUg
d2l0aCB0aGUgUEVQIGluIGEgc3RhbmRhcmQgd2F5LCB3aXRoIGEgY29tbW9uIHN5bnRheCBhbmQg
c2VtYW50aWNzIG9mIHBvbGljeSBpbmZvcm1hdGlvbi4gRHVlIHRvIHRoZSBhZG9wdGVkIHNvbHV0
aW9uIGEgc2Vjb25kIHByb2JsZW0gcmlzZTogdGhlIGltcGxlbWVudGF0aW9uIG9mIGEgUFJDIGlu
IGEgb2JqZWN0IG9yaWVudGVkIGxhbmd1YWdlLiBUaGUgUFJDcyBvZiB0aGUgaW1wbGVtZW50ZWQg
UElCcyBhcmUgcmVhbGl6ZWQgd2l0aCBhIGNvbW1vbiB0ZWNobmlxdWUuIEFjY29yZGluZyB0byBT
UFBJIGRlZmluaXRpb24gYSBQUkMgb2YgYSBQSUIgaXMgYSCTU0VRVUVOQ0UgT0YgVGFibGVFbnRy
eZQgYW5kIGEgk1RhYmxlRW50cnmUIGlzIGEgk1NFUVVFTkNFIE9GIEF0dHJpYnV0ZZQuIFRvIHJl
bmRlciB0aGlzIGRlZmluaXRpb24sIEkgaGF2ZSBpbXBsZW1lbnRlZCBhIGNsYXNzIJNUYWJsZZQg
dGhhdCBpcyBhIGNvbnRhaW5lciBvZiBvYmplY3RzIG9mIGNsYXNzIJNFbnRyeZQuIFRoaXMgb25l
IGhhcyBhIHNldCBvZiBhdHRyaWJ1dGUgd2hpY2ggaXMgaWRlbnRpY2FsIHRvIHRoYXQgb2YgdGhl
IG1vZGVsZWQgUFJDLiANClRoZSBpbXBsZW1lbnRlZCBQSUJzIGFyZSB0d28uIFRoZSBGcmFtZXdv
cmsgUElCICh0aGUgUFJDcyByZWFsaXplZCBhcmU6IFBSQyBTdXBwb3J0IFRhYmxlLCBJbnRlcmZh
Y2UgQ2FwYWJpbGl0eSBTZXQgVGFibGUsIFJvbGUgQ29tYm8gVGFibGUsIElQIEZpbHRlciBUYWJs
ZSkgYW5kIHRoZSBEaWZmLVNlcnYgUElCIChQUkM6IERhdGEgUGF0aCBUYWJsZSwgQ2xhc3NpZmll
ciBUYWJsZSwgQ2xhc3NpZmllciBFbGVtZW50IFRhYmxlLCBNYXJrIEFjdGlvbiBUYWJsZSwgUXVl
dWUgVGFibGUsIFNjaGVkdWxlciBUYWJsZSwgUW9TIEludGVyZmFjZSBDbGFzc2lmaWNhdGlvbiBD
YXBhYmlsaXR5IFRhYmxlLCBRb1MgU2NoZWR1bGVyIENhcGFiaWxpdHkgVGFibGUsIFFvUyBJbnRl
cmZhY2UgUXVldWUgQ2FwYWJpbGl0eSBUYWJsZSkuDQoNClBEUCBhbmQgUEVQIA0KDQpUaGUgb3Ro
ZXIgcHJvdG90eXBlcyByZWFsaXplZCBhcmUgdGhvc2Ugb2YgUERQIGFuZCBQRVAuIER1cmluZyB0
aGUgd29yayBJIGltcGxlbWVudGVkIHR3byBwYWlycyBvZiBQRFAvUEVQLiANClRoZSBmaXJzdCBv
bmUgaXMgY29tcG9zZWQgb2YgYSBtdWx0aS10aHJlYWQgc2VydmVyICh0aGUgk3N0YXJ0IHVwIFBE
UJQpIHRoYXQgYWxsb3dzIHRvIHNpbXVsYXRlIHRoZSBzdGFydCB1cCBpbnRlcmFjdGlvbiB3aXRo
IGEgY2xpZW50ICh0aGUgk3N0YXJ0IHVwIFBFUJQpLiANClRoZSBQRVAgY29ubmVjdHMgdG8gdGhl
IFBEUCBhbmQgc2VuZHMsIGFzIENPUFMtUFIgcmVxdWVzdCBtZXNzYWdlcywgdGhlIERpZmYtc2Vy
diBjYXBhYmlsaXR5IGFuZCByb2xlIGNvbWJpbmF0aW9uIG9mIHRoZSBpbnRlcmZhY2UgdGhhdCBp
dCBjb250cm9scy4gVGhlIFBEUCBpbnN0YWxscyB0aGUgY2FwYWJpbGl0eSBpbiBpdHMgb3duIFBJ
QnMgYW5kLCB0aGVuLCBzZW5kcywgYXMgQ09QUy1QUiBkZWNpc2lvbiBtZXNzYWdlLCB0aGUgRGlm
Zi1zZXJ2IGNvbmZpZ3VyYXRpb24gdG8gdGhlIFBFUC4gVGhlIHJlYWxpemVkIFBEUCBpcyBzdGF0
ZSBmdWxsLiBUaHVzIHJpc2UgdGhlIHByb2JsZW0gb2YgdGhlIG1haW50ZW5hbmNlIG9mIHRoZSB1
cGRhdGVkIHN0YXRlIG9mIHRoZSBjYXBhYmlsaXRpZXMgYW5kIHJvbGUgY29tYmluYXRpb25zIG9m
IGFsbCBjb25uZWN0ZWQgUEVQcywgYW5kIG9mIHRoZSBjb3JyZWN0IGFzc29jaWF0aW9uIGJldHdl
ZW4gYSBzaW5nbGUgUEVQIGFuZCBpdHMgY2FwYWJpbGl0eSBhbmQgYmV0d2VlbiBQRVAgYW5kIGl0
cyByb2xlIGNvbWJpbmF0aW9uLiBJIHNvbHZlZCB0aGUgcHJvYmxlbSBieSB0aGUgaW1wbGVtZW50
YXRpb24gb2Ygc29tZSBhc3NvY2lhdGl2ZSBtYXBzIGluIHdoaWNoIHRoZSBQRFAgaW5zZXJ0cyB0
aGUgUEVQIGlkZW50aWZpZXIgKFBFUElkIG9iamVjdCkgYW5kIHRoZSBjYXBhYmlsaXR5L3JvbGUg
Y29tYmluYXRpb24gcmVjZWl2ZWQuDQpBbm90aGVyIHByb2JsZW0gZmFjZWQgZHVyaW5nIHRoZSBy
ZWFsaXphdGlvbiBwcm9jZXNzIG9mICB0aGUgUERQIHdhcyB0aGF0IG9mIHRoZSBjb25zdHJ1Y3Rp
b24gb2YgdGhlIGRlY2lzaW9uIG1lc3NhZ2Ugd2l0aCB0aGUgZGlmZi1zZXJ2IGNvbmZpZ3VyYXRp
b24gZm9yIHRoZSBQRVAuIFRvIHNvbHZlIHRoZSBwcm9ibGVtIEkgZGVjaWRlZCB0byBleHBsb2l0
IHRoZSBkaWZmLXNlcnYgZGF0YSBwYXRoIGNvbmNlcHQuIEkgZml4ZWQgdGhlIHNlcXVlbmNlIG9m
IHRoZSBjb25zdGl0dWVudCBlbGVtZW50IG9mIHRoZSBkYXRhIHBhdGgsIHdoaWxlIHRoZWlycyBu
dW1iZXIgYW5kIHRoZWlycyBpbnRlcmNvbm5lY3Rpb24gcGF0dGVybiBpcyB2YXJpYWJsZSAoIHRo
dXMgaXMgYWxzbyB2YXJpYWJsZSB0aGUgY29tcGxleGl0eSBvZiB0aGUgcG9saWN5L2NvbmZpZ3Vy
YXRpb24pLiANClRoZSBQRFAgb2J0YWlucyB0aGUgY29uZmlndXJhdGlvbiBicm93c2luZyBhbG9u
ZyB0aGUgZGF0YSBwYXRoLCByZXByZXNlbnRlZCBieSB0aGUgUFJDcyBvZiB0aGUgRGlmZi1zZXJ2
IFBJQiwgYW5kIGV4cGxvcmluZyBpdCBjb21wbGV0ZWx5LCB1c2luZyB0aGUgaW50ZXJjb25uZWN0
aW9uIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIGV2ZXJ5IFBSQyAobmV4dCBhdHRyaWJ1dGUpLiBX
aGVuIHJlY2VpdmluZyB0aGUgZGVjaXNpb24gbWVzc2FnZSB0aGUgUEVQIHBhcnNlcyBpdCBhbmQg
aW5zdGFsbCAoY29weSkgdGhlIGNvbmZpZ3VyYXRpb24gaW4gaXRzIG93biBEaWZmLXNlcnYgUElC
Lg0KDQpUaGUgc2Vjb25kIGNvdXBsZSBvZiBQRFAvUEVQIChuYW1lZCCTRGVjaXNpb24gUERQlCBh
bmQgk0RlY2lzaW9uIFBFUJQgKSB3YW50cyB0byBzaW11bGF0ZSB0aGUgc2NlbmFyaW8gaW4gd2hp
Y2ggdGhlIGNvbmZpZ3VyYXRpb24gb2YgTiCTRGVjaXNpb24gUEVQc5QgaXMgbWFkZSBieSB0aGUg
k0RlY2lzaW9uIFBEUJQgYWZ0ZXIgaXQgcmVjZWl2ZXMgdGhlIGNvbmZpZ3VyYXRpb24gcmVxdWVz
dCBvZiBhIHRoaXJkIG5ldHdvcmsgZWxlbWVudCwgb3Igd2hlbiBpdCBjaGVja3MgdGhlIGFjdGl2
YXRpb24gb2YgYW4gaGlnaGVyIGxldmVsIHBvbGljeS4NClRoZSBwcm90b3R5cGUgb2Ygk0RlY2lz
aW9uIFBEUJQgaXMgYSBtdWx0aS10aHJlYWQgc2VydmVyIHRoYXQgdGFrZXMgYW4gb3BlcmF0aXZl
IGV2ZW50IGFuZCwgYXMgcmVzcG9uc2UgdG8gdGhpcywgY29uZmlndXJlcyBOIGNvbm5lY3RlZCCT
RGVjaXNpb24gUEVQc5QuIFRoZSBkZWNpc2lvbnMgbWVzc2FnZXMgd2l0aCB0aGUgY29uZmlndXJh
dGlvbiBhcmUgYnVpbGQgYXMgcHJldmlvdXMuIFRoZSBQRVAgcGFyc2VzIHRoZSByZWNlaXZlZCBt
ZXNzYWdlIGFuZCBpbnN0YWxsIHRoZSBjb25maWd1cmF0aW9uIGluIGl0cyBEaWZmU2Vydi1QSUIu
IFRoZSBvcGVyYXRpdmUgZXZlbnQgc2VsZWN0ZWQgaXMgdGhlIHJlZ2lzdHJhdGlvbiAodmlhIENP
UFMgT1BFTiBtZXNzYWdlKSBvZiB0aGUgTnRoIJNEZWNpc2lvbiBQRVCULiBUaGlzIGV2ZW50IGlz
IHNpbXBsZSB0byBpbXBsZW1lbnQgYW5kLCBmb3IgbWVhc3VyZW1lbnQgcHVycG9zZXMgb2YgY29u
ZmlndXJhdGlvbiBwcm92aXNpb25pbmcsIGlzIGVxdWl2YWxlbnQgdG8gYW4gZXh0ZXJuYWwgcmVx
dWVzdCBvciB0byB0aGUgYWN0aXZhdGlvbiBvZiBhIGhpZ2hlciBsZXZlbCBwb2xpY3kuDQoNClRv
IGltcGxlbWVudCB0aGUgcHJvdG90eXBlcyBvZiB0aGUgUERQcyBhbmQgb2YgdGhlIFBFUHMsIEkg
aGF2ZSB1c2VkIGEgc2V0IG9mIGZyZWUgQVBJLCBkaXN0cmlidXRlZCBieSBWb3ZpZGEgb3JnYW5p
emF0aW9uICh3d3cudm92aWRhLm9yZyA8aHR0cDovL3d3dy52b3ZpZGEub3JnPikuIFRoZSBBUEkg
cmVhbGl6ZSB0aGUgQ09QUy1QUiBzdGFjay4NCg0KVGhlIGxhc3QgcGhhc2Ugb2YgdGhlIGpvYiBp
cyB0aGF0IG9mIG1lYXN1cmVtZW50cyAodGhpcyBzdGFnZSBvZiB0aGUgd29yayBpcyBzdGlsbCB0
byBmaW5pc2hpbmcpLiBUbyBtYWtlIHRoZSBtZWFzdXJlLCBJIGRlY2lkZSB0byBwdXQgdGhlIFBE
UCBwcm9jZXNzIG9uIGEgZGVkaWNhdGVkIG1hY2hpbmUgYW5kIHRoZSBOIFBFUCBwcm9jZXNzZXMg
b24gdHdvIHNlcGFyYXRlZCBtYWNoaW5lcywgcnVubmluZyBpbiBwYXJhbGxlbCAobWF4IDUwMCBw
cm9jZXNzKS4gVGhlIGNvbXB1dGVyIGFyZSBjb25uZWN0ZWQgYnkgYSAxMDAgTWJpdCBzd2l0aGNo
ZWQgTEFOLiBJIGhhdmUgZGVzaWduZWQgZm91ciB0eXBlIG9mIG1lYXN1cmU6DQoxKQlUaGUgbWVh
c3VyZW1lbnQgKHNlcnZlciBzaWRlKSBvZiB0aGUgYWxsIHN0YXJ0IHVwIGludGVyYWN0aW9uLiBU
aGUgbWVhc3VyZSBpcyBkb25lIHdpdGggb25lIJNzdGFydCB1cCBQRFCUIGFuZCBvbmUgk3N0YXJ0
IHVwIFBFUJQsIHNpbmNlIGlzIGltcHJvYmFibGUgdGhhdCBtb3JlIHRoYW4gb25lIFBFUCBzdGFy
dHMgdXAgc2ltdWx0YW5lb3VzbHksIG9yIHRoYXQgYSBQRVAgc3RhcnRzIGJlZm9yZSB0aGF0IHRo
ZSBQRFAgZW5kcyB0byBzZXJ2ZSB0aGUgcHJldmlvdXMgb25lLiBJIHRoaW5rIHRvIG1lYXN1cmUg
dGhlIHRpbWUgZWxhcHNlZCBiZXR3ZWVuIJNjb25uZWN0aW9uIGFjY2VwdJQgbWFkZSBieSB0aGUg
UERQIGFuZCB0aGUgcmV0dXJuIG9mIHRoZSCTc2VuZJQgZnVuY3Rpb24gb2YgdGhlIGRlY2lzaW9u
IG1lc3NhZ2UuDQoyKQlUaGUgbWVhc3VyZW1lbnQgb2YgdGhlIHRpbWUgbmVjZXNzYXJ5IHRvIHRo
ZSCTRGVjaXNpb24gUERQlCB0byBwcm92aXNpb24gTiCTRGVjaXNpb24gUEVQlCB3aXRoIGEgRGlm
Zi1zZXJ2IGNvbmZpZ3VyYXRpb24uIEkgdGhpbmsgdG8gbWVhc3VyZSB0aGUgdGltZSBlbGFwc2Vk
IGJldHdlZW4gdGhlIHJlY29yZGluZyBvZiB0aGUgk29wZXJhdGl2ZSBldmVudJQgYW5kIHRoZSBy
ZXR1cm4gb2YgdGhlIJNzZW5klCBmdW5jdGlvbiBvZiB0aGUgbGFzdCBkZWNpc2lvbiBtZXNzYWdl
IHNlbnQsIGJ5IHRoZSBQRFAsIHRvIHRoZSBsYXN0IHNlcnZlZCBQRVAuDQozKQlUaGUgbWVhc3Vy
ZW1lbnQgb2YgdGhlIGVudGlyZSBwcm92aXNpb25pbmcgdGltZSwgZm9ybSB0aGUgcmVjb3JkaW5n
IG9mIHRoZSCTb3BlcmF0aXZlIGV2ZW50lCAoc2VydmVyIHNpZGUpIHRvIHRoZSBhY3R1YWwgaW5z
dGFsbGF0aW9uIG9mIHRoZSBjb25maWd1cmF0aW9uIGJ5IHRoZSBsYXN0IJNEZWNpc2lvbiBQRVCU
IChjbGllbnQgc2lkZSkuIFRoaXMgbWVhc3VyZSB3b3VsZCByZXF1ZXN0IHRoZSBhc3Nlc3NtZW50
IG9mIHR3byB0ZW1wb3JhbCBldmVudCBvbiB0d28gZGlzdGluY3QgbWFjaGluZSAodGhhdCB3aXRo
IHRoZSCTRGVjaXNpb24gUERQlCBhbmQgdGhhdCB3aXRoIHRoZSBOIJNEZWNpc2lvbiBQRVBzlCku
IFRoaXMgaXMgaW1wb3NzaWJsZSB3aXRoIHRoZSBwcm9maWxpbmcgbWV0aG9kIHVzZWQgKHNlZSBi
ZWxvdykuIEluc3RlYWQsIEkgdGhpbmsgdG8gbWVhc3VyZSBhbiBhcHByb3hpbWF0aW9uIG9mIHRo
ZSB0b3RhbCBwcm92aXNpb25pbmcgdGltZSBvbmx5IFBFUCBzaWRlLiBJIG1lYXN1cmUgdGhlIHRp
bWUgZWxhcHNlZCBiZXR3ZWVuIHRoZSBzZW5kaW5nIG9mIHRoZSByZWdpc3RyYXRpb24gbWVzc2Fn
ZSBvZiB0aGUgbGFzdCBQRVAgYW5kIHRoZSBpbnN0YWxsYXRpb24gb2YgdGhlIERpZmYtc2VydiBj
b25maWd1cmF0aW9uIG1hZGUgYnkgdGhlIGxhc3QgUEVQIHNlcnZlZC4gSSB0aGluayB0aGF0IHRo
aXMgYXBwcm94aW1hdGlvbiBpcyB2ZXJ5IGxpdHRsZSBiZWNhdXNlIHRoZSBoaWdoIGJpdCByYXRl
IG9mIHRoZSBMQU4gYW5kIHJlbGF0aXZlIHNtYWxsIHByb2Nlc3NpbmcgdGltZSBvZiB0aGUgbGFz
dCBPUEVOIG1lc3NhZ2UgcmVzcGVjdCB0byB0aGUgdG90YWwgcHJvdmlzaW9uaW5nIHRpbWUuDQo0
KQlUaGUgbWVhc3VyZW1lbnQgb2YgdGhlIHVwZGF0aW5nIHRpbWUgb2YgdGhlIERpZmYtc2VydiBQ
SUIuIEkgdGhpbmsgdG8gbWVhc3VyZSB0aGUgdGltZSBlbGFwc2VkIGJldHdlZW4gdGhlIHJldHVy
biBvZiB0aGUgk3JlY2VpdmWUIGZ1bmN0aW9uIG9mIHRoZSBkZWNpc2lvbiBtZXNzYWdlIGFuZCB0
aGUgZW5kIG9mIHRoZSBQSUIgdXAgZGF0ZS4NCg0KQXMgcHJvZmlsaW5nIG1ldGhvZCBJkm0gdXNp
bmcgdGhlIJN0aW1lIHN0YW1wIGNvdW50ZXKUIG9mIHRoZSBQZW50aXVtIHByb2Nlc3Nvci4gVGhl
IGNvdW50ZXIgaXMgaW5jcmVtZW50ZWQgYnkgYW4gdW5pdHkgZXZlcnkgY2xvY2sgY3ljbGUuIFRo
ZSBjb3VudGVyIGNhbiBiZSB1c2VkIHZlcnkgc2ltcGx5IHRvIHJlY29yZCB0aGUgZXhlY3V0aW9u
IHRpbWUgb2YgYW4gaW5zdHJ1Y3Rpb24gc2V0LiBUaGUgZXhlY3V0aW9uIHRpbWUgaXMgdGhlIGRp
ZmZlcmVuY2UgYmV0d2VlbiB0aGUgdmFsdWUgb2YgdGhlIGNvdW50ZXIganVzdCBhZnRlciBhbmQg
anVzdCBiZWZvcmUgdGhlIGluc3RydWN0aW9uIGJsb2NrLCBkaXZpZGVkIGZvciB0aGUgcHJvY2Vz
c29yIGZyZXF1ZW5jeS4gVGhpcyBtZXRob2QgaGFzIGJlZW4gY2hvc2VuIGZvciBpdHMgaGlnaCBw
cmVjaXNpb24gKGEgc2luZ2xlIGNsb2NrIGN5Y2xlKSBhbmQgZm9yIGl0cyBsb3cgb3ZlciBoZWFk
LiBUaGUgbWV0aG9kIGlzIGFwcGxpY2FibGUgdG8gdGhlIHByb3Bvc2VkIG1lYXN1cmUgd2l0aCBz
b21lIGZldyBvdGhlciBhdHRlbnRpb25zIGR1ZSB0byB0aGUgdGhyZWFkZWQgZXhlY3V0aW9uIG9m
IFBEUHMuIA0KQWxsIG1lYXN1cmVzIHdpbGwgYWxzbyBiZSByZXBlYXRlZCB3aXRoIGZvdXIgZGlm
ZmVyZW50IERpZmYtU2VydiBjb25maWd1cmF0aW9uLiBUaGlzIHRvIGV2YWx1YXRlIHRoZSBpbXBh
Y3Qgb2YgdGhlIHBvbGljeSBjb21wbGV4aXR5IG9uIHRoZSB0aW1lcyByZWNvcmRlZC4NCg0KUGxl
YXNlLCBhbnkgb25lIGlzIGludGVyZXN0ZWQgY2FuIG1ha2UgbWUgcXVlc3Rpb25zIGFuZCBzZW5k
IG1lIGhpcy9oZXIgY29tbWVudHMvc3VnZ2VzdGlvbnMuDQo=

------_=_NextPart_001_01C236D9.1282C954--



From owner-rap@ops.ietf.org  Mon Jul 29 04:30:25 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20939
	for <rap-archive@lists.ietf.org>; Mon, 29 Jul 2002 04:30:24 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17Z5vw-0008aB-00
	for rap-data@psg.com; Mon, 29 Jul 2002 01:31:16 -0700
Received: from rumba.cefriel.it ([131.175.53.6])
	by psg.com with esmtp (Exim 3.36 #1)
	id 17Z5vs-0008Zw-00
	for rap@ops.ietf.org; Mon, 29 Jul 2002 01:31:12 -0700
content-class: urn:content-classes:message
Subject: COPS-PR performance measurements
Date: Mon, 29 Jul 2002 10:33:05 +0200
Message-ID: <28C92BFE6EB5C943B15743D0E11E6036042311@rumba.cefriel.it>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C236DA.8F27FB14"
X-MS-Has-Attach: yes
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: COPS-PR performance measurements
Thread-Index: AcI22mL53S3jqlALT1+hXGDyztVqJQ==
From: "Marco De Bernardi" <debernar@cefriel.it>
To: <rap@ops.ietf.org>
X-Spam-Status: No, hits=0.2 required=5.0
	tests=PORN_14
	version=2.31
Sender: owner-rap@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C236DA.8F27FB14
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi to everybody,

My name is Marco De Bernardi and I'm a student of Politecnico di Milano, =
I'm currently working on my master thesis at Cefriel ( a consortium =
between public and private - www.cefriel.it )
I regret in advanced for the length of the mail, I was not able to =
shorten it further.
My thesis is focused on performance measurement of policy provisioning =
protocol (COPS-PR) in a policy based environment. As case study I chosen =
diff-serv configuration provisioning.
This mail would be a public contribution to implementation problem we =
encountered and at the same time we want to know the mailing list =
opinion about the hypothesis of our implementation.=20
I have implemented some PIB, PDP and PEP software prototypes, using C++ =
language on Linux OS.

In the attached file there is the description of my work.


------_=_NextPart_001_01C236DA.8F27FB14
Content-Type: application/octet-stream;
	name="description.txt"
Content-Description: description.txt
Content-Disposition: attachment;
	filename="description.txt"
Content-Transfer-Encoding: base64

SW1wbGVtZW50YXRpb24NCg0KVGhlIHR3byBQSUJzDQpUaGUgZmlyc3QgcHJvYmxlbSBmYWNlZCBp
biB0aGUgaW1wbGVtZW50YXRpb24gcHJvY2VzcyB3YXMgdGhlIGRldmVsb3BtZW50IG9mIHNvbWUg
ZGF0YSBzdHJ1Y3R1cmUgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBwb2xpY3kgaW5mb3JtYXRp
b24uDQpBcyBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gSSBkZWNpZGVkIHRvIGFkb3B0IFBJQnMg
c29sdXRpb24uIEluIGZhY3QsIHRoZXNlIGFsbG93IHRvIHRoZSBQRFAgdG8gY29tbXVuaWNhdGUg
d2l0aCB0aGUgUEVQIGluIGEgc3RhbmRhcmQgd2F5LCB3aXRoIGEgY29tbW9uIHN5bnRheCBhbmQg
c2VtYW50aWNzIG9mIHBvbGljeSBpbmZvcm1hdGlvbi4gRHVlIHRvIHRoZSBhZG9wdGVkIHNvbHV0
aW9uIGEgc2Vjb25kIHByb2JsZW0gcmlzZTogdGhlIGltcGxlbWVudGF0aW9uIG9mIGEgUFJDIGlu
IGEgb2JqZWN0IG9yaWVudGVkIGxhbmd1YWdlLiBUaGUgUFJDcyBvZiB0aGUgaW1wbGVtZW50ZWQg
UElCcyBhcmUgcmVhbGl6ZWQgd2l0aCBhIGNvbW1vbiB0ZWNobmlxdWUuIEFjY29yZGluZyB0byBT
UFBJIGRlZmluaXRpb24gYSBQUkMgb2YgYSBQSUIgaXMgYSCTU0VRVUVOQ0UgT0YgVGFibGVFbnRy
eZQgYW5kIGEgk1RhYmxlRW50cnmUIGlzIGEgk1NFUVVFTkNFIE9GIEF0dHJpYnV0ZZQuIFRvIHJl
bmRlciB0aGlzIGRlZmluaXRpb24sIEkgaGF2ZSBpbXBsZW1lbnRlZCBhIGNsYXNzIJNUYWJsZZQg
dGhhdCBpcyBhIGNvbnRhaW5lciBvZiBvYmplY3RzIG9mIGNsYXNzIJNFbnRyeZQuIFRoaXMgb25l
IGhhcyBhIHNldCBvZiBhdHRyaWJ1dGUgd2hpY2ggaXMgaWRlbnRpY2FsIHRvIHRoYXQgb2YgdGhl
IG1vZGVsZWQgUFJDLiANClRoZSBpbXBsZW1lbnRlZCBQSUJzIGFyZSB0d28uIFRoZSBGcmFtZXdv
cmsgUElCICh0aGUgUFJDcyByZWFsaXplZCBhcmU6IFBSQyBTdXBwb3J0IFRhYmxlLCBJbnRlcmZh
Y2UgQ2FwYWJpbGl0eSBTZXQgVGFibGUsIFJvbGUgQ29tYm8gVGFibGUsIElQIEZpbHRlciBUYWJs
ZSkgYW5kIHRoZSBEaWZmLVNlcnYgUElCIChQUkM6IERhdGEgUGF0aCBUYWJsZSwgQ2xhc3NpZmll
ciBUYWJsZSwgQ2xhc3NpZmllciBFbGVtZW50IFRhYmxlLCBNYXJrIEFjdGlvbiBUYWJsZSwgUXVl
dWUgVGFibGUsIFNjaGVkdWxlciBUYWJsZSwgUW9TIEludGVyZmFjZSBDbGFzc2lmaWNhdGlvbiBD
YXBhYmlsaXR5IFRhYmxlLCBRb1MgU2NoZWR1bGVyIENhcGFiaWxpdHkgVGFibGUsIFFvUyBJbnRl
cmZhY2UgUXVldWUgQ2FwYWJpbGl0eSBUYWJsZSkuDQoNClBEUCBhbmQgUEVQIA0KDQpUaGUgb3Ro
ZXIgcHJvdG90eXBlcyByZWFsaXplZCBhcmUgdGhvc2Ugb2YgUERQIGFuZCBQRVAuIER1cmluZyB0
aGUgd29yayBJIGltcGxlbWVudGVkIHR3byBwYWlycyBvZiBQRFAvUEVQLiANClRoZSBmaXJzdCBv
bmUgaXMgY29tcG9zZWQgb2YgYSBtdWx0aS10aHJlYWQgc2VydmVyICh0aGUgk3N0YXJ0IHVwIFBE
UJQpIHRoYXQgYWxsb3dzIHRvIHNpbXVsYXRlIHRoZSBzdGFydCB1cCBpbnRlcmFjdGlvbiB3aXRo
IGEgY2xpZW50ICh0aGUgk3N0YXJ0IHVwIFBFUJQpLiANClRoZSBQRVAgY29ubmVjdHMgdG8gdGhl
IFBEUCBhbmQgc2VuZHMsIGFzIENPUFMtUFIgcmVxdWVzdCBtZXNzYWdlcywgdGhlIERpZmYtc2Vy
diBjYXBhYmlsaXR5IGFuZCByb2xlIGNvbWJpbmF0aW9uIG9mIHRoZSBpbnRlcmZhY2UgdGhhdCBp
dCBjb250cm9scy4gVGhlIFBEUCBpbnN0YWxscyB0aGUgY2FwYWJpbGl0eSBpbiBpdHMgb3duIFBJ
QnMgYW5kLCB0aGVuLCBzZW5kcywgYXMgQ09QUy1QUiBkZWNpc2lvbiBtZXNzYWdlLCB0aGUgRGlm
Zi1zZXJ2IGNvbmZpZ3VyYXRpb24gdG8gdGhlIFBFUC4gVGhlIHJlYWxpemVkIFBEUCBpcyBzdGF0
ZSBmdWxsLiBUaHVzIHJpc2UgdGhlIHByb2JsZW0gb2YgdGhlIG1haW50ZW5hbmNlIG9mIHRoZSB1
cGRhdGVkIHN0YXRlIG9mIHRoZSBjYXBhYmlsaXRpZXMgYW5kIHJvbGUgY29tYmluYXRpb25zIG9m
IGFsbCBjb25uZWN0ZWQgUEVQcywgYW5kIG9mIHRoZSBjb3JyZWN0IGFzc29jaWF0aW9uIGJldHdl
ZW4gYSBzaW5nbGUgUEVQIGFuZCBpdHMgY2FwYWJpbGl0eSBhbmQgYmV0d2VlbiBQRVAgYW5kIGl0
cyByb2xlIGNvbWJpbmF0aW9uLiBJIHNvbHZlZCB0aGUgcHJvYmxlbSBieSB0aGUgaW1wbGVtZW50
YXRpb24gb2Ygc29tZSBhc3NvY2lhdGl2ZSBtYXBzIGluIHdoaWNoIHRoZSBQRFAgaW5zZXJ0cyB0
aGUgUEVQIGlkZW50aWZpZXIgKFBFUElkIG9iamVjdCkgYW5kIHRoZSBjYXBhYmlsaXR5L3JvbGUg
Y29tYmluYXRpb24gcmVjZWl2ZWQuDQpBbm90aGVyIHByb2JsZW0gZmFjZWQgZHVyaW5nIHRoZSBy
ZWFsaXphdGlvbiBwcm9jZXNzIG9mICB0aGUgUERQIHdhcyB0aGF0IG9mIHRoZSBjb25zdHJ1Y3Rp
b24gb2YgdGhlIGRlY2lzaW9uIG1lc3NhZ2Ugd2l0aCB0aGUgZGlmZi1zZXJ2IGNvbmZpZ3VyYXRp
b24gZm9yIHRoZSBQRVAuIFRvIHNvbHZlIHRoZSBwcm9ibGVtIEkgZGVjaWRlZCB0byBleHBsb2l0
IHRoZSBkaWZmLXNlcnYgZGF0YSBwYXRoIGNvbmNlcHQuIEkgZml4ZWQgdGhlIHNlcXVlbmNlIG9m
IHRoZSBjb25zdGl0dWVudCBlbGVtZW50IG9mIHRoZSBkYXRhIHBhdGgsIHdoaWxlIHRoZWlycyBu
dW1iZXIgYW5kIHRoZWlycyBpbnRlcmNvbm5lY3Rpb24gcGF0dGVybiBpcyB2YXJpYWJsZSAoIHRo
dXMgaXMgYWxzbyB2YXJpYWJsZSB0aGUgY29tcGxleGl0eSBvZiB0aGUgcG9saWN5L2NvbmZpZ3Vy
YXRpb24pLiANClRoZSBQRFAgb2J0YWlucyB0aGUgY29uZmlndXJhdGlvbiBicm93c2luZyBhbG9u
ZyB0aGUgZGF0YSBwYXRoLCByZXByZXNlbnRlZCBieSB0aGUgUFJDcyBvZiB0aGUgRGlmZi1zZXJ2
IFBJQiwgYW5kIGV4cGxvcmluZyBpdCBjb21wbGV0ZWx5LCB1c2luZyB0aGUgaW50ZXJjb25uZWN0
aW9uIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIGV2ZXJ5IFBSQyAobmV4dCBhdHRyaWJ1dGUpLiBX
aGVuIHJlY2VpdmluZyB0aGUgZGVjaXNpb24gbWVzc2FnZSB0aGUgUEVQIHBhcnNlcyBpdCBhbmQg
aW5zdGFsbCAoY29weSkgdGhlIGNvbmZpZ3VyYXRpb24gaW4gaXRzIG93biBEaWZmLXNlcnYgUElC
Lg0KDQpUaGUgc2Vjb25kIGNvdXBsZSBvZiBQRFAvUEVQIChuYW1lZCCTRGVjaXNpb24gUERQlCBh
bmQgk0RlY2lzaW9uIFBFUJQgKSB3YW50cyB0byBzaW11bGF0ZSB0aGUgc2NlbmFyaW8gaW4gd2hp
Y2ggdGhlIGNvbmZpZ3VyYXRpb24gb2YgTiCTRGVjaXNpb24gUEVQc5QgaXMgbWFkZSBieSB0aGUg
k0RlY2lzaW9uIFBEUJQgYWZ0ZXIgaXQgcmVjZWl2ZXMgdGhlIGNvbmZpZ3VyYXRpb24gcmVxdWVz
dCBvZiBhIHRoaXJkIG5ldHdvcmsgZWxlbWVudCwgb3Igd2hlbiBpdCBjaGVja3MgdGhlIGFjdGl2
YXRpb24gb2YgYW4gaGlnaGVyIGxldmVsIHBvbGljeS4NClRoZSBwcm90b3R5cGUgb2Ygk0RlY2lz
aW9uIFBEUJQgaXMgYSBtdWx0aS10aHJlYWQgc2VydmVyIHRoYXQgdGFrZXMgYW4gb3BlcmF0aXZl
IGV2ZW50IGFuZCwgYXMgcmVzcG9uc2UgdG8gdGhpcywgY29uZmlndXJlcyBOIGNvbm5lY3RlZCCT
RGVjaXNpb24gUEVQc5QuIFRoZSBkZWNpc2lvbnMgbWVzc2FnZXMgd2l0aCB0aGUgY29uZmlndXJh
dGlvbiBhcmUgYnVpbGQgYXMgcHJldmlvdXMuIFRoZSBQRVAgcGFyc2VzIHRoZSByZWNlaXZlZCBt
ZXNzYWdlIGFuZCBpbnN0YWxsIHRoZSBjb25maWd1cmF0aW9uIGluIGl0cyBEaWZmU2Vydi1QSUIu
IFRoZSBvcGVyYXRpdmUgZXZlbnQgc2VsZWN0ZWQgaXMgdGhlIHJlZ2lzdHJhdGlvbiAodmlhIENP
UFMgT1BFTiBtZXNzYWdlKSBvZiB0aGUgTnRoIJNEZWNpc2lvbiBQRVCULiBUaGlzIGV2ZW50IGlz
IHNpbXBsZSB0byBpbXBsZW1lbnQgYW5kLCBmb3IgbWVhc3VyZW1lbnQgcHVycG9zZXMgb2YgY29u
ZmlndXJhdGlvbiBwcm92aXNpb25pbmcsIGlzIGVxdWl2YWxlbnQgdG8gYW4gZXh0ZXJuYWwgcmVx
dWVzdCBvciB0byB0aGUgYWN0aXZhdGlvbiBvZiBhIGhpZ2hlciBsZXZlbCBwb2xpY3kuDQoNClRv
IGltcGxlbWVudCB0aGUgcHJvdG90eXBlcyBvZiB0aGUgUERQcyBhbmQgb2YgdGhlIFBFUHMsIEkg
aGF2ZSB1c2VkIGEgc2V0IG9mIGZyZWUgQVBJLCBkaXN0cmlidXRlZCBieSBWb3ZpZGEgb3JnYW5p
emF0aW9uICh3d3cudm92aWRhLm9yZyA8aHR0cDovL3d3dy52b3ZpZGEub3JnPikuIFRoZSBBUEkg
cmVhbGl6ZSB0aGUgQ09QUy1QUiBzdGFjay4NCg0KVGhlIGxhc3QgcGhhc2Ugb2YgdGhlIGpvYiBp
cyB0aGF0IG9mIG1lYXN1cmVtZW50cyAodGhpcyBzdGFnZSBvZiB0aGUgd29yayBpcyBzdGlsbCB0
byBmaW5pc2hpbmcpLiBUbyBtYWtlIHRoZSBtZWFzdXJlLCBJIGRlY2lkZSB0byBwdXQgdGhlIFBE
UCBwcm9jZXNzIG9uIGEgZGVkaWNhdGVkIG1hY2hpbmUgYW5kIHRoZSBOIFBFUCBwcm9jZXNzZXMg
b24gdHdvIHNlcGFyYXRlZCBtYWNoaW5lcywgcnVubmluZyBpbiBwYXJhbGxlbCAobWF4IDUwMCBw
cm9jZXNzKS4gVGhlIGNvbXB1dGVyIGFyZSBjb25uZWN0ZWQgYnkgYSAxMDAgTWJpdCBzd2l0aGNo
ZWQgTEFOLiBJIGhhdmUgZGVzaWduZWQgZm91ciB0eXBlIG9mIG1lYXN1cmU6DQoxKQlUaGUgbWVh
c3VyZW1lbnQgKHNlcnZlciBzaWRlKSBvZiB0aGUgYWxsIHN0YXJ0IHVwIGludGVyYWN0aW9uLiBU
aGUgbWVhc3VyZSBpcyBkb25lIHdpdGggb25lIJNzdGFydCB1cCBQRFCUIGFuZCBvbmUgk3N0YXJ0
IHVwIFBFUJQsIHNpbmNlIGlzIGltcHJvYmFibGUgdGhhdCBtb3JlIHRoYW4gb25lIFBFUCBzdGFy
dHMgdXAgc2ltdWx0YW5lb3VzbHksIG9yIHRoYXQgYSBQRVAgc3RhcnRzIGJlZm9yZSB0aGF0IHRo
ZSBQRFAgZW5kcyB0byBzZXJ2ZSB0aGUgcHJldmlvdXMgb25lLiBJIHRoaW5rIHRvIG1lYXN1cmUg
dGhlIHRpbWUgZWxhcHNlZCBiZXR3ZWVuIJNjb25uZWN0aW9uIGFjY2VwdJQgbWFkZSBieSB0aGUg
UERQIGFuZCB0aGUgcmV0dXJuIG9mIHRoZSCTc2VuZJQgZnVuY3Rpb24gb2YgdGhlIGRlY2lzaW9u
IG1lc3NhZ2UuDQoyKQlUaGUgbWVhc3VyZW1lbnQgb2YgdGhlIHRpbWUgbmVjZXNzYXJ5IHRvIHRo
ZSCTRGVjaXNpb24gUERQlCB0byBwcm92aXNpb24gTiCTRGVjaXNpb24gUEVQlCB3aXRoIGEgRGlm
Zi1zZXJ2IGNvbmZpZ3VyYXRpb24uIEkgdGhpbmsgdG8gbWVhc3VyZSB0aGUgdGltZSBlbGFwc2Vk
IGJldHdlZW4gdGhlIHJlY29yZGluZyBvZiB0aGUgk29wZXJhdGl2ZSBldmVudJQgYW5kIHRoZSBy
ZXR1cm4gb2YgdGhlIJNzZW5klCBmdW5jdGlvbiBvZiB0aGUgbGFzdCBkZWNpc2lvbiBtZXNzYWdl
IHNlbnQsIGJ5IHRoZSBQRFAsIHRvIHRoZSBsYXN0IHNlcnZlZCBQRVAuDQozKQlUaGUgbWVhc3Vy
ZW1lbnQgb2YgdGhlIGVudGlyZSBwcm92aXNpb25pbmcgdGltZSwgZm9ybSB0aGUgcmVjb3JkaW5n
IG9mIHRoZSCTb3BlcmF0aXZlIGV2ZW50lCAoc2VydmVyIHNpZGUpIHRvIHRoZSBhY3R1YWwgaW5z
dGFsbGF0aW9uIG9mIHRoZSBjb25maWd1cmF0aW9uIGJ5IHRoZSBsYXN0IJNEZWNpc2lvbiBQRVCU
IChjbGllbnQgc2lkZSkuIFRoaXMgbWVhc3VyZSB3b3VsZCByZXF1ZXN0IHRoZSBhc3Nlc3NtZW50
IG9mIHR3byB0ZW1wb3JhbCBldmVudCBvbiB0d28gZGlzdGluY3QgbWFjaGluZSAodGhhdCB3aXRo
IHRoZSCTRGVjaXNpb24gUERQlCBhbmQgdGhhdCB3aXRoIHRoZSBOIJNEZWNpc2lvbiBQRVBzlCku
IFRoaXMgaXMgaW1wb3NzaWJsZSB3aXRoIHRoZSBwcm9maWxpbmcgbWV0aG9kIHVzZWQgKHNlZSBi
ZWxvdykuIEluc3RlYWQsIEkgdGhpbmsgdG8gbWVhc3VyZSBhbiBhcHByb3hpbWF0aW9uIG9mIHRo
ZSB0b3RhbCBwcm92aXNpb25pbmcgdGltZSBvbmx5IFBFUCBzaWRlLiBJIG1lYXN1cmUgdGhlIHRp
bWUgZWxhcHNlZCBiZXR3ZWVuIHRoZSBzZW5kaW5nIG9mIHRoZSByZWdpc3RyYXRpb24gbWVzc2Fn
ZSBvZiB0aGUgbGFzdCBQRVAgYW5kIHRoZSBpbnN0YWxsYXRpb24gb2YgdGhlIERpZmYtc2VydiBj
b25maWd1cmF0aW9uIG1hZGUgYnkgdGhlIGxhc3QgUEVQIHNlcnZlZC4gSSB0aGluayB0aGF0IHRo
aXMgYXBwcm94aW1hdGlvbiBpcyB2ZXJ5IGxpdHRsZSBiZWNhdXNlIHRoZSBoaWdoIGJpdCByYXRl
IG9mIHRoZSBMQU4gYW5kIHJlbGF0aXZlIHNtYWxsIHByb2Nlc3NpbmcgdGltZSBvZiB0aGUgbGFz
dCBPUEVOIG1lc3NhZ2UgcmVzcGVjdCB0byB0aGUgdG90YWwgcHJvdmlzaW9uaW5nIHRpbWUuDQo0
KQlUaGUgbWVhc3VyZW1lbnQgb2YgdGhlIHVwZGF0aW5nIHRpbWUgb2YgdGhlIERpZmYtc2VydiBQ
SUIuIEkgdGhpbmsgdG8gbWVhc3VyZSB0aGUgdGltZSBlbGFwc2VkIGJldHdlZW4gdGhlIHJldHVy
biBvZiB0aGUgk3JlY2VpdmWUIGZ1bmN0aW9uIG9mIHRoZSBkZWNpc2lvbiBtZXNzYWdlIGFuZCB0
aGUgZW5kIG9mIHRoZSBQSUIgdXAgZGF0ZS4NCg0KQXMgcHJvZmlsaW5nIG1ldGhvZCBJkm0gdXNp
bmcgdGhlIJN0aW1lIHN0YW1wIGNvdW50ZXKUIG9mIHRoZSBQZW50aXVtIHByb2Nlc3Nvci4gVGhl
IGNvdW50ZXIgaXMgaW5jcmVtZW50ZWQgYnkgYW4gdW5pdHkgZXZlcnkgY2xvY2sgY3ljbGUuIFRo
ZSBjb3VudGVyIGNhbiBiZSB1c2VkIHZlcnkgc2ltcGx5IHRvIHJlY29yZCB0aGUgZXhlY3V0aW9u
IHRpbWUgb2YgYW4gaW5zdHJ1Y3Rpb24gc2V0LiBUaGUgZXhlY3V0aW9uIHRpbWUgaXMgdGhlIGRp
ZmZlcmVuY2UgYmV0d2VlbiB0aGUgdmFsdWUgb2YgdGhlIGNvdW50ZXIganVzdCBhZnRlciBhbmQg
anVzdCBiZWZvcmUgdGhlIGluc3RydWN0aW9uIGJsb2NrLCBkaXZpZGVkIGZvciB0aGUgcHJvY2Vz
c29yIGZyZXF1ZW5jeS4gVGhpcyBtZXRob2QgaGFzIGJlZW4gY2hvc2VuIGZvciBpdHMgaGlnaCBw
cmVjaXNpb24gKGEgc2luZ2xlIGNsb2NrIGN5Y2xlKSBhbmQgZm9yIGl0cyBsb3cgb3ZlciBoZWFk
LiBUaGUgbWV0aG9kIGlzIGFwcGxpY2FibGUgdG8gdGhlIHByb3Bvc2VkIG1lYXN1cmUgd2l0aCBz
b21lIGZldyBvdGhlciBhdHRlbnRpb25zIGR1ZSB0byB0aGUgdGhyZWFkZWQgZXhlY3V0aW9uIG9m
IFBEUHMuIA0KQWxsIG1lYXN1cmVzIHdpbGwgYWxzbyBiZSByZXBlYXRlZCB3aXRoIGZvdXIgZGlm
ZmVyZW50IERpZmYtU2VydiBjb25maWd1cmF0aW9uLiBUaGlzIHRvIGV2YWx1YXRlIHRoZSBpbXBh
Y3Qgb2YgdGhlIHBvbGljeSBjb21wbGV4aXR5IG9uIHRoZSB0aW1lcyByZWNvcmRlZC4NCg0KUGxl
YXNlLCBhbnkgb25lIGlzIGludGVyZXN0ZWQgY2FuIG1ha2UgbWUgcXVlc3Rpb25zIGFuZCBzZW5k
IG1lIGhpcy9oZXIgY29tbWVudHMvc3VnZ2VzdGlvbnMuDQo=

------_=_NextPart_001_01C236DA.8F27FB14--



From owner-rap@ops.ietf.org  Mon Jul 29 21:36:35 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21440
	for <rap-archive@lists.ietf.org>; Mon, 29 Jul 2002 21:36:35 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1)
	id 17ZLvZ-0001BN-00
	for rap-data@psg.com; Mon, 29 Jul 2002 18:35:57 -0700
Received: from jffdns01.or.intel.com ([134.134.248.3] helo=ganymede.or.intel.com)
	by psg.com with esmtp (Exim 3.36 #1)
	id 17ZLvV-0001B7-00
	for rap@ops.ietf.org; Mon, 29 Jul 2002 18:35:53 -0700
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by ganymede.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6U1Zq504611
	for <rap@ops.ietf.org>; Tue, 30 Jul 2002 01:35:52 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002072918364722561
 ; Mon, 29 Jul 2002 18:36:47 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <P2AHL892>; Mon, 29 Jul 2002 18:35:52 -0700
Message-ID: <59885C5E3098D511AD690002A5072D3C07868F2E@orsmsx111.jf.intel.com>
From: "Hahn, Scott" <scott.hahn@intel.com>
To: rap@ops.ietf.org
Cc: mlstevens@rcn.com, "Bert Wijnen (Bert) (E-mail)" <bwijnen@lucent.com>,
        Diana.Rawlins@wcom.com, amol.kulkarni@intel.com,
        khchan@nortelnetworks.com, mbokaemper@unispherenetworks.com,
        ddutt@cisco.com
Subject: WG Last Call for draft-ietf-rap-feedback-frwk-02.txt and draft-ie
	tf-rap-feedback-fr-pib-03.txt
Date: Mon, 29 Jul 2002 18:35:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.31
Sender: owner-rap@ops.ietf.org
Precedence: bulk

As discussed at the RAP working group meeting in Yokohama, the following 2
drafts are now ready for WG last call. 

http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt

Please review these drafts in the next two weeks and submit comments to the
mailing list.

Working group last-call on these documents will end August 12, 2002.

Regards
   Scott Hahn
   Mark Stevens
   RAP WG co-chairs