From mib2rdml-bounces@ietf.org Mon Jul 14 16:16:17 2008 Return-Path: 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 EEF273A6A0F; Mon, 14 Jul 2008 16:16:17 -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 C4A833A68C7; Mon, 14 Jul 2008 16:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 s1ULj-aEUFdv; Mon, 14 Jul 2008 16:16:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 5832D3A6842; Mon, 14 Jul 2008 16:16:12 -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 m6ENGc3w007714; Mon, 14 Jul 2008 19:16:38 -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 m6ENGchZ007711; Mon, 14 Jul 2008 19:16:38 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 19:16:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 19:16:36 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expressing SNMP SMI Datatypes in XML Schema Definition Language -02 draft submitted Thread-Index: AchshrU9Eh9mtU+dQEyJvMbrsqa/2wK9u9bgG6JDzkA= References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> From: "Natale, Bob" To: X-OriginalArrivalTime: 14 Jul 2008 23:16:38.0016 (UTC) FILETIME=[AA868000:01C8E607] Cc: mib2rdml@ietf.org Subject: [MIB2RDML] Expressing SNMP SMI Datatypes in XML Schema Definition Language -02 draft submitted X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: converting MIB modules into resource models List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1612729591==" Sender: mib2rdml-bounces@ietf.org Errors-To: mib2rdml-bounces@ietf.org This is a multi-part message in MIME format. --===============1612729591== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E607.AA432694" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E607.AA432694 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have submitted an updated version of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via the Internet-Drafts submission tool ahead of today's deadline, but had to do it via a "manual entry" due to administrative complications (once again!), which imposes some delays in the formal announcement process. =20 Pending formal publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-opsawg-smi-datatypes -in-xsd-02.txt. If that presents any problems for you, please let me know and I will forward you a copy directly. =20 This draft includes changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups noted in the Change Log section. =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 Cheers, BobN =20 ------_=_NextPart_001_01C8E607.AA432694 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,=

 =

I have submitted an updated version of = "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via = the Internet-Drafts submission tool ahead of today’s deadline, but had = to do it via a "manual entry" due to administrative complications = (once again!), which imposes some delays in the formal announcement = process.

 

Pending formal publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-= opsawg-smi-datatypes-in-xsd-02.txt.  If that presents any problems for you, = please let me know and I will forward you a copy = directly.

 =

This draft includes changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and = David Harrington, and some other fix-ups noted in the Change Log = section.=

 =

I hope that this version may be ready for WG last = call.  I will not be in Dublin, however – but will try to participate = remotely if possible if this topic is discussed in the OPSAWG session = there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA = Considerations”).

 

Please let me know your observations, etc.=

 =

Cheers,=

BobN=

 

------_=_NextPart_001_01C8E607.AA432694-- --===============1612729591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www.ietf.org/mailman/listinfo/mib2rdml --===============1612729591==-- From mib2rdml-bounces@ietf.org Sun Jul 27 22:15:24 2008 Return-Path: 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 CE01E3A6A5B; Sun, 27 Jul 2008 22:15:24 -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 465523A6A5B; Sun, 27 Jul 2008 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hHqJRCpGDf3k; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 71F953A685C; Sun, 27 Jul 2008 22:15:12 -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 m6S5FKnY021333; Mon, 28 Jul 2008 01:15:20 -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 m6S5FKlc021327; Mon, 28 Jul 2008 01:15:20 -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 01:15:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 01:13:50 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted Thread-Index: AchshrU9Eh9mtU+dQEyJvMbrsqa/2wK9u9bgG6JDzkACmju30A== References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> From: "Natale, Bob" To: X-OriginalArrivalTime: 28 Jul 2008 05:15:20.0419 (UTC) FILETIME=[EE3F5330:01C8F070] Cc: mib2rdml@ietf.org Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771121299==" Sender: mib2rdml-bounces@ietf.org Errors-To: mib2rdml-bounces@ietf.org This is a multi-part message in MIME format. --===============1771121299== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F070.BAA7AC6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have submitted an updated version (-03) of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", via the Internet-Drafts submission tool, but it will likely not get processed until following IETF-72. =20 In the meantime, interested parties can download a copy from: http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-x sd-03.txt =20 The -03 version has some minor fix-ups (documented in the change log) and is being submitted now because the -02 version (which was posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) technical problem with the tool (apparently). =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 [I've included a couple of the NETCONF-related lists as bcc: addressees on this, since several recent threads on those lists have mentioned the XSDMI work. Further discussion about this draft, however, should be on the OPSAWG list.] =20 Cheers, BobN =20 From: Natale, Bob=20 Sent: Monday, July 14, 2008 7:17 PM To: opsawg@ietf.org Cc: mib2rdml@ietf.org Subject: Expressing SNMP SMI Datatypes in XML Schema Definition Language -02 draft submitted =20 Hi, =20 I have submitted an updated version of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via the Internet-Drafts submission tool ahead of today's deadline, but had to do it via a "manual entry" due to administrative complications (once again!), which imposes some delays in the formal announcement process. =20 Pending formal publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-opsawg-smi-datatypes -in-xsd-02.txt. If that presents any problems for you, please let me know and I will forward you a copy directly. =20 This draft includes changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups noted in the Change Log section. =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 Cheers, BobN =20 ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have submitted an updated version (-03) of = “Expressing SNMP SMI Datatypes in XML Schema Definition Language”, via the = Internet-Drafts submission tool, but it will likely not get processed until following = IETF-72.

 

In the meantime, interested parties can download a copy = from:

http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi= -datatypes-in-xsd-03.txt

 

The -03 version has some minor fix-ups (documented in the = change log) and is being submitted now because the -02 version (which was = posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) = technical problem with the tool (apparently).

 

I hope that this version may be ready for WG last = call.  I will not be in Dublin, however – but will try to participate = remotely if possible if this topic is discussed in the OPSAWG session = there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA = Considerations”).

 

Please let me know your observations, = etc.

 

[I’ve included a couple of the NETCONF-related lists = as bcc: addressees on this, since several recent threads on those lists = have mentioned the XSDMI work.  Further discussion about this draft, = however, should be on the OPSAWG list.]

 

Cheers,

BobN

 

From: Natale, Bob
Sent: Monday, July 14, 2008 7:17 PM
To: opsawg@ietf.org
Cc: mib2rdml@ietf.org
Subject: Expressing SNMP SMI Datatypes in XML Schema Definition = Language -02 draft submitted

 

Hi,=

 

I have submitted = an updated version of "Expressing SNMP SMI Datatypes in XML Schema = Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via = the Internet-Drafts submission tool ahead of today’s deadline, but had = to do it via a "manual entry" due to administrative complications = (once again!), which imposes some delays in the formal announcement = process.

 =

Pending formal = publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-= opsawg-smi-datatypes-in-xsd-02.txt.  If that presents any problems for you, = please let me know and I will forward you a copy = directly.

 

This draft includes = changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups = noted in the Change Log section.

 

I hope that this = version may be ready for WG last call.  I will not be in Dublin, however = – but will try to participate remotely if possible if this topic is discussed = in the OPSAWG session there.

 =

If anything is a = hang-up, I suspect it will be in the XML registration section (“IANA Considerations”).

 =

Please let me know your observations, etc.=

 

Cheers,=

BobN=

 =

