[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIB2RDML] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted
Hi Mark,
- I think that sub-section 4.3.3.1.2 of the ref Juergen cites below
contains the operative rule: "if {primitive type definition} is
hexBinary or base64Binary, then the length of the value, as measured in
octets of the binary data, *must* be less than or equal to {value};"
... the {value} referred to there is the maxLength value.
- I agree with Juergen on the "OID fragment" request. It might be
handled somewhere else, but not in the base SMI datatypes XSD.
- For the next version (-04), I will update the wording in Sec. 5.1 to
account for all of Counter32/64, TimeTicks, and Gauge32. You are
correct in implying that the inclusion of Gauge32 is due mostly to
historic language in earlier versions of the SMI...Sec. 7.1.7 of
RFC2578 is clear but in actuality does not impose any behavioral
semantics of note.
Cheers,
BobN
-----Original Message-----
From: Juergen Schoenwaelder
[mailto:j.schoenwaelder at jacobs-university.de]
Sent: Monday, July 28, 2008 3:19 PM
To: ellison at ieee.org
Cc: Natale, Bob; mib2rdml at ietf.org; opsawg at ietf.org
Subject: Re: [MIB2RDML] Expressing SNMP SMI Datatypes in XML
SchemaDefinition Language -03 draft submitted
On Mon, Jul 28, 2008 at 03:09:35PM -0400, Mark Ellison wrote:
> - In section 5.2, "OctetString", second paragraph says "each octet is
> encoded as two hexadecimal digits" and the third bullet indicates the
> "maxLength" restriction of 65535 octets. However, the xs:simpleType
> "OctetString" definition in section 4 indicates an xs:maxLength
> value="65535". If the intent is to represent 65535 octets then the
> xs:maxLength value should be twice this number, "131070".
I think the maxLength restriction is counted in the number of decoded
bytes not the number of bytes needed for the encoding. Please check
section 4.3.3 of <http://www.w3.org/TR/xmlschema-2/>. (I did run into
this before; perhaps it is worth adding a comment so that we do not
run into this question again - or worse someone "fixes" this later
on.)
> - [more of a personal wish] In section 5.5, "ObjectIdentifier", I
> realize the text is written to be faithful to the definition of the
SMI
> OBJECT IDENTIFIER. In this regard, it is probably not appropriate to
> place support for "OID fragments" here. I find I use a lot of OID
> fragments (1 or more subids that do not have the initial 2 subid
> restrictions) to represent instance components for a set of related
> OBJECT-TYPE OIDs. Possibly there is a place, either in this memo, or
in
> another related memo to support the notion of an OID fragment? I
> suppose I could use the ObjectIdentifier "as is" by prepending any
> fragment with 1.1, but I regard this as a programmatic contortion
with
> undesirable overhead.
Your ObjectIdentifierFragment simply is not an ObjectIdentifier...
/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://www.ietf.org/mailman/listinfo/mib2rdml