From owner-rap@ops.ietf.org  Fri Feb  1 05:07:25 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12026
	for <rap-archive@lists.ietf.org>; Fri, 1 Feb 2002 05:07:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WaaV-000A5Z-00
	for rap-data@psg.com; Fri, 01 Feb 2002 02:06:31 -0800
Received: from rumba.cefriel.it ([131.175.53.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WaaU-000A5T-00
	for rap@ops.ietf.org; Fri, 01 Feb 2002 02:06:30 -0800
Received: by rumba.cefriel.it with Internet Mail Service (5.5.2650.21)
	id <ZCB9SPV0>; Fri, 1 Feb 2002 11:07:02 +0100
Message-ID: <7B6D8AAF768F194EB3090A0325C8520206AB1F@rumba.cefriel.it>
From: Marco De Bernardi <debernar@cefriel.it>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: Diffserv PIB
Date: Fri, 1 Feb 2002 11:07:01 +0100 
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 everybody,

I have a little question for you about the Diffserv PIB. How does the PDP
uses the capabilities
informations reported by the PEP's request message?
Do you have an exemple?

Thanks. 

You can mail to debernar@cefriel.it




From owner-rap@ops.ietf.org  Fri Feb  1 10:16:28 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26400
	for <rap-archive@lists.ietf.org>; Fri, 1 Feb 2002 10:16:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WfO8-000OIO-00
	for rap-data@psg.com; Fri, 01 Feb 2002 07:14:04 -0800
Received: from [64.223.136.41] (helo=hqmail01.ellacoya.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WfO7-000OII-00
	for rap@ops.ietf.org; Fri, 01 Feb 2002 07:14:03 -0800
Received: by hqmail01.ellacoya.com with Internet Mail Service (5.5.2653.19)
	id <1BZXDW3Y>; Fri, 1 Feb 2002 10:12:28 -0500
Message-ID: <D9B4A3B5A9FCD5118BFE00D0B760121C412212@hqmail01.ellacoya.com>
From: "Weiss, Walter" <wweiss@Ellacoya.com>
To: "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>,
        jmoisand@unispherenetworks.com, yacine.el_mghazli@ms.alcatel.fr,
        rap@ops.ietf.org
Subject: RE: Outsourcing and Provisioning common model
Date: Fri, 1 Feb 2002 10:12:27 -0500 
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

Actually, this does not affect the protocol at all. It is mainly a question
of PIB structures. It is also worth pointing out that with the proper
outsourcing semantics defined through PIBS, this will not only be useful to
RSVP, but to any protocol with a control plain requiring configuration
policies for the data plain.

regards,

-Walter

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> Sent: Thursday, January 31, 2002 8:37 PM
> To: jmoisand@unispherenetworks.com; yacine.el_mghazli@ms.alcatel.fr;
> rap@ops.ietf.org
> Subject: RE: Outsourcing and Provisioning common model
> 
> 
> Hi,
> 
> If I understand it correctly, 3GPP would like to use COPS-PR 
> for the GO interface and they have a tight schedule for their 
> next release. If we keep on changing the COPS protocols, is 
> it possible that people who are friendly with COPS will pick 
> up an alternative solution (SNMP or even Radius) simply for 
> stability reasons. By the time we come up with a perfect COPS 
> solution, many have already stood behind other protocols. 
> This applies not only to folks in 3GPP but also to those who 
> are interested in using COPS for policy management. Timing 
> may be everything for gaining market recognition. Without 
> market share, what is a perfect solution good for? 
> 
> Man 
> 
> 



From owner-rap@ops.ietf.org  Fri Feb  1 12:52:00 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05681
	for <rap-archive@lists.ietf.org>; Fri, 1 Feb 2002 12:51:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WhqP-0003fa-00
	for rap-data@psg.com; Fri, 01 Feb 2002 09:51:25 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WhqO-0003fU-00
	for rap@ops.ietf.org; Fri, 01 Feb 2002 09:51:24 -0800
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11HpHC03125;
	Fri, 1 Feb 2002 12:51:17 -0500 (EST)
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11HpFb03578;
	Fri, 1 Feb 2002 12:51:15 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id D8Z2Y05J; Fri, 1 Feb 2002 12:50:40 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJYB2; Fri, 1 Feb 2002 12:50:37 -0500
Message-Id: <5.0.0.25.0.20020201123733.028c2eb0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 01 Feb 2002 12:50:03 -0500
To: <Man.M.Li@nokia.com>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: RE: Outsourcing and Provisioning common model
Cc: <jmoisand@unispherenetworks.com>, <yacine.el_mghazli@ms.alcatel.fr>,
        <rap@ops.ietf.org>
In-Reply-To: <A6D9D7495456414BA08DB655C2AC67124143AC@bsebe001.NOE.Nokia.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Agree.

The proposal submitted into 3GPP is to USE THE COPS PROTOCOL WITH THE
COPS-PR EXTENSION AS IS.  NO PROTOCOL CHANGE REQUIRED.

We envision 3GPP's usage will be applicable to other usage also.
Hence we should work toward NO MORE COPS or COPS-PR PROTOCOL CHANGES!

Also, some good news:
3GPP CN3 have re-confirmed on Wed Jan 30, 2002 that the previous decision 
have not
change.  That is COPS-PR and UMTS Go PIB will be used for the 3GPP CN3 
functionalities.

We are continuing to get the UMTS Go PIB completed as part of 3GPP CN3 work 
item.
We will send updated UMTS Go PIB drafts into IETF as individual submissions.

-- Kwok --


At 08:36 PM 1/31/02 -0500, Man.M.Li@nokia.com wrote:
>Hi,
>
>If I understand it correctly, 3GPP would like to use COPS-PR for the GO 
>interface and they have a tight schedule for their next release. If we 
>keep on changing the COPS protocols, is it possible that people who are 
>friendly with COPS will pick up an alternative solution (SNMP or even 
>Radius) simply for stability reasons. By the time we come up with a 
>perfect COPS solution, many have already stood behind other protocols. 
>This applies not only to folks in 3GPP but also to those who are 
>interested in using COPS for policy management. Timing may be everything 
>for gaining market recognition. Without market share, what is a perfect 
>solution good for?
>
>Man




From owner-rap@ops.ietf.org  Fri Feb  1 13:09:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06195
	for <rap-archive@lists.ietf.org>; Fri, 1 Feb 2002 13:09:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Wi7v-0004Kt-00
	for rap-data@psg.com; Fri, 01 Feb 2002 10:09:31 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Wi7u-0004Km-00
	for rap@ops.ietf.org; Fri, 01 Feb 2002 10:09:30 -0800
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11I9OC09587;
	Fri, 1 Feb 2002 13:09:24 -0500 (EST)
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11I9Kc01186;
	Fri, 1 Feb 2002 13:09:21 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1CJ1Z34K; Fri, 1 Feb 2002 13:09:20 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJYC5; Fri, 1 Feb 2002 13:09:19 -0500
Message-Id: <5.0.0.25.0.20020201125143.028d3300@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 01 Feb 2002 13:08:45 -0500
To: Marco De Bernardi <debernar@cefriel.it>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: Diffserv PIB
Cc: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
In-Reply-To: <7B6D8AAF768F194EB3090A0325C8520206AB1F@rumba.cefriel.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Please reference 2nd to 5th paragraphs of section 7 (PIB Operational Overview)
of draft-ietf-diffserv-pib-05.txt.

Building on the info in the above reference...
The PDP will know if the PEP support a specific type of dropper, and
a specific type of scheduler.
The higher level Policies known to the PDP may indicate a specific
behavior needed to support a service.  This behavior may be achieved
by a specific mix of droppers, queues and schedulers on a single PEP.
And the same behavior may be achieved by another specific mix of
droppers, queues and schedulers on another PEP.
The PDP will use the capabilities indicated by each PEP to achieve
the required behavior for supporting the service required.

Please let me and others in the RAP/COPS community know if you have
other usage in mind.
Thanks!
-- Kwok --


At 11:07 AM 2/1/02 +0100, Marco De Bernardi wrote:
>Hi everybody,
>
>I have a little question for you about the Diffserv PIB. How does the PDP
>uses the capabilities
>informations reported by the PEP's request message?
>Do you have an exemple?
>
>Thanks.
>
>You can mail to debernar@cefriel.it




From owner-rap@ops.ietf.org  Fri Feb  1 14:31:06 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09486
	for <rap-archive@lists.ietf.org>; Fri, 1 Feb 2002 14:31:05 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WjOC-000716-00
	for rap-data@psg.com; Fri, 01 Feb 2002 11:30:24 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WjOB-00070w-00
	for rap@ops.ietf.org; Fri, 01 Feb 2002 11:30:23 -0800
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11JUKC24108;
	Fri, 1 Feb 2002 14:30:20 -0500 (EST)
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11JUHc08552;
	Fri, 1 Feb 2002 14:30:18 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id D8Z2ZMTD; Fri, 1 Feb 2002 14:30:17 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJY2X; Fri, 1 Feb 2002 14:30:15 -0500
Message-Id: <5.0.0.25.0.20020201142618.02c51b10@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 01 Feb 2002 14:29:41 -0500
To: "Krishna Prasad Akkineni" <krishna.akkineni@wipro.com>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: Response  Request: COPS PIBs standardization due-diligence
   feedback
Cc: Muralidhar S <mdhara@WSSPL.com>, "RapWG (E-mail)" <rap@ops.ietf.org>
In-Reply-To: <3C5A1812.CBBC0621@wipro.com>
References: <30BFDEA66FF4D41191EB00D0B765BC6F0468A5@medha.wsspl.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_930755==_.ALT"
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--=====================_930755==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

frwkIpFilterSrcPrefixLength (and also frwkIpFilterDstPrefixLength) works
the same way as how IP Address Ranges are specified today using CIDR.
Please reference RFC 1519 for more details on CIDR.
-- Kwok --

At 09:52 AM 2/1/02 +0530, Krishna Prasad Akkineni wrote:
>Hi,
>     This frwkIpFilterSrcPrefixLength got added 
> from  draft-ietf-rap-frameworkpib-06.txt.
>It looks like IP range representation can be made using this. But I do not 
>know how exactly?
>Could any one please explain more about frwkIpFilterSrcPrefixLength
>Regards
>kp
>
>
>Muralidhar S wrote:
>>Krishna Prasad,
>>
>>The  "FrwkIpFilterEntry" in  "draft-ietf-rap-frameworkpib-06.txt" defines an
>>attribute
>>"frwkIpFilterSrcPrefixLength". There is one for destination address also.
>>Can we make
>>use of this to define the range of IpAddress??.
>>
>>Regards
>>murali
>>
>>-----Original Message-----
>>From: Krishna Prasad Akkineni 
>>[<mailto:krishna.akkineni@wipro.com>mailto:krishna.akkineni@wipro.com]
>>Sent: 2002. January 29. 13:31
>>To: rap@ops.ietf.org
>>Cc: scott.hahn@intel.com
>>Subject: [Fwd: Re: Response Request: COPS PIBs standardization due-diligence
>>feedback]
>>
>>Hi,
>>     I would like to construct a policy for which the condition attribute is
>>a range of IP addresses.
>>e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in PIB.
>>Regards
>>Krishna Prasad.A
>>
>
>
>

--=====================_930755==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
frwkIpFilterSrcPrefixLength (and also frwkIpFilterDstPrefixLength)
works<br>
the same way as how IP Address Ranges are specified today using
CIDR.<br>
Please reference RFC 1519 for more details on CIDR.<br>
-- Kwok --<br>
<br>
At 09:52 AM 2/1/02 +0530, Krishna Prasad Akkineni wrote:<br>
<blockquote type=cite class=cite cite>Hi, <br>
&nbsp;&nbsp;&nbsp; This frwkIpFilterSrcPrefixLength got added from&nbsp;
draft-ietf-rap-frameworkpib-06.txt. <br>
It looks like IP range representation can be made using this. But I do
not know how exactly? <br>
<font color="#3333FF">Could any one please explain more about
frwkIpFilterSrcPrefixLength</font> <br>
Regards <br>
kp <br>
&nbsp; <br>
<br>
Muralidhar S wrote: <br>
<blockquote type=cite class=cite cite>Krishna Prasad, <br>
<br>
The&nbsp; &quot;FrwkIpFilterEntry&quot; in&nbsp;
&quot;draft-ietf-rap-frameworkpib-06.txt&quot; defines an <br>
attribute <br>
&quot;frwkIpFilterSrcPrefixLength&quot;. There is one for destination
address also. <br>
Can we make <br>
use of this to define the range of IpAddress??. <br>
<br>
Regards <br>
murali <br>
<br>
-----Original Message----- <br>
From: Krishna Prasad Akkineni
[<a href="mailto:krishna.akkineni@wipro.com">mailto:krishna.akkineni@wipro.com</a>]
<br>
Sent: 2002. January 29. 13:31 <br>
To: rap@ops.ietf.org <br>
Cc: scott.hahn@intel.com <br>
Subject: [Fwd: Re: Response Request: COPS PIBs standardization
due-diligence <br>
feedback] <br>
<br>
Hi, <br>
&nbsp;&nbsp;&nbsp; I would like to construct a policy for which the
condition attribute is <br>
a range of IP addresses. <br>
e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in
PIB. <br>
Regards <br>
Krishna Prasad.A <br>
&nbsp;</blockquote><br>
&nbsp; <br>
&nbsp; </blockquote></html>

--=====================_930755==_.ALT--




From owner-rap@ops.ietf.org  Fri Feb  1 18:19:59 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13992
	for <rap-archive@lists.ietf.org>; Fri, 1 Feb 2002 18:19:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Wmxd-000EPw-00
	for rap-data@psg.com; Fri, 01 Feb 2002 15:19:13 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Wmxc-000EPo-00
	for rap@ops.ietf.org; Fri, 01 Feb 2002 15:19:12 -0800
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11NJ3t25807
	for <rap@ops.ietf.org>; Fri, 1 Feb 2002 18:19:03 -0500 (EST)
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11NJ0t24915
	for <rap@ops.ietf.org>; Fri, 1 Feb 2002 18:19:01 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1CJ1ZP16; Fri, 1 Feb 2002 18:19:00 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJY5J; Fri, 1 Feb 2002 18:18:59 -0500
Message-Id: <5.0.0.25.0.20020201175520.02c0d050@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 01 Feb 2002 18:18:23 -0500
To: saurabh.kapoor@wipro.com
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: draft-ietf-rap-frameworkpib-06
Cc: rap <rap@ops.ietf.org>, srinivasu.nampelli@wipro.com,
        ravi.attili@wipro.com, naganna.vydyula@wipro.com,
        krishna.akkineni@wipro.com
In-Reply-To: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net>
References: <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Saurabh:
Sorry for not responding to this earlier.
Currently the "ifSpeed" refers to the interface speed provided by
the MIB's ifTable in RFC 2863.
Design of the DiffServ PIB is to be Role Combination specific and not
interface specific.  We also didn't want to pull in the MIB's ifTable into
a PIB as there are many proprietary extensions to the ifTable already.
Another point is that we can add this as part of the capabilities for
a specific Role Combination, but we may want to have a single Role
Combination containing interfaces of more than one interface speed.

I would like to leave it the way it is and just use the ifSpeed from the 
MIB's ifTable.
Let the DiffServ PIB get to Proposed Standard RFC.
Get more implementation experience to determine what is the right thing to do
before modifying it, as there are other things we will learn from more
implementation experience.

-- Kwok --


At 06:21 PM 1/2/02 +0530, saurabh.kapoor@wipro.com wrote:
>     The qosAssuredRateAbs parameter of the qosAssuredRate table specifies
>the minimum absolute rate, in kbps that a downstream scheduler element
>should allocate to the queue.
>This attributes value is coupled to that of qosAssuredRateRel : changes to
>one will affect the value of other. They are related to each other by the
>equation :
>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000
>
>My question is how does the PDP get the value of 'ifSpeed'? Does the PEP
>specify the value? If yes, then in which PIb is the value found ?
>
>Regards,
>Saurabh Kapoor
>----------------------------------------------------------------------------
>----------
>
>
>




From owner-rap@ops.ietf.org  Sun Feb  3 09:59:00 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25967
	for <rap-archive@lists.ietf.org>; Sun, 3 Feb 2002 09:58:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XO4x-000DmP-00
	for rap-data@psg.com; Sun, 03 Feb 2002 06:57:15 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16XO4w-000DmJ-00
	for rap@ops.ietf.org; Sun, 03 Feb 2002 06:57:15 -0800
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g13EufH04502;
	Sun, 3 Feb 2002 09:56:41 -0500 (EST)
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g13EucY20256;
	Sun, 3 Feb 2002 09:56:38 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id D8Z26WKD; Sun, 3 Feb 2002 09:56:36 -0500
Received: from tweedy.NortelNetworks.com (artpt5tq.us.nortel.com [47.140.52.240]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJZN8; Sun, 3 Feb 2002 09:56:35 -0500
Message-Id: <5.0.0.25.0.20020203093120.020a3eb0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sun, 03 Feb 2002 09:55:57 -0500
To: rap@ops.ietf.org, diffserv@ietf.org
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: ifSpeed with DiffServ PIB and Framework PIB [Previously Re:
  draft-ietf-rap-frameworkpib-06]
Cc: saurabh.kapoor@wipro.com, srinivasu.nampelli@wipro.com,
        ravi.attili@wipro.com, naganna.vydyula@wipro.com,
        krishna.akkineni@wipro.com, khchan@NortelNetworks.com
In-Reply-To: <5.0.0.25.0.20020201175520.02c0d050@zbl6c002.corpeast.bayne
 tworks.com>
References: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net>
 <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

An alternative to the treatment of ifSpeed by the DiffServ PIB is to add
an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry
to indicate the bit rate that can "sink" the output of the Scheduler
Data Path Element.  This will allow the DiffServ PIB to not rely on the
Interface MIB.

The above alternative is possible because the Framework PIB now
allows multiple interface capability sets belonging to the same Role
Combination, hence policies belonging to the same Role Combination
can be used for interfaces with different interface capability sets
(different interface speeds).

I have also put this on the diffserv mailing list as this need to be decided
with the DiffServ WG.
I can change this in the DiffServ PIB-06 I am submitting.
Notice DiffServ PIB-05 have already passed WG Last Call,
so this will be a minor change after WG Last Call before IESG Review.

-- Kwok --


At 06:18 PM 2/1/02 -0500, Chan, Kwok-Ho [BL60:470:EXCH] wrote:
>Saurabh:
>Sorry for not responding to this earlier.
>Currently the "ifSpeed" refers to the interface speed provided by
>the MIB's ifTable in RFC 2863.
>Design of the DiffServ PIB is to be Role Combination specific and not
>interface specific.  We also didn't want to pull in the MIB's ifTable into
>a PIB as there are many proprietary extensions to the ifTable already.
>Another point is that we can add this as part of the capabilities for
>a specific Role Combination, but we may want to have a single Role
>Combination containing interfaces of more than one interface speed.
>
>I would like to leave it the way it is and just use the ifSpeed from the 
>MIB's ifTable.
>Let the DiffServ PIB get to Proposed Standard RFC.
>Get more implementation experience to determine what is the right thing to do
>before modifying it, as there are other things we will learn from more
>implementation experience.
>
>-- Kwok --
>
>
>At 06:21 PM 1/2/02 +0530, saurabh.kapoor@wipro.com wrote:
>>     The qosAssuredRateAbs parameter of the qosAssuredRate table specifies
>>the minimum absolute rate, in kbps that a downstream scheduler element
>>should allocate to the queue.
>>This attributes value is coupled to that of qosAssuredRateRel : changes to
>>one will affect the value of other. They are related to each other by the
>>equation :
>>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000
>>
>>My question is how does the PDP get the value of 'ifSpeed'? Does the PEP
>>specify the value? If yes, then in which PIb is the value found ?
>>
>>Regards,
>>Saurabh Kapoor
>>----------------------------------------------------------------------------
>>----------
>>
>>
>




From owner-rap@ops.ietf.org  Mon Feb  4 04:48:10 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17487
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 04:48:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xfhv-0007w4-00
	for rap-data@psg.com; Mon, 04 Feb 2002 01:46:39 -0800
Received: from rumba.cefriel.it ([131.175.53.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Xfhu-0007vy-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 01:46:38 -0800
Received: by rumba.cefriel.it with Internet Mail Service (5.5.2650.21)
	id <ZCB9SQJW>; Mon, 4 Feb 2002 10:47:12 +0100
Message-ID: <7B6D8AAF768F194EB3090A0325C8520206AB27@rumba.cefriel.it>
From: Marco De Bernardi <debernar@cefriel.it>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: Diffserv PIB and LDAP
Date: Mon, 4 Feb 2002 10:47:09 +0100 
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 to everybody,

I have two questions about Diffserv PIB.
1)Can the PDP dinamically link the PRIs (with "next" attribute) ? If the
answer is "YES", the PDP makes links between PRIs basing the PEP
capabilities?

2) A PIB is a virtual policy data base. Is a PIB implemented by LDAP
protocol? Are there any implementations?


Thanks  



From owner-rap@ops.ietf.org  Mon Feb  4 05:54:53 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18224
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 05:54:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XglT-000Aly-00
	for rap-data@psg.com; Mon, 04 Feb 2002 02:54:23 -0800
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16XglS-000Als-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 02:54:22 -0800
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g14AsKr12836
	for <rap@ops.ietf.org>; Mon, 4 Feb 2002 05:54:20 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <1ACQC4WS>; Mon, 4 Feb 2002 11:54:19 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E69BCAE@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Kwok Ho Chan <khchan@NortelNetworks.com>, rap@ops.ietf.org,
        diffserv@ietf.org
Cc: saurabh.kapoor@wipro.com, srinivasu.nampelli@wipro.com,
        ravi.attili@wipro.com, naganna.vydyula@wipro.com,
        krishna.akkineni@wipro.com
Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ
	ously Re: draft-ietf-rap-frameworkpib-06]
Date: Mon, 4 Feb 2002 11:54:18 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Kwok writes:
> 
> An alternative to the treatment of ifSpeed by the DiffServ PIB is to
> add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry
> to indicate the bit rate that can "sink" the output of the Scheduler
> Data Path Element.  This will allow the DiffServ PIB to not 
> rely on the Interface MIB.
> 
So to me that sounds as "duplicating" information. 
How does this new field get filled out by the PEP?
What if that field conflicts with ifSpeed?

Would any network device not have the IF-MIB implemented anyway,
so the fact that you remove the dependency from the PIB, does not
mean that the IF-MIB does not have to be implemented in the device,
does it?

Bert



From owner-rap@ops.ietf.org  Mon Feb  4 08:08:11 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21060
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 08:08:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xipz-000GSm-00
	for rap-data@psg.com; Mon, 04 Feb 2002 05:07:11 -0800
Received: from p-mail1.rd.francetelecom.com ([193.49.124.31])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Xipw-000GSd-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 05:07:09 -0800
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <CVJT45P5>; Mon, 4 Feb 2002 14:06:49 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D8201E2FEE2@lat3721.rd.francetelecom.fr>
From: NOISETTE Yoann FTRD/DMI/CAE <yoann.noisette@rd.francetelecom.com>
To: rap@ops.ietf.org
Subject: Questions on framework-pib07
Date: Mon, 4 Feb 2002 14:07:02 +0100 
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA21060


I have some questions about the management of Role-Combinations as described
in §2.2 of the document "draft-ietf-rap-frameworkpib-07.txt". 

>>>>	At any later time, the PDP can update the Role-Combinations assigned

>>>>	to a specific interface, identified by IfIndex, or for an aggregate,

>>>>	identified by IfCapSetName, via an unsolicited decision to the PEP 
>>>>	on any open request handle. The PDP does this by sending updated 
>>>>	PRIs for the frwkIfRoleComboTable.

=> I suppose this update is done by the PDP for a given Client-Type, but I
think it would be good to give this precision in the text. Moreover, the
fact that the PDP can proceed using "any open request handle" leads me to
ask/think :

1) this means to me that the update impacts all instances of PIB, as "any
one" can be chosen. Thus all instances of PIB have the same role combos
defined for the interfaces (for a given CT). Is that right ? Isn't it
possible to have different role combos for an interface in different
instances of PIB attached to different Handle on a given Client-Type ? To
rely on an simple example :
Suppose I have two instances of PIB which I activate at different times,
let's say, one for the days of work, one for the week-end. I could decide to
give the role "comptability" during the days of work and "none" during the
week end to a given interface which I don't want to be used "with
"comptability" configuration during the week end.

2) should(n't) the PDP use the active handle to proceed  ? is it
implementation specific ?

3) SHOULD or MUST (or ...) the frwkPibIncarnationId be changed by the PDP
when updating the Role-Combinations ??

Following in §2.2 :
>>>>	When the Interface Role Combination associations are updated by the 
>>>>	PDP, the PEP SHOULD send updated ĉfull stateĈ requests for all open 
>>>> 	contexts (request handles).

=> this sentence reenforces the idea I exposed above in 1)... 
Therefore, the PEP will modify the required role combinations in all the
instances of PIB attached to the different existing contexts (handles).
Isn't it a bit contradictory with the settlement in §2.4 " [COPS-PR]
supports multiple, disjoint, independent instances of the PIB to represent
multiple instances of configured policy.". I see the same kind of
contradiction with the PEP changing the attribute frwkPibIncarnationActive
when necessary (§2.4), the contradiction coming on the word "independent"...

