Subject: [netmod] SMIv2->XSD

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jul 2008 14:25:25 -0400

Hi,

I have copied this to the netmod and opsawg WG mailing lists, since
that is where datatype libraries should be discussed.

You only see two immediate uses for SMIv2 datatypes in XSD because you
only work on netconf standards.

How about datatypes for my SNMP NMS that has an XML/XSD-capable
database? Why do I have to wait for the Netmod WG to finish designing
a language **specifically for use with netconf** before I can have a
standard XSD to work with my SMIv2 datatypes in an SNMP-focused
application?

How about the <name a company> implementing netconf that needs/wants
to define XML-based datamodels to use with netconf, as suggested by
RFC4741, and the company wants to leverage all the SMIv2 MIB support
it already has available in its products and wants a standardized
translation of SMIv2 datatypes NOW, not in 3-5 more years.

Real world: the IETF network management world does not revolve around
YANG. For 20 years, it has revolved around SMI datatypes, not YANG
datatypes.

XSDMI is an OPSAWG work item. 
We have already had this discussion mutliple times, and reached
consensus to do XSDMI independent of YANG, but with an effort to
coordinate with YANG.
XSDMI is just about ready for WGLC.
Netmod WG is finally going to have its first WG meeting. 
Netmod WG will not realistically finish anytime soon.
And the IESG might eventually decide to not approve netmod's YANG
language as a standard. 
So why does the whole SNMP community need to wait for
SMIv2->YANG->XSD?

If the available tools generate SMIv2->XSD translations that are
valid, 
and the tools generate SMIv2->YANG->XSD translations that are valid
but different, 
then either the YANG translation rules got it wrong
or the YANG tools are trying to solve a different problam than the
SMIv2->XSD translation.
If I want a direct translation from SMIv2->XSD, why do I have to use
YANG tools to do this?

Juergen's suggested approaches include b) which is "coordinated" and
c) which is "painful". I think this is a false characterization. b) is
"painful" to those who have to wait possibly much longer for standard
datatypes, especially for non-netconf applications, and c) and d)
still have "coordination" so that the result is consistent. 

XSDMI has already slowed down its work by months to deliberately
coordinate its work with the YANG datatypes work, so the two are very
close already. Why don't we eliminate YANG-LIB and DSDL datatype work
from netmod, and standardize SMIv2 "faithful" datatypes (i.e., with no
netconf-specific "improvements") in XSDMI/OPSAWG (possibly using
translation rules rather than hand translations) and then netmod
(YANG, XML-on-the-wire, and the DSDL mapping) can use the OPSAWG
standard datatype library? That way, a standard datatypes library
could be available much sooner for applicability to netconf,
non-netconf, netmod and non-netmod uses rather than making everybody
wait for netmod.

If you are convinced that netmod will add some specific requirements
that we don't even know about yet, then let's not make XSDMI and the
SNMP community and the non-YANG Netconf community wait for netmod to
decide what those are since they are obviously not requirements of
SMIv2, and XSDMI is all about SMIv2, not netmod.

dbh

