Re: [MIB2RDML] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted

"Natale, Bob" <RNATALE@mitre.org> Mon, 28 July 2008 20:25 UTC

Return-Path: <mib2rdml-bounces@ietf.org>
X-Original-To: mib2rdml-archive@optimus.ietf.org
Delivered-To: ietfarch-mib2rdml-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB103A68F0; Mon, 28 Jul 2008 13:25:09 -0700 (PDT)
X-Original-To: mib2rdml@core3.amsl.com
Delivered-To: mib2rdml@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC203A68AC; Mon, 28 Jul 2008 13:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level:
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70faZUNXD3Ai; Mon, 28 Jul 2008 13:25:02 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 57EC23A6B02; Mon, 28 Jul 2008 13:25:02 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6SKPCvm006467; Mon, 28 Jul 2008 16:25:12 -0400
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6SKPBBU006450; Mon, 28 Jul 2008 16:25:11 -0400
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 16:25:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 28 Jul 2008 16:24:17 -0400
Message-ID: <4915F014FDD99049A9C3A8C1B832004F02E472B1@IMCSRV2.MITRE.ORG>
In-Reply-To: <20080728191837.GA9535@elstar.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MIB2RDML] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted
Thread-Index: Acjw5sLcqpv29o6PTDKjPklUh/+y0AABucwQ
References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> <488E196F.2080304@EllisonSoftware.com> <20080728191837.GA9535@elstar.local>
From: "Natale, Bob" <RNATALE@mitre.org>
To: ellison@ieee.org
X-OriginalArrivalTime: 28 Jul 2008 20:25:11.0492 (UTC) FILETIME=[09100040:01C8F0F0]
Cc: mib2rdml@ietf.org, opsawg@ietf.org
Subject: Re: [MIB2RDML] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted
X-BeenThere: mib2rdml@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: converting MIB modules into resource models <mib2rdml.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mib2rdml>, <mailto:mib2rdml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mib2rdml>
List-Post: <mailto:mib2rdml@ietf.org>
List-Help: <mailto:mib2rdml-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib2rdml>, <mailto:mib2rdml-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mib2rdml-bounces@ietf.org
Errors-To: mib2rdml-bounces@ietf.org

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@jacobs-university.de] 
Sent: Monday, July 28, 2008 3:19 PM
To: ellison@ieee.org
Cc: Natale, Bob; mib2rdml@ietf.org; opsawg@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@ietf.org
https://www.ietf.org/mailman/listinfo/mib2rdml