From:         Bert Wijnen (primary OPS AD for RAP WG)
Subject:      Evaluation of FRAMEWORK-PIB and DIFFSERV-PIB
Last changed: April 12th, 2002

When the RAP 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 for the 
    same problem space.
  - In most cases, PIB development is done by different people
    than MIB development, if we're lucky they talk to each other.
  - Many 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 are only in the beginning stages and
    do not have 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 IESG to approve the FRAMEWORK-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 (as documented in 
the WG charter).

Bert