Re: Call for censensus on path forward

At 9/23/2002:01:54 PM, Wes Hardaker wrote:

Hi Wes,

>Bob> b.  At the risk of showing my age, I believe that
>Bob> MIBs can be made *vastly* more capable -- in terms of, e.g.,
>Bob> aggregate/derived objects, behavior/operations, secure sets,
>Bob> multi-entity interoperation, publish/subscribe services, etc.
>Bob> -- without major mods to the SMI and definitely
>Bob> without modifications to SNMP[v3] itself.
>
>Interesting.  So, you generally disagree with the reasons behind the
>chartering if both the EoS working group and the SMIng working group?

Generally, I think it's less important than nearer-term
exploitation (in the good sense) of possibilities already
existing in SNMPv3 and the SMI.  Better MIBs and agents
that implement them offer "low-hanging fruit" for a
resurgence of interest in SNMP.  This "bottom-up" paradigm
may then fuel the network management applications that will
take advantage of them.  (I think we can all agree that
waiting for capable "top-down" network management applications
to extract the (often elusive) non-trivial capabilities of
(most) existing MIBs and agents is futile at this point.)

However, I am not at all opposed (quite the contrary!) to 
either IRTF-like research and planning efforts or to a
"standing body" of sorts to oversee SNMP evolution.

>(on a side note, have you read some of the operator-requirements
>documents?)

I am not sure which particular documents you are referring
to here.  I spend most of my time every day working with
major service provider RFIs and RFPs.  In that domain, the
current vogue is "control plane" (e.g., GMPLS) to "management
plane" automation via TMF Multi-Technology Network Management
(MTNM v2, 814) CORBA API/IDL/SIDM.  SNMP is on the way out.
SNMPv3 offers an opportunity to reverse the trend a bit,
as security is getting more than lip-service in some of the
most recent procurements.  However, the (anticipated) OpEx
gains via "bottom-up" paradigm (control plane automation,
publish/subscribe flow-up interfaces, etc.) might, in the
end, out-weigh even the security concerns.  (And TMF
proponents can point to the OMG CORBA security options
as an alternative.)

>I think much of the newer work is not to say that it's not possible to
>do things with the existing technologies (both SMI and PDU types), but
>that it's hard and the effort to make things happen is large.  If the
>effort can be reduced, then the number of MIBs we can deploy in the
>future will likely be greater and will increase in deployment speed.
>I suspect, though, that you disagree with this.

It's hard to use existing SNMP technologies for significant
management applications in the legacy "top-down" paradigm
(which can be reduced to "dumb agents"...not a normative
critique...that's what the old model called for).  On the
other hand, a "bottom-up" paradigm in which MIBs are far
richer in terms of *information* (as opposed to *data*)
content and support notions like operations, in which agents
are more capable (do more of the work behind the MIB), and
in which management communications are driven mostly by a
publish/subscribe arrangement (as opposed to a polling
arrangement) -- combined with the increased focus on
security requirements -- affords another opportunity for
SNMP to regain marketplace relevance.

I don't really have "increasing the number of MIBs" or
even "increasing the deployment speed of MIBs" as goals
unless and until the paradigm shifts from top-down to
bottom-up and the quality of the MIBs and the agents
behind them improves accordingly.  This is what I think
ought to be the goal of the Ops Area at this time wrt
near-term SNMP evolution.

Lastly, in terms of an IRTF-like effort, I don't
disagree at all with your (or EoS, or SMIng) direction.

Cheers,

BobN