From owner-rap@ops.ietf.org  Wed Jun  6 21:21:47 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11501
	for <rap-archive@lists.ietf.org>; Wed, 6 Jun 2001 21:21:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 157oT3-000CKA-00
	for rap-data@psg.com; Wed, 06 Jun 2001 18:20:09 -0700
Received: from [63.109.116.89] (helo=longmail2.lboard.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 157oT2-000CJr-00
	for rap@ops.ietf.org; Wed, 06 Jun 2001 18:20:08 -0700
Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21)
	id <L3S8424S>; Wed, 6 Jun 2001 21:19:37 -0400
Message-ID: <F2F760C942EBD411B98800A0CC733FCF179465@longmail2.lboard.com>
From: Ed Ellesson <eellesson@lboard.com>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Cc: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>,
        "'Joel M. Halpern'"
	 <joel@longsys.com>
Subject: RAP WG Notice:  Policy Terminology Last Call is now complete
Date: Wed, 6 Jun 2001 21:19:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi, RAP WG:
We apologize to those of you who receive more than one copy of this notice.

The extended working group last call is now completed, for the draft titled
"Terminology" (draft-ietf-policy-terminology-03.txt), which is being
re-titled as "Terminology for Policy-Based Management".  This extended last
call provided an opportunity for the following working groups to comment on
the draft, and discuss proposed changes on the Policy Framework WG mailing
list.  
Working groups participating in the extended working group last call for
this draft: 
Policy
DiffServ
RAP
IPSP
SNMPCONF
AAA
AAAArch (IRTF)
RSVP
MPLS
Comments resulting from this extended multiple working group last call were
discussed and accepted on the policy framework working group mailing list.
The document will be revised in accordance with the results of that
discussion.   The Policy Framework working group will then submit it to the
IESG to request their review and approval for publication as an
Informational RFC. 
Thanks to all of you who participated in this successful extended working
group last call, and a special thanks to Andrea Westerinen, who edited the
draft, engaged in the discussion of the comments, and who will update it per
the discussion results.
Ed Ellesson, with Joel Halpern, Co-chairs, Policy Framework WG




From owner-rap@ops.ietf.org  Thu Jun  7 15:11:53 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12798
	for <rap-archive@lists.ietf.org>; Thu, 7 Jun 2001 15:11:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 1585At-000OTJ-00
	for rap-data@psg.com; Thu, 07 Jun 2001 12:10:31 -0700
Received: from [63.104.246.2] (helo=MAIL-CLUSTER.calynet.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 1585As-000OTD-00
	for rap@ops.ietf.org; Thu, 07 Jun 2001 12:10:30 -0700
Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2653.19)
	id <L3X5RBYX>; Thu, 7 Jun 2001 12:08:03 -0700
Message-ID: <636C2D109E6CD3119C3600062905FE8F9F599B@mail-cluster.calynet.com>
From: Sumit Vakil <sumit@calynet.com>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: Policy Device Auxiliary MIB
Date: Thu, 7 Jun 2001 12:08:01 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Whatever happened to the Policy Device Auxiliary MIB?  Couldn't find it on
the IETF's RAP page.

Thanks,

Sumit A. Vakil
Caly Networks



From owner-rap@ops.ietf.org  Thu Jun  7 15:31:21 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13099
	for <rap-archive@lists.ietf.org>; Thu, 7 Jun 2001 15:31:20 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 1585VI-0000WF-00
	for rap-data@psg.com; Thu, 07 Jun 2001 12:31:36 -0700