Let's look rapidly at the way to proceed :
a) when the PEP receives a Role Combination update from the PDP, it passes
this update on all the contexts (request handles) for the considered
Client-type. Then it sends a success report.
b) sending updated full state request is only SHOULD, therefore, if we admit
the Roles-Combinations of the interfaces in the different PIB instances are
the same, I see two possible inconsistencies :
	* the update has been done on the PEP's side, but if no full-state
request is sent afterwards, the PDP doesn't have the updated
Role-combinations in its own instances (cf. §2.2 "the PDP must have the
previous request state that it maintained for that request handle").
	* if for only some contexts, the PEP has sent updated full-state
request, then on the PDP's side, some context are updated, others  are not,
leading to have two different sets of Role-combinations at the same time on
different contexts... which is contradictory to the hypothesis stated in b)
above...

Please correct me if I'm wrong... If not, this means that the document
contains two possible inconsistencies, which could be avoided, for instance
by simply having the PDP update the different contexts on its side once it
has received the success report from the PEP...

Finally, some typos :

* page 23 : fwrPibIncarnationFullState : "It does not have any meaning when
sent from the PDP to the PEP" (instead of PDP in the text)
* page 23 : fwrPibIncarnationFullState : "see section 2.3 for details..."
(instead of section 3.3 in the text)

Thanks for your replies.

Yoann Noisette




From owner-rap@ops.ietf.org  Mon Feb  4 10:59:20 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26701
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 10:59:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XlUu-000ODP-00
	for rap-data@psg.com; Mon, 04 Feb 2002 07:57:36 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16XlUt-000ODD-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 07:57:35 -0800
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14FvUH15029;
	Mon, 4 Feb 2002 10:57:31 -0500 (EST)
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14FvS302364;
	Mon, 4 Feb 2002 10:57:28 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id D8Z2824R; Mon, 4 Feb 2002 10:57:25 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJ5MM; Mon, 4 Feb 2002 10:57:27 -0500
Message-Id: <5.0.0.25.0.20020204105040.02ac47c0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 04 Feb 2002 10:56:48 -0500
To: Marco De Bernardi <debernar@cefriel.it>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: Diffserv PIB and LDAP
Cc: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
In-Reply-To: <7B6D8AAF768F194EB3090A0325C8520206AB27@rumba.cefriel.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi Marco:
Please see response inline.
-- Kwok --

At 10:47 AM 2/4/02 +0100, Marco De Bernardi wrote:
>Hi to everybody,
>
>I have two questions about Diffserv PIB.
>1)Can the PDP dinamically link the PRIs (with "next" attribute) ? If the
>answer is "YES", the PDP makes links between PRIs basing the PEP
>capabilities?

Yes, with dynamic meaning based on more general, network wide policies
at the PDP and higher level servers.


>2) A PIB is a virtual policy data base. Is a PIB implemented by LDAP
>protocol? Are there any implementations?

A PIB is a data representation that is carried over the wire.
The PDP may store the Policy Data Base using any data base technology
it chooses.  Currently PIBs are carried by the COPS-PR protocol.



>Thanks




From owner-rap@ops.ietf.org  Mon Feb  4 11:37:09 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28112
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 11:37:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xm6s-0000Hc-00
	for rap-data@psg.com; Mon, 04 Feb 2002 08:36:50 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Xm6r-0000HV-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 08:36:49 -0800
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14GaAH19909;
	Mon, 4 Feb 2002 11:36:10 -0500 (EST)
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14Ga7706584;
	Mon, 4 Feb 2002 11:36:07 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1CJ1ZQDX; Mon, 4 Feb 2002 11:36:07 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DR4GJ5Q8; Mon, 4 Feb 2002 11:36:07 -0500
Message-Id: <5.0.0.25.0.20020204110610.025da1f0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 04 Feb 2002 11:35:28 -0500
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB
  [Previ ously Re: draft-ietf-rap-frameworkpib-06]
Cc: "Kwok-Ho Chan"<khchan@NortelNetworks.com>, rap@ops.ietf.org,
        diffserv@ietf.org, saurabh.kapoor@wipro.com,
        srinivasu.nampelli@wipro.com, ravi.attili@wipro.com,
        naganna.vydyula@wipro.com, krishna.akkineni@wipro.com
In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0E69BCAE@nl0006exch002u.nl
 .lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Bert:
Please see response inline.
-- Kwok --

At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote:
>Kwok writes:
> >
> > An alternative to the treatment of ifSpeed by the DiffServ PIB is to
> > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry
> > to indicate the bit rate that can "sink" the output of the Scheduler
> > Data Path Element.  This will allow the DiffServ PIB to not
> > rely on the Interface MIB.
> >
>So to me that sounds as "duplicating" information.
>How does this new field get filled out by the PEP?

The "ifSpeed" being discussed is the information required for the PDP
to formulate the correct scheduling policy parameters based on network
wide policies.  May be we should not use the term "ifSpeed" and allow
the scheduling policy parameter be not tightly coupled to interface.
This field should be filled out by the PEP as it sees what it needs to be
controlled by policy, and this is not necessarily an interface.

>What if that field conflicts with ifSpeed?

The scheduling policy parameter here may be totally different from
ifSpeed in the IF-MIB.  So I don't think the notion of conflict exists.


>Would any network device not have the IF-MIB implemented anyway,
>so the fact that you remove the dependency from the PIB, does not
>mean that the IF-MIB does not have to be implemented in the device,
>does it?

The removal of this dependency from the PIB does not say anything about
implementation of the IF-MIB at all.  It is up to the implementation what it
wants/needs to do.


>Bert




From owner-rap@ops.ietf.org  Mon Feb  4 16:23:30 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06245
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 16:23:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XqZb-000BIv-00
	for rap-data@psg.com; Mon, 04 Feb 2002 13:22:47 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16XqZa-000BIp-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 13:22:46 -0800
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14LMBH19979;
	Mon, 4 Feb 2002 16:22:11 -0500 (EST)
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14LM7707419;
	Mon, 4 Feb 2002 16:22:08 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1CJ1ZQTM; Mon, 4 Feb 2002 16:22:07 -0500
Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1JPBYXAB; Mon, 4 Feb 2002 16:22:07 -0500
Message-Id: <5.0.0.25.0.20020204160524.0342d1a0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 04 Feb 2002 16:21:22 -0500
To: "Andrew Smith" <ah_smith@acm.org>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB
  [Previ ously Re: draft-ietf-rap-frameworkpib-06]
Cc: "Kwok-Ho Chan"<khchan@NortelNetworks.com>,
        "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com>, <rap@ops.ietf.org>,
        <diffserv@ietf.org>, <saurabh.kapoor@wipro.com>,
        <srinivasu.nampelli@wipro.com>, <ravi.attili@wipro.com>,
        <naganna.vydyula@wipro.com>, <krishna.akkineni@wipro.com>
In-Reply-To: <KIEAIFILPFNLNGMKLEMGIEIADAAA.ah_smith@acm.org>
References: <5.0.0.25.0.20020204110610.025da1f0@zbl6c002.corpeast.baynetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Andrew:
Thanks for the clarification,
Please see response inline.
-- Kwok --

At 10:30 AM 2/4/02 -0800, Andrew Smith wrote:
>I think you're all missing the point here. The relationship between the
>"xxxRel" and the "xxxAbs" objects in the Diffserv PIB is just the same as in
>the Diffserv MIB:
>
>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000
>
>The reason that both objects are present is that sometime you want to set a
>configuration based on an absolute bandwidth (e.g. 1 Mbps), sometimes you
>want to set it based on a fraction of the link's bandwidth (e.g. 20% of line
>rate). In order to allow people to use either type of "policy", we
>duplicated the object and had the two incarnations of it linked by the above
>equation (it's a clumsy solution but it seemed like the best we could do
>given the languages we have for describing the semantics of objects in SMI
>or SPPI).
>
>The manager (or PDP) only has to set one of the two objects and, therefore,
>does not need to know the ifSpeed if it sets the "xxxRel" object. If it sets
>the "xxxAbs" object then it probably should have some way of knowing, a
>priori, what speed each interface covered by a RoleCombination can handle -

The above have not changed.  But the policy does not always have to be
associated to an interface, and that is where ifTable will not come into play.
And that is why we may only want to indicate the capability as a "sink"
or "drain" rate out of a scheduler data path element.  Also even when only
"xxxRel" is used, the PDP may still want to know the "xxxAbs" numbers
to make sure a specific service is supported with the policy.

>I'd suggest that the ifTable is a good way of discovering this information
>ahead of time, through SNMP probably.

Notice my reply to Bert is this change does not say anything about
implementation and usage of ifTable.
If policy is associated with an interface, there may be an association.
But we may not want to have such a limitation from the policy sense.

>  [There's a larger issue too: what is
>the defined behaviour when one or more members of a RoleCombination cannot
>support a given policy rule (e.g. manager tries to set a 10Mbps RateAbs
>policy on a 2Mbps interface?]
>
>So I'd object to Kwok's proposed change.
>
>Andrew Smith
>
>
>-----Original Message-----
>From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of
>Kwok Ho Chan
>Sent: Monday, February 04, 2002 8:35 AM
>To: Wijnen, Bert (Bert)
>Cc: Kwok-Ho Chan; rap@ops.ietf.org; diffserv@ietf.org;
>saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com;
>ravi.attili@wipro.com; naganna.vydyula@wipro.com;
>krishna.akkineni@wipro.com
>Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB
>[Previ ously Re: draft-ietf-rap-frameworkpib-06]
>
>
>Bert:
>Please see response inline.
>-- Kwok --
>
>At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote:
> >Kwok writes:
> > >
> > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to
> > > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry
> > > to indicate the bit rate that can "sink" the output of the Scheduler
> > > Data Path Element.  This will allow the DiffServ PIB to not
> > > rely on the Interface MIB.
> > >
> >So to me that sounds as "duplicating" information.
> >How does this new field get filled out by the PEP?
>
>The "ifSpeed" being discussed is the information required for the PDP
>to formulate the correct scheduling policy parameters based on network
>wide policies.  May be we should not use the term "ifSpeed" and allow
>the scheduling policy parameter be not tightly coupled to interface.
>This field should be filled out by the PEP as it sees what it needs to be
>controlled by policy, and this is not necessarily an interface.
>
> >What if that field conflicts with ifSpeed?
>
>The scheduling policy parameter here may be totally different from
>ifSpeed in the IF-MIB.  So I don't think the notion of conflict exists.
>
>
> >Would any network device not have the IF-MIB implemented anyway,
> >so the fact that you remove the dependency from the PIB, does not
> >mean that the IF-MIB does not have to be implemented in the device,
> >does it?
>
>The removal of this dependency from the PIB does not say anything about
>implementation of the IF-MIB at all.  It is up to the implementation what it
>wants/needs to do.
>
>
> >Bert
>
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>https://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html




From owner-rap@ops.ietf.org  Mon Feb  4 17:59:03 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07741
	for <rap-archive@lists.ietf.org>; Mon, 4 Feb 2002 17:59:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xs4O-000DMF-00
	for rap-data@psg.com; Mon, 04 Feb 2002 14:58:40 -0800
Received: from ierw.net.avaya.com ([198.152.13.101])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Xs4N-000DM9-00
	for rap@ops.ietf.org; Mon, 04 Feb 2002 14:58:39 -0800
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22572
	for <rap@ops.ietf.org>; Mon, 4 Feb 2002 17:57:04 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22563
	for <rap@ops.ietf.org>; Mon, 4 Feb 2002 17:57:03 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06]
Date: Tue, 5 Feb 2002 00:57:39 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2FACAEE4@IS0004AVEXU1.global.avaya.com>
Thread-Topic: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06]
Thread-Index: AcGtamAQN1GapWijSsePFyJqXQoa4QABdxKA
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "Kwok Ho Chan" <khchan@NortelNetworks.com>, <rap@ops.ietf.org>,
        <diffserv@ietf.org>
Cc: <saurabh.kapoor@wipro.com>, <srinivasu.nampelli@wipro.com>,
        <ravi.attili@wipro.com>, <naganna.vydyula@wipro.com>,
        <krishna.akkineni@wipro.com>
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07741

This discussion has for me some confusing aspects. The existence of
several management protocols is not something new. After all most of the
devices that I know 'always' supported at least two management protocols
- CLI and SNMP - now COPS emerged for policy configuration on some
devices, and there are several other around. 

I am not sure that the requirement of not duplicating information is
caught in any of the standards. It is more a common sense requirement,
but behind it hides the more complex issue of a single data model for
all IETF management protocols. This is the real issue that we need to
face as we advance towards the 'new generation' of management protocols,
and in the absence of a valid solution to this problem no real
consistence can be expected in this space.

Before Brian jumps on me, I would say that this discussion might be
appropriate for one of the 'management - new generation' lists, but
before we move there (if anybody is interested in the continuation of a
thread on this) I wanted to have the reply visible for the participants
in the original thread.

Regards,

Dan


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, February 04, 2002 12:54 PM
> To: Kwok Ho Chan; rap@ops.ietf.org; diffserv@ietf.org
> Cc: saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; 
> ravi.attili@wipro.com; naganna.vydyula@wipro.com; 
> krishna.akkineni@wipro.com
> Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and 
> Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06]
> 
> 
> Kwok writes:
> > 
> > An alternative to the treatment of ifSpeed by the DiffServ PIB is to
> > add an attribute qosIfSchedulerCapsIfSpeed to 
> qosIfSchedulerCapsEntry
> > to indicate the bit rate that can "sink" the output of the Scheduler
> > Data Path Element.  This will allow the DiffServ PIB to not 
> > rely on the Interface MIB.
> > 
> So to me that sounds as "duplicating" information. 
> How does this new field get filled out by the PEP?
> What if that field conflicts with ifSpeed?
> 
> Would any network device not have the IF-MIB implemented anyway,
> so the fact that you remove the dependency from the PIB, does not
> mean that the IF-MIB does not have to be implemented in the device,
> does it?
> 
> Bert
> 
> 



