Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 27 Sep 2009 22:06:17 +0200

I am not really interested to get involved too deeply in this discussion,
certainly not at the level of detail that David does in his repsonse to Paul.

But I would like to comment on one statement from David Harrington,
namely:

  ----- Original Message ----- 
  From: David Harrington 
  To: [email-masked] ; 'OPS Area (E-mail)' 
  Sent: Saturday, September 26, 2009 12:16 AM
  Subject: Re: [OPS-AREA] Present day reality of COPS-PR

  Hi,

  comments inline. I can help with the RFC. here's a start ... ;-)

  > It never 
  > really took off, for the following reasons....
  > 
  > - most, if not all, of what could be done with COPS-PR/PIBs 
  > can be done
  > with SNMP/MIBs. To do both is significant duplicated effort.

  That is true, and that is what really killed it in IETF, where there
  was a policy that all WGs were expected to "write a MIB" to make their
  protoocls manageable. The IESG decided that they could not insist that
  WGs duplicate effort by writing both a MIB and a PIB, but SNMP could
  work with PIBs (and it would not have been easy to make that work), so
  just "write a PIB" for both COPS-PR and SNMP usage was not a viable
  option either.

This gives the impression that the IESG decided this on her own. The IESG did collect
IETF input in various ways (BOF, info-gathering meetings, plenary discussion etc)
and based on the input concluded that there was (albeit very rough) consensus to not 
support PIB Modules on the standards track.

Bert

---

From: "David Harrington" <[email-masked]>
Date: Sun, 27 Sep 2009 18:43:46 -0400

Hi,
 
I did not mean to imply that the IESG did this without following the
normal IETF review process.
I agree it was IETF rough consensus.
 
and I have a typo in that paragraph. 
s/SNMP could work with PIBs/SNMP could not work with PIBs/
 
dbh

  _____  

From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Sunday, September 27, 2009 4:06 PM
To: David Harrington; [email-masked]; 'OPS Area (E-mail)'
Cc: [email-masked]
Subject: Re: [OPS-AREA] Present day reality of COPS-PR

I am not really interested to get involved too deeply in this
discussion,
certainly not at the level of detail that David does in his repsonse
to Paul.

----- Original Message ----- 
From: David Harrington 
To: [email-masked] ; 'OPS Area (E-mail)' 
Sent: Saturday, September 26, 2009 12:16 AM
Subject: Re: [OPS-AREA] Present day reality of COPS-PR

Hi,

This gives the impression that the IESG decided this on her own. The
IESG did collect
IETF input in various ways (BOF, info-gathering meetings, plenary
discussion etc)
and based on the input concluded that there was (albeit very rough)
consensus to not 
support PIB Modules on the standards track.
 
Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Sep 2009 09:53:25 +1300

> certainly not at the level of detail that David does in his repsonse to Paul.

Ditto, however:

...
> support PIB Modules on the standards track.

I'd like to say, as a case in point, that the diffserv WG produced both a MIB
(because Bert said we had to ;-) and a PIB. The latter (RFC3317) took almost a
year after we'd finished all the core work of the WG, but I've really never heard
of it being used extensively and it was only somewhat supported even while under
active development (see below). What Bert says fits that picture.

    Brian

-------- Original Message --------
Subject: Updated summary Re: diffserv PIB: a question to the WG
Date: Wed, 12 Dec 2001 22:47:35 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Diff Serv <[email-masked]>
CC: Bert Wijnen <[email-masked]>, Randy Bush <[email-masked]>
References: <[email-masked]>

Summary so far:

Plan to use the PIB: 1
May use and implement the PIB: 1
Implemented/now implementing the draft PIB: 3

Also, the PIB is currently a normative reference in 3GPP.

More replies welcome; anonymity guaranteed if requested.

   Brian