> -----Original Message-----
> From: Balazs Lengyel [mailto:[email-masked]] 
> Sent: Thursday, July 24, 2008 8:40 AM
> To: Romascanu, Dan (Dan); David Harrington; Natale, Bob; 
> Sharon Chisholm; [email-masked]
> Subject: Re: [Netconf] Review of
draft-ietf-netconf-monitoring-02.txt
> 
> Hello,
> I see two immediate users of the datatypes: XSD in new drafts 
> e.g. Netconf Monitoring, and the 
> DSDL mapping. They can either:
> - Assume solution b) coordinated, consistent datatypes
> - Start working on draft-wonderful-xsd-datatypes-for-netconf
> The latter will need extra work, time and authors.
> balazs
> 
> Juergen Schoenwaelder wrote:
> > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan 
> (Dan) wrote:
> > 
> >> So, in your opinion, the specification of the translation 
> rules should
> >> be the sole (principal?) scope of standardization in this 
> area? Or is
> >> there a need to optimize the output to get that 'better 
> quality' level
> >> for some of the commonly used structures?
> > 
> > There are two work items we have to distinguish:
> > 
> > a] The first work item is reuse of existing SMIv2 definitions in
XML
> >    based protocols and for this we need translation rules. 
> Whether the
> >    rules contain very specific rules to deal with some specific
but
> >    frequently occuring constructs is subject to the group 
> defining the
> >    rules. At the end, however, everything has to be automatic
since
> >    nobody is going to hand translate stuff that is out there.
> > 
> > b] The second work item are data types for new definitions. In
some
> >    cases, translation rules will not produce reasonable results (a
> >    good example is the InetAddress family of TCs that try to work
> >    around the lack of proper unions in the SMIv2). While any new
> >    definitions should align to existing definitions as much as
> >    possible, there will be cases where this requires discussion.
For
> >    me, the BridgeID is a good example of this kind of discussion
and
> >    there is in my view no way to avoid these discussions for cases
> >    where the binary representation implied by the SMIv2 
> does not match
> >    the more textual XSD approach or where the SMIv2 
> representation is
> >    specific to SNMP and SMIv2 limitations which do not 
> exist in other
> >    XML based protocols such as NETCONF.
> > 
> > My understanding was that XSDMI is addressing a] while NETMOD will
> > work on b] to produce reusable constructs for new configuration
data
> > models.
> > 
> > Excursion to the real world: I am familiar with a particular
> > implementation that has translation rules to directly translate
> > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF
> > efforts to specify how to translate YANG->XSD. So given 
> FOO-MIB, I can
> > do already today:
> > 
> > 1)	FOO-MIB -> FOO-MIB.xsd
> > 2)	FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd
> > 
> > And the result is not the same. Assuming that NETCONF will 
> be used to
> > provide access to SMIv2 instrumentation, I believe we are 
> in trouble.
> > 
> > Back from the real world to the IETF: There is a work item in the
> > OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG
> > (the YANG->XSD mapping). So from your perspective, you can say
there
> > is no problem as of now. ;-)
> > 
> > In practice, there is already running code for all of this and if
we
> > do not find a way to make the translation rules consistent in time
> > (whatever that means in the IETF ;-), I believe we will see that
> > people use differnet translation rules and we are going to pay the
> > bill later on.
> > 
> > There are different solutions possible to deal with this issue.
Some
> > solutions I quickly can come up with (but this is not meant to be
a
> > complete list):
> > 
> > a) Translation of SMIv2 to YANG is simply forbitten, only the
direct
> >    translation to XSD is allowed.
> > 
> > b) Both translations are developed at the same time and we 
> ensure that
> >    things are coordinated and that at the end that the 
> outcome of the
> >    two translation paths is consistent.
> > 
> > c) Both translation roads are engineered in parallel and 
> who completes
> >    first wins and the other one has to adapt to the winner, 
> regardless
> >    how painful this will be.
> > 
> > d) Settle on a single translation approach but make sure 
> that everyone
> >    interested in the other approach is made aware to follow 
> it closely
> >    to ensure that problems are avoided (this is essentially 
> b) without
> >    managed coordination).
> > 
> > e) Declare that this problem is not worth solving since XML 
> namespaces
> >    will take care of the differences and application 
> writers can deal
> >    with it.
> > 
> > f) Postpone the problem.
> > 
> > All I am suggesting is to discuss this issue openly and fairly on
> > technical grounds with the goal to avoid incompatible XSD 
> translations
> > of SMIv2 modules.
> > 
> > /js
> > 
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> TSP System Manager
> ECN: 831 7320                        Fax: +36 1 4377792
> Tel: +36-1-437-7320     email: [email-masked]
> 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Jul 2008 22:38:17 +0200 (CEST)

> translation of SMIv2 datatypes NOW, not in 3-5 more years.

Several companies already do this, in proprietary ways.  But the
datatype translation is just one part (maybe the easy one).  Other
things to consider for a standard SMIv2->XML mapping are: what does
the XML structure look like?  What is the top-level element for a
given MIB?  Which namespace URI is used?  How are INDEXes encoded?
How are INDEXes in foreign tables encoded?  How is RowStatus handled?
How is StorageType handled?

I think it has been said before, but I would rather see a mapping of
SMIv2 (types and structure) to XML, than XSD.  If there was a mapping
to XML, tools could generate compliant XSD, RNG, or YANG.

/martin