From owner-rap@ops.ietf.org  Wed Feb 13 08:12:26 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00436
	for <rap-archive@lists.ietf.org>; Wed, 13 Feb 2002 08:12:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16azBX-0009ZG-00
	for rap-data@psg.com; Wed, 13 Feb 2002 05:10:55 -0800
Received: from infres.enst.fr ([137.194.160.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16azBW-0009ZA-00
	for rap@ops.ietf.org; Wed, 13 Feb 2002 05:10:55 -0800
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP id 90C3C189D
	for <rap@ops.ietf.org>; Wed, 13 Feb 2002 14:10:50 +0100 (MET)
Message-ID: <3C6A67E7.3529DD71@yahoo.com>
Date: Wed, 13 Feb 2002 14:19:35 +0100
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: PIB-ACCESS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi everybody,

How can I reuse a PRC but with onother PIB-ACCESS clause?

For exemple:
Diffserv PIB has defined qosTBParamEntry PRC with the PIB-ACCESS =
'install' in qosTBParamTable. I defined another PIB for another COPS
extension and want to reuse this PRC for 'notify' purpose. How can I use
it without defining an identical PRC table except PIB-ACCESS='notify'
(or PIB-ACCESS='notify-install')?

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 74 61 - Fax : 01 45 81 31 19
email : trnguyen@enst.fr





From owner-rap@ops.ietf.org  Wed Feb 13 15:47:47 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20295
	for <rap-archive@lists.ietf.org>; Wed, 13 Feb 2002 15:47:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b6Ix-000F4y-00
	for rap-data@psg.com; Wed, 13 Feb 2002 12:47:03 -0800
Received: from birch.ee.vt.edu ([128.173.88.34])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b6Ix-000F4r-00
	for rap@ops.ietf.org; Wed, 13 Feb 2002 12:47:03 -0800
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 PAA05557
	for <rap@ops.ietf.org>; Wed, 13 Feb 2002 15:47:01 -0500 (EST)
Received: from localhost (kphanse@localhost)
	by yew.ee.vt.edu (8.10.2+Sun/8.10.2) with ESMTP id g1DKkvR18594
	for <rap@ops.ietf.org>; Wed, 13 Feb 2002 15:46:58 -0500 (EST)
Date: Wed, 13 Feb 2002 15:46:57 -0500 (EST)
From: Kaustubh Phanse <kphanse@ee.vt.edu>
To: <rap@ops.ietf.org>
Subject: Handling multiple events at the PEP
Message-ID: <Pine.SOL.4.30.0202131508530.18330-100000@yew.ee.vt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rap@ops.ietf.org
Precedence: bulk


Hi! everyone,

	I had a question as to how multiple (almost simultaneous) events
are handled at a PEP.

	RFC 2748 states the following (about the stateful nature of the
COPS protocol) on pages 3 and 4:
	"By (2) we mean that
         the server may respond to new queries differently because of
         previously installed Request/Decision state(s) that are
         related."

	So, (in an outsourcing model) if a PEP has multiple policy
requests to be sent (in response to almost simultaneous occurence of
events), does the PEP wait for the PDP to send a decision on its previous
policy request before sending the next request, to ensure that a proper
Request/Decision state is installed (given that subsequent queries may be
related)?

Thank you very much.
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  Wed Feb 13 16:40:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22105
	for <rap-archive@lists.ietf.org>; Wed, 13 Feb 2002 16:40:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b786-000Ggc-00
	for rap-data@psg.com; Wed, 13 Feb 2002 13:39:54 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b783-000Gf0-00
	for rap@ops.ietf.org; Wed, 13 Feb 2002 13:39:52 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id VAA05570
	for <rap@ops.ietf.org>; Wed, 13 Feb 2002 21:39:47 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021313385422901
 ; Wed, 13 Feb 2002 13:38:54 -0800
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <1Y38XFCB>; Wed, 13 Feb 2002 13:39:45 -0800
Message-ID: <10C8636AE359D4119118009027AE99870DA5DDDE@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'Nguyen Thi Mai Trang'" <maitrangqos@yahoo.com>, rap@ops.ietf.org
Subject: RE: PIB-ACCESS
Date: Wed, 13 Feb 2002 13:39:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Hi Nguyen,
I think in this case, you'll have to copy & paste the definition. The reason
is that changing the PIB-ACCESS implies you are changing the semantics while
reusing the syntax. SPPI's concept of reuse is geared to both semantic AND
syntactic reuse.
Cheers,
-Dave

> -----Original Message-----
> From: Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com]
> Sent: Wednesday, February 13, 2002 5:20 AM
> To: rap@ops.ietf.org
> Subject: PIB-ACCESS
> 
> Hi everybody,
> 
> How can I reuse a PRC but with onother PIB-ACCESS clause?
> 
> For exemple:
> Diffserv PIB has defined qosTBParamEntry PRC with the PIB-ACCESS =
> 'install' in qosTBParamTable. I defined another PIB for another COPS
> extension and want to reuse this PRC for 'notify' purpose. How can I use
> it without defining an identical PRC table except PIB-ACCESS='notify'
> (or PIB-ACCESS='notify-install')?
> 
> 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 74 61 - Fax : 01 45 81 31 19
> email : trnguyen@enst.fr
> 




From owner-rap@ops.ietf.org  Mon Feb 18 07:55:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01411
	for <rap-archive@lists.ietf.org>; Mon, 18 Feb 2002 07:55:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16cnHe-000AJ9-00
	for rap-data@psg.com; Mon, 18 Feb 2002 04:52:42 -0800
Received: from rumba.cefriel.it ([131.175.53.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16cnHe-000AIv-00
	for rap@ops.ietf.org; Mon, 18 Feb 2002 04:52:42 -0800
Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19)
	id <1PGZ6XLY>; Mon, 18 Feb 2002 13:54:18 +0100
Message-ID: <7B6D8AAF768F194EB3090A0325C8520206AB3E@rumba.cefriel.it>
From: Marco De Bernardi <debernar@cefriel.it>
To: "'rap@ops.ietf.org'" <rap@ops.ietf.org>
Subject: COPS, COPS-PR performance and scalability
Date: Mon, 18 Feb 2002 13:54:09 +0100
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


Hi to everybody,

I'm interested to evaluate COPS/COPS-PR performance and scalability. Do any
studies already exist? Where can I find them?

Thanks.



From owner-rap@ops.ietf.org  Mon Feb 18 19:18:02 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24396
	for <rap-archive@lists.ietf.org>; Mon, 18 Feb 2002 19:18:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16cxy5-000GWk-00
	for rap-data@psg.com; Mon, 18 Feb 2002 16:17:13 -0800
Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16cxy4-000GWV-00
	for rap@ops.ietf.org; Mon, 18 Feb 2002 16:17:12 -0800
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id TAA08296;
	Mon, 18 Feb 2002 19:26:42 -0500 (EST)
Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1)
	id xma008288; Mon, 18 Feb 02 19:25:56 -0500
Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19)
	id <1VYXQ74B>; Mon, 18 Feb 2002 19:15:19 -0500
Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA0934@corp-exc3.ctron.com>
From: "Harrington, David" <dbh@enterasys.com>
To: "'Marco De Bernardi'" <debernar@cefriel.it>,
        "'rap@ops.ietf.org'"
	 <rap@ops.ietf.org>
Subject: RE: COPS, COPS-PR performance and scalability
Date: Mon, 18 Feb 2002 19:15:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B8DA.859F3770"
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_01C1B8DA.859F3770
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Erik Liden and Anders Torger wrote a master's thesis in January 2000 on the
"Implementation and Evaluation of the Common Open Policy Service (COPS)
Protocol and its use for Policy Provisioning" that you might want to review.

They did their master's work at the Department of Computer Science and
Electrical Engineering of the Lulea University of Technology.

dbh

> -----Original Message-----
> From: Marco De Bernardi [mailto:debernar@cefriel.it]
> Sent: Monday, February 18, 2002 7:54 AM
> To: 'rap@ops.ietf.org'
> Subject: COPS, COPS-PR performance and scalability
> 
> 
> 
> Hi to everybody,
> 
> I'm interested to evaluate COPS/COPS-PR performance and 
> scalability. Do any
> studies already exist? Where can I find them?
> 
> Thanks.
> 

------_=_NextPart_001_01C1B8DA.859F3770
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.2653.12">
<TITLE>RE: COPS, COPS-PR performance and scalability</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Erik Liden and Anders Torger wrote a master's thesis =
in January 2000 on the &quot;Implementation and Evaluation of the =
Common Open Policy Service (COPS) Protocol and its use for Policy =
Provisioning&quot; that you might want to review.</FONT></P>

<P><FONT SIZE=3D2>They did their master's work at the Department of =
Computer Science and Electrical Engineering of the Lulea University of =
Technology.</FONT></P>

<P><FONT SIZE=3D2>dbh</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Marco De Bernardi [<A =
HREF=3D"mailto:debernar@cefriel.it">mailto:debernar@cefriel.it</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, February 18, 2002 7:54 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'rap@ops.ietf.org'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: COPS, COPS-PR performance and =
scalability</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi to everybody,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm interested to evaluate COPS/COPS-PR =
performance and </FONT>
<BR><FONT SIZE=3D2>&gt; scalability. Do any</FONT>
<BR><FONT SIZE=3D2>&gt; studies already exist? Where can I find =
them?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1B8DA.859F3770--



From owner-rap@ops.ietf.org  Tue Feb 19 07:12:52 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15624
	for <rap-archive@lists.ietf.org>; Tue, 19 Feb 2002 07:12:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16d96M-000LjO-00
	for rap-data@psg.com; Tue, 19 Feb 2002 04:10:30 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16d96L-000LiE-00
	for rap@ops.ietf.org; Tue, 19 Feb 2002 04:10:29 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15369;
	Tue, 19 Feb 2002 07:10:27 -0500 (EST)
Message-Id: <200202191210.HAA15369@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-session-auth-03.txt
Date: Tue, 19 Feb 2002 07:10:26 -0500
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

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

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Tue Feb 19 07:12:55 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15636
	for <rap-archive@lists.ietf.org>; Tue, 19 Feb 2002 07:12:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16d96S-000LmG-00
	for rap-data@psg.com; Tue, 19 Feb 2002 04:10:36 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16d96R-000Ll1-00
	for rap@ops.ietf.org; Tue, 19 Feb 2002 04:10:35 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15387;
	Tue, 19 Feb 2002 07:10:31 -0500 (EST)
Message-Id: <200202191210.HAA15387@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-rsvp-authsession-02.txt
Date: Tue, 19 Feb 2002 07:10:31 -0500
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

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

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Wed Feb 20 20:05:43 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25295
	for <rap-archive@lists.ietf.org>; Wed, 20 Feb 2002 20:05:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16dhes-000Oya-00
	for rap-data@psg.com; Wed, 20 Feb 2002 17:04:26 -0800
Received: from rip.psg.com ([147.28.0.39])
	by psg.com with esmtp (Exim 3.35 #1)
	id 16dhes-000OyU-00
	for rap@ops.ietf.org; Wed, 20 Feb 2002 17:04:26 -0800
Received: from randy by rip.psg.com with local (Exim 3.35 #1)
	id 16dhes-000Gkh-00
	for rap@ops.ietf.org; Wed, 20 Feb 2002 17:04:26 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A4FCF75@cms3.etri.re.kr>
From: jekim@etri.re.kr
To: rap@ops.ietf.org
Subject: Could you recommend COPS open sources?
Date: Thu, 21 Feb 2002 10:04:17 +0900
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,

I'm sorry if my question is not related to this mailing list. 
I'm find the COPS open source code to apply to policy server and FreeBSD
router.
The platform COPS implementted on not important, I will refer to that and
modify to be appropriate to my platform.
It is very helpful to me for somebody to recommend COPS open source codes.
Thank you.

Ji-Eon Kim



From owner-rap@ops.ietf.org  Wed Feb 20 20:59:54 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25939
	for <rap-archive@lists.ietf.org>; Wed, 20 Feb 2002 20:59:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16diW6-00008r-00
	for rap-data@psg.com; Wed, 20 Feb 2002 17:59:26 -0800
Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16diW5-00008k-00
	for rap@ops.ietf.org; Wed, 20 Feb 2002 17:59:25 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id BAA04748
	for <rap@ops.ietf.org>; Thu, 21 Feb 2002 01:59:24 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022017583228605
 ; Wed, 20 Feb 2002 17:58:32 -0800
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <FJBKKMW7>; Wed, 20 Feb 2002 17:59:24 -0800
Message-ID: <59885C5E3098D511AD690002A5072D3C034BEACF@orsmsx111.jf.intel.com>
From: "Hahn, Scott" <scott.hahn@intel.com>
To: rap@ops.ietf.org
Cc: "Mark L. Stevens (E-mail)" <mlstevens@rcn.com>,
        "Bert Wijnen (Bert) (E-mail)" <bwijnen@lucent.com>,
        nhamer@nortelnetworks.com, kosinski@cs.ualberta.ca,
        gageb@nortelnetworks.com, mbroda@nortelnetworks.com,
        hugh.shieh@attws.com
Subject: WG Last Call for draft-ietf-rap-rsvp-authsession-02.txt and draft
	-ietf-rap-session-auth-03.txt
Date: Wed, 20 Feb 2002 17:59:22 -0800
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

Working Group last-call to commence on

http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-03.txt

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

Working group last-call on these documents will end March 6, 2002.

Regards
   Scott Hahn
   Mark Stevens
   RAP WG co-chairs





From owner-rap@ops.ietf.org  Thu Feb 21 11:13:03 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22540
	for <rap-archive@lists.ietf.org>; Thu, 21 Feb 2002 11:13:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16dvnr-000Dcx-00
	for rap-data@psg.com; Thu, 21 Feb 2002 08:10:39 -0800
Received: from pmesmtp02.wcom.com ([199.249.20.2])
	by psg.com with esmtp (Exim 3.35 #1)
	id 16dvnq-000Dcr-00
	for rap@ops.ietf.org; Thu, 21 Feb 2002 08:10:38 -0800
Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257)
 id <0GRW00F014XOM2@firewall.wcom.com> for rap@ops.ietf.org; Thu,
 21 Feb 2002 16:10:36 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GRW00DF94XOCF@firewall.wcom.com>; Thu,
 21 Feb 2002 16:10:36 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0GRW00H014XJ6F@pmismtp02.wcomnet.com>;
 Thu, 21 Feb 2002 16:10:36 +0000 (GMT)
Received: from dgmexch09.wcomnet.com ([166.38.58.240])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0GRW00G6T4XDKG@pmismtp02.wcomnet.com>; Thu,
 21 Feb 2002 16:10:25 +0000 (GMT)
Received: by DGMEXCH09.wcomnet.com with Internet Mail Service (5.5.2653.19)
 id <1575Z3T0>; Thu, 21 Feb 2002 16:10:25 +0000
Content-return: allowed
Date: Thu, 21 Feb 2002 16:10:20 +0000
From: "Rawlins, Diana" <Diana.Rawlins@wcom.com>
Subject: RE: Could you recommend COPS open sources?
To: "'jekim@etri.re.kr'" <jekim@etri.re.kr>, rap@ops.ietf.org
Cc: "Kulkarni Amol (Kulkarni, Amol)" <amol.kulkarni@intel.com>
Message-id: <492EB4A3F68CD411ABE800508B69362E648259@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Xao/i3Npt5ATlGwY9LYekA)"
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_Xao/i3Npt5ATlGwY9LYekA)
Content-type: text/plain; CHARSET=US-ASCII

Ji-Eon,

Check out the website, www.vovida.org.
The COPS link is under Protocols in the left hand frame.

Also, I understand that Intel has COPS open source. I don't have a link but
have cc'd an Intel engineer, Amol, that may be able to point you to some
info.

-Diana

-----Original Message-----
From: jekim@etri.re.kr [mailto:jekim@etri.re.kr] 
Sent: Wednesday, February 20, 2002 7:04 PM
To: rap@ops.ietf.org
Subject: Could you recommend COPS open sources?

Hi All,

I'm sorry if my question is not related to this mailing list. 
I'm find the COPS open source code to apply to policy server and FreeBSD
router.
The platform COPS implementted on not important, I will refer to that and
modify to be appropriate to my platform.
It is very helpful to me for somebody to recommend COPS open source codes.
Thank you.

Ji-Eon Kim

--Boundary_(ID_Xao/i3Npt5ATlGwY9LYekA)
Content-type: text/html; CHARSET=US-ASCII
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=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: Could you recommend COPS open sources?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ji-Eon,</FONT>
</P>

<P><FONT SIZE=3D2>Check out the website, www.vovida.org.</FONT>
<BR><FONT SIZE=3D2>The COPS link is under Protocols in the left hand =
frame.</FONT>
</P>

<P><FONT SIZE=3D2>Also, I understand that Intel has COPS open source. I =
don't have a link but have cc'd an Intel engineer, Amol, that may be =
able to point you to some info.</FONT></P>

<P><FONT SIZE=3D2>-Diana</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: jekim@etri.re.kr [<A =
HREF=3D"mailto:jekim@etri.re.kr">mailto:jekim@etri.re.kr</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, February 20, 2002 7:04 PM</FONT>
<BR><FONT SIZE=3D2>To: rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Could you recommend COPS open =
sources?</FONT>
</P>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>I'm sorry if my question is not related to this =
mailing list. </FONT>
<BR><FONT SIZE=3D2>I'm find the COPS open source code to apply to =
policy server and FreeBSD</FONT>
<BR><FONT SIZE=3D2>router.</FONT>
<BR><FONT SIZE=3D2>The platform COPS implementted on not important, I =
will refer to that and</FONT>
<BR><FONT SIZE=3D2>modify to be appropriate to my platform.</FONT>
<BR><FONT SIZE=3D2>It is very helpful to me for somebody to recommend =
COPS open source codes.</FONT>
<BR><FONT SIZE=3D2>Thank you.</FONT>
</P>

<P><FONT SIZE=3D2>Ji-Eon Kim</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_Xao/i3Npt5ATlGwY9LYekA)--



From owner-rap@ops.ietf.org  Thu Feb 21 11:19:04 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22738
	for <rap-archive@lists.ietf.org>; Thu, 21 Feb 2002 11:19:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16dvvv-000Dpl-00
	for rap-data@psg.com; Thu, 21 Feb 2002 08:18:59 -0800
Received: from [202.96.136.222] (helo=public.szptt.net.cn)
	by psg.com with smtp (Exim 3.35 #1)
	id 16dvvs-000Dpd-00
	for rap@ops.ietf.org; Thu, 21 Feb 2002 08:18:57 -0800
Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0)
	with SMTP id jm23c753830; Thu, 21 Feb 2002 16:18:27 -0000
Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0)
	with SMTP id jm53c72d036; Tue, 19 Feb 2002 16:17:29 -0000
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA25888
	for ietf-123-outbound.01@ietf.org; Tue, 19 Feb 2002 10:35:00 -0500 (EST)
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 HAA24450
	for <all-ietf@loki.ietf.org>; Tue, 19 Feb 2002 07:10:28 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15369;
	Tue, 19 Feb 2002 07:10:27 -0500 (EST)
Message-Id: <200202191210.HAA15369@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rap@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-session-auth-03.txt
Date: Tue, 19 Feb 2002 07:10:26 -0500
Sender: owner-rap@ops.ietf.org
Precedence: bulk

