Subject: RE: prequeal to WG lat call om the LSR mib module

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Wed, 11 Jun 2003 16:01:59 -0400

Hi Tom,

I appreciate your extensive implementation
experience and your willingness to share
your analysis with the group.  However, I
strongly support Adrian's position on the
issue of read-write objects in this (and
most other) MIB.

The question "Is anyone really using it
for provisioning anyway?" appears to be
of the chicken/egg quandary type.  Well,
now we have a "chicken" (so to speak!)
in SNMPv3...let's have it give birth to
lots of useful agents and applications.

The concept of producing a separate
"Provisioning MIB" has its own merits
when one means by that a higher-order
MIB that would focus more on logical
or service kinds of entities rather
than specific transport level atomic
objects.  However, such an endeavor
should not, IMHO, obviate the need
for and value of Set-ability of
appropriate objects in lower-order MIBs.

Cheers,

BobN

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 10:59 AM

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, June 11, 2003 10:45 AM
> 
> Tom wrote...
> 
> > Since we are spinning around in the mud
> > on this, let me make a proposal that would
> > make this problem go away. Lets make
> > the LSR MIB entirely read-only.
> 
> Yeah, right.
> Let's remove half the utrility of this MIB!

	I disagree that half of its utility is
in read-write access. Is anyone really using it
for provisioning anyway? In the nearly 4 years that
I have been working on this MIB I have been made
aware of precisely 0 implementations that used it
in a writable mode.  If you have been, please stand
up and be heard!
 
> There is valuable utility to write-access in the LSR MIB. 
> Manually provisioned LSPs (PVC-style) are important in all 
> networks, but especially in ATM and FR. If you talk to your 
> transport people, they'll tell you that support for this 
> function in the GMPLS/TDM/optical world is essential.
> 
> This is a non-starter. We discussed the need for this MIB to 
> have write access at least three years ago, and added it then.

	I am not disputing that provisioning functions are 
essential, but they are not possible in the LSR MIB
without lots of other changes. Your proposal will not
fix the provisioning issue you raised. Why don't we just 
punt on provisioning and re-visit the issue with a 
provisioning-specific MIB in the future that allows for 
specific per-application provisioning semantics?  
This is indeed at the heart of the issue you raise.
This is perfectly acceptable too. The AD stated at
a recent IETF meeting that it was indeed okay for 
WGs to produce read-only MIBs if there was consensus 
to do so.

	--Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Jun 2003 22:35:09 -0400

In message <[email-masked].
> appropriate objects in lower-order MIBs.

Bob, 

I've been on the provider side of this and quite a long time ago Bay
networks made every aspect of their provisioning available in the MIB
and we found that completely *unacceptable* for various technical
reasons, some of which go away with SNMPv3, others which may not.

Router configurations can be huge and changes need to be atomic.  The
old way to do this was to do sets, then gets to verify the sets.  This
was excruciatingly slow and was not atomic.  Bulk sets may go a long
way toward solving this.  Even so, MIB dumps are barely human
readable.  There needs to be ways to generate configurations but also
ways for operators to read and eaily understand the configuration and
change them if needed.  A read-write MIB is poorly suited for this.

At this point I'm on the provider side of things and I'm not hearing
anyone that is running a network saying they want to configure their
network with SNMP.  All our MIBs are read-only and no customer
considers that a problem.

Given that situation we don't care if the IETF is defining MIBs to be
read-write or read-only.  We are implementing them read-only, advising
customers of that and not a single customer is complaining about it.
If they complain, we'll change but they haven't.

Curtis