Subject: [NGO] CANMOD req 3.8.3 -- reinvent the wheel

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Mar 2008 06:57:15 -0800

Hi,

This requirement really misses that mark, wrt to the big picture:

3.8.3.  Minimize SMI Translation Pain (NOT Agreed)

    Minimize translation pain from SMI into NETCONF content.  Translation
    of NETCONF content into SMI is not a consideration.  Disagreement
    about this requirement stems from concern about the possibility that
    this might be interpreted as requiring the perpetuation of SMI-style
    models, rather than merely accommodating the basic types, as
    described in the work-in-progress
    [I-D.ietf-opsawg-smi-datatypes-in-xsd].

This not-agreed-upon requirement is of some concern to me.
Only YANG has any tools for translating MIB definitions
into the 'next-gen DML'.  The other proposals talk about
how important it is to reuse standards, but when it comes
to reusing any of the standard or proprietary MIBs created
over the last 2 decades -- that is somehow not important.

The IETF has a distinct pattern to development of MIBs.
They are done slowly, but a lot of attention is given to
reusability.  Reinventing MIB objects instead of reusing the
existing infrastructure is just Bad Engineering.

So now we are moving forward with NETCONF MIBs, and the official
plan to tell the world is "Don't reuse anything.  Toss out
all the MIB work and start over."   About half of all MIB work
extends some existing data model in some way.  For all the
vendors and WGs who already have some MIB definitions that
will need updating over the years -- tough luck, start over?
Wrong answer.

The NETMOD WG (or whatever WG) MUST develop a solution
that provides for reuse of existing MIB data models.
It is unacceptable to toss out all the data models
in MIBs and start over with XML.

Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 4 Mar 2008 10:10:00 -0500

Hi

SNMP, for the most part, was not a configuration protocol and its MIBs
were primarily used for operational data. It isn't clear to me, in
practice, how much benefit we would get from trying to leverage this
investment when trying to create a quality configuration model
(including supporting hierarchies of arbitrary depth). I'm much more
interested in looking at what can be done to align the NETCONF data
model with CLI models personally. I think a disconnect between CLI and
NETCONF will be much more an issue then if extra glue is required
between SNMP and NETCONF.

Sharon  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andy Bierman
Sent: Monday, March 03, 2008 9:57 AM
To: NETCONF Goes On
Subject: [NGO] CANMOD req 3.8.3 -- reinvent the wheel

Hi,

    Minimize translation pain from SMI into NETCONF content.
Translation

This not-agreed-upon requirement is of some concern to me.
Only YANG has any tools for translating MIB definitions into the
'next-gen DML'.  The other proposals talk about how important it is to
reuse standards, but when it comes to reusing any of the standard or
proprietary MIBs created over the last 2 decades -- that is somehow not
important.

The IETF has a distinct pattern to development of MIBs.
They are done slowly, but a lot of attention is given to reusability.
Reinventing MIB objects instead of reusing the existing infrastructure
is just Bad Engineering.

So now we are moving forward with NETCONF MIBs, and the official plan to
tell the world is "Don't reuse anything.  Toss out
all the MIB work and start over."   About half of all MIB work
extends some existing data model in some way.  For all the vendors and
WGs who already have some MIB definitions that will need updating over
the years -- tough luck, start over?
Wrong answer.

The NETMOD WG (or whatever WG) MUST develop a solution that provides for
reuse of existing MIB data models.
It is unacceptable to toss out all the data models in MIBs and start
over with XML.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Mar 2008 07:43:30 -0800

> between SNMP and NETCONF.

It is probably true that an application which writes an initial config
to a NETCONF device can ignore all MIB data.

Applications which do provisioning, or need to
diagnose a broken configuration (very important use cases), will
likely need various state information, in addition to the current
configuration.

There is a huge difference between writing all the NETCONF monitoring
data models from scratch, and typing 'make' so some tool generates them
all in an instant.

Nobody is proposing an all-or-nothing reuse scheme for SNMP MIBs, but
rather the ability for a DM writer to choose MIBs, tables, columns,
and/or notifications from the vast set of MIB modules, and easily
integrate that reuse into a new data model.