Received: from [64.223.136.42] (helo=postal.ellacoya.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 1585VI-0000RO-00
	for rap@ops.ietf.org; Thu, 07 Jun 2001 12:31:36 -0700
Received: from ellacoya.com (192.168.245.41 [192.168.245.41]) by postal.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LD4SQ3TZ; Thu, 7 Jun 2001 15:28:45 -0400
Message-ID: <3B1FD66D.8144F310@ellacoya.com>
Date: Thu, 07 Jun 2001 15:30:53 -0400
From: "Mark L. Stevens" <mstevens@ellacoya.com>
Organization: Ellacoya Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Sumit Vakil <sumit@calynet.com>
CC: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: Re: Policy Device Auxiliary MIB
References: <636C2D109E6CD3119C3600062905FE8F9F599B@mail-cluster.calynet.com>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA13099

The draft expired. The authors are busily readying it for re-submission. Look
for it again soon.

If any of the authors are listening, do not hesitate to re-submit the
document at your earliest convenience.  A quick note indicating the expected
time for doing so would be very helpful, too.

-Mark Stevens

Sumit Vakil wrote:

> Whatever happened to the Policy Device Auxiliary MIB?  Couldn't find it on
> the IETF's RAP page.
>
> Thanks,
>
> Sumit A. Vakil
> Caly Networks


From owner-rap@ops.ietf.org  Fri Jun  8 04:10:22 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07475
	for <rap-archive@lists.ietf.org>; Fri, 8 Jun 2001 04:10:22 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 158HKs-0009Zb-00
	for rap-data@psg.com; Fri, 08 Jun 2001 01:09:38 -0700
Received: from porsta.cs.helsinki.fi ([128.214.48.124] ident=root)
	by psg.com with esmtp (Exim 3.16 #1)
	id 158HKq-0009Wh-00
	for rap@ops.ietf.org; Fri, 08 Jun 2001 01:09:36 -0700
Received: from localhost (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by porsta.cs.Helsinki.FI (8.11.3/8.11.3) with ESMTP id f5889Vm28562
	for <rap@ops.ietf.org>; Fri, 8 Jun 2001 11:09:31 +0300
Date: Fri, 8 Jun 2001 11:09:32 +0300 (EET DST)
From: Jukka Manner <jmanner@cs.Helsinki.FI>
To: <rap@ops.ietf.org>
Subject: What has happened to the RSVP proxy work?
In-Reply-To: <636C2D109E6CD3119C3600062905FE8F9F599B@mail-cluster.calynet.com>
Message-ID: <Pine.LNX.4.30.0106081102060.2130-100000@melkinkari.cs.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rap@ops.ietf.org
Precedence: bulk


	Hi,

	I've tried to find out what has happened to the RSVP proxy work? I've
understood that the first ID on the ideas (draft-ietf-rsvp-proxy-02) was taken
to the RAP WG and converged with the ID on COPS usage with the RSVP proxy. What
has happened to this work, as the latest draft-nitsan-cops-rsvp-proxy-03 draft
has expired.

	BR,

	Jukka Manner





From owner-rap@ops.ietf.org  Mon Jun 11 12:33:13 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14249
	for <rap-archive@lists.ietf.org>; Mon, 11 Jun 2001 12:33:07 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159Ubq-0002qK-00
	for rap-data@psg.com; Mon, 11 Jun 2001 09:32:10 -0700
Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr)
	by psg.com with esmtp (Exim 3.16 #1)
	id 159UbW-0002pY-00
	for rap@ops.ietf.org; Mon, 11 Jun 2001 09:32:09 -0700
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP id 8BAAE18C2
	for <rap@ops.ietf.org>; Mon, 11 Jun 2001 18:31:25 +0200 (MET DST)
Message-ID: <3B24F311.C700289A@yahoo.com>
Date: Mon, 11 Jun 2001 18:34:25 +0200
From: Nguyen Thi Mai Trang <maitrangqos@yahoo.com>
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rap@ops.ietf.org
Subject: COPS usage
References: <636C2D109E6CD3119C3600062905FE8F9F599B@mail-cluster.calynet.com> <3B1FD66D.8144F310@ellacoya.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

I have a question about the COPS protocol usage.

In the normal operation of COPS-PR, the network administrator will creat the
policies and stock them in the COPS-PR Policy Repository. The COPS-PR PDP
connects to the COPS-PR Policy Repository to retrieve the policy and configure
its PEP.

I would like to make a SLA server who manages all SLAs of the domain. Instead of
creating all the policies for the COPS-PR Policy Repository, the administrator
will creat the policies for the SLA server and stock them in the SLA Policy
Repository. The SLA server connects to the SLA Policy Repository to retrieve the
policy. The SLA policy helps the SLA server decide to accept or refuse a SLS
requested by his client. Once the SLA server accept a SLS (i.e., the SLA is
established), it will make some changes or generate some new rules in the Policy
Repository of the COPS-PR Policy Repository so that the COPS-PR PDP can properly
configure its PEPs.

My questions :
1. Am I permitted to use the COPS protocol for the communication between the SLA
client and the SLA server ? call the SLA server the PDP and I call the SLA client
the PEP ?
2. If the answer of question 1 is "yes", is the fact that the SLA PDP make some
changes in the Policy Repository of COPS-PR PDP conflict with the Policy Based
Management Framework and Architecture ?

Thank you very much.
Mai Trang








From owner-rap@ops.ietf.org  Mon Jun 11 13:03:00 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14875
	for <rap-archive@lists.ietf.org>; Mon, 11 Jun 2001 13:02:58 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159V5d-0003Xj-00
	for rap-data@psg.com; Mon, 11 Jun 2001 10:02:57 -0700
Received: from pmesmtp01.wcom.com ([199.249.20.1])
	by psg.com with esmtp (Exim 3.16 #1)
	id 159V5c-0003XS-00
	for rap@ops.ietf.org; Mon, 11 Jun 2001 10:02:56 -0700
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GER003K6Z9F25@firewall.mcit.com> for rap@ops.ietf.org; Mon,
 11 Jun 2001 17:00:51 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GER00K01Z8VRM@pmismtp01.wcomnet.com>;
 Mon, 11 Jun 2001 17:00:51 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GER00HO6Z8UAJ@pmismtp01.wcomnet.com>; Mon,
 11 Jun 2001 17:00:30 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id <K25G50AP>; Mon, 11 Jun 2001 17:00:29 +0000
Content-return: allowed
Date: Mon, 11 Jun 2001 17:00:25 +0000
From: "Iliff, Tina" <Tina.Iliff@WCOM.Com>
Subject: RE: COPS usage
To: "'Nguyen Thi Mai Trang'" <maitrangqos@yahoo.com>, rap@ops.ietf.org
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Sender: owner-rap@ops.ietf.org
Precedence: bulk



Mai Trang,

Here is one answer or recommendation to your questions.
1. I would recommend using COPS usage for RSVP.
2. No, it does not conflict.  In fact, you can consider this as an example
of an "external event" which is mentioned in the COPS RFCs.
Tina Iliff


 -----Original Message-----
From: 	Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com] 
Sent:	Monday, June 11, 2001 11:34 AM
To:	rap@ops.ietf.org
Subject:	COPS usage

Hi all,

I have a question about the COPS protocol usage.

In the normal operation of COPS-PR, the network administrator will creat the
policies and stock them in the COPS-PR Policy Repository. The COPS-PR PDP
connects to the COPS-PR Policy Repository to retrieve the policy and
configure
its PEP.

I would like to make a SLA server who manages all SLAs of the domain.
Instead of
creating all the policies for the COPS-PR Policy Repository, the
administrator
will creat the policies for the SLA server and stock them in the SLA Policy
Repository. The SLA server connects to the SLA Policy Repository to retrieve
the
policy. The SLA policy helps the SLA server decide to accept or refuse a SLS
requested by his client. Once the SLA server accept a SLS (i.e., the SLA is
established), it will make some changes or generate some new rules in the
Policy
Repository of the COPS-PR Policy Repository so that the COPS-PR PDP can
properly
configure its PEPs.

My questions :
1. Am I permitted to use the COPS protocol for the communication between the
SLA
client and the SLA server ? call the SLA server the PDP and I call the SLA
client
the PEP ?
2. If the answer of question 1 is "yes", is the fact that the SLA PDP make
some
changes in the Policy Repository of COPS-PR PDP conflict with the Policy
Based
Management Framework and Architecture ?

Thank you very much.
Mai Trang








From owner-rap@ops.ietf.org  Mon Jun 11 16:16:46 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18164
	for <rap-archive@lists.ietf.org>; Mon, 11 Jun 2001 16:16:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159Y6q-00068g-00
	for rap-data@psg.com; Mon, 11 Jun 2001 13:16:24 -0700
Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr)
	by psg.com with esmtp (Exim 3.16 #1)
	id 159Y6p-00068a-00
	for rap@ops.ietf.org; Mon, 11 Jun 2001 13:16:23 -0700
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP id 6DD881895
	for <rap@ops.ietf.org>; Mon, 11 Jun 2001 22:16:20 +0200 (MET DST)
Message-ID: <3B2527C8.C142B526@yahoo.com>
Date: Mon, 11 Jun 2001 22:19:20 +0200
From: Nguyen Thi Mai Trang <maitrangqos@yahoo.com>
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rap@ops.ietf.org
Subject: Re: COPS usage
References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Tina and all,

Thanks alot for your answer. Permit me to have two other questions.

3. Can a PDP of a client-type be a PEP of another client-type? For exemple, in
the same machine of  the COPS-PR PDP, I implement a SLA-PEP who occupies the SLA
establishment with another domain.

4. In the same client-type, can a PDP be a PEP of another PDP? For example, in
the same machine of the SLA-PDP who manages all SLAs of  domain A, I implement a
SLA-PEP who occupies the SLA establishment with domain B.

I poste these four questions because of the following context:  (see the exemple

in question 4)  when a client of  domain A requests a SLS to the SLA-PDP of
domain A, if this is an intra-domain SLS request, the SLA-PDP may accept this
request and make some changes in the COPS-PR Policy Repository. If this is an
inter-domain SLS request, the SLA-PDP does not reply yet, it transfers this
request to the SLA-PEP who occupies the SLA establishment with domain B. When
the request is accepted by the other domain, it may accept this request and make
some changes in the COPS-PR Policy Repository of domain A.

My friend says that "If you implement three entities (COPS-PR PDP of domain A,
SLA-PDP of domain A, SLA-PEP for SLA establishment with domain B) in the same
machine, it conflicts with the Policy Based Management Framework and
Architecture. Firstly, a PDP can not a be PEP. Secondly, all a PDP does is send
the DEC to the client, not other things (e.g. make some changes in one Policy
Repository). Thirdly, a COPS-PDP can not make some changes in the Policy
Repository because they are not in the same abstraction level".

I say that "It doesn't conflict with the architecture and the framework.
Firstly, why can not a PDP be a PEP when they are logically two separate
entities? Secondly, I don't find out in the RFCs the convention that the PDP can

not make other things than sending the DEC to its client. Thirdly, "a PDP makes
some changes in its Policy Repository" may conflict with the architecture BUT "a

PDP makes some changes in the Policy Repositoy of another PDP" does not conflict
with the architecture. How it can make some change in the other Policy
Repository is the implementation problem "

We can not arrive the conclusion:-( Excuse-me for a long message but I only hope

for getting the answer in the mailing list of RAP WG who defines the Policy
Based Management Framework and Architecture.

Thank you very much in advance.
Mai Trang

"Iliff, Tina" wrote:

> Mai Trang,
>
> Here is one answer or recommendation to your questions.
> 1. I would recommend using COPS usage for RSVP.
> 2. No, it does not conflict.  In fact, you can consider this as an example
> of an "external event" which is mentioned in the COPS RFCs.
> Tina Iliff
>
>  -----Original Message-----
> From:   Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com]
> Sent:   Monday, June 11, 2001 11:34 AM
> To:     rap@ops.ietf.org
> Subject:        COPS usage
>
> Hi all,
>
> I have a question about the COPS protocol usage.
>
> In the normal operation of COPS-PR, the network administrator will creat the
> policies and stock them in the COPS-PR Policy Repository. The COPS-PR PDP
> connects to the COPS-PR Policy Repository to retrieve the policy and
> configure
> its PEP.
>
> I would like to make a SLA server who manages all SLAs of the domain.
> Instead of
> creating all the policies for the COPS-PR Policy Repository, the
> administrator
> will creat the policies for the SLA server and stock them in the SLA Policy
> Repository. The SLA server connects to the SLA Policy Repository to retrieve
> the
> policy. The SLA policy helps the SLA server decide to accept or refuse a SLS
> requested by his client. Once the SLA server accept a SLS (i.e., the SLA is
> established), it will make some changes or generate some new rules in the
> Policy
> Repository of the COPS-PR Policy Repository so that the COPS-PR PDP can
> properly
> configure its PEPs.
>
> My questions :
> 1. Am I permitted to use the COPS protocol for the communication between the
> SLA
> client and the SLA server ? call the SLA server the PDP and I call the SLA
> client
> the PEP ?
> 2. If the answer of question 1 is "yes", is the fact that the SLA PDP make
> some
> changes in the Policy Repository of COPS-PR PDP conflict with the Policy
> Based
> Management Framework and Architecture ?
>
> Thank you very much.
> Mai Trang

--
----------------------------------------------------
Nguyen Thi Mai Trang
Ecole Nationale Superieure des Telecommunications
Dept. INFRES - Bur. C234-4
46 Rue Barrault - 75013 Paris
Tel: 01 45 81 72 61 - Fax : 01 45 81 31 19
email : trnguyen@enst.fr





From owner-rap@ops.ietf.org  Tue Jun 12 11:51:30 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18068
	for <rap-archive@lists.ietf.org>; Tue, 12 Jun 2001 11:51:28 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159qS8-000K1u-00
	for rap-data@psg.com; Tue, 12 Jun 2001 08:51:36 -0700
Received: from mel.alcatel.fr ([212.208.74.132])
	by psg.com with esmtp (Exim 3.16 #1)
	id 159qS7-000K1o-00
	for rap@ops.ietf.org; Tue, 12 Jun 2001 08:51:35 -0700
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id QAA01551;
        Tue, 12 Jun 2001 16:29:26 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA06804;
        Tue, 12 Jun 2001 17:51:01 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id RAA03298;
	Tue, 12 Jun 2001 17:51:02 +0200 (MET DST)
Received: from pc50062 ([188.9.248.194])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id RAA29941;
	Tue, 12 Jun 2001 17:51:07 +0200 (MET DST)
Message-ID: <02b901c0f357$265828b0$c2f809bc@ms.alcatel.fr>
Reply-To: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
From: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
To: <rap@ops.ietf.org>, <diffserv@ietf.org>
References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com> <3B2527C8.C142B526@yahoo.com>
Subject: PIB design
Date: Tue, 12 Jun 2001 17:48:38 +0200
Organization: Alcatel R&I
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

My question is quite simple, I guess some of you well know the diffserv PIB
: Finally, since the lattest versions, it is very closed to the diffserv
MIB.
So, will all the future specific PIBs be so closed to their corresponding
MIB ?
If not, what motivated such a choice for diffserv ?

Thanks,
Yacine

-- Yacine El Mghazli
----------------------------------------------------------------------
  Alcatel R&I
  Software and Services Strategic Program - VIPeR
  Marcoussis, France
  Tel  +33 1 6963 4187
  Fax  +33 1 6963 1169
  yacine.el_mghazli@ms.alcatel.fr
----------------------------------------------------------------------




From owner-rap@ops.ietf.org  Tue Jun 12 12:21:47 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18593
	for <rap-archive@lists.ietf.org>; Tue, 12 Jun 2001 12:21:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159qvP-000KKn-00
	for rap-data@psg.com; Tue, 12 Jun 2001 09:21:51 -0700
Received: from birch.ee.vt.edu ([128.173.88.34])
	by psg.com with esmtp (Exim 3.16 #1)
	id 159qvO-000KKh-00
	for rap@ops.ietf.org; Tue, 12 Jun 2001 09:21:50 -0700
Received: from yew.ee.vt.edu (yew.ee.vt.edu [128.173.88.43])
	by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id MAA02834
	for <rap@ops.ietf.org>; Tue, 12 Jun 2001 12:21:48 -0400 (EDT)
Received: from localhost (kphanse@localhost)
	by yew.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id MAA11453
	for <rap@ops.ietf.org>; Tue, 12 Jun 2001 12:21:48 -0400 (EDT)
Date: Tue, 12 Jun 2001 12:21:47 -0400 (EDT)
From: Kaustubh Phanse <kphanse@ee.vt.edu>
To: rap@ops.ietf.org
Message-ID: <Pine.GSO.3.96.1010612120937.10840B-100000@yew.ee.vt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rap@ops.ietf.org
Precedence: bulk


Hello!
	Just curious if there are any practical/experimental results
about COPS performance when used with RSVP for outsourcing policies etc.
in terms of for example the signaling overhead (bandwidth usage,
additional delay incurred in setting up the RSVP reservation) or any such
related results. I would be more than happy to know more about the same.
	Also is there any ongoing research effort (either academic or in
industry) in setting up policies between multiple domains (e.g. through
some kind of inter-PDP signaling)?? I guess the bandwidth broker concept
and architecture comes close to this? Possible extension could be a BB
which could also incorporate PDP functionalities??
	Any comments/suggestions on the above questions or any relevant
ongoing/open research issues for QoS policy are more than welcome.

Thank you
regards
Kaustubh
-----------------------------------------------------------------------------
 Kaustubh S. Phanse					  kphanse@ee.vt.edu
 PhD student				       http://www.ee.vt.edu/~kphanse
 Alexandria Research Institute
 Electrical & Computer Engineering Department		               
 Virginia Polytechnic Institute & State University 
-----------------------------------------------------------------------------




From owner-rap@ops.ietf.org  Tue Jun 12 15:44:20 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23313
	for <rap-archive@lists.ietf.org>; Tue, 12 Jun 2001 15:44:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159u5I-000Mms-00
	for rap-data@psg.com; Tue, 12 Jun 2001 12:44:16 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim)
	by psg.com with esmtp (Exim 3.16 #1)
	id 159u5I-000Mmm-00
	for rap@ops.ietf.org; Tue, 12 Jun 2001 12:44:16 -0700
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 159u5I-000E4b-00
	for rap@ops.ietf.org; Tue, 12 Jun 2001 12:44:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Brian E Carpenter <brian@hursley.ibm.com>
To: Yacine El Mghazli <yacine.el_mghazli@ms.alcatel.fr>
CC: rap@ops.ietf.org, diffserv@ietf.org
Subject: Re: [Diffserv] PIB design
References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com> <3B2527C8.C142B526@yahoo.com> <02b901c0f357$265828b0$c2f809bc@ms.alcatel.fr>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Message-Id: <E159u5I-000Mms-00@psg.com>
Date: Tue, 12 Jun 2001 12:44:16 -0700
Content-Transfer-Encoding: 7bit

It's certainly intentional for the diffserv case, for many
obvious practical reasons. For the general case, that is a RAP 
discussion only and diffserv has nothing to say.

    Brian

Yacine El Mghazli wrote:
> 
> Hi all,
> 
> My question is quite simple, I guess some of you well know the diffserv PIB
> : Finally, since the lattest versions, it is very closed to the diffserv
> MIB.
> So, will all the future specific PIBs be so closed to their corresponding
> MIB ?
> If not, what motivated such a choice for diffserv ?
> 
> Thanks,
> Yacine
> 
> -- Yacine El Mghazli
> ----------------------------------------------------------------------
>   Alcatel R&I
>   Software and Services Strategic Program - VIPeR
>   Marcoussis, France
>   Tel  +33 1 6963 4187
>   Fax  +33 1 6963 1169
>   yacine.el_mghazli@ms.alcatel.fr
> ----------------------------------------------------------------------
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org




From owner-rap@ops.ietf.org  Tue Jun 12 16:26:15 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24019
	for <rap-archive@lists.ietf.org>; Tue, 12 Jun 2001 16:26:13 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 159uk4-000NHl-00
	for rap-data@psg.com; Tue, 12 Jun 2001 13:26:24 -0700
Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 159uk3-000NHF-00
	for rap@ops.ietf.org; Tue, 12 Jun 2001 13:26:23 -0700
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CKPPE12983
	for <rap@ops.ietf.org>; Tue, 12 Jun 2001 16:25:27 -0400 (EDT)
Message-Id: <200106122025.f5CKPPE12983@zcars0m9.ca.nortel.com>
Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 12 Jun 2001 16:25:02 -0400
Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id MZJ8MWN1; Tue, 12 Jun 2001 16:25:04 -0400
Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) 
          by zbl6c000.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JM9FPH06; Tue, 12 Jun 2001 16:25:01 -0400
X-Sender: khchan@zbl6c000.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 12 Jun 2001 16:23:11 -0400
To: Yacine El Mghazli <yacine.el_mghazli@ms.alcatel.fr>
X-Sybari-Space: 00000000 00000000 00000000
From: "Kwok-Ho Chan" <khchan@nortelnetworks.com>
Subject: Re: PIB design
Cc: rap <rap@ops.ietf.org>, diffserv <diffserv@ietf.org>
In-Reply-To: <02b901c0f357$265828b0$c2f809bc@ms.alcatel.fr>
References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com> <3B2527C8.C142B526@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Orig: <khchan@NortelNetworks.com>
Sender: owner-rap@ops.ietf.org
Precedence: bulk

IMHO, some of the reasons for the DiffServ MIB and PIB "closeness":
1. Common co-authors with Model, PIB, MIB drafts.
2. Some of the PIB work actually started before the Model and MIB drafts.
    Some of the idea in the original PIB was used in the Model and MIB,
    and some improved in the Model and MIB.
3. At the end of the day, implementations will have a set of
    registers/memory locations to hold the data definitions for provisioning.
    It will be nice to have the same data definition no matter PIB or MIB is
    used, RoleCombo or Interface specific.

This is done for DiffServ, it will be good to do the same for the other
technologies, but that is not a DiffServ WG issue.

-- Kwok Ho Chan --


At 05:48 PM 6/12/01 +0200, Yacine El Mghazli wrote:
>Hi all,
>
>My question is quite simple, I guess some of you well know the diffserv PIB
>: Finally, since the lattest versions, it is very closed to the diffserv
>MIB.
>So, will all the future specific PIBs be so closed to their corresponding
>MIB ?
>If not, what motivated such a choice for diffserv ?
>
>Thanks,
>Yacine
>
>-- Yacine El Mghazli
>----------------------------------------------------------------------
>  Alcatel R&I
>  Software and Services Strategic Program - VIPeR
>  Marcoussis, France
>  Tel  +33 1 6963 4187
>  Fax  +33 1 6963 1169
>  yacine.el_mghazli@ms.alcatel.fr
>----------------------------------------------------------------------
> 




From owner-rap@ops.ietf.org  Wed Jun 13 11:20:51 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24951
	for <rap-archive@lists.ietf.org>; Wed, 13 Jun 2001 11:20:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15ACR3-0008lA-00
	for rap-data@psg.com; Wed, 13 Jun 2001 08:19:57 -0700
Received: from [65.194.140.138] (helo=email2.it.west.unispherenetworks.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15ACR3-0008kb-00
	for rap@ops.ietf.org; Wed, 13 Jun 2001 08:19:57 -0700
Received: by mailhost2.unispherenetworks.com with Internet Mail Service (5.5.2653.19)
	id <MS66LZA5>; Wed, 13 Jun 2001 11:19:26 -0400
Message-ID: <9DCB6C9DC7C3D311B835009027DE069F03533A4E@mailhost2.unispherenetworks.com>
From: "Moisand, Jerome" <jmoisand@unispherenetworks.com>
To: "'MORAND Pierrick FTRD/DMI/CAE'" <pierrick.morand@rd.francetelecom.fr>,
        "IPSEC-POLICY (E-mail)" <ipsec-policy@vpnc.org>,
        "RAP (E-mail)"
	 <rap@ops.ietf.org>
Subject: RE: COPS-PR security general  issues
Date: Wed, 13 Jun 2001 11:19:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk


I support the concern described by the e-mail quoted below, which resonates
quite well with what I heard from multiple service providers during
COPS-related discussions.

I would suggest that the topic is discussed during the next IETF meeting in
the context of the "rap" group since the point is essentially to secure the
COPS/COPS-PR interactions, irrespective of the type of policies being
managed.

In this context, among other alternatives, I would also suggest to discuss
the following internet-draft:
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt

Tx
Jerome

=========================================== 
Jerome P. Moisand 
Senior Product Manager 
Unisphere Networks 
mailto:jmoisand@UnisphereNetworks.com 




-----Original Message-----
From: MORAND Pierrick FTRD/DMI/CAE
[mailto:pierrick.morand@rd.francetelecom.fr]
Sent: Thursday, May 31, 2001 8:08 AM
To: IPSEC-POLICY (E-mail); RAP (E-mail)
Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE
Subject: COPS-PR security general issues


We are currently working on the general theme of provisioning. We are
considering COPS-PR with attention and would bring to the attention of RAP
and IPSP experts the following remarks and questions with our apologizes if
these issues have already been debated.

In a general way, COPS-PR has been designed to provision configuration
policies for various functional domains such as IPSec, L2TP, MPLS, AAA,
Routing, TE ....

Considering for instance, IPSec, AAA and L2TP, provisioning of those
functions leads to exchange with the equipment sensitive information such as
shared secrets (L2TP-Tunnel-password, users password, radius secret and so
on).

Within COPS there is an optional security mechanisms, which only guarantees
the integrity of the COPS messages. There is no general mechanisms allowing
to cipher some particular sensitive fields.

Do these security issues shall conduct an implementer or an operator to
systematically make use of IPSec to secure exchanges between a PEP and a PDP
so that it becomes possible to provision sensitive security information
without having to defined ciphered fields in the PIBs for which no generic
mechanisms have currently been defined ?

If  IPSec is used to secure COPS-PR exchanges what would become the utility
of the integrity mechanisms defined within COPS and more especially when
used within COPS-PR ?

Additionally, the IPSec PIB which is currently in its definition phase,
allows to define IKE rules specifying pre-shared key as Ike proposal
authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with
presharedKey(1) as possible value]method but does not allow to provision
those secrets. This means that the provisioning of those secrets shall be
done by an other way and in that case advantages of COPS-PR in case of
pre-shared authentication becomes greatly reduced since this shall be
achieved by hand or using an other mechanism.

In a same way if L2TP or AAA PIBs were to be defined how secrets (and more
generally sensitive information) should be provisioned ? 
-In clear : not reasonable
-Ciphered : there is no generic mechanisms
-Protected by IPSec, SSL... : should work fine, but the RFC should precise
that usage of a particular client type, defining sensitive information MUST
make use of an external mechanisms in order to secure those sensitive
information..

To conclude it seams that we can have the two possible approaches in order
to allow the exchange of sensible security information between a PEP an a
PDP :
1-systematicaly make use of an underlying security layer (IPSec for
instance) to secure exchanges between PEP and PDP. In that case the COPS
integrity mechanism is no more necessary. This approach implies that the PEP
has to support a security communication layer which might not be the case in
all situation.
2-defines a generic COPS ciphering mechanism which allows to protect some
sensitive fields. Security is embedded in the COPS protocol and must be
supported.

If this issue was solved, could IPSP experts extend the PIB so that shared
secret can be exchanged or is the reason for which it is not currently
supported more fundamental ?

Thanks in advance for your answers and comments.

Pierrick Morand
france telecom R&D/DMI/SIR/IPI
Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email :pierrick.morand@francetelecom.com





From owner-rap@ops.ietf.org  Wed Jun 13 16:57:47 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01515
	for <rap-archive@lists.ietf.org>; Wed, 13 Jun 2001 16:57:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15AHg2-000DMD-00
	for rap-data@psg.com; Wed, 13 Jun 2001 13:55:46 -0700
Received: from [65.194.140.138] (helo=email2.it.west.unispherenetworks.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15AHg1-000DLw-00
	for rap@ops.ietf.org; Wed, 13 Jun 2001 13:55:45 -0700
Received: by mailhost2.unispherenetworks.com with Internet Mail Service (5.5.2653.19)
	id <MS66LZZ5>; Wed, 13 Jun 2001 16:55:14 -0400
Message-ID: <9DCB6C9DC7C3D311B835009027DE069F03533A5D@mailhost2.unispherenetworks.com>
From: "Moisand, Jerome" <jmoisand@unispherenetworks.com>
To: "'IPSEC-POLICY (E-mail)'" <ipsec-policy@vpnc.org>,
        "'RAP (E-mail)'"
	 <rap@ops.ietf.org>
Subject: RE: COPS-PR security general  issues
Date: Wed, 13 Jun 2001 16:54:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk


Sorry if it's a duplicate, sounds that I got filtered first time I sent this
e-mail.

Tx
Jerome

-----Original Message-----
From: Moisand, Jerome 
Sent: Wednesday, June 13, 2001 11:19 AM
To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail); RAP (E-mail)
Subject: RE: COPS-PR security general issues



I support the concern described by the e-mail quoted below, which resonates
quite well with what I heard from multiple service providers during
COPS-related discussions.

I would suggest that the topic is discussed during the next IETF meeting in
the context of the "rap" group since the point is essentially to secure the
COPS/COPS-PR interactions, irrespective of the type of policies being
managed.

In this context, among other alternatives, I would also suggest to discuss
the following internet-draft:
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt

Tx
Jerome

=========================================== 
Jerome P. Moisand 
Senior Product Manager 
Unisphere Networks 
mailto:jmoisand@UnisphereNetworks.com 




-----Original Message-----
From: MORAND Pierrick FTRD/DMI/CAE
[mailto:pierrick.morand@rd.francetelecom.fr]
Sent: Thursday, May 31, 2001 8:08 AM
To: IPSEC-POLICY (E-mail); RAP (E-mail)
Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE
Subject: COPS-PR security general issues


We are currently working on the general theme of provisioning. We are
considering COPS-PR with attention and would bring to the attention of RAP
and IPSP experts the following remarks and questions with our apologizes if
these issues have already been debated.

In a general way, COPS-PR has been designed to provision configuration
policies for various functional domains such as IPSec, L2TP, MPLS, AAA,
Routing, TE ....

Considering for instance, IPSec, AAA and L2TP, provisioning of those
functions leads to exchange with the equipment sensitive information such as
shared secrets (L2TP-Tunnel-password, users password, radius secret and so
on).

Within COPS there is an optional security mechanisms, which only guarantees
the integrity of the COPS messages. There is no general mechanisms allowing
to cipher some particular sensitive fields.

Do these security issues shall conduct an implementer or an operator to
systematically make use of IPSec to secure exchanges between a PEP and a PDP
so that it becomes possible to provision sensitive security information
without having to defined ciphered fields in the PIBs for which no generic
mechanisms have currently been defined ?

If  IPSec is used to secure COPS-PR exchanges what would become the utility
of the integrity mechanisms defined within COPS and more especially when
used within COPS-PR ?

Additionally, the IPSec PIB which is currently in its definition phase,
allows to define IKE rules specifying pre-shared key as Ike proposal
authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with
presharedKey(1) as possible value]method but does not allow to provision
those secrets. This means that the provisioning of those secrets shall be
done by an other way and in that case advantages of COPS-PR in case of
pre-shared authentication becomes greatly reduced since this shall be
achieved by hand or using an other mechanism.

In a same way if L2TP or AAA PIBs were to be defined how secrets (and more
generally sensitive information) should be provisioned ? 
-In clear : not reasonable
-Ciphered : there is no generic mechanisms
-Protected by IPSec, SSL... : should work fine, but the RFC should precise
that usage of a particular client type, defining sensitive information MUST
make use of an external mechanisms in order to secure those sensitive
information..

To conclude it seams that we can have the two possible approaches in order
to allow the exchange of sensible security information between a PEP an a
PDP :
1-systematicaly make use of an underlying security layer (IPSec for
instance) to secure exchanges between PEP and PDP. In that case the COPS
integrity mechanism is no more necessary. This approach implies that the PEP
has to support a security communication layer which might not be the case in
all situation.
2-defines a generic COPS ciphering mechanism which allows to protect some
sensitive fields. Security is embedded in the COPS protocol and must be
supported.

If this issue was solved, could IPSP experts extend the PIB so that shared
secret can be exchanged or is the reason for which it is not currently
supported more fundamental ?

Thanks in advance for your answers and comments.

Pierrick Morand
france telecom R&D/DMI/SIR/IPI
Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email :pierrick.morand@francetelecom.com





From owner-rap@ops.ietf.org  Wed Jun 13 20:33:07 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03903
	for <rap-archive@lists.ietf.org>; Wed, 13 Jun 2001 20:33:06 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15AL4F-000G1W-00
	for rap-data@psg.com; Wed, 13 Jun 2001 17:32:59 -0700
Received: from hypnos.cps.intel.com ([192.198.165.17])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15AL4E-000G1I-00
	for rap@ops.ietf.org; Wed, 13 Jun 2001 17:32:58 -0700
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id AAB15084;
	Thu, 14 Jun 2001 00:32:39 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 14 Jun 2001 00:32:39 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <MLFTQLXV>; Wed, 13 Jun 2001 17:32:37 -0700
Message-ID: <10C8636AE359D4119118009027AE998704F39FB1@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'Moisand, Jerome'" <jmoisand@unispherenetworks.com>,
        "'IPSEC-POLICY (E-mail)'" <ipsec-policy@vpnc.org>,
        "'RAP (E-mail)'"
	 <rap@ops.ietf.org>
Subject: RE: COPS-PR security general  issues
Date: Wed, 13 Jun 2001 17:32:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

The basic integrity mechanisms of the COPS protocol are required to be
implemented, thus ensuring they will be universally available... but are
optionally used. So this means other security mechanisms can be used instead
of or to augment the integrity object. For privately exchanging information
using COPS, TLS/SSL is the preferred security mechanism since COPS already
runs over TCP. Specific client-types can be defined that *require* a
specific additional security mechanism must be used, such as TLS. This is
done by simply stating as much in the security considerations section of the
corresponding document.

Given TLS, do you see any reason to implement per-attribute security via
Diffie-Hellman exchanges or some other mechanism? TLS seems more than
sufficient for COPS messaging given the persistent TCP connection & single
master control.

-Dave

> -----Original Message-----
> From: Moisand, Jerome [mailto:jmoisand@unispherenetworks.com]
> Sent: Wednesday, June 13, 2001 1:54 PM
> To: 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)'
> Subject: RE: COPS-PR security general issues
> 
> 
> 
> Sorry if it's a duplicate, sounds that I got filtered first 
> time I sent this
> e-mail.
> 
> Tx
> Jerome
> 
> -----Original Message-----
> From: Moisand, Jerome 
> Sent: Wednesday, June 13, 2001 11:19 AM
> To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail); 
> RAP (E-mail)
> Subject: RE: COPS-PR security general issues
> 
> 
> 
> I support the concern described by the e-mail quoted below, 
> which resonates
> quite well with what I heard from multiple service providers during
> COPS-related discussions.
> 
> I would suggest that the topic is discussed during the next 
> IETF meeting in
> the context of the "rap" group since the point is essentially 
> to secure the
> COPS/COPS-PR interactions, irrespective of the type of policies being
> managed.
> 
> In this context, among other alternatives, I would also 
> suggest to discuss
> the following internet-draft:
> http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt
> 
> Tx
> Jerome
> 
> =========================================== 
> Jerome P. Moisand 
> Senior Product Manager 
> Unisphere Networks 
> mailto:jmoisand@UnisphereNetworks.com 
> 
> 
> 
> 
> -----Original Message-----
> From: MORAND Pierrick FTRD/DMI/CAE
> [mailto:pierrick.morand@rd.francetelecom.fr]
> Sent: Thursday, May 31, 2001 8:08 AM
> To: IPSEC-POLICY (E-mail); RAP (E-mail)
> Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE
> Subject: COPS-PR security general issues
> 
> 
> We are currently working on the general theme of provisioning. We are
> considering COPS-PR with attention and would bring to the 
> attention of RAP
> and IPSP experts the following remarks and questions with our 
> apologizes if
> these issues have already been debated.
> 
> In a general way, COPS-PR has been designed to provision configuration
> policies for various functional domains such as IPSec, L2TP, 
> MPLS, AAA,
> Routing, TE ....
> 
> Considering for instance, IPSec, AAA and L2TP, provisioning of those
> functions leads to exchange with the equipment sensitive 
> information such as
> shared secrets (L2TP-Tunnel-password, users password, radius 
> secret and so
> on).
> 
> Within COPS there is an optional security mechanisms, which 
> only guarantees
> the integrity of the COPS messages. There is no general 
> mechanisms allowing
> to cipher some particular sensitive fields.
> 
> Do these security issues shall conduct an implementer or an 
> operator to
> systematically make use of IPSec to secure exchanges between 
> a PEP and a PDP
> so that it becomes possible to provision sensitive security 
> information
> without having to defined ciphered fields in the PIBs for 
> which no generic
> mechanisms have currently been defined ?
> 
> If  IPSec is used to secure COPS-PR exchanges what would 
> become the utility
> of the integrity mechanisms defined within COPS and more 
> especially when
> used within COPS-PR ?
> 
> Additionally, the IPSec PIB which is currently in its 
> definition phase,
> allows to define IKE rules specifying pre-shared key as Ike proposal
> authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with
> presharedKey(1) as possible value]method but does not allow 
> to provision
> those secrets. This means that the provisioning of those 
> secrets shall be
> done by an other way and in that case advantages of COPS-PR in case of
> pre-shared authentication becomes greatly reduced since this shall be
> achieved by hand or using an other mechanism.
> 
> In a same way if L2TP or AAA PIBs were to be defined how 
> secrets (and more
> generally sensitive information) should be provisioned ? 
> -In clear : not reasonable
> -Ciphered : there is no generic mechanisms
> -Protected by IPSec, SSL... : should work fine, but the RFC 
> should precise
> that usage of a particular client type, defining sensitive 
> information MUST
> make use of an external mechanisms in order to secure those sensitive
> information..
> 
> To conclude it seams that we can have the two possible 
> approaches in order
> to allow the exchange of sensible security information 
> between a PEP an a
> PDP :
> 1-systematicaly make use of an underlying security layer (IPSec for
> instance) to secure exchanges between PEP and PDP. In that 
> case the COPS
> integrity mechanism is no more necessary. This approach 
> implies that the PEP
> has to support a security communication layer which might not 
> be the case in
> all situation.
> 2-defines a generic COPS ciphering mechanism which allows to 
> protect some
> sensitive fields. Security is embedded in the COPS protocol 
> and must be
> supported.
> 
> If this issue was solved, could IPSP experts extend the PIB 
> so that shared
> secret can be exchanged or is the reason for which it is not currently
> supported more fundamental ?
> 
> Thanks in advance for your answers and comments.
> 
> Pierrick Morand
> france telecom R&D/DMI/SIR/IPI
> Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
> Email :pierrick.morand@francetelecom.com
> 
> 
> 
> 




