Subject: [OPSAWG] SMI-to-XSD mapping work

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Jul 2007 11:18:44 -0500

Hi,

The XSDMI BOF proposed the creation of a WG to develop 1) the XSD
equivalents of datatypes and textual conventions from SMIv2, 2)
algorithms to translate MIB module specifications into XSD
equivalents, 3) Netconf operations to access MIB data, and 4) a draft
documenting security requirements for protocols accessing the MIB. The
BOF demonstrated community support for the first two objectives. The
third objective should be moved to a Netconf-specific WG. There was a
lack of support for the fourth objective.

People in the BOF volunteered to commit to being editors (3) and
reviewers (14) for the first two objectives. Starting documents and
implementations already exist. The work is expected to take less than
12 months.

Rather than starting a new WG for achieving the first two objectives,
I would like to propose this protocol-independent work be done in the
OPSAWG.

David Harrington
[email-masked]
[email-masked]

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 29 Jul 2007 10:37:30 +0200

On Fri, Jul 27, 2007 at 11:18:44AM -0500, David Harrington wrote:

> equivalents, 3) Netconf operations to access MIB data, and 4) a
> draft documenting security requirements for protocols accessing the
> MIB. The BOF demonstrated community support for the first two
> objectives. The third objective should be moved to a
> Netconf-specific WG. There was a lack of support for the fourth
> objective.

As long as NETCONF data modeling is completely undefined, developing
XSDs for data types and SMIv2 MIB module translations for use with
NETCONF will constrain any future NETCONF standards-track data
modeling work.

I don't want to discourage people from doing work on accessing SNMP
instrumentation via NETCONF; but I have a serious concern if the goal
is to produce standards-track specifications for 1) and 2) for the
reason mentioned above.

/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, 29 Jul 2007 11:10:14 +0200

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Sunday, July 29, 2007 11:38 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [OPSAWG] SMI-to-XSD mapping work
> 
> As long as NETCONF data modeling is completely undefined, 
> developing XSDs for data types and SMIv2 MIB module 
> translations for use with NETCONF will constrain any future 
> NETCONF standards-track data modeling work.
> 
> I don't want to discourage people from doing work on 
> accessing SNMP instrumentation via NETCONF; but I have a 
> serious concern if the goal is to produce standards-track 
> specifications for 1) and 2) for the reason mentioned above.
> 
> /js
> 
> -- 

Hi Juergen,

I am not sure that I follow. Why would be somebody constrained to
develop data models for NETCONF? 

As I understand David's proposal, he is not targeting NETCONF only.
Although NETCONF can be one possible protocol using the outputs of 1)
and 2) other protocols that need XSD-expressed data could benefit. On
the other hand there are clear limitations for NETCONF using only the
output of such work, so that development of other data models should be
pursued. 

If the target proposed status would be experimental rather than
standard-track would this ease your concerns? 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Jul 2007 07:38:31 +0200

On Sun, Jul 29, 2007 at 10:58:29AM -0400, David Harrington wrote:
 
> This proposed work is explicitly NOT particular to NETCONF. I have
> worked hard to ensure this is NOT a NETCONF-specific work item. This
> is a work item for the whole IETF, led by the OPS area.

This makes my concern even stronger. [Comments continue at the end.] 
 