In addition, many SMIv2 objects are read-only for political reasons,
like the ifMtu object.  An API for NETCONF does not need to maintain
the exact structure of the SMIv2 data model.  For example, an 'edit-config'
operation could reuse the syntax and semantics of the ifMtu leaf,
except for the MAC-ACCESS read-only part.

The choices are not 'reuse all MIB objects' or 'ignore all MIB objects'.
The DM designer needs the ability to pick and choose, based on the
requirements of the new data model.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 04 Mar 2008 17:57:40 +0100

HI think reusing a few central objects like interface tables (and probably more) will be 
requested. The SNMP part is clearly used in alarms/traps and performance monitoring, while we 
will want to do configuration from NETCONF. So if we have some mapping between SNMP and NETCONF 
that helps.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Mar 2008 11:18:23 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Sharon Chisholm" <[email-masked]>
> Cc: "NETCONF Goes On" <[email-masked]>
> Sent: Tuesday, March 04, 2008 7:43 AM
> Subject: Re: [NGO] CANMOD req 3.8.3 -- reinvent the wheel
...
> requirements of the new data model.
...

The requirement was phrase in terms of "minimizing pain" in order
to avoid being misunderstood as a requirement for fully automated
mappings or a complete carryover of all existing MIB modules.
The intent was simply that we shouldn't make it unduly difficult
to make use of work that has already been done.  However, in
the design team, we were not even able to get agreement on
that terribly low bar, much less the more ambitious (and in my
opinion more useful) support for selective automatic conversion.
I think the situation can be summed up this way: even though
folks don't want to agree to this a requirement, it's probably
satisfied to some extent by all the proposals.  Go figure.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Mar 2008 12:36:19 -0800

> satisfied to some extent by all the proposals.  Go figure.

The larger issue is the process the IETF is going to
use for standardization of data models for configuration.

Are WGs expected to toss out all NM data in the form of MIBs
because there is a new protocol and new encoding?  Or are WGs
going to look at what already has been standardized in MIBs
to see if any of TEXTUAL-CONVENTION, OBJECT-TYPE,
or NOTIFICATION-TYPE macros already in existence can be reused.
There's only about 100,000 to choose from, so no big loss
if we just ignore all of them :-(

Isn't there the possibility that most MIB definitions are
really network management definitions, and most SMIv2 and/or
SNMP 'protocol leaks' are trivial or even irrelevant?
Talk about throwing the baby out with the bath water...

Reusing SMI concepts, range definitions, etc. certainly makes
conversion easier, but in the case of YANG, a lot of hard work by
the programmers, and some DML extensions to better support
the conversion, had more to do with support for SMIv2 reuse.

You are correct that somebody could take any of
the CANMOD proposals and do the work to create tools
for SMIv2 conversion.  It is just an implementation detail
for the purposes of our discussion.  For an operator, the
existence of real tools may mean a bit more than that.

A first-order problem we keep bumping into is the difference
between 'vendor concerns' and 'standards concerns'.
Most vendors do not tend to volunteer to add many features
to their products related to the latter.
IMO, the IETF is way too much work and takes way too long
not to get some real interoperability out of the deal.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Mar 2008 22:38:57 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Sent: Tuesday, March 04, 2008 12:36 PM
...
> the conversion, had more to do with support for SMIv2 reuse.

Sounds like a job for ISO 24707. 

...
> not to get some real interoperability out of the deal.

This is where other ways of looking at {subclassing / refinement / 
extension / subsetting} could be really helpful.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 5 Mar 2008 21:32:07 +0100

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andy Bierman
> Sent: Tuesday, March 04, 2008 10:36 PM
> To: Randy Presuhn
> Cc: NETCONF Goes On
> conversion easier, but in the case of YANG, a lot of hard 
> work by the programmers, and some DML extensions to better 
> support the conversion, had more to do with support for SMIv2 reuse.

You mean 'hard work' that was already done and included in the current
YANG proposal? 

> 
> You are correct that somebody could take any of the CANMOD 
> proposals and do the work to create tools for SMIv2 
> conversion.  It is just an implementation detail for the 
> purposes of our discussion.  For an operator, the existence 
> of real tools may mean a bit more than that.

It may mean a great difference if they are already using SMIv2 MIBs. 

Dan