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

From: "Andy Bierman" <[email-masked]>
Date: Tue, 05 Oct 2010 10:51:14 -0700

We have the description stmt for clarifying that operstatus is related to adminstatus.  Adding a machine readable stmt for that will have no impact on the deployment of standard content.  RFC publication of standard content will have an impact.

Adding more protocol bells and whistles is just an excuse for delaying the real data model definition work.

Andy

----- Reply message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, Oct 5, 2010 10:39
Subject: [netmod] True for NETCONF/YANG as well (was: RE:	[Isms][OPS-AREA]	status and future of the isms working group)
To: "Andy Bierman" <[email-masked]>, "Juergen Schoenwaelder" <[email-masked]>, "Jon Saperia" <[email-masked]>
Cc: <[email-masked]>

Those three modules (plus minus one) are the core of the rechartering
scope. 

But can you write an interface table without clarifying how admin/oper
status is modeled? This is not a corner issue imho. 

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Tuesday, October 05, 2010 7:34 PM
> To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Jon Saperia
> Cc: [email-masked]
> Subject: RE: [netmod] True for NETCONF/YANG as well (was: RE: 
> [Isms][OPS-AREA] status and future of the isms working group)
> 
> I do not agree at all that the lack of standard data models 
> for configuration has anything at all to do with the 
> clarification of corner-case operational data, such as the 
> duplex-mode = 'auto' example that has been used many times.
> Plain old config vs. plain old state data is just not a problem.
> 
> The lack of 3 things that are so obvious they should not need 
> mentioning, but here they are again (since repetition is the 
> key to learning ;-)
>    * system group
>    * interface table
>    * ENTITY-MIB replacement
> 
> Some vendors will insist that their own proprietary versions 
> are good enough.
> I think that is the real problem -- there are no vendors 
> motivated to work on a standard solution for these 
> infrastructure data models (my employer included).
> 
> 
> Andy
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, October 05, 2010 10:22 AM
> To: Juergen Schoenwaelder; Jon Saperia
> Cc: [email-masked]
> Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: 
> [Isms] [OPS-AREA] status and future of the isms working group)
> 
> The re-chartering is on the table of the IESG. I agree with 
> Juergen here, I think that the NETMOD team should do one more 
> step in creating a small base of core YANG modules that would 
> both provide basic infrastructure objects and a small set of 
> examples about how to structure data models. Other WGs in the 
> IETF areas or other SDOs will continue to build on this work 
> and extend the data models according to their needs.
> 
> Dan
>   
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> > Sent: Tuesday, October 05, 2010 7:07 PM
> > To: Jon Saperia
> > Cc: [email-masked]
> > Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: 
> > [Isms] [OPS-AREA] status and future of the isms working group)
> > 
> > On Tue, Oct 05, 2010 at 05:30:32PM +0200, Jon Saperia wrote:
> >  
> > > 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.
> > 
> > Nope, the NETCONF/NETMOD framework still lack a common 
> understanding 
> > how to structure data models (missing basic
> > infrastructure) and we do not really know how to deal with the 
> > distinction and modeling of the relationship between 
> operational state 
> > and configuration state. This is why NETMOD was supposed to 
> recharter 
> > to put the core data models in place. At least that was my 
> > understanding at the last IETF.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> > _______________________________________________
> > netmod mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod