RE: why i should like pibs

["Durham, David" <david.durham@intel.com>]

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:bwijnen@lucent.com]
> Sent: Thursday, March 21, 2002 1:13 PM
> To: rap@ops.ietf.org
> Cc: diffserv@ietf.org; ipsec-policy@vpnc.org
> 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