From owner-rap@ops.ietf.org  Thu Jun 14 01:34:37 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10031
	for <rap-archive@lists.ietf.org>; Thu, 14 Jun 2001 01:34:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15APki-000JV1-00
	for rap-data@psg.com; Wed, 13 Jun 2001 22:33:08 -0700
Received: from [203.197.249.146] (helo=indica.wipsys.stph.net)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15APke-000JUi-00
	for rap@ops.ietf.org; Wed, 13 Jun 2001 22:33:06 -0700
Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24])
	by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id LAA19244
	for <rap@ops.ietf.org>; Thu, 14 Jun 2001 11:03:57 +0530 (IST)
Received: from kapoor ([192.168.143.50]) by
          vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with
          SMTP id GEWNBN00.NLC for <rap@ops.ietf.org>; Thu, 14 Jun 2001
          11:01:00 +0530 
Message-ID: <00a501c0f493$be706260$328fa8c0@wipsys.stph.net>
From: "Saurabh kapoor" <saurabh.kapoor@wipro.com>
To: "'RAP (E-mail)'" <rap@ops.ietf.org>
References: <9DCB6C9DC7C3D311B835009027DE069F03533A5D@mailhost2.unispherenetworks.com>
Subject: COPS-PR Clarifications 
Date: Thu, 14 Jun 2001 11:04:55 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

We would Like to have a few clarifications regarding the flow of
Configuration request in the COPS PR.
While Sending a configuration request the PEP sends the PDP a Client SI
object containing  <PRID> <EPD> pair.

==> What does PRID stand for? is it the OID of the individual table (for eg
OID of Support Table in FrameWork PIB) or is it the OID of an individual
attribute present with in the table.

==> Does EPD contain the entire table data or an individual attribute value.
If it is Table data(i.e. all attribute values), then with single PRID of
table, how do we fill the individual attributes.Is it the sequential flow we
need to follow in filling the attribute values??

==> One more clarification required is how PIB is constructed at PDP
side..i.e how do we map the OID's to respective attribute of the PIB ( Could
be DiffServ ).

Regards,
Saurabh Kapoor
----------------------------------------------------------------------------
----------
The opinions expressed here are my personal opinions
and not necessarily those of WIPRO Technologies.
----------------------------------------------------------------------------
----------







From owner-rap@ops.ietf.org  Thu Jun 14 09:23:04 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28326
	for <rap-archive@lists.ietf.org>; Thu, 14 Jun 2001 09:23:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15AX5P-000PJv-00
	for rap-data@psg.com; Thu, 14 Jun 2001 06:22:59 -0700
Received: from [65.194.140.138] (helo=email2.it.west.unispherenetworks.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15AX5O-000PJV-00
	for rap@ops.ietf.org; Thu, 14 Jun 2001 06:22:58 -0700
Received: by mailhost2.unispherenetworks.com with Internet Mail Service (5.5.2653.19)
	id <MS66L5NQ>; Thu, 14 Jun 2001 09:22:27 -0400
Message-ID: <9DCB6C9DC7C3D311B835009027DE069F03533A78@mailhost2.unispherenetworks.com>
From: "Moisand, Jerome" <jmoisand@unispherenetworks.com>
To: "'IPSEC-POLICY (E-mail)'" <ipsec-policy@vpnc.org>,
        "'RAP (E-mail)'"
	 <rap@ops.ietf.org>
Subject: RE: COPS-PR security general  issues
Date: Thu, 14 Jun 2001 09:20:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk


Personally, I also have sympathy for the "simple is beautiful" COPS/TLS
solution. But didn't want to jump to conclusions too fast.

So I was simply suggesting that it's probably worth going through a good
open discussion on this security topic, try to reach a good consensus and
then possibly enhance/clarify the existing COPS-related material with
specific recommendations.

Makes sense?

Jerome

-----Original Message-----
From: Durham, David [mailto:david.durham@intel.com]
Sent: Wednesday, June 13, 2001 8:32 PM
To: Moisand, Jerome; 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)'
Subject: RE: COPS-PR security general issues


The basic integrity mechanisms of the COPS protocol are required to be
implemented, thus ensuring they will be universally available... but are
optionally used. So this means other security mechanisms can be used instead
of or to augment the integrity object. For privately exchanging information
using COPS, TLS/SSL is the preferred security mechanism since COPS already
runs over TCP. Specific client-types can be defined that *require* a
specific additional security mechanism must be used, such as TLS. This is
done by simply stating as much in the security considerations section of the
corresponding document.

Given TLS, do you see any reason to implement per-attribute security via
Diffie-Hellman exchanges or some other mechanism? TLS seems more than
sufficient for COPS messaging given the persistent TCP connection & single
master control.

-Dave

> -----Original Message-----
> From: Moisand, Jerome [mailto:jmoisand@unispherenetworks.com]
> Sent: Wednesday, June 13, 2001 1:54 PM
> To: 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)'
> Subject: RE: COPS-PR security general issues
> 
> 
> 
> Sorry if it's a duplicate, sounds that I got filtered first 
> time I sent this
> e-mail.
> 
> Tx
> Jerome
> 
> -----Original Message-----
> From: Moisand, Jerome 
> Sent: Wednesday, June 13, 2001 11:19 AM
> To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail); 
> RAP (E-mail)
> Subject: RE: COPS-PR security general issues
> 
> 
> 
> I support the concern described by the e-mail quoted below, 
> which resonates
> quite well with what I heard from multiple service providers during
> COPS-related discussions.
> 
> I would suggest that the topic is discussed during the next 
> IETF meeting in
> the context of the "rap" group since the point is essentially 
> to secure the
> COPS/COPS-PR interactions, irrespective of the type of policies being
> managed.
> 
> In this context, among other alternatives, I would also 
> suggest to discuss
> the following internet-draft:
> http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt
> 
> Tx
> Jerome
> 
> =========================================== 
> Jerome P. Moisand 
> Senior Product Manager 
> Unisphere Networks 
> mailto:jmoisand@UnisphereNetworks.com 
> 
> 
> 
> 
> -----Original Message-----
> From: MORAND Pierrick FTRD/DMI/CAE
> [mailto:pierrick.morand@rd.francetelecom.fr]
> Sent: Thursday, May 31, 2001 8:08 AM
> To: IPSEC-POLICY (E-mail); RAP (E-mail)
> Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE
> Subject: COPS-PR security general issues
> 
> 
> We are currently working on the general theme of provisioning. We are
> considering COPS-PR with attention and would bring to the 
> attention of RAP
> and IPSP experts the following remarks and questions with our 
> apologizes if
> these issues have already been debated.
> 
> In a general way, COPS-PR has been designed to provision configuration
> policies for various functional domains such as IPSec, L2TP, 
> MPLS, AAA,
> Routing, TE ....
> 
> Considering for instance, IPSec, AAA and L2TP, provisioning of those
> functions leads to exchange with the equipment sensitive 
> information such as
> shared secrets (L2TP-Tunnel-password, users password, radius 
> secret and so
> on).
> 
> Within COPS there is an optional security mechanisms, which 
> only guarantees
> the integrity of the COPS messages. There is no general 
> mechanisms allowing
> to cipher some particular sensitive fields.
> 
> Do these security issues shall conduct an implementer or an 
> operator to
> systematically make use of IPSec to secure exchanges between 
> a PEP and a PDP
> so that it becomes possible to provision sensitive security 
> information
> without having to defined ciphered fields in the PIBs for 
> which no generic
> mechanisms have currently been defined ?
> 
> If  IPSec is used to secure COPS-PR exchanges what would 
> become the utility
> of the integrity mechanisms defined within COPS and more 
> especially when
> used within COPS-PR ?
> 
> Additionally, the IPSec PIB which is currently in its 
> definition phase,
> allows to define IKE rules specifying pre-shared key as Ike proposal
> authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with
> presharedKey(1) as possible value]method but does not allow 
> to provision
> those secrets. This means that the provisioning of those 
> secrets shall be
> done by an other way and in that case advantages of COPS-PR in case of
> pre-shared authentication becomes greatly reduced since this shall be
> achieved by hand or using an other mechanism.
> 
> In a same way if L2TP or AAA PIBs were to be defined how 
> secrets (and more
> generally sensitive information) should be provisioned ? 
> -In clear : not reasonable
> -Ciphered : there is no generic mechanisms
> -Protected by IPSec, SSL... : should work fine, but the RFC 
> should precise
> that usage of a particular client type, defining sensitive 
> information MUST
> make use of an external mechanisms in order to secure those sensitive
> information..
> 
> To conclude it seams that we can have the two possible 
> approaches in order
> to allow the exchange of sensible security information 
> between a PEP an a
> PDP :
> 1-systematicaly make use of an underlying security layer (IPSec for
> instance) to secure exchanges between PEP and PDP. In that 
> case the COPS
> integrity mechanism is no more necessary. This approach 
> implies that the PEP
> has to support a security communication layer which might not 
> be the case in
> all situation.
> 2-defines a generic COPS ciphering mechanism which allows to 
> protect some
> sensitive fields. Security is embedded in the COPS protocol 
> and must be
> supported.
> 
> If this issue was solved, could IPSP experts extend the PIB 
> so that shared
> secret can be exchanged or is the reason for which it is not currently
> supported more fundamental ?
> 
> Thanks in advance for your answers and comments.
> 
> Pierrick Morand
> france telecom R&D/DMI/SIR/IPI
> Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
> Email :pierrick.morand@francetelecom.com
> 
> 
> 
> 



