[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> > I think we have a clear consensus among those that have recently
> > 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

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
do not want configuration and control objects in the MIB Module(s).