--NextPart

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

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Mon Feb 25 10:41:44 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14311
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 10:41:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fNFM-0004cK-00
	for rap-data@psg.com; Mon, 25 Feb 2002 07:41:00 -0800
Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fNFL-0004cE-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 07:40:59 -0800
Received: from enst.fr (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP
	id 1DBB818B1; Mon, 25 Feb 2002 16:40:55 +0100 (MET)
Message-ID: <3C7A5D2F.A348666C@enst.fr>
Date: Mon, 25 Feb 2002 16:50:07 +0100
From: Nguyen Thi Mai Trang <trnguyen@enst.fr>
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Weiss, Walter" <wweiss@Ellacoya.com>, rap@ops.ietf.org,
        Kwok Ho Chan <khchan@NortelNetworks.com>, sherzog@hyperchip.com
Subject: Re: Outsourcing and Provisioning common model
References: <D9B4A3B5A9FCD5118BFE00D0B760121C412210@bor.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 Walter, Kwok, Herzog and everybody,

> As such the arguement for normalization is to take the best of both COPS and
> COPS-PR, and merge them together.

I think that COPS include COPS-PR but when I read this sentence, COPS and
COPS-PR seem two  separate parts. I wonder that COPS-PR is a functional mode of
COPS protocol or COPS-PR is a protocol layer? I explain this question:

In RFC 3084, COPS-PR is defined as one functional mode of COPS protocol in which
the policies is supplied to the PEP before the event arrive. COPS Outsourcing is
another mode in which the policies is supplied to the PEP after the event
arrive. I read your draft and find that there are some cases (pages 8), the
event arrive ("When a packet arrive") and there is not yet policies to applied
("it does not match the criteria for an existing session"), the PEP marks the
session as "pending" and sends a REQ to the PDP to get policies for this event.
This means that you are in Outsourcing mode but the message are unchanged in
compare with COPS-PR. It means that you use 'Context = Configuration', 'ClientSI
= Named ClientSI'.

Therefore, I find that you call a protocol COPS-PR because it uses the PIB data
presentation and the Objects transporting PIB instances (COPS-PR plays the role
of protocol layer) rather than the Provioning model defined in the begining of
RFC 3084. I feel the same thing while reading COPS-UMTS.

Why don't you use 'Context = Resource-Allocation/ or Authorization' and
''ClientSI = Signaled ClientSI' for the case of Access Request and Access
Response because the sementic of this REQ is signaling to the PDP a new session
and request for an authorization?
For Accessor Provisioning Request, Provisioning Response and Report messages, I
totally agreed with your draft that it is pure COPS-PR.

I agreed with Kwok in a precedent message that the dynamic-ness of provisioning
can be from very static to very dynamic in COPS-PR. But the choice binary
Outsourcing/Provisioning for a client-type may cause sometimes paradox with
concepts defined in RFC 3084. Especially we call a client-type COPS-Provisioning
but some events arrive before its policies are requested and supplied.

IMHO, defining a 'unified mode' as the presentation of Shai Herzog is a good
idea and neccessary for an agree upon terminology for client-types using both
Outsourcing and Provisioning modes. A well definied terminology concerning
'Context' , 'ClientSI object', data representation in this mode...is wished.

Please tell me if I have misunderstandings. Thank you very much.
Mai Trang




From owner-rap@ops.ietf.org  Mon Feb 25 12:38:20 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21174
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 12:38:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fP4h-0006yB-00
	for rap-data@psg.com; Mon, 25 Feb 2002 09:38:07 -0800
Received: from mail.ee.gatech.edu ([130.207.225.105])
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fP4g-0006y5-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 09:38:06 -0800
Received: from escada.ece.gatech.edu (escada.ece.gatech.edu [199.77.155.39])
	by mail.ee.gatech.edu (8.12.2/8.12.1) with ESMTP id g1PHc4WT005483;
	Mon, 25 Feb 2002 12:38:04 -0500 (EST)
Received: from localhost (tricha@localhost)
	by escada.ece.gatech.edu (8.12.0.Beta19/8.12.0.Beta19/Submit) with ESMTP id g1PHc3MZ015476;
	Mon, 25 Feb 2002 12:38:03 -0500 (EST)
Date: Mon, 25 Feb 2002 12:38:03 -0500 (EST)
From: Tricha Anjali <tricha@ece.gatech.edu>
To: rap@ops.ietf.org
cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Subject: COPS vs. SNMP
Message-ID: <Pine.GSO.4.44.0202251227500.15181-100000@escada.ece.gatech.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-rap@ops.ietf.org
Precedence: bulk


Hello,

We have been following the IETF activities concerning the ongoing work in
the fields of SNMP and COPS. It seems that at the meeting in March 2000 in
Adelaide, the snmpconf working group was formed for issues dealing with
policy-based network management after the BOF about network management in
Dec 1999. However, now the group seems to have accomplished its charter
and finished. Does this mean that the discussion has been resolved?

We would like to know if the resource reservation in a network can/should
be achieved via COPS? If yes, how is it advantageous over SNMP?

Any help will be appreciated!

Thanks in advance,

Tricha

-------------------------------
Tricha Anjali
Broadband & Wireless Networking Lab
School of Electrical and Computer Engineering
Georgia Institute of Technology
http://users.ece.gatech.edu/~tricha/






From owner-rap@ops.ietf.org  Mon Feb 25 13:32:24 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23662
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 13:32:23 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fPum-0007vd-00
	for rap-data@psg.com; Mon, 25 Feb 2002 10:31:56 -0800
Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fPul-0007vX-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 10:31:55 -0800
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id SAA22472
	for <rap@ops.ietf.org>; Mon, 25 Feb 2002 18:31:54 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022510323813539
 ; Mon, 25 Feb 2002 10:32:38 -0800
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <1Y3021PH>; Mon, 25 Feb 2002 10:31:54 -0800
Message-ID: <10C8636AE359D4119118009027AE99870DA5DE2E@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'Tricha Anjali'" <tricha@ece.gatech.edu>, rap@ops.ietf.org
Cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 10:31:53 -0800
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'm interested in what the industry adoption of SNMPConf is/will be.
Particularly given that CERT is already advising that administrators TURN
SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of CERT advisories
and other bad press due to its
troubling susceptibilities. Now just imagine allowing people to actually
download viruses and worms via SNMPConf PM MIB's Scripts.
-Dave

http://www.internetwk.com/story/INW20020213S0002

> -----Original Message-----
> From: Tricha Anjali [mailto:tricha@ece.gatech.edu]
> Sent: Monday, February 25, 2002 9:38 AM
> To: rap@ops.ietf.org
> Cc: Ian F. Akyildiz
> Subject: COPS vs. SNMP
> 
> 
> 
> Hello,
> 
> We have been following the IETF activities concerning the 
> ongoing work in
> the fields of SNMP and COPS. It seems that at the meeting in 
> March 2000 in
> Adelaide, the snmpconf working group was formed for issues 
> dealing with
> policy-based network management after the BOF about network 
> management in
> Dec 1999. However, now the group seems to have accomplished 
> its charter
> and finished. Does this mean that the discussion has been resolved?
> 
> We would like to know if the resource reservation in a 
> network can/should
> be achieved via COPS? If yes, how is it advantageous over SNMP?
> 
> Any help will be appreciated!
> 
> Thanks in advance,
> 
> Tricha
> 
> -------------------------------
> Tricha Anjali
> Broadband & Wireless Networking Lab
> School of Electrical and Computer Engineering
> Georgia Institute of Technology
> http://users.ece.gatech.edu/~tricha/
> 
> 
> 
> 



From owner-rap@ops.ietf.org  Mon Feb 25 13:49:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24431
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 13:49:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fQBT-0008Ce-00
	for rap-data@psg.com; Mon, 25 Feb 2002 10:49:11 -0800
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fQBS-0008CY-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 10:49:10 -0800
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1PIn7027593
	for <rap@ops.ietf.org>; Mon, 25 Feb 2002 13:49:07 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <1Z89Q8QQ>; Mon, 25 Feb 2002 19:49:06 +0100
Message-ID: <114DE1AABD7DD41189B600508BAF127105597265@nl0006exch005u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Durham, David" <david.durham@intel.com>,
        "'Tricha Anjali'"
	 <tricha@ece.gatech.edu>, rap@ops.ietf.org
Cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 19:49:06 +0100
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

David, I am not sure what you are trying to tell people?

The SNMP CERT advisories have NOT talked about a flaw
in the SNMP Protocol at all. They have talked about implementation
bugs. Further, it seems that most implementation bugs have been
in the area of not properly decoding BER encoded SNMP packets.

Since the COPS-PR with PIB approach also uses BER encoding for
sending the configuration/policy information, I would suspect
that COPS-PR implementations have the same potential risks!!!

Bert 

> -----Original Message-----
> From: Durham, David [mailto:david.durham@intel.com]
> Sent: Monday, February 25, 2002 7:32 PM
> To: 'Tricha Anjali'; rap@ops.ietf.org
> Cc: Ian F. Akyildiz
> Subject: RE: COPS vs. SNMP
> 
> 
> I'm interested in what the industry adoption of SNMPConf is/will be.
> Particularly given that CERT is already advising that 
> administrators TURN
> SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of 
> CERT advisories
> and other bad press due to its
> troubling susceptibilities. Now just imagine allowing people 
> to actually
> download viruses and worms via SNMPConf PM MIB's Scripts.
> -Dave
> 
> http://www.internetwk.com/story/INW20020213S0002
> 
> > -----Original Message-----
> > From: Tricha Anjali [mailto:tricha@ece.gatech.edu]
> > Sent: Monday, February 25, 2002 9:38 AM
> > To: rap@ops.ietf.org
> > Cc: Ian F. Akyildiz
> > Subject: COPS vs. SNMP
> > 
> > 
> > 
> > Hello,
> > 
> > We have been following the IETF activities concerning the 
> > ongoing work in
> > the fields of SNMP and COPS. It seems that at the meeting in 
> > March 2000 in
> > Adelaide, the snmpconf working group was formed for issues 
> > dealing with
> > policy-based network management after the BOF about network 
> > management in
> > Dec 1999. However, now the group seems to have accomplished 
> > its charter
> > and finished. Does this mean that the discussion has been resolved?
> > 
> > We would like to know if the resource reservation in a 
> > network can/should
> > be achieved via COPS? If yes, how is it advantageous over SNMP?
> > 
> > Any help will be appreciated!
> > 
> > Thanks in advance,
> > 
> > Tricha
> > 
> > -------------------------------
> > Tricha Anjali
> > Broadband & Wireless Networking Lab
> > School of Electrical and Computer Engineering
> > Georgia Institute of Technology
> > http://users.ece.gatech.edu/~tricha/
> > 
> > 
> > 
> > 
> 



From owner-rap@ops.ietf.org  Mon Feb 25 14:17:30 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25690
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 14:17:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fQcd-0008jf-00
	for rap-data@psg.com; Mon, 25 Feb 2002 11:17:15 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fQcc-0008jY-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 11:17:14 -0800
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id TAA06819
	for <rap@ops.ietf.org>; Mon, 25 Feb 2002 19:17:12 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022511175510949
 ; Mon, 25 Feb 2002 11:17:55 -0800
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <1YP2GSPM>; Mon, 25 Feb 2002 11:17:12 -0800
Message-ID: <65D5A07B5098D511BDDA0002A508E64F01D0289C@orsmsx110.jf.intel.com>
From: "Sahita, Ravi" <ravi.sahita@intel.com>
To: "'Tricha Anjali'" <tricha@ece.gatech.edu>, rap@ops.ietf.org
Cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 11:17:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Tricha,

Thanks for tracking the COPS activity in the IETF.
Within the RAP wg, the COPS base protocol, and the 
extensions - COPS for RSVP and COPS-PR have been RFC'ed.
These are RFC 2748, 2749 and 3084 respectively. 
SPPI describes the PIB language spec which
is one of the data models COPS-PR can carry. This
is described in RFC 3159.

Regarding COPS-PR features, some important notions are 
described in the COPS-PR RFC 3084 in Section 1.1.

Also, David Harrington sent this info on the list a few days
back - Erik Liden and Anders Torger wrote a master's thesis 
in January 2000 on the "Implementation and Evaluation of the 
Common Open Policy Service (COPS) Protocol and its use for 
Policy Provisioning" that you might want to review.
Its at http://extwww.lulea.trab.se/cops/

Intel has an open source COPS Client SDK for the above
specifications at http://www.intel.com/labs/manage/cops/
There will be an update soon that will include a client side 
PIB Control Interface Generator.

Hope that helps.
Ravi


-----Original Message-----
From: Tricha Anjali [mailto:tricha@ece.gatech.edu] 
Sent: Monday, February 25, 2002 9:38 AM
To: rap@ops.ietf.org
Cc: Ian F. Akyildiz
Subject: COPS vs. SNMP



Hello,

We have been following the IETF activities concerning the ongoing work in
the fields of SNMP and COPS. It seems that at the meeting in March 2000 in
Adelaide, the snmpconf working group was formed for issues dealing with
policy-based network management after the BOF about network management in
Dec 1999. However, now the group seems to have accomplished its charter and
finished. Does this mean that the discussion has been resolved?

We would like to know if the resource reservation in a network can/should be
achieved via COPS? If yes, how is it advantageous over SNMP?

Any help will be appreciated!

Thanks in advance,

Tricha

-------------------------------
Tricha Anjali
Broadband & Wireless Networking Lab
School of Electrical and Computer Engineering
Georgia Institute of Technology http://users.ece.gatech.edu/~tricha/






From owner-rap@ops.ietf.org  Mon Feb 25 14:27:03 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26167
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 14:27:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fQm2-0008uV-00
	for rap-data@psg.com; Mon, 25 Feb 2002 11:26:58 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fQm2-0008uP-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 11:26:58 -0800
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id TAA11308
	for <rap@ops.ietf.org>; Mon, 25 Feb 2002 19:26:57 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022511295428767
 ; Mon, 25 Feb 2002 11:29:54 -0800
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <FJAQJG5F>; Mon, 25 Feb 2002 11:26:57 -0800
Message-ID: <10C8636AE359D4119118009027AE99870DA5DE30@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, rap@ops.ietf.org
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 11:26:56 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-rap@ops.ietf.org
Precedence: bulk

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> 
> David, I am not sure what you are trying to tell people?


[Dave] That before we start calling SNMPConf Done, we should take a step
back and carefully consider the security issues associated with allowing
local scripts to control the configuration of a device. Seems there is more
work to do here.
> 
> The SNMP CERT advisories have NOT talked about a flaw
> in the SNMP Protocol at all. They have talked about implementation
> bugs. Further, it seems that most implementation bugs have been
> in the area of not properly decoding BER encoded SNMP packets.
> 
[Dave] Perhaps, but that raises serious questions about using the current
installed base of SNMP for configuration. It is not clear to me where a
problem with implementations is to blame vs. the protocol definitions. There
are a lot of SHOULDs and MAYs in the specs that help contribute to
implementations going awry.  

> Since the COPS-PR with PIB approach also uses BER encoding for
> sending the configuration/policy information, I would suspect
> that COPS-PR implementations have the same potential risks!!!
> 
[Dave] COPS and COPS-PR security mechanisms are NOT BER-based. The security
mechanisms use fixed size COPS objects and tried & true TCP security
mechanisms. Once the persistent & secure client/server communication is
established, only then does BER come into play. Even then, the BER objects
are still wrapped in COPS objects, providing an extra level of validation to
avoid buffer overruns and the like. 

... But I think it is good to analyze COPS-PR in this regard. Certainly, we
should be assured that CERT will have no issues with COPS-PR in the future.
   
> Bert
> 
> > -----Original Message-----
> > From: Durham, David [mailto:david.durham@intel.com]
> > Sent: Monday, February 25, 2002 7:32 PM
> > To: 'Tricha Anjali'; rap@ops.ietf.org
> > Cc: Ian F. Akyildiz
> > Subject: RE: COPS vs. SNMP
> >
> >
> > I'm interested in what the industry adoption of SNMPConf is/will be.
> > Particularly given that CERT is already advising that
> > administrators TURN
> > SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of
> > CERT advisories
> > and other bad press due to its
> > troubling susceptibilities. Now just imagine allowing people
> > to actually
> > download viruses and worms via SNMPConf PM MIB's Scripts.
> > -Dave
> >
> > http://www.internetwk.com/story/INW20020213S0002
> >
> > > -----Original Message-----
> > > From: Tricha Anjali [mailto:tricha@ece.gatech.edu]
> > > Sent: Monday, February 25, 2002 9:38 AM
> > > To: rap@ops.ietf.org
> > > Cc: Ian F. Akyildiz
> > > Subject: COPS vs. SNMP
> > >
> > >
> > >
> > > Hello,
> > >
> > > We have been following the IETF activities concerning the
> > > ongoing work in
> > > the fields of SNMP and COPS. It seems that at the meeting in
> > > March 2000 in
> > > Adelaide, the snmpconf working group was formed for issues
> > > dealing with
> > > policy-based network management after the BOF about network
> > > management in
> > > Dec 1999. However, now the group seems to have accomplished
> > > its charter
> > > and finished. Does this mean that the discussion has been resolved?
> > >
> > > We would like to know if the resource reservation in a
> > > network can/should
> > > be achieved via COPS? If yes, how is it advantageous over SNMP?
> > >
> > > Any help will be appreciated!
> > >
> > > Thanks in advance,
> > >
> > > Tricha
> > >
> > > -------------------------------
> > > Tricha Anjali
> > > Broadband & Wireless Networking Lab
> > > School of Electrical and Computer Engineering
> > > Georgia Institute of Technology
> > > http://users.ece.gatech.edu/~tricha/
> > >
> > >
> > >
> > >
> >



From owner-rap@ops.ietf.org  Mon Feb 25 15:23:46 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28454
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 15:23:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fRed-0009wo-00
	for rap-data@psg.com; Mon, 25 Feb 2002 12:23:23 -0800
Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fRec-0009wi-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 12:23:22 -0800
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA26057;
	Mon, 25 Feb 2002 15:31:38 -0500 (EST)
Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1)
	id xma025989; Mon, 25 Feb 02 15:30:36 -0500
Received: by smtp.enterasys.com with Internet Mail Service (5.5.2653.19)
	id <FK5RLXVG>; Mon, 25 Feb 2002 15:20:04 -0500
Message-ID: <0BF8B32B723ED5119E0B0002A551748B03054528@corp-exc3.ctron.com>
From: "Harrington, David" <dbh@enterasys.com>
To: "'Tricha Anjali'" <tricha@ece.gatech.edu>, rap@ops.ietf.org,
        "snmpconf@snmp. com (E-mail)" <snmpconf@snmp.com>
Cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 15:19:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BE39.C31FF7B0"
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_01C1BE39.C31FF7B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Tricha,

I recommend that if you want answers from both sides of the issue of COPS/PR
versus SNMPCONF, you should send your mail to both the RAP WG and the
SNMPCONF WG. And you should be prepared for very biased, and often
inflammatory and misleading, information from both sides.

There are a number of differences between these two approaches, and neither
is a clear winner. I don't find either approach compelling, but I need to
recuse myself, since I have been a co-chair of the SNMPCONF WG in the past,
and have done work on the COPS/PR specifications. You'll need decide for
yourself which is best. I'll give you an overview of things to look for when
doing your analysis, and I'll try to be neutral. 

I have two sections. One compares their provisioning ability; the second
deals with security issues. You'll need to decide what's important to you
and your customers.