From owner-rap@ops.ietf.org  Thu Jun 14 09:58:22 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29591
	for <rap-archive@lists.ietf.org>; Thu, 14 Jun 2001 09:58:20 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15AXdj-000PmE-00
	for rap-data@psg.com; Thu, 14 Jun 2001 06:58:27 -0700
Received: from dgesmtp02.wcom.com ([199.249.16.17])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15AXdi-000PlZ-00
	for rap@ops.ietf.org; Thu, 14 Jun 2001 06:58:26 -0700
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GEX00DGGASC6R@firewall.mcit.com> for rap@ops.ietf.org; Thu,
 14 Jun 2001 13:57:48 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GEX00F01ASB6D@pmismtp01.wcomnet.com>;
 Thu, 14 Jun 2001 13:57:47 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GEX00ACGARWD3@pmismtp01.wcomnet.com>; Thu,
 14 Jun 2001 13:57:32 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id <K25G9AGN>; Thu, 14 Jun 2001 13:57:32 +0000
Content-return: allowed
Date: Thu, 14 Jun 2001 13:57:29 +0000
From: "Iliff, Tina" <Tina.Iliff@WCOM.Com>
Subject: RE: COPS-PR Clarifications
To: "'Saurabh kapoor'" <saurabh.kapoor@wipro.com>,
        "'RAP (E-mail)'" <rap@ops.ietf.org>
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5968@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Saurabh,

Answers to your questions are inline.

Tina Iliff


 -----Original Message-----
From: 	Saurabh kapoor [mailto:saurabh.kapoor@wipro.com] 
Sent:	Thursday, June 14, 2001 12:35 AM
To:	'RAP (E-mail)'
Subject:	COPS-PR Clarifications

We would Like to have a few clarifications regarding the flow of
Configuration request in the COPS PR.
While Sending a configuration request the PEP sends the PDP a Client SI
object containing  <PRID> <EPD> pair.

==> What does PRID stand for? is it the OID of the individual table (for eg
OID of Support Table in FrameWork PIB) or is it the OID of an individual
attribute present with in the table.
It stands for Policy Rule Instance Identifier.  In the case of the <PRID,
EPD> binding it is the OID of the PRC (individual table) entry + InstanceId
subidentifier.
==> Does EPD contain the entire table data or an individual attribute value.
If it is Table data(i.e. all attribute values), then with single PRID of
table, how do we fill the individual attributes.Is it the sequential flow we
need to follow in filling the attribute values??
The EPD contains a complete PRC instance; i.e. a complete table record.  It
contains values of each of the attributes.  

==> One more clarification required is how PIB is constructed at PDP
side..i.e how do we map the OID's to respective attribute of the PIB ( Could
be DiffServ ).
I do not know if I understand this question completely.  The PDP, through
some means which is implementation dependant, will have knowledge of both
the framework PIB and DiffServ PIB OIDs and Entry SEQUENCEs and will process
the NamedClientSI contents based on this knowledge.

Regards,
Saurabh Kapoor
----------------------------------------------------------------------------
----------
The opinions expressed here are my personal opinions
and not necessarily those of WIPRO Technologies.
----------------------------------------------------------------------------
----------







From owner-rap@ops.ietf.org  Thu Jun 14 13:17:33 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04491
	for <rap-archive@lists.ietf.org>; Thu, 14 Jun 2001 13:17:33 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15AakD-000A4j-00
	for rap-data@psg.com; Thu, 14 Jun 2001 10:17:21 -0700
Received: from yonge.cs.toronto.edu ([128.100.1.8] ident=root)
	by psg.com with smtp (Exim 3.16 #1)
	id 15AakC-000A4b-00
	for rap@ops.ietf.org; Thu, 14 Jun 2001 10:17:20 -0700
Received: from jane.cs.toronto.edu ([128.100.2.31]) by yonge.cs.toronto.edu with SMTP id <33974-12058>; Thu, 14 Jun 2001 13:17:12 -0400
Received: from gardiner.cs.toronto.edu by jane.cs.toronto.edu id <453137-28229>; Thu, 14 Jun 2001 13:17:01 -0400
Date: 	Thu, 14 Jun 2001 13:16:57 -0400
From: Andreas Polyrakis <apolyr@cs.toronto.edu>
X-Sender: apolyr@gardiner.cs
To: rap@ops.ietf.org
cc: Andreas Polyrakis <apolyr@cs.toronto.edu>,
        Raouf Boutaba <rboutaba@bbcr.uwaterloo.ca>
Subject: New draft
Message-ID: <Pine.GSO.4.21.0106141315380.18361-100000@gardiner.cs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rap@ops.ietf.org
Precedence: bulk



Hello,

I would like to draw your attention to the following draft:

COPS-PR with Meta-Policy Support
http://www.ietf.org/internet-drafts/draft-boutaba-copsprmp-00.txt

This draft defines an extention of the COPS-PR protocol that
allows the PDP to communicate "meta-policies" to the PEP.
Meta-policies are policies that control the content of the PIB of the PEP,
always according to the PDP directions. Hence, the PIB can be
controlled by the PDP either directly (as described by COPS-PR)
or indirectly, through meta-policies. However, by using
meta-policies, the PDP is able to push more policing functionality towards
the PEP, overcome the rigidity of its PIB and make the model 
more distributed, scalable and fault-tolerant.

Any feedback on our work would be greatly appreciated.

Regards,

Raouf Boutaba 
Andreas Polyrakis 







From owner-rap@ops.ietf.org  Fri Jun 15 12:41:50 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15232
	for <rap-archive@lists.ietf.org>; Fri, 15 Jun 2001 12:41:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15AwfA-0005yV-00
	for rap-data@psg.com; Fri, 15 Jun 2001 09:41:36 -0700
Received: from dgesmtp01.wcom.com ([199.249.16.16])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15Awf9-0005xt-00
	for rap@ops.ietf.org; Fri, 15 Jun 2001 09:41:35 -0700
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GEZ00305CZOSC@firewall.mcit.com> for rap@ops.ietf.org; Fri,
 15 Jun 2001 16:40:36 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GEZ00901CZLSI@pmismtp01.wcomnet.com> for
 rap@ops.ietf.org; Fri, 15 Jun 2001 16:40:35 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GEZ004FFCYPQY@pmismtp01.wcomnet.com> for rap@ops.ietf.org;
 Fri, 15 Jun 2001 16:40:01 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id <K25G0K2W>; Fri, 15 Jun 2001 16:40:01 +0000
Content-return: allowed
Date: Fri, 15 Jun 2001 16:40:00 +0000
From: "Iliff, Tina" <Tina.Iliff@WCOM.Com>
Subject: Framework PIB:  frwkPibIncarnation Prid
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5982@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_bQU/mZ6c9K5/qSN5GT0jpw)"
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.

--Boundary_(ID_bQU/mZ6c9K5/qSN5GT0jpw)
Content-type: text/plain; charset=ISO-8859-1

Hi,

I need to verify that my interpretation of the frwkPibIncarnation PRC is
correct.  Namely, does the PRID attribute value have to be unique across
contexts per PDP?  For instance, can one Request-State have an
frwkPibIncarnation instance with a PRID value of 3 / Active value of True
and another have an instance with a PRID value of 3 / Active value of False.
If each Request-State has its own name space which does not overlap with any
other Request-State, then the uniqueness of the Prid value should not
matter.  Please clarify if there is a requirement for the Prid values to be
unique across contexts per PDP and explain the reason.

Regards,

Tina Iliff

  

--Boundary_(ID_bQU/mZ6c9K5/qSN5GT0jpw)
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.2654.59">
<TITLE>Framework PIB:  frwkPibIncarnation Prid</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" FACE=3D"Arial">Hi,</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" FACE=3D"Arial">I need to verify =
that my interpretation</FONT> <FONT COLOR=3D"#000000" FACE=3D"Arial">of =
the frwkPibIncarnation PRC is correct.&nbsp; Namely, does the PRID =
attribute value have to be unique across contexts per PDP</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial">?&nbsp;</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">For instance</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial">,</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">can</FONT> <FONT COLOR=3D"#000000" FACE=3D"Arial">one =
Request-State have</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">an</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> =
frwkPibIncarnation instance with a PRID</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">value of 3</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">/</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> Active =
value of True</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> and another =
have an instance with a PRID value of 3</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">/</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> Active =
value of False</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial">.&nbsp; If =
each Request-State has its own name space which does not overlap</FONT> =
<FONT COLOR=3D"#000000" FACE=3D"Arial">with</FONT> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">any other Request-State</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial">, then the uniqueness of the Prid =
value should not matter.&nbsp;</FONT> <FONT COLOR=3D"#000000" =
FACE=3D"Arial">Please clarify if there is a requirement for the =
Prid</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> values</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> to be unique</FONT> <FONT =
COLOR=3D"#000000" FACE=3D"Arial">across contexts per PDP and explain =
the reason.</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" =
FACE=3D"Arial">Regards,</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#800080" FACE=3D"Monotype Corsiva">Tina =
Iliff</FONT></P>

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

</BODY>
</HTML>

--Boundary_(ID_bQU/mZ6c9K5/qSN5GT0jpw)--



From owner-rap@ops.ietf.org  Fri Jun 15 13:07:06 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16824
	for <rap-archive@lists.ietf.org>; Fri, 15 Jun 2001 13:07:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15Ax47-00096j-00
	for rap-data@psg.com; Fri, 15 Jun 2001 10:07:23 -0700
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15Ax45-00096c-00
	for rap@ops.ietf.org; Fri, 15 Jun 2001 10:07:21 -0700
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id RAA04127;
	Fri, 15 Jun 2001 17:07:18 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 15 Jun 2001 17:07:18 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <MK76TCL9>; Fri, 15 Jun 2001 10:07:17 -0700
Message-ID: <75F7304BB41CD411B06600A0C98414FC015B7329@ORSMSX54>
From: "Sahita, Ravi" <ravi.sahita@intel.com>
To: "'Iliff, Tina'" <Tina.Iliff@WCOM.Com>,
        "'rap@ops.ietf.org'"
	 <rap@ops.ietf.org>
Subject: RE: Framework PIB:  frwkPibIncarnation Prid
Date: Fri, 15 Jun 2001 10:07:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F5BD.9F9A2F80"
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_01C0F5BD.9F9A2F80
Content-Type: text/plain;
	charset="iso-8859-1"

Tina,
 
You're right, the uniqueness of the InstanceId in the Incarnation PRC does
not matter across contexts. 
 
Ravi
 
-----Original Message-----
From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
Sent: Friday, June 15, 2001 9:40 AM
To: 'rap@ops.ietf.org'
Subject: Framework PIB: frwkPibIncarnation Prid



Hi,

I need to verify that my interpretation of the frwkPibIncarnation PRC is
correct.  Namely, does the PRID attribute value have to be unique across
contexts per PDP?  For instance, can one Request-State have an
frwkPibIncarnation instance with a PRID value of 3 / Active value of True
and another have an instance with a PRID value of 3 / Active value of False.
If each Request-State has its own name space which does not overlap with any
other Request-State, then the uniqueness of the Prid value should not
matter.  Please clarify if there is a requirement for the Prid values to be
unique across contexts per PDP and explain the reason.

Regards,

Tina Iliff

  


------_=_NextPart_001_01C0F5BD.9F9A2F80
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<TITLE>Framework PIB: frwkPibIncarnation Prid</TITLE>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=617080817-15062001><FONT color=#0000ff face=Arial 
size=2>Tina,</FONT></SPAN></DIV>
<DIV><SPAN class=617080817-15062001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=617080817-15062001><FONT color=#0000ff face=Arial size=2>You're 
right, the uniqueness of the InstanceId in the Incarnation PRC does not matter 
across contexts. </FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=617080817-15062001><FONT color=#0000ff face=Arial 
size=2>Ravi</FONT></SPAN></DIV>
<DIV><SPAN class=617080817-15062001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader DIR = LTR><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Iliff, Tina 
[mailto:Tina.Iliff@WCOM.Com]<BR><B>Sent:</B> Friday, June 15, 2001 9:40 
AM<BR><B>To:</B> 'rap@ops.ietf.org'<BR><B>Subject:</B> Framework PIB: 
frwkPibIncarnation Prid<BR><BR></FONT></DIV>
<P align=left><FONT color=#000000 face=Arial>Hi,</FONT></P>
<P align=left><FONT color=#000000 face=Arial>I need to verify that my 
interpretation</FONT> <FONT color=#000000 face=Arial>of the frwkPibIncarnation 
PRC is correct.&nbsp; Namely, does the PRID attribute value have to be unique 
across contexts per PDP</FONT><FONT color=#000000 face=Arial>?&nbsp;</FONT> 
<FONT color=#000000 face=Arial>For instance</FONT><FONT color=#000000 
face=Arial>,</FONT> <FONT color=#000000 face=Arial>can</FONT> <FONT 
color=#000000 face=Arial>one Request-State have</FONT> <FONT color=#000000 
face=Arial>an</FONT><FONT color=#000000 face=Arial> frwkPibIncarnation instance 
with a PRID</FONT> <FONT color=#000000 face=Arial>value of 3</FONT> <FONT 
color=#000000 face=Arial>/</FONT><FONT color=#000000 face=Arial> Active value of 
True</FONT><FONT color=#000000 face=Arial> and another have an instance with a 
PRID value of 3</FONT> <FONT color=#000000 face=Arial>/</FONT><FONT 
color=#000000 face=Arial> Active value of False</FONT><FONT color=#000000 
face=Arial>.&nbsp; If each Request-State has its own name space which does not 
overlap</FONT> <FONT color=#000000 face=Arial>with</FONT> <FONT color=#000000 
face=Arial>any other Request-State</FONT><FONT color=#000000 face=Arial>, then 
the uniqueness of the Prid value should not matter.&nbsp;</FONT> <FONT 
color=#000000 face=Arial>Please clarify if there is a requirement for the 
Prid</FONT><FONT color=#000000 face=Arial> values</FONT><FONT color=#000000 
face=Arial> to be unique</FONT> <FONT color=#000000 face=Arial>across contexts 
per PDP and explain the reason.</FONT></P>
<P align=left><FONT color=#000000 face=Arial>Regards,</FONT></P>
<P align=left><FONT color=#800080 face="Monotype Corsiva">Tina Iliff</FONT></P>
<P align=left><FONT color=#000000 face=Arial>&nbsp; </FONT></P></BODY></HTML>

------_=_NextPart_001_01C0F5BD.9F9A2F80--