------_=_NextPart_001_01C8F070.BAA7AC6E-- --===============1771121299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www.ietf.org/mailman/listinfo/mib2rdml --===============1771121299==-- From mib2rdml-bounces@ietf.org Mon Jul 28 12:08:03 2008 Return-Path: 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 EEBE428C16E; Mon, 28 Jul 2008 12:08:02 -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 70F2528C0F8 for ; Mon, 28 Jul 2008 12:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_29=0.6] 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 XMultXCKHRMG for ; Mon, 28 Jul 2008 12:06:53 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by core3.amsl.com (Postfix) with ESMTP id 7DEF83A6B08 for ; Mon, 28 Jul 2008 12:06:52 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr14.mgt.hosting.dc2.netsol.com [10.49.6.77]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m6SJ71wr011541 for ; Mon, 28 Jul 2008 15:07:01 -0400 Received: (qmail 27844 invoked by uid 78); 28 Jul 2008 19:07:00 -0000 Received: from unknown (HELO ?192.168.1.205?) (mark@ellisonsoftware.com@71.168.120.104) by ns-omr14.lb.hosting.dc2.netsol.com with SMTP; 28 Jul 2008 19:07:00 -0000 Message-ID: <488E196F.2080304@EllisonSoftware.com> Date: Mon, 28 Jul 2008 15:09:35 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. User-Agent: Thunderbird 2.0b2 (X11/20070116) MIME-Version: 1.0 To: "Natale, Bob" References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> 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 Reply-To: ellison@ieee.org List-Id: converting MIB modules into resource models List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0750253013==" Sender: mib2rdml-bounces@ietf.org Errors-To: mib2rdml-bounces@ietf.org This is a multi-part message in MIME format. --===============0750253013== Content-Type: multipart/alternative; boundary="------------050909060504030802010007" This is a multi-part message in MIME format. --------------050909060504030802010007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Bob, I have reviewed the -03 draft and have the following comments: - In section 5.1, "Numeric Datatypes", last paragraph: I think it reasonable to also include the Counter64 datatype as having "...special application semantics that must be considered..." since Counter32 and Counter64 can both wrap and suffer discontinuities. Possibly, TimeTicks should also be mentioned as having special application semantics (due to the 'epoch' concept). Is Gauge32 mentioned due to the 'latching' concept? - 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". - [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. Thanks for considering these two comments and one wish! Mark -- Mark Ellison Ellison Software Consulting, Inc. tel: +1 (603) 362-9270 38 Salem Road web: http://EllisonSoftware.com Atkinson, NH 03811, USA On 07/28/2008 01:13 AM, Natale, Bob wrote: > > Hi, > > > > I have submitted an updated version (-03) of "Expressing SNMP SMI > Datatypes in XML Schema Definition Language", via the Internet-Drafts > submission tool, but it will likely not get processed until following > IETF-72. > > > > In the meantime, interested parties can download a copy from: > > http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-xsd-03.txt > > > > > The -03 version has some minor fix-ups (documented in the change log) > and is being submitted now because the -02 version (which was posted > ahead of the IETF-72 cut-off time) got dropped as a result of an > (on-going) technical problem with the tool (apparently). > > > > I hope that this version may be ready for WG last call. I will not be > in Dublin, however -- but will try to participate remotely if possible > if this topic is discussed in the OPSAWG session there. > > > > If anything is a hang-up, I suspect it will be in the XML registration > section ("IANA Considerations"). > > > > Please let me know your observations, etc. > > > > [I've included a couple of the NETCONF-related lists as bcc: > addressees on this, since several recent threads on those lists have > mentioned the XSDMI work. Further discussion about this draft, > however, should be on the OPSAWG list.] > > > > Cheers, > > BobN > > > > *From:* Natale, Bob > *Sent:* Monday, July 14, 2008 7:17 PM > *To:* opsawg@ietf.org > *Cc:* mib2rdml@ietf.org > *Subject:* Expressing SNMP SMI Datatypes in XML Schema Definition > Language -02 draft submitted > > > > Hi, > > > > I have submitted an updated version of "Expressing SNMP SMI Datatypes > in XML Schema Definition > Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via the > Internet-Drafts submission tool ahead of today's deadline, but had to > do it via a "manual entry" due to administrative complications (once > again!), which imposes some delays in the formal announcement process. > > > > Pending formal publication, you can get a copy from the "staging" area > at: > http://www.ietf.org/proceedings/staging/draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt. > If that presents any problems for you, please let me know and I will > forward you a copy directly. > > > > This draft includes changes made for comments on the -01 > version received from Mark Ellison, Juergen Schoenwaelder, and David > Harrington, and some other fix-ups noted in the Change Log section. > > > > I hope that this version may be ready for WG last call. I will not be > in Dublin, however -- but will try to participate remotely if possible > if this topic is discussed in the OPSAWG session there. > > > > If anything is a hang-up, I suspect it will be in the XML registration > section ("IANA Considerations"). > > > > Please let me know your observations, etc. > > > > Cheers, > > BobN > > > > ------------------------------------------------------------------------ > > _______________________________________________ > MIB2RDML mailing list > MIB2RDML@ietf.org > https://www.ietf.org/mailman/listinfo/mib2rdml > --------------050909060504030802010007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Bob,

I have reviewed the -03 draft and have the following comments:
 
- In section 5.1, "Numeric Datatypes", last paragraph:  I think it reasonable to also include the Counter64 datatype as having "...special application semantics that must be considered..." since Counter32 and Counter64 can both wrap and suffer discontinuities.  Possibly, TimeTicks should also be mentioned as having special application semantics (due to the 'epoch' concept).  Is Gauge32 mentioned due to the 'latching' concept?

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

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

Thanks for considering these two comments and one wish!

Mark

-- 
Mark Ellison                        Ellison Software Consulting, Inc.
tel: +1 (603) 362-9270              38 Salem Road
web: http://EllisonSoftware.com     Atkinson, NH  03811, USA

On 07/28/2008 01:13 AM, Natale, Bob wrote:

Hi,

 

I have submitted an updated version (-03) of “Expressing SNMP SMI Datatypes in XML Schema Definition Language”, via the Internet-Drafts submission tool, but it will likely not get processed until following IETF-72.

 

In the meantime, interested parties can download a copy from:

http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-xsd-03.txt

 

The -03 version has some minor fix-ups (documented in the change log) and is being submitted now because the -02 version (which was posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) technical problem with the tool (apparently).

 

I hope that this version may be ready for WG last call.  I will not be in Dublin, however – but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA Considerations”).

 