COPS/PR:
Advantages: Designed specifically for provisioning with all the benefits of
a protocol designed for the purpose at hand. Event-driven. Object-oriented.
Includes explicit provisions for fail-over, role-combinations, and other
provisioning-related issues. Able to provision SNMP MIBs, taking advantage
of 10,000+ managed objects. Currently depends on SNMP protocol for
monitoring, which is widely deployed. 
Disadvantages: It is a new protocol not supported on most existing hardware;
no hard data about how robust or useful it is as a protocol. The PIB
approach is a new mechanism and there is no hard data about how robust or
useful it is for expressing policies. The integration between COPS/PR and
SNMP has not been fully specified, so applications will need to provide much
of the integration "outside" the two protocols. Since it builds upon SNMP
data modeling and depends on SNMP monitoring, it suffers all the
disadvantages of SNMP when doing data modeling and monitoring.

SNMPCONF:
Advantages: Uses existing SNMP protocol and architecture, with twelve years
as a widely-deployed, robust and useful protocol standard for monitoring;
lack of security in SNMPv1 has severely limited its use for provisioning.
SNMP protocol can be used in a polling-driven or event-driven approach
(typically it has been polling-based due to the unreliability of SNMPv1/UDP
traps). Able to provision SNMP MIBs, taking advantage of 10,000+ managed
objects. Uses SNMP both for provisioning and monitoring, so data is fairly
easily correlated.
Disadvantages: Depends on an administrator developing policies using a
scripting language that is the amalgum of multiple existing languages.  This
new programming language is not supported on existing devices, and has no
hard data about how robust or useful it is for expressing policies. Since it
builds upon SNMP data modeling and depends on SNMP for provisioning and
monitoring, it suffers all the disadvantages of SNMP when doing data
modeling and provisioning or monitoring.


There are differences in security: 
SNMPCONF ties into SNMPv3 security, which is not widely deployed, but which
addresses user-based authentication and administrator configurable
authorization. Encryption provides a tunnel between the manager application
and the agent. The integration of the division of responsibility between
SNMPCONF policies and SNMPv3 access control has not been clearly defined,
although the same administrators are likely to write the policies and
configure the access control.
COPS/PR security depends on IPSec, which uses host-based authentication.
IPSec encryption typically provides a tunnel between the host running the
manager application and the device running the agent. The host-based
approach may or may not be adequate depending on the division of
responsibilities in an organization. Authorization to manipulate
provisioning data depends on clearly separated responsibilities of clients
that may be produced by different vendors; different vendors may divide
responsibilities differently making it more difficult to write
vendor-neutral policies. The integration of the division of responsibility
between COPS/PR policies and SNMPv3 access control has not been clearly
defined; COPS/PR division of responsibility is largely
client-vendor-dependent, while SNMPv3 access control is configured by the
network administrator.

I'm sure both sides will find fault with my analysis. You'll need to do your
own analysis to determine how they compare for the purpose to which you want
to put them. Hopefully my suggestions will give you some idea of the things
to look at more closely.

dbh
---
David Harrington            
dbh@enterasys.com           
co-chair, IETF SNMPv3 WG


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, February 25, 2002 1:49 PM
> To: Durham, David; 'Tricha Anjali'; rap@ops.ietf.org
> Cc: Ian F. Akyildiz
> Subject: RE: COPS vs. SNMP
> 
> 
> David, I am not sure what you are trying to tell people?
> 
> The SNMP CERT advisories have NOT talked about a flaw
> in the SNMP Protocol at all. They have talked about implementation
> bugs. Further, it seems that most implementation bugs have been
> in the area of not properly decoding BER encoded SNMP packets.
> 
> Since the COPS-PR with PIB approach also uses BER encoding for
> sending the configuration/policy information, I would suspect
> that COPS-PR implementations have the same potential risks!!!
> 
> Bert 
> 
> > -----Original Message-----
> > From: Durham, David [mailto:david.durham@intel.com]
> > Sent: Monday, February 25, 2002 7:32 PM
> > To: 'Tricha Anjali'; rap@ops.ietf.org
> > Cc: Ian F. Akyildiz
> > Subject: RE: COPS vs. SNMP
> > 
> > 
> > I'm interested in what the industry adoption of SNMPConf is/will be.
> > Particularly given that CERT is already advising that 
> > administrators TURN
> > SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of 
> > CERT advisories
> > and other bad press due to its
> > troubling susceptibilities. Now just imagine allowing people 
> > to actually
> > download viruses and worms via SNMPConf PM MIB's Scripts.
> > -Dave
> > 
> > http://www.internetwk.com/story/INW20020213S0002
> > 
> > > -----Original Message-----
> > > From: Tricha Anjali [mailto:tricha@ece.gatech.edu]
> > > Sent: Monday, February 25, 2002 9:38 AM
> > > To: rap@ops.ietf.org
> > > Cc: Ian F. Akyildiz
> > > Subject: COPS vs. SNMP
> > > 
> > > 
> > > 
> > > Hello,
> > > 
> > > We have been following the IETF activities concerning the 
> > > ongoing work in
> > > the fields of SNMP and COPS. It seems that at the meeting in 
> > > March 2000 in
> > > Adelaide, the snmpconf working group was formed for issues 
> > > dealing with
> > > policy-based network management after the BOF about network 
> > > management in
> > > Dec 1999. However, now the group seems to have accomplished 
> > > its charter
> > > and finished. Does this mean that the discussion has been 
> resolved?
> > > 
> > > We would like to know if the resource reservation in a 
> > > network can/should
> > > be achieved via COPS? If yes, how is it advantageous over SNMP?
> > > 
> > > Any help will be appreciated!
> > > 
> > > Thanks in advance,
> > > 
> > > Tricha
> > > 
> > > -------------------------------
> > > Tricha Anjali
> > > Broadband & Wireless Networking Lab
> > > School of Electrical and Computer Engineering
> > > Georgia Institute of Technology
> > > http://users.ece.gatech.edu/~tricha/
> > > 
> > > 
> > > 
> > > 
> > 
> 

------_=_NextPart_001_01C1BE39.C31FF7B0
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.2653.12">
<TITLE>RE: COPS vs. SNMP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Tricha,</FONT>
</P>

<P><FONT SIZE=3D2>I recommend that if you want answers from both sides =
of the issue of COPS/PR versus SNMPCONF, you should send your mail to =
both the RAP WG and the SNMPCONF WG. And you should be prepared for =
very biased, and often inflammatory and misleading, information from =
both sides.</FONT></P>

<P><FONT SIZE=3D2>There are a number of differences between these two =
approaches, and neither is a clear winner. I don't find either approach =
compelling, but I need to recuse myself, since I have been a co-chair =
of the SNMPCONF WG in the past, and have done work on the COPS/PR =
specifications. You'll need decide for yourself which is best. I'll =
give you an overview of things to look for when doing your analysis, =
and I'll try to be neutral. </FONT></P>

<P><FONT SIZE=3D2>I have two sections. One compares their provisioning =
ability; the second deals with security issues. You'll need to decide =
what's important to you and your customers.</FONT></P>

<P><FONT SIZE=3D2>COPS/PR:</FONT>
<BR><FONT SIZE=3D2>Advantages: Designed specifically for provisioning =
with all the benefits of a protocol designed for the purpose at hand. =
Event-driven. Object-oriented. Includes explicit provisions for =
fail-over, role-combinations, and other provisioning-related issues. =
Able to provision SNMP MIBs, taking advantage of 10,000+ managed =
objects. Currently depends on SNMP protocol for monitoring, which is =
widely deployed. </FONT></P>

<P><FONT SIZE=3D2>Disadvantages: It is a new protocol not supported on =
most existing hardware; no hard data about how robust or useful it is =
as a protocol. The PIB approach is a new mechanism and there is no hard =
data about how robust or useful it is for expressing policies. The =
integration between COPS/PR and SNMP has not been fully specified, so =
applications will need to provide much of the integration =
&quot;outside&quot; the two protocols. Since it builds upon SNMP data =
modeling and depends on SNMP monitoring, it suffers all the =
disadvantages of SNMP when doing data modeling and =
monitoring.</FONT></P>

<P><FONT SIZE=3D2>SNMPCONF:</FONT>
<BR><FONT SIZE=3D2>Advantages: Uses existing SNMP protocol and =
architecture, with twelve years as a widely-deployed, robust and useful =
protocol standard for monitoring; lack of security in SNMPv1 has =
severely limited its use for provisioning. SNMP protocol can be used in =
a polling-driven or event-driven approach (typically it has been =
polling-based due to the unreliability of SNMPv1/UDP traps). Able to =
provision SNMP MIBs, taking advantage of 10,000+ managed objects. Uses =
SNMP both for provisioning and monitoring, so data is fairly easily =
correlated.</FONT></P>

<P><FONT SIZE=3D2>Disadvantages: Depends on an administrator developing =
policies using a scripting language that is the amalgum of multiple =
existing languages.&nbsp; This new programming language is not =
supported on existing devices, and has no hard data about how robust or =
useful it is for expressing policies. Since it builds upon SNMP data =
modeling and depends on SNMP for provisioning and monitoring, it =
suffers all the disadvantages of SNMP when doing data modeling and =
provisioning or monitoring.</FONT></P>
<BR>

<P><FONT SIZE=3D2>There are differences in security: </FONT>
<BR><FONT SIZE=3D2>SNMPCONF ties into SNMPv3 security, which is not =
widely deployed, but which addresses user-based authentication and =
administrator configurable authorization. Encryption provides a tunnel =
between the manager application and the agent. The integration of the =
division of responsibility between SNMPCONF policies and SNMPv3 access =
control has not been clearly defined, although the same administrators =
are likely to write the policies and configure the access control.</FONT=
></P>

<P><FONT SIZE=3D2>COPS/PR security depends on IPSec, which uses =
host-based authentication. IPSec encryption typically provides a tunnel =
between the host running the manager application and the device running =
the agent. The host-based approach may or may not be adequate depending =
on the division of responsibilities in an organization. Authorization =
to manipulate provisioning data depends on clearly separated =
responsibilities of clients that may be produced by different vendors; =
different vendors may divide responsibilities differently making it =
more difficult to write vendor-neutral policies. The integration of the =
division of responsibility between COPS/PR policies and SNMPv3 access =
control has not been clearly defined; COPS/PR division of =
responsibility is largely client-vendor-dependent, while SNMPv3 access =
control is configured by the network administrator.</FONT></P>

<P><FONT SIZE=3D2>I'm sure both sides will find fault with my analysis. =
You'll need to do your own analysis to determine how they compare for =
the purpose to which you want to put them. Hopefully my suggestions =
will give you some idea of the things to look at more =
closely.</FONT></P>