From owner-rap@ops.ietf.org  Mon Jun 18 09:18:16 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06651
	for <rap-archive@lists.ietf.org>; Mon, 18 Jun 2001 09:18:15 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15Bytw-000KSW-00
	for rap-data@psg.com; Mon, 18 Jun 2001 06:17:08 -0700
Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15Bytv-000KRt-00
	for rap@ops.ietf.org; Mon, 18 Jun 2001 06:17:07 -0700
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP id 7EA5418B8
	for <rap@ops.ietf.org>; Mon, 18 Jun 2001 15:17:04 +0200 (MET DST)
Message-ID: <3B2E001B.B46FF664@yahoo.com>
Date: Mon, 18 Jun 2001 15:20:27 +0200
From: Nguyen Thi Mai Trang <maitrangqos@yahoo.com>
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rap@ops.ietf.org
Subject: can a PDP be a PEP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I apologize to you for the second mail about these questions. I have
posted these two questions, but I received no reply :-((

1. Can a PDP of a client-type be a PEP of another client-type? For
exemple, in
the same machine of  the COPS-PR PDP, I have a SLA-PEP who occupies the
SLA establishment with another domain.

2. In the same client-type, can a PDP be a PEP of another PDP? For
example, in
the same machine of the SLA-PDP who manages all SLAs of  domain A, I
have a SLA-PEP who occupies the SLA establishment with domain B.

Excuse-me if there were some incorrectnesses in the previous message.
All responses are appreciated. It's really my problem.

Thank you in advance.
Mai Trang





From owner-rap@ops.ietf.org  Mon Jun 18 10:10:00 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08341
	for <rap-archive@lists.ietf.org>; Mon, 18 Jun 2001 10:09:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15BzjQ-000Lbw-00
	for rap-data@psg.com; Mon, 18 Jun 2001 07:10:20 -0700
Received: from mail.san.yahoo.com ([209.132.1.30])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15BzjQ-000Lbb-00
	for rap@ops.ietf.org; Mon, 18 Jun 2001 07:10:20 -0700
Received: from ntearb4s22b666 (212.179.158.189) by mail.san.yahoo.com (5.5.032)
        id 3B2918FF0005829E; Mon, 18 Jun 2001 07:09:41 -0700
From: "Ron Cohen" <ronc@ntear.com>
To: "Nguyen Thi Mai Trang" <maitrangqos@yahoo.com>, <rap@ops.ietf.org>
Subject: RE: can a PDP be a PEP
Date: Mon, 18 Jun 2001 16:15:43 +0200
Message-ID: <NCEDLGJMPCPHKGNKCIKMGEAICDAA.ronc@ntear.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3B2E001B.B46FF664@yahoo.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mai Trang,

The answers are both Yes. There is nothing in COPS that prevents you from
doing so. Whether this is the right architecture or not is a different
matter.

Ron


> -----Original Message-----
> From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On
> Behalf Of Nguyen Thi Mai Trang
> Sent: Monday, June 18, 2001 3:20 PM
> To: rap@ops.ietf.org
> Subject: can a PDP be a PEP
>
>
> I apologize to you for the second mail about these questions. I have
> posted these two questions, but I received no reply :-((
>
> 1. Can a PDP of a client-type be a PEP of another client-type? For
> exemple, in
> the same machine of  the COPS-PR PDP, I have a SLA-PEP who occupies the
> SLA establishment with another domain.
>
> 2. In the same client-type, can a PDP be a PEP of another PDP? For
> example, in
> the same machine of the SLA-PDP who manages all SLAs of  domain A, I
> have a SLA-PEP who occupies the SLA establishment with domain B.
>
> Excuse-me if there were some incorrectnesses in the previous message.
> All responses are appreciated. It's really my problem.
>
> Thank you in advance.
> Mai Trang
>
>
>




From owner-rap@ops.ietf.org  Mon Jun 18 10:33:44 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08877
	for <rap-archive@lists.ietf.org>; Mon, 18 Jun 2001 10:33:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15C05m-000MAJ-00
	for rap-data@psg.com; Mon, 18 Jun 2001 07:33:26 -0700
Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15C05l-000MAC-00
	for rap@ops.ietf.org; Mon, 18 Jun 2001 07:33:25 -0700
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP
	id A69C818BB; Mon, 18 Jun 2001 16:33:22 +0200 (MET DST)
Message-ID: <3B2E11FD.1C752C64@yahoo.com>
Date: Mon, 18 Jun 2001 16:36:45 +0200
From: Nguyen Thi Mai Trang <maitrangqos@yahoo.com>
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Cohen <ronc@ntear.com>
Cc: rap@ops.ietf.org
Subject: Re: can a PDP be a PEP
References: <NCEDLGJMPCPHKGNKCIKMGEAICDAA.ronc@ntear.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ron,
I would greatly appreciate your response.

It's really that my problem is whether this is the right architecture or not
in the context of Policy Based Management Framework and Architecture.

Best regards,
Mai Trang

Ron Cohen wrote:

> Mai Trang,
>
> The answers are both Yes. There is nothing in COPS that prevents you from
> doing so. Whether this is the right architecture or not is a different
> matter.
>
> Ron
>
> > -----Original Message-----
> > From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On
> > Behalf Of Nguyen Thi Mai Trang
> > Sent: Monday, June 18, 2001 3:20 PM
> > To: rap@ops.ietf.org
> > Subject: can a PDP be a PEP
> >
> >
> > I apologize to you for the second mail about these questions. I have
> > posted these two questions, but I received no reply :-((
> >
> > 1. Can a PDP of a client-type be a PEP of another client-type? For
> > exemple, in
> > the same machine of  the COPS-PR PDP, I have a SLA-PEP who occupies the
> > SLA establishment with another domain.
> >
> > 2. In the same client-type, can a PDP be a PEP of another PDP? For
> > example, in
> > the same machine of the SLA-PDP who manages all SLAs of  domain A, I
> > have a SLA-PEP who occupies the SLA establishment with domain B.
> >
> > Excuse-me if there were some incorrectnesses in the previous message.
> > All responses are appreciated. It's really my problem.
> >
> > Thank you in advance.
> > Mai Trang
> >
> >
> >

--
----------------------------------------------------
Nguyen Thi Mai Trang
Ecole Nationale Superieure des Telecommunications
Dept. INFRES - Bur. C234-4
46 Rue Barrault - 75013 Paris
Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19
email : trnguyen@enst.fr





From owner-rap@ops.ietf.org  Mon Jun 18 11:06:29 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09756
	for <rap-archive@lists.ietf.org>; Mon, 18 Jun 2001 11:06:27 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15C0c9-000Mz1-00
	for rap-data@psg.com; Mon, 18 Jun 2001 08:06:53 -0700
Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15C0c7-000Myu-00
	for rap@ops.ietf.org; Mon, 18 Jun 2001 08:06:53 -0700
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP
	id B0B2818BB; Mon, 18 Jun 2001 17:06:49 +0200 (MET DST)
Message-ID: <3B2E19D4.C1556DBC@yahoo.com>
Date: Mon, 18 Jun 2001 17:10:12 +0200
From: Nguyen Thi Mai Trang <maitrangqos@yahoo.com>
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Cohen <ronc@ntear.com>
Cc: Nguyen Thi Mai Trang <maitrangqos@yahoo.com>, rap@ops.ietf.org
Subject: Re: can a PDP be a PEP
References: <NCEDLGJMPCPHKGNKCIKMGEAICDAA.ronc@ntear.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Ron,

Thank you for the reply.

Sorry that I did not make it clear in the question. I was, indeed, not sure
whether this (the model in these questions) is the right architecture or not
in the context of Policy Based Management Framework and Architecture.

I'm looking forward to your reply.

Mai Trang

Ron Cohen wrote:

> Mai Trang,
>
> The answers are both Yes. There is nothing in COPS that prevents you from
> doing so. Whether this is the right architecture or not is a different
> matter.
>
> Ron
>
> > -----Original Message-----
> > From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On
> > Behalf Of Nguyen Thi Mai Trang
> > Sent: Monday, June 18, 2001 3:20 PM
> > To: rap@ops.ietf.org
> > Subject: can a PDP be a PEP
> >
> >
> > I apologize to you for the second mail about these questions. I have
> > posted these two questions, but I received no reply :-((
> >
> > 1. Can a PDP of a client-type be a PEP of another client-type? For
> > exemple, in
> > the same machine of  the COPS-PR PDP, I have a SLA-PEP who occupies the
> > SLA establishment with another domain.
> >
> > 2. In the same client-type, can a PDP be a PEP of another PDP? For
> > example, in
> > the same machine of the SLA-PDP who manages all SLAs of  domain A, I
> > have a SLA-PEP who occupies the SLA establishment with domain B.
> >
> > Excuse-me if there were some incorrectnesses in the previous message.
> > All responses are appreciated. It's really my problem.
> >
> > Thank you in advance.
> > Mai Trang
> >
> >
> >

--
----------------------------------------------------
Nguyen Thi Mai Trang
Ecole Nationale Superieure des Telecommunications
Dept. INFRES - Bur. C234-4
46 Rue Barrault - 75013 Paris
Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19
email : trnguyen@enst.fr





From owner-rap@ops.ietf.org  Mon Jun 18 11:36:44 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10476
	for <rap-archive@lists.ietf.org>; Mon, 18 Jun 2001 11:36:44 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15C15E-000Ni2-00
	for rap-data@psg.com; Mon, 18 Jun 2001 08:36:56 -0700
Received: from ztxmail05.ztx.compaq.com ([161.114.1.209])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15C15D-000NhR-00
	for rap@ops.ietf.org; Mon, 18 Jun 2001 08:36:55 -0700
Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345)
	id D6270484; Mon, 18 Jun 2001 10:36:24 -0500 (CDT)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 9D9BE1E4A
	for <rap@ops.ietf.org>; Mon, 18 Jun 2001 10:36:22 -0500 (CDT)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <LT3FMV3R>; Mon, 18 Jun 2001 17:36:21 +0200
Message-ID: <C1434589DE6ED411885900508BDF604D014B1A1C@vbeexc01.vbe.cpqcorp.net>
From: "Bouarich, Reda" <Reda.Bouarich@Compaq.com>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: PathErr and resvErr
Date: Mon, 18 Jun 2001 17:38:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hello all,
I have a little problem. I thought that the PathErr and the ResvErr were not
handled by the user but only by the PDP. Thus, I thought that if a defined
Path or Resv command fails , then its corresponding error messages is
released by the PDP as a DEC. 

But it seems that the user should also define the PathErr and ResvErr
commands, that means that a REQ could be a PathErr or a ResvErr!! Is it
true? 

Thanks for the help.

Regards,

Reda.



From owner-rap@ops.ietf.org  Tue Jun 19 14:12:35 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29386
	for <rap-archive@lists.ietf.org>; Tue, 19 Jun 2001 14:12:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15CPyz-000OVJ-00
	for rap-data@psg.com; Tue, 19 Jun 2001 11:12:09 -0700
Received: from mgw-dax1.ext.nokia.com ([63.78.179.216])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15CPyz-000OUu-00
	for rap@ops.ietf.org; Tue, 19 Jun 2001 11:12:09 -0700
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5JIC8821469
	for <rap@ops.ietf.org>; Tue, 19 Jun 2001 13:12:08 -0500 (CDT)
Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T543d37e95cac12f255079@davir02nok.americas.nokia.com> for <rap@ops.ietf.org>;
 Tue, 19 Jun 2001 13:12:07 -0500
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <NFQ3ALDJ>; Tue, 19 Jun 2001 13:12:07 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292BB1C@bseis01nok>
From: Man.M.Li@nokia.com
To: rap@ops.ietf.org
Subject: framework PIB - Device Capability, PRC support, limitation 
Date: Tue, 19 Jun 2001 13:12:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi,

For the Framework PIB,

- The Interface Capabilitites Set Table has a reference
"frwkIfCapSetCapability" pointing to "relevant capability tables in any
PIB". Does this mean that any PIB (e.g., Diffserv, security) MUST have
capability tables? 

- What's the difference between the Capability Set Table and the PRC support
table + Component limitation table? To me, they seem to be the same thing.
Take Diffserv PIB as an example, the ClassificationCapsSpec table is able to
specify that it has the ability to classify based on source address. But
cannot the same thing be said with a Framework PRC support table indicating
that for the filter table, only src address is supported? 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 



From owner-rap@ops.ietf.org  Wed Jun 20 13:22:46 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14905
	for <rap-archive@lists.ietf.org>; Wed, 20 Jun 2001 13:22:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15Clfd-000JnB-00
	for rap-data@psg.com; Wed, 20 Jun 2001 10:21:37 -0700
Received: from birch.ee.vt.edu ([128.173.88.34])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15Clfc-000Jn3-00
	for rap@ops.ietf.org; Wed, 20 Jun 2001 10:21:36 -0700
Received: from yew.ee.vt.edu (yew.ee.vt.edu [128.173.88.43])
	by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id NAA15733
	for <rap@ops.ietf.org>; Wed, 20 Jun 2001 13:21:35 -0400 (EDT)
Received: from localhost (kphanse@localhost)
	by yew.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id NAA14722
	for <rap@ops.ietf.org>; Wed, 20 Jun 2001 13:21:34 -0400 (EDT)
Date: Wed, 20 Jun 2001 13:21:34 -0400 (EDT)
From: Kaustubh Phanse <kphanse@ee.vt.edu>
To: rap@ops.ietf.org
Subject: Interaction between COPS-RSVP and COPS-PR
Message-ID: <Pine.GSO.3.96.1010620131906.14713A-100000@yew.ee.vt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rap@ops.ietf.org
Precedence: bulk


	Has any work been done (or is being done) involving interaction
between COPS-RSVP and COPS-PR?? Any IETF drafts/papers? Any pointers to
this are greatly appreciated.

Thank you
regards
Kaustubh
-----------------------------------------------------------------------------
 Kaustubh S. Phanse					  kphanse@ee.vt.edu
 PhD student				       http://www.ee.vt.edu/~kphanse
 Alexandria Research Institute
 Electrical & Computer Engineering Department		               
 Virginia Polytechnic Institute & State University 
-----------------------------------------------------------------------------




From owner-rap@ops.ietf.org  Thu Jun 21 12:22:03 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04857
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 12:22:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15D5NN-000E01-00
	for rap-data@psg.com; Thu, 21 Jun 2001 07:24:05 -0700
Received: from mel.alcatel.fr ([212.208.74.132])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15D5NL-000Dzv-00
	for rap@ops.ietf.org; Thu, 21 Jun 2001 07:24:04 -0700
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA18266;
        Thu, 21 Jun 2001 15:00:35 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA26596;
        Thu, 21 Jun 2001 16:23:23 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id QAA17915;
	Thu, 21 Jun 2001 16:23:36 +0200 (MET DST)
Received: from pc50062 ([188.9.248.194])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id QAA19749;
	Thu, 21 Jun 2001 16:23:40 +0200 (MET DST)
Message-ID: <00bd01c0fa5d$e80f8e50$c2f809bc@pc50062>
From: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
To: "Bouarich, Reda" <Reda.Bouarich@Compaq.com>
Cc: <rap@ops.ietf.org>
References: <C1434589DE6ED411885900508BDF604D014B1A1C@vbeexc01.vbe.cpqcorp.net>
Subject: Re: PathErr and resvErr
Date: Thu, 21 Jun 2001 16:24:39 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> But it seems that the user should also define the PathErr and ResvErr
> commands, 

Yes, if for example capacity admission control (local) failed.

> that means that a REQ could be a PathErr or a ResvErr!! Is it
> true? 

see the example in RFC2749 page 13-14






From owner-rap@ops.ietf.org  Thu Jun 21 12:29:01 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05218
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 12:29:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15D5WO-000EAb-00
	for rap-data@psg.com; Thu, 21 Jun 2001 07:33:24 -0700
Received: from mel.alcatel.fr ([212.208.74.132])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15D5WN-000EAO-00
	for rap@ops.ietf.org; Thu, 21 Jun 2001 07:33:24 -0700
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA22804
        for <rap@ops.ietf.org>; Thu, 21 Jun 2001 15:09:55 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA02873
        for <rap@ops.ietf.org>; Thu, 21 Jun 2001 16:32:43 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id QAA18468
	for <rap@ops.ietf.org>; Thu, 21 Jun 2001 16:32:52 +0200 (MET DST)
Received: from pc50062 ([188.9.248.194])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id QAA20755
	for <rap@ops.ietf.org>; Thu, 21 Jun 2001 16:32:57 +0200 (MET DST)
Message-ID: <00ed01c0fa5f$3402f4e0$c2f809bc@pc50062>
From: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
To: <rap@ops.ietf.org>
References: <Pine.GSO.3.96.1010620131906.14713A-100000@yew.ee.vt.edu>
Subject: PDP denied ResvErr/PathErr
Date: Thu, 21 Jun 2001 16:33:17 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Is it possible that a PDP deny/reject a ResvErr/PathErr outsourced message ?
If yes, what happens so ?

Thanks,
Yacine

-- Yacine El Mghazli
----------------------------------------------------------------------
  Alcatel R&I
  Software and Services Strategic Program - VIPeR
  Marcoussis, France
  Tel  +33 1 6963 4187
  Fax  +33 1 6963 1169
  yacine.el_mghazli@ms.alcatel.fr
----------------------------------------------------------------------





From owner-rap@ops.ietf.org  Thu Jun 21 12:30:07 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05298
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 12:30:06 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15D5Px-000E3M-00
	for rap-data@psg.com; Thu, 21 Jun 2001 07:26:45 -0700
Received: from mel.alcatel.fr ([212.208.74.132])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15D5Pw-000E3G-00
	for rap@ops.ietf.org; Thu, 21 Jun 2001 07:26:45 -0700
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA19510;
        Thu, 21 Jun 2001 15:03:16 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA28335;
        Thu, 21 Jun 2001 16:26:00 +0200 (MET DST)
Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id QAA18051;
	Thu, 21 Jun 2001 16:26:11 +0200 (MET DST)
Received: from pc50062 ([188.9.248.194])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id QAA19964;
	Thu, 21 Jun 2001 16:26:13 +0200 (MET DST)
Message-ID: <00c501c0fa5e$43b10b80$c2f809bc@pc50062>
From: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
To: "Kaustubh Phanse" <kphanse@ee.vt.edu>, <rap@ops.ietf.org>
References: <Pine.GSO.3.96.1010620131906.14713A-100000@yew.ee.vt.edu>
Subject: Re: Interaction between COPS-RSVP and COPS-PR
Date: Thu, 21 Jun 2001 16:27:13 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

see http://search.ietf.org/internet-drafts/draft-rawlins-rsvppcc-pib-01.txt

Yacine

> Has any work been done (or is being done) involving interaction
> between COPS-RSVP and COPS-PR?? Any IETF drafts/papers? Any pointers to
> this are greatly appreciated.
>
> Thank you
> regards
> Kaustubh
> --------------------------------------------------------------------------
---
>  Kaustubh S. Phanse   kphanse@ee.vt.edu
>  PhD student        http://www.ee.vt.edu/~kphanse
>  Alexandria Research Institute
>  Electrical & Computer Engineering Department
>  Virginia Polytechnic Institute & State University
> --------------------------------------------------------------------------
---
>
>




From owner-rap@ops.ietf.org  Thu Jun 21 12:41:16 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05944
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 12:41:15 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15D7Um-000GAu-00
	for rap-data@psg.com; Thu, 21 Jun 2001 09:39:52 -0700
Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15D7Uk-000GAf-00; Thu, 21 Jun 2001 09:39:50 -0700
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id QAA21356;
	Thu, 21 Jun 2001 16:38:07 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 21 Jun 2001 16:38:07 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <NKPR9P43>; Thu, 21 Jun 2001 09:38:04 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E8900655DDBB@orsmsx35.jf.intel.com>
From: "Hegde, Shriharsha" <shriharsha.hegde@intel.com>
To: "'Ritu Chadha'" <chadha@mailee.research.telcordia.com>, franr@pfn.com,
        Olivier.Dugeon@rd.francetelecom.com, mpls@UU.NET, te-wg@ops.ietf.org,
        sganguly@carrier9.com
Cc: policy@raleigh.ibm.com, rap@ops.ietf.org
Subject: RE: MPLS and COPS
Date: Thu, 21 Jun 2001 09:37:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Just like Diffserv MIB and Diffserv PIB are in Diffserv working group,
I support the notion of having a TE PIB in parallel to TE MIB in
TE WG. I believe PIB approach is the right direction to take for
policy/administrative control over MPLS/TE.

harsha

PS: I have not followed the TE WG discussion which took place months
ago about the ADs deciding that policy should not be in TEWG charter.




-----Original Message-----
From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com]
Sent: Tuesday, June 12, 2001 12:50 PM
To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET;
te-wg@ops.ietf.org; sganguly@carrier9.com
Cc: chadha@mailee.research.telcordia.com; policy@raleigh.ibm.com
Subject: RE: MPLS and COPS


Well, I can't comment on that except to say that I'm completely in 
agreement with you. You should direct your concerns to the ADs.
Randy?
Ritu

>From: "Sukanta Ganguly" <sganguly@carrier9.com>
>To: "Ritu Chadha" <chadha@research.telcordia.com>, <franr@pfn.com>, 
<Olivier.Dugeon@rd.francetelecom.com>, <mpls@UU.NET>, <te-wg@ops.ietf.org>
>Subject: RE: MPLS and COPS
>Date: Tue, 12 Jun 2001 11:50:35 -0700
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
>X-Loop-Detect: 1
>
>Ritu,
>  I see what you are saying and I did read some of them emails but it is
>needed. I mean I don't get it (:-)). Why not have a way for TE to take in
>some higher layer knowledge to perform smart engineering. There is a lot of
>knowledge that can be conveyed to the lower layers from the applications
>sitting on top.
>
>
>Sukanta Ganguly
>Senior Architect
>Carrier9 Networks
>Phone (408)-746-0400 x 119
>FAx (408)-730-9441
>
>-----Original Message-----
>From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com]
>Sent: Tuesday, June 12, 2001 11:16 AM
>To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET;
>te-wg@ops.ietf.org; sganguly@carrier9.com
>Cc: chadha@mailee.research.telcordia.com
>Subject: RE: MPLS and COPS
>
>
>Been there, tried that :-).
>
>This was discussed at some length a few months ago on the tewg mailing
list.
>The ADs did not see policy as an area that fitted within the TE WG charter
>at that time.
>
>Ritu
>
>>From: "Sukanta Ganguly" <sganguly@carrier9.com>
>>To: "Fran Reichmeyer" <franr@pfn.com>, "'Olivier Dugeon '"
><Olivier.Dugeon@rd.francetelecom.com>, <mpls@UU.NET>, <te-wg@ops.ietf.org>
>>Subject: RE: MPLS and COPS
>>Date: Tue, 12 Jun 2001 10:51:26 -0700
>>MIME-Version: 1.0
>>Content-Transfer-Encoding: 7bit
>>X-Priority: 3 (Normal)
>>X-MSMail-Priority: Normal
>>Importance: Normal
>>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
>>X-Loop-Detect: 1
>>
>>Maybe the TE group should be the place for this. Clearly policies should
be
>>an important traffic engineering operation.
>>
>>SG
>>
>>-----Original Message-----
>>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
>>Behalf Of Fran Reichmeyer
>>Sent: Tuesday, June 12, 2001 6:54 AM
>>To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org '
>>Subject: RE: MPLS and COPS
>>
>>
>>After several attempts at introducing this to the wg, it
>>was decided that policy is out of scope for the MPLS wg at this
>>time.
>>-Fran
>>
>>
>>-----Original Message-----
>>From: Olivier Dugeon
>>To: mpls@UU.NET; te-wg@ops.ietf.org
>>Sent: 6/12/01 4:28 AM
>>Subject: MPLS and COPS
>>
>>Hi all,
>>
>>In a context of QoS control in a multi-domain and multi-technology
>>network, we would use COPS as the control protocol rather than SNMP.
>>COPS need a "Policy rules Information Base" to work. A such PIB is
>>available for DiffServ for example. I would to know if somebody work on
>>a PIB for MPLS.
>>
>>- Is there some case study inside the WG or it is out the scope/out of
>>date ?
>>- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ?
>>
>>Thank's a lot
>>
>>Olivier Dugeon
>>--
>> FTR&D/DAC/CPN
>> Technopole Anticipa     | mailto:Olivier.Dugeon@francetelecom.com
>> 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
>> F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52
>>
>

============================================================================
=
Ritu Chadha
Director
Service Management Research
Telcordia Technologies 				(973) 829-4869 (voice)
MCC 1A-216R                                     (973) 829-5889 (fax)
445 South Street
chadha@research.telcordia.com
Morristown NJ 07960.
============================================================================
=






From owner-rap@ops.ietf.org  Thu Jun 21 14:55:04 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14061
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 14:55:02 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15D9Kb-000I6C-00
	for rap-data@psg.com; Thu, 21 Jun 2001 11:37:29 -0700
Received: from hawk.mail.pas.earthlink.net ([207.217.120.22])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15D9KY-000I5t-00; Thu, 21 Jun 2001 11:37:26 -0700
Received: from ANDREWHOME (user-vcauoft.dsl.mindspring.com [216.175.97.253])
	by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id LAA08149;
	Thu, 21 Jun 2001 11:37:22 -0700 (PDT)
Reply-To: <ah_smith@pacbell.net>
From: "Andrew Smith" <ah_smith@pacbell.net>
To: <te-wg@ops.ietf.org>, <mpls@UU.NET>, <subip-area@subip.ietf.org>
Cc: <rap@ops.ietf.org>, <franr@pfn.com>,
        "Hegde, Shriharsha" <shriharsha.hegde@intel.com>, <iesg@ietf.org>
Subject: RE: MPLS and COPS
Date: Thu, 21 Jun 2001 11:53:04 -0700
Message-ID: <KIEAIFILPFNLNGMKLEMGCENKCHAA.ah_smith@pacbell.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <4148FEAAD879D311AC5700A0C969E8900655DDBB@orsmsx35.jf.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

If:
(a) none of the existing WGs want the work item
(b) there are willing and able people to do the work
(c) it doesn't overlap with other work
(d) it is a legitimate, missing piece of what seems to be a popular
(proposed) standard

then find a friendly AD (doesn't seem to matter which Area), hold a BoF, if
anyone shows up for the BoF ask to form a WG and go from there. Don't let
the unwillingness of existing WGs (or their chairs or their ADs) stop a
piece of work that people, both vendors and consumers, want to see
standardised. Fran and Harsha, you know the process - just get the work
done.

My 2c.

Andrew

P.S. There's no such thing as "policy" - it's just network management. It
would be irresponsible for the IESG to hold back this legitimate piece of
standards' work.

-----Original Message-----
From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of
Hegde, Shriharsha
Sent: Thursday, June 21, 2001 9:38 AM
To: 'Ritu Chadha'; franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com;
mpls@UU.NET; te-wg@ops.ietf.org; sganguly@carrier9.com
Cc: policy@raleigh.ibm.com; rap@ops.ietf.org
Subject: RE: MPLS and COPS


Just like Diffserv MIB and Diffserv PIB are in Diffserv working group,
I support the notion of having a TE PIB in parallel to TE MIB in
TE WG. I believe PIB approach is the right direction to take for
policy/administrative control over MPLS/TE.

harsha

PS: I have not followed the TE WG discussion which took place months
ago about the ADs deciding that policy should not be in TEWG charter.




-----Original Message-----
From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com]
Sent: Tuesday, June 12, 2001 12:50 PM
To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET;
te-wg@ops.ietf.org; sganguly@carrier9.com
Cc: chadha@mailee.research.telcordia.com; policy@raleigh.ibm.com
Subject: RE: MPLS and COPS


Well, I can't comment on that except to say that I'm completely in
agreement with you. You should direct your concerns to the ADs.
Randy?
Ritu

>From: "Sukanta Ganguly" <sganguly@carrier9.com>
>To: "Ritu Chadha" <chadha@research.telcordia.com>, <franr@pfn.com>,
<Olivier.Dugeon@rd.francetelecom.com>, <mpls@UU.NET>, <te-wg@ops.ietf.org>
>Subject: RE: MPLS and COPS
>Date: Tue, 12 Jun 2001 11:50:35 -0700
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
>X-Loop-Detect: 1
>
>Ritu,
>  I see what you are saying and I did read some of them emails but it is
>needed. I mean I don't get it (:-)). Why not have a way for TE to take in
>some higher layer knowledge to perform smart engineering. There is a lot of
>knowledge that can be conveyed to the lower layers from the applications
>sitting on top.
>
>
>Sukanta Ganguly
>Senior Architect
>Carrier9 Networks
>Phone (408)-746-0400 x 119
>FAx (408)-730-9441
>
>-----Original Message-----
>From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com]
>Sent: Tuesday, June 12, 2001 11:16 AM
>To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET;
>te-wg@ops.ietf.org; sganguly@carrier9.com
>Cc: chadha@mailee.research.telcordia.com
>Subject: RE: MPLS and COPS
>
>
>Been there, tried that :-).
>
>This was discussed at some length a few months ago on the tewg mailing
list.
>The ADs did not see policy as an area that fitted within the TE WG charter
>at that time.
>
>Ritu
>
>>From: "Sukanta Ganguly" <sganguly@carrier9.com>
>>To: "Fran Reichmeyer" <franr@pfn.com>, "'Olivier Dugeon '"
><Olivier.Dugeon@rd.francetelecom.com>, <mpls@UU.NET>, <te-wg@ops.ietf.org>
>>Subject: RE: MPLS and COPS
>>Date: Tue, 12 Jun 2001 10:51:26 -0700
>>MIME-Version: 1.0
>>Content-Transfer-Encoding: 7bit
>>X-Priority: 3 (Normal)
>>X-MSMail-Priority: Normal
>>Importance: Normal
>>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
>>X-Loop-Detect: 1
>>
>>Maybe the TE group should be the place for this. Clearly policies should
be
>>an important traffic engineering operation.
>>
>>SG
>>
>>-----Original Message-----
>>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
>>Behalf Of Fran Reichmeyer
>>Sent: Tuesday, June 12, 2001 6:54 AM
>>To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org '
>>Subject: RE: MPLS and COPS
>>
>>
>>After several attempts at introducing this to the wg, it
>>was decided that policy is out of scope for the MPLS wg at this
>>time.
>>-Fran
>>
>>
>>-----Original Message-----
>>From: Olivier Dugeon
>>To: mpls@UU.NET; te-wg@ops.ietf.org
>>Sent: 6/12/01 4:28 AM
>>Subject: MPLS and COPS
>>
>>Hi all,
>>
>>In a context of QoS control in a multi-domain and multi-technology
>>network, we would use COPS as the control protocol rather than SNMP.
>>COPS need a "Policy rules Information Base" to work. A such PIB is
>>available for DiffServ for example. I would to know if somebody work on
>>a PIB for MPLS.
>>
>>- Is there some case study inside the WG or it is out the scope/out of
>>date ?
>>- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ?
>>
>>Thank's a lot
>>
>>Olivier Dugeon
>>--
>> FTR&D/DAC/CPN
>> Technopole Anticipa     | mailto:Olivier.Dugeon@francetelecom.com
>> 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
>> F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52
>>
>

============================================================================
=
Ritu Chadha
Director
Service Management Research
Telcordia Technologies 				(973) 829-4869 (voice)
MCC 1A-216R                                     (973) 829-5889 (fax)
445 South Street
chadha@research.telcordia.com
Morristown NJ 07960.
============================================================================
=







From owner-rap@ops.ietf.org  Thu Jun 21 20:22:17 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21396
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 20:22:16 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15DC3i-000LEd-00
	for rap-data@psg.com; Thu, 21 Jun 2001 14:32:14 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15DC3i-000LEX-00
	for rap@ops.ietf.org; Thu, 21 Jun 2001 14:32:14 -0700
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 15DC3h-0005Xq-00
	for rap@ops.ietf.org; Thu, 21 Jun 2001 14:32:13 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: ah_smith@pacbell.net, te-wg@ops.ietf.org, mpls@UU.NET,
        subip-area@subip.ietf.org
Cc: rap@ops.ietf.org, franr@pfn.com,
        "Hegde, Shriharsha" <shriharsha.hegde@intel.com>, iesg@ietf.org
Subject: RE: MPLS and COPS
In-Reply-To: <KIEAIFILPFNLNGMKLEMGCENKCHAA.ah_smith@pacbell.net>
References:  <KIEAIFILPFNLNGMKLEMGCENKCHAA.ah_smith@pacbell.net>
X-Mailer: Mulberry/2.1.0a6 (Win32)
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Message-Id: <E15DC3i-000LEd-00@psg.com>
Date: Thu, 21 Jun 2001 14:32:14 -0700
Content-Transfer-Encoding: 7bit

Note:

If there is a piece of standards work that is needed, well defined
and not part of any WG's charter, there is a shorter process:

- Write it up as an internet-draft.
- Talk about it in whatever fashion you like.
- Get a friendly AD to sponsor it.
- Do the 4-week IETF-wide Last Call.
- You're done.

Don't let the fact that it's an item too small to spin up a WG for block 
you from doing what's right.


--On 21. juni 2001 11:53 -0700 Andrew Smith <ah_smith@pacbell.net> wrote:

> If:
> (a) none of the existing WGs want the work item
> (b) there are willing and able people to do the work
> (c) it doesn't overlap with other work
> (d) it is a legitimate, missing piece of what seems to be a popular
> (proposed) standard
>
> then find a friendly AD (doesn't seem to matter which Area), hold a BoF,
> if anyone shows up for the BoF ask to form a WG and go from there. Don't
> let the unwillingness of existing WGs (or their chairs or their ADs) stop
> a piece of work that people, both vendors and consumers, want to see
> standardised. Fran and Harsha, you know the process - just get the work
> done.








From owner-rap@ops.ietf.org  Thu Jun 21 20:23:33 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21464
	for <rap-archive@lists.ietf.org>; Thu, 21 Jun 2001 20:23:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15DE48-000NSk-00
	for rap-data@psg.com; Thu, 21 Jun 2001 16:40:48 -0700
Received: from pmesmtp01.wcom.com ([199.249.20.1])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15DE47-000NSM-00
	for rap@ops.ietf.org; Thu, 21 Jun 2001 16:40:48 -0700
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GFB008ID0F4R1@firewall.mcit.com> for rap@ops.ietf.org; Thu,
 21 Jun 2001 23:40:16 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0GFB00B010F3AQ@dgismtp02.wcomnet.com>;
 Thu, 21 Jun 2001 23:40:16 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0GFB001PT0F1W4@dgismtp02.wcomnet.com>; Thu,
 21 Jun 2001 23:40:13 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id <KZ7F0KJ0>; Thu, 21 Jun 2001 23:40:13 +0000
Content-return: allowed
Date: Thu, 21 Jun 2001 23:40:11 +0000
From: "Rawlins, Diana" <Diana.Rawlins@wcom.com>
Subject: RE: PDP denied ResvErr/PathErr
To: "'Yacine El Mghazli'" <yacine.el_mghazli@ms.alcatel.fr>, rap@ops.ietf.org
Message-id: <492EB4A3F68CD411ABE800508B69362E31AA81@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Sender: owner-rap@ops.ietf.org
Precedence: bulk

My understanding of the COPS-RSVP spec is that the Request ResvErr or
PathErr results because of the PDP responding with a Dec Remove to the
previous request of the same handle. The Request ResvErr/PathErr provides
the change for the PDP to update the ERROR_SPEC object specifying detailed
error sub-codes (error-value) in the Decision Replacement object.

It doesn't make sense to me that the PDP would return a DEC Remove to a
legitimate REQ ResvErr/PathErr, but I suppose it could happen. I'm not
familiar with this case being explicitly addressed in any of the RFC's.
However, I don't see that it would change the PEP state a great deal. There
would be no need for the PEP to exchange the ResvErr or PathErr ERROR_SPEC
object out since the PDP would not have provided it in the Decision Remove.
The RSVP signal would be "error'ed" with a RESVERR or PATHERR and the policy
state removed. 

-Diana



-----Original Message-----
From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr]
Sent: Thursday, June 21, 2001 9:33 AM
To: rap@ops.ietf.org
Subject: PDP denied ResvErr/PathErr


Is it possible that a PDP deny/reject a ResvErr/PathErr outsourced message ?
If yes, what happens so ?

Thanks,
Yacine

-- Yacine El Mghazli
----------------------------------------------------------------------
  Alcatel R&I
  Software and Services Strategic Program - VIPeR
  Marcoussis, France
  Tel  +33 1 6963 4187
  Fax  +33 1 6963 1169
  yacine.el_mghazli@ms.alcatel.fr
----------------------------------------------------------------------





From owner-rap@ops.ietf.org  Fri Jun 22 07:34:24 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16767
	for <rap-archive@lists.ietf.org>; Fri, 22 Jun 2001 07:34:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15DMlr-00076Z-00
	for rap-data@psg.com; Fri, 22 Jun 2001 01:58:31 -0700
Received: from p-mail2.rd.francetelecom.fr ([193.49.124.32] helo=p-mail2.cnet.fr)
	by psg.com with smtp (Exim 3.16 #1)
	id 15DMlq-00075z-00
	for rap@ops.ietf.org; Fri, 22 Jun 2001 01:58:30 -0700
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <NJRF08JG>; Fri, 22 Jun 2001 10:57:58 +0200
Message-ID: <91A311FF6A85D3118DDF0060080C3D8201E2FB97@lat3721.rd.francetelecom.fr>
From: NOISETTE Yoann FTRD/DMI/CAE <yoann.noisette@rd.francetelecom.fr>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Cc: MORAND Pierrick FTRD/DMI/CAE <pierrick.morand@rd.francetelecom.fr>,
        RABOT Wilfrid FTRD/DMI/CAE <wilfrid.rabot@rd.francetelecom.fr>
Subject: Framework PIB clarifications
Date: Fri, 22 Jun 2001 10:57:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

We are currently working on a project making use of COPS-PR for provisioning
purposes. As far as the Framework PIB is concerned, we have some questions
to which we would like to draw the RAP list attention. Thanks in advance for
your replies.

1)	This point has already been asked by Man Li, with no answer. 
In the Interface Capability Set Table, the attribute frwkIfCapSetCapability
specifies the capability PRC instance for the interface. This PRC instance
is normally defined in other PIBs, like it is the case for the DiffServ PIB
for example.
We are working with the IPSec PIB, which doesn't contain any Capability
Table. So my question is, what value must we give to frwkIfCapSetCapability,
in so far as we don't have any capability table we can refer to in the IPSec
PIB??

2)	We have the same question regarding the attribute
frwIfCapSetRoleComboName. If we consider the IPSec PIB again, the PEP won't
notify the PDP with any Capability Set instance since there is no Capability
Table we can refer to. Thus, we wouldn't have any value for
frwIfCapSetRoleComboName. What value should we use then?? 

3)	What is the reason to use the frwIfCapSetName? Indeed the same
frwIfCapSetRoleComboRoles can be used to refer to many frwIfCapSetName which
themselves refer to a frwkIfCapSetCapability. What is the aim of such an
organisation? Why not frwIfCapSetRoleComboRoles refers directly to
frwkIfCapSetCapability? 

