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

[Jon Saperia <[e-mail]>]

Yes.

Many objects that are used in SNMP today were developed outside of the SNMP WG.  The larger community now has to look at the body of work completed in NETCONF/YANG and see how they might want to define standard configuration objects for their respective areas.


/jon


On Oct 5, 2010, at 11:22 AM, Andy Bierman wrote:

> It is going to require domain-specific WG efforts, not more netmod work.
> 
> Andy
> 
> ----- Reply message -----
> From: "Romascanu, Dan (Dan)" <[e-mail]>
> Date: Tue, Oct 5, 2010 02:22
> Subject: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA]	status and future of the isms working group)
> To: "Jon Saperia" <[e-mail]>, "Randy Presuhn" <[e-mail]>
> Cc: <[e-mail]>
> 
> 
> 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: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Jon Saperia
> > Sent: Monday, September 20, 2010 7:44 PM
> > To: Randy Presuhn
> > Cc: [e-mail]; [e-mail]
> > 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" <[e-mail]>
> > > ...
> > >> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ops-area
> > > 
> > 
> > _______________________________________________
> > Isms mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/isms
> > 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
>