Brian E Carpenter wrote:
>
> Diffservers,
>
> As you know the Diffserv PIB recently passed WG last call, and will be forwarded
> to the IESG as soon as the draft is updated.
>
> Now I have a question, at the request of the Ops and Management Area Directors:
>
> Can anyone who plans to implement the diffserv PIB (or has already done so)
> please let us know? If you don't want to answer on the list, please send
> me a private response.
>
> Thanks
>    Brian Carpenter
>    diffserv co-chair

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 Sep 2009 13:14:14 +0200

(moving the discussion to OPSAWG). 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Harrington
> 
> > 
> > - there are few, if any, significant deployments.
> > 
> > AFAIK, there is minimal commercial or open source support.
> 
> I have not been able to research these claims, but I am told 
> that COPS-PR is actually in use in a number of places. Here 
> are some of the claims I have heard:
> 
> 1) Juniper uses COPS-PR for their resource allocation, using 
> both push and pull methods, at least in the access and 
> aggregation network. 
> 2) COPS-PR may be deployed in the Verizon FIOS (FTTH) access 
> network in the US.
> 3) COPS-PR may be deployed in the FT-Orange IPTV access network in UK.
> 4) Comcast uses a mix of COPS and COPS-PR in cable TV video 
> QoS control. 
> 5) COPS-PR is in DOCSIS 1.0 QoS, which may still be used in 
> cable deployments
> 6) Huawei uses both COPS and COPS-PR in their Quidway RM9000 
> Resource Manager and their Multi-Service Control Gateway 
> solution (public documents show COPS, but I have not found 
> explicit mention of COPS-PR; I am checking further)
> 7) ITU-T has a proposal being considered that is based on COPS-PR
> 
> Searching the Web I found some additional information that 
> might bear further research (many items have no associated dates):
> 8) MultiService Forum has an Implementation Agreement for 
> Dynamic Policy Control Using COPS-PR (2005) 
> http://www.msforum.org/techinfo/approved/MSF-IA-COPS-PR.001-FINAL.pdf
> 9) IEEE Xplore has a paper that apparently was presented at 
> ICT 2008 comparing the performance of COPS-PR and Netconf. 
> The paper might identify some equipment that has COPS-PR support.
> 10) A 2006 paper was published in the Proceedings of the IEEE 
> International Workshop on Policies for Distributed Systems 
> and Networks. The paper considers substituting Netconf and/or 
> SOAP for COPS-PR
> 11) I found discussion of COPS-PR in JUNOSe and the SAE on 
> the web, apparently for the SDX line (dated 2008). Was this 
> from the Juniper acquisition of netscreen and neoteris?
> 12) Sejong University apparently has developed a COPS-PR lite
> http://ietcom.oxfordjournals.org/cgi/content/abstract/E90-B/11/3024
> 13) EION has an implementation
> http://www.eion.com/protocols/protocols_traffic_cops.html
> 14) Cisco Catalyst has an implementation
> 15) Wireshark apparently implements it
> 16) ACSE Networks implements COPS-PR in their NeuTrans product line
> 17) ZNYX Networks implements COPS-PR in the ZX4900
> 18) libsmi implemented it
> 19) Operax AB implemented it
> 20) MIB Smithy implemented it
> 21) GridNet has implemented it in its products for managing utility
> (power) grids
> 22) GE apparently embeds the GridNet implementation in its 
> WiMax SmartMeter and SmartGrid Router family of products
> 23) COPS-PR has been the subject of a tremendous number of 
> academic papers
> 

There claims need to be examined carefully. We need to differentiate
between academic papers, code implementation and deployment. It is
probably true that a number of open source packages and tools
implemented COPS-PR after it was put on standards track, but the
question is to what extent this code was also used and deployed. Same
for the vendors implementations - was COPS-PR deployed and how?  In the
absence of standards PIBs I suspect that the majority or all the
deployments use one vendor tools and agents, but we need to give enough
time for these vendors to step ahead and explain in case
interoperability is impacted by the proposed standards action. 

Dan

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Sep 2009 08:22:18 -0400

Hi,