<P><FONT SIZE=3D2>dbh</FONT>
<BR><FONT SIZE=3D2>---</FONT>
<BR><FONT SIZE=3D2>David =
Harrington&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; </FONT>
<BR><FONT =
SIZE=3D2>dbh@enterasys.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>co-chair, IETF SNMPv3 WG</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Wijnen, Bert (Bert) [<A =
HREF=3D"mailto:bwijnen@lucent.com">mailto:bwijnen@lucent.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Monday, February 25, 2002 1:49 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Durham, David; 'Tricha Anjali'; =
rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Ian F. Akyildiz</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: COPS vs. SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David, I am not sure what you are trying to =
tell people?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The SNMP CERT advisories have NOT talked about =
a flaw</FONT>
<BR><FONT SIZE=3D2>&gt; in the SNMP Protocol at all. They have talked =
about implementation</FONT>
<BR><FONT SIZE=3D2>&gt; bugs. Further, it seems that most =
implementation bugs have been</FONT>
<BR><FONT SIZE=3D2>&gt; in the area of not properly decoding BER =
encoded SNMP packets.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Since the COPS-PR with PIB approach also uses =
BER encoding for</FONT>
<BR><FONT SIZE=3D2>&gt; sending the configuration/policy information, I =
would suspect</FONT>
<BR><FONT SIZE=3D2>&gt; that COPS-PR implementations have the same =
potential risks!!!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bert </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Durham, David [<A =
HREF=3D"mailto:david.durham@intel.com">mailto:david.durham@intel.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Monday, February 25, 2002 7:32 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Tricha Anjali'; =
rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: Ian F. Akyildiz</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: COPS vs. SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I'm interested in what the industry =
adoption of SNMPConf is/will be.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Particularly given that CERT is already =
advising that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; administrators TURN</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SNMP OFF! Eg. SNMP is currently undergoing =
a maelstrom of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CERT advisories</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and other bad press due to its</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; troubling susceptibilities. Now just =
imagine allowing people </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to actually</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; download viruses and worms via SNMPConf PM =
MIB's Scripts.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://www.internetwk.com/story/INW20020213S0002" =
TARGET=3D"_blank">http://www.internetwk.com/story/INW20020213S0002</A></=
FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Tricha Anjali [<A =
HREF=3D"mailto:tricha@ece.gatech.edu">mailto:tricha@ece.gatech.edu</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Monday, February 25, 2002 9:38 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: Ian F. Akyildiz</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: COPS vs. SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; We have been following the IETF =
activities concerning the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ongoing work in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the fields of SNMP and COPS. It seems =
that at the meeting in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; March 2000 in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Adelaide, the snmpconf working group =
was formed for issues </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; dealing with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; policy-based network management after =
the BOF about network </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; management in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Dec 1999. However, now the group =
seems to have accomplished </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; its charter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and finished. Does this mean that the =
discussion has been </FONT>
<BR><FONT SIZE=3D2>&gt; resolved?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; We would like to know if the resource =
reservation in a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; network can/should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; be achieved via COPS? If yes, how is =
it advantageous over SNMP?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Any help will be appreciated!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Thanks in advance,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Tricha</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
-------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Tricha Anjali</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Broadband &amp; Wireless Networking =
Lab</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; School of Electrical and Computer =
Engineering</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Georgia Institute of =
Technology</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; <A =
HREF=3D"http://users.ece.gatech.edu/~tricha/" =
TARGET=3D"_blank">http://users.ece.gatech.edu/~tricha/</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BE39.C31FF7B0--



From owner-rap@ops.ietf.org  Mon Feb 25 19:51:27 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05202
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 19:51:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fVpE-000Eo1-00
	for rap-data@psg.com; Mon, 25 Feb 2002 16:50:36 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fVpC-000Eni-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 16:50:34 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id AAA14196
	for <rap@ops.ietf.org>; Tue, 26 Feb 2002 00:50:32 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022516493931712
 ; Mon, 25 Feb 2002 16:49:39 -0800
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <19D3MVQP>; Mon, 25 Feb 2002 16:50:31 -0800
Message-ID: <B9ECACBD6885D5119ADC00508B68C1EA07316EEC@orsmsx107.jf.intel.com>
From: "Kulkarni, Amol" <amol.kulkarni@intel.com>
To: "'Harrington, David'" <dbh@enterasys.com>,
        "'Tricha Anjali'"<tricha@ece.gatech.edu>,
        "'rap@ops.ietf.org'" <rap@ops.ietf.org>,
        "'snmpconf@snmp. com (E-mail)'" <snmpconf@snmp.com>
Cc: "'Ian F. Akyildiz'" <ian@ece.gatech.edu>
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 16:50:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BE5F.924B8D40"
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_01C1BE5F.924B8D40
Content-Type: text/plain

David,
 
I'd like to add to/correct some of what you said about COPS-PR security. 
 
COPS-PR security is not restricted to IPSec. In fact, the draft 'COPS over
TLS', which has passed last call, describes how TLS can be used to secure
COPS.
 
Amol
 
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com] 
Sent: Monday, February 25, 2002 12:20 PM
To: 'Tricha Anjali'; rap@ops.ietf.org; snmpconf@snmp. com (E-mail)
Cc: Ian F. Akyildiz
Subject: RE: COPS vs. SNMP
 
Hi Tricha, 
I recommend that if you want answers from both sides of the issue of COPS/PR
versus SNMPCONF, you should send your mail to both the RAP WG and the
SNMPCONF WG. And you should be prepared for very biased, and often
inflammatory and misleading, information from both sides.
There are a number of differences between these two approaches, and neither
is a clear winner. I don't find either approach compelling, but I need to
recuse myself, since I have been a co-chair of the SNMPCONF WG in the past,
and have done work on the COPS/PR specifications. You'll need decide for
yourself which is best. I'll give you an overview of things to look for when
doing your analysis, and I'll try to be neutral. 
I have two sections. One compares their provisioning ability; the second
deals with security issues. You'll need to decide what's important to you
and your customers.
COPS/PR: 
Advantages: Designed specifically for provisioning with all the benefits of
a protocol designed for the purpose at hand. Event-driven. Object-oriented.
Includes explicit provisions for fail-over, role-combinations, and other
provisioning-related issues. Able to provision SNMP MIBs, taking advantage
of 10,000+ managed objects. Currently depends on SNMP protocol for
monitoring, which is widely deployed. 
Disadvantages: It is a new protocol not supported on most existing hardware;
no hard data about how robust or useful it is as a protocol. The PIB
approach is a new mechanism and there is no hard data about how robust or
useful it is for expressing policies. The integration between COPS/PR and
SNMP has not been fully specified, so applications will need to provide much
of the integration "outside" the two protocols. Since it builds upon SNMP
data modeling and depends on SNMP monitoring, it suffers all the
disadvantages of SNMP when doing data modeling and monitoring.
SNMPCONF: 
Advantages: Uses existing SNMP protocol and architecture, with twelve years
as a widely-deployed, robust and useful protocol standard for monitoring;
lack of security in SNMPv1 has severely limited its use for provisioning.
SNMP protocol can be used in a polling-driven or event-driven approach
(typically it has been polling-based due to the unreliability of SNMPv1/UDP
traps). Able to provision SNMP MIBs, taking advantage of 10,000+ managed
objects. Uses SNMP both for provisioning and monitoring, so data is fairly
easily correlated.
Disadvantages: Depends on an administrator developing policies using a
scripting language that is the amalgum of multiple existing languages.  This
new programming language is not supported on existing devices, and has no
hard data about how robust or useful it is for expressing policies. Since it
builds upon SNMP data modeling and depends on SNMP for provisioning and
monitoring, it suffers all the disadvantages of SNMP when doing data
modeling and provisioning or monitoring.
 
There are differences in security: 
SNMPCONF ties into SNMPv3 security, which is not widely deployed, but which
addresses user-based authentication and administrator configurable
authorization. Encryption provides a tunnel between the manager application
and the agent. The integration of the division of responsibility between
SNMPCONF policies and SNMPv3 access control has not been clearly defined,
although the same administrators are likely to write the policies and
configure the access control.
COPS/PR security depends on IPSec, which uses host-based authentication.
IPSec encryption typically provides a tunnel between the host running the
manager application and the device running the agent. The host-based
approach may or may not be adequate depending on the division of
responsibilities in an organization. Authorization to manipulate
provisioning data depends on clearly separated responsibilities of clients
that may be produced by different vendors; different vendors may divide
responsibilities differently making it more difficult to write
vendor-neutral policies. The integration of the division of responsibility
between COPS/PR policies and SNMPv3 access control has not been clearly
defined; COPS/PR division of responsibility is largely
client-vendor-dependent, while SNMPv3 access control is configured by the
network administrator.
I'm sure both sides will find fault with my analysis. You'll need to do your
own analysis to determine how they compare for the purpose to which you want
to put them. Hopefully my suggestions will give you some idea of the things
to look at more closely.
dbh 
--- 
David Harrington            
dbh@enterasys.com           
co-chair, IETF SNMPv3 WG 
 
> -----Original Message----- 
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com
<mailto:bwijnen@lucent.com> ] 
> Sent: Monday, February 25, 2002 1:49 PM 
> To: Durham, David; 'Tricha Anjali'; rap@ops.ietf.org 
> Cc: Ian F. Akyildiz 
> Subject: RE: COPS vs. SNMP 
> 
> 
> David, I am not sure what you are trying to tell people? 
> 
> The SNMP CERT advisories have NOT talked about a flaw 
> in the SNMP Protocol at all. They have talked about implementation 
> bugs. Further, it seems that most implementation bugs have been 
> in the area of not properly decoding BER encoded SNMP packets. 
> 
> Since the COPS-PR with PIB approach also uses BER encoding for 
> sending the configuration/policy information, I would suspect 
> that COPS-PR implementations have the same potential risks!!! 
> 
> Bert 
> 
> > -----Original Message----- 
> > From: Durham, David [mailto:david.durham@intel.com
<mailto:david.durham@intel.com> ] 
> > Sent: Monday, February 25, 2002 7:32 PM 
> > To: 'Tricha Anjali'; rap@ops.ietf.org 
> > Cc: Ian F. Akyildiz 
> > Subject: RE: COPS vs. SNMP 
> > 
> > 
> > I'm interested in what the industry adoption of SNMPConf is/will be. 
> > Particularly given that CERT is already advising that 
> > administrators TURN 
> > SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of 
> > CERT advisories 
> > and other bad press due to its 
> > troubling susceptibilities. Now just imagine allowing people 
> > to actually 
> > download viruses and worms via SNMPConf PM MIB's Scripts. 
> > -Dave 
> > 
> > http://www.internetwk.com/story/INW20020213S0002
<http://www.internetwk.com/story/INW20020213S0002>  
> > 
> > > -----Original Message----- 
> > > From: Tricha Anjali [mailto:tricha@ece.gatech.edu
<mailto:tricha@ece.gatech.edu> ] 
> > > Sent: Monday, February 25, 2002 9:38 AM 
> > > To: rap@ops.ietf.org 
> > > Cc: Ian F. Akyildiz 
> > > Subject: COPS vs. SNMP 
> > > 
> > > 
> > > 
> > > Hello, 
> > > 
> > > We have been following the IETF activities concerning the 
> > > ongoing work in 
> > > the fields of SNMP and COPS. It seems that at the meeting in 
> > > March 2000 in 
> > > Adelaide, the snmpconf working group was formed for issues 
> > > dealing with 
> > > policy-based network management after the BOF about network 
> > > management in 
> > > Dec 1999. However, now the group seems to have accomplished 
> > > its charter 
> > > and finished. Does this mean that the discussion has been 
> resolved? 
> > > 
> > > We would like to know if the resource reservation in a 
> > > network can/should 
> > > be achieved via COPS? If yes, how is it advantageous over SNMP? 
> > > 
> > > Any help will be appreciated! 
> > > 
> > > Thanks in advance, 
> > > 
> > > Tricha 
> > > 
> > > ------------------------------- 
> > > Tricha Anjali 
> > > Broadband & Wireless Networking Lab 
> > > School of Electrical and Computer Engineering 
> > > Georgia Institute of Technology 
> > > http://users.ece.gatech.edu/~tricha/
<http://users.ece.gatech.edu/~tricha/>  
> > > 
> > > 
> > > 
> > > 
> > 
> 

------_=_NextPart_001_01C1BE5F.924B8D40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1BE1C.83632880">
<title>RE: COPS vs. SNMP</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>David,<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'd like to add to/correct some of =
what
you said about COPS-PR security. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>COPS-PR security is not restricted =
to <span
class=3DSpellE>IPSec</span>. In fact, the draft 'COPS over TLS', which =
has passed
last call, describes how TLS can be used to secure =
COPS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Amol<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Harrington, David
[mailto:dbh@enterasys.com<span class=3DGramE>] <br>
<b><span style=3D'font-weight:bold'>Sent</span></b></span><b><span
style=3D'font-weight:bold'>:</span></b> Monday, February 25, 2002 12:20 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Tricha Anjali';
rap@ops.ietf.org; snmpconf@snmp. com (E-mail)<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Ian F. Akyildiz<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: COPS vs. =
SNMP</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Hi Tricha,</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I recommend that if you want answers from =
both sides
of the issue of COPS/PR versus SNMPCONF, you should send your mail to =
both the
RAP WG and the SNMPCONF WG. And you should be prepared for very biased, =
and
often inflammatory and misleading, information from both =
sides.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>There are a number of differences between =
these two
approaches, and neither is a clear winner. I don't find either approach
compelling, but I need to recuse myself, since I have been a co-chair =
of the
SNMPCONF WG in the past, and have done work on the COPS/PR =
specifications.
You'll need decide for yourself which is best. I'll give you an =
overview of
things to look for when doing your analysis, and I'll try to be =
neutral. </span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I have two sections. One compares their =
provisioning
ability; the second deals with security issues. You'll need to decide =
what's
important to you and your customers.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>COPS/PR:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Advantages: Designed =
specifically
for provisioning with all the benefits of a protocol designed for the =
purpose
at hand. Event-driven. Object-oriented. Includes explicit provisions =
for
fail-over, role-combinations, and other provisioning-related issues. =
Able to
provision SNMP MIBs, taking advantage of 10,000+ managed objects. =
Currently
depends on SNMP protocol for monitoring, which is widely deployed. =
</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Disadvantages: It is a new protocol not =
supported on
most existing hardware; no hard data about how robust or useful it is =
as a
protocol. The PIB approach is a new mechanism and there is no hard data =
about
how robust or useful it is for expressing policies. The integration =
between
COPS/PR and SNMP has not been fully specified, so applications will =
need to
provide much of the integration &quot;outside&quot; the two protocols. =
Since it
builds upon SNMP data modeling and depends on SNMP monitoring, it =
suffers all
the disadvantages of SNMP when doing data modeling and =
monitoring.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>SNMPCONF:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Advantages: Uses =
existing SNMP
protocol and architecture, with twelve years as a widely-deployed, =
robust and
useful protocol standard for monitoring; lack of security in SNMPv1 has =
severely
limited its use for provisioning. SNMP protocol can be used in a =
polling-driven
or event-driven approach (typically it has been polling-based due to =
the
unreliability of SNMPv1/UDP traps). Able to provision SNMP MIBs, taking
advantage of 10,000+ managed objects. Uses SNMP both for provisioning =
and
monitoring, so data is fairly easily =
correlated.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Disadvantages: Depends on an administrator =
developing
policies using a scripting language that is the amalgum of multiple =
existing
languages.&nbsp; This new programming language is not supported on =
existing
devices, and has no hard data about how robust or useful it is for =
expressing
policies. Since it builds upon SNMP data modeling and depends on SNMP =
for
provisioning and monitoring, it suffers all the disadvantages of SNMP =
when
doing data modeling and provisioning or =
monitoring.</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>There are differences in security: =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>SNMPCONF ties into =
SNMPv3 security,
which is not widely deployed, but which addresses user-based =
authentication and
administrator configurable authorization. Encryption provides a tunnel =
between
the manager application and the agent. The integration of the division =
of
responsibility between SNMPCONF policies and SNMPv3 access control has =
not been
clearly defined, although the same administrators are likely to write =
the
policies and configure the access control.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>COPS/PR security depends on IPSec, which =
uses
host-based authentication. IPSec encryption typically provides a tunnel =
between
the host running the manager application and the device running the =
agent. The
host-based approach may or may not be adequate depending on the =
division of
responsibilities in an organization. Authorization to manipulate =
provisioning
data depends on clearly separated responsibilities of clients that may =
be
produced by different vendors; different vendors may divide =
responsibilities differently
making it more difficult to write vendor-neutral policies. The =
integration of
the division of responsibility between COPS/PR policies and SNMPv3 =
access
control has not been clearly defined; COPS/PR division of =
responsibility is
largely client-vendor-dependent, while SNMPv3 access control is =
configured by
the network administrator.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I'm sure both sides will find fault with my =
analysis.
You'll need to do your own analysis to determine how they compare for =
the
purpose to which you want to put them. Hopefully my suggestions will =
give you
some idea of the things to look at more =
closely.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>dbh</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>---</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>David
Harrington&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; </span></font><br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>dbh@enterasys.com&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>co-chair, IETF SNMPv3 =
WG</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: Wijnen, Bert =
(Bert) [<a
href=3D"mailto:bwijnen@lucent.com">mailto:bwijnen@lucent.com</a>]</span>=
</font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Monday, =
February 25,
2002 1:49 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: Durham, David; =
'Tricha
Anjali'; rap@ops.ietf.org</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Cc: Ian F. =
Akyildiz</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: RE: COPS =
vs. SNMP</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; David, I am not =
sure what you
are trying to tell people?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The SNMP CERT =
advisories have
NOT talked about a flaw</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; in the SNMP =
Protocol at all.
They have talked about implementation</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; bugs. Further, it =
seems that
most implementation bugs have been</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; in the area of not =
properly
decoding BER encoded SNMP packets.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Since the COPS-PR =
with PIB
approach also uses BER encoding for</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; sending the
configuration/policy information, I would suspect</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; that COPS-PR =
implementations
have the same potential risks!!!</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Bert =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; -----Original =
Message-----</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; From: Durham, =
David [<a
href=3D"mailto:david.durham@intel.com">mailto:david.durham@intel.com</a>=
]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; Sent: Monday, =
February
25, 2002 7:32 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; To: 'Tricha =
Anjali';
rap@ops.ietf.org</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; Cc: Ian F. =
Akyildiz</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; Subject: RE: =
COPS vs. SNMP</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; I'm =
interested in what
the industry adoption of SNMPConf is/will be.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; Particularly =
given that
CERT is already advising that </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
administrators TURN</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; SNMP OFF! Eg. =
SNMP is
currently undergoing a maelstrom of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; CERT =
advisories</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; and other bad =
press due
to its</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; troubling
susceptibilities. Now just imagine allowing people </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; to =
actually</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; download =
viruses and
worms via SNMPConf PM MIB's Scripts.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
-Dave</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; <a
href=3D"http://www.internetwk.com/story/INW20020213S0002" =
target=3D"_blank">http://www.internetwk.com/story/INW20020213S0002</a></=
span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; From: =
Tricha Anjali
[<a =
href=3D"mailto:tricha@ece.gatech.edu">mailto:tricha@ece.gatech.edu</a>]<=
/span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Sent: =
Monday,
February 25, 2002 9:38 AM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; To: =
rap@ops.ietf.org</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Cc: Ian =
F. Akyildiz</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Subject: =
COPS vs.
SNMP</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
Hello,</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; We have =
been
following the IETF activities concerning the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; ongoing =
work in</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; the =
fields of SNMP
and COPS. It seems that at the meeting in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; March =
2000 in</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
Adelaide, the
snmpconf working group was formed for issues </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; dealing =
with</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
policy-based network
management after the BOF about network </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
management in</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Dec =
1999. However,
now the group seems to have accomplished </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; its =
charter</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; and =
finished. Does
this mean that the discussion has been </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
resolved?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; We would =
like to
know if the resource reservation in a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; network =
can/should</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; be =
achieved via
COPS? If yes, how is it advantageous over SNMP?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Any help =
will be
appreciated!</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Thanks =
in advance,</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
Tricha</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt;
-------------------------------</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Tricha =
Anjali</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
Broadband &amp;
Wireless Networking Lab</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; School =
of Electrical
and Computer Engineering</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; Georgia =
Institute of
Technology</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; <a
href=3D"http://users.ece.gatech.edu/~tricha/" =
target=3D"_blank">http://users.ece.gatech.edu/~tricha/</a></span></font>=

<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1BE5F.924B8D40--



From owner-rap@ops.ietf.org  Mon Feb 25 20:41:44 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05779
	for <rap-archive@lists.ietf.org>; Mon, 25 Feb 2002 20:41:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fWcZ-000FjD-00
	for rap-data@psg.com; Mon, 25 Feb 2002 17:41:35 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fWcY-000Fit-00
	for rap@ops.ietf.org; Mon, 25 Feb 2002 17:41:35 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id BAA07744
	for <rap@ops.ietf.org>; Tue, 26 Feb 2002 01:41:34 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022517404122443
 ; Mon, 25 Feb 2002 17:40:41 -0800
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <19D3M8Q9>; Mon, 25 Feb 2002 17:41:34 -0800
Message-ID: <10C8636AE359D4119118009027AE99870DA5DE36@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'Tricha Anjali'" <tricha@ece.gatech.edu>, rap@ops.ietf.org
Cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Subject: RE: COPS vs. SNMP
Date: Mon, 25 Feb 2002 17:41:33 -0800
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

Hi Tricha,

I think I forgot to address your second question. Yes, resource reservation
in a network can be achieved via COPS. Its primary advantage over SNMP is
that it was designed with this specific purpose in mind. Specifically:

* COPS-PR supports a completely transactional model:
	o Messages represent atomic transactions. 
	o All parts of a transaction either succeed or fail.
	o On failure, the device automatically rolls-back to its last
operational state.
	o The server can also quickly switch between provisioned contexts
(eg. from day policies to night policies).
	o Failures and errors are very precisely reported PEP to PDP.
	o Supports large transactions.
	o Implementations do not worry about caching random attributes
waiting for a complete transaction (as is a problem for SNMP), everything in
the transaction comes at once in one message.
* COPS-PR supports structured row-level access:
	o A row represents an atomic unit for data communication.
	o There is no need for rowstatus, owner strings and the like.
	o A row is essentially an indivisible structured data type.
	o OID data is sent only once per row, representing a 10x gain in
on-the-wire efficiency over SNMP for e.g. a packet classifier filter w/ 10
fields.
* COPS-PR supports multi-manager control without the danger of corruption:
	o Each PDP has its own data instance space on the PEP which cannot
be manipulated by other PDPs.
	o PDPs data instances are isolated by the message-level client-type
field.
* Completely event-driven:
	o There is no polling in COPS-PR. 
	o PEPs notify PDPs only when there is something to report and vice
versa.
	o Persistent TCP connection means no 3-way handshake overhead for
messages.
	o TCP heartbeat verifies aggregate communication over the connection
and confirms operational status.
* Multiple Levels of security:
	o COPS intrinsically provides message-level integrity with PEP and
PDP authentication.
	o COPS over TLS provides additional level of authentication and
private communication.
	o IPSec provides yet another level of authentication and privacy. 
	o ... All communication is secure before the first COPS-PR message
is even exchanged. 	
* Object-Oriented Data Model and Data Definition Language.
	o COPS-PR via the SPPI improves the state of the art over the SNMP
SMI.
		- Allows inheritance of data structures.
		- Allows typed references.
		- Allows structured containment.
		- Allows typed associations.
		- Allows typed groupings.
		- Adds support for Integer64 and other basic data types.
		- Maximizes reuse of data definitions.
	o Via the framework PIB provides a data model that can be
reused/shared across PIBs for common/redundant policy functions and
definitions.
	o All new PIB definitions can integrate with existing PIB
definitions to add features and capabilities.
	o Common data-path theme throughout COPS-PR PIBs.
* Capabilities Reporting:
	o COPS-PR via the framework PIB provides a mechanism by which the
PEP clearly yet generically describes what PIBs and parts of PIBs it
supports.
	o Both semantic and syntactic capabilities are generically
communicated PEP to PDP.
* COPS-PR integrates event outsourcing and provisioning:
	o Eg. when an RSVP message is signaled & outsourced PEP-PDP, a
diffserv provisioning policy can be pushed down.
	o Integrated provisioning and outsourcing can be accomplished over
one message RTT.
	o Policy usage information can be used to signal a policy change.
* COPS provides built-in synchronization and failover:
	o PEP automatically moves to backup PDPs on failure.
	o PDP quickly synchronizes state with PEP after communication
failure.
		- Quick last transaction ID verifies PEP state.
		- PDP can resynchronize all or any selected state.
	o Enables quick TCP session recovery.
* COPS-PR inherently was designed to run over reliable transport via TCP.


Well, anyway, these are some of the main reasons for COPS-PR that come to my
mind.

Cheers,
-Dave



> -----Original Message-----
> From: Tricha Anjali [mailto:tricha@ece.gatech.edu]
> Sent: Monday, February 25, 2002 9:38 AM
> To: rap@ops.ietf.org
> Cc: Ian F. Akyildiz
> Subject: COPS vs. SNMP
> 
> 
> 
> Hello,
> 
> We have been following the IETF activities concerning the 
> ongoing work in
> the fields of SNMP and COPS. It seems that at the meeting in 
> March 2000 in
> Adelaide, the snmpconf working group was formed for issues 
> dealing with
> policy-based network management after the BOF about network 
> management in
> Dec 1999. However, now the group seems to have accomplished 
> its charter
> and finished. Does this mean that the discussion has been resolved?
> 
> We would like to know if the resource reservation in a 
> network can/should
> be achieved via COPS? If yes, how is it advantageous over SNMP?
> 
> Any help will be appreciated!
> 
> Thanks in advance,
> 
> Tricha
> 
> -------------------------------
> Tricha Anjali
> Broadband & Wireless Networking Lab
> School of Electrical and Computer Engineering
> Georgia Institute of Technology
> http://users.ece.gatech.edu/~tricha/
> 
> 
> 
> 



From owner-rap@ops.ietf.org  Tue Feb 26 10:06:49 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02426
	for <rap-archive@lists.ietf.org>; Tue, 26 Feb 2002 10:06:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fjB8-0007ce-00
	for rap-data@psg.com; Tue, 26 Feb 2002 07:06:06 -0800
Received: from rip.psg.com ([147.28.0.39])
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fjB8-0007cY-00
	for rap@ops.ietf.org; Tue, 26 Feb 2002 07:06:06 -0800
Received: from randy by rip.psg.com with local (Exim 4.00)
	id 16fjB8-0000Tj-00
	for rap@ops.ietf.org; Tue, 26 Feb 2002 07:06:06 -0800
In-reply-to: <10C8636AE359D4119118009027AE99870DA5DE2E@FMSMSX34>
Message-id: <200202261245.26462.David.Partain@ericsson.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
References: <10C8636AE359D4119118009027AE99870DA5DE2E@FMSMSX34>
Date: Tue, 26 Feb 2002 12:45:26 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: COPS vs. SNMP
To: "Durham, David" <david.durham@intel.com>,
        "'Tricha Anjali'" <tricha@ece.gatech.edu>, rap@ops.ietf.org
Cc: "Ian F. Akyildiz" <ian@ece.gatech.edu>
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02426

Hi all,

On Monday 25 February 2002 19.31, Durham, David wrote:
> I'm interested in what the industry adoption of SNMPConf is/will be.

As co-chair of SNMPCONF, so am I :-)

> Particularly given that CERT is already advising that administrators TURN
> SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of CERT advisories
> and other bad press due to its
> troubling susceptibilities.

I'm very surprised that you would use FUD as a tool for pushing
COPS-PR.  Whether you like SNMP or not, using buffer overflow
problems in (some) SNMP agent implementations to do so seems
pretty ridiculous.

To set the record straight:

  - CERT didn't anything about the SNMP protocol

    That being said, there is NO ONE who thinks that SNMPv1 or
    SNMPv2c is secure.  The SNMP community is/has been pushing
    SNMPv3, which is on the brink of being Standard.

  - What CERT _did_ issue was an advisory about various security
    vulnerabilities in some SNMP implementations.  These
    vulnerabilities were brought to light by a group of
    researchers in Finland who created a set of test tools which
    send pretty whacked-out SNMP packets.  In some cases, the
    agents went belly-up when they got the packets.  In some
    cases, there is a risk that the agent will scribble on memory
    that it shouldn't.  Read the advisory (see below).

    There's no one saying that this is not a problem, but it's
    nothing more than Yet Another Buffer Overflow security
    problem.

To the best of my knowledge, no one's launched such a set
of tests against the COPS implementations.  Are you saying
that if some of these implementations go belly-up and have
buffer overflow problems that this will mean that COPS is an
inappropriate technology for configuration?

