From opsawg-bounces@ietf.org Tue Oct 16 10:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihn87-0006by-15; Tue, 16 Oct 2007 10:10:43 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1Ihn83-0006Z4-JF for opsawg-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 10:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihn82-0006X5-C7 for opsawg@ietf.org; Tue, 16 Oct 2007 10:10:38 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihn7w-0005he-7N for opsawg@ietf.org; Tue, 16 Oct 2007 10:10:38 -0400 Received: from harrington73653 (unknown[61.48.39.185]) by comcast.net (alnrmhc12) with SMTP id <20071016141015b1200me5ase>; Tue, 16 Oct 2007 14:10:16 +0000 From: "David Harrington" To: Date: Tue, 16 Oct 2007 22:10:02 +0800 Message-ID: <02ac01c80ffe$3fab7450$b927303d@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgP/ibea7yqjlcLTcKxinFlpABJuQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [OPSAWG] XSDMI X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, Juergen has raised the issue that the XSD produced by the XDMI effort and the XSD produced by the YANG effort might be different, and having two different XSD equivalents for MIB datatypes would be suboptimal. I agree. However, I have the concern that while vendors wait for YANG to be completed, they will need to develop proprietary data models for use with netconf. Some vendors will want to reuse datatypes found in the 15 year compilation of IETF NM experience found in the standard MIB modules, and supported by existing implementation code. If they need to develop their own translations of existing SMI datatypes and textual conventions into XSD and XML, we could wind up with a variety of competing XSD specifications. The XSDMI work would provide reusable XSD equivalents of SMI datatypes and textual conventions. If vendors use these consistent XSD translations, then later work to derive standards from the proprietary information/data models would be easier because there would be increased commonality in the datatypes and textual conventions and semantics used to model the information. In addition to proprietary data models, there are multiple IETF efforts to translate existing information models (often from ASN.1-based formats) into XML formats. draft-frascone-xml-dictionary-00 describes the Diameter "dictionary" in XML format; draft-legg-xed-roadmap-06.txt describes translating LDAP and X.509 directory information models into semantically equivalent XML renditions of existing directory protocols; IPPM is working on an information model in XML for traceroute measurements. So a MIB-related translation to XML is not unique. The XSDMI effort is about taking the MIB, which operators have complained is not well suited to configuration, and translating aspects of the MIB into equivalent XSD. The fact that the MIB datatypes can be translated into XSD will not make the MIB more suitable for configuration; it will simply make reusable dataypes available in an XML-compatible format. The netconf community should be focused on defining a data modeling language and data models for configuration. The YANG approach for netconf focuses not only on configuration, but also on developing an information modeling language which can then be used by tools to generate syntax-specific data models for a variety of purposes, such as Netconf-suitable XSD data models, SNMP-suitable MIB modules, plus data models for other modeling systems. I have a concern that the SNMP community has not been asking for this approach, and the IETF failed to reach consensus on the need for the information-modeling approach when it was presented to the SMING WG. If the information-model-generates-data-models approach is adopted by the IETF, then does that mean that efforts to use XML-based data models for ipfix, Diameter, IPPM, and LDAP should not be permitted until YANG can determine how to generate those data models as well? Just to be clear, I support the YANG effort because I believe it could lead to better consistency of data modeling across protocols, but it has yet to be proven to be viable, and other efforts to converge or harmonize data models have had mixed success at best. We should not put all our eggs into one basket. If the YANG approach proves to be viable, then the XSDMI translations can be modified as needed to work with YANG in the future. But XSDMI could give us XSD datatypes to develop data models, possibly years before consensus on YANG will be achieved. I believe the XSDMI effort should be an OPS-area effort (indeed an IETF-wide effort), focused in the OPSAWG, to allow the representation and translation into XML idiom of the existing datatypes, textual conventions, and semantic models defined in 15 years of work by multiple working groups and multiple areas of the IETF. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sat Oct 27 07:00:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljOb-0002a3-4y; Sat, 27 Oct 2007 07:00:01 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IljOa-0002Zm-5R for opsawg-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 07:00:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljOV-0002ZY-E3 for opsawg@ietf.org; Sat, 27 Oct 2007 06:59:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IljOU-0001ld-TK for opsawg@ietf.org; Sat, 27 Oct 2007 06:59:55 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQK003CYH6OJA@szxga03-in.huawei.com> for opsawg@ietf.org; Sat, 27 Oct 2007 18:59:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQK00HWBH6O1H@szxga03-in.huawei.com> for opsawg@ietf.org; Sat, 27 Oct 2007 18:59:12 +0800 (CST) Received: from l48181 ([10.111.12.236]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQK0081JH6NUW@szxml04-in.huawei.com> for opsawg@ietf.org; Sat, 27 Oct 2007 18:59:12 +0800 (CST) Date: Sat, 27 Oct 2007 18:59:11 +0800 From: Li Yan In-reply-to: <46F033D0.2030503@andybierman.com> To: 'Andy Bierman' , 'OPSAWG' Message-id: <000001c81888$682a9860$ec0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf6MmE8O6X59qlWS9uJebbjMr3KlAeTpZCw X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [OPSAWG] RE: [NGO] comments on draft-romascanu-netconf-datatypes-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, I agree that 'duration' datatype is prone to typo error, but I think it is more human readable than an integer. When a time interval appears as an integer, people have to calculate the number of years, months, days, hours, minutes, and seconds. I agree that this work has two purposes. Should the document have two XSDs? One is for new data models, the other is for translations of existing data models. Yan > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Wednesday, September 19, 2007 4:24 AM > To: NETCONF Goes On; OPSAWG > Subject: [NGO] comments on draft-romascanu-netconf-datatypes-02.txt > ... > * Sec 2.1.4: > > I strongly object to the proposal to translate integer-based > time-related SMIv2 data types to the complex 'duration' datatype > in XSD. Why make the data encoding as complicated > as possible? People will make mistakes typing it in. > > This draft does not seem to be clear on its higher purpose. > This is not just for writing new data models without giving up > core SMIv2 TCs. It is also needed to translate existing MIB > modules into NETCONF-compatible data models. > > The draft should distinguish between recommendations > for new data models vs. translations of existing data models. > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sat Oct 27 09:20:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IllaZ-0004zw-Ps; Sat, 27 Oct 2007 09:20:31 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IllaY-0004vD-Fy for opsawg-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 09:20:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IllaY-0004ur-5n for opsawg@ietf.org; Sat, 27 Oct 2007 09:20:30 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IllaX-0004Ow-QM for opsawg@ietf.org; Sat, 27 Oct 2007 09:20:30 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D07186850; Sat, 27 Oct 2007 15:20:28 +0200 (CEST) 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 23531-08; Sat, 27 Oct 2007 15:20:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B7418665B; Sat, 27 Oct 2007 15:20:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 508CF3AF9FC; Sat, 27 Oct 2007 15:20:23 +0200 (CEST) Date: Sat, 27 Oct 2007 15:20:23 +0200 From: Juergen Schoenwaelder To: Li Yan Subject: Re: [OPSAWG] RE: [NGO] comments on draft-romascanu-netconf-datatypes-02.txt Message-ID: <20071027132023.GA7518@elstar.local> Mail-Followup-To: Li Yan , 'Andy Bierman' , 'OPSAWG' References: <46F033D0.2030503@andybierman.com> <000001c81888$682a9860$ec0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c81888$682a9860$ec0c6f0a@china.huawei.com> 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'OPSAWG' X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org On Sat, Oct 27, 2007 at 06:59:11PM +0800, Li Yan wrote: > I agree that 'duration' datatype is prone to typo error, but I think it is > more human readable than an integer. When a time interval appears as an > integer, people have to calculate the number of years, months, days, hours, > minutes, and seconds. XSD duration is seriously broken. Go and read the definition, the many ways there are to represent the same value and most important the ambiguities involved in several representations (e.g. what is the duration of a months?). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg