From mib2rdml-bounces@ietf.org Wed Nov 28 01:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGio-0002jY-0J; Wed, 28 Nov 2007 01:48:34 -0500 Received: from mib2rdml by megatron.ietf.org with local (Exim 4.43) id 1IxGim-0002hQ-6o for mib2rdml-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 01:48:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGil-0002hG-Py; Wed, 28 Nov 2007 01:48:31 -0500 Received: from smtp-bedford.mitre.org ([192.160.51.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxGil-0000WT-21; Wed, 28 Nov 2007 01:48:31 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id lAS6mU5e024183; Wed, 28 Nov 2007 01:48:30 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id AC115BF90; Wed, 28 Nov 2007 01:48:30 -0500 (EST) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id lAS6mTQ2024168; Wed, 28 Nov 2007 01:48:29 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 01:48:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 01:48:33 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNMP MIB to XSD mapping I-D available Thread-Index: AcgxirHW5FIU2mR9TiKWOw3/nJQ+Iw== From: "Natale, Bob" To: X-OriginalArrivalTime: 28 Nov 2007 06:48:29.0386 (UTC) FILETIME=[AF26C2A0:01C8318A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ops-area@ietf.org Subject: [MIB2RDML] SNMP MIB to XSD mapping I-D available X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.5 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="===============1084364664==" Errors-To: mib2rdml-bounces@ietf.org This is a multi-part message in MIME format. --===============1084364664== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8318A.AEA4FD5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8318A.AEA4FD5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 For those of you on the MIB2RMDL list who have been wondering what (if anything!) has been going on during this long period of silence on the e-mail list, and for others interested in having an IETF standard methodology for mapping SNMP MIBs to XML via XSD for generic use by XML-based management applications, I can now report some progress. =20 That progress is best represented by a new Internet Draft which is now available at http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd -00.txt, pending posting to the IETF I-D repository following the imminent Vancouver IETF meeting. =20 Dave Harrington has led this effort, starting with the XSDMI proposal at the Chicago IETF meeting. As I published on this list around that time, it makes sense for the MIB2RMDL effort to see XSDMI as the essential first half of the equation (i.e., the "MIB2->" part) of MIB2RMDL. Once the IETF publishes a standard methodology for the expression of management information described in and accessible via SNMP Management Information Bases (MIBs) as XML documents, then other groups (if desired) can undertake the second half (i.e., the "->2RMDL" part). (Note that this approach also allows for multiple resource model mappings from the standard MIB to XSD mapping.) Yan Li did much of the concrete research of multiple existing independent approaches for doing the fundamental datatypes mapping addressed in this draft. We then did a comparative analysis of those approaches, relative to the requirements stipulated in Sec. 3 of this draft, as a baseline for the specific approach this draft proposes. This draft originated from draft-romascanu-netconf-datatypes, but now bears little resemblance to that document, due to differences in scope, structure, and content. =20 Any errors or otherwise errant statements in the draft are purely my responsibility. =20 I believe that the OPS ADs plan to allocate some agenda time to discuss this work at the Vancouver IETF. I will post that scheduling info when it becomes available, and I will do a post-Vancouver recap message as soon after IETF-70 as possible. =20 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). =20 Cheers, BobN ------_=_NextPart_001_01C8318A.AEA4FD5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
For=20 those of you on the MIB2RMDL list who have been wondering what (if = anything!)=20 has been going on during this long period of silence on the e-mail list, = and for=20 others interested in having an IETF standard methodology for mapping = SNMP MIBs=20 to XML via XSD for generic use by XML-based management applications, I = can now=20 report some progress.
 
That=20 progress is best represented by a new Internet Draft which is now = available=20 at http://home.comcast.net/~bobnatale/draft-li-natale-smi-dat= atypes-in-xsd-00.txt,=20 pending posting to the IETF I-D repository following the imminent = Vancouver IETF=20 meeting.
 
Dave=20 Harrington has led this effort, starting with the XSDMI proposal at the = Chicago=20 IETF meeting.  As I published on this list around that time, it = makes sense=20 for the MIB2RMDL effort to see XSDMI as the essential first half of the = equation=20 (i.e., the "MIB2->" part) of MIB2RMDL.  Once the IETF publishes = a=20 standard methodology for the expression of management information = described in=20 and accessible via SNMP Management Information Bases (MIBs) as XML = documents,=20 then other groups (if desired) can undertake the second half (i.e., the=20 "->2RMDL" part).  (Note that this approach also allows for = multiple=20 resource model mappings from the standard MIB to XSD mapping.)  Yan = Li did=20 much of the concrete research of multiple existing independent = approaches for=20 doing the fundamental datatypes mapping addressed in this = draft.  We=20 then did a comparative analysis of those approaches, relative to the=20 requirements stipulated in Sec. 3 of this draft, as a baseline for the = specific=20 approach this draft proposes.  This draft originated from=20 draft-romascanu-netconf-datatypes, but now bears little resemblance to = that=20 document, due to differences in scope, structure, and=20 content.
 
Any=20 errors or otherwise errant statements in the draft are purely my=20 responsibility.
 
I=20 believe that the OPS ADs plan to allocate some agenda time to discuss = this work=20 at the Vancouver IETF.  I will post that scheduling info when it = becomes=20 available, and I will do a post-Vancouver recap message as soon after = IETF-70 as=20 possible.
 
In=20 the meantime, please feel free to raise any issues or post any comments=20 concerning the draft or the plans here and on the ops-area list (unless = the ADs=20 give other guidance about which list(s) to use).
 
Cheers,
BobN
------_=_NextPart_001_01C8318A.AEA4FD5A-- --===============1084364664== 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://www1.ietf.org/mailman/listinfo/mib2rdml --===============1084364664==-- From mib2rdml-bounces@ietf.org Wed Nov 28 03:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIGv-0000lT-3x; Wed, 28 Nov 2007 03:27:53 -0500 Received: from mib2rdml by megatron.ietf.org with local (Exim 4.43) id 1IxIGu-0000lD-4C for mib2rdml-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 03:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIGg-0000I2-Nj; Wed, 28 Nov 2007 03:27:38 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxIGe-0006Nq-Qt; Wed, 28 Nov 2007 03:27:38 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C925784AE5; Wed, 28 Nov 2007 09:27:35 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29714-03; Wed, 28 Nov 2007 09:27:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C47408A105; Wed, 28 Nov 2007 09:27:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6DBE43F7BB9; Wed, 28 Nov 2007 09:27:30 +0100 (CET) Date: Wed, 28 Nov 2007 09:27:30 +0100 From: Juergen Schoenwaelder To: "Natale, Bob" Subject: Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available Message-ID: <20071128082730.GA28685@elstar.local> References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mib2rdml@ietf.org, ops-area@ietf.org X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: mib2rdml-bounces@ietf.org 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 _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www1.ietf.org/mailman/listinfo/mib2rdml From mib2rdml-bounces@ietf.org Wed Nov 28 08:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMZK-0003mn-Pl; Wed, 28 Nov 2007 08:03:10 -0500 Received: from mib2rdml by megatron.ietf.org with local (Exim 4.43) id 1IxHNB-0006w0-C4 for mib2rdml-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 02:30:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHNA-0006vN-As; Wed, 28 Nov 2007 02:30:16 -0500 Received: from mail.unijos.edu.ng ([82.206.136.75] helo=smtp.unijos.edu.ng) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxHN7-0006mV-3F; Wed, 28 Nov 2007 02:30:14 -0500 Received: from localhost (smtp.unijos.edu.ng [127.0.0.1]) by smtp.unijos.edu.ng (Postfix) with ESMTP id AA0786813F; Wed, 28 Nov 2007 08:30:03 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng X-Spam-Score: -3.705 X-Spam-Level: X-Spam-Status: No, score=-3.705 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.694, BAYES_00=-2.599] Received: from smtp.unijos.edu.ng ([127.0.0.1]) by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceVk4pkeN2zx; Wed, 28 Nov 2007 08:29:53 +0100 (WAT) Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.unijos.edu.ng (Postfix) with ESMTP id 9D5A66813C; Wed, 28 Nov 2007 08:29:53 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id F347A281C9; Wed, 28 Nov 2007 08:57:11 +0100 (WAT) Received: from 192.168.192.51 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Wed, 28 Nov 2007 08:57:12 +0100 (WAT) Message-ID: <2300.192.168.192.51.1196236632.squirrel@mail.unijos.edu.ng> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> Date: Wed, 28 Nov 2007 08:57:12 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: "Natale, Bob" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Wed, 28 Nov 2007 08:03:10 -0500 Cc: mib2rdml@ietf.org, ops-area@ietf.org Subject: [MIB2RDML] Re: [OPS-AREA] SNMP MIB to XSD mapping I-D available X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: converting MIB modules into resource models List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mib2rdml-bounces@ietf.org I tried getting the site given but it responded page does not exist. That is: http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd On Wed, November 28, 2007 7:48 am, Natale, Bob said: > Hi, > > For those of you on the MIB2RMDL list who have been wondering what (if > anything!) has been going on during this long period of silence on the > e-mail list, and for others interested in having an IETF standard > methodology for mapping SNMP MIBs to XML via XSD for generic use by > XML-based management applications, I can now report some progress. > > That progress is best represented by a new Internet Draft which is now > available at > http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd > -00.txt, pending posting to the IETF I-D repository following the > imminent Vancouver IETF meeting. > > Dave Harrington has led this effort, starting with the XSDMI proposal > at the Chicago IETF meeting. As I published on this list around that > time, it makes sense for the MIB2RMDL effort to see XSDMI as the > essential first half of the equation (i.e., the "MIB2->" part) of > MIB2RMDL. Once the IETF publishes a standard methodology for the > expression of management information described in and accessible via > SNMP Management Information Bases (MIBs) as XML documents, then other > groups (if desired) can undertake the second half (i.e., the "->2RMDL" > part). (Note that this approach also allows for multiple resource > model mappings from the standard MIB to XSD mapping.) Yan Li did much > of the concrete research of multiple existing independent approaches > for doing the fundamental datatypes mapping addressed in this draft. > We then did a comparative analysis of those approaches, relative to the > requirements stipulated in Sec. 3 of this draft, as a baseline for the > specific approach this draft proposes. This draft originated from > draft-romascanu-netconf-datatypes, but now bears little resemblance to > that document, due to differences in scope, structure, and content. > > Any errors or otherwise errant statements in the draft are purely my > responsibility. > > I believe that the OPS ADs plan to allocate some agenda time to discuss > this work at the Vancouver IETF. I will post that scheduling info when > it becomes available, and I will do a post-Vancouver recap message as > soon after IETF-70 as possible. > > 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). > > Cheers, > BobN > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www1.ietf.org/mailman/listinfo/mib2rdml From mib2rdml-bounces@ietf.org Wed Nov 28 08:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMnC-0008MZ-Bw; Wed, 28 Nov 2007 08:17:30 -0500 Received: from mib2rdml by megatron.ietf.org with local (Exim 4.43) id 1IxMnB-0008Ke-6h for mib2rdml-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:17:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMn9-0008KA-Bm; Wed, 28 Nov 2007 08:17:27 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxMn8-0007tG-HB; Wed, 28 Nov 2007 08:17:26 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208,217";a="81908729" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Nov 2007 08:17:25 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208,217";a="134816825" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Nov 2007 08:17:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 14:16:14 +0100 Message-ID: In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] SNMP MIB to XSD mapping I-D available Thread-Index: AcgxirHW5FIU2mR9TiKWOw3/nJQ+IwANhBwQ References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> From: "Romascanu, Dan (Dan)" To: "Natale, Bob" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ops-area@ietf.org Subject: [MIB2RDML] RE: [OPS-AREA] SNMP MIB to XSD mapping I-D available X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.5 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="===============0233955664==" Errors-To: mib2rdml-bounces@ietf.org This is a multi-part message in MIME format. --===============0233955664== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C831C0.DA86E689" This is a multi-part message in MIME format. ------_=_NextPart_001_01C831C0.DA86E689 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 ________________________________ From: Natale, Bob [mailto:RNATALE@mitre.org]=20 =09 =20 =20 I believe that the OPS ADs plan to allocate some agenda time to discuss this work at the Vancouver IETF. I will post that scheduling info when it becomes available, and I will do a post-Vancouver recap message as soon after IETF-70 as possible. =20 =09 [DR] It's on the agenda of the OPS Area Open Meeting available at http://www3.ietf.org/proceedings/07dec/agenda/opsarea.txt.=20 =20 Dan =20 ------_=_NextPart_001_01C831C0.DA86E689 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 

From: Natale, Bob = [mailto:RNATALE@mitre.org]=20
 
 
I=20 believe that the OPS ADs plan to allocate some agenda time to discuss = this=20 work at the Vancouver IETF.  I will post that scheduling info = when it=20 becomes available, and I will do a post-Vancouver recap message as = soon after=20 IETF-70 as possible.
 

[DR] It's on the agenda of the OPS Area = Open Meeting=20 available at http:/= /www3.ietf.org/proceedings/07dec/agenda/opsarea.txt. 
 
Dan
 
= ------_=_NextPart_001_01C831C0.DA86E689-- --===============0233955664== 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://www1.ietf.org/mailman/listinfo/mib2rdml --===============0233955664==-- From mib2rdml-bounces@ietf.org Thu Nov 29 01:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxcqI-0006oa-Sg; Thu, 29 Nov 2007 01:25:46 -0500 Received: from mib2rdml by megatron.ietf.org with local (Exim 4.43) id 1IxcqH-0006mY-I3 for mib2rdml-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:25:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxcqH-0006lC-3V; Thu, 29 Nov 2007 01:25:45 -0500 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxcqG-0004Bm-Hn; Thu, 29 Nov 2007 01:25:44 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id lAT6PimJ000593; Thu, 29 Nov 2007 01:25:44 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id D575EBF8F; Thu, 29 Nov 2007 01:25:43 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id lAT6PhsQ000582; Thu, 29 Nov 2007 01:25:43 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 01:25:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MIB2RDML] SNMP MIB to XSD mapping I-D available Date: Thu, 29 Nov 2007 01:25:43 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02520673@IMCSRV2.MITRE.ORG> In-Reply-To: <20071128082730.GA28685@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB2RDML] SNMP MIB to XSD mapping I-D available Thread-Index: AcgxmIjASuDDdv6OTE6BeTxUYFIAeAAtdySg References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> <20071128082730.GA28685@elstar.local> From: "Natale, Bob" To: X-OriginalArrivalTime: 29 Nov 2007 06:25:43.0264 (UTC) FILETIME=[AB4AD600:01C83250] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mib2rdml@ietf.org, ops-area@ietf.org X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: converting MIB modules into resource models List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mib2rdml-bounces@ietf.org Hi Juergen, Thanks for the feedback. Concerning the clarifications you requested:=20 "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=20 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@jacobs-university.de]=20 Sent: Wednesday, November 28, 2007 3:28 AM To: Natale, Bob Cc: mib2rdml@ietf.org; ops-area@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: =20 > 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 <=3D> XSD equivalence (I assume this because you carry the 128 subidentifier OID restriction forward) while in other places people are fine with just SMI =3D> 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 --=20 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://www1.ietf.org/mailman/listinfo/mib2rdml From mib2rdml-bounces@ietf.org Thu Nov 29 05:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgtX-00054n-6h; Thu, 29 Nov 2007 05:45:23 -0500 Received: from mib2rdml by megatron.ietf.org with local (Exim 4.43) id 1IxgtV-00054f-Up for mib2rdml-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:45:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgtP-00052A-O0; Thu, 29 Nov 2007 05:45:15 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxgtO-0004ye-0b; Thu, 29 Nov 2007 05:45:15 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB4D88A22A; Thu, 29 Nov 2007 11:45:08 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03064-01; Thu, 29 Nov 2007 11:45:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D89148A1EC; Thu, 29 Nov 2007 11:44:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 710AD40219A; Thu, 29 Nov 2007 11:44:57 +0100 (CET) Date: Thu, 29 Nov 2007 11:44:57 +0100 From: Juergen Schoenwaelder To: "Natale, Bob" Subject: Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available Message-ID: <20071129104457.GA10751@elstar.local> References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> <20071128082730.GA28685@elstar.local> <4915F014FDD99049A9C3A8C1B832004F02520673@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02520673@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mib2rdml@ietf.org, ops-area@ietf.org X-BeenThere: mib2rdml@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: mib2rdml-bounces@ietf.org 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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ MIB2RDML mailing list MIB2RDML@ietf.org https://www1.ietf.org/mailman/listinfo/mib2rdml