These claims were gathered by me from co-workers familiar with
COPS-PR.
I have not checked any of the claims.

The most interesting to me are the claims of deployment in FIOS,
FT-Orange, and Comcast.
We should seek out people knowledgeable about the technologies used in
these networks, and ask about COPS-PR.
Does anybody have contacts within the IT departments of these
companies?

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Wednesday, September 30, 2009 7:14 AM
> To: David Harrington; [email-masked]
> Cc: [email-masked]
> Subject: RE: [OPS-AREA] Present day reality of COPS-PR
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 Sep 2009 14:27:38 +0200

We can write a short cal for input about implementations and deployments
of COPS-PR on the general IETF list, pointing to the discussion going on
in OPSAWG. Certainly such input may also arrive at the time of the IETF
LC but it would be better to know about it earlier. 

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, September 30, 2009 2:22 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: [email-masked]
> These claims were gathered by me from co-workers familiar 
> with COPS-PR.
> The most interesting to me are the claims of deployment in 
> FIOS, FT-Orange, and Comcast.
> We should seek out people knowledgeable about the 
> technologies used in these networks, and ask about COPS-PR.
> > > I have not been able to research these claims, but I am told that 
> > > COPS-PR is actually in use in a number of places. Here 
> are some of 
> > > the claims I have heard:
> > > 
> > > 1) Juniper uses COPS-PR for their resource allocation, using both 
> > > push and pull methods, at least in the access and aggregation 
> > > network.
> > > 2) COPS-PR may be deployed in the Verizon FIOS (FTTH) 
> access network 
> > > in the US.
> > > 4) Comcast uses a mix of COPS and COPS-PR in cable TV video QoS 
> > > control.
> > > 5) COPS-PR is in DOCSIS 1.0 QoS, which may still be used in cable 
> > > deployments
> > > Resource Manager and their Multi-Service Control Gateway solution 
> > > (public documents show COPS, but I have not found 
> explicit mention 
> > > Searching the Web I found some additional information that might 
> > > bear further research (many items have no associated dates):
> > > 8) MultiService Forum has an Implementation Agreement for Dynamic 
> > > Policy Control Using COPS-PR (2005)
> > > 
> >
> > > 9) IEEE Xplore has a paper that apparently was presented 
> at ICT 2008 
> > > comparing the performance of COPS-PR and Netconf.
> > > International Workshop on Policies for Distributed Systems and 
> > > Networks. The paper considers substituting Netconf and/or 
> SOAP for 
> > > COPS-PR
> > > 11) I found discussion of COPS-PR in JUNOSe and the SAE 
> on the web, 
> > > apparently for the SDX line (dated 2008). Was this from 
> the Juniper 
> > > acquisition of netscreen and neoteris?
> > > 22) GE apparently embeds the GridNet implementation in its WiMax 
> > > SmartMeter and SmartGrid Router family of products
> > > 23) COPS-PR has been the subject of a tremendous number 
> of academic 
> > > papers
> > > 
> > 
> > for the vendors implementations - was COPS-PR deployed and how?  In 
> > the absence of standards PIBs I suspect that the majority 
> or all the 
> > deployments use one vendor tools and agents, but we need to give 
> > enough time for these vendors to step ahead and explain in case

---

From: Paul Duffy <[email-masked]>
Date: Wed, 30 Sep 2009 09:57:04 -0400

Appreciate the investigation, but also agree it needs to be vetted 
(academic versus real world deployments). 

For example...

- AFAIK COPS, not COPS-PR, is used for DOCSIS/PacketCable DQoS. Hope the 
rest of the list correctly makes this distinction.
- I've not been able to locate any open source community
- I've located a single vendor, Trillium, that offers support (embedded 
in an IMS suite).
- the word from my colleagues @ Cisco is that its time has passed.
- etc.

Its pretty clear its not massively deployed.