Please let me know your observations, etc.

 

[I’ve included a couple of the NETCONF-related lists as bcc: addressees on this, since several recent threads on those lists have mentioned the XSDMI work.  Further discussion about this draft, however, should be on the OPSAWG list.]

 

Cheers,

BobN

 

From: Natale, Bob
Sent: Monday, July 14, 2008 7:17 PM
To: opsawg@ietf.org
Cc: mib2rdml@ietf.org
Subject: Expressing SNMP SMI Datatypes in XML Schema Definition Language -02 draft submitted

 

Hi,

 

I have submitted an updated version of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via the Internet-Drafts submission tool ahead of today’s deadline, but had to do it via a "manual entry" due to administrative complications (once again!), which imposes some delays in the formal announcement process.

 

Pending formal publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt.  If that presents any problems for you, please let me know and I will forward you a copy directly.

 

This draft includes changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups noted in the Change Log section.

 

I hope that this version may be ready for WG last call.  I will not be in Dublin, however – but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA Considerations”).

 

Please let me know your observations, etc.

 

Cheers,

BobN

 


_______________________________________________
MIB2RDML mailing list
MIB2RDML@ietf.org
https://www.ietf.org/mailman/listinfo/mib2rdml

--------------050909060504030802010007-- --===============0750253013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www.ietf.org/mailman/listinfo/mib2rdml --===============0750253013==-- From mib2rdml-bounces@ietf.org Mon Jul 28 12:18:37 2008 Return-Path: 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 67AB03A6AC0; Mon, 28 Jul 2008 12:18:37 -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 484623A6845; Mon, 28 Jul 2008 12:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_210=0.6, J_CHICKENPOX_29=0.6] 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 xC7eggnrtA7f; Mon, 28 Jul 2008 12:18:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BD9123A694E; Mon, 28 Jul 2008 12:18:34 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3349C002D; Mon, 28 Jul 2008 21:18:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 94VEebI9NYpJ; Mon, 28 Jul 2008 21:18:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B74CC0034; Mon, 28 Jul 2008 21:18:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 186D267942B; Mon, 28 Jul 2008 21:18:37 +0200 (CEST) Date: Mon, 28 Jul 2008 21:18:37 +0200 From: Juergen Schoenwaelder To: ellison@ieee.org Message-ID: <20080728191837.GA9535@elstar.local> Mail-Followup-To: ellison@ieee.org, "Natale, Bob" , mib2rdml@ietf.org, opsawg@ietf.org References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> <488E196F.2080304@EllisonSoftware.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <488E196F.2080304@EllisonSoftware.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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 Reply-To: j.schoenwaelder@jacobs-university.de List-Id: converting MIB modules into resource models List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mib2rdml-bounces@ietf.org Errors-To: mib2rdml-bounces@ietf.org 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 . (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 _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www.ietf.org/mailman/listinfo/mib2rdml From mib2rdml-bounces@ietf.org Mon Jul 28 13:25:09 2008 Return-Path: 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 . (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 _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www.ietf.org/mailman/listinfo/mib2rdml From mib2rdml-bounces@ietf.org Mon Jul 28 13:28:17 2008 Return-Path: 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 AA49C3A6B0C; Mon, 28 Jul 2008 13:28:17 -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 53B803A6B0A for ; Mon, 28 Jul 2008 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_29=0.6] 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 3u3h9kZ8db4L for ; Mon, 28 Jul 2008 13:28:15 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by core3.amsl.com (Postfix) with ESMTP id 4513E3A6B09 for ; Mon, 28 Jul 2008 13:28:15 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr11.mgt.hosting.dc2.netsol.com [10.49.6.74]) by omr11.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m6SKSI05022400 for ; Mon, 28 Jul 2008 16:28:25 -0400 Received: (qmail 28306 invoked by uid 78); 28 Jul 2008 20:28:17 -0000 Received: from unknown (HELO ?192.168.1.205?) (mark@ellisonsoftware.com@71.168.120.104) by ns-omr11.lb.hosting.dc2.netsol.com with SMTP; 28 Jul 2008 20:28:17 -0000 Message-ID: <488E2C7C.8010409@EllisonSoftware.com> Date: Mon, 28 Jul 2008 16:30:52 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. User-Agent: Thunderbird 2.0b2 (X11/20070116) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de 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> In-Reply-To: <20080728191837.GA9535@elstar.local> 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 Reply-To: ellison@ieee.org List-Id: converting MIB modules into resource models List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1180444973==" Sender: mib2rdml-bounces@ietf.org Errors-To: mib2rdml-bounces@ietf.org This is a multi-part message in MIME format. --===============1180444973== Content-Type: multipart/alternative; boundary="------------090304000706080304010601" This is a multi-part message in MIME format. --------------090304000706080304010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, Thanks for this reply. My comments/clarifications are inline, below. On 07/28/2008 03:18 PM, Juergen Schoenwaelder wrote: > 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 . (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.) > > Good- section 4.3.3 of is helpful, I see now how I became confused by the current text in the second paragraph. I agree with your suggestion to add some text/comment to clarify. >> - [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... > Yes I agree with this- hopefully there is a proper place for defining an ObjectIdentifierFragment... > /js > Thanks, Mark --------------090304000706080304010601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Juergen,

Thanks for this reply.  My comments/clarifications are inline, below.

On 07/28/2008 03:18 PM, Juergen Schoenwaelder wrote: 
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.)
Good- section  4.3.3 of <http://www.w3.org/TR/xmlschema-2/> is helpful, I see now how I became confused by the current text in the second paragraph.  I agree with your suggestion to add some text/comment to clarify.

  

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



Yes I agree with this- hopefully there is a proper place for defining
an ObjectIdentifierFragment...



  
/js
  



Thanks,



Mark






--------------090304000706080304010601--

--===============1180444973==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
MIB2RDML mailing list
MIB2RDML@ietf.org
https://www.ietf.org/mailman/listinfo/mib2rdml

--===============1180444973==--