Subject: why i should like pibs

From: "Hahn, Scott" <[email-masked]>
Date: Thu, 21 Mar 2002 09:19:14 -0800

I would like to say that this question bothers me. The term *significant* is
a highly subjective term that will be interpreted in different ways by
different people. The *significant* attribute that might convince you,
Randy, to make a purchase are probably a completely different set of
*significant* attributes that would affect my (or someone else's) purchase. 

I think the key point is that the IESG has chartered the working groups. The
COPS documents that are currently in front of the IESG are part of the
charters of the WG's involved. The IESG accepted these charters with these
documents as work items. And finally, the WG chairs were asked by the IESG
to request from the community at large for a count of companies that are
planning implementations of the protocol which resulted in a number of
positive responses. There are obviously volunteers from the IETF community
willing to do the work. I would like to see the IESG let the market decide
whether the advantages of using COPS and COPS-PR for configuration make it a
success or not.

	-Scott

---

From: "Durham, David" <[email-masked]>
Date: Thu, 21 Mar 2002 14:20:10 -0800

Reaction (sorry): I must remind Bert that he did advocate moving the
DiffServ MIB along on standards track despite it has demonstrated NO
ADOPTION FOR CONFIGURATION. Whereas the DiffServ PIB has ALREADY
demonstrated significant enough adoption to move to DRAFT STANDARD... And
yet this door is now being shut.

If it becomes a BIG THING, it means the industry has in fact decided! Why
should one stand in the way and prevent this from happening? 

The simple reason is that PIBs are easier to write and easier to use, and
that's why, despite the downfall of the Internet economy, they continue grow
and to amaze with their resilience. Artificially cutting them off at the
knees is simply not the IETF way.

-Dave

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 1:13 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: why i should like pibs
> 
> All,
> 
> Let me post to these lists a similar statement as I made in the
> RAP WG meeting at this 53rd IETF, so that everyone has the same
> info. Here we go. I would prefer to have andy reactions (if any)
> posted to just one mailing list (the RAP wg mailing list).
> 
> When the WG completed WG Last Call and reached consensus on
> the FRAMEWORK PIB, the WG chairs asked me (the primary AD
> for the WG) to consider this document for Proposed Standard.
> Normally I then review and ask for IETF wide Last Call and
> if no valid objections are received, then I put the document
> on the IESG agenda for approval.
> 
> My current evaluation however for this document at this time
> is as follows:
> - If we look at the NM related activities, then we can see
>   that for SNMP/MIBs, the majority of work/time/effort is
>   spent in the MIB development. It also touches on virtually
>   all WGs. Same will be true for COPS-PR/PIBs if we start to
>   put PIBs on the standareds track.
>   This could be a VERY BIG thing. In SNMP, the real investment
>   is in MIBs. This is true for MIB design (IETF), for vendor
>   implementation effort, and for user deployment. If IETF
>   working groups start to develop PIBs they would be faced
>   with significant extra, and in many cases, redundant effort
> - We have accepted COPS and COPS-PR 2-3 years ago as PS.
>   That was the start of a duplicate approach, which only
>   provides marginal improvement in some areas, and possibly
>   a negative effect in some other areas.
> - We have also accepted SPPI as a duplicate approach, again
>   with only marginal improvement. It allows to define PIBs,
>   most of which I think can also be done with MIBs or
>   better/different MIB design.
> - Note that PIBs are basically intended for configuring
>   network devices and services.
> - Two years back, the ADs and Diffserv WG chairs agreed to do
>   a MIB and a PIB for standards track. And we agreed with the
>   RAP WG to develop a set of base PIBs for standards track.
> - Meanwhile, we have seen:
>   - Some key players withdrew from COPS and PIBs approach
>     They claim there is no market, and with reduced budgets
>     there is no place to just do multiple solutions to same
>     address space.
>   - In most cases, PIB development is done by different people
>     than MIB development, if we're lucky they talk to each other.
>   - WGs in general have very little interest in MIBs or in PIBs,
>     let alone both.
>   - Operators (ISPs) tell us they do not see much use for binary
>     interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to
>     configure their network devices/services. The reality is that
>     they use (and expect to have to continue to use) ASCII based
>     CLI-type interfaces (Maybe ASCII should read human readable)
>   - We have started an effort to try and consolidate SMI and SPPI
>     We may want to await the results before we invest in the
>     standardization of PIBs.
>   - The NM community in the IETF (lots of SNMP folk, but COPS,
>     Policy WG and Operators are participating too) are trying to
>     come up with some vision/framework to address Operator (ISP)
>     concerns. Discussions is only in beginning stages and not any
>     IETF sanctioned status yet.
>   - IAB is planning a NM Architecture Workshop this summer (as
>     announced at the IAB plenary on Wednesday March 20th)
> - We (the IETF/IESG) are to decide on the first IETF produced PIBs.
>   If we approve them as standards track, then:
>   - I suspect we will find a lot of duplicate work, i.e. MIBs and
>     PIBs, to be designed, tested, handled-for-stds-track approval
>   - Vendors and users may be faced with the big duplicate investment.
>     They can opt to not do so, but of course the more PIBs we approve
>     as stds track, the more the pressure will be put on them.
>   - We are telling the market that we cannot decide and let them do it.
>     Maybe this is OK. But not in my mind, I do not think we do the
>     IETF community or the world a favor by approving this duplicate
>     approach
> 
> As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB
> (or any PIBs for that matter) on the standards track at this point
> in time. I strongly recommend to publish them as Informational for
> now. We can revisit this after we get some better architectural
> guidelines/help from the current actitivities that are taking
> place in informal gatherings and the upcoming IAB NM Workshop.
> 
> I understand that this is sort of "breaking the contract" with
> the RAP WG on my part. But the situation has changed quite a bit
> from 2 years ago when we started down this path (agreed on the WG
> charter).
> 
> Bert

---

From: John Schnizlein <[email-masked]>
Date: Wed, 27 Mar 2002 18:26:34 -0500

It seems time again for me to summarize my concern about COPS-PR
and PIBs. The intensity of feeling, apparent in the Plenary, that 
the ADs have done other than what we expect of them both motivates 
me to repeat what was ignored some time ago in Policy Framework
interim meetings and makes me recall that the little boy who said 
what he saw in the Emperor's New Clothes" fared poorly.

The fundamental problem with distributing policy to traffic-forwarding
devices rather than translating policy into configurations under the
constraints of the composition (topology) and capabilities of the
devices in the path of the traffic remains. It is essentially wishful
thinking that individual devices can determine the correct configuration
of their local parameters without the domain-wide information. I have
not been persuaded that the capability-exchange between the PEP and PDP
solves this problem. There are hints of importance of the domain-wide 
context in DiffServ's per-domain behavior (PDB) specifications.

It is even a mistake IMHO to invite network administrators to establish
policies their networks cannot deliver. Although consensus was never
reached on the architecture for policy networking, the insistence that
policy be independent of the devices and topology that started there 
seems to persist under the surface of the COPS-PR development.

My concerns about distributing un-interpreted policy appears to be
shared by the network operators who shared their view with people
soliciting "requirements for network configuration" when they say 
they do not want policy, or even configuration, distributed to devices
until they know what it will do to the network.

Response to particular points:

At 04:50 PM 3/26/2002, Walter Weiss wrote:
>... First of all, the pervasive perspective that there is only one 
>operations organization is very misleading. ... Therefore, drawing 
>conclusions about the value of COPS or PIBS to operators is premature. 

Good point. Standardizing without expected value is not the IETF way.

>I would also like to consider this issue from a requirements perspective. In
>my view, we can divide operational needs into four areas: Stats Collection,
>Events, Static config and Dynamic config.

This taxonomy of operational needs for network management is novel.
Instead of the 5 FCAPS categories, it creates 4, with a new distinction
in configuration that may or may not have value. It also seems that
this Dynamic Config has a lot in common with what has been supported in 
RADIUS as user profiles. Why is this not better treated as a QoS case
of authorization? 

>I would also like to reconsider Bert's points. First, I would agree that the
>level of interest in COPS-PR is relatively small. However, I would argue
>that this is because Dynamic Config is only starting to become important as
>mappings for QoS, Security, and Tunneling are coming to the forefront.

Maybe we should see if this new category of Dynamic Config really develops
before standardizing it into existence.

>Second, I disagree that there is overlap with PIBs. While the DiffServ PIB
>and MIB are nearly identical, this was done because it was assumed that they
>were both addressing the config space that CLI is so clearly dominating. In
>the absense of a common model for all config, I believe this was a mistake.

Don't follow this. You think any correspondence in the data models for the 
DiffServ application is a mistake without a "common model for all config"?
Wouldn't incremental steps be more practical?

>Given the unique applicability of COPS-PR, PIBs should be defined
>specifically for this purpose and only this purpose. 

Which unique applicability of COPS-PR is this? The newly proposed
Dynamic Config?

>On Bert's third point,
>I would argue that the investment in PIBs is far smaller than he suggests.
>Given the specific scope of applicability, PIBs would not be appropriate for
>most IETF activities involving failure events or static config (routing,
>transport and applications). Hence, the number of PIBs is relatively small.
>Further, I do not believe that any of the alternatives on the table can meet
>these requirements to the extent that COPS-PR can.
>
>I would agree with Juergen that what we have today is a hodge-podge of
>protocols and mechanisms for configuration management and little incentive
>for changing the situation. As such, I see two alternatives:
>1. We can use COPS-PR and restrict it specifically to the area that it
>addresses most effectively: dynamic config management (at the network edge).
>2. We can block progress on all config drafts/standards to motivate a
>solution to Juergen's larger issue of concerted participation in a single
>and uniform set of standards.

No one has proposed to "block progress on all config drafts/standards"
up until this point. Way back in the Configuration Management BOF in
Washington, I thought Bert supported Experimental status as the best
way to explore the new ideas proposed with COPS-PR and PIBs.

>We could also block the advancement of COPS-PR. However, that prevents us
>from addressing the dynamic config space and does not advance an
>alternative. 

Bert's original suggestion of Experimental seems again the best way to
encourage use of the new ideas in COPS-PR. I have never seen him (or
Randy, for that matter) try to "block advancement".

John