Romascanu, Dan (Dan) wrote:
>> are some of 
>>>> the claims I have heard:
>>>> 3) COPS-PR may be deployed in the FT-Orange IPTV access
>>>>         
>>> network in UK.
>>>       
>> explicit mention 
>>>> of COPS-PR; I am checking further)
>>>> 16) ACSE Networks implements COPS-PR in their NeuTrans product
>>>>         
>> line
>>     
>>>> 21) GridNet has implemented it in its products for managing
>>>>         
>> utility
>>     
>>>> (power) grids
>>> There claims need to be examined carefully. We need to 
>>>       
>> differentiate 
>>     
>>> question is to what extent this code was also used and deployed.
>>>       
>> Same
>>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Sep 2009 08:51:23 -0700

>>>>> On Wed, 30 Sep 2009 13:14:14 +0200, "Romascanu, Dan (Dan)" <[email-masked]> said:

DR> In the absence of standards PIBs I suspect that the majority or all
DR> the deployments use one vendor tools

I don't think you can safely make that argument.  Personally, I have no
knowledge about how well COPS or COPS-PR or implementations of MIBs
are/were used.  But I think since the IETF functionally made all the
COPS folks mad by refusing to let them standardize their work (I'm not
saying whether this was right or wrong; it's simply fact) the end result
was all the COPS folks left the IETF.  If PIBs were indeed written they
certainly wouldn't have been standardized within the IETF.  Maybe the
IETFs push-back did really cause the technology to become unused.  I
don't know.  But I don't think you can use any metrics affected by IETF
actions to decide that.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 Sep 2009 18:01:04 +0200

Wes,

I am not sure that I understand the point that you are making. We are
trying to gather information if and how is COPS-PR implemented and
deployed. Do you say that there are standard PIB modules that have been
developped by out of the IETF? It's a good time to get this kind of
input.

Dan

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, September 30, 2009 5:51 PM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; [email-masked]; [email-masked]
> Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR
> 
> I don't think you can safely make that argument.  Personally, 
> I have no knowledge about how well COPS or COPS-PR or 
> implementations of MIBs are/were used.  But I think since the 
> IETF functionally made all the COPS folks mad by refusing to 
> let them standardize their work (I'm not saying whether this 
> was right or wrong; it's simply fact) the end result was all 
> the COPS folks left the IETF.  If PIBs were indeed written 
> they certainly wouldn't have been standardized within the 
> IETF.  Maybe the IETFs push-back did really cause the 
> technology to become unused.  I don't know.  But I don't 
> think you can use any metrics affected by IETF actions to decide that.
> --
> Wes Hardaker

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Sep 2009 12:33:38 -0400

Hi 

> From: Paul Duffy [mailto:[email-masked]] 
> Sent: Wednesday, September 30, 2009 9:57 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; [email-masked]

I absolutely agree that the list needs vetting.
I suspect the claims I have seen might blur the distinction between
COPS-PR and "COPS with some COPS-PR-like proprietary extensions"

> rest of the list correctly makes this distinction.

I seem to recall vaguely that COPS-PR was in DOCSIS 1.0, but removed
from 2.0, IIRC.
(Or was that SNMPv3?)
I don't work with DOCSIS standards, so I cannot vet this myself.

> - I've located a single vendor, Trillium, that offers support 

I searched the web and found more than just Trillium. YMMV.

> - the word from my colleagues @ Cisco is that its time has passed.

Certainly Cisco pulled the plug on it a long time ago.

> Its pretty clear its not massively deployed.

Neither is Netconf and YANG.
And if the IESG refused to allow any YANG models to advance to
standards track, because the contents would duplicate MIB content,
YANG probably will never get wide deployment.
Should we declare Netconf and YANG Historic as well?
Let's use consistent comparisons if Netconf and YANG are the
replacement for COPS-PR.

Please understand. Up until recently I was fully convinced COPS-PR was
dead. I didn't think declaring it Historic would make any difference
because as far as I knew NOBODY was using it anyway.

COPS-PR only came up when Washam Fan wrote a LOCK-MIB that included a
table for COPS-PR locks (which, as far as I knew, nobody would ever
use). It was there for completeness; COPS-PR is an IETF standard that
has a lock, and so is Netconf. So they should both be included in the
LOCK-MIB. We have LOTS of things in MIB modules that are never used,
so having a potential COPS-PR lock represented was largely meaningless
and certainly not harmful.

But the Netconf community stepped up and said "Hey wait! ****we****
have the only IETF-BLESSED solution for configuration. We need to make
sure this other thing gets declared Historic so nobody will be tempted
to use it instead our solution." I don't think that's the best
justification for declaring something Historic.

At the same time, this WG has been developing a guidelines document,
and during IETF Last Call it was made very clear that the OPS-approach
to management seems too oriented toward routers and device management,
and that approach is NOT IETF-BLESSED as the only approach to
management. Netconf and YANG very much follow that approach. So it
seems apparent that the Netconf/YANG approach is not IETF-BLESSED as
the ONLY way to do configuration management. In fact, the charter for
YANG was required to say that it was ONE language, but not the only
language, that could be used with netconf. And other areas are working
on alternative approaches to configuration.

So I have a real problem with the desire to declare COPS-PR Historic
because Netconf and YANG are BLESSED by the whole IETF to replace
COPS-PR. As the editor for the Guidleines document, I had to deal
directly with the feedback we got, and I do not believe Netconf and
YANG are the BLESSED protocols for doing all configuration in the
IETF.

If you look at COPS-PR, you will also see that COPS-PR does MUCH more
than Netconf. The COPS-PR approach is very oriented toward
policy-based management, with its policy decision points and policy
enforcement points and policy-server discovery and so on. Netconf
doesn't provide those features at all.

I have a history or questioning claims made by the netconf community.
I actually support netconf and YANG, but I think they really need to
stop making inflated claims about what they can do. I think netconf
has standardized some very important aspects of configuration, and I
think YANG may be a very expressive langugae for data modeling. But
they are still unproven in the marketplace. They do not have wide
deployment yet. Cisco doesn't seem at all committed to YANG. Huawei
implemented Netconf, but have no intention that I am aware of to
implement YANG. 

I question whether Netconf and YANG replace the functionality found in
COPS-PR. I think it does not. I was around when COPS-PR came out, and
there were aspects that I thought would be useful for management
purposes. My background is in NMS systems, and having to poll whole
ranges of IP addresses to try to find the devices to manage is a
horrible design; letting the devices come to the manager and ask to be
managed makes tremendous sense to me. COPS-PR has that; SNMP and
Netconf do not.

I don't want to throw out the baby with the bathwater in this rush to
declare COPS-PR Historic. There are features in COPS-PR that we should
be looking at to consider what might be good to keep. Declaring the
whole thing Historic is not the right way to do that.

Technologies are converging. I think COPS-PR is more-telco oriented
than Netconf is. The OPS area and the IETF in general are in the midst
of a debate about allowing multiple protocols to be used to manage
networks, rather than trying to force one protocol to be used for all
purposes. We are having a discussion of what OAM means in different
environments. When COPS-PR came out, we had a philosophy of
SNMP-to-do-all-management, and "write a MIB" for all IETF standard
protocols. We have grown significantly in our viewpoints since then,
and are moving toward a "pick the tool that best does the job you need
done". I don't think that declaring COPS-PR Historic at this point in
time helps that. Maybe if we allowed PIBs to be standardized, COPS-PR
would actually get implemented and deployed on a wider basis. I
wouldn't bet on it, but we would be no worse off than we are now. 

I don't see the problem inherent in allowing COPS-PR and SPPI to
remain standards, and allowing PIBs to be standards-track, as long as
WGs are not required to write them. We are already allowing WGs to
"pick the tool    that best does the job you need done" - including
SNMP, Netconf, Syslog, IPFIX, and others that are being developed in
other areas. Maybe WGs would find COPS-PR to be a valuable tool for
managing Internet resources, such as applications and services, where
Netconf may not be "the best tool". Maybe if PIBs were allowed to be
standards-track, somebody would be willing to make the changes to
COPS-PR to make it more Netconf-compatible.

I just feel like we are trying to declare this Historic for the wrong
reasons.

dbh

> solution 
might 
> >>>> 22) GE apparently embeds the GridNet implementation in its
WiMax

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Sep 2009 12:54:05 -0400

Hi,

I don't think you can assume all deployemnts use one vendor's tools
just because there are no standard PIBs.
My research showed support in the Juniper/Netscreen products, and in
Huawei/HuaweiSymantec products.
I have no reason to believe all deployments use exclusively one or the
other's tools or PIBs.

It is safe to assume they may not interoperate across vendor
implementations, if that was your point. But that is our fault, when
we as a community decided not to allow PIBs onto the standards-track,
and effectively told the COPS-PR developers to just go home.

In the absence of standard YANG models, any netconf deployments are
not all based on one vendor's tools.
In the absence of standard YANG models, the Netconf deployments using
equipment from different vendors and vendor-specific data models are
also not interoperable. 

Is that the point you wanted to make? That interoperability is
hindered by not having standards-track models?

dbh

> Sent: Wednesday, September 30, 2009 11:51 AM
> To: Romascanu, Dan (Dan)
> I have no

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Sep 2009 10:07:20 -0700

>>>>> On Wed, 30 Sep 2009 18:01:04 +0200, "Romascanu, Dan (Dan)" <[email-masked]> said:

DR> I am not sure that I understand the point that you are making.

The point I was making was that your statement:

DR> In the absence of standards PIBs I suspect that the majority or all
DR> the deployments use one vendor tools and agents

I don't think is safe to say.  Unless you're saying there are no
standard PIBs anywhere (I don't know, personally).  There aren't any in
the IETF because the IETF chose not to publish them and actively
discouraged their use.  So if there are standard PIBs, we likely
wouldn't know about them.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Sep 2009 10:17:46 -0700

DH> I just feel like we are trying to declare this Historic for the wrong
DH> reasons.

David,

Well written and well said.  I personally don't use COPS, but I do
question the point of making it historic.  Why waste the effort for, um,
no gain?  IE, what's the benefit of spending the cycles?  Wouldn't it be
better to improve the other protocols instead?
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Paul Duffy <[email-masked]>
Date: Wed, 30 Sep 2009 13:19:49 -0400

Understood.  And to clarify, I (just me) came to this discussion just to 
confirm real world reality of the COPR-PR ecosystem, not to compare 
COPR-PR to NETCONF.

As an aside, I don't get the need for YANG, but that's just me  ;)

David Harrington wrote:
>>> We can write a short cal for input about implementations 
>>>       
>> and deployments
>>     
>>> of COPS-PR on the general IETF list, pointing to the 
>>>       
>> discussion going on
>>     
>>> in OPSAWG. Certainly such input may also arrive at the time 
>>>       
>> of the IETF
>>     
>>>>>> [mailto:[email-masked]] On Behalf Of David
>>>>>>             
> Harrington
>   
>>>>>>         
>>>>>>             
>>>>>> I have not been able to research these claims, but I am 
>>>>>>             
>> told that 
>>     
>>>>>> 1) Juniper uses COPS-PR for their resource allocation, 
>>>>>>             
>> using both 
>>     
>>>>>> 5) COPS-PR is in DOCSIS 1.0 QoS, which may still be used 
>>>>>>             
>> in cable 
>>     
>>>>>> deployments
>>>>>> 7) ITU-T has a proposal being considered that is based on
>>>>>>             
> COPS-PR
>   
>>>>>> 8) MultiService Forum has an Implementation Agreement 
>>>>>>             
>> for Dynamic 
>>     
>>>>>> The paper might identify some equipment that has COPS-PR
>>>>>>             
> support.
>   
>>>>> between academic papers, code implementation and 
>>>>>           
>> deployment. It is 
>>     
>>>>> for the vendors implementations - was COPS-PR deployed 
>>>>>           
>> and how?  In 
>>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Sep 2009 14:32:47 -0400

Hi,

To be clear, I did not come to this discussion to compare COPS-PR to
Netconf either.

I came to this discussion because two documents I am associated with
contained reference to COPS-PR, and members of the Netconf/YANG
community reacted strongly to its being mentioned in documents, and
wanted it declared Historic and the references removed from the two
documents. 

The proposed document for declaring COPS-PR Historic originally said
that all IETF configuration work is now centered on Netconf and YANG.
I dispute that all IETF configuration work is now centered on Netconf
and YANG. (This claim has been limited in -01-, but -01- still does
mention that other areas are considering other alternatives.)

As a result of this discussion occuring in IETF, we have found that
COPS-PR is in real-world use (although we need to vet the claims to
understand the extent of deployment).

In the course of this discussion, most of the reasons given for not
approving any PIBs for standards-track could equally apply to YANG
models, with an expected similar result of non-deployment. Andy
Bierman has been arguing that we need to get some standard YANG data
models, or Netconf will likely die.

The arguments that COPS-PR and PIBs lack wide deployment could also be
applied to YANG and Netconf. The fact that COPS-PR does not have wider
deployment may be directly related to a lack of standard PIBs.

I do not believe Netconf does a good job of replacing all the
functionality found in COPS-PR. Declaring COPS-PR Historic, and
continuing to explicitly discourage its use, denies the IETF a
potentially useful tool for managing technologies where a policy-based
management approach might make sense.

