Subject: [OPSAWG] XSDMI

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Oct 2007 22:10:02 +0800

Hi,

Juergen has raised the issue that the XSD produced by the XDMI effort
and the XSD produced by the YANG effort might be different, and having
two different XSD equivalents for MIB datatypes would be suboptimal. I
agree.

However, I have the concern that while vendors wait for YANG to be
completed, they will need to develop proprietary data models for use
with netconf. Some vendors will want to reuse datatypes found in the
15 year compilation of IETF NM experience found in the standard MIB
modules, and supported by existing implementation code. If they need
to develop their own translations of existing SMI datatypes and
textual conventions into XSD and XML, we could wind up with a variety
of competing XSD specifications. 

The XSDMI work would provide reusable XSD equivalents of SMI datatypes
and textual conventions. If vendors use these consistent XSD
translations, then later work to derive standards from the proprietary
information/data models would be easier because there would be
increased commonality in the datatypes and textual conventions and
semantics used to model the information.

In addition to proprietary data models, there are multiple IETF
efforts to translate existing information models (often from
ASN.1-based formats) into XML formats.
draft-frascone-xml-dictionary-00 describes the Diameter "dictionary"
in XML format; draft-legg-xed-roadmap-06.txt describes translating
LDAP and X.509 directory information models into semantically
equivalent XML renditions of existing directory protocols; IPPM is
working on an information model in XML for traceroute measurements. So
a MIB-related translation to XML is not unique.

The XSDMI effort is about taking the MIB, which operators have
complained is not well suited to configuration, and translating
aspects of the MIB into equivalent XSD. The fact that the MIB
datatypes can be translated into XSD will not make the MIB more
suitable for configuration; it will simply make reusable dataypes
available in an XML-compatible format.

The netconf community should be focused on defining a data modeling
language and data models for configuration. The YANG approach for
netconf focuses not only on configuration, but also on developing an
information modeling language which can then be used by tools to
generate syntax-specific data models for a variety of purposes, such
as Netconf-suitable XSD data models, SNMP-suitable MIB modules, plus
data models for other modeling systems. I have a concern that the SNMP
community has not been asking for this approach, and the IETF failed
to reach consensus on the need for the information-modeling approach
when it was presented to the SMING WG. If the
information-model-generates-data-models approach is adopted by the
IETF, then does that mean that efforts to use XML-based data models
for ipfix, Diameter, IPPM, and LDAP should not be permitted until YANG
can determine how to generate those data models as well?

Just to be clear, I support the YANG effort because I believe it could
lead to better consistency of data modeling across protocols, but it
has yet to be proven to be viable, and other efforts to converge or
harmonize data models have had mixed success at best. We should not
put all our eggs into one basket. If the YANG approach proves to be
viable, then the XSDMI translations can be modified as needed to work
with YANG in the future. But XSDMI could give us XSD datatypes to
develop data models, possibly years before consensus on YANG will be
achieved.

I believe the XSDMI effort should be an OPS-area effort (indeed an
IETF-wide effort), focused in the OPSAWG, to allow the representation
and translation into XML idiom of the existing datatypes, textual
conventions, and semantic models defined in 15 years of work by
multiple working groups and multiple areas of the IETF. 

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

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