Re: why i should like pibs

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

[Since people want to have something in the records for our historians...]

>>>>> Durham, David writes:

>> Items a) and b) are technically easy to support in SNMP. The real
>> problem here is the "SNMP community process" which is in blocking
>> mode for several years now for various non-technical reasons.

Dave> [Dave] By the time you integrate all the COPS-PR features and
Dave> advancements into SNMP, you still get COPS-PR, just 5 years too
Dave> late. But, perhaps the best reason of all for COPS-PR and PIBs
Dave> is that you don't have the "SNMP community process" that you
Dave> just described.

This touches the real issue: The work in the IETF network management
area is way too much controlled by vendors rather than the users who
need to operate networks. Example: Almost every SNMP user I know of
who had to retrieve large tables knows very well that the overall
speed sucks (and I am not referring here to those implementations that
suffer from specific problems in their instrumentation).

The IETF and the rules of the standards process have been used by the
SNMP community continously to block forward process in order to
satisfy some vendor interests, ignoring the real user interests.
Because this problem persisted a long time, we finally got COPS-PR
which tries to address some user interests but which is also driven to
a large part by vendor interests - it is just another camp of vendors.
And now these vendor gangs use the IETF and the rules of the standards
process to fight against each other, certainly not the users interest.

I have heard from operators that they really have no interest in
getting a new protocol every time the IETF fails to resolve deadlock
situations or has battles between vendors. For the people running
networks, every new management standard just adds to the technology
nirvana and makes things worse and more expensive.

A future where we have MIBs/SNMP for monitoring, PIBs/COPS-PR for
"dynamic" configuration, CLIs (standard and non-standard) for "static"
configuration, Radius/Diameter for service installation / activation /
termination, policies and LDAP for automated reconfiguration, ... is
really a poor end result if you look at it from the perspective of
someone who has to operate networks in cost effective ways. Sure, a
some set of vendors (especially toolkit providers) make money with all
these competing technologies while all the other vendors pay a price
to support multiple technologies. And the users who operate networks
are the real loosers since they only have the option to either deal
with all of this stuff or to bind themself to just one or two vendors.

This is my understanding of the current situation. Sure, I am
simplifying quite a bit and I am putting some things to an extreme.
But I certainly believe that in order to do something good for the
Internet and the people who actually keep the Internet running, the
IETF should find ways to give actual users a more effective direct
feedback channel into the standards process.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>