RE: [MIB2RDML] SNMP MIB to XSD mapping I-D available

["Natale, Bob" <RNATALE at mitre.org>]

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:j.schoenwaelder at jacobs-university.de] 
Sent: Wednesday, November 28, 2007 3:28 AM
To: Natale, Bob
Cc: mib2rdml at ietf.org; ops-area at ietf.org
Subject: Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available

On Wed, Nov 28, 2007 at 01:48:33AM -0500, Natale, Bob wrote:
  
> 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).

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/>


_______________________________________________
MIB2RDML mailing list
MIB2RDML at ietf.org
https://www1.ietf.org/mailman/listinfo/mib2rdml