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 08:22:21 -0700

It is going to require domain-specific WG efforts, not more netmod work.

Andy

----- Reply message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
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" <[email-masked]>, "Randy Presuhn" <[email-masked]>
Cc: <[email-masked]>

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
> 
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Jon Saperia <[email-masked]>
Date: Tue, 5 Oct 2010 11:30:32 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Oct 2010 19:07:06 +0200

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 5 Oct 2010 19:21:44 +0200

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 Oct 2010 10:29:40 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Jon Saperia" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, October 05, 2010 10:07 AM
> Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group)
...
> relationship between operational state and configuration state.
...

Total agreement.

This need for a "meta-model" (for lack of a better term) was a recurring
concern when we were putting together the data modeling requirements
i-d way back when.  However, I fear that such a thing is unlikely to come
to be unless there has been a major cultural shift in the IETF.  The netconf
pendulum has swung in the direction of encouraging maximum vendor
differentiation, to the point of not even nailing down such fundamentals.
Any effort to nail things down now will probably meet with fierce resistance
from those whose deployed models don't map well to whatever the meta-
model ends up being.  And, for better or worse, running code trumps theory.

Randy

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Oct 2010 10:34:09 -0700

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)

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 5 Oct 2010 19:39:47 +0200

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

> 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.
> 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
> 
> 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
> 
> 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> 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
>   
> 
> 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
> > 
> > --