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

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Nov 29, 2007 at 01:25:43AM -0500, Natale, Bob wrote:
 
> 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.

OK
 
> "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.

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

> 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".

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.

> 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".

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>


_______________________________________________
MIB2RDML mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mib2rdml