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

----- Original Message -----
From: "Jon Saperia" <[email protected]>
To: "Randy Presuhn" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, September 20, 2010 7:43 PM

> 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

My current hot button is not data but protocols.  I am worried about the
explosion in 'OAM' (ie ping, traceroute etc) protocols to run in the MPLS
dataplane, that are being defined in the MPLS-TP nexus.  Before long, we might
have Y.1731 as a standards track RFC:-(

I was relieved to see the IESG sending back
draft-ietf-opsawg-mpls-tp-oam-def
but what happens next, metaphorically speaking? I would rather more people with
a background in the IETF were involved with this.

Tom Petch

> /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
> >
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area