Subject: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 5 Oct 2010 11:22:29 +0200

I cannot agree more as well to:  

>  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.

And I am copying the netmod list on purpose because I hold the opinion
that this statement made in the SNMP / ISMS context is true for the
current state of the NETCONF and YANG evolution as well. 

I hope that the rechartering of the NETMOD WG will be soon approved as a
step in this direction. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jon Saperia
> Sent: Monday, September 20, 2010 7:44 PM
> To: Randy Presuhn
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isms] [OPS-AREA] 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-masked]>
> > ...
> >> 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-masked]
> > https://www.ietf.org/mailman/listinfo/ops-area
> > 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>