> Now just imagine allowing people to actually
> download viruses and worms via SNMPConf PM MIB's Scripts.

Pardon me, but where in the heck did that come from?  Assuming
secure authentication using SNMPv3 (which everyone is), in what
way do you mean that SNMPCONF would be enabling the spread of
viruses and worms?

> http://www.internetwk.com/story/INW20020213S0002

This, and many other articles in the press, just don't Get It.
They say "vulnerabilities that have been discovered in the
Simple Network Management Protocol (SNMP)", which is just wrong.

May I suggest that those who want to understand
should look at the CERT advisory instead of reading
incorrect interpretations by the press.  The advisory is at
http://www.cert.org/advisories/CA-2002-03.html and plainly says,
"Multiple Vulnerabilities in Many Implementations of the Simple
Network Management Protocol (SNMP)".  It says absolutely nothing
about "vulnerabilities ... in SNMP".  You'll also note that it
specifically talks about SNMPv1.

Now, back to your favorite "my protocol is prettier than your
protocol" discussion.

Cheers,

dlp





From owner-rap@ops.ietf.org  Tue Feb 26 12:09:27 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10683
	for <rap-archive@lists.ietf.org>; Tue, 26 Feb 2002 12:09:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fl5U-000Bzn-00
	for rap-data@psg.com; Tue, 26 Feb 2002 09:08:24 -0800
Received: from rip.psg.com ([147.28.0.39])
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fl5T-000Bzh-00
	for rap@ops.ietf.org; Tue, 26 Feb 2002 09:08:23 -0800
Received: from randy by rip.psg.com with local (Exim 4.00)
	id 16fl5T-0003v6-00
	for rap@ops.ietf.org; Tue, 26 Feb 2002 09:08:23 -0800
In-reply-to: <10C8636AE359D4119118009027AE99870DA5DE30@FMSMSX34>
Message-id: <200202261303.13763.David.Partain@ericsson.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
References: <10C8636AE359D4119118009027AE99870DA5DE30@FMSMSX34>
Date: Tue, 26 Feb 2002 13:03:13 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: COPS vs. SNMP
To: "Durham, David" <david.durham@intel.com>,
        "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, rap@ops.ietf.org
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10683

[ not posted from a subscriber address ]

Hi all,

bw = Bert
dd = David Durham

bw> David, I am not sure what you are trying to tell people?

dd> That before we start calling SNMPConf Done, we should take a step
dd> back and carefully consider the security issues associated with allowing
dd> local scripts to control the configuration of a device. Seems there is 
more
dd> work to do here.

Ah hah.  So it's the model of local control and local decision
making which makes you uncomfortable?  That someone would write
an application that they download to a machine and it runs on
that machine locally without relying on a higher-level entity to
take the decision?  I'm just trying to see where the gripe is.

I don't see that that has _anything_ whatsoever to do with SNMP
(which was the focus of your mail about the CERT advisory),
but it certainly is related to SNMPCONF (of course).  Of course,
this model has existed in DISMAN for a number of years, as well
as in various other areas of technology.

bw> The SNMP CERT advisories have NOT talked about a flaw
bw> in the SNMP Protocol at all. They have talked about implementation
bw> bugs. Further, it seems that most implementation bugs have been
bw> in the area of not properly decoding BER encoded SNMP packets.

dd> Perhaps,

It's not a question of "perhaps".  It's absolutely certain.
Please read the advisory.

dd> but that raises serious questions about using the current
dd> installed base of SNMP for configuration.

Of _course_ the current installed base is not appropriate for
configuration, if it's based on SNMPv1.  No one's claiming
anything else.

dd> It is not clear to me where a
dd> problem with implementations is to blame vs. the protocol definitions.

Maybe reading the CERT advisory will help.

dd> There are a lot of SHOULDs and MAYs in the specs that help contribute to
dd> implementations going awry.

In this case, it's classic programming errors in handling
buffers.  It's exactly the same kind of programming errors that
have affected a very wide range of available software from
OS kernels to web servers to printing systems, to....

Don't try to blame this on the protocol.  It won't fly.

bw> Since the COPS-PR with PIB approach also uses BER encoding for
bw> sending the configuration/policy information, I would suspect
bw> that COPS-PR implementations have the same potential risks!!!

dd> COPS and COPS-PR security mechanisms are NOT BER-based.

It has absolutely nothing to do with security mechanisms.
It's buffer overflows.

dd> The security
dd> mechanisms use fixed size COPS objects and tried & true TCP security
dd> mechanisms. Once the persistent & secure client/server communication is
dd> established, only then does BER come into play. Even then, the BER objects
dd> are still wrapped in COPS objects, providing an extra level of validation
dd> to avoid buffer overruns and the like.

If the folks writing COPS/COPS-PR code write perfect code,
I'm sure there'll never be any COPS-related problems with any
kind of denial of service or buffer overflow attack.

Cheers,

dlp






From owner-rap@ops.ietf.org  Tue Feb 26 21:14:05 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27800
	for <rap-archive@lists.ietf.org>; Tue, 26 Feb 2002 21:14:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16ftar-0007Ll-00
	for rap-data@psg.com; Tue, 26 Feb 2002 18:13:21 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16ftaq-0007Lb-00
	for rap@ops.ietf.org; Tue, 26 Feb 2002 18:13:20 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id CAA24640
	for <rap@ops.ietf.org>; Wed, 27 Feb 2002 02:13:19 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022618122619573
 ; Tue, 26 Feb 2002 18:12:26 -0800
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <FJBKQBXQ>; Tue, 26 Feb 2002 18:13:19 -0800
Message-ID: <10C8636AE359D4119118009027AE99870DA5DE3F@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        rap@ops.ietf.org
Subject: RE: COPS vs. SNMP
Date: Tue, 26 Feb 2002 18:13:11 -0800
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

Comments inline...

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: Tuesday, February 26, 2002 4:03 AM
> To: Durham, David; 'Wijnen, Bert (Bert)'; rap@ops.ietf.org
> Subject: Re: COPS vs. SNMP
>
[DaveD] ...

> I don't see that that has _anything_ whatsoever to do with SNMP
> (which was the focus of your mail about the CERT advisory),
> but it certainly is related to SNMPCONF (of course).  Of course,
> this model has existed in DISMAN for a number of years, as well
> as in various other areas of technology.
> 
[DaveD] The issue is two fold, 1. if the installed base of
protocol/implementations for whatever reason are being shut-off, then who
can do configuration management with SNMP? 2. Somebody should take a close
look at running local scripts to do policy control, specifically in the
context of SNMPConf... I've brought this up before, the CERT advisory is a
nice reminder to make sure some up-front attack prevention is done or at
least considered. Clearly defining the division of responsibility between PM
policy and SNMPv3 access-control would be a nice place to start.

> bw> The SNMP CERT advisories have NOT talked about a flaw
> bw> in the SNMP Protocol at all. They have talked about implementation
> dd> Perhaps,
> 
> It's not a question of "perhaps".  It's absolutely certain.
> Please read the advisory.

[DaveD] The advisory is not clear in this regard, I read it. Also, the press
reports clearly specify  that there are Vulnerabilities in the SNMP
Protocol. It was not clear if this was based ONLY on the cited CERT
advisory.
> 
> dd> There are a lot of SHOULDs and MAYs in the specs that 
> help contribute to
> dd> implementations going awry.
> 
> In this case, it's classic programming errors in handling
> buffers.  It's exactly the same kind of programming errors that
> have affected a very wide range of available software from
> OS kernels to web servers to printing systems, to....
> 
> Don't try to blame this on the protocol.  It won't fly.

[DaveD] Ummm, the protocol can make it more difficult for implementations to
get it right. Eg. XML provides nice begin tags and end tags. Or better yet,
fixed size fields are easier to implement than allowing everything to vary.
Allowing fields to vary (via the spec) within bounds specified with a lower
bound of MUST and an upper bound of SHOULD also adds to the complexity for
implementers.
> 
> dd> COPS and COPS-PR security mechanisms are NOT BER-based.
> 
> It has absolutely nothing to do with security mechanisms.
> It's buffer overflows.

[DaveD] If the protocol uses the BER encoded security mechanisms, and the
BER encodings are susceptible to buffer overflows,  then you can obviously
directly attack a machine through the BER encoded security mechanism itself!

> 
> dd> The security
> dd> mechanisms use fixed size COPS objects and tried & true 
> TCP security
> dd> mechanisms. Once the persistent & secure client/server 
> communication is
> dd> established, only then does BER come into play. Even 
> then, the BER objects
> dd> are still wrapped in COPS objects, providing an extra 
> level of validation
> dd> to avoid buffer overruns and the like.
> 
> If the folks writing COPS/COPS-PR code write perfect code,
> I'm sure there'll never be any COPS-related problems with any
> kind of denial of service or buffer overflow attack.

[DaveD] ... And I forgot to point out that the SPPI promotes better type
checking as well, and removes the need for those long, composit-INDEX OIDs
altogether. Keeping things easy for implementers is a good thing here!



From owner-rap@ops.ietf.org  Tue Feb 26 21:49:55 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29189
	for <rap-archive@lists.ietf.org>; Tue, 26 Feb 2002 21:49:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16fu9t-0008au-00
	for rap-data@psg.com; Tue, 26 Feb 2002 18:49:33 -0800
Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16fu9s-0008ao-00
	for rap@ops.ietf.org; Tue, 26 Feb 2002 18:49:32 -0800
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id VAA28490;
	Tue, 26 Feb 2002 21:59:07 -0500 (EST)
Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1)
	id xma028484; Tue, 26 Feb 02 21:59:01 -0500
Received: by smtp.enterasys.com with Internet Mail Service (5.5.2653.19)
	id <FK5RNB3J>; Tue, 26 Feb 2002 21:48:26 -0500
Message-ID: <0BF8B32B723ED5119E0B0002A551748B0305453E@corp-exc3.ctron.com>
From: "Harrington, David" <dbh@enterasys.com>
To: "'Durham, David'" <david.durham@intel.com>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        rap@ops.ietf.org
Subject: RE: COPS vs. SNMP
Date: Tue, 26 Feb 2002 21:48:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BF39.33FA0930"
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_01C1BF39.33FA0930
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Durham, David [mailto:david.durham@intel.com]
> 
> > bw> The SNMP CERT advisories have NOT talked about a flaw
> > bw> in the SNMP Protocol at all. They have talked about 
> implementation
> > dd> Perhaps,
> > 
> > It's not a question of "perhaps".  It's absolutely certain.
> > Please read the advisory.
> 
> [DaveD] The advisory is not clear in this regard, I read it. 

What is not clear about this text from the advisory?
"Numerous vulnerabilities have been reported in multiple vendors' SNMP
implementations."
[Oulu] "has reported numerous vulnerabilities in SNMPv1 implementations."

> Also, the press
> reports clearly specify  that there are Vulnerabilities in the SNMP
> Protocol. It was not clear if this was based ONLY on the cited CERT
> advisory.

So we look to the press to provide us protocol designers with solid
technical information now? Oh my! 

I hope COPS wasn't designed by the journalists.... ;-)

As far as the recommendation to disable SNMP, the advisory reads:
"As a general rule, the CERT/CC recommends disabling any service or
capability that is not explicitly required, including SNMP." So, using your
logic, if I have devices that don't need COPS/PR, then COPS/PR must not be
suitable for provisioning?

Get a clue. Understand what the CERT advisory is about before you try to use
it to justify COPS/PR.

I expected better from you.
dbh

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
 

------_=_NextPart_001_01C1BF39.33FA0930
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.2653.12">
<TITLE>RE: COPS vs. SNMP</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Durham, David [<A =
HREF=3D"mailto:david.durham@intel.com">mailto:david.durham@intel.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; bw&gt; The SNMP CERT advisories have NOT =
talked about a flaw</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; bw&gt; in the SNMP Protocol at all. They =
have talked about </FONT>
<BR><FONT SIZE=3D2>&gt; implementation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; dd&gt; Perhaps,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It's not a question of =
&quot;perhaps&quot;.&nbsp; It's absolutely certain.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Please read the advisory.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [DaveD] The advisory is not clear in this =
regard, I read it. </FONT>
</P>

<P><FONT SIZE=3D2>What is not clear about this text from the =
advisory?</FONT>
<BR><FONT SIZE=3D2>&quot;Numerous vulnerabilities have been reported in =
multiple vendors' SNMP implementations.&quot;</FONT>
<BR><FONT SIZE=3D2>[Oulu] &quot;has reported numerous vulnerabilities =
in SNMPv1 implementations.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Also, the press</FONT>
<BR><FONT SIZE=3D2>&gt; reports clearly specify&nbsp; that there are =
Vulnerabilities in the SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; Protocol. It was not clear if this was based =
ONLY on the cited CERT</FONT>
<BR><FONT SIZE=3D2>&gt; advisory.</FONT>
</P>

<P><FONT SIZE=3D2>So we look to the press to provide us protocol =
designers with solid technical information now? Oh my! </FONT>
</P>

<P><FONT SIZE=3D2>I hope COPS wasn't designed by the journalists.... =
;-)</FONT>
</P>

<P><FONT SIZE=3D2>As far as the recommendation to disable SNMP, the =
advisory reads:</FONT>
<BR><FONT SIZE=3D2>&quot;As a general rule, the CERT/CC recommends =
disabling any service or capability that is not explicitly required, =
including SNMP.&quot; So, using your logic, if I have devices that =
don't need COPS/PR, then COPS/PR must not be suitable for =
provisioning?</FONT></P>

<P><FONT SIZE=3D2>Get a clue. Understand what the CERT advisory is =
about before you try to use it to justify COPS/PR.</FONT>
</P>

<P><FONT SIZE=3D2>I expected better from you.</FONT>
<BR><FONT SIZE=3D2>dbh</FONT>
</P>

<P><FONT SIZE=3D2>David Harrington</FONT>
<BR><FONT SIZE=3D2>Network Management Architect</FONT>
<BR><FONT SIZE=3D2>Office of the CTO</FONT>
<BR><FONT SIZE=3D2>Enterasys Networks</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BF39.33FA0930--



From owner-rap@ops.ietf.org  Wed Feb 27 10:13:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26489
	for <rap-archive@lists.ietf.org>; Wed, 27 Feb 2002 10:13:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16g5l0-0009bH-00
	for rap-data@psg.com; Wed, 27 Feb 2002 07:12:38 -0800
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16g5kz-0009bB-00
	for rap@ops.ietf.org; Wed, 27 Feb 2002 07:12:37 -0800
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1RFCW401338;
	Wed, 27 Feb 2002 10:12:32 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1RFCUc07493;
	Wed, 27 Feb 2002 10:12:30 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <FYCHFR14>; Wed, 27 Feb 2002 10:12:31 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60179383B@zcard0ke.ca.nortel.com>
From: "Glenn Waters"<gww@nortelnetworks.com>
To: rap@ops.ietf.org
Cc: "Durham, David" <david.durham@intel.com>
Subject: RE: COPS vs. SNMP
Date: Wed, 27 Feb 2002 10:04:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BFA0.1836C640"
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_01C1BFA0.1836C640
Content-Type: text/plain

Dave, the CERT advisory is purely about SNMP implementations and it not in
any way about the design of the SNMP protocol.

The types of implementation problems that have been identified are pretty
much all buffer overflow problems. When a buffer overflow occurs the box
will typically exhibit some bad behavior -- like crash. This is known as a
denial of service attack. Some smart hackers have even put assembled byte
code in the overflowed buffer in an attempt to get that code to execute. In
this case, the hacker could possibly take control of the box.

If you remember your Internet history, many years ago the SMTP protocol was
used to compromise a system. This also made the news big time. I would
characterize the SMTP protocol encoding to be even simpler than COPS-PR; to
which I conclude that COPS-PR is just as vulnerable as ANY other protocol.
Try the following goggle search and you see what I mean by the word ANY in
the previous sentence:

	http://www.google.com/search?hl=en&q=buffer+overflow 

/gww

-----Original Message-----
From: Durham, David [mailto:david.durham@intel.com] 
Sent: Tuesday, February 26, 2002 21:13
To: 'David.Partain@ericsson.com'; rap@ops.ietf.org
Subject: RE: COPS vs. SNMP

Comments inline...

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: Tuesday, February 26, 2002 4:03 AM
> To: Durham, David; 'Wijnen, Bert (Bert)'; rap@ops.ietf.org
> Subject: Re: COPS vs. SNMP
>
[DaveD] ...

> I don't see that that has _anything_ whatsoever to do with SNMP
> (which was the focus of your mail about the CERT advisory),
> but it certainly is related to SNMPCONF (of course).  Of course,
> this model has existed in DISMAN for a number of years, as well
> as in various other areas of technology.
> 
[DaveD] The issue is two fold, 1. if the installed base of
protocol/implementations for whatever reason are being shut-off, then who
can do configuration management with SNMP? 2. Somebody should take a close
look at running local scripts to do policy control, specifically in the
context of SNMPConf... I've brought this up before, the CERT advisory is a
nice reminder to make sure some up-front attack prevention is done or at
least considered. Clearly defining the division of responsibility between PM
policy and SNMPv3 access-control would be a nice place to start.

> bw> The SNMP CERT advisories have NOT talked about a flaw
> bw> in the SNMP Protocol at all. They have talked about implementation
> dd> Perhaps,
> 
> It's not a question of "perhaps".  It's absolutely certain.
> Please read the advisory.

[DaveD] The advisory is not clear in this regard, I read it. Also, the press
reports clearly specify  that there are Vulnerabilities in the SNMP
Protocol. It was not clear if this was based ONLY on the cited CERT
advisory.
> 
> dd> There are a lot of SHOULDs and MAYs in the specs that 
> help contribute to
> dd> implementations going awry.
> 
> In this case, it's classic programming errors in handling
> buffers.  It's exactly the same kind of programming errors that
> have affected a very wide range of available software from
> OS kernels to web servers to printing systems, to....
> 
> Don't try to blame this on the protocol.  It won't fly.

[DaveD] Ummm, the protocol can make it more difficult for implementations to
get it right. Eg. XML provides nice begin tags and end tags. Or better yet,
fixed size fields are easier to implement than allowing everything to vary.
Allowing fields to vary (via the spec) within bounds specified with a lower
bound of MUST and an upper bound of SHOULD also adds to the complexity for
implementers.
> 
> dd> COPS and COPS-PR security mechanisms are NOT BER-based.
> 
> It has absolutely nothing to do with security mechanisms.
> It's buffer overflows.

[DaveD] If the protocol uses the BER encoded security mechanisms, and the
BER encodings are susceptible to buffer overflows,  then you can obviously
directly attack a machine through the BER encoded security mechanism itself!

> 
> dd> The security
> dd> mechanisms use fixed size COPS objects and tried & true 
> TCP security
> dd> mechanisms. Once the persistent & secure client/server 
> communication is
> dd> established, only then does BER come into play. Even 
> then, the BER objects
> dd> are still wrapped in COPS objects, providing an extra 
> level of validation
> dd> to avoid buffer overruns and the like.
> 
> If the folks writing COPS/COPS-PR code write perfect code,
> I'm sure there'll never be any COPS-related problems with any
> kind of denial of service or buffer overflow attack.

[DaveD] ... And I forgot to point out that the SPPI promotes better type
checking as well, and removes the need for those long, composit-INDEX OIDs
altogether. Keeping things easy for implementers is a good thing here!


------_=_NextPart_001_01C1BFA0.1836C640
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: COPS vs. SNMP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dave, the CERT advisory is purely about SNMP =
implementations and it not in any way about the design of the SNMP =
protocol.</FONT></P>