> The proposed SMI-to-XSD translation is targeted at providing a
> protocol-independent XSD rendering of SMIv2 datatypes so any XML-based
> protocol, IETF-standard or otherwise, can transport existing
> management objects in XML and be able to use XSD to validate the data.
> 
> Most MIB data is focused on monitoring information, such as statistics
> and state. The MIB (with SNMP) has not been widely used for
> configuration, and many MIB modules do not contain objects for
> configuration or other protocol-specific specialized functionality.
> Any protocol that wants to look at statistics or state for
> technologies where a MIB module has already been developed for that
> purpose could benefit from utilizing the same managed objects as are
> used in the MIB module. NM protocols that have a different focus of
> applicability, such as NETCONF, will almost certainly require a
> different modeling language than SMI to entirely model their
> functionality, but might still benefit from reusing existing MIB
> objects for monitoring the configured technology or checking the state
> following configuration. They should not be required to use SNMP to
> carry the data in ASN.1  format, and an SMIv2 MIB module parser to
> validate the existing data if their protocol can already carry XML,
> and their application already supports XSD validation. We should
> provide a standard translation to make using the MIB's managed objects
> with XML/XSD easier.
> 
> If the developers of a protocol decide that there are insufficient
> benefits from reusing existing MIB data, they are not forced to do so.
> 
> Two goals of this work are instrumentation reuse and semantics reuse.
> The IETF has spent twenty years developing standard managed objects,
> and vendors have supplemented that with proprietary managed objects,
> all written using a standard language for expressing the syntax and
> semantics. We want to preserve that work and make it available for
> XML-based messaging.
> 
> Vendors have spent a great deal of money adding "hooks" into their
> instrumentation to support existing managed objects, such as counters.
> Operators have spent a great deal of time learning those managed
> objects, including which things a counter does and does not count. 
> 
> It would be a bad thing if NM data model designers designed new
> objects that differ slightly from existing standard managed objects,
> for no good reason,, thus requiring vendors to reimplement to support
> the slight differences, and operators to learn the new semantics if
> this is really unnecessary. If a new object would better serve the
> purpose, there is nothing that constrains designers from developing a
> new counter. 
> 
> If an existing managed object would work for multiple protocols, it
> would be a good thing if the XSD format used to represent the existing
> managed object is consistent across protocols, and properly represents
> the original design of the managed object. WG review can help to
> ensure that the translations are done properly.

I do not question any of the motivation. My concern, however, remains
that the existence of the translated XSD output will cause future data
modeling languages to be "consistent" with the XSD output coming out
of the translation. For me, a NETCONF data modeling language and SMIv2
translations should go hand in hand and not be separate efforts.

/js

---

From: "David Harrington" <[email-masked]>
Date: Sun, 29 Jul 2007 10:58:29 -0400

Hi,

dbh

> Sent: Sunday, July 29, 2007 4:38 AM
> To: David Harrington
> Cc: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Jul 2007 19:25:34 +0200

On Mon, Jul 30, 2007 at 01:14:11PM -0400, David Harrington wrote:
 
> To my knowledge there are three "teams" working on NETCONF data
> modeling - pure-XSD, and two unpublished specs (NCX and Yang). I have
> discussed the SMI-to-XSD work with leaders of each of these teams, and
> all agree that a common XSD for MIB access makes sense. I do not think
> they feel constrained by such an effort.
>
> You didn't attend the XSDMI BOF. The XSDMI BOF was filled primarily
> with people who are active in NETCONF, including the leaders of the
> three teams, and the consensus was 13 for doing this work, and zero
> against.

OK. Then count me as the one against.

> One reason I view the separation of this work to be acceptable is that
> the SMI-to-XSD effort is fairly simple translation work from one
> modeling langauge to another; it can be done by engineers with a
> reasonable amount of skill in SMI and XSD - a junior programmer could
> do most of the work in this effort, with technical reviews done by
> more experienced SMI and XSD engineers. We have three editors willing
> to document the translations, and thirteen willing reviewers,
> including the leaders of the three NETCONF teams.
> 
> The work being done in the NCX and Yang efforts is to develop a
> completely new modeling language; this (and the work with pure-XSD)
> requires the expertise of people with years of experience with SMI and
> XML, a profound understanding of the limitations of the SMI and the
> limitations of XML/XSD, and years of experience developing language
> tools. This requires senior programmer/architect skills.

I don't care which skills are required for which document. I am
concerned that we see a situation where we have both

(a)  SMIv2 -> XSD
(b)  SMIv2 -> "NETCONF DML" -> XSD

and thus there may be some notable confusion if the result is not the
same or we have in fact established a constraint on the "NETCONF DML"
and associated translations.

> I will point out that many of the current NETCONF leaders could not
> reach consensus on a new data modeling langauge in the failed SMING
> WG. I do not believe that all IETF protocols should be denied
> XML-based access to MIB data just because the NETCONF community cannot
> achieve consensus on a new data modeling language. 

Which protocols other than NETCONF do you have in mind?

> There is work that can be done now to allow access to MIB data by
> XML-based protocols, that will not constrain the "star" developers in
> their efforts, and will allow the whole IETF to better utilize the
> standard MIB objects have developed over the past twenty years.

Again, what is this "whole IETF" thing you are talking about other
than NETCONF?

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 30 Jul 2007 13:14:11 -0400

Hi Juergen,
 
> translations should go hand in hand and not be separate efforts.

I think the efforts should be coordinated, but can be different. 

This work should NOT be gated on NETCONF data modeling consensus.

David Harrington
[email-masked]
[email-masked]