4)	As we understand it, there is an instance of PIB Framework
associated with each Request. Therefore, the Framework PIB is pushed by the
PEP for each Request it opens. However, most of the information is only
"notify", we are wondering why it should proceed so, since once the PDP has
the device description (roles, limitations, identification...), it can use
it for all following Request-States, within the context of a given
Client-Type of course. 
After the initial Request, only the PIB Incarnation Table and the possible
Filter Tables would have to be sent. The PDP would only have to complete
with the other information it already has. 
Or is there a good reason for sending the complete Framework PIB each time
(leading however to generate more traffic, consume memory and persistent
storage)?

5)	In the context of many Requests being opened for a same Client-Type,
how is handled the activation/deactivation of a PIB thanks to the
frwkPibIncarnationActive object ? For instance, I have a PEP and a PDP with
two Requests and the associated PIBs, PIB 1 active and PIB 2 not active:
a.	First scenario:  the PDP sets the frwkPibIncarnationActive object to
false for PIB 1 and then sets frwkPibIncarnationActive to true for PIB 2.
What happens during the short period of time when there is no active PIB??
Which policies are used by the PEP? 
b.	Second scenario: the PDP sets the frwkPibIncarnationActive object to
true for PIB 2. Then we have two active PIBs at the same time. Does the PDP
sets the frwkPibIncarnationActive to false on PIB 1, but what happens during
the period when there are two active PIBs ? Or does the PEP sets itself the
frwkPibIncarnationActive object to false for PIB 1, and notifies the PDP of
the change?