<P><FONT SIZE=3D2>The types of implementation problems that have been =
identified are pretty much all buffer overflow problems. When a buffer =
overflow occurs the box will typically exhibit some bad behavior -- =
like crash. This is known as a denial of service attack. Some smart =
hackers have even put assembled byte code in the overflowed buffer in =
an attempt to get that code to execute. In this case, the hacker could =
possibly take control of the box.</FONT></P>

<P><FONT SIZE=3D2>If you remember your Internet history, many years ago =
the SMTP protocol was used to compromise a system. This also made the =
news big time. I would characterize the SMTP protocol encoding to be =
even simpler than COPS-PR; to which I conclude that COPS-PR is just as =
vulnerable as ANY other protocol. Try the following goggle search and =
you see what I mean by the word ANY in the previous =
sentence:</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2><A =
HREF=3D"http://www.google.com/search?hl=3Den&q=3Dbuffer+overflow" =
TARGET=3D"_blank">http://www.google.com/search?hl=3Den&q=3Dbuffer+overfl=
ow</A> </FONT>
</P>

<P><FONT SIZE=3D2>/gww</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Durham, David [<A =
HREF=3D"mailto:david.durham@intel.com">mailto:david.durham@intel.com</A>=
] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 26, 2002 21:13</FONT>
<BR><FONT SIZE=3D2>To: 'David.Partain@ericsson.com'; =
rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: COPS vs. SNMP</FONT>
</P>

<P><FONT SIZE=3D2>Comments inline...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Partain [<A =
HREF=3D"mailto:David.Partain@ericsson.com">mailto:David.Partain@ericsson=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, February 26, 2002 4:03 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Durham, David; 'Wijnen, Bert (Bert)'; =
rap@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: COPS vs. SNMP</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>[DaveD] ...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I don't see that that has _anything_ whatsoever =
to do with SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; (which was the focus of your mail about the =
CERT advisory),</FONT>
<BR><FONT SIZE=3D2>&gt; but it certainly is related to SNMPCONF (of =
course).&nbsp; Of course,</FONT>
<BR><FONT SIZE=3D2>&gt; this model has existed in DISMAN for a number =
of years, as well</FONT>
<BR><FONT SIZE=3D2>&gt; as in various other areas of technology.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>[DaveD] The issue is two fold, 1. if the installed =
base of</FONT>
<BR><FONT SIZE=3D2>protocol/implementations for whatever reason are =
being shut-off, then who</FONT>
<BR><FONT SIZE=3D2>can do configuration management with SNMP? 2. =
Somebody should take a close</FONT>
<BR><FONT SIZE=3D2>look at running local scripts to do policy control, =
specifically in the</FONT>
<BR><FONT SIZE=3D2>context of SNMPConf... I've brought this up before, =
the CERT advisory is a</FONT>
<BR><FONT SIZE=3D2>nice reminder to make sure some up-front attack =
prevention is done or at</FONT>
<BR><FONT SIZE=3D2>least considered. Clearly defining the division of =
responsibility between PM</FONT>
<BR><FONT SIZE=3D2>policy and SNMPv3 access-control would be a nice =
place to start.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; bw&gt; The SNMP CERT advisories have NOT talked =
about a flaw</FONT>
<BR><FONT SIZE=3D2>&gt; bw&gt; in the SNMP Protocol at all. They have =
talked about implementation</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; Perhaps,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It's not a question of =
&quot;perhaps&quot;.&nbsp; It's absolutely certain.</FONT>
<BR><FONT SIZE=3D2>&gt; Please read the advisory.</FONT>
</P>

<P><FONT SIZE=3D2>[DaveD] The advisory is not clear in this regard, I =
read it. Also, the press</FONT>
<BR><FONT SIZE=3D2>reports clearly specify&nbsp; that there are =
Vulnerabilities in the SNMP</FONT>
<BR><FONT SIZE=3D2>Protocol. It was not clear if this was based ONLY on =
the cited CERT</FONT>
<BR><FONT SIZE=3D2>advisory.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; There are a lot of SHOULDs and MAYs in =
the specs that </FONT>
<BR><FONT SIZE=3D2>&gt; help contribute to</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; implementations going awry.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In this case, it's classic programming errors =
in handling</FONT>
<BR><FONT SIZE=3D2>&gt; buffers.&nbsp; It's exactly the same kind of =
programming errors that</FONT>
<BR><FONT SIZE=3D2>&gt; have affected a very wide range of available =
software from</FONT>
<BR><FONT SIZE=3D2>&gt; OS kernels to web servers to printing systems, =
to....</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Don't try to blame this on the protocol.&nbsp; =
It won't fly.</FONT>
</P>

<P><FONT SIZE=3D2>[DaveD] Ummm, the protocol can make it more difficult =
for implementations to</FONT>
<BR><FONT SIZE=3D2>get it right. Eg. XML provides nice begin tags and =
end tags. Or better yet,</FONT>
<BR><FONT SIZE=3D2>fixed size fields are easier to implement than =
allowing everything to vary.</FONT>
<BR><FONT SIZE=3D2>Allowing fields to vary (via the spec) within bounds =
specified with a lower</FONT>
<BR><FONT SIZE=3D2>bound of MUST and an upper bound of SHOULD also adds =
to the complexity for</FONT>
<BR><FONT SIZE=3D2>implementers.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; COPS and COPS-PR security mechanisms are =
NOT BER-based.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It has absolutely nothing to do with security =
mechanisms.</FONT>
<BR><FONT SIZE=3D2>&gt; It's buffer overflows.</FONT>
</P>

<P><FONT SIZE=3D2>[DaveD] If the protocol uses the BER encoded security =
mechanisms, and the</FONT>
<BR><FONT SIZE=3D2>BER encodings are susceptible to buffer =
overflows,&nbsp; then you can obviously</FONT>
<BR><FONT SIZE=3D2>directly attack a machine through the BER encoded =
security mechanism itself!</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; The security</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; mechanisms use fixed size COPS objects =
and tried &amp; true </FONT>
<BR><FONT SIZE=3D2>&gt; TCP security</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; mechanisms. Once the persistent &amp; =
secure client/server </FONT>
<BR><FONT SIZE=3D2>&gt; communication is</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; established, only then does BER come =
into play. Even </FONT>
<BR><FONT SIZE=3D2>&gt; then, the BER objects</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; are still wrapped in COPS objects, =
providing an extra </FONT>
<BR><FONT SIZE=3D2>&gt; level of validation</FONT>
<BR><FONT SIZE=3D2>&gt; dd&gt; to avoid buffer overruns and the =
like.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the folks writing COPS/COPS-PR code write =
perfect code,</FONT>
<BR><FONT SIZE=3D2>&gt; I'm sure there'll never be any COPS-related =
problems with any</FONT>
<BR><FONT SIZE=3D2>&gt; kind of denial of service or buffer overflow =
attack.</FONT>
</P>

<P><FONT SIZE=3D2>[DaveD] ... And I forgot to point out that the SPPI =
promotes better type</FONT>
<BR><FONT SIZE=3D2>checking as well, and removes the need for those =
long, composit-INDEX OIDs</FONT>
<BR><FONT SIZE=3D2>altogether. Keeping things easy for implementers is =
a good thing here!</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BFA0.1836C640--



From owner-rap@ops.ietf.org  Wed Feb 27 12:59:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06668
	for <rap-archive@lists.ietf.org>; Wed, 27 Feb 2002 12:59:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16g8LS-000GWI-00
	for rap-data@psg.com; Wed, 27 Feb 2002 09:58:26 -0800
Received: from jffdns01.or.intel.com ([134.134.248.3] helo=ganymede.or.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16g8LQ-000GRa-00
	for rap@ops.ietf.org; Wed, 27 Feb 2002 09:58:24 -0800
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id RAA29444
	for <rap@ops.ietf.org>; Wed, 27 Feb 2002 17:56:53 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022710022223089
 ; Wed, 27 Feb 2002 10:02:22 -0800
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <1YPLY95S>; Wed, 27 Feb 2002 09:56:52 -0800
Message-ID: <10C8636AE359D4119118009027AE99870DA5DE41@FMSMSX34>
From: "Durham, David" <david.durham@intel.com>
To: "'Glenn Waters'" <gww@nortelnetworks.com>, rap@ops.ietf.org
Subject: RE: COPS vs. SNMP
Date: Wed, 27 Feb 2002 09:56:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BFB8.1E3C71D0"
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_01C1BFB8.1E3C71D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Glenn,
 
I think there is a clear difference between COPS-PR & SNMP models regarding
the issue of security, particularly in light of this CERT advisory.
 
COPS-PR:
* The Network Devices initiate all communication with trusted PDPs via a TCP
session that can be secured at 3 different levels (COPS Message Integrity,
TLS, & IPSec).
 
* The Network Devices do not respond to any COPS TCP connection requests
coming in.
 
* Only once a secure TCP session is established and the COPS
clientopen/accept exchange do the devices communicate & receive data.
 
SNMP:
* SNMP UDP packets are asynchronously received by Network Devices pretty
much from anyone, anywhere.
 
* Since no session needs be established before hand, one shot SNMP UDP
packets can be sent & addresses can be spoofed.
 
* The devices need to start parsing the PDUs in each of these SNMP UDP
packets, and correct me if I am wrong, the PDUs are themselves BER
encoded... Even the SNMPv3 security mechanisms.
 
For the above reasons, it seems to me that the COPS-PR model is more secure,
particularly given BER seems to be hard to get right.
 
Cheers,
-Dave
 

-----Original Message-----
From: Glenn Waters [mailto:gww@nortelnetworks.com]
Sent: Wednesday, February 27, 2002 7:05 AM
To: rap@ops.ietf.org
Cc: Durham, David
Subject: RE: COPS vs. SNMP



Dave, the CERT advisory is purely about SNMP implementations and it not in
any way about the design of the SNMP protocol.

The types of implementation problems that have been identified are pretty
much all buffer overflow problems. When a buffer overflow occurs the box
will typically exhibit some bad behavior -- like crash. This is known as a
denial of service attack. Some smart hackers have even put assembled byte
code in the overflowed buffer in an attempt to get that code to execute. In
this case, the hacker could possibly take control of the box.

If you remember your Internet history, many years ago the SMTP protocol was
used to compromise a system. This also made the news big time. I would
characterize the SMTP protocol encoding to be even simpler than COPS-PR; to
which I conclude that COPS-PR is just as vulnerable as ANY other protocol.
Try the following goggle search and you see what I mean by the word ANY in
the previous sentence:

        http://www.google.com/search?hl=en
<http://www.google.com/search?hl=en&q=buffer+overflow> &q=buffer+overflow 

/gww 


------_=_NextPart_001_01C1BFB8.1E3C71D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: COPS vs. SNMP</TITLE>

<META content="MSHTML 5.50.4912.300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>Hi 
Glenn,</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>I 
think there is a clear difference between COPS-PR &amp; SNMP models 
regarding&nbsp;the issue of security, particularly in light of this CERT 
advisory.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2>COPS-PR:</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>* The 
Network Devices initiate all communication with trusted PDPs&nbsp;via a TCP 
session that can be secured at 3 different levels (COPS Message Integrity, TLS, 
&amp; IPSec).</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>* The 
Network Devices do not respond to any COPS TCP connection requests coming 
in.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>* Only 
once a secure TCP session is established and the COPS clientopen/accept exchange 
do the devices communicate &amp; receive data.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2>SNMP:</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>* SNMP 
UDP packets are asynchronously received by Network Devices pretty much from 
anyone, anywhere.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>* 
Since no session needs be established before hand, one shot SNMP&nbsp;UDP 
packets can be sent &amp;&nbsp;addresses can be spoofed.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>* The 
devices need to start parsing the PDUs in each of these SNMP UDP packets, and 
correct me if I am wrong, the PDUs are themselves BER encoded... Even the SNMPv3 
security mechanisms.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff size=2>For 
the above reasons, it seems to me that the COPS-PR model is more secure, 
particularly given BER&nbsp;seems to be hard to get right.</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2>-Dave</FONT></SPAN></DIV>
<DIV><SPAN class=099551517-27022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Glenn Waters 
  [mailto:gww@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, February 27, 2002 
  7:05 AM<BR><B>To:</B> rap@ops.ietf.org<BR><B>Cc:</B> Durham, 
  David<BR><B>Subject:</B> RE: COPS vs. SNMP<BR><BR></FONT></DIV>
  <P><FONT size=2>Dave, the CERT advisory is purely about SNMP implementations 
  and it not in any way about the design of the SNMP protocol.</FONT></P>
  <P><FONT size=2>The types of implementation problems that have been identified 
  are pretty much all buffer overflow problems. When a buffer overflow occurs 
  the box will typically exhibit some bad behavior -- like crash. This is known 
  as a denial of service attack. Some smart hackers have even put assembled byte 
  code in the overflowed buffer in an attempt to get that code to execute. In 
  this case, the hacker could possibly take control of the box.</FONT></P>
  <P><FONT size=2>If you remember your Internet history, many years ago the SMTP 
  protocol was used to compromise a system. This also made the news big time. I 
  would characterize the SMTP protocol encoding to be even simpler than COPS-PR; 
  to which I conclude that COPS-PR is just as vulnerable as ANY other protocol. 
  Try the following goggle search and you see what I mean by the word ANY in the 
  previous sentence:</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2><A target=_blank 
  href="http://www.google.com/search?hl=en&amp;q=buffer+overflow">http://www.google.com/search?hl=en&amp;q=buffer+overflow</A> 
  </FONT></P>
  <P><FONT size=2>/gww</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1BFB8.1E3C71D0--



From owner-rap@ops.ietf.org  Wed Feb 27 13:47:44 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09632
	for <rap-archive@lists.ietf.org>; Wed, 27 Feb 2002 13:47:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16g96x-000IoN-00
	for rap-data@psg.com; Wed, 27 Feb 2002 10:47:31 -0800
Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com)
	by psg.com with esmtp (Exim 3.35 #1)
	id 16g96v-000Io4-00
	for rap@ops.ietf.org; Wed, 27 Feb 2002 10:47:30 -0800
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id SAA12911
	for <rap@ops.ietf.org>; Wed, 27 Feb 2002 18:47:27 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022710480725887
 ; Wed, 27 Feb 2002 10:48:08 -0800
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <1Y30J7B8>; Wed, 27 Feb 2002 10:46:30 -0800
Message-ID: <59885C5E3098D511AD690002A5072D3C0381F847@orsmsx111.jf.intel.com>
From: "Hahn, Scott" <scott.hahn@intel.com>
To: Glenn Waters <gww@nortelnetworks.com>, rap@ops.ietf.org
Cc: "Durham, David" <david.durham@intel.com>
Subject: RE: COPS vs. SNMP
Date: Wed, 27 Feb 2002 10:46:25 -0800
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

While I find this discussion interesting, I think a discussion about
potentially security problems in SNMP should be moved to one or all of the
SNMP mailing lists.

	-Scott Hahn
	RAP WG co-chair

-----Original Message-----
From: Glenn Waters [mailto:gww@nortelnetworks.com]
Sent: Wednesday, February 27, 2002 7:05 AM
To: rap@ops.ietf.org
Cc: Durham, David
Subject: RE: COPS vs. SNMP


Dave, the CERT advisory is purely about SNMP implementations and it not in
any way about the design of the SNMP protocol.
The types of implementation problems that have been identified are pretty
much all buffer overflow problems. When a buffer overflow occurs the box
will typically exhibit some bad behavior -- like crash. This is known as a
denial of service attack. Some smart hackers have even put assembled byte
code in the overflowed buffer in an attempt to get that code to execute. In
this case, the hacker could possibly take control of the box.
If you remember your Internet history, many years ago the SMTP protocol was
used to compromise a system. This also made the news big time. I would
characterize the SMTP protocol encoding to be even simpler than COPS-PR; to
which I conclude that COPS-PR is just as vulnerable as ANY other protocol.
Try the following goggle search and you see what I mean by the word ANY in
the previous sentence:
        http://www.google.com/search?hl=en&q=buffer+overflow 
/gww 
-----Original Message----- 
From: Durham, David [mailto:david.durham@intel.com] 
Sent: Tuesday, February 26, 2002 21:13 
To: 'David.Partain@ericsson.com'; rap@ops.ietf.org 
Subject: RE: COPS vs. SNMP 
Comments inline... 
> -----Original Message----- 
> From: David Partain [mailto:David.Partain@ericsson.com] 
> Sent: Tuesday, February 26, 2002 4:03 AM 
> To: Durham, David; 'Wijnen, Bert (Bert)'; rap@ops.ietf.org 
> Subject: Re: COPS vs. SNMP 
> 
[DaveD] ... 
> I don't see that that has _anything_ whatsoever to do with SNMP 
> (which was the focus of your mail about the CERT advisory), 
> but it certainly is related to SNMPCONF (of course).  Of course, 
> this model has existed in DISMAN for a number of years, as well 
> as in various other areas of technology. 
> 
[DaveD] The issue is two fold, 1. if the installed base of 
protocol/implementations for whatever reason are being shut-off, then who 
can do configuration management with SNMP? 2. Somebody should take a close 
look at running local scripts to do policy control, specifically in the 
context of SNMPConf... I've brought this up before, the CERT advisory is a 
nice reminder to make sure some up-front attack prevention is done or at 
least considered. Clearly defining the division of responsibility between PM

policy and SNMPv3 access-control would be a nice place to start. 
> bw> The SNMP CERT advisories have NOT talked about a flaw 
> bw> in the SNMP Protocol at all. They have talked about implementation 
> dd> Perhaps, 
> 
> It's not a question of "perhaps".  It's absolutely certain. 
> Please read the advisory. 
[DaveD] The advisory is not clear in this regard, I read it. Also, the press

reports clearly specify  that there are Vulnerabilities in the SNMP 
Protocol. It was not clear if this was based ONLY on the cited CERT 
advisory. 
> 
> dd> There are a lot of SHOULDs and MAYs in the specs that 
> help contribute to 
> dd> implementations going awry. 
> 
> In this case, it's classic programming errors in handling 
> buffers.  It's exactly the same kind of programming errors that 
> have affected a very wide range of available software from 
> OS kernels to web servers to printing systems, to.... 
> 
> Don't try to blame this on the protocol.  It won't fly. 
[DaveD] Ummm, the protocol can make it more difficult for implementations to

get it right. Eg. XML provides nice begin tags and end tags. Or better yet, 
fixed size fields are easier to implement than allowing everything to vary. 
Allowing fields to vary (via the spec) within bounds specified with a lower 
bound of MUST and an upper bound of SHOULD also adds to the complexity for 
implementers. 
> 
> dd> COPS and COPS-PR security mechanisms are NOT BER-based. 
> 
> It has absolutely nothing to do with security mechanisms. 
> It's buffer overflows. 
[DaveD] If the protocol uses the BER encoded security mechanisms, and the 
BER encodings are susceptible to buffer overflows,  then you can obviously 
directly attack a machine through the BER encoded security mechanism itself!

> 
> dd> The security 
> dd> mechanisms use fixed size COPS objects and tried & true 
> TCP security 
> dd> mechanisms. Once the persistent & secure client/server 
> communication is 
> dd> established, only then does BER come into play. Even 
> then, the BER objects 
> dd> are still wrapped in COPS objects, providing an extra 
> level of validation 
> dd> to avoid buffer overruns and the like. 
> 
> If the folks writing COPS/COPS-PR code write perfect code, 
> I'm sure there'll never be any COPS-related problems with any 
> kind of denial of service or buffer overflow attack. 
[DaveD] ... And I forgot to point out that the SPPI promotes better type 
checking as well, and removes the need for those long, composit-INDEX OIDs 
altogether. Keeping things easy for implementers is a good thing here!