Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt

From: Mark Ellison <[email-masked]>
Date: Fri, 7 Oct 2011 10:44:34 -0400

Hi-

The initial (-00) draft for mapping SMIv2 Textual Conventions to XSD is now
posted and available for review.  This draft represents follow-on work to
RFC 5935.

Critical review and comments welcome!

Regards,

Mark

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Oct 7, 2011 at 10:33 AM
Subject: I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : Expressing SNMP SMI Textual Conventions in XML
Schema Definition Language
       Author(s)       : Mark Ellison
                         Bob Natale
       Filename        :
draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt
       Pages           : 84
       Date            : 2011-10-07

  This memo defines the IETF standard expression of Structure of
  Management Information (SMI) textual conventions in Extensible Markup
  Language (XML) Schema Definition (XSD) language.  The primary
  objective of this memo is to enable the production of XML documents
  that are as faithful to the SMI as possible, using XSD as the
  validation mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Oct 2011 17:01:36 +0200

> Critical review and comments welcome!

I like to know the difference (if any) between running 'smidump -f
yang' and converting the resulting yang to XSD using pyang and your
proposed mapping of TCs. Note that the translation done by smidump is
currently a working group item of the NETMOD working group.

http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01

/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: Mark Ellison <[email-masked]>
Date: Wed, 12 Oct 2011 10:22:50 -0400

inline...

> http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01

Juergen,

The draft-ellison-opsawg-smi-textual-conventions-xsd is simply the
anticipated follow-on to a previous OPSAWG work item- see RFC 5935.

The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as compared
to the SMIv2-->YANG-->XSD production is more faithful to and better reflects
the semantics and base data types of SMIv2 textual conventions.  I believe
you will see that the proposed mapping
in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more direct
and lends itself to a less complex tool set.

The mapping described in draft-ellison-opsawg-smi-textual-conventions-xsd
has no dependencies on YANG and the resulting XSD has no dependencies upon
YANG namespaces.  Rather, there is a dependency upon the namespace
established within RFC 5935.

In other words, when TCs are mapped from SMIv2 to XSD using the algorithms
described in draft-ellison-opsawg-smi-textual-conventions-xsd, the resulting
XSD is built upon the XSD simple types, as defined in RFC 5935, representing
the mapped SMIv2 base type.  Thus the relationship between TC refinement and
base type as established within the SMIv2 is maintained within the XSD.  I
believe this essential relationship is lost in the SMIv2-->YANG-->XSD
mapping currently produced by smidump and pyang.

My hope is that participants of the OPSAWG see the value of such an
algorithmic, direct mapping from SMIv2 to XSD for textual conventions, that
is faithful to the original SMIv2, that deterministically extends from the
mapped SMIv2 base types and, that has no dependencies on YANG intermediate
forms or YANG namespaces in the resulting XSD.

Kindly review and consider draft-ellison-opsawg-smi-textual-conventions-xsd
as a work item for the OPSAWG...

Regards,

Mark
--
Mark Ellison
http://EllisonSoftware.com/

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Oct 2011 16:41:38 +0200

> and lends itself to a less complex tool set.

My concern is that multiple mappings to XSD likely are more costly
than having a single one.

> established within RFC 5935.

Putting all TCs into a single namespace won't work if you have TCs in
different SMIv2 modules that happen to have the same name.
 
> mapping currently produced by smidump and pyang.

Not sure what is lost. Perhaps an example helps me to understand.

> forms or YANG namespaces in the resulting XSD.

I am concerned about having multiple mappings that lead not just to
different namespaces but also different XSD data types. I am also kind
of missing the description of the actual algorithm in the document (OK
its a first draft so probably too much to ask for). What I see are a
collection of examples and it is not always clear how the algorithm
would actually work (e.g. how does the pattern you have for
DateAndTime work faithfully with base="smi:OctetString")? It is not
really clear from the document whether you want to standardize an
algorithm or the outcome of executing an algorithm on a certain
collection of TCs (in that case a single namespace might work but
then extending the collection will be painful).

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Oct 2011 10:33:31 -0700

We went through the overlap discussion about a year ago I think.
Choice of tools is subjective.  I prefer to use YANG, not XSD,
so I can't say this draft is useful of not, because XSD itself
is not useful to me.

Since we have no official YANG to XSD mapping, there is no chance
that there can be conflicts between different XSDs (generated vs. static).
So there is no chance that any YANG definition could ever be affected
because it doesn't 'match the XSD version' in this draft.

As long as that is true (ADs?) then I have no strong objections to this draft.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, October 12, 2011 7:42 AM
To: Mark Ellison
Cc: [email-masked]
Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt

 

/js

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

---

From: Mark Ellison <[email-masked]>
Date: Mon, 17 Oct 2011 10:20:34 -0400

Hello Jeurgen...

> than having a single one.

I understand this concern.   However, the XSD mappings provided in RFC 5935
ought form the base of any mappings from SMIv2 to XSD, not a YANG data type.
 The purpose of RFC 5935 is to provide a mapping from SMIv2 base data types
into XSD.  The ID under discussion extends the mapping of TCs (which rely
upon refinements of SMIv2 base data types) directly to XSD.  The resulting
XSD is based upon, and refines the set of XSD definintions of the SMIv2 base
data types found in RFC 5935.  No YANG stuff here!

> different SMIv2 modules that happen to have the same name.
I agree with your statement.  Putting all TCs mapped into XSD into a single
XML namespace is not the intention of the draft under discussion.  I have
made a note to add text to the next revision to clarify and relieve this
concern.

>From my perspective, what is lost is the use of the base data type XSD
definitions contained in RFC 5935.  There is also a reliance upon YANG
namespace definitions, which adds complexity that is not necessary.

> then extending the collection will be painful).

We already have a mapping for the base data types.  It is the belief of the
authors of the draft under discussion that TCs should be based upon these
base data types.  The SMIv2-->YANG-->XSD does not use the definitions found
in RFC 5935...maybe it should?

re- the DateAndTime...its still a work-in-progress.  I have made a note on
this issue.

Mark
-- 
Mark Ellison
Ellison Software Consulting, Inc.
http://EllisonSoftware.com/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 24 Oct 2011 13:18:33 +0200

Hi,

Sorry for the late intervention, I was on vacation for the last 12 days.
In answer to Andy's AD-directed question, I think that this is true and
that this document is a 'natural' extension of RFC 5935 and in line with
the plans we had in mind when we started the work on XML-based
configuration in the area. I do not think it will harm or impact in
anyway the usage of YANG or definition of YANG modules. The question is
to what extent it will be used, but then this is a more general question
about the usage and usefulness of XSD for this purpose. 

Dan

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andy Bierman
> Sent: Wednesday, October 12, 2011 7:34 PM
> To: Juergen Schoenwaelder; Mark Ellison
> Cc: [email-masked]
> As long as that is true (ADs?) then I have no strong objections to
this
> draft.
> > has no dependencies on YANG and the resulting XSD has no
dependencies
> upon