Thanks for the replies.

Yoann





From owner-rap@ops.ietf.org  Fri Jun 22 07:34:25 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16778
	for <rap-archive@lists.ietf.org>; Fri, 22 Jun 2001 07:34:25 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15DM90-0006NJ-00
	for rap-data@psg.com; Fri, 22 Jun 2001 01:18:22 -0700
Received: from p-mail2.rd.francetelecom.fr ([193.49.124.32] helo=p-mail2.cnet.fr)
	by psg.com with smtp (Exim 3.16 #1)
	id 15DM8z-0006M9-00
	for rap@ops.ietf.org; Fri, 22 Jun 2001 01:18:22 -0700
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <NJRF07PV>; Fri, 22 Jun 2001 10:17:48 +0200
Message-ID: <91A311FF6A85D3118DDF0060080C3D8201E2FB96@lat3721.rd.francetelecom.fr>
From: NOISETTE Yoann FTRD/DMI/CAE <yoann.noisette@rd.francetelecom.fr>
To: rap@ops.ietf.org
Cc: MORAND Pierrick FTRD/DMI/CAE <pierrick.morand@rd.francetelecom.fr>,
        RABOT Wilfrid FTRD/DMI/CAE <wilfrid.rabot@rd.francetelecom.fr>
Subject: Framework PIB clarifications 
Date: Fri, 22 Jun 2001 10:17:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

We are currently working on a project making use of COPS-PR for provisioning
purposes. As far as the Framework PIB is concerned, we have some questions
to which we would like to draw the RAP list attention. Thanks in advance for
your replies.

1)	This point has already been asked by Man Li, with no answer. 
In the Interface Capability Set Table, the attribute frwkIfCapSetCapability
specifies the capability PRC instance for the interface. This PRC instance
is normally defined in other PIBs, like it is the case for the DiffServ PIB
for example.
We are working with the IPSec PIB, which doesn't contain any Capability
Table. So my question is, what value must we give to frwkIfCapSetCapability,
in so far as we don't have any capability table we can refer to in the IPSec
PIB??

2)	We have the same question regarding the attribute
frwIfCapSetRoleComboName. If we consider the IPSec PIB again, the PEP won't
notify the PDP with any Capability Set instance since there is no Capability
Table we can refer to. Thus, we wouldn't have any value for
frwIfCapSetRoleComboName. What value should we use then?? 

3)	What is the reason to use the frwIfCapSetName? Indeed the same
frwIfCapSetRoleComboRoles can be used to refer to many frwIfCapSetName which
themselves refer to a frwkIfCapSetCapability. What is the aim of such an
organisation? Why not frwIfCapSetRoleComboRoles refers directly to
frwkIfCapSetCapability? 

4)	As we understand it, there is an instance of PIB Framework
associated with each Request. Therefore, the Framework PIB is pushed by the
PEP for each Request it opens. However, most of the information is only
"notify", we are wondering why it should proceed so, since once the PDP has
the device description (roles, limitations, identification...), it can use
it for all following Request-States, within the context of a given
Client-Type of course. 
After the initial Request, only the PIB Incarnation Table and the possible
Filter Tables would have to be sent. The PDP would only have to complete
with the other information it already has. 
Or is there a good reason for sending the complete Framework PIB each time
(leading however to generate more traffic, consume memory and persistent
storage)?

5)	In the context of many Requests being opened for a same Client-Type,
how is handled the activation/deactivation of a PIB thanks to the
frwkPibIncarnationActive object ? For instance, I have a PEP and a PDP with
two Requests and the associated PIBs, PIB 1 active and PIB 2 not active:
a.	First scenario:  the PDP sets the frwkPibIncarnationActive object to
false for PIB 1 and then sets frwkPibIncarnationActive to true for PIB 2.
What happens during the short period of time when there is no active PIB??
Which policies are used by the PEP? 
b.	Second scenario: the PDP sets the frwkPibIncarnationActive object to
true for PIB 2. Then we have two active PIBs at the same time. Does the PDP
sets the frwkPibIncarnationActive to false on PIB 1, but what happens during
the period when there are two active PIBs ? Or does the PEP sets itself the
frwkPibIncarnationActive object to false for PIB 1, and notifies the PDP of
the change?

Thanks for the replies.

Yoann



From owner-rap@ops.ietf.org  Fri Jun 22 18:37:31 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13818
	for <rap-archive@lists.ietf.org>; Fri, 22 Jun 2001 18:37:30 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15DYH9-000KKK-00
	for rap-data@psg.com; Fri, 22 Jun 2001 14:15:35 -0700
Received: from birch.ee.vt.edu ([128.173.88.34])
	by psg.com with esmtp (Exim 3.16 #1)
	id 15DYH9-000KKE-00
	for rap@ops.ietf.org; Fri, 22 Jun 2001 14:15:35 -0700
Received: from yew.ee.vt.edu (yew.ee.vt.edu [128.173.88.43])
	by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id RAA03123
	for <rap@ops.ietf.org>; Fri, 22 Jun 2001 17:15:33 -0400 (EDT)
Received: from localhost (kphanse@localhost)
	by yew.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id RAA28629
	for <rap@ops.ietf.org>; Fri, 22 Jun 2001 17:15:33 -0400 (EDT)
Date: Fri, 22 Jun 2001 17:15:32 -0400 (EDT)
From: Kaustubh Phanse <kphanse@ee.vt.edu>
To: rap@ops.ietf.org
Subject: Policy control for RSVP
Message-ID: <Pine.GSO.3.96.1010622165116.28256A-100000@yew.ee.vt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rap@ops.ietf.org
Precedence: bulk


	Just wanted to clarify my understanding of the policy
control/processing of PATH and RESV messages.

	To successfully implement policy-based admission control, during
the initiation of an RSVP reservation, is it really "necessary" to enforce
policy control on both PATH and RESV messages? I understand that policy
elements in PATH message can be used to authenticate users/applications
and the corresponding Tspec. But this may be achieved even by
policy control of the RESV message. So, even if PEP on the sender side
does not perform any policy-based admission control on an "invalid" PATH
message and lets it flow to the receiver, the PEP on the receiver-side
should be able to "reject" the resulting "invalid" RESV message...right?
And hence such a policy framework should still work? Is there a scenario
where this is NOT the case and policy control on both PATH and RESV
message is "critical" for successful enforcement of PAC.

Please forgive my ignorance on this topic! :) Any comments/clarifications
are more than welcome.

Thanks in advance.
sincerely,
Kaustubh 
-----------------------------------------------------------------------------
 Kaustubh S. Phanse					  kphanse@ee.vt.edu
 PhD student				       http://www.ee.vt.edu/~kphanse
 Alexandria Research Institute
 Electrical & Computer Engineering Department		               
 Virginia Polytechnic Institute & State University 
-----------------------------------------------------------------------------




From owner-rap@ops.ietf.org  Mon Jun 25 10:33:12 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16538
	for <rap-archive@lists.ietf.org>; Mon, 25 Jun 2001 10:33:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15EUZS-000Iku-00
	for rap-data@psg.com; Mon, 25 Jun 2001 04:30:22 -0700
Received: from alc119.alcatel.be ([195.207.101.119] helo=relay1.alcatel.be)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15EUZQ-000Ikd-00; Mon, 25 Jun 2001 04:30:20 -0700
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5PBU3910486;
	Mon, 25 Jun 2001 13:30:11 +0200 (MET DST)
