Subject: [OPS-AREA] SNMP MIB to XSD mapping I-D available

From: "Natale, Bob" <[email-masked]>
Date: Wed, 28 Nov 2007 01:48:33 -0500

Hi,
 
For those of you on the MIB2RMDL list who have been wondering what (if
anything!) has been going on during this long period of silence on the
e-mail list, and for others interested in having an IETF standard
methodology for mapping SNMP MIBs to XML via XSD for generic use by
XML-based management applications, I can now report some progress.
 
That progress is best represented by a new Internet Draft which is now
available at
http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd
-00.txt, pending posting to the IETF I-D repository following the
imminent Vancouver IETF meeting.
 
Dave Harrington has led this effort, starting with the XSDMI proposal
at the Chicago IETF meeting.  As I published on this list around that
time, it makes sense for the MIB2RMDL effort to see XSDMI as the
essential first half of the equation (i.e., the "MIB2->" part) of
MIB2RMDL.  Once the IETF publishes a standard methodology for the
expression of management information described in and accessible via
SNMP Management Information Bases (MIBs) as XML documents, then other
groups (if desired) can undertake the second half (i.e., the "->2RMDL"
part).  (Note that this approach also allows for multiple resource
model mappings from the standard MIB to XSD mapping.)  Yan Li did much
of the concrete research of multiple existing independent approaches
for doing the fundamental datatypes mapping addressed in this draft.
We then did a comparative analysis of those approaches, relative to the
requirements stipulated in Sec. 3 of this draft, as a baseline for the
specific approach this draft proposes.  This draft originated from
draft-romascanu-netconf-datatypes, but now bears little resemblance to
that document, due to differences in scope, structure, and content.
 
Any errors or otherwise errant statements in the draft are purely my
responsibility.
 
I believe that the OPS ADs plan to allocate some agenda time to discuss
this work at the Vancouver IETF.  I will post that scheduling info when
it becomes available, and I will do a post-Vancouver recap message as
soon after IETF-70 as possible.
 
In the meantime, please feel free to raise any issues or post any
comments concerning the draft or the plans here and on the ops-area
list (unless the ADs give other guidance about which list(s) to use).
 
Cheers,
BobN
_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: "GOGWIM, JOEL GODWIN" <[email-masked]>
Date: Wed, 28 Nov 2007 08:57:12 +0100 (WAT)

I tried getting the site given but it responded page does not exist.
That is:
http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2007 09:27:30 +0100

> list (unless the ADs give other guidance about which list(s) to use).

It might be helpful to clarify what is meant with the following
stated requirements:

  R3.  The XSD datatype specified for a given SMI datatype MUST include
       and restrictions on values associated with the SMI datatype.

  R4.  The XSD datatype specified for a given SMI datatype MUST be the
       most direct XSD datatype, with the most parsimonious
       restrictions, which matches the foregoing requirements.

You seem to want SMI <=> XSD equivalence (I assume this because you
carry the 128 subidentifier OID restriction forward) while in other
places people are fine with just SMI => XSD mapping. Note that it is a
very fundamental design decision to require equivalence and will be of
much more importance once you move to TCs and you look at the stuff
that is more challenging.

/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: Wed, 28 Nov 2007 14:16:14 +0100

________________________________

	From: Natale, Bob [mailto:[email-masked]] 

	I believe that the OPS ADs plan to allocate some agenda time to
discuss this work at the Vancouver IETF.  I will post that scheduling
info when it becomes available, and I will do a post-Vancouver recap
message as soon after IETF-70 as possible.

	[DR] It's on the agenda of the OPS Area Open Meeting available
at http://www3.ietf.org/proceedings/07dec/agenda/opsarea.txt. 
	 
	Dan

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 29 Nov 2007 01:25:43 -0500

Hi Juergen,

Thanks for the feedback.

Concerning the clarifications you requested: 

"R3.  The XSD datatype specified for a given SMI datatype MUST include
       and restrictions on values associated with the SMI datatype."
       ^^^

Stupid typo on my part...should be: "...MUST include any restrictions
on 
values associated with the SMI datatype."            ^^^

This simply means that any restrictions on a datatype specified in the
SMI
(such as the maximum length of 65535 octets for an OCTET STRING) must
be
reflected in the XSD datatype definition.

"R4.  The XSD datatype specified for a given SMI datatype MUST be the
       most direct XSD datatype, with the most parsimonious
       restrictions, which matches the foregoing requirements."

This is just the corollary of R3: The XSD datatype definition must not
add any unnecessary "decoration" relative to the SMI datatype
definition.

You are correct in noting that this specification aims for "fidelity"
of the XSD to the SMI for the core datatypes defined in RFC 2578 (and
RFC 1155) -- or, put another way, "equivalence where possible; variance
only where necessary".

I do understand the implications and appreciate your cautions about
impact on TC mappings -- there the guidance might become, "equivalence
where possible; variance where helpful".

The goal of "fidelity" is important in this effort because it targets
*reuse* by generic XML-based management applications of existing
(including future) MIBs both as precise data models and as
instrumentation
artifacts via gateways to SNMP agents.

Cheers,
BobN

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Wednesday, November 28, 2007 3:28 AM
To: Natale, Bob
Cc: [email-masked]; [email-masked]
Subject: Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2007 11:44:57 +0100

On Thu, Nov 29, 2007 at 01:25:43AM -0500, Natale, Bob wrote:
 
> This simply means that any restrictions on a datatype specified in
> the SMI (such as the maximum length of 65535 octets for an OCTET
> STRING) must be reflected in the XSD datatype definition.

OK
 
> add any unnecessary "decoration" relative to the SMI datatype

This sounds fuzzy to me; people likely have totally different
understandings of 'unnecessary "decoration"'.

> RFC 1155) -- or, put another way, "equivalence where possible; variance

Let me ask why you actually have Counter and Couter32 (and similarly
Gauge and Gauge32). Since SMI versions prior to SMIv2 [RFC2578] can be
translated to SMIv2 (STD58 since 1999), why does this document care
about SMIv1 and things such as RFC 1155 at all? Note that libsmi does
not distinguish between Counter and Couter32 or Gauge and Gauge32 and
this has never been a problem as far as I can tell.

> where possible; variance where helpful".

So you are saying lossless SMI => XSD translation is required while
lossless XSD => SMI translation is nice to have but not required.

> The goal of "fidelity" is important in this effort because it
> targets *reuse* by generic XML-based management applications of
> existing (including future) MIBs both as precise data models and as
> instrumentation artifacts via gateways to SNMP agents.

You either require strict XSD => SMI or not. Gateways or translations
that work sometimes or only for some subsets are IMHO not a solution.

I just want to understand whether you guys envision to live with the
SMIv2 limitations forever or whether you have a plan to overcome some
of them and to gradually move forward. This is not clear to me.

/js