I question the need to declare COPS-PR et al Historic.

dbh

> Sent: Wednesday, September 30, 2009 1:20 PM
> To: David Harrington
> Cc: 'Romascanu, Dan (Dan)'; [email-masked]

> >>>>>> 4) Comcast uses a mix of COPS and COPS-PR in cable TV video
QoS

> >>>>>> International Workshop on Policies for Distributed Systems
and

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Oct 2009 09:54:49 +1300

On 2009-10-01 07:32, David Harrington wrote:
...
> understand the extent of deployment).

I think we should consider the effort that led to RFC4550
("Getting Rid of the Cruft: Report from an Experiment in Identifying and
Reclassifying Obsolete Standards Documents"). The IESG followed the
recommendations therein and reclassified a large number of standards
track documents to Historic.

The criterion for *not* obsoleting a document during that work were
described as:

"  ...a judgment is necessary as to whether or not a
   protocol is both in use and likely to be supported.  The parameters
   of our experiment were sufficiently conservative to avoid cases where
   protocols were likely to continue to be supported.  That is, anyone
   could remove a document from the list for any reason.  "

If the COPS-PR documents had been candidates for inclusion in RFC4550,
Dave Harrington's message would have been enough to remove them (and
in fact, since they are not Proposed Standards, they wouldn't ever have
been considered).

That doesn't tell us the correct decision here. But it does tell us that
the proposal is stronger than the approach taken in RFC4550.

That was written as the former AD who shepherded RFC4550.

As an individual, I don't believe that COPS-PR and PIBs are a success
story, and I'd be much less conservative in my approach than RFC4550.
So I support the proposal, personally (and as an ex-WG Chair responsible
for one of the RFCs in question).

    Brian

---

From: Phil Shafer <[email-masked]>
Date: Wed, 30 Sep 2009 17:01:46 -0400

>> both push and pull methods, at least in the access and 

The group that uses COPS-PR isn't one I work with, but Juniper does
actively use COPS-PR on some of our products.  These products are
widely deployed and are likely to use COPS-PR for the foreseeable
future.  Since we do not see standard content being defined for
COPS-PR, we would not object to having it classified as historical
for the IETF from an "ongoing development and interest within the
IETF" point of view, but it will continue to be "in use" in the
wild.

Thanks,
 Phil