Received: from alcatel.be ([138.203.66.234]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7  (934.1 12-30-1999)) with SMTP id C1256A76.003F26D6; Mon, 25 Jun 2001 13:29:47 +0200
Message-ID: <3B3720A9.A63B6C58@alcatel.be>
Date: Mon, 25 Jun 2001 13:29:45 +0200
From: Dominique Chantrain <dominique.chantrain@alcatel.be>
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ops-area@ops.ietf.org, rap@ops.ietf.org
Subject: Communication between applications and network
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Recently a new Internet draft has been submitted
(draft-pham-triggers-and-handles-00.txt, downloadable from
http://www.ietf.org/internet-drafts/draft-pham-triggers-and-handles-00.txt),
which introduces a new concept for communication between applications
and network 
elements. The document defines triggers and handles exchanged between
applications and network elements, and introduces associated
communication mechanisms such as subscription to triggers from a network
element, and discovery of network element interfaces.

This communication interface and framework will allow applications to be
deployed on heterogeneous networks in a vendor-independent way but still
being aware of network events by the mechanism of triggers and being
able to control network resources by the mechanism of handles, i.e.
network awareness of applications will be improved. The work will aim at
reusing as much as possible existing protocols and will 
define extensions or new protocols only when necessary. The targeted
network environment is primarily the broadband access network (user
terminal - DSL modem - DSLAM - BRAS), although also other networks can
be envisaged.

The purpose of this Internet Draft is to stimulate discussion on this
concept. Therefore an associated mailinglist has been created where you
can send your comments and reactions:
Address: triggershandles@public.alcatel.com
To subscribe, send an email to majordomo@public.alcatel.com with in the
body "subcribe triggershandles"

If discussions raise enough interests, a BOF will be requested to
further work on the subject in IETF. Indeed, the topic is today not
really covered in a charter of any working group. Nevertheless, it has
clear links with following areas and working groups:
- the applications area: since the I-D deals with mechanisms to make
applications more network aware.
- the operations and management area: since the mechanism are based on
or similar to concepts used in AAA, in policy framework, etc.
- the resource allocation protocol WG (rap): since the COPS protocol is
currently envisaged to be one of the major cornerstones of the triggers
& handles framework.
- the middlebox communication WG (midcom): as this WG deals with
mechanisms for applications to be able to communicate their needs to the
devices in the network that provide transport policy enforcement. in
other words, very similar to the idea of handles in the I-D.

Looking forward to receiving your comments,

Dominique Chantrain & Hien-Thong Pham
-- 
________ _ ____________________________________________________________
         V          Dominique CHANTRAIN
 +---------------+  Alcatel Bell NV      dominique.chantrain@alcatel.be
 | A L C A T E L |  F. Wellesplein 1             Voice: +32-3-240.85.18
 +---------------+  B-2018 Antwerpen, BELGIUM      Fax: +32-3-240.84.85

Research & Innovation
Telecom Services Project
_______________________________________________________________________



From owner-rap@ops.ietf.org  Tue Jun 26 09:05:58 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01743
	for <rap-archive@lists.ietf.org>; Tue, 26 Jun 2001 09:05:56 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15EqcZ-0008ot-00
	for rap-data@psg.com; Tue, 26 Jun 2001 04:03:03 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15EqcY-0008oa-00
	for rap@ops.ietf.org; Tue, 26 Jun 2001 04:03:02 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27231;
	Tue, 26 Jun 2001 07:02:22 -0400 (EDT)
Message-Id: <200106261102.HAA27231@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-new-rsvp-ext-00.txt
Date: Tue, 26 Jun 2001 07:02:22 -0400
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		: RSVP Extensions for Policy Control
	Author(s)	: R. Hess, S. Herzog
	Filename	: draft-ietf-rap-new-rsvp-ext-00.txt
	Pages		: 13
	Date		: 25-Jun-01
	
This memo presents a set of extensions for supporting generic policy
based admission control in RSVP. It should be perceived as an
extension to the RSVP functional specifications [RSVP].

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

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-new-rsvp-ext-00.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-new-rsvp-ext-00.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:	<20010625095559.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-new-rsvp-ext-00.txt

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

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

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Tue Jun 26 09:06:45 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01833
	for <rap-archive@lists.ietf.org>; Tue, 26 Jun 2001 09:06:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15EqcK-0008nq-00
	for rap-data@psg.com; Tue, 26 Jun 2001 04:02:48 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15EqcJ-0008nk-00
	for rap@ops.ietf.org; Tue, 26 Jun 2001 04:02:47 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27193;
	Tue, 26 Jun 2001 07:02:06 -0400 (EDT)
Message-Id: <200106261102.HAA27193@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-auth-policy-data-00.txt
Date: Tue, 26 Jun 2001 07:02:06 -0400
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		: Cryptographic Authentication for RSVP POLICY_DATA 
                          Objects
	Author(s)	: R. Hess
	Filename	: draft-ietf-rap-auth-policy-data-00.txt
	Pages		: 21
	Date		: 25-Jun-01
	
This document describes the format and use of the INTEGRITY option
within RSVP's POLICY_DATA object to provide integrity and
authentication of POLICY_DATA objects within RSVP messages.

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

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-auth-policy-data-00.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-auth-policy-data-00.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:	<20010625095542.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-auth-policy-data-00.txt

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

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

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Tue Jun 26 09:07:17 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01920
	for <rap-archive@lists.ietf.org>; Tue, 26 Jun 2001 09:07:14 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15EqcR-0008o2-00
	for rap-data@psg.com; Tue, 26 Jun 2001 04:02:55 -0700
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15EqcQ-0008nv-00
	for rap@ops.ietf.org; Tue, 26 Jun 2001 04:02:55 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27213;
	Tue, 26 Jun 2001 07:02:14 -0400 (EDT)
Message-Id: <200106261102.HAA27213@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-better-identity-00.txt
Date: Tue, 26 Jun 2001 07:02:14 -0400
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		: Identity Representation for RSVP
	Author(s)	: R. Hess et al.
	Filename	: draft-ietf-rap-rsvp-better-identity-00.txt
	Pages		: 17
	Date		: 25-Jun-01
	
This document describes the representation of identity information in
POLICY_DATA objects [POL-EXT] for supporting policy based admission
control in RSVP.  The goal of identity representation is to allow a
process on a system to securely identify the owner and the
application of the communicating process (e.g. user id) and convey
this information in RSVP messages (PATH or RESV) in a secure manner.
We describe the encoding of identities as a RSVP policy element.  We
describe the processing rules to generate identity policy elements
for multicast merged flows.  Subsequently, we describe
representations of user identities for Kerberos and Public Key based
user authentication mechanisms.  In summary we describe the use of
this identity information in an operational setting.

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

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-better-identity-00.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-better-identity-00.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:	<20010625095551.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-00.txt

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

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

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Tue Jun 26 14:01:37 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01245
	for <rap-archive@lists.ietf.org>; Tue, 26 Jun 2001 14:01:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15EwkP-000M4n-00
	for rap-data@psg.com; Tue, 26 Jun 2001 10:35:33 -0700
Received: from pc-62-30-167-16-ca.blueyonder.co.uk ([62.30.167.16] helo=NEXUS.replicants.org.uk)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15EwkO-000M4V-00
	for rap@ops.ietf.org; Tue, 26 Jun 2001 10:35:33 -0700
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Tue, 26 Jun 2001 18:39:12 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 15:08:43 2001
Received: from [132.151.1.177] (helo=loki.ietf.org)	by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15EtWD-0008IR-00; Tue, 26 Jun 2001 15:08:42 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19214	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:35:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18574	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:02:08 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27193;	Tue, 26 Jun 2001 07:02:06 -0400 (EDT)
Message-Id: <200106261102.HAA27193@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-auth-policy-data-00.txt
Date: Tue, 26 Jun 2001 07:02:06 -0400
X-OriginalArrivalTime: 26 Jun 2001 17:39:12.0487 (UTC) FILETIME=[E98DAF70:01C0FE66]
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		: Cryptographic Authentication for RSVP POLICY_DATA 
                          Objects
	Author(s)	: R. Hess
	Filename	: draft-ietf-rap-auth-policy-data-00.txt
	Pages		: 21
	Date		: 25-Jun-01
	
This document describes the format and use of the INTEGRITY option
within RSVP's POLICY_DATA object to provide integrity and
authentication of POLICY_DATA objects within RSVP messages.

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

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-auth-policy-data-00.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-auth-policy-data-00.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:	<20010625095542.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-auth-policy-data-00.txt

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

Co

--OtherAccess--
--NextPart--


From owner-rap@ops.ietf.org  Tue Jun 26 14:02:55 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01282
	for <rap-archive@lists.ietf.org>; Tue, 26 Jun 2001 14:02:52 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15EwkY-000M64-00
	for rap-data@psg.com; Tue, 26 Jun 2001 10:35:42 -0700
Received: from pc-62-30-167-16-ca.blueyonder.co.uk ([62.30.167.16] helo=NEXUS.replicants.org.uk)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15EwkX-000M4V-00
	for rap@ops.ietf.org; Tue, 26 Jun 2001 10:35:42 -0700
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Tue, 26 Jun 2001 18:39:11 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 15:18:28 2001
Received: from [132.151.1.177] (helo=loki.ietf.org)	by mail13.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15Etfg-0006AX-00; Tue, 26 Jun 2001 15:18:28 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19381	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:55:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18588	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:02:24 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27231;	Tue, 26 Jun 2001 07:02:22 -0400 (EDT)
Message-Id: <200106261102.HAA27231@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-new-rsvp-ext-00.txt
Date: Tue, 26 Jun 2001 07:02:22 -0400
X-OriginalArrivalTime: 26 Jun 2001 17:39:11.0786 (UTC) FILETIME=[E922B8A0:01C0FE66]
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		: RSVP Extensions for Policy Control
	Author(s)	: R. Hess, S. Herzog
	Filename	: draft-ietf-rap-new-rsvp-ext-00.txt
	Pages		: 13
	Date		: 25-Jun-01
	
This memo presents a set of extensions for supporting generic policy
based admission control in RSVP. It should be perceived as an
extension to the RSVP functional specifications [RSVP].

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

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-new-rsvp-ext-00.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-new-rsvp-ext-00.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:	<20010625095559.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-new-rsvp-ext-00.txt

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

Con

--OtherAccess--
--NextPart--


From owner-rap@ops.ietf.org  Tue Jun 26 14:04:15 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01298
	for <rap-archive@lists.ietf.org>; Tue, 26 Jun 2001 14:04:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1)
	id 15Ewkg-000M6V-00
	for rap-data@psg.com; Tue, 26 Jun 2001 10:35:50 -0700
Received: from pc-62-30-167-16-ca.blueyonder.co.uk ([62.30.167.16] helo=NEXUS.replicants.org.uk)
	by psg.com with esmtp (Exim 3.16 #1)
	id 15Ewkf-000M4V-00
	for rap@ops.ietf.org; Tue, 26 Jun 2001 10:35:49 -0700
Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC;
	 Tue, 26 Jun 2001 18:39:12 +0100
X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 15:13:04 2001
Received: from [132.151.1.177] (helo=loki.ietf.org)	by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0)	id 15EtaR-0001sT-00; Tue, 26 Jun 2001 15:13:04 +0100
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19307	for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:45:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18581	for <all-ietf@loki.ietf.org>; Tue, 26 Jun 2001 07:02:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27213;	Tue, 26 Jun 2001 07:02:14 -0400 (EDT)
Message-Id: <200106261102.HAA27213@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-better-identity-00.txt
Date: Tue, 26 Jun 2001 07:02:14 -0400
X-OriginalArrivalTime: 26 Jun 2001 17:39:12.0798 (UTC) FILETIME=[E9BD23E0:01C0FE66]
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		: Identity Representation for RSVP
	Author(s)	: R. Hess et al.
	Filename	: draft-ietf-rap-rsvp-better-identity-00.txt
	Pages		: 17
	Date		: 25-Jun-01
	
This document describes the representation of identity information in
POLICY_DATA objects [POL-EXT] for supporting policy based admission
control in RSVP.  The goal of identity representation is to allow a
process on a system to securely identify the owner and the
application of the communicating process (e.g. user id) and convey
this information in RSVP messages (PATH or RESV) in a secure manner.
We describe the encoding of identities as a RSVP policy element.  We
describe the processing rules to generate identity policy elements
for multicast merged flows.  Subsequently, we describe
representations of user identities for Kerberos and Public Key based
user authentication mechanisms.  In summary we describe the use of
this identity information in an operational setting.

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

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-better-identity-00.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-better-identity-00.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:	<20010625095551.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-rsvp-better-identity-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-draf"

--OtherAccess--
--NextPart--


From owner-rap@ops.ietf.org  Fri Jun 29 07:32:01 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16094
	for <rap-archive@lists.ietf.org>; Fri, 29 Jun 2001 07:32:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.30 #1)
	id 15FsH9-00034k-00
	for rap-data@psg.com; Fri, 29 Jun 2001 00:01:11 -0700
Received: from david.siemens.de ([192.35.17.14])
	by psg.com with esmtp (Exim 3.30 #1)
	id 15FsH7-00034Q-00
	for rap@ops.ietf.org; Fri, 29 Jun 2001 00:01:09 -0700
X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer david.siemens.de)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.0/8.11.0) with ESMTP id f5T717c23160
	for <rap@ops.ietf.org>; Fri, 29 Jun 2001 09:01:07 +0200 (MET DST)
Received: from mchp0153 (sn52sun1.mchp.siemens.de [139.23.202.144])
	by mail3.siemens.de (8.11.1/8.11.1) with SMTP id f5T716C18348848
	for <rap@ops.ietf.org>; Fri, 29 Jun 2001 09:01:06 +0200 (MEST)
Reply-To: <Hannes.Tschofenig@mchp.siemens.de>
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: <rap@ops.ietf.org>
Subject: Question about RFC 2752
Date: Fri, 29 Jun 2001 09:01:01 +0200
Message-ID: <NFBBKINBKMJFFHBMCIAOKEEACAAA.Hannes.Tschofenig@mchp.siemens.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

hi

a remark in RFC 2752 in section 4.2.1 notes: ‘The KDC is used to validate
the ticket and authentication the user sending RSVP message.’. this sounds
strange to me since the network element for which the ticket was requested
is able to decrypt the ticket and to authenticated the user and hence no kdc
involvement is required at this processing step.

an other statement which I think is somewhat misleading is given in section
6.3 of rfc 2752 in the context of user authentication at the router or the
PDP: ‘Send the Kerberos ticket to the KDC to obtain the session key. Using
the session key authenticate the user.’ if the service ticket is requested
by the user for the router or the pdp then no involvement of the kdc is
requried.

ciao
hannes




From owner-rap@ops.ietf.org  Fri Jun 29 07:32:03 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16123
	for <rap-archive@lists.ietf.org>; Fri, 29 Jun 2001 07:32:02 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.30 #1)
	id 15FsH8-00034X-00
	for rap-data@psg.com; Fri, 29 Jun 2001 00:01:10 -0700
Received: from goliath.siemens.de ([194.138.37.131])
	by psg.com with esmtp (Exim 3.30 #1)
	id 15FsH7-00034P-00
	for rap@ops.ietf.org; Fri, 29 Jun 2001 00:01:09 -0700
X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer goliath.siemens.de)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f5T716b18431
	for <rap@ops.ietf.org>; Fri, 29 Jun 2001 09:01:06 +0200 (MET DST)
Received: from mchp0153 (sn52sun1.mchp.siemens.de [139.23.202.144])
	by mail3.siemens.de (8.11.1/8.11.1) with SMTP id f5T716C18420352
	for <rap@ops.ietf.org>; Fri, 29 Jun 2001 09:01:06 +0200 (MEST)
Reply-To: <Hannes.Tschofenig@mchp.siemens.de>
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: <rap@ops.ietf.org>
Subject: Question to Kerberos/Multicast/RSVP
Date: Fri, 29 Jun 2001 09:01:00 +0200
Message-ID: <NFBBKINBKMJFFHBMCIAOIEEACAAA.Hannes.Tschofenig@mchp.siemens.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi!

in section 7 of rfc 2474 the use of multicast with kerberos is described as
follows:

"In the multicast case all receivers of a multicast
   RSVP message MUST share a single key with the KDC (e.g. the receivers
   are in effect the same security principal with respect to Kerberos)."

is this an appropriate assumption since this requires that before starting a
multicast session
a new principal name must be created at the kdc and the information
(principal name and key) must be send to the
participating users (receivers). then the actual reservation can take place
to make use of the above mentioned single key.

the above mentioned procedure is required since it cannot be assumed that
two principals are the same security principal. additionally this creates
problems for accounting.

am i missing something?
how should the exact processing work?

ciao
hannes





From owner-rap@ops.ietf.org  Fri Jun 29 07:40:25 2001
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21987
	for <rap-archive@lists.ietf.org>; Fri, 29 Jun 2001 07:40:25 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.30 #1)
	id 15FsH9-00034l-00
	for rap-data@psg.com; Fri, 29 Jun 2001 00:01:11 -0700
Received: from david.siemens.de ([192.35.17.14])
	by psg.com with esmtp (Exim 3.30 #1)
	id 15FsH7-00034R-00
	for rap@ops.ietf.org; Fri, 29 Jun 2001 00:01:09 -0700
X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer david.siemens.de)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.0/8.11.0) with ESMTP id f5T717c23162
	for <rap@ops.ietf.org>; Fri, 29 Jun 2001 09:01:07 +0200 (MET DST)
Received: from mchp0153 (sn52sun1.mchp.siemens.de [139.23.202.144])
	by mail3.siemens.de (8.11.1/8.11.1) with SMTP id f5T717C18408185
	for <rap@ops.ietf.org>; Fri, 29 Jun 2001 09:01:07 +0200 (MEST)
Reply-To: <Hannes.Tschofenig@mchp.siemens.de>
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: <rap@ops.ietf.org>
Subject: "Identity Representation for RSVP" question
Date: Fri, 29 Jun 2001 09:01:02 +0200
Message-ID: <NFBBKINBKMJFFHBMCIAOMEEACAAA.Hannes.Tschofenig@mchp.siemens.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi

in section 6.3. of <draft-ietf-rap-rsvp-better-identity-00.txt> the
verification procedure of the user credentials are explained:

"Kerberos: Send the Kerberos ticket to the KDC to obtain the session key.
Using the session key authenticate the user.".

why should the router/pdp send the ticket to the kdc?

ciao
hannes