Subject: snmpconf Re: TE-MIB readonly or read/write

From: Jon Saperia <[email-masked]>
Date: Mon, 18 Dec 2000 06:34:36 -0500

on 12/13/2000 12:36 PM, Tony Tauber at [email-masked] wrote:

> I'm inclined to agree.
> 
> I don't do SNMP sets and believe that's the common practice
> among operators today (as Randy mentioned), but can't see
> a good architectural reason to deny this possiblity right
> out of the gate and box ourselves in.
> 
> If people choose not to use this capability or to administratively
> prohibit it, that's fine; just like is done with SNMP sets today.

There has been quite a lot of email on this topic. The two paragraphs above
make two good points. One of the reasons operators do not do much with SNMP
sets today is that there are very very few standard objects to set. I
believe the job of the people developing the standard MIB Modules is to
provide complete management coverage. For those operators that do not wish
to use set operations, they can continue not to use them. This time they
will have a real choice, not because there is not much worthwhile to do with
them as has historically been the case.

The issue that I have raised is that for the newly created area, we should
provide complete coverage.

/jon

---

From: "Suresh Krishnan" <[email-masked]>
Date: Mon, 18 Dec 2000 11:08:52 -0800

Hi Jon,

> > prohibit it, that's fine; just like is done with SNMP sets today.
    The MIB could be created as Read-Write and the implementers of the snmp
agent could use the AGENT-CAPABILITIES to redefine it as Read-only , if they
do not want people to have R/W access to the MIB.

Thanks
Suresh

---

From: Jon Saperia <[email-masked]>
Date: Tue, 19 Dec 2000 05:25:31 -0500

> do not want people to have R/W access to the MIB.

I think we have a clear consensus among those that have recently
commented. Define the MIB module completely including
configuration/control objects. There are plenty of standard mechanisms
by which vendors and users can use less than the full set of
capabilities.

/jon

---

From: David Partain <[email-masked]>
Date: Tue, 19 Dec 2000 15:50:45 +0100

Howdy all,

I've axed most of the cc'ed folks and reduced it to TE and
SNMPCONF.

Jon Saperia wrote:
> I think we have a clear consensus among those that have
> recently commented. Define the MIB module completely including
> configuration/control objects. There are plenty of standard
> mechanisms by which vendors and users can use less than the
> full set of capabilities.

I completely agree.  Given that we _do_ have a secure way of
using SNMP now, I think it would be a mistake not to include
read/write objects in the MIB.  While some vendors may decide
not to implement them read/write, others certainly might
want to.  In my opinion, the MIB writers shouldn't make that
decision for them.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Dec 2000 06:54:02 -0800

> commented.

the tyranny of the verbose and stubborn?  :-)

> Define the MIB module completely including configuration/control
> objects. There are plenty of standard mechanisms by which vendors and
> users can use less than the full set of capabilities.

in light of the ccamp mandated separation of measurement and control
planes, this rush to judgement might take a bit of a pause.

randy

---

From: Jon Saperia <[email-masked]>
Date: Tue, 19 Dec 2000 10:47:24 -0500

Ran Wrote:

>         A large part of the reason operators disable/don't use
> SNMP SETs is that most managed devices haven't shipped SNMPv3
> with (at least) MD5 authentication yet.  The most widely used

I wanted to double check before responding. Last I knew, your statement
was correct for Juniper. It has not been correct for Cisco for some
time. From what I can tell most ISPs have a 12.x that should have these
features. 

> network management platforms DO have SNMPv3 capability today,
> either via a 3rd party plug-in (e.g. SNMP Research's module
> for HP OpenView) or natively (e.g. Objective Systems' NetExpert
> package).

True enough. There is also third party code (some of it freeware) that
also has full v3 support.
> 
>         It would be helpful all around if folks who build boxes 
> would evangelise within their own employer -- to cause the 
> implementation (and shipping) of SNMPv3 (with at least MD5
> authentication, preferably both MD5 and DES-CBC) in their 
> respective boxes.
> 
Agree.
/jon

---

From: Jon Saperia <[email-masked]>
Date: Wed, 20 Dec 2000 07:29:01 -0500

> planes, this rush to judgement might take a bit of a pause.

Randy, I was confused by by your comment so I double checked with Scott
Bradner to verify my understanding. I believe that the separation you
point to is part of a three part plane of management and control
functions. There is a desire to standardize two of the three. 

           1. The first, and lowest layer in this view, is the box to
           box control protocol. A request to set up a new path, for
           example. Two cooperating devices would use the protocol to
           request a new path establishment and probably report certain
           conditions to the operational software. Using a routing
           analogy, this would be the exchange of LSAs. Clearly there is
           benefit to the standardization of such things.

           2. The second plane is the 'brains of the operation'. This is
           the portion that Scott and others believe is best left
           un-standardized. It is at this layer, that the decision about
           whether to ask for a new path is made. One vendor may have
           better heuristics than another and thus might distinguish
           themselves. Interoperability is not compromised in this
           regard since the two systems use the layer I described above
           to communicate the request for a new path.

           3. The third plane, and the one that is the only subject for
           the MIB Modules under discussion is the management
           plane. This plane has objects for the configuration and
           control of the behavior of the system. These controls are
           interpreted by the brains with the resulting behavior on the
           wire. Also it is at this layer that one would write MIB
           objects for usage counters and errors for example.

I believe the "Define the MIB module completely including
configuration/control objects." statement was intended to address only
the third plane. The plane that is historically in the management
domain. People want to be sure that the interfaces to the external world
are standardized, planes one and three, while the middle one is left
open for vendor innovation. This approach could equally be applied to
routing protocols or other areas of technology.

If we are in agreement on these points, then there is no issue unless
you
do not want configuration and control objects in the MIB Module(s).

/jon