Subject: [netmod] smi2yang general problem statement

From: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Apr 2011 13:48:32 +0200 (CEST)

Hi,

I think that the WG needs to think about and document how this mapping
is supposed to be used.  Some people might think that with the
publication of this mapping, IETF recommends that non-config data is
modelled in SMIv2, and config data is modelled in YANG.  With the
smi2yang translation, all objects are then accessible over NETCONF.

I think this would be unfortunate.

In some simple special cases, one can argue that it is better to use
the YANG module generated from a MIB, than to write a YANG model for
non-config data.  IF-MIB is one example.  This is a fairly simple MIB
in its structure, and people know it well.

But in other cases, the structure of the data represented in the MIB
might be better modelled using the features of YANG. 

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 9 Apr 2011 17:00:40 +0200

> might be better modelled using the features of YANG. 

A general long-term strategy does not seem to exist as far as I can
tell. Perhaps it would be nice if there were such a grand plan but
then I think writing one would be a separate effort, not part of the
SMIv2 to YANG translation specification.

/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: Sun, 10 Apr 2011 10:26:09 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Saturday, April 09, 2011 6:01 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: [netmod] smi2yang general problem statement
> 
> A general long-term strategy does not seem to exist as far as 
> I can tell. Perhaps it would be nice if there were such a 
> grand plan but then I think writing one would be a separate 
> effort, not part of the

Indeed. But maybe it is time to start thinking about such an effort of
defining a long term strategy as well as an architecture for Internet
management. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 Apr 2011 09:07:06 -0700

> defining a long term strategy as well as an architecture for Internet

We have a hard time with 1-size-fits-all.
We don't have that for NETCONF by itself, so we won't have it
for the multi-protocol big picture either.
Our goal right now should be to provide reasonable standard config modules
for common features that are only configured with proprietary CLI today.

Our progress on infrastructure modules is not very fast.
We have to focus on must-have, not nice-to-have.
IMO, rewriting data models that already exist in SMIv2 for operational data
is going to take way longer than we think, and it is not clear that
is the right approach anyway.  The RMON MIB modules (i.e., configurable monitoring)
are a corner-case perhaps.  Some vendors have proprietary CLI config
instead of SNMP config for RMON, so maybe these MIB modules are worth redoing.

Applications will not evolve in all-or-nothing fashion.
For example, the SNMP notification receiver component doesn't need to change
because the config and reports sections evolve from screen-scraping CLI to NETCONF.

The applications that use SNMP monitoring instead of CLI screen-scraping show commands
may not need to evolve.  An application that never used SNMP is more likely to take advantage
of the MIB data that is (soon to be) available via NETCONF SMIv2-to-YANG translation.

Some vendors are using custom 'get' operations, instead of config=false datastore access via <get>.
Some WG members feel we still have a problem with an over-simplified model that does not
account for all types of operational data, or complex config states, such as pre-provisioning.
We may not have the NETCONF-only architecture completely done yet, and the
multi-protocol architecture will depend on the details.

> Dan

Andy