Re: [Isms] status and future of the isms working group

I could not agree more. 

I would add  that additional protocol/architecture/framework on any of the management infrastructures we have does not address the key point I took from Randy's post.  What we need are widely implemented objects (however you want to call the structures) that give real visibility into what is going on in the devices and networks.  That has always been the problem and until we address that who cares how we transport the data. I would settle for RFC2549, if it contained the right information.

/jon
On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote:

> Hi -
> 
>> From: "t.petch" <[email protected]>
> ...
>> I think that our resources are limited, and tend to decay with the age of a
>> working group, so I would rather see them applied elsewhere.  I look back at the
>> effort that went into RFC3411, over many years, and yet it fell at the first
>> hurdle, not accommodating the move of security from deep inside the engine to
>> off the bottom of the radar; why should we do any better this time?
> ...
> 
> The problem as I see it was that RFC3411 was intended to be the glue
> describing how a particular set of specifications fit together, *not* as
> *the* architecture for all future SNMP work.  *Requiring* extensions,
> additions, and embellishments to adhere to that architecture is in
> my opinion a huge mistake.  From my perspective, the real problem
> addressed by RFC 3411 was that some of the preceding proposals
> for securing SNMP had so many convolutions and interactions that
> a lot of folks had trouble wrapping their heads around them.  The
> modularity brought by RFC 3411 was modularity of *specification*,
> not necessarily implementation.  The ASIs were rather controversial
> because folks were (rightly, in retrospect) concerned that they would
> be understood in a prescriptive sense, rather than descriptive sense
> in which they were intended.
> 
> More importantly, I think focusing energy on this "problem" (which is
> tempting because it's something we think we understand) would be
> a huge distraction from the *real* problem: the kinds of information models
> this infrastructure should provide access to.  If the information models
> can't support the high-value functions administrators / operators need,
> then embellishing the protocol engine architecture is a waste of time.
> 
> Randy
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>