From discuss-bounces@apps.ietf.org Thu Nov 01 05:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWZF-00026u-3y; Thu, 01 Nov 2007 05:42:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1InWUF-0002Ay-A4 for discuss-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 05:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWUE-0002A5-NC for discuss@apps.ietf.org; Thu, 01 Nov 2007 05:37:14 -0400 Received: from mail123.messagelabs.com ([85.158.136.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InWU8-0000GF-9F for discuss@apps.ietf.org; Thu, 01 Nov 2007 05:37:14 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-5.tower-123.messagelabs.com!1193909804!35000219!1 X-StarScan-Version: 5.5.12.14.2; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 22373 invoked from network); 1 Nov 2007 09:36:44 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-5.tower-123.messagelabs.com with SMTP; 1 Nov 2007 09:36:44 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id lA19ah009512 for ; Thu, 1 Nov 2007 10:36:44 +0100 (MET) 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: ETSI TISPAN interest in tv:URI Date: Thu, 1 Nov 2007 10:36:43 +0100 Message-ID: <42F3BE57026C6E49B09E267EEF639D56029F029F@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56019F7C94@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ETSI TISPAN interest in tv:URI thread-index: AcboWEdyz2u14ulLQmOOXlEqwqG1OQDJhFfwNKOJfCAXlwmUgA== References: <42F3BE57026C6E49B09E267EEF639D56D38E21@ms-dt01thalia.tsn.tno.nl> <42F3BE57026C6E49B09E267EEF639D56019F7C94@ms-dt01thalia.tsn.tno.nl> From: "Deventer, M.O. (Oskar) van" To: X-Spam-Score: -2.2 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org All, The=20issue=20of=20identification=20of=20television=20channels=20for=20IPT= V=20Presence=20has been=20discssed=20at=20the=20ETSI=20TISPAN=2014ter=20and=2015=20Plenary=20= meetings.=20This=20has lead=20to=20the=20start=20of=20a=20new=20Work=20Item=20in=20Working=20Grou= p=20WG4.=20 The=20new=20Work=20Item=20WI=204014=20is=20titled=20"Guidelines=20on=20TV=20= URI=20use=20for=20the identification=20of=20television=20channels",=20see http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=3D27318. The=20subject=20of=20IPTV=20Presence=20itself=20("my=20buddies=20being=20a= ble=20to=20see=20which TV=20channel=20I=20am=20watching")=20will=20be=20documented=20in=20the=20p= rotocol=20document TS=20183=20063=20"IMS-based=20IPTV=20stage=203=20specification",=20see http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=3D26367 TISPAN=20WG4=20(identifiers)=20has=20allocated=20a=20session=20in=20next=20= TISPAN=20meeting dedicated=20to=20"Guidelines=20on=20TV=20URI=20use=20for=20the=20identific= ation=20of television=20channels"".=20The=20meeting=20details=20are=20as=20follows,=20= see http://webapp.etsi.org/MeetingCalendar/MeetingDetails.asp?mid=3D11493. Meeting:=20TISPAN4-TISPAN=20WG4=20Ad=20Hoc=20 Location:=20ETSI=20Headquarters,=20Sophia=20Antipolis Dates:=2026-30=20November=202007 With=20this=20email,=20I=20would=20like=20to=20invite=20interested=20parti= es=20to participate=20and/or=20contribute=20to=20this=20ETSI=20TISPAN=20WG4=20work= . Best=20regards, Oskar=20 -------------------------------- dr.ir.=20M.=20Oskar=20van=20Deventer TNO=20Information=20and=20Communication=20Technology P.O.=20box=205050 2600=20GB=20=20Delft Netherlands +31=20651=20914=20918 oskar.vandeventer@tno.nl -------------------------------- Connecting=20to=20a=20TNO=20colleague?=20Call=20+31=2015=20285=2075=2075 -----Original=20Message----- From:=20Deventer,=20M.O.=20(Oskar)=20van=20[mailto:oskar.vandeventer@tno.n= l]=20 Sent:=20woensdag=204=20juli=202007=2011:35 To:=20discuss@apps.ietf.org Subject:=20ETSI=20TISPAN=20interest=20in=20tv:URI All, The=20issue=20of=20identification=20of=20television=20channels=20has=20bee= n=20discussed=20in the=20ETSI=20TISPAN=2014bis=20meeting=20of=20last=20week.=20The=20applicat= ion=20of=20this identification=20is=20IPTV=20Presence:=20a=20presentity=20can=20publish=20= which=20TV channel=20he=20is=20watching.=20The=20fact=20that=20ETSI=20TISPAN=20has=20= requirements related=20to=20the=20identification=20of=20TV=20channels=20(e.g.=20tv:URI)= =20is=20reflected in=20the=20recent=20update=20of=20our=20internet=20draft http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-01.txt. TISPAN=20WG1=20(services)=20and=20WG2=20(architecture)=20have=20defined=20= the=20following requirements,=20relevant=20to=20our=20IETF=20APPS=20mailing=20list=20discu= ssions=20on=20the tv:URI=20last=20October. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20Start=20of=20TISPAN=20requirements=20=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D WI01044=20(Draft=20TS=20181=20016): "Users'=20presence=20information=20may=20be=20related=20to,=20e.g.,=20thei= r=20connection status,=20location=20information,=20channel=20currently=20accessed=20or=20= acceptable communication=20means.=20Presence=20information=20on=20channel=20currently= =20accessed may=20be=20used=20by=20another=20user=20to=20instruct=20his=20set-top=20bo= x=20with=20a=20single click=20to=20switch=20to=20the=20identified=20channel,=20or=20to=20instruc= t=20his=20set-top box=20to=20keep=20following=20identified=20channel=20changes.=20There=20ma= y=20be significant=20delays=20in=20this=20following,=20depending=20on=20the=20upd= ate=20speed=20of the=20presence=20service. Any=20published=20presence=20information=20should=20only=20be=20disseminat= ed=20other users=20that=20are=20authorised=20to=20receiving=20this=20presence=20infor= mation according=20to=20the=20presentity=20policies=20Users=20can=20also=20define= =20a=20set=20of access=20rules=20to=20control=20access=20to=20their=20presence=20informati= on. 6.2.1.1=09=09It=20must=20be=20possible=20to=20define=20presence=20informat= ion related=20to=20the=20IPTV=20experience,=20e.g.=20channel=20currently=20acc= essed.=20The identification=20of=20the=20channel=20currently=20accessed=20shall=20be machine-readable.=20Language=20dependent=20information=20may=20also=20be=20= made available=20to=20watchers." WI02048=20(Draft=20TS=20182=20027): "The=20following=20specific=20IPTV=20attributes=20may=20also=20be=20suppor= ted: channel=20currently=20accessed, program=20currently=20watched,=20when=20available. content=20currently=20accessed. If=20the=20IPTV=20presence=20attribute=20"channel=20currently=20accessed"=20= is supported,=20then=20the=20machine-readable=20part=20of=20the=20identificat= ion=20of=20the channel=20shall=20be=20globally=20unique.=20The=20term=20globally=20unique= =20here=20means that=20there=20is=20no=20ambiguity=20in=20the=20identification=20of=20the=20= channel=20if presentity=20and=20watcher=20(for=20terminology,=20see=20in=20ETSI=20182=20= 008)=20are=20with different=20network=20operators=20and/or=20in=20different=20countries." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20End=20of=20TISPAN=20requirements=20=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D TISPAN=20WG4=20(identifiers)=20has=20allocated=20a=20session=20in=20next=20= TISPAN=20meeting dedicated=20to=20"Tv=20URI=20identifier=20and=20resolution".=20The=20meeti= ng=20details=20for this=20session=20are=20as=20follows. Meeting:=20ETSI=20TISPAN=2014ter Location:=20ETSI=20Headquarters,=20Sophia=20Antipolis Dates:=203-7=20September=202007 WG4=20session=20on=20tv:URI:=20Wednesday=205=20September,=2011:15-13:00 With=20this=20email,=20I=20would=20like=20to=20invite=20interested=20parti= es=20to participate=20and/or=20contribute=20to=20this=20WG4=20session. Best=20regards, Oskar=20 -----Original=20Message----- From:=20Keesmaat,=20N.W.=20(Iko) Sent:=20maandag=209=20oktober=202006=2013:25 To:=20discuss@apps.ietf.org Cc:=20Clive=20D.W.=20Feather;=20Zigmond,=20Dan Subject:=20RE:=20Reigistry=20for=20tv:URI's [...=20previous=20mail=20thread=20...] This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at http://www.tno.nl/disclaimer/email.html This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Fri Nov 02 15:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io28H-0006ws-So; Fri, 02 Nov 2007 15:24:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Io28H-0006wj-3o for discuss-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 15:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io28G-0006wX-Q5 for discuss@apps.ietf.org; Fri, 02 Nov 2007 15:24:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io28B-00033E-Hw for discuss@apps.ietf.org; Fri, 02 Nov 2007 15:24:40 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Io282-000EFB-GA for discuss@apps.ietf.org; Fri, 02 Nov 2007 15:24:26 -0400 Date: Fri, 02 Nov 2007 15:24:18 -0400 From: John C Klensin To: discuss@apps.ietf.org Subject: IDNAbis documents Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi. Two new documents, draft-klensin-idnabis-issues-03 and draft-klensin-idnabis-protocol-00 have been posted The first has been announced, the second should follow soon. These are the first versions of the IDNAbis document set that separate the protocol specification from the theory and rationale. I suggest that anyone interested in IDNA examine them as closely as possible. john From discuss-bounces@apps.ietf.org Mon Nov 05 20:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpDRG-0002Xg-8S; Mon, 05 Nov 2007 20:41:10 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IpDRE-0002Vh-N5 for discuss-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 20:41:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpDRE-0002S0-0j for discuss@apps.ietf.org; Mon, 05 Nov 2007 20:41:08 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpDRA-0002hY-6i for discuss@apps.ietf.org; Mon, 05 Nov 2007 20:41:07 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B2F0814220C; Mon, 5 Nov 2007 17:41:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdnR24p0xcri; Mon, 5 Nov 2007 17:40:57 -0800 (PST) Received: from [192.168.1.103] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EDA64142207; Mon, 5 Nov 2007 17:40:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-11--889793745 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps area activity for October 2007 From: Lisa Dusseault Date: Mon, 5 Nov 2007 17:40:54 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-11--889793745 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Notes: - ATOMPUB working group closed - HTTP working group chartered - See you in Vancouver -- Accepting Apparea meeting topics Document Status and Progress Active Documents: my action - draft-sjdcox-cgi-urn (None): I need to review - draft-adolf-dvb-urn (Informational): I need to do a writeup -- no document shepherd Stalled, in review, waiting on other: - draft-ietf-sieve-notify: waiting on author response to AD review - draft-ietf-sieve-notify-mailto: waiting on author response to AD review - draft-ietf-sieve-notify-xmpp: waiting on author response to AD review - draft-goodwin-iso-urn (Informational): in IETF Last Call - draft-snell-atompub-bidi (Proposed Standard): author waiting on some implementation feedback - draft-creed-ogc-urn (Informational): in IETF Last Call - draft-wilde-sms-uri (Proposed Standard): in IETF Last Call - draft-ietf-sieve-body (Proposed Standard): Waiting on revised ID to deal with gen-art feedback - draft-mealling-epc-urn (Informational): Ready for IESG Evaluation - draft-ietf-imapext-sort (Proposed Standard) : waiting for authors to revise or decide it's ready - draft-montemurro-gsma-imei-urn (Experimental): Waiting for authors to deal with early feedback Finished Processing -- RFC Ed queue and new RFCs - draft-saintandre-rfc4622bis (Proposed Standard) - draft-crocker-rfc4234bis (Standard) - draft-ietf-sieve-3028bis (Proposed Standard) RFC5051 -- i;unicode-casemap - Simple Unicode Collation Algorithm RFC5023 -- The Atom Publishing Protocol WG Status - SIEVE waiting for final documents to go through evaluation, IETF last call, etc. - IMAPEXT stalled waiting for i18n work to complete - ATOMPUB closed - CALSIFY quiet in last month - USEFOR stalled on single WG deliverable - HTTP just started up Lisa --Apple-Mail-11--889793745 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
=A0- ATOMPUB = working group closed
=A0- HTTP = working group chartered
=A0- See you in = Vancouver -- Accepting Apparea meeting topics=A0

Document Status and Progress

Active = Documents: my action
=A0-=A0draft-sjdcox-cgi-urn (None): I = need to review
=A0-=A0draft-adolf-dvb-urn (Informational): I = need to do a writeup -- no document shepherd


Finished = Processing -- RFC Ed queue and new = RFCs
=A0-=A0draft-saintandre-rfc4622bis (Proposed = Standard)
=A0-=A0draft-crocker-rfc4234bis = (Standard)
=A0-=A0draft-ietf-sieve-3028bis (Proposed = Standard)
=A0RFC5051 --=A0i;unicode-casemap - Simple Unicode = Collation Algorithm
=A0RFC5023 --=A0The Atom Publishing = Protocol

WG Status
=A0- SIEVE = waiting for final documents to go through evaluation, IETF last call, = etc.
=A0- IMAPEXT stalled waiting for = i18n work to complete
=A0- ATOMPUB = closed
=A0- CALSIFY quiet in last = month
=A0- USEFOR stalled on single WG = deliverable
=A0- HTTP just started = up=A0

Lisa=A0

= --Apple-Mail-11--889793745-- From discuss-bounces@apps.ietf.org Wed Nov 07 17:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipt89-0007Z4-4k; Wed, 07 Nov 2007 17:12:13 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ipt88-0007Yy-1q for discuss-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 17:12:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipt87-0007YK-LC for discuss@apps.ietf.org; Wed, 07 Nov 2007 17:12:11 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipt82-0004m6-GP for discuss@apps.ietf.org; Wed, 07 Nov 2007 17:12:11 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188792000"; d="scan'208";a="81693227" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 07 Nov 2007 17:12:05 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188792000"; d="scan'208";a="122966047" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 07 Nov 2007 17:11:25 -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: FW: [YANG] YANG draft Date: Wed, 7 Nov 2007 23:11:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [YANG] YANG draft Thread-Index: AcghgWTiLe/FvXcgTCG62Q1CX9RSkAACXLow From: "Romascanu, Dan (Dan)" To: "Netconf WG" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 I apologize for cross-posting.=20 Dan =20 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Wednesday, November 07, 2007 11:05 PM To: yang@ietf.org Subject: [YANG] YANG draft A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-bjorklund-netconf-yang-00.txt Pages : 147 Date : 2007-11-07 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt /martin From discuss-bounces@apps.ietf.org Fri Nov 09 13:55:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ19-0005YC-6y; Fri, 09 Nov 2007 13:55:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IqZ17-0005UP-5X for discuss-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 13:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ16-0005Th-Re for discuss@apps.ietf.org; Fri, 09 Nov 2007 13:55:44 -0500 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZ11-0001mb-H8 for discuss@apps.ietf.org; Fri, 09 Nov 2007 13:55:44 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 452B92A6C for ; Fri, 9 Nov 2007 18:55:36 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID151Lkis4K6024Xo2; Fri, 09 Nov 2007 18:55:36 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID151Lkis4K6024Xo2 Received: from [192.168.1.103] ([74.95.2.169]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 11:55:34 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-18--568516901 From: Lisa Dusseault Subject: Usefulness of WSDL Date: Fri, 9 Nov 2007 10:55:31 -0800 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Nov 2007 18:55:34.0725 (UTC) FILETIME=[1C07F750:01C82302] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-18--568516901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed I see WSDL proposed for some spec in the IETF every so often but =20 nobody's ever explained to me what it solves. James Snell who has =20 more experience than me in the matter wrote: "Those who are familiar with my history with IBM should know that I =20 was once a *major* proponent of the WS-* approach. I was one of the =20 original members of the IBM Emerging Technologies Toolkit team, I =20 wrote so many articles on the subject during my first year with IBM =20 that I was able to pay a down payment on my house without touching a =20 dime of savings or regular paycheck, and I was involved in most of =20 the internal efforts to design and prototype nearly all of the WS-* =20 specifications. However, over the last two years I haven=92t written a =20= single line of code that has anything to do with WS-*. The reason for =20= this change is simple: when I was working on WS-*, I never once =20 worked on an application that solved a real business need. Everything =20= I wrote back then were demos. Now that I=92m working for IBM=92s = WebAhead =20 group, building and supporting applications that are being used by =20 tens of thousands of my fellow IBMers, I haven=92t come across a single =20= use case where WS-* would be a suitable fit." Anybody got counter-arguments or is this a reasonable indictment? Lisa [from James' blog: http://www.snellspace.com/wp/?p=3D798]= --Apple-Mail-18--568516901 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252

I see WSDL proposed for = some spec in the IETF every so often but nobody's ever explained to me = what it solves.=A0 James Snell who has more experience than me in the = matter wrote:

"Those who are familiar with my history with IBM should know that = I was once a *major* proponent of the WS-* approach. I was one of the = original members of the IBM Emerging Technologies Toolkit team, I wrote = so many articles on the subject during my first year with IBM that I was = able to pay a down payment on my house without touching a dime of = savings or regular paycheck, and I was involved in most of the internal = efforts to design and prototype nearly all of the WS-* specifications. = However, over the last two years I haven=92t written a single line of = code that has anything to do with WS-*. The reason for this change is = simple: when I was working on WS-*, I never once worked on an = application that solved a real business need. Everything I wrote back = then were demos. Now that I=92m working for IBM=92s WebAhead group, = building and supporting applications that are being used by tens of = thousands of my fellow IBMers, I haven=92t come across a single use case = where WS-* would be a suitable fit."

Anybody got = counter-arguments or is this a reasonable indictment?

Lisa

= --Apple-Mail-18--568516901-- From discuss-bounces@apps.ietf.org Fri Nov 09 14:06:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZBt-0000yI-Hi; Fri, 09 Nov 2007 14:06:53 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IqZBs-0000xf-2a for discuss-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZBr-0000xW-Kl for discuss@apps.ietf.org; Fri, 09 Nov 2007 14:06:51 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZBp-0002D2-8l for discuss@apps.ietf.org; Fri, 09 Nov 2007 14:06:51 -0500 Received: by wx-out-0506.google.com with SMTP id h26so360754wxd for ; Fri, 09 Nov 2007 11:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=WNEYUKsicyCe8GNbgy4plChakZNt1rDe7MCTscm3uek=; b=NYf8tVhSprCb/Swj86IHdVn2lKofkVcyl2dwT4JSzk5ogtzmKd2CTcXgSx47+XqlPVQJSbGqvlvAZkVCUA5shazhvcAcQHgWDl0aPUaP8CfsE8ZBvrsm7rlQT8CgcDLX0RTcILLIzOalRHARGdtR31Wn7AwDorj3s9onap9gYa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=tL4XZYuIc8eSy4NZpjfUz8+J06iWoJ2SQler75GOllmzyMucMecS7zfkfbNTJTY2LKFm4oGNo9aV4/YiOpTO2Y5xs85hf7TaqK7NFSKadOz5zvKI8e8MWXOOF35Ye+1PQz9+pqFUD7XpSBKT8seWHDP06/Q7QS2k0vyITISYsP8= Received: by 10.70.50.4 with SMTP id x4mr1479579wxx.1194635208355; Fri, 09 Nov 2007 11:06:48 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id h14sm125780wxd.2007.11.09.11.06.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Nov 2007 11:06:47 -0800 (PST) Message-ID: <4734AFBF.20302@gmail.com> Date: Fri, 09 Nov 2007 11:06:39 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Usefulness of WSDL References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Just as a point of clarification: I'm not saying that WSDL is not useful in general; I'm saying that in my personal experience I've never had any reason to ever use it in a real-world application. :-) - James Lisa Dusseault wrote: > > I see WSDL proposed for some spec in the IETF every so often but > nobody's ever explained to me what it solves. James Snell who has more > experience than me in the matter wrote: > > "Those who are familiar with my history with IBM should know that I was > once a *major* proponent of the WS-* approach. I was one of the original > members of the IBM Emerging Technologies Toolkit team, I wrote so many > articles on the subject during my first year with IBM that I was able to > pay a down payment on my house without touching a dime of savings or > regular paycheck, and I was involved in most of the internal efforts to > design and prototype nearly all of the WS-* specifications. However, > over the last two years I haven’t written a single line of code that has > anything to do with WS-*. The reason for this change is simple: when I > was working on WS-*, I never once worked on an application that solved a > real business need. Everything I wrote back then were demos. Now that > I’m working for IBM’s WebAhead group, building and supporting > applications that are being used by tens of thousands of my fellow > IBMers, I haven’t come across a single use case where WS-* would be a > suitable fit." > > Anybody got counter-arguments or is this a reasonable indictment? > > Lisa > > [from James' blog: http://www.snellspace.com/wp/?p=798] From discuss-bounces@apps.ietf.org Fri Nov 09 15:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqaQv-00050A-An; Fri, 09 Nov 2007 15:26:29 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IqaQt-0004wv-J5 for discuss-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 15:26:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqaQt-0004wn-9E for discuss@apps.ietf.org; Fri, 09 Nov 2007 15:26:27 -0500 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqaQp-0005s6-PY for discuss@apps.ietf.org; Fri, 09 Nov 2007 15:26:27 -0500 Received: by nz-out-0506.google.com with SMTP id n29so477556nzf for ; Fri, 09 Nov 2007 12:26:22 -0800 (PST) Received: by 10.114.125.2 with SMTP id x2mr785035wac.1194639981983; Fri, 09 Nov 2007 12:26:21 -0800 (PST) Received: by 10.115.48.11 with HTTP; Fri, 9 Nov 2007 12:26:21 -0800 (PST) Message-ID: Date: Fri, 9 Nov 2007 15:26:21 -0500 From: "Mark Baker" To: "Lisa Dusseault" Subject: Re: Usefulness of WSDL In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 866623da2e869189 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 11/9/07, Lisa Dusseault wrote: > > > I see WSDL proposed for some spec in the IETF every so often but nobody's > ever explained to me what it solves. James Snell who has more experience > than me in the matter wrote: > > "Those who are familiar with my history with IBM should know that I was once > a *major* proponent of the WS-* approach. I was one of the original members > of the IBM Emerging Technologies Toolkit team, I wrote so many articles on > the subject during my first year with IBM that I was able to pay a down > payment on my house without touching a dime of savings or regular paycheck, > and I was involved in most of the internal efforts to design and prototype > nearly all of the WS-* specifications. However, over the last two years I > haven't written a single line of code that has anything to do with WS-*. The > reason for this change is simple: when I was working on WS-*, I never once > worked on an application that solved a real business need. Everything I > wrote back then were demos. Now that I'm working for IBM's WebAhead group, > building and supporting applications that are being used by tens of > thousands of my fellow IBMers, I haven't come across a single use case where > WS-* would be a suitable fit." > > Anybody got counter-arguments or is this a reasonable indictment? Nope, sounds about right to me. IMO, the whole notion of service-specific interfaces - the reason WSDL exists - is an anethema to Internet scale and so has no place in the IETF. It also encourages bad practice around exposing implementation details, such as the current schema support by the device (because we all know, those never change over time 8-). That said, if some spec author wants to use it, I don't see any need to prevent them from doing so, so long as the emphasis of the spec is on the protocol. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com From discuss-bounces@apps.ietf.org Fri Nov 09 16:33:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqbU7-000550-7F; Fri, 09 Nov 2007 16:33:51 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IqbU5-0004yJ-3c for discuss-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 16:33:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqbU4-0004yA-QI for discuss@apps.ietf.org; Fri, 09 Nov 2007 16:33:48 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqbU1-0008T5-7j for discuss@apps.ietf.org; Fri, 09 Nov 2007 16:33:48 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lA9LXid5003454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Nov 2007 13:33:44 -0800 X-Auth-Received: from D-140-142-21-197.dhcp4.washington.edu (D-140-142-21-197.dhcp4.washington.edu [140.142.21.197]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lA9LXhBh017896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Nov 2007 13:33:43 -0800 Date: Fri, 9 Nov 2007 13:33:22 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Lisa Dusseault Subject: Re: Usefulness of WSDL In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.11.9.130500 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I see WSDL proposed for some spec in the IETF every so often but > nobody's ever explained to me what it solves. The motivations for Interface Definition Languages (IDLs), of which WSDL is an example, and of Remote Procedure Call (RPC) systems, of which IDLs are a component (and of which WS-* is an example), are straightforward. Among other places they are described in RFCs 1057 and 1831, which document Sun's ONC RPC (1831 is standards-track even). The seminal paper, as mentioned in 1831, is Birrell, A. D. & Nelson, B. J., "Implementing Remote Procedure Calls", XEROX CSL-83-7, October 1983. for which a cursory search doesn't reveal an online instance. (Some might flame at calling WS-* "RPC", so OK, substitute "RPC-like distributed computing system" instead.) The idea is that protocols are hard to write, and software implementing protocols is hard to write. So an RPC system creates a meta-protocol; a concrete protocol to do real operations is created by writing an interface definition in an IDL. The IDL serves as generator for both a protocol spec and an API spec; the IDL is fed into a language-specific stub generator which produces libraries for use in that language for that interface (ie, that protocol). The programmer just uses those libraries like she would any other libraries when implementing a system. Voila, the pain of writing protocol implementations, and protocols, vanishes. This argument has been so compelling that dozens (maybe hundreds) of RPC systems have been invented, and many widely deployed, over the years. Each promises to solve the problems that have led to the previous ones not meeting the hype of their promoters. And of course the gap between hype and adoption has led to some of them being among the highest-profile computing failures (see "DCE"), at least in popular opinion. I think the story has remained largely the same for the last 25 years or so. Using an RPC system is undeniably better than the usual system integration alternative of making up a new protocol from scratch, which anyone doing system integration knows leads to appalling protocol interfaces on systems of all kinds. But RPC systems never seem to escape this niche of home-grown interfaces for a small purpose with a few consumers. Probably there are lots of reasons why this has been so. I'd guess among the most important is that IDL toolkits inevitably become language- and vendor-centric, so the theoretical cross-platform agility and interop doesn't happen in real life. So people with real scalable distributed systems work to do focus on real protocols and accept the burden of writing implementations of them more or less from scratch (often these days based on HTTP+REST). (Obviously there are many perspectives and counterexamples, it's a big Internet.) Given that Internet protocols specified in RFCs are presumably intended for those widely distributed and widely implemented cases, it seems like RPC/IDL technology, including WS-*/WSDL, is generally inappropriate. Obviously there have been exceptions, as RFCs 1831-3 and 3530 demonstrate. - RL "Bob" From discuss-bounces@apps.ietf.org Sun Nov 11 16:06:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrK14-0001Ki-IP; Sun, 11 Nov 2007 16:06:50 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IrK13-0001IK-1L for discuss-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 16:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrK12-0001HW-Nh for discuss@apps.ietf.org; Sun, 11 Nov 2007 16:06:48 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrK0z-00023l-F1 for discuss@apps.ietf.org; Sun, 11 Nov 2007 16:06:48 -0500 Received: by rv-out-0910.google.com with SMTP id c27so864439rvf for ; Sun, 11 Nov 2007 13:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=NIAjiFURdGCF9013rHji1dHOm7hqEodUlnZWOxrqldg=; b=Ozy2K0d/qQpp7Pp3feOwPhdEso6bBK7nkOQJyUnGB5xehl0roPyightFYJuuEW1p3FwVwC5RPbefWCGXR/K+/MYCX1oz/+NJdZQCPnhjJYPB6B9+6M2rnf14mP7CYB9+pfAxxhcrGhZlLHfFd9ww3qO2KE6GcQGLgSgNlCPZ814= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lQHkqCDAGCjXQBhL3xnPxtJUPas20ud6YJEcOGM9hkOSyolBQpH80XJYIjU1TqzrDZJ/f6Ry5sXAvgH42mSFUAhwV1QXC9zwlMtqgyiYYI7sP1yGgA5vW/v5m7arMqGJ8+z5jO7BDaCTkCwNjHCrk6Yj1v39ghrfGnvxj98KjyU= Received: by 10.115.75.1 with SMTP id c1mr1433935wal.1194815204381; Sun, 11 Nov 2007 13:06:44 -0800 (PST) Received: by 10.114.161.15 with HTTP; Sun, 11 Nov 2007 13:06:44 -0800 (PST) Message-ID: <517bf110711111306nff005b4x706e79144298b14c@mail.gmail.com> Date: Sun, 11 Nov 2007 13:06:44 -0800 From: "Tim Bray" To: "Lisa Dusseault" Subject: Re: Usefulness of WSDL In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: b0f558d1793c6828 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa, you might it useful to pull a copy of the WSDL spec and invest a half-hour in just looking at it. It's really hard to understand, and my feeling is that it's an extremely poor piece of design. I can remember I was once speaking at a big Java conference, maybe 600 people in audience; I asked for a show of hands as to who was using WSDL. A large majority of hands went up. Then I asked how many thought they actually understood it. Maybe 2 or 3 hands. How many liked it? Another couple of hands. Based on experience with WS-*, I suspect that in general any IETF spec that requires the use of WSDL will be expensive to implement and fragile in deployment. Among other things, a spec that's regarded as difficult to understand should be avoided if there's a plausible alternative. -Tim From discuss-bounces@apps.ietf.org Mon Nov 12 06:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXD0-0007OI-LM; Mon, 12 Nov 2007 06:12:02 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IrXCw-0007I3-94 for discuss-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 06:11:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXCv-0007Hu-SY for discuss@apps.ietf.org; Mon, 12 Nov 2007 06:11:57 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrXCs-00063B-Be for discuss@apps.ietf.org; Mon, 12 Nov 2007 06:11:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 7405B3C223; Mon, 12 Nov 2007 12:11:53 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09162-01-16; Mon, 12 Nov 2007 12:11:53 +0100 (CET) Received: from klapautius.it.su.se (dhcp-wavelan-vo-30.publik.su.se [193.11.30.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id A01FB3C045; Mon, 12 Nov 2007 12:11:52 +0100 (CET) Message-ID: <47383503.2090207@it.su.se> Date: Mon, 12 Nov 2007 12:12:03 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Usefulness of WSDL References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.075 tagged_above=-99 required=7 tests=[AWL=0.237, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org These days WS-* is something everyone loves to hate (and often for good reason). In the case of WSDL I think its good to remember that WSDL is one of the very few WS* technologies that has been widely implemented - people do actually use WSDL from perl-based SOAP- stacks to lookup and call java-based services etc. As for how much developers _really_ understand technology, I suspect one would get similar answers as Tim got if one were to ask a set of programmers about just about any set of technologies for which there is good tooling available. Those programmers probably was thinking more about the quality of the tooling than about the quality of the under- lying technology. I think it may be interesting to ask why WSDL turns up in IETF specs but not (say) WS-Policy or WS-ReliableMessaging. My guess would be that in many cases solutions which started out as simple systems- integration RPCs (ct-kip-ws may be an example) have grown into protocols in the sense that they are implemented by multiple vendors etc. Cheers Leif From discuss-bounces@apps.ietf.org Mon Nov 12 07:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYrn-0000wb-Qp; Mon, 12 Nov 2007 07:58:15 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IrYrm-0000wT-S6 for discuss-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYrm-0000wL-Ic for discuss@apps.ietf.org; Mon, 12 Nov 2007 07:58:14 -0500 Received: from mxout-04.mxes.net ([216.86.168.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrYrj-0001iq-A8 for discuss@apps.ietf.org; Mon, 12 Nov 2007 07:58:14 -0500 Received: from [127.0.0.1] (unknown [216.145.54.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2F33DD0501; Mon, 12 Nov 2007 07:58:08 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D742E59-FA65-4A99-B055-8A50AADA628C@mnot.net> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: Usefulness of WSDL Date: Mon, 12 Nov 2007 23:55:15 +1100 To: Mark Baker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Apps Discuss , Lisa Dusseault X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 10/11/2007, at 7:26 AM, Mark Baker wrote: > That said, if some spec author wants to use it, I don't see any > need to prevent them from doing so, so long as the emphasis of the > spec is on the protocol. I disagree. The interop and interpretation problems with WSDL make it too much of a liability to use in a spec; it will cause more problems than it solves. Even if you plaster warnings that it's non-normative and that the spec wins, people will still use it to generate their code, and they'll be stuck with the data binding and interface modelling mess that results. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Mon Nov 12 14:59:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfQz-0001yz-3m; Mon, 12 Nov 2007 14:59:01 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IrfQx-0001py-E8 for discuss-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 14:58:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfQx-0001pq-4a for discuss@apps.ietf.org; Mon, 12 Nov 2007 14:58:59 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrfQu-0002X9-GM for discuss@apps.ietf.org; Mon, 12 Nov 2007 14:58:59 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lACJwmRq019678 for ; Mon, 12 Nov 2007 21:58:54 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 21:58:51 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 21:58:51 +0200 Received: from [10.162.64.241] ([10.162.64.241]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 21:58:50 +0200 Message-ID: <4738B07A.3000407@nsn.com> Date: Mon, 12 Nov 2007 21:58:50 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: File metadata format draft Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 19:58:50.0944 (UTC) FILETIME=[71FE4400:01C82566] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Matuszewski Marcin \(Nokia-NRC/Helsinki\)" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi: I have submitted a draft that defines an XML schema for describing files and associated metadata. I am referring to this draft: http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-format-00.txt The background of this draft is as follows: We first submitted a SIP event package for subscribing to changes in files stored in a remote endpoint. The idea is to use SIP to emulate the "shared folder" functionality that is available in common instant messaging and presence clients. A part of the overall function is a format for describing files and associated metadata. At the last IETF meeting, I got a few comments indicating that the data format could be reused by other protocols, namely HTTP, and thus, it should be split out from the draft and discussed in the Apss area. So this is what I am doing. So, the authors would like to get comments and questions about the document. Yours, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From discuss-bounces@apps.ietf.org Mon Nov 12 15:09:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfb6-0005kQ-MI; Mon, 12 Nov 2007 15:09:28 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Irfb6-0005kB-48 for discuss-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 15:09:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfb5-0005k3-Qm for discuss@apps.ietf.org; Mon, 12 Nov 2007 15:09:27 -0500 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irfb1-0002tF-4J for discuss@apps.ietf.org; Mon, 12 Nov 2007 15:09:27 -0500 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lACK9G34025607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2007 15:09:19 -0500 Date: Mon, 12 Nov 2007 15:09:11 -0500 From: Cyrus Daboo To: Miguel Garcia , discuss@apps.ietf.org Subject: Re: File metadata format draft Message-ID: In-Reply-To: <4738B07A.3000407@nsn.com> References: <4738B07A.3000407@nsn.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Matuszewski Marcin \(Nokia-NRC/Helsinki\)" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Miguel, --On November 12, 2007 9:58:50 PM +0200 Miguel Garcia wrote: > I have submitted a draft that defines an XML schema for describing files > and associated metadata. I am referring to this draft: > > http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-forma > t-00.txt > > The background of this draft is as follows: We first submitted a SIP > event package for subscribing to changes in files stored in a remote > endpoint. The idea is to use SIP to emulate the "shared folder" > functionality that is available in common instant messaging and presence > clients. A part of the overall function is a format for describing files > and associated metadata. > > At the last IETF meeting, I got a few comments indicating that the data > format could be reused by other protocols, namely HTTP, and thus, it > should be split out from the draft and discussed in the Apss area. So > this is what I am doing. > > So, the authors would like to get comments and questions about the > document. Had a quick look. In the HTTP world, meta-data about files is already covered by WebDAV properties. So the question I have is what, if any, thought has been given to integration with WebDAV. e.g. a lot of elements in your schema have exact equivalents in WebDAV. It might be useful, at a minimum, to define a mapping between your schema and what WebDAV provides. -- Cyrus Daboo From discuss-bounces@apps.ietf.org Tue Nov 13 05:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrspP-0000uX-5v; Tue, 13 Nov 2007 05:17:07 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IrspO-0000uS-GM for discuss-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 05:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrspO-0000t5-5a for discuss@apps.ietf.org; Tue, 13 Nov 2007 05:17:06 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrspK-00042J-GI for discuss@apps.ietf.org; Tue, 13 Nov 2007 05:17:06 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lADAGEs6016679; Tue, 13 Nov 2007 12:16:59 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 12:16:57 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 12:16:56 +0200 Received: from [10.144.22.54] ([10.144.22.54]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 12:16:56 +0200 Message-ID: <47397998.10102@nsn.com> Date: Tue, 13 Nov 2007 12:16:56 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: File metadata format draft References: <4738B07A.3000407@nsn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 10:16:56.0865 (UTC) FILETIME=[51FE5910:01C825DE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "Matuszewski Marcin \(Nokia-NRC/Helsinki\)" , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At the moment the integration with the WebDAV properties is not done. I believe this is a topic for discussion. I have here more questions than answers. For example: Do we want to propose a single data format for describing file metadata? The WebDAV properties is already standardized and deployed, whereas the file-data-format draft is not. However, the requirements of both applications are not totally the same. For example, the file data format does not care about the creator, but needs to signal different endpoints (instances) that host the same file. Or can we integrate the WebDAV properties into the file data format? This will effectively create a superset of the WebDAV properties, bt I am not sure it will have a footprint on the implementations, due to the advance state of deployment of WebDAV. Or do we want to continue with two separate paths, perhaps with this mapping that you mentioned? BR, Miguel Cyrus Daboo wrote: > Hi Miguel, > > --On November 12, 2007 9:58:50 PM +0200 Miguel Garcia > wrote: > >> I have submitted a draft that defines an XML schema for describing files >> and associated metadata. I am referring to this draft: >> >> http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-forma >> t-00.txt >> >> The background of this draft is as follows: We first submitted a SIP >> event package for subscribing to changes in files stored in a remote >> endpoint. The idea is to use SIP to emulate the "shared folder" >> functionality that is available in common instant messaging and presence >> clients. A part of the overall function is a format for describing files >> and associated metadata. >> >> At the last IETF meeting, I got a few comments indicating that the data >> format could be reused by other protocols, namely HTTP, and thus, it >> should be split out from the draft and discussed in the Apss area. So >> this is what I am doing. >> >> So, the authors would like to get comments and questions about the >> document. > > Had a quick look. In the HTTP world, meta-data about files is already > covered by WebDAV properties. So the question I have is what, if any, > thought has been given to integration with WebDAV. e.g. a lot of > elements in your schema have exact equivalents in WebDAV. It might be > useful, at a minimum, to define a mapping between your schema and what > WebDAV provides. > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From discuss-bounces@apps.ietf.org Tue Nov 13 08:33:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvtK-0008Up-9l; Tue, 13 Nov 2007 08:33:22 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IrvtJ-0008QE-1J for discuss-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 08:33:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvtI-0008Q0-Na for discuss@apps.ietf.org; Tue, 13 Nov 2007 08:33:20 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrvtE-0001gP-EI for discuss@apps.ietf.org; Tue, 13 Nov 2007 08:33:20 -0500 Received: by wa-out-1112.google.com with SMTP id m16so1909983waf for ; Tue, 13 Nov 2007 05:29:41 -0800 (PST) Received: by 10.115.109.1 with SMTP id l1mr71955wam.1194960580680; Tue, 13 Nov 2007 05:29:40 -0800 (PST) Received: by 10.115.48.11 with HTTP; Tue, 13 Nov 2007 05:29:40 -0800 (PST) Message-ID: Date: Tue, 13 Nov 2007 08:29:40 -0500 From: "Mark Baker" To: "Mark Nottingham" Subject: Re: Usefulness of WSDL In-Reply-To: <0D742E59-FA65-4A99-B055-8A50AADA628C@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0D742E59-FA65-4A99-B055-8A50AADA628C@mnot.net> X-Google-Sender-Auth: 0f67dc790a11e7e0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Apps Discuss , Lisa Dusseault X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 11/12/07, Mark Nottingham wrote: > On 10/11/2007, at 7:26 AM, Mark Baker wrote: > > That said, if some spec author wants to use it, I don't see any > > need to prevent them from doing so, so long as the emphasis of the > > spec is on the protocol. > > I disagree. The interop and interpretation problems with WSDL make it > too much of a liability to use in a spec; it will cause more problems > than it solves. > > Even if you plaster warnings that it's non-normative and that the > spec wins, people will still use it to generate their code, and > they'll be stuck with the data binding and interface modelling mess > that results. I hear you, but the alternative seems to be a mandate that it not ever be used, which AFAIK, there's no precedent for. I'd rather its use be evaluated on a case-by-case basis during the review process. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com From discuss-bounces@apps.ietf.org Wed Nov 14 19:09: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 1IsSIb-0007O5-CO; Wed, 14 Nov 2007 19:09:37 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IsSIa-0007Md-2o for discuss-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 19:09:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsSIZ-0007MT-PH for discuss@apps.ietf.org; Wed, 14 Nov 2007 19:09:35 -0500 Received: from mail26-priv.ctv.ca ([199.85.69.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsSIX-00060A-3S for discuss@apps.ietf.org; Wed, 14 Nov 2007 19:09:35 -0500 X-IronPort-AV: E=Sophos;i="4.21,418,1188792000"; d="scan'208";a="55314228" Received: by agcoms01.corp.ctv.ca with Internet Mail Service (5.5.2658.3) id ; Wed, 14 Nov 2007 19:09:29 -0500 Message-ID: From: Trace Bond To: discuss@apps.ietf.org Subject: Re: File metadata format draft Date: Wed, 14 Nov 2007 19:09:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: METS@LOC.gov X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Miguel, Thanks for this draft. I think this is a very important topic! For the past two years, I've been searching for an XML format for describing computer files that I could use for creating catalogs of files for backup purposes. Such a format could be a very useful tool for making, duplicating and sharing vendor-independent file systems, as well as cataloging. There seem to be two barriers to the embrace of some such standard: 1) The tendency of the community to focus on "resources" which may be misguided since most of the "resources" are files. 2) There are already several file metadata XML formats and the community/communities cannot focus on one. Examples: a) the WebDAV format mentioned below b) FLUTE/RFC3926's file description format c) schema from the library community (http://www.loc.gov/standards/mets/) d) the DublinCore/RDF format from the resource-centric SemanticWeb community One of my many questions is.. could this draft be the core of a general-purpose XML format for describing computer files and file systems? Is such a question or format meaningful or possible? Some questions on this draft http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-format-0 0.txt: 1) From page 5: "Each element provides information that is related to a particular instance of the file, rather than the file itself." This is unclear to me.. isn't each instance of the file an actual physical copy/clone? 2) From page 6: "The element indicates the date and time at which the file was last modified." If this is the case, then this element should be in (not ) since it is my understanding that all instances/copies of a file must be identical. Please forgive me for posting to two email forums. Best regards, Trace Bond Vancouver @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ At the moment the integration with the WebDAV properties is not done. I believe this is a topic for discussion. I have here more questions than answers. For example: Do we want to propose a single data format for describing file metadata? The WebDAV properties is already standardized and deployed, whereas the file-data-format draft is not. However, the requirements of both applications are not totally the same. For example, the file data format does not care about the creator, but needs to signal different endpoints (instances) that host the same file. Or can we integrate the WebDAV properties into the file data format? This will effectively create a superset of the WebDAV properties, bt I am not sure it will have a footprint on the implementations, due to the advance state of deployment of WebDAV. Or do we want to continue with two separate paths, perhaps with this mapping that you mentioned? BR, Miguel Cyrus Daboo wrote: Hi Miguel, --On November 12, 2007 9:58:50 PM +0200 Miguel Garcia wrote: I have submitted a draft that defines an XML schema for describing files and associated metadata. I am referring to this draft: http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-forma t-00.txt The background of this draft is as follows: We first submitted a SIP event package for subscribing to changes in files stored in a remote endpoint. The idea is to use SIP to emulate the "shared folder" functionality that is available in common instant messaging and presence clients. A part of the overall function is a format for describing files and associated metadata. At the last IETF meeting, I got a few comments indicating that the data format could be reused by other protocols, namely HTTP, and thus, it should be split out from the draft and discussed in the Apss area. So this is what I am doing. So, the authors would like to get comments and questions about the document. Had a quick look. In the HTTP world, meta-data about files is already covered by WebDAV properties. So the question I have is what, if any, thought has been given to integration with WebDAV. e.g. a lot of elements in your schema have exact equivalents in WebDAV. It might be useful, at a minimum, to define a mapping between your schema and what WebDAV provides. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From discuss-bounces@apps.ietf.org Thu Nov 15 04:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isadw-0005Kq-Km; Thu, 15 Nov 2007 04:04:12 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Isadv-0005IC-6D for discuss-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 04:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isadu-0005HB-Oy for discuss@apps.ietf.org; Thu, 15 Nov 2007 04:04:10 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isadr-0002wD-7x for discuss@apps.ietf.org; Thu, 15 Nov 2007 04:04:10 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAF93ulM023751; Thu, 15 Nov 2007 11:03:59 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 11:03:56 +0200 Received: from [10.144.23.72] ([10.144.23.72]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 11:03:56 +0200 Message-ID: <473C0B7C.8090308@nsn.com> Date: Thu, 15 Nov 2007 11:03:56 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Trace Bond Subject: Re: File metadata format draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 09:03:56.0282 (UTC) FILETIME=[73C9EDA0:01C82766] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: discuss@apps.ietf.org, METS@LOC.gov X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Trace: Thanks for your comments. See some inline discussion. Trace Bond wrote: > Hi Miguel, > Thanks for this draft. I think this is a very important topic! > > For the past two years, I've been searching for an XML format for describing > computer files that I could use for creating catalogs of files for backup > purposes. > Such a format could be a very useful tool for making, duplicating and > sharing vendor-independent file systems, as well as cataloging. > > There seem to be two barriers to the embrace of some such standard: > 1) The tendency of the community to focus on "resources" which may be > misguided since most of the "resources" are files. And as a matter of fact, earlier versions of the draft, which were at that time part of a SIP event package draft, was discussing "resources" rather than "files". We found difficult to get a general format for describing any kind of resource, so we decided to focus on "files", which is our main target. > 2) There are already several file metadata XML formats and the > community/communities cannot focus on one. > Examples: > a) the WebDAV format mentioned below > b) FLUTE/RFC3926's file description format > c) schema from the library community > (http://www.loc.gov/standards/mets/) > d) the DublinCore/RDF format from the resource-centric SemanticWeb > community > > One of my many questions is.. could this draft be the core of a > general-purpose XML format for describing computer files and file systems? That is a good question. Honestly, it seems that creating a generic format that can serve any possible application is a real challenge. Perhaps we should take the approach you suggest... creating a core extensible specification that would be the foundation for describing files. If applications need to express additional characteristics of a file, those could be done through extensions. This has the benefit of easiness of implementing additional applications, once you have implemented the first one. This would also require some sort of commitment from the IETF community on the approach taken. I don't think we are here yet, perhaps this is the first step. > Is such a question or format meaningful or possible? > > Some questions on this draft > http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-format-0 > 0.txt: > 1) From page 5: > "Each element provides information that is related to a > particular instance of the file, rather than the file itself." > This is unclear to me.. isn't each instance of the file an actual physical > copy/clone? That's right. Each instance is a copy of the same size. I'll try to find a better words to describe what the element is. > 2) From page 6: > "The element indicates the date and time at which the > file was last modified." > If this is the case, then this element should be in (not > ) since it is my understanding that all instances/copies of a file > must be identical. Hmm... this is an interesting question, and I have been thinking for a while, but I don't have a straight answer. These are some facts: - If I open a file to edit it and then save it without changes... does the modification date changes? I guess this might depend on the file system. But the idea is: if the file is simply saved with no changes, it should be exactly the same file, right? If we add the to the element, then it would automatically imply it is a different file. Is this the desired behavior? - I want to understand what happens if I receive a file somehow, I store it, but I don't have the modification date. Most likely, the operating system writes a modification date that equals the creation date (I have to verify this point, though). So, if the is part of the element, this file would be different from the same file stored in another endpoint. I think this isn't the desired effect. BR, Miguel > > Please forgive me for posting to two email forums. > Best regards, > Trace Bond > Vancouver > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > At the moment the integration with the WebDAV properties is not done. I > believe this is a topic for discussion. I have here more questions than > answers. For example: > > Do we want to propose a single data format for describing file metadata? The > WebDAV properties is already standardized and deployed, whereas the > file-data-format draft is not. However, the requirements of both > applications are not totally the same. For example, the file data format > does not care about the creator, but needs to signal different endpoints > (instances) that host the same file. > > Or can we integrate the WebDAV properties into the file data format? This > will effectively create a superset of the WebDAV properties, bt I am not > sure it will have a footprint on the implementations, due to the advance > state of deployment of WebDAV. > > Or do we want to continue with two separate paths, perhaps with this mapping > that you mentioned? > > BR, > Miguel > > > Cyrus Daboo wrote: > > Hi Miguel, > > --On November 12, 2007 9:58:50 PM +0200 Miguel Garcia at nsn.com> wrote: > > > > I have submitted a draft that defines an XML schema for > describing files > and associated metadata. I am referring to this draft: > > > http://www.ietf.org/internet-drafts/draft-garcia-app-area-file-data-forma > t-00.txt > > The background of this draft is as follows: We first > submitted a SIP > event package for subscribing to changes in files stored in > a remote > endpoint. The idea is to use SIP to emulate the "shared > folder" > functionality that is available in common instant messaging > and presence > clients. A part of the overall function is a format for > describing files > and associated metadata. > > At the last IETF meeting, I got a few comments indicating > that the data > format could be reused by other protocols, namely HTTP, and > thus, it > should be split out from the draft and discussed in the Apss > area. So > this is what I am doing. > > So, the authors would like to get comments and questions > about the > document. > > > > Had a quick look. In the HTTP world, meta-data about files is > already covered by WebDAV properties. So the question I have is what, if > any, thought has been given to integration with WebDAV. e.g. a lot of > elements in your schema have exact equivalents in WebDAV. It might be > useful, at a minimum, to define a mapping between your schema and what > WebDAV provides. > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From discuss-bounces@apps.ietf.org Thu Nov 15 17:03: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 1Ismnx-0003kW-RT; Thu, 15 Nov 2007 17:03:21 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ismnw-0003fk-BX for discuss-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 17:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ismnv-0003bN-GC for discuss@apps.ietf.org; Thu, 15 Nov 2007 17:03:19 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ismnr-0008Sz-8D for discuss@apps.ietf.org; Thu, 15 Nov 2007 17:03:19 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 526FB142207; Thu, 15 Nov 2007 14:03:15 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky3+m8MsxXYB; Thu, 15 Nov 2007 14:03:09 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BCB2F1421FC; Thu, 15 Nov 2007 14:03:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Apps Area Architecture Workshop announcement Date: Thu, 15 Nov 2007 14:03:07 -0800 To: Apps Discuss , iesg@ietf.org, IAB IAB X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Feb 11 and 12, there will be an Applications Area Architecture workshop somewhere in the Bay Area. We hope to nail down a venue once we've got a better idea of attendance. We are going to look for a host, but if there are a few expenses not covered, we may ask for a few 100$ attendance fee. If we need to charge a small fee we'll ask in advance of the actual meeting. Position papers are required of all attendees by Dec 14. These should be a few pages of text on some topic related to Applications area architectural issues. Since the group of attendees is expected to span HTTP and AtomPub, email, IM, calendaring, directories and more, issues should be of interest to more than one of these groups. Some existing Applications architecture "modules" that already are reused include SASL, URLs, MIME types, XML and XML schemas and namespaces, HTTP as a substrate, TLS, ABNF, BEEP. A position paper could describe a problem or make a proposal to solve a problem. The paper could be a prelude to an I-D of any kind or to a WG charter, or might simply educate and persuade. An ideal position paper would seed new work or make progress towards solving a problem that would benefit Apps protocol designers, implementors or users. Participants may send position papers directly to Lisa and Chris, although you can send position papers directly to the Apps Discuss list (we'll be circulating the papers publicly anyway). Since the due date for papers is Dec 14, if you'd like to flesh out an idea, the Vancouver IETF meeting might be a handy place to grab people and do so. In advance of Dec 14, we'd still appreciate early RSVPs. Lisa From discuss-bounces@apps.ietf.org Mon Nov 19 05:18: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 1Iu3hn-0000HG-KI; Mon, 19 Nov 2007 05:18:15 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iu3hn-0000H8-78 for discuss-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 05:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3hm-0000H0-TN for discuss@apps.ietf.org; Mon, 19 Nov 2007 05:18:14 -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 1Iu3hj-00084u-MH for discuss@apps.ietf.org; Mon, 19 Nov 2007 05:18:14 -0500 X-IronPort-AV: E=Sophos;i="4.21,435,1188792000"; d="scan'208";a="79732531" 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; 19 Nov 2007 05:18:12 -0500 X-IronPort-AV: E=Sophos;i="4.21,435,1188792000"; d="scan'208";a="131994832" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Nov 2007 05:18:09 -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: FW: [YANG] YANG tools etc Date: Mon, 19 Nov 2007 11:18:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [YANG] YANG tools etc Thread-Index: AcgqklZ5paDYqgEwSeWf9Ssb+q3Z7QAAxnkQ From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 =20 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Monday, November 19, 2007 11:56 AM To: yang@ietf.org Subject: [YANG] YANG tools etc Hi, We have set up a site dedicated to YANG, http://www.yang-central.org There you can find some free tools, examples, a tutorial etc. /martin From discuss-bounces@apps.ietf.org Tue Nov 27 00:48:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwtJN-0001mh-D8; Tue, 27 Nov 2007 00:48:45 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IwtJM-0001kb-7F for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 00:48:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwtJL-0001jh-T2 for discuss@apps.ietf.org; Tue, 27 Nov 2007 00:48:43 -0500 Received: from el-out-1112.google.com ([209.85.162.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwtJI-0005KA-2j for discuss@apps.ietf.org; Tue, 27 Nov 2007 00:48:43 -0500 Received: by el-out-1112.google.com with SMTP id n30so305353elf for ; Mon, 26 Nov 2007 21:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=iRLdYLSg0GIav+z2xpBTjy3gik0A7aDQA37NK0AycBY=; b=hsBWaLYWCgInu6OCT4rvPud/E9yKg1wpGkR8T2e/nUB5CiFhffcCpJkm6a0+9daVwxZPnmq2yajxeY5cwy7hYTBmedhvg68hRS0GRrUaOCGVrNze/k8SD+n13VML50eKphtNcfCsnk+omnGNg6ZETc1vI8TlgtC5wSHGuPYhS1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=OyKCutfaQHypqsQJ/A4buSj6Uzr0cXwgDzhMIrtpowR5qR6FJ5MEZvID+GIJOevYBbjUNIG9DGmRywh6OrLCY8C8OrNYTlImYGnMbuXRQc/J6bqkcapDRUsC96TF1GUgBST3fQL9UJXzlC+Xhr4cumI8tBjBw9ZjA4rMI7aDHLc= Received: by 10.143.161.3 with SMTP id n3mr749895wfo.1196142518093; Mon, 26 Nov 2007 21:48:38 -0800 (PST) Received: by 10.142.214.15 with HTTP; Mon, 26 Nov 2007 21:48:37 -0800 (PST) Message-ID: <953beacc0711262148me3c119coebc756a44322b6e9@mail.gmail.com> Date: Mon, 26 Nov 2007 21:48:37 -0800 From: "Rohan Mahy" To: discuss@apps.ietf.org Subject: analysis of YANG vs. RELAX NG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8624_3260125.1196142518017" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_8624_3260125.1196142518017 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and thought immediately that all of the problems the draft is trying to address looked very suitable to use RELAX NG as a schema language. Looking at section F.2(Why not RELAX NG) I did not see any specific examples motivating the apparently contradictory statements that Relax is not expressive enough and Relax is too expressive. Below is a comparison of YANG integral types and common idioms to integral types/idioms available in RELAX NG. I seems pretty clear to me that expressing any of the idioms in YANG should be straightforward in RELAX NG and very easy to read and write. Writing a schema language is a lot of work, and I can't imagine the IETF designing one that would only be used by NETCONF. RELAX NG has existing tools and parsers, has additional integral types (ex: URI, dates, and times), and was written by a large group of folks who have tons of experience designing schema languages. thanks, -rohan BUILT IN TYPES yang: relax: int8 byte int16 short int32 int int64 long uint8 unsignedByte uint16 unsignedShort uint32 unsignedInt uint64 unsignedLong float32 float float64 double string string boolean boolean binary base64Binary empty anyxml union or enumeration, bits foo bar keyref and instance-identifier are probably better served by referencing an 'id' attribute and using the 'ID' type, but doing exactly what is done in YANG could still be handled easily using an anyURI restricted to be an XPath expression. Below, I also show examples of the YANG concepts of leaf node, leaf-list, container, and list expressed in YANG, how it would be expressed in NETCONF, and expressed in RELAX NG. LEAF yang: leaf host-name { type string; description "Hostname for this system"; } netconf: my.example.com relax: Hostname for this system LEAF-LIST yang: leaf-list domain-search { type string; } netconf: example.com example.org relax: CONTAINER yang: container system { container login { leaf message { type string; } } } netconf: Hello Dave relax: LIST yang: list user { key "name"; leaf name { type string; } leaf class { type string; } } netconf: alice human cheshire cat relax: name ------=_Part_8624_3260125.1196142518017 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and thought immediately that all of the problems the draft is trying to address looked very suitable to use RELAX NG as a schema language.  Looking at section F.2 (Why not RELAX NG) I did not see any specific examples motivating the apparently contradictory statements that Relax is not expressive enough and Relax is too expressive.

Below is a comparison of YANG integral types and common idioms to integral types/idioms available in RELAX NG. I seems pretty clear to me that expressing any of the idioms in YANG should be straightforward in RELAX NG and very easy to read and write. 

Writing a schema language is a lot of work, and I can't imagine the IETF designing one that would only be used by NETCONF. RELAX NG has existing tools and parsers, has additional integral types (ex: URI, dates, and times), and was written by a large group of folks who have tons of experience designing schema languages.

thanks,
-rohan


BUILT IN TYPES
yang:    relax:
int8     byte
int16    short
int32    int
int64    long
uint8    unsignedByte
uint16   unsignedShort
uint32   unsignedInt
uint64   unsignedLong
float32  float
float64  double

string   string
boolean  boolean
binary   base64Binary

empty    <empty/>
anyxml   <anyName/>
union    <choice>  or    <interleaved>

enumeration, <text><choice>
bits           <value>foo</value>
               <value>bar</value>
             </choice></text>

keyref and instance-identifier are probably better served by referencing an 'id' attribute and using the 'ID' type, but doing exactly what is done in YANG could still be handled easily using an anyURI restricted to be an XPath expression.


Below, I also show examples of the YANG concepts of leaf node, leaf-list, container, and list expressed in YANG, how it would be expressed in NETCONF, and expressed in RELAX NG.


LEAF
yang:
leaf host-name {
  type string;
  description "Hostname for this system";
}

netconf:
<host-name>my.example.com</host-name>

relax:
<element name="host-name">
  <other:description>Hostname for this system</other:description>
  <data type="string"/>
</element>

LEAF-LIST
yang:
leaf-list domain-search {
  type string;
}

netconf:
<domain-search>example.com</domain-search>
<domain-search> example.org</domain-search>

relax:
<zeroOrMore> <!-- could be oneOrMore instead -->
  <element name="domain-search">
    <text/>  <!-- this is an alias for data type="string" -->
  </element>
</zeroOrMore>

CONTAINER
yang:
container system {
  container login {
    leaf message {
      type string;
    }
  }
}

netconf:
<system>
  <login>
    <message>Hello Dave</message>
  </login>
</system>

relax:
<element name="system">
  <element name="login">
    <element name="message">
      <text/>
    </element>
  </element>
</element>


LIST
yang:
list user {
  key "name";
  leaf name {
    type string;
  }
  leaf class {
    type string;
  }
}

netconf:
<user>
  <name>alice</name>
  <class>human</class>
</user>
<user>
  <name>cheshire</name>
  <class>cat</class>
</user>

relax:
<zeroOrMore>
  <element name="user">
    <other:key>name</other:key>
    <element name="name">
      <text/>
    </element>
    <element name="class">
      <text/>
    </element>
  </element>
</zeroOrMore>


------=_Part_8624_3260125.1196142518017-- From discuss-bounces@apps.ietf.org Tue Nov 27 02:33:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwux9-00048Q-D1; Tue, 27 Nov 2007 02:33:55 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iwux8-00048F-6V for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 02:33:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwux7-000487-T6 for discuss@apps.ietf.org; Tue, 27 Nov 2007 02:33:53 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwux2-0005PN-Tj for discuss@apps.ietf.org; Tue, 27 Nov 2007 02:33:53 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8553D20E08 for ; Tue, 27 Nov 2007 08:32:37 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-6d-474bc8150f6a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6C2CA20E00 for ; Tue, 27 Nov 2007 08:32:37 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 08:32:37 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 08:32:36 +0100 From: David Partain Organization: Ericsson AB To: discuss@apps.ietf.org Subject: Some background on YANG Date: Tue, 27 Nov 2007 08:32:35 +0100 User-Agent: KMail/1.9.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711270832.36138.david.partain@ericsson.com> X-OriginalArrivalTime: 27 Nov 2007 07:32:36.0913 (UTC) FILETIME=[AEC99210:01C830C7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi all, As some of you may know, a group of people proposed a BOF for the upcoming IETF on a new modeling language that we call YANG. The BOF proposal can be found at http://www1.ietf.org/mail-archive/web/yang/current/msg00002.html YANG is explicitly designed to be used for configuration of network devices using NETCONF. The BOF proposal was rejected by the IESG/IAB but we were asked to take the discussion of YANG to the APPS area and will be doing a brief presentation at the meeting on Monday next week in the Applications Area Open Meeting at 9:00 in Salon 3. This mail is to give some background on where YANG comes from in order to get the discussion going _before_ the meeting. NETCONF lacks an interoperable, standardized way to create models for configuration data. In SNMP terms (if you're familiar with those), we have no SMI to use to create MIBs. This means that today all NETCONF tools have to invent their own language to define configuration models and a third-party "manager" has no prayer of handling with all of the different languages used for models. In SNMP, _any_ manager can _at least_ parse a model and do rudimentary management tasks simply given access to the MIB document itself. We're a long way from that with NETCONF and YANG is intended to take us closer to that goal for NETCONF. A few IETFs ago, I initiated a dialog with one NETCONF vendor (Tail-F Systems) and asked them if they'd be interested in working together on a common language. That dialog soon included a group of interested people who share the belief that this is a serious problem that threatens to slow uptake of NETCONF, perhaps make it irrelevant. Since we all think that NETCONF has great potential to improve a rather ugly O&M picture (where configuration management is largely the domain of proprietary solutions), we wanted to do something about that. The list of people involved, all of whom have been working with NETCONF a long time, can be found in the draft, which is at http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt The IESG/IAB decision to reject the BOF was largely based on a "not-invented -here" argument, meaning that there was a perception that we were inventing something just because we could, that the new language was not really necessary, and that we should use XSD or RelaxNG instead. We clearly believe that there are good reasons _not_ to use existing languages for configuration modeling in NETCONF and I hope a dialog during this week and during the IETF will help understand why we believe that. In initial discussions among NETCONF implementors, an interesting pattern emerged. It turned out that in at least three cases, the implmentor had first started by trying to use XSD for modeling and had soon discovered that users were having great trouble using it. Then there was a brief walk into RelaxNG, before all the companies in question decided that they needed to have something else, so they invented their own language. This wasn't something that happened overnight or without serious consideration. Our first priority when designing YANG has been the reader of the model. We believe it is critical that a human (who today uses a CLI) MUST be able to grok a model by reading it, without tools or having to read a book first. XSD, in our opinion, is not readable by (almost any) humans. Furthermore, history in the NETCONF working group clearly demonstrates that humans are _very_ resistant to learning XSD and are not very good at debugging it. Bugs have been found in the XSD used in the NETCONF protocol specification after RFC publication after years of work in the working group.... There are a number of reasons why we think YANG is the right way to go _for modeling configuration data for NETCONF_. It was not, and still is not, our intention that YANG should be used as a general modeling language by the IETF. YANG is intended to be specific to NETCONF needs, by design does not support arbitrary XML instance documents, and has many features specific to NETCONF and derived from 15 years of experience with the SMI data modeling language for SNMP. Network configuration is almost completely proprietary today. The only possible way to change that is for vendors to agree on the common knobs and how vendor knobs 'play nice' with standard knobs. Discussion of data models within a WG context is even more critical than usual in this case. We don't think this is going to happen without a language that people understand, which supports all the real needs of standards and vendor-based configuration. While we couldn't get it in advance of the -00 deadline, we'll publish a "draft" on http://www.yang-central.org which makes a case for using YANG rather than an existing language. We'll send a pointer to that document as soon as it's available (hopefully today or tomorrow). Clearly, we don't believe XSD's place is in defining the configuration models. That doesn't mean that we think XSD has no place in the NETCONF picture. We believe that XSD has a very important place, particularly in applications development. For this very reason, YANG models can be translated into both an XML representation and XSD. Tools already exist to do this. Cheers, David Partain From discuss-bounces@apps.ietf.org Tue Nov 27 07:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwz9S-0008Eb-QX; Tue, 27 Nov 2007 07:02:54 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iwz9R-00085Z-G1 for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 07:02:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwz9R-00085B-5f for discuss@apps.ietf.org; Tue, 27 Nov 2007 07:02:53 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwz9Q-0006wm-HT for discuss@apps.ietf.org; Tue, 27 Nov 2007 07:02:53 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id B533A1B80C3; Tue, 27 Nov 2007 13:02:50 +0100 (CET) Date: Tue, 27 Nov 2007 13:03:55 +0100 (CET) Message-Id: <20071127.130355.18118495.mbj@tail-f.com> To: rohan.mahy@gmail.com Subject: Re: analysis of YANG vs. RELAX NG From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, "Rohan Mahy" wrote: > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and > thought immediately that all of the problems the draft is trying to > address looked very suitable to use RELAX NG as a schema language. > Looking at section F.2 (Why not RELAX NG) I did not see any specific > examples motivating the apparently contradictory statements that Relax > is not expressive enough and Relax is too expressive. What we mean with this is that generic XML schema languages such as RelaxNG and XSD are designed to specify the grammar for (almost) any XML instance document. For example they both support mixed content and XML attributes, neither of which we use in YANG. You could of course just state that these constructs MUST NOT be used. None of these languages support important configuration management concepts like default values (XSD has a default construct, but it is not the same); you cannot see if a parameter represents configuration or state data (since it's very domain specific). In RelaxNG there is not support (by design) for integrity contraints and keys. None of the languages have support for specific augmentation (this is important e.g. for vendors to add vendor-specific stuff to standard data models). We also note in the draft that both languages are extensible, and with an extensible language you can add whatever you want. All this means that the existing tools might not be that simple to use. These tools are not aware of any restrictions on the usage imposed by NETCONF, and they do not understand the NETCONF-specific extensions. Another question regarding existing tools is what exactly these tools are supposed to be used for? Probably not instance document (NETCONF PDU) validation, unless all elements are defined as optional, since e.g. in an edit-config request you just include the elements you want to modify. > keyref and instance-identifier are probably better served by referencing > an 'id' attribute and using the 'ID' type The problem with the ID type is that its value is global to a document. If the document is the entire configuration datastore, all IDs will have to be unique. Since you can reference any key (or maybe even any leaf), every key (or leaf) will have to have it's own unique ID. This won't scale and would be very difficult to maintain. > Below, I also show examples of the YANG concepts of leaf node, > leaf-list, container, and list expressed in YANG, how it would be > expressed in NETCONF, and expressed in RELAX NG. Here's another one: in module foo: rpc my-rpc { input { leaf foo { type string; } } output { leaf-list bar { type int32; } leaf baz { type int32; } } } in module bar: augment /foo:my-rpc/foo:output { leaf data { type int32; } } How would this translate to RelaxNG? /martin From discuss-bounces@apps.ietf.org Tue Nov 27 07:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwzoj-0000Ba-6O; Tue, 27 Nov 2007 07:45:33 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iwzoi-0000BT-Uj for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 07:45:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwzoi-0000BC-Kf for discuss@apps.ietf.org; Tue, 27 Nov 2007 07:45:32 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwzoi-0003iS-Ba for discuss@apps.ietf.org; Tue, 27 Nov 2007 07:45:32 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id ABF953C1D9; Tue, 27 Nov 2007 13:45:29 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05837-01-7; Tue, 27 Nov 2007 13:45:29 +0100 (CET) Received: from k2.mnt.se (dhcp-wavelan-vo-7.publik.su.se [193.11.30.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 616903C0E6; Tue, 27 Nov 2007 13:45:29 +0100 (CET) Message-ID: <474C116A.1080001@it.su.se> Date: Tue, 27 Nov 2007 13:45:30 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> In-Reply-To: <20071127.130355.18118495.mbj@tail-f.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.083 tagged_above=-99 required=7 tests=[AWL=0.229, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > > How would this translate to RelaxNG? > > > > /martin > > > I don't know about RelaxNG, but it is pretty close to OWL. Apart from the C-like syntax (which might be important to some) the example suggests a modeling language which supports classes, packages, properties (possibly associations?) and a form of multiple inheritance. While I am as happy as the next guy that we won't be seeing RFCs with XMI in them anytime soon I am curious as to why something like OWL isn't a strong candidate for something like this. Is it just "anti-XML" or is there something more substantial to it? I'm looking foward to the BOF. Cheers Leif From discuss-bounces@apps.ietf.org Tue Nov 27 07:47: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 1Iwzqe-0002RA-Hg; Tue, 27 Nov 2007 07:47:32 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iwzqd-0002Ic-2I for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 07:47:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwzqc-0002Fq-Nb for discuss@apps.ietf.org; Tue, 27 Nov 2007 07:47:30 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwzqa-0003y7-M1 for discuss@apps.ietf.org; Tue, 27 Nov 2007 07:47:30 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16B5F8A123; Tue, 27 Nov 2007 13:47:28 +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 00429-01-6; Tue, 27 Nov 2007 13:47:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFB245ACD6; Tue, 27 Nov 2007 13:47:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8B7893F6E7D; Tue, 27 Nov 2007 13:47:12 +0100 (CET) Date: Tue, 27 Nov 2007 13:47:12 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071127124712.GA27378@elstar.local> References: <20071127.130355.18118495.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071127.130355.18118495.mbj@tail-f.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: 52f7a77164458f8c7b36b66787c853da Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, Nov 27, 2007 at 01:03:55PM +0100, Martin Bjorklund wrote: > "Rohan Mahy" wrote: > > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and > > thought immediately that all of the problems the draft is trying to > > address looked very suitable to use RELAX NG as a schema language. > > Looking at section F.2 (Why not RELAX NG) I did not see any specific > > examples motivating the apparently contradictory statements that Relax > > is not expressive enough and Relax is too expressive. > > What we mean with this is that generic XML schema languages such as > RelaxNG and XSD are designed to specify the grammar for (almost) any > XML instance document. For example they both support mixed content > and XML attributes, neither of which we use in YANG. You could of > course just state that these constructs MUST NOT be used. It might be important form some people on this list who are not too heavily involved in the network management activities of the IETF to know some of the history and experience with the IETF's SMI data modeling language very widely used to write MIB modules (within the IETF, by other SDOs, and a large number of device vendors; in 2005, I counted ~170 IETF modules, ~480 Cisco modules, and ~100 Juniper modules with a rough total of 32,000 object definitions [1]). Back in the old times when SNMP came up, the language of the day was called ASN.1. When the SMI became formalized (after it turned out that plain textual descriptions are too difficult to be understood by tools), something now called an adapted subset of ASN.1 was created. The idea was to take ASN.1, forbit those constructs that are somehow not useful in the SNMP context, and add some new constructs via ASN.1 macros that carry the stuff needed for SNMP data modeling. Since then, the SMI has become pretty much its own language and almost all SNMP tools I have seen in the last decade actually do not use generic ASN.1 parsers to parse MIB modules. There are several reasons for this which I will not go into here. The experience, however, has been that creating an "adapted subset" of ASN.1 (1987) turned out to be no money or energy saver and there are still today questions popping up whether some constructs are legal which you can't easily answer since you need the 1987 spec of ASN.1 and then find the "right" interpretation of it. (Note that the whole macro notation meanwhile got dropped from ASN.1.) I think it is important to consider the long term implications of creating adapted subsets of other languages in the IETF. NETCONF needs a data modeling language and framework that must be long term stable and easy to use. I personally believe that designing a domain specific language for NETCONF has large benefits since we can optimize the language for what is needed for NETCONF, make the language simple to read, ensure the language works well in the IETF process (max 76 ASCII character lines, compact for plain text email discussions), and we can have long term stability and full chance control in the IETF. /js [1] J. Schoenwaelder, Characterization of SNMP MIB Modules, Proc. 9th IFIP/IEEE International Symposium on Integrated Network Management, 2005 [2] K. McCloghrie, D. Perkins, J. Schoenwaelder, Structure of Management Information Version 2 (SMIv2), STD0058, April 1999 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Tue Nov 27 11:37: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 1Ix3RX-0006DW-QA; Tue, 27 Nov 2007 11:37:51 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix3RW-0006D5-MT for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3RW-0006Cp-3S for discuss@apps.ietf.org; Tue, 27 Nov 2007 11:37:50 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3RT-0003mN-Oy for discuss@apps.ietf.org; Tue, 27 Nov 2007 11:37:50 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6EF58A14E; Tue, 27 Nov 2007 17:37:46 +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 25947-01-10; Tue, 27 Nov 2007 17:37:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D2FA8A17B; Tue, 27 Nov 2007 17:37:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ED11C3F730D; Tue, 27 Nov 2007 17:37:27 +0100 (CET) Date: Tue, 27 Nov 2007 17:37:27 +0100 From: Juergen Schoenwaelder To: Leif Johansson Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071127163727.GA27816@elstar.local> References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474C116A.1080001@it.su.se> 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: b19722fc8d3865b147c75ae2495625f2 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, Nov 27, 2007 at 01:45:30PM +0100, Leif Johansson wrote: > I don't know about RelaxNG, but it is pretty close to OWL. Apart from > the C-like syntax (which might be important to some) the example > suggests a modeling language which supports classes, packages, > properties (possibly associations?) and a form of multiple inheritance. > > While I am as happy as the next guy that we won't be seeing RFCs > with XMI in them anytime soon I am curious as to why something like > OWL isn't a strong candidate for something like this. Is it just "anti-XML" > or is there something more substantial to it? NETCONF uses XML for data encoding and is this is just fine. YANG is a domain specific data modeling language designed to support NETCONF (no more, no less). The YANG language reflects many years of experience with other network management data modeling languages in the IETF and proprietary languages created by NETCONF implementors to support their implementations (after figuring out that creating adapted subset languages did not work well in their companies or for their customers). While YANG clearly lacks features such as multiple inheritance or support for semantic web reasoning engines, we feel that it helps a lot in writing understandable and extensible NETCONF data models and in addition it can enjoy long-term predictability and stability. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Tue Nov 27 11:54:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3i2-0005kW-RF; Tue, 27 Nov 2007 11:54:54 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix3i1-0005e3-N1 for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:54:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3i1-0005aT-9q for discuss@apps.ietf.org; Tue, 27 Nov 2007 11:54:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3hx-0007Sg-MB for discuss@apps.ietf.org; Tue, 27 Nov 2007 11:54:53 -0500 Received: from [165.227.249.200] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lARGslGt060704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Nov 2007 09:54:48 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <953beacc0711262148me3c119coebc756a44322b6e9@mail.gmail.com> References: <953beacc0711262148me3c119coebc756a44322b6e9@mail.gmail.com> Date: Tue, 27 Nov 2007 08:54:45 -0800 To: discuss@apps.ietf.org From: Paul Hoffman Subject: Re: analysis of YANG vs. RELAX NG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 9:48 PM -0800 11/26/07, Rohan Mahy wrote: >Writing a schema language is a lot of work, and I can't imagine the >IETF designing one that would only be used by NETCONF. RELAX NG has >existing tools and parsers, has additional integral types (ex: URI, >dates, and times), and was written by a large group of folks who >have tons of experience designing schema languages. FWIW, I bought a copy of the book "RELAX NG" by van der Vlist and found it to be quite easy to understand. After reading it (well, about half of it), I found RELAX NG much less threatening than after reading a bunch of web resources. From discuss-bounces@apps.ietf.org Tue Nov 27 13:37:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5Jb-0007a4-Ba; Tue, 27 Nov 2007 13:37:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix5Ja-0007Zj-34 for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:37:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5JZ-0007ZX-PN for discuss@apps.ietf.org; Tue, 27 Nov 2007 13:37:45 -0500 Received: from smtp-bedford.mitre.org ([192.160.51.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix5JW-0002bX-Da for discuss@apps.ietf.org; Tue, 27 Nov 2007 13:37:45 -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 lARIbfQn008923 for ; Tue, 27 Nov 2007 13:37:42 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 7DDD0BF95 for ; Tue, 27 Nov 2007 13:37:41 -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 lARIbfKR008909; Tue, 27 Nov 2007 13:37:41 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 13:37:40 -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: analysis of YANG vs. RELAX NG Date: Tue, 27 Nov 2007 13:37:40 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02490FAD@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: analysis of YANG vs. RELAX NG Thread-Index: AcgxFkm8xpmXqH7YRku5GjH2XA4i/gADjGZQ References: <953beacc0711262148me3c119coebc756a44322b6e9@mail.gmail.com> From: "Natale, Bob" To: "Paul Hoffman" X-OriginalArrivalTime: 27 Nov 2007 18:37:40.0966 (UTC) FILETIME=[9774D860:01C83124] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Paul, And online access to the book is available via http://books.xmlschemata.org/relaxng/. (I have not checked whether any newer print version of the book might be available.) Cheers, BobN -----Original Message----- From: Paul Hoffman [mailto:phoffman@imc.org]=20 Sent: Tuesday, November 27, 2007 11:55 AM To: discuss@apps.ietf.org Subject: Re: analysis of YANG vs. RELAX NG At 9:48 PM -0800 11/26/07, Rohan Mahy wrote: >Writing a schema language is a lot of work, and I can't imagine the=20 >IETF designing one that would only be used by NETCONF. RELAX NG has=20 >existing tools and parsers, has additional integral types (ex: URI,=20 >dates, and times), and was written by a large group of folks who=20 >have tons of experience designing schema languages. FWIW, I bought a copy of the book "RELAX NG" by van der Vlist and=20 found it to be quite easy to understand. After reading it (well,=20 about half of it), I found RELAX NG much less threatening than after=20 reading a bunch of web resources. From discuss-bounces@apps.ietf.org Tue Nov 27 14:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6Vu-0002mY-Dv; Tue, 27 Nov 2007 14:54:34 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix6Vt-0002ld-AZ for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:54:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6Vt-0002lG-0M for discuss@apps.ietf.org; Tue, 27 Nov 2007 14:54:33 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix6Vq-0002qe-OC for discuss@apps.ietf.org; Tue, 27 Nov 2007 14:54:32 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30FD8142206; Tue, 27 Nov 2007 11:54:31 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhKZILDsweIn; Tue, 27 Nov 2007 11:54:25 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B6C6142204; Tue, 27 Nov 2007 11:54:25 -0800 (PST) In-Reply-To: <20071127163727.GA27816@elstar.local> References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se> <20071127163727.GA27816@elstar.local> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: analysis of YANG vs. RELAX NG Date: Tue, 27 Nov 2007 11:54:23 -0800 To: j.schoenwaelder@jacobs-university.de X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: discuss@apps.ietf.org, Leif Johansson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Another question to answer, is why is having a data model (an ontology) not enough? The question of needing a standard data model must be separated from the need for a custom modeling language. Some of the justifications I've seen so far for a modeling language have really been justifying only a standard data model. Of course using XML as the data format doesn't, by itself, give enough of a common data model for 3rd-party NetConf tools to understand arbitrary data. NetConf probably does need a common data model, perhaps defining how IDs are expressed and what a container is, what is a netconf "object" that can be operated on. But a common data model does not need to depend on a modeling language at all. Put it differently: a sufficiently strong common data model can work with multiple modeling languages without harming interoperability. Thus, having a standard data model that is independent of the modeling language can be a real win for clarity and robustness and somewhat more proof against changing stylistic preferences. The commonest approach for IETF protocols that deal with an ontology is to define the data model in English, limiting the ways the data can be expressed to something that becomes essentially self- describing (the name of a new thing/object, and its contents or value, can be derived from the document without seeing a specific schema). LDAP is one of the clearest examples of this. An LDAP agent can handle custom content because it follows the expected data model. There's no need, in LDAP, for a special language to describe new attributes. The iCalendar and vCard formats are the same. SNMP is really different in having a special language to learn, and using that in specs. My experience with description languages or other formalizations is that these often take the place of proper specification. Authors think that they are done when they've written the code that describes the format. However, the most important aspect to a new standard schema is usually what it *means*. Lisa On Nov 27, 2007, at 8:37 AM, Juergen Schoenwaelder wrote: > On Tue, Nov 27, 2007 at 01:45:30PM +0100, Leif Johansson wrote: > >> I don't know about RelaxNG, but it is pretty close to OWL. Apart from >> the C-like syntax (which might be important to some) the example >> suggests a modeling language which supports classes, packages, >> properties (possibly associations?) and a form of multiple >> inheritance. >> >> While I am as happy as the next guy that we won't be seeing RFCs >> with XMI in them anytime soon I am curious as to why something like >> OWL isn't a strong candidate for something like this. Is it just >> "anti-XML" >> or is there something more substantial to it? > > NETCONF uses XML for data encoding and is this is just fine. > > YANG is a domain specific data modeling language designed to support > NETCONF (no more, no less). The YANG language reflects many years of > experience with other network management data modeling languages in > the IETF and proprietary languages created by NETCONF implementors to > support their implementations (after figuring out that creating > adapted subset languages did not work well in their companies or for > their customers). > > While YANG clearly lacks features such as multiple inheritance or > support for semantic web reasoning engines, we feel that it helps a > lot in writing understandable and extensible NETCONF data models and > in addition it can enjoy long-term predictability and stability. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > From discuss-bounces@apps.ietf.org Tue Nov 27 17:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8kG-0002zD-54; Tue, 27 Nov 2007 17:17:32 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix8kE-0002z3-KB for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 17:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8kE-0002yR-AG for discuss@apps.ietf.org; Tue, 27 Nov 2007 17:17:30 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix8kC-00063F-FP for discuss@apps.ietf.org; Tue, 27 Nov 2007 17:17:30 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E7930142206 for ; Tue, 27 Nov 2007 14:17:28 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEtLdGIZnoSV for ; Tue, 27 Nov 2007 14:17:23 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 49275142203 for ; Tue, 27 Nov 2007 14:17:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <178C64E1-7F99-4C19-90C8-CC9B7B6F9A62@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-8-998793786 References: From: Lisa Dusseault Subject: Fwd: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard Date: Tue, 27 Nov 2007 14:17:22 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-8-998793786 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI Begin forwarded message: > From: The IESG > Date: November 26, 2007 5:32:59 PM PST > To: IETF-Announce > Subject: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer > Protocol) to Draft Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from an individual submitter to > consider > the following document: > > - 'Simple Mail Transfer Protocol ' > as a Draft Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2007-12-24. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-06.txt > > Implementation Report can be accessed at > http://www.ietf.org/IESG/implementation.html > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=13354&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-8-998793786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI

Begin = forwarded message:

From: = The IESG <iesg-secretary@ietf.org>
Date: November 26, 2007 5:32:59 PM = PST
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Last Call: draft-klensin-rfc2821bis = (Simple Mail Transfer=A0 = Protocol) to Draft Standard=A0
Reply-To: = ietf@ietf.org

The = IESG has received a request from an individual submitter to = consider
the following = document:

- 'Simple Mail Transfer Protocol '
=A0=A0 = <draft-klensin-rfc2821bis-06.txt> as a Draft = Standard

The IESG plans to make a decision in the next few = weeks, and solicits
final comments on this = action.=A0 Please send = substantive comments to the
ietf@ietf.org mailing lists by = 2007-12-24. Exceptionally,=A0
comments = may be sent to iesg@ietf.org = instead. In either case, please=A0
retain = the beginning of the Subject line to allow automated sorting.

The file = can be obtained via

Implementation Report can be accessed at


IESG discussion can be tracked via


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=
= --Apple-Mail-8-998793786-- From discuss-bounces@apps.ietf.org Tue Nov 27 18:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9UD-0008Ve-9M; Tue, 27 Nov 2007 18:05:01 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix9UB-0008VR-P0 for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:04:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9UB-0008VI-FK for discuss@apps.ietf.org; Tue, 27 Nov 2007 18:04:59 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9U9-0001lj-Sl for discuss@apps.ietf.org; Tue, 27 Nov 2007 18:04:59 -0500 Received: by wr-out-0506.google.com with SMTP id 70so956264wra for ; Tue, 27 Nov 2007 15:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=UX64pti1R4WYu7zniMlFjhj7eBCrdC42KGUM/5o8hcE=; b=n8KGRYiKFqRDf2/nog5s0f9J6VcpOw/1olYyIrAMNE7BQ3mH8a7jpBDAUOt+tK6AOWuv5SbHss10uW9GKj6rO5QrLtcdTTfaVWC28H6ZmuJ3mBcDMuiBi3+fNoRR4u1qoz4O1yelYexts13HQ3O4bJhPgqsy+Ith4V1x5p5c5bM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NxVFSVLDZzSUSJoM17yyqoCApXqjlJPK5UTq7ih4ldB+z/rvTxWPzV+gbEdQuhpQ1PBX9BVaqRr6jH4tmkOTmKycD7QkdMQT8xIWDENjLTIbFuGJsj3dqR415+3keZWvVAqZYfXpSXE50K4UZ+E46G18FCRqXRbjF79ZDGD4IIQ= Received: by 10.142.215.5 with SMTP id n5mr1293651wfg.1196204693338; Tue, 27 Nov 2007 15:04:53 -0800 (PST) Received: by 10.142.214.15 with HTTP; Tue, 27 Nov 2007 15:04:53 -0800 (PST) Message-ID: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> Date: Tue, 27 Nov 2007 15:04:53 -0800 From: "Rohan Mahy" To: "Martin Bjorklund" Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <20071127.130355.18118495.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_599_33550710.1196204693324" References: <20071127.130355.18118495.mbj@tail-f.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_599_33550710.1196204693324 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Martin, More comments inline. On Nov 27, 2007 4:03 AM, Martin Bjorklund wrote: > Hi, > > "Rohan Mahy" wrote: > > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and > > thought immediately that all of the problems the draft is trying to > > address looked very suitable to use RELAX NG as a schema language. > > Looking at section F.2 (Why not RELAX NG) I did not see any specific > > examples motivating the apparently contradictory statements that Relax > > is not expressive enough and Relax is too expressive. > > What we mean with this is that generic XML schema languages such as > RelaxNG and XSD are designed to specify the grammar for (almost) any > XML instance document. For example they both support mixed content > and XML attributes, neither of which we use in YANG. You could of > course just state that these constructs MUST NOT be used. Yes, these languages are used to define many schema that do not support mixed content. Defining a set of templates in Relax would make it very clear how the new data should be organized, and is very easy for readers to parse and validate with boatloads of existing tools. Most netconf implementors will already have an XML parser that will automatically validate against either XSD or Relax schema. > None of these languages support important configuration management > concepts like default values (XSD has a default construct, but it is > not the same); you cannot see if a parameter represents configuration > or state data (since it's very domain specific). In RelaxNG there is > not support (by design) for integrity contraints and keys. None of > the languages have support for specific augmentation (this is > important e.g. for vendors to add vendor-specific stuff to standard > data models). I understand that you want semantic data mixed with your syntax data. I don't think you need to define a new schema language to do this. Relax allows arbitrary annotations in other namespaces, and these annotations can have semantic meaning. Rather than define a whole new syntax as well, I am much more comfortable defining additional semantics layered on top of an existing schema which validates the syntax. > We also note in the draft that both languages are extensible, and with > an extensible language you can add whatever you want. > > All this means that the existing tools might not be that simple to > use. These tools are not aware of any restrictions on the usage > imposed by NETCONF, and they do not understand the NETCONF-specific > extensions. This is a tautological statement. The existing tools will automatically catch large categories of errors automatically (that's as simple as it gets). If you want additional semantic checking, you will define those rules whether you write a whole new language or not. > Another question regarding existing tools is what exactly these tools > are supposed to be used for? Probably not instance document (NETCONF > PDU) validation, unless all elements are defined as optional, since > e.g. in an edit-config request you just include the elements you want > to modify. > > > keyref and instance-identifier are probably better served by referencing > > > an 'id' attribute and using the 'ID' type > > The problem with the ID type is that its value is global to a > document. If the document is the entire configuration datastore, all > IDs will have to be unique. Since you can reference any key (or maybe > even any leaf), every key (or leaf) will have to have it's own unique > ID. This won't scale and would be very difficult to maintain. > In RAI we had some rather painful experience with referencing keys in XCAP (RFC 4825) which also uses XPath expressions to point at subparts or subtrees of an XML document. You can certainly maintain a unique key within a list which is not generated from the data in each record. Not doing so "won't scale and would be very difficult to maintain". However, this argument is orthogonal to our main topic. > > Below, I also show examples of the YANG concepts of leaf node, > > leaf-list, container, and list expressed in YANG, how it would be > > expressed in NETCONF, and expressed in RELAX NG. > > Here's another one: > > in module foo: > > rpc my-rpc { > input { > leaf foo { type string; } > } > output { > leaf-list bar { type int32; } > leaf baz { type int32; } > } > } > > in module bar: > > augment /foo:my-rpc/foo:output { > leaf data { type int32; } > } > > > How would this translate to RelaxNG? I am assuming that this would generate the following XML in Netconf: some string 4134 3882 112334 82382 I was not clear exactly the significance of "module foo" and "module bar". If I understood correctly, module foo defines the "my-rpc" RPC call, and module bar just extends the response. I will call these "my-rpc.rng" and " my-rpc-extension1.rng" respectively. my-rpc my-rpc Note that I used a Relax annotation to convey extra semantic data. This is ignored during relax syntax validation, but available to the implementation if it wants to use this additional semantic information. An example of this is described in the book in chapter 13.3: http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html The "augment" is accomplished using a define with interleave: Finally, if you are allergic to angle brackets, you can do all this in compact form as well: # my-rpc.rnc include "netconf-rpc.rnc" rpc-requests |= element foo { xsd:string } rpc-responses |= { element bar { xsd:int }+, element baz { xsd:int } } # my-rpc-extension1.rnc include "my-rpc.rnc" my-rpc-response &= element data { xsd:int } For a more full example, I invite you to look at how Jari Urpalainen did this for the PIDF family of XML schemas to allow full automatic syntax validation. While his draft is recently expired, I have archived a copy here: http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt Also section 10.2 "Merging Grammars" in the Relax NG book describes this very nicely: http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html thanks, -rohan ------=_Part_599_33550710.1196204693324 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Martin,

More comments inline.

On Nov 27, 2007 4:03 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

"Rohan Mahy" <rohan.mahy@gmail.com> wrote:
> I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and
> thought immediately that all of the problems the draft is trying to
> address looked very suitable to use RELAX NG as a schema language.
> Looking at section F.2 (Why not RELAX NG) I did not see any specific
> examples motivating the apparently contradictory statements that Relax
> is not expressive enough and Relax is too expressive.

What we mean with this is that generic XML schema languages such as
RelaxNG and XSD are designed to specify the grammar for (almost) any
XML instance document.  For example they both support mixed content
and XML attributes, neither of which we use in YANG.  You could of
course just state that these constructs MUST NOT be used.

Yes, these languages are used to define many schema that do not support mixed content. Defining a set of templates in Relax would make it very clear how the new data should be organized, and is very easy for readers to parse and validate with boatloads of existing tools.  Most netconf implementors will already have an XML parser that will automatically validate against either XSD or Relax schema.
 
None of these languages support important configuration management
concepts like default values (XSD has a default construct, but it is
not the same); you cannot see if a parameter represents configuration
or state data (since it's very domain specific).  In RelaxNG there is
not support (by design) for integrity contraints and keys.  None of
the languages have support for specific augmentation (this is
important e.g. for vendors to add vendor-specific stuff to standard
data models).

I understand that you want semantic data mixed with your syntax data. I don't think you need to define a new schema language to do this. Relax allows arbitrary annotations in other namespaces, and these annotations can have semantic meaning.  Rather than define a whole new syntax as well, I am much more comfortable defining additional semantics layered on top of an existing schema which validates the syntax.
 
We also note in the draft that both languages are extensible, and with
an extensible language you can add whatever you want.

All this means that the existing tools might not be that simple to
use.  These tools are not aware of any restrictions on the usage
imposed by NETCONF, and they do not understand the NETCONF-specific
extensions.

This is a tautological statement. The existing tools will automatically catch large categories of errors automatically (that's as simple as it gets). If you want additional semantic checking, you will define those rules whether you write a whole new language or not.
 
Another question regarding existing tools is what exactly these tools
are supposed to be used for?  Probably not instance document (NETCONF
PDU) validation, unless all elements are defined as optional, since
e.g. in an edit-config request you just include the elements you want
to modify.

> keyref and instance-identifier are probably better served by referencing
> an 'id' attribute and using the 'ID' type

The problem with the ID type is that its value is global to a
document.  If the document is the entire configuration datastore, all
IDs will have to be unique.  Since you can reference any key (or maybe
even any leaf), every key (or leaf) will have to have it's own unique
ID.  This won't scale and would be very difficult to maintain.

In RAI we had some rather painful experience with referencing keys in XCAP (RFC 4825) which also uses XPath expressions to point at subparts or subtrees of an XML document. You can certainly maintain a unique key within a list which is not generated from the data in each record.  Not doing so "won't scale and would be very difficult to maintain".  However, this argument is orthogonal to our main topic.
 
> Below, I also show examples of the YANG concepts of leaf node,
> leaf-list, container, and list expressed in YANG, how it would be
> expressed in NETCONF, and expressed in RELAX NG.

Here's another one:

in module foo:

  rpc my-rpc {
    input {
      leaf foo { type string; }
    }
    output {
      leaf-list bar { type int32; }
      leaf baz      { type int32; }
    }
  }

in module bar:

 augment /foo:my-rpc/foo:output {
    leaf data { type int32; }
 }


How would this translate to RelaxNG?

I am assuming that this would generate the following XML in Netconf:
<rpc message-id="45">
  <my-rpc>
    <foo>some string</foo>
  </my-prc>
</rpc>

<rpc-result message-id="45">
  <bar>4134</bar>
  <bar>3882</bar>
  <baz>112334</baz>
  <data>82382</data>
</rpc-result>

I was not clear exactly the significance of "module foo" and "module bar".  If I understood correctly, module foo defines the "my-rpc" RPC call, and module bar just extends the response.  I will call these " my-rpc.rng" and  "my-rpc-extension1.rng" respectively.


<!-- my-rpc.rng  -->
<include href="netconf-rpc.rng"/>

<define name="rpc-requests" combine="choice">
  <ref name="my-rpc-request"/>
</define>

<define name="rpc-responses" combine="choice">
  <ref name="my-rpc-response"/>
</define>

<define name="my-rpc-request">
  <element name="foo">
    <data type="string"/>
  </element>
  <netconf:rpc-method type="request">my-rpc</netconf:rpc-method>
</define>

<define name="my-rpc-response">
  <oneOrMore>
    <element name="bar">
      <data type="int"/>
    </element>
  </oneOrMore>
  <element name="baz">
    <data type="int"/>
  </element>
  <netconf:rpc-method type="response">my-rpc</netconf:rpc-method>
</define>

Note that I used a Relax annotation to convey extra semantic data.  This is ignored during relax syntax validation, but available to the implementation if it wants to use this additional semantic information.  An example of this is described in the book in chapter 13.3: http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html

The "augment" is accomplished using a define with interleave:
 
<!-- my-rpc-extension1.rng -->

<include href="my-rpc.rng"/>

<define name="my-rpc-response" combine="interleave">
  <element name="data">
    <data type="int"/>
  </element>
</define>

Finally, if you are allergic to angle brackets, you can do all this in compact form as well:

# my-rpc.rnc
include "netconf-rpc.rnc"
rpc-requests |= element foo { xsd:string }
rpc-responses |= {
  element bar { xsd:int }+,
  element baz { xsd:int }
}

# my-rpc-extension1.rnc
include "my-rpc.rnc"
my-rpc-response &= element data { xsd:int }

 
For a more full example, I invite you to look at how Jari Urpalainen did this for the PIDF family of XML schemas to allow full automatic syntax validation. While his draft is recently expired, I have archived a copy here:
http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt

Also section 10.2 "Merging Grammars" in the Relax NG book describes this very nicely: http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html

thanks,
-rohan
------=_Part_599_33550710.1196204693324-- From discuss-bounces@apps.ietf.org Tue Nov 27 18:18:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9h9-0001e9-II; Tue, 27 Nov 2007 18:18:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix9h8-0001dx-Mr for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9h8-0001dm-DJ for discuss@apps.ietf.org; Tue, 27 Nov 2007 18:18:22 -0500 Received: from eastrmmtao101.cox.net ([68.230.240.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9h7-0004Sz-1M for discuss@apps.ietf.org; Tue, 27 Nov 2007 18:18:22 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071127231820.VOAW5378.eastrmmtao101.cox.net@eastrmimpo01.cox.net>; Tue, 27 Nov 2007 18:18:20 -0500 Received: from charger ([68.100.33.12]) by eastrmimpo01.cox.net with bizsmtp id HzHq1Y00Y0FiBvo0000000; Tue, 27 Nov 2007 18:17:51 -0500 From: "Scott Hollenbeck" To: "'Lisa Dusseault'" , "'Apps Discuss'" References: <178C64E1-7F99-4C19-90C8-CC9B7B6F9A62@osafoundation.org> Subject: RE: Last Call: draft-klensin-rfc2821bis (Simple Mail TransferProtocol) to Draft Standard Date: Tue, 27 Nov 2007 18:18:19 -0500 Message-ID: <001201c8314b$cc833c00$0323520a@charger> 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.3198 Thread-index: AcgxQ11s90R5BJkzRV6iXMJMG8NxsQACBfwg In-Reply-To: <178C64E1-7F99-4C19-90C8-CC9B7B6F9A62@osafoundation.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > Sent: Tuesday, November 27, 2007 5:17 PM > To: Apps Discuss > Subject: Fwd: Last Call: draft-klensin-rfc2821bis (Simple > Mail TransferProtocol) to Draft Standard > > FYI > > > Begin forwarded message: > > > From: The IESG > Date: November 26, 2007 5:32:59 PM PST > To: IETF-Announce > Subject: Last Call: draft-klensin-rfc2821bis (Simple > Mail Transfer Protocol) to Draft Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from an individual > submitter to consider > the following document: > > - 'Simple Mail Transfer Protocol ' > as a Draft Standard [snip] > Implementation Report can be accessed at > http://www.ietf.org/IESG/implementation.html > I don't see the implementation report at the location described above. Pointer, please? -Scott- From discuss-bounces@apps.ietf.org Wed Nov 28 03:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIRo-0002r6-U0; Wed, 28 Nov 2007 03:39:08 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxIRn-0002qB-BK for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 03:39:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIRh-0002pF-IF for discuss@apps.ietf.org; Wed, 28 Nov 2007 03:39:01 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxIRg-0006sz-JN for discuss@apps.ietf.org; Wed, 28 Nov 2007 03:39:01 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21F0F8A1B1; Wed, 28 Nov 2007 09:39:00 +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 30598-07-2; Wed, 28 Nov 2007 09:38:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A8F68A1AE; Wed, 28 Nov 2007 09:38:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9BE033F7C3C; Wed, 28 Nov 2007 09:38:52 +0100 (CET) Date: Wed, 28 Nov 2007 09:38:52 +0100 From: Juergen Schoenwaelder To: Lisa Dusseault Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071128083852.GB28685@elstar.local> References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se> <20071127163727.GA27816@elstar.local> <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.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: a8a20a483a84f747e56475e290ee868e Cc: discuss@apps.ietf.org, Leif Johansson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, Nov 27, 2007 at 11:54:23AM -0800, Lisa Dusseault wrote: > Another question to answer, is why is having a data model (an ontology) not > enough? The question of needing a standard data model must be separated > from the need for a custom modeling language. Some of the justifications > I've seen so far for a modeling language have really been justifying only a > standard data model. Different areas happen to use different terminology. What you call a data model is what network management people happen to call an information model, see RFC 3444. I don't care which terminology we use in this discussion as long as we happen to understand the same thing when we use the same words. > Of course using XML as the data format doesn't, by itself, give enough of a > common data model for 3rd-party NetConf tools to understand arbitrary data. > NetConf probably does need a common data model, perhaps defining how IDs > are expressed and what a container is, what is a netconf "object" that can > be operated on. > > But a common data model does not need to depend on a modeling language at > all. Put it differently: a sufficiently strong common data model can work > with multiple modeling languages without harming interoperability. Thus, > having a standard data model that is independent of the modeling language > can be a real win for clarity and robustness and somewhat more proof > against changing stylistic preferences. The network management world is used to automated processes and the number of MIB modules in existences may serve as a proof that people do find benefits from using machine readable definitions. OK, to be fair, I must admit that SNMP is almost unusable with generic tools without at least translating OIDs into something textual. But there is of course much more you get out of concrete machine readable data models since they can drive large (and annoying and error prone) parts of implementation processes. > The commonest approach for IETF protocols that deal with an ontology is to > define the data model in English, limiting the ways the data can be > expressed to something that becomes essentially self-describing (the name > of a new thing/object, and its contents or value, can be derived from the > document without seeing a specific schema). LDAP is one of the clearest > examples of this. An LDAP agent can handle custom content because it > follows the expected data model. There's no need, in LDAP, for a special > language to describe new attributes. The iCalendar and vCard formats are > the same. SNMP is really different in having a special language to learn, > and using that in specs. I would call the "iCalendar apprach" semi-formal and this is likely true for the others you mention as well. My understanding is that iCalendar does in fact use some ABNF plus several other "conventions", i.e., certain naming and structuring rules, value notation rules, quoting rules and so on. So there is somewhat formalized content but I also agree that the overall format is not as strict as the SMIv2 or YANG or RelaxNG or XSD (just to name a few ;-). I believe the key difference is simply the number of definitions network management people happen to deal with. The complete configuration of high-end routers involves significantly more than just a few 10s of knobs. I am sure people from the network device vendor business can provide concrete numbers concerning the size of configuration options you find on today's products in case that is useful. Once you reach a critical threshold, you really like to have precise machine readable specifications that can drive a tool chain and to some extend validate definitions, automate some of the implementation work, reduce implementation bugs, drive documentation tools and so on. > My experience with description languages or other formalizations is that > these often take the place of proper specification. Authors think that > they are done when they've written the code that describes the format. > However, the most important aspect to a new standard schema is usually what > it *means*. Sure, languages can't turn lazy people into smart people. But the IETF is actually very good at handling this. You can't publish a protocol by writing down just a few ABNF definitions. You can't publish a MIB module by leaving description clauses empty. You can't publish a protocol by just writing down message formats in ASCII art and nothing else. The key to good specifications is simply good reviews. I do not really want to be involved in a high-level discussion whether formalized notations, semi-formal notations, or plain English notations are most useful and I hope we can avoid getting into such a discussion to save us all time and bandwidth. I suggest that the WGs and people actually involved in a given protocol take this decision. Personally, I happen to believe that the scale in terms of the number of definitions you have to handle determines whether machine readable definitions are worth the extra formalization efforts. In the case of NETCONF, it is important to allow operators to quickly and easily understand what configuration knobs exist on their devices, what they mean and how to turn them. A common notation is needed for that so that SDOs, vendors, and operators have a common language to work with. In order to deal with the large number of knobs you find on today's devices, I believe that a formalized notation is well worth the effort. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Wed Nov 28 07:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxM39-0004SA-Kc; Wed, 28 Nov 2007 07:29:55 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxM39-0004S4-5z for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 07:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxM38-0004Rv-PE for discuss@apps.ietf.org; Wed, 28 Nov 2007 07:29:54 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxM37-0004Ka-QQ for discuss@apps.ietf.org; Wed, 28 Nov 2007 07:29:54 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208";a="76431053" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Nov 2007 07:29:51 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208";a="134803639" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Nov 2007 07:29:10 -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: analysis of YANG vs. RELAX NG Date: Wed, 28 Nov 2007 13:28:55 +0100 Message-ID: In-Reply-To: <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: analysis of YANG vs. RELAX NG Thread-Index: AcgxL1zSq50VzO2ZTaKHDFjYYc0u4QAiU/hQ References: <20071127.130355.18118495.mbj@tail-f.com><474C116A.1080001@it.su.se> <20071127163727.GA27816@elstar.local> <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> From: "Romascanu, Dan (Dan)" To: "Lisa Dusseault" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: discuss@apps.ietf.org, Leif Johansson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa, As Juergen has pointed, we differentiate in the OPS area between information model and data model. I believe that much of what you say about ontology and data model in English actually relates to what we call information models. There was an effort to start a new information model (nim) in the IETF, we had a BOF some time ago, but the general feeling was that the endeavor is too big, the field too dynamic, and other SDOs may be better places for IM definition. The approach that you see today which starts with the definition of a data modeling language and uses it to perform a one step modeling resulting in an interoperable data structure is the result of accumulating experience and a few basic requirements derived from the needs of the operators performing network management operations - scalability, extensibility, machine readable and yet human comprehensible format, interoperability between different vendors agents and managers, form factor that allows rather complex and large configuration data bases to run or relatively resource challenged devices.=20 Dan =20 =20 > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 > Sent: Tuesday, November 27, 2007 9:54 PM > To: j.schoenwaelder@jacobs-university.de > Cc: discuss@apps.ietf.org; Leif Johansson > Subject: Re: analysis of YANG vs. RELAX NG >=20 > Another question to answer, is why is having a data model (an > ontology) not enough? The question of needing a standard=20 > data model must be separated from the need for a custom=20 > modeling language. Some of the justifications I've seen so=20 > far for a modeling language have really been justifying only=20 > a standard data model. >=20 > Of course using XML as the data format doesn't, by itself,=20 > give enough of a common data model for 3rd-party NetConf=20 > tools to understand arbitrary data. NetConf probably does=20 > need a common data model, perhaps defining how IDs are=20 > expressed and what a container is, what is a netconf "object"=20 > that can be operated on. >=20 > But a common data model does not need to depend on a modeling=20 > language at all. Put it differently: a sufficiently strong=20 > common data model can work with multiple modeling languages=20 > without harming interoperability. Thus, having a standard=20 > data model that is independent of the modeling language can=20 > be a real win for clarity and robustness and somewhat more=20 > proof against changing stylistic preferences. >=20 > The commonest approach for IETF protocols that deal with an=20 > ontology is to define the data model in English, limiting the=20 > ways the data can be expressed to something that becomes=20 > essentially self- describing (the name of a new thing/object,=20 > and its contents or value, can be derived from the document=20 > without seeing a specific schema). LDAP is one of the=20 > clearest examples of this. An LDAP agent can handle custom=20 > content because it follows the expected data model. There's=20 > no need, in LDAP, for a special language to describe new=20 > attributes. The iCalendar and vCard formats are the same. =20 > SNMP is really different in having a special language to=20 > learn, and using that in specs. >=20 > My experience with description languages or other=20 > formalizations is that these often take the place of proper=20 > specification. Authors think that they are done when they've=20 > written the code that describes the format. However, the=20 > most important aspect to a new standard schema is usually=20 > what it *means*. >=20 > Lisa >=20 > On Nov 27, 2007, at 8:37 AM, Juergen Schoenwaelder wrote: >=20 > > On Tue, Nov 27, 2007 at 01:45:30PM +0100, Leif Johansson wrote: > > > >> I don't know about RelaxNG, but it is pretty close to OWL.=20 > Apart from=20 > >> the C-like syntax (which might be important to some) the example=20 > >> suggests a modeling language which supports classes, packages,=20 > >> properties (possibly associations?) and a form of multiple=20 > >> inheritance. > >> > >> While I am as happy as the next guy that we won't be=20 > seeing RFCs with=20 > >> XMI in them anytime soon I am curious as to why something like OWL=20 > >> isn't a strong candidate for something like this. Is it just=20 > >> "anti-XML" > >> or is there something more substantial to it? > > > > NETCONF uses XML for data encoding and is this is just fine. > > > > YANG is a domain specific data modeling language designed=20 > to support=20 > > NETCONF (no more, no less). The YANG language reflects many=20 > years of=20 > > experience with other network management data modeling languages in=20 > > the IETF and proprietary languages created by NETCONF=20 > implementors to=20 > > support their implementations (after figuring out that creating=20 > > adapted subset languages did not work well in their=20 > companies or for=20 > > their customers). > > > > While YANG clearly lacks features such as multiple inheritance or=20 > > support for semantic web reasoning engines, we feel that it helps a=20 > > lot in writing understandable and extensible NETCONF data=20 > models and=20 > > in addition it can enjoy long-term predictability and stability. > > > > /js > > > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > >=20 >=20 From discuss-bounces@apps.ietf.org Wed Nov 28 08:16:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMln-0006ZE-6M; Wed, 28 Nov 2007 08:16:03 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxMll-0006WZ-6G for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMlk-0006Vy-JM for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:16:00 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxMlj-0007lh-31 for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:16:00 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 040C43C2A6; Wed, 28 Nov 2007 14:15:58 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10572-01-33; Wed, 28 Nov 2007 14:15:57 +0100 (CET) Received: from k2.mnt.se (eduroam-vastra-120.publik.su.se [77.238.38.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id A250E3C025; Wed, 28 Nov 2007 14:15:57 +0100 (CET) Message-ID: <474D6A11.50708@it.su.se> Date: Wed, 28 Nov 2007 14:16:01 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se> <20071127163727.GA27816@elstar.local> <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> In-Reply-To: <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.195 tagged_above=-99 required=7 tests=[AWL=0.117, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > > My experience with description languages or other formalizations is > that these often take the place of proper specification. Authors > think that they are done when they've written the code that describes > the format. However, the most important aspect to a new standard > schema is usually what it *means*. > I could not agree more. A formal language *can* make the specification more precise and less readable (and useful) at the same time. Having said that I've found that using formal languages for ontologies can help, especially if you actually plan on producing "stuff" from the ontology (code for instance). I don't think MIBs would be very useful if they were written in English :-) Cheers Leif From discuss-bounces@apps.ietf.org Wed Nov 28 08:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMuI-0000X4-6G; Wed, 28 Nov 2007 08:24:50 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxMuH-0000Wt-Bb for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:24:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMuH-0000Wj-1g for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:24:49 -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 1IxMuG-00006F-Ic for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:24:49 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208";a="81910981" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Nov 2007 08:24:48 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208";a="128925070" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Nov 2007 08:24:44 -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: analysis of YANG vs. RELAX NG Date: Wed, 28 Nov 2007 14:22:21 +0100 Message-ID: In-Reply-To: <474D6A11.50708@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: analysis of YANG vs. RELAX NG Thread-Index: AcgxwPHzbMyxF903RjGHT2k+zOU98AAAIELA References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se><20071127163727.GA27816@elstar.local><03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> <474D6A11.50708@it.su.se> From: "Romascanu, Dan (Dan)" To: "Leif Johansson" , "Lisa Dusseault" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 =20 > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se]=20 > Sent: Wednesday, November 28, 2007 3:16 PM > To: Lisa Dusseault > Cc: discuss@apps.ietf.org > Subject: Re: analysis of YANG vs. RELAX NG >=20 >=20 > > > > My experience with description languages or other formalizations is=20 > > that these often take the place of proper specification. Authors=20 > > think that they are done when they've written the code that=20 > describes=20 > > the format. However, the most important aspect to a new standard=20 > > schema is usually what it *means*. > > > I could not agree more. A formal language *can* make the=20 > specification more precise and less readable (and useful) at=20 > the same time. >=20 > Having said that I've found that using formal languages for=20 > ontologies can help, especially if you actually plan on=20 > producing "stuff" from the ontology (code for instance). I=20 > don't think MIBs would be very useful if they were written in=20 > English :-) >=20 > Cheers Leif >=20 Well, actually the common practice is that MIBs take a mid-way approach using a formal data language and plain English DESCRIPTION clauses associated with the definition of each object.=20 Dan From discuss-bounces@apps.ietf.org Wed Nov 28 08:56:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNOT-0007Gz-4B; Wed, 28 Nov 2007 08:56:01 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxNOR-0007GU-Fc for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:55:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNOR-0007GK-5H for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:55:59 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNOO-0003G3-O7 for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:55:59 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 8FA521B80CE; Wed, 28 Nov 2007 14:55:54 +0100 (CET) Date: Wed, 28 Nov 2007 14:57:01 +0100 (CET) Message-Id: <20071128.145701.64447349.mbj@tail-f.com> To: rohan.mahy@gmail.com Subject: Re: analysis of YANG vs. RELAX NG From: Martin Bjorklund In-Reply-To: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, "Rohan Mahy" wrote: > Hi Martin, > > More comments inline. > > On Nov 27, 2007 4:03 AM, Martin Bjorklund wrote: > > > Hi, > > > > "Rohan Mahy" wrote: > > > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and > > > thought immediately that all of the problems the draft is trying to > > > address looked very suitable to use RELAX NG as a schema language. > > > Looking at section F.2 (Why not RELAX NG) I did not see any specific > > > examples motivating the apparently contradictory statements that Relax > > > is not expressive enough and Relax is too expressive. [...] > I understand that you want semantic data mixed with your syntax data. I > don't think you need to define a new schema language to do this. Right. I think we say that in the draft as well. This can absolutely be done, but for the reasons we have listed in the draft and in this email thread so far, we think a better solution is to use a domain specific language. Note that YANG is not a XML schema language. A RelaxNG or XSD schema can be used to validate the NETCONF XML encoding of the data, operations and notifications described in YANG modules. (actually, you'd typically need more than one schema, depending on which NETCONF operation you're validating - these can be generated by the tools and fed into the XML parsers). > > All this means that the existing tools might not be that simple to > > use. These tools are not aware of any restrictions on the usage > > imposed by NETCONF, and they do not understand the NETCONF-specific > > extensions. > > This is a tautological statement. The existing tools will automatically > catch large categories of errors automatically (that's as simple as it > gets). If you want additional semantic checking, you will define those rules > whether you write a whole new language or not. Absolutely. This work has to be done anyway. > In RAI we had some rather painful experience with referencing keys in XCAP > (RFC 4825) which also uses XPath expressions to point at subparts or > subtrees of an XML document. You can certainly maintain a unique key within > a list which is not generated from the data in each record. Not doing so > "won't scale and would be very difficult to maintain". However, this > argument is orthogonal to our main topic. Yes. /martin From discuss-bounces@apps.ietf.org Wed Nov 28 09:16:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNhx-0003HD-Sq; Wed, 28 Nov 2007 09:16:09 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxNhw-0003H5-LJ for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:16:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNhw-0003Gv-BG for discuss@apps.ietf.org; Wed, 28 Nov 2007 09:16:08 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNht-0005KI-9I for discuss@apps.ietf.org; Wed, 28 Nov 2007 09:16:08 -0500 Received: from [10.71.1.105] ([65.90.227.73]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lASEG1Uo015601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Nov 2007 08:16:01 -0600 In-Reply-To: <20071128083852.GB28685@elstar.local> References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se> <20071127163727.GA27816@elstar.local> <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> <20071128083852.GB28685@elstar.local> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-3-1056312835 Message-Id: From: Jon Saperia Subject: Re: analysis of YANG vs. RELAX NG Date: Wed, 28 Nov 2007 09:16:01 -0500 To: j.schoenwaelder@jacobs-university.de X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.7 (+) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: discuss@apps.ietf.org, Leif Johansson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-3-1056312835 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 28, 2007, at 3:38 AM, Juergen Schoenwaelder wrote: > On Tue, Nov 27, 2007 at 11:54:23AM -0800, Lisa Dusseault wrote: > >> Another question to answer, is why is having a data model (an >> ontology) not >> enough? The question of needing a standard data model must be >> separated >> from the need for a custom modeling language. Some of the >> justifications >> I've seen so far for a modeling language have really been >> justifying only a >> standard data model. > > Different areas happen to use different terminology. What you call a > data model is what network management people happen to call an > information model, see RFC 3444. I don't care which terminology we use > in this discussion as long as we happen to understand the same thing > when we use the same words. > >> Of course using XML as the data format doesn't, by itself, give >> enough of a >> common data model for 3rd-party NetConf tools to understand >> arbitrary data. >> NetConf probably does need a common data model, perhaps defining >> how IDs >> are expressed and what a container is, what is a netconf "object" >> that can >> be operated on. >> >> But a common data model does not need to depend on a modeling >> language at >> all. Put it differently: a sufficiently strong common data model >> can work >> with multiple modeling languages without harming >> interoperability. Thus, >> having a standard data model that is independent of the modeling >> language >> can be a real win for clarity and robustness and somewhat more proof >> against changing stylistic preferences. > > The network management world is used to automated processes and the > number of MIB modules in existences may serve as a proof that people > do find benefits from using machine readable definitions. OK, to be > fair, I must admit that SNMP is almost unusable with generic tools > without at least translating OIDs into something textual. But there is > of course much more you get out of concrete machine readable data > models since they can drive large (and annoying and error prone) parts > of implementation processes. > >> The commonest approach for IETF protocols that deal with an >> ontology is to >> define the data model in English, limiting the ways the data can be >> expressed to something that becomes essentially self-describing >> (the name >> of a new thing/object, and its contents or value, can be derived >> from the >> document without seeing a specific schema). LDAP is one of the >> clearest >> examples of this. An LDAP agent can handle custom content because it >> follows the expected data model. There's no need, in LDAP, for a >> special >> language to describe new attributes. The iCalendar and vCard >> formats are >> the same. SNMP is really different in having a special language >> to learn, >> and using that in specs. > > I would call the "iCalendar apprach" semi-formal and this is likely > true for the others you mention as well. My understanding is that > iCalendar does in fact use some ABNF plus several other "conventions", > i.e., certain naming and structuring rules, value notation rules, > quoting rules and so on. So there is somewhat formalized content but I > also agree that the overall format is not as strict as the SMIv2 or > YANG or RelaxNG or XSD (just to name a few ;-). > > I believe the key difference is simply the number of definitions > network management people happen to deal with. The complete > configuration of high-end routers involves significantly more than > just a few 10s of knobs. I am sure people from the network device > vendor business can provide concrete numbers concerning the size of > configuration options you find on today's products in case that is > useful. Once you reach a critical threshold, you really like to have > precise machine readable specifications that can drive a tool chain > and to some extend validate definitions, automate some of the > implementation work, reduce implementation bugs, drive documentation > tools and so on. > >> My experience with description languages or other formalizations >> is that >> these often take the place of proper specification. Authors think >> that >> they are done when they've written the code that describes the >> format. >> However, the most important aspect to a new standard schema is >> usually what >> it *means*. > > Sure, languages can't turn lazy people into smart people. But the IETF > is actually very good at handling this. You can't publish a protocol > by writing down just a few ABNF definitions. You can't publish a MIB > module by leaving description clauses empty. You can't publish a > protocol by just writing down message formats in ASCII art and nothing > else. The key to good specifications is simply good reviews. > > I do not really want to be involved in a high-level discussion whether > formalized notations, semi-formal notations, or plain English > notations are most useful and I hope we can avoid getting into such a > discussion to save us all time and bandwidth. I suggest that the WGs > and people actually involved in a given protocol take this decision. > Personally, I happen to believe that the scale in terms of the number > of definitions you have to handle determines whether machine readable > definitions are worth the extra formalization efforts. > > In the case of NETCONF, it is important to allow operators to quickly > and easily understand what configuration knobs exist on their devices, > what they mean and how to turn them. A common notation is needed for > that so that SDOs, vendors, and operators have a common language to > work with. In order to deal with the large number of knobs you find on > today's devices, I believe that a formalized notation is well worth > the effort. Juergen, there is one additional point/requirement for a solution related to the number of objects you suggest. That is the rate of change, not be the standards body, in this case since we are talking about configuration information, but by the vendors. With each new technology, hardware platform, software revision and potentially firmware revision, a vendor will need to modify the 'knobs'. This is where the formalized notation in my view has a strong payback. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > Thanks, /jon ---- Jon Saperia saperia@jdscons.com (mobil) 617-201-2655 (office) 978-461-0249 --Apple-Mail-3-1056312835 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Nov 28, 2007, at 3:38 AM, Juergen Schoenwaelder = wrote:

On Tue, Nov 27, 2007 at = 11:54:23AM -0800, Lisa Dusseault wrote:

Another question to answer, is why is having a data = model (an ontology) not=A0
=A0 The question = of needing a standard data model must be separated=A0
from the = need for a custom modeling language.=A0 Some of the = justifications=A0
I've seen so far for a modeling language have really = been justifying only a=A0
standard = data model.

Different areas happen to use = different terminology. What you call a
data = model is what network management people happen to call an
information model, see RFC 3444. I don't care which = terminology we use
in this discussion as long = as we happen to understand the same thing
when we = use the same words.
Of course = using XML as the data format doesn't, by itself, give enough of a=A0
common = data model for 3rd-party NetConf tools to understand arbitrary = data.=A0
NetConf probably does need a common data model, = perhaps defining how IDs=A0
are = expressed and what a container is, what is a netconf "object" that = can=A0
be operated on.

But a common data model does not = need to depend on a modeling language at=A0
=A0 Put it = differently: a sufficiently strong common data model can work=A0
with = multiple modeling languages without harming interoperability.=A0 Thus,=A0
having a = standard data model that is independent of the modeling language=A0
can be a = real win for clarity and robustness and somewhat more proof=A0
against = changing stylistic preferences.

The = network management world is used to automated processes and = the
number of MIB modules in = existences may serve as a proof that people
do find = benefits from using machine readable definitions. OK, to be
fair, I must admit that SNMP is almost unusable with = generic tools
without at least translating = OIDs into something textual. But there is
of = course much more you get out of concrete machine readable data
models since they can drive large (and annoying and = error prone) parts
of implementation = processes.

=
The commonest approach for = IETF protocols that deal with an ontology is to=A0
define = the data model in English, limiting the ways the data can be=A0
=A0
of a new thing/object, and its contents or value, = can be derived from the=A0
document = without seeing a specific schema).=A0= LDAP is one of the clearest=A0
examples = of this.=A0 An LDAP agent = can handle custom content because it=A0
follows = the expected data model. There's no need, in LDAP, for a special=A0
language = to describe new attributes.=A0 = The iCalendar and vCard formats are=A0
the = same.=A0 SNMP is really = different in having a special language to learn,=A0
and = using that in specs.

I would call the "iCalendar = apprach" semi-formal and this is likely
true for = the others you mention as well. My understanding is that
iCalendar does in fact use some ABNF plus several = other "conventions",
i.e., certain naming and = structuring rules, value notation rules,
quoting = rules and so on. So there is somewhat formalized content but I
also agree that the overall format is not as strict = as the SMIv2 or
YANG or RelaxNG or XSD (just to = name a few ;-).

I believe the key difference is simply the number of = definitions
network management people happen = to deal with. The complete
configuration = of high-end routers involves significantly more than
just a few 10s of knobs. I am sure people from the = network device
vendor business can provide = concrete numbers concerning the size of
useful. Once you reach a critical threshold, = you really like to have
precise = machine readable specifications that can drive a tool chain
and to some extend validate definitions, automate = some of the
implementation work, reduce = implementation bugs, drive documentation
tools = and so on.

=
My experience with = description languages or other formalizations is that=A0
these = often take the place of proper specification.=A0 Authors think that=A0
they are = done when they've written the code that describes the format. =A0
However, = the most important aspect to a new standard schema is usually what=A0
it = *means*.
Sure, languages can't turn lazy = people into smart people. But the IETF
is = actually very good at handling this. You can't publish a = protocol
by writing down just a few ABNF = definitions. You can't publish a MIB
module by = leaving description clauses empty. You can't publish a
protocol by just writing down message formats in = ASCII art and nothing
else. The key to good = specifications is simply good reviews.

I do not = really want to be involved in a high-level discussion whether
formalized notations, semi-formal notations, or = plain English
notations are most useful and I = hope we can avoid getting into such a
and people actually involved in = a given protocol take this decision.
Personally, I = happen to believe that the scale in terms of the number
of definitions you have to handle determines whether = machine readable
definitions are worth the extra = formalization efforts.
In the case of NETCONF, it is = important to allow operators to quickly
and = easily understand what configuration knobs exist on their = devices,
what they mean and how to turn = them. A common notation is needed for
that so = that SDOs, vendors, and operators have a common language to
work with. In order to deal with the large number of = knobs you find on
today's devices, I believe that = a formalized notation is well worth
the = effort.

Juergen, there is one = additional point/requirement for a solution related to the number of = objects you suggest. =A0That is the rate of change, not be the standards = body, in this case since we are talking about configuration information, = but by the vendors. =A0With each new technology, hardware platform, = software revision and potentially firmware revision, a vendor will need = to modify the 'knobs'. =A0This is where the formalized notation in my = view has a strong payback.


--=A0
Juergen = Schoenwaelder =A0 =A0 =A0 =A0 =A0 = Jacobs University Bremen gGmbH
Phone: = +49 421 200 3587 =A0 =A0 =A0 =A0 = Campus Ring 1, 28759 Bremen, Germany
Fax: = =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >


=

saperia@jdscons.com
(mob= il) = 617-201-2655
(office) = 978-461-0249



= --Apple-Mail-3-1056312835-- From discuss-bounces@apps.ietf.org Wed Nov 28 09:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO7D-0003vV-If; Wed, 28 Nov 2007 09:42:15 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxO7B-0003up-Rf for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:42:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO7B-0003uc-HK for discuss@apps.ietf.org; Wed, 28 Nov 2007 09:42:13 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxO79-0000mS-6Z for discuss@apps.ietf.org; Wed, 28 Nov 2007 09:42:13 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B59F520CC1; Wed, 28 Nov 2007 15:42:05 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-ca-474d7e3df93c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CEEB20C8E; Wed, 28 Nov 2007 15:42:05 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 15:42:05 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 15:42:04 +0100 Message-ID: <474D7E3A.10805@ericsson.com> Date: Wed, 28 Nov 2007 15:42:02 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Jon Saperia Subject: Do we need a formalized language: [Was: Re: analysis of YANG vs. RELAX NG] References: <20071127.130355.18118495.mbj@tail-f.com> <474C116A.1080001@it.su.se> <20071127163727.GA27816@elstar.local> <03A9505C-36BB-4C69-9626-8FFADE5BFC68@osafoundation.org> <20071128083852.GB28685@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 14:42:05.0023 (UTC) FILETIME=[D830DEF0:01C831CC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: discuss@apps.ietf.org, Leif Johansson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, Ericsson uses it"s own formalized language (which we would like to change to a standard solution) to automatically - generate code - generate html documentation in a strict Ericsson-format - do semantic checks - provide standard interface description e.g. LDAP schema files, Corba IDLs Doing all this without a precise formal language would be near impossible. Balazs Jon Saperia wrote: > > On Nov 28, 2007, at 3:38 AM, Juergen Schoenwaelder wrote: > >> On Tue, Nov 27, 2007 at 11:54:23AM -0800, Lisa Dusseault wrote: >> >>> Another question to answer, is why is having a data model (an >>> ontology) not >>> enough? The question of needing a standard data model must be separated >>> from the need for a custom modeling language. Some of the >>> justifications >>> I've seen so far for a modeling language have really been justifying >>> only a >>> standard data model. >> >> Different areas happen to use different terminology. What you call a >> data model is what network management people happen to call an >> information model, see RFC 3444. I don't care which terminology we use >> in this discussion as long as we happen to understand the same thing >> when we use the same words. >> >>> Of course using XML as the data format doesn't, by itself, give >>> enough of a >>> common data model for 3rd-party NetConf tools to understand arbitrary >>> data. >>> NetConf probably does need a common data model, perhaps defining how IDs >>> are expressed and what a container is, what is a netconf "object" >>> that can >>> be operated on. >>> >>> But a common data model does not need to depend on a modeling >>> language at >>> all. Put it differently: a sufficiently strong common data model can >>> work >>> with multiple modeling languages without harming interoperability. >>> Thus, >>> having a standard data model that is independent of the modeling >>> language >>> can be a real win for clarity and robustness and somewhat more proof >>> against changing stylistic preferences. >> >> The network management world is used to automated processes and the >> number of MIB modules in existences may serve as a proof that people >> do find benefits from using machine readable definitions. OK, to be >> fair, I must admit that SNMP is almost unusable with generic tools >> without at least translating OIDs into something textual. But there is >> of course much more you get out of concrete machine readable data >> models since they can drive large (and annoying and error prone) parts >> of implementation processes. >> >>> The commonest approach for IETF protocols that deal with an ontology >>> is to >>> define the data model in English, limiting the ways the data can be >>> expressed to something that becomes essentially self-describing (the >>> name >>> of a new thing/object, and its contents or value, can be derived from >>> the >>> document without seeing a specific schema). LDAP is one of the clearest >>> examples of this. An LDAP agent can handle custom content because it >>> follows the expected data model. There's no need, in LDAP, for a special >>> language to describe new attributes. The iCalendar and vCard formats >>> are >>> the same. SNMP is really different in having a special language to >>> learn, >>> and using that in specs. >> >> I would call the "iCalendar apprach" semi-formal and this is likely >> true for the others you mention as well. My understanding is that >> iCalendar does in fact use some ABNF plus several other "conventions", >> i.e., certain naming and structuring rules, value notation rules, >> quoting rules and so on. So there is somewhat formalized content but I >> also agree that the overall format is not as strict as the SMIv2 or >> YANG or RelaxNG or XSD (just to name a few ;-). >> >> I believe the key difference is simply the number of definitions >> network management people happen to deal with. The complete >> configuration of high-end routers involves significantly more than >> just a few 10s of knobs. I am sure people from the network device >> vendor business can provide concrete numbers concerning the size of >> configuration options you find on today's products in case that is >> useful. Once you reach a critical threshold, you really like to have >> precise machine readable specifications that can drive a tool chain >> and to some extend validate definitions, automate some of the >> implementation work, reduce implementation bugs, drive documentation >> tools and so on. >> >>> My experience with description languages or other formalizations is that >>> these often take the place of proper specification. Authors think that >>> they are done when they've written the code that describes the format. >>> However, the most important aspect to a new standard schema is >>> usually what >>> it *means*. >> >> Sure, languages can't turn lazy people into smart people. But the IETF >> is actually very good at handling this. You can't publish a protocol >> by writing down just a few ABNF definitions. You can't publish a MIB >> module by leaving description clauses empty. You can't publish a >> protocol by just writing down message formats in ASCII art and nothing >> else. The key to good specifications is simply good reviews. >> >> I do not really want to be involved in a high-level discussion whether >> formalized notations, semi-formal notations, or plain English >> notations are most useful and I hope we can avoid getting into such a >> discussion to save us all time and bandwidth. I suggest that the WGs >> and people actually involved in a given protocol take this decision. >> Personally, I happen to believe that the scale in terms of the number >> of definitions you have to handle determines whether machine readable >> definitions are worth the extra formalization efforts. >> >> In the case of NETCONF, it is important to allow operators to quickly >> and easily understand what configuration knobs exist on their devices, >> what they mean and how to turn them. A common notation is needed for >> that so that SDOs, vendors, and operators have a common language to >> work with. In order to deal with the large number of knobs you find on >> today's devices, I believe that a formalized notation is well worth >> the effort. > > Juergen, there is one additional point/requirement for a solution > related to the number of objects you suggest. That is the rate of > change, not be the standards body, in this case since we are talking > about configuration information, but by the vendors. With each new > technology, hardware platform, software revision and potentially > firmware revision, a vendor will need to modify the 'knobs'. This is > where the formalized notation in my view has a strong payback. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> > > Thanks, > /jon > ---- > Jon Saperia > saperia@jdscons.com > (mobil) 617-201-2655 > (office) 978-461-0249 > > > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From discuss-bounces@apps.ietf.org Wed Nov 28 11:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPP4-0005c4-AZ; Wed, 28 Nov 2007 11:04:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxPP2-0005bj-V6 for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 11:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPP2-0005ba-LX for discuss@apps.ietf.org; Wed, 28 Nov 2007 11:04:44 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxPOz-0005UX-8l for discuss@apps.ietf.org; Wed, 28 Nov 2007 11:04:44 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 906F120406; Wed, 28 Nov 2007 17:04:40 +0100 (CET) X-AuditID: c1b4fb3c-af796bb0000030cf-87-474d9198d9dc Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 78EDB2004B; Wed, 28 Nov 2007 17:04:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 17:04:40 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 17:04:39 +0100 Message-ID: <474D9194.3060103@ericsson.com> Date: Wed, 28 Nov 2007 17:04:36 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> In-Reply-To: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 16:04:40.0005 (UTC) FILETIME=[61971F50:01C831D8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, I am no expert in RelaxNg but here are some thoughts why I like Yang better. I have the feeling once you extend RelaxNg with all the necessary bits, half your statements will start with . There are many aspects that can be somewhat tricky and/or simply time consuming, and are missing from RelaxNg: - what does a default mean for configuration data - what is considered a compatible or incompatible change - ordering of items within list, leaf-lists - netconf edit-config semantics - differentiating between configuration and operational data - differentiating between RPCs, notifications and data containers (in YANG you have separate statements) - connecting RPC request definitions with RPC reply definitions - definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter, etc.). Nothing special but work to do even for RelaxNg - Netconf specific error messages Certainly all these can be done as extensions to RelaxNg as well, but even after taking RelaxNg as your base, you still have a big work to do. And once your specification is complete you need to build custom tools to understand the statements. (For YANG we already have tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools) -------------------------------------------------------------------------------------------- For NETCONF readability by operators, untrained in modeling languages, is a crucial requirement. The question is after how many hours (not days) of training can an operator grok a YANG model or a RelaxNg model? I feel YANG is easier. One important advantage of YANG is that the number of features in YANG is much smaller then in RelaxNg. If we would count the number of features excluding stuff that is missing from RelaxNg, the difference would become even more pronounced. Generally YANG uses the terminology that network management people are familiar with e.g. container, augment, configuration data. Learning the RelaxNg terminology takes time. In the network management world there is a general dislike for so called "little rules". Things like - you can use RelaxNg but don't use attributes - you can use RelaxNg but don't use mixed pattern - you can use RelaxNg but don't redefine or remove patterns With RelaxNg we will need a number of such rules. With a problem specific solution - YANG - the number of such rules is minimal. Balazs Rohan Mahy wrote: > Hi Martin, > > More comments inline. > > On Nov 27, 2007 4:03 AM, Martin Bjorklund > wrote: > > Hi, > > "Rohan Mahy" > wrote: > > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and > > thought immediately that all of the problems the draft is trying to > > address looked very suitable to use RELAX NG as a schema language. > > Looking at section F.2 (Why not RELAX NG) I did not see any specific > > examples motivating the apparently contradictory statements that > Relax > > is not expressive enough and Relax is too expressive. [BALAZS]: Relax can say a number of things we don't need, but can't say a number of other things we do. If you have thousands of words for ice cream but no words for colors then your language is too big and too small at the same time. > > What we mean with this is that generic XML schema languages such as > RelaxNG and XSD are designed to specify the grammar for (almost) any > XML instance document. For example they both support mixed content > and XML attributes, neither of which we use in YANG. You could of > course just state that these constructs MUST NOT be used. > > > Yes, these languages are used to define many schema that do not support > mixed content. Defining a set of templates in Relax would make it very > clear how the new data should be organized, and is very easy for readers > to parse and validate with boatloads of existing tools. Most netconf > implementors will already have an XML parser that will automatically > validate against either XSD or Relax schema. > > > None of these languages support important configuration management > concepts like default values (XSD has a default construct, but it is > not the same); you cannot see if a parameter represents configuration > or state data (since it's very domain specific). In RelaxNG there is > not support (by design) for integrity contraints and keys. None of > the languages have support for specific augmentation (this is > important e.g. for vendors to add vendor-specific stuff to standard > data models). > > > I understand that you want semantic data mixed with your syntax data. I > don't think you need to define a new schema language to do this. Relax > allows arbitrary annotations in other namespaces, and these annotations > can have semantic meaning. Rather than define a whole new syntax as > well, I am much more comfortable defining additional semantics layered > on top of an existing schema which validates the syntax. > > > We also note in the draft that both languages are extensible, and with > an extensible language you can add whatever you want. > > All this means that the existing tools might not be that simple to > use. These tools are not aware of any restrictions on the usage > imposed by NETCONF, and they do not understand the NETCONF-specific > extensions. > > > This is a tautological statement. The existing tools will automatically > catch large categories of errors automatically (that's as simple as it > gets). If you want additional semantic checking, you will define those > rules whether you write a whole new language or not. > > > Another question regarding existing tools is what exactly these tools > are supposed to be used for? Probably not instance document (NETCONF > PDU) validation, unless all elements are defined as optional, since > e.g. in an edit-config request you just include the elements you want > to modify. > > > keyref and instance-identifier are probably better served by > referencing > > an 'id' attribute and using the 'ID' type > > The problem with the ID type is that its value is global to a > document. If the document is the entire configuration datastore, all > IDs will have to be unique. Since you can reference any key (or maybe > even any leaf), every key (or leaf) will have to have it's own unique > ID. This won't scale and would be very difficult to maintain. > > > In RAI we had some rather painful experience with referencing keys in > XCAP (RFC 4825) which also uses XPath expressions to point at subparts > or subtrees of an XML document. You can certainly maintain a unique key > within a list which is not generated from the data in each record. Not > doing so "won't scale and would be very difficult to maintain". > However, this argument is orthogonal to our main topic. > > > > Below, I also show examples of the YANG concepts of leaf node, > > leaf-list, container, and list expressed in YANG, how it would be > > expressed in NETCONF, and expressed in RELAX NG. > > Here's another one: > > in module foo: > > rpc my-rpc { > input { > leaf foo { type string; } > } > output { > leaf-list bar { type int32; } > leaf baz { type int32; } > } > } > > in module bar: > > augment /foo:my-rpc/foo:output { > leaf data { type int32; } > } > > > How would this translate to RelaxNG? > > > I am assuming that this would generate the following XML in Netconf: > > > some string > > > > > 4134 > 3882 > 112334 > 82382 > > > I was not clear exactly the significance of "module foo" and "module > bar". If I understood correctly, module foo defines the "my-rpc" RPC > call, and module bar just extends the response. I will call these " > my-rpc.rng" and "my-rpc-extension1.rng" respectively. > > > > > > > > > > > > > > > > > > my-rpc > > > > > > > > > > > > my-rpc > > > Note that I used a Relax annotation to convey extra semantic data. This > is ignored during relax syntax validation, but available to the > implementation if it wants to use this additional semantic information. > An example of this is described in the book in chapter 13.3: > http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html > > The "augment" is accomplished using a define with interleave: > > > > > > > > > > > > Finally, if you are allergic to angle brackets, you can do all this in > compact form as well: > > # my-rpc.rnc > include "netconf-rpc.rnc" > rpc-requests |= element foo { xsd:string } > rpc-responses |= { > element bar { xsd:int }+, > element baz { xsd:int } > } > > # my-rpc-extension1.rnc > include "my-rpc.rnc" > my-rpc-response &= element data { xsd:int } > > > For a more full example, I invite you to look at how Jari Urpalainen did > this for the PIDF family of XML schemas to allow full automatic syntax > validation. While his draft is recently expired, I have archived a copy > here: > http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt > > > Also section 10.2 "Merging Grammars" in the Relax NG book describes this > very nicely: > http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html > > > thanks, > -rohan -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From discuss-bounces@apps.ietf.org Wed Nov 28 13:26:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRbj-0004hs-Sq; Wed, 28 Nov 2007 13:25:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxRbi-0004Rv-GQ for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:25:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRbi-0004R9-66 for discuss@apps.ietf.org; Wed, 28 Nov 2007 13:25:58 -0500 Received: from el-out-1112.google.com ([209.85.162.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxRbe-0007YG-VH for discuss@apps.ietf.org; Wed, 28 Nov 2007 13:25:58 -0500 Received: by el-out-1112.google.com with SMTP id n30so656064elf for ; Wed, 28 Nov 2007 10:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=b4rWhls1fHEdMQx4eN1UEzaNE0xnheOrpXDHZpICaBA=; b=LJKeNyVAyUXCqEveR7J7C99awXQT4HWxFLq7GQY/baNONq37OuwKazJ2U9zAG3l2f+4wj+15HZkx/ORQbzjO/1u6sfhul4iWHXAH68SMETuvxY86Oad1tZWwAQ79Cj9Ge4xuxtFjcfpSbFn4o8XOQCsz2C60xYtBheZ2t6o1NGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tm+rcIlc5wO6oaMK+5uq+B2i0vblwUj3BUGV5IKhd/QJr8yoIONXWWHIMJo5J/rk+T41Jh5vhVfg576xwQCRzQHkaJNE1PEiTgZi7G3aknU9tyx1gWF/lvUh/Sjgj0Jx3oQEUXlk+QxFfMUS/CReVXez426Xmu+DqcGGWVYeWIE= Received: by 10.142.154.20 with SMTP id b20mr1590757wfe.1196274350561; Wed, 28 Nov 2007 10:25:50 -0800 (PST) Received: by 10.142.214.15 with HTTP; Wed, 28 Nov 2007 10:25:50 -0800 (PST) Message-ID: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> Date: Wed, 28 Nov 2007 10:25:50 -0800 From: "Rohan Mahy" To: "Balazs Lengyel" Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <474D9194.3060103@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5182_2026779.1196274350548" References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_5182_2026779.1196274350548 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Comments inline. On Nov 28, 2007 8:04 AM, Balazs Lengyel wrote: > Hello, > I am no expert in RelaxNg but here are some thoughts why I like Yang > better. > > I have the feeling once you extend RelaxNg with all the necessary bits, > half your statements > will start with . We will never know unless we try the exercise. It seems you are suggesting that we don't even try. However, I see a pretty small number of additional semantic items you list below: - an indicator of a default value (if any) - a flag that indicates whether a subtree is atomic for edit-config - an indicator that the schema is an rpc method and what its matching request or response is - a flag that indicates whether a subtree is configuration or operational data (read-write or read-only). Setting that aside for a moment, even if half the statements in a schema are annotation, the other half can still do something very, very useful. They can validate the syntax and structure of the XML received on the wire automatically in a piece of code (the XML parser) that the implementation probably already has. If we decided we wanted to build something like YANG, we would still need a tool to generate valid XSD or Relax from the YANG definitions to turn on validation in the XML parser. There are many aspects that can be somewhat tricky and/or simply time > consuming, and are > missing from RelaxNg: These aspects are not *missing* from Relax NG. Some of these things are not in the scope of the Relax NG schema, but can be defined as an additional layer on top of a specific Relax schema. We can even write schema which describes what syntax is allowed for these annotations in a netconf-semantics namespace. > - what does a default mean for configuration data this is semantic. > - what is considered a compatible or incompatible change I believe I already covered this. Adding an additional choice (adding a new rpc method), adding via interleave (adding additional data within a container), and copying and redefining via restriction or addition (reusing parts of one container for a new container) are all pretty easy. > - ordering of items within list, leaf-lists The schema I described preserves ordering. > - netconf edit-config semantics semantic - differentiating between configuration and operational data semantic - differentiating between RPCs, notifications and data containers (in YANG > you have separate > statements) This is easy to do using pure syntax. As in my example, to add an RPC method or response, you just "combine with choice" and you insure that the method isn't used as a notification or a data container. > - connecting RPC request definitions with RPC reply definitions > This is semantic. I provided an example of how to link these. - definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter, > etc.). Nothing > special but work to do even for RelaxNg To me this strongly motivates using Relax for the syntax. A language to define new data types has already been invented and it works very well. - Netconf specific error messages If you are talking about error messages sent on the wire, this is a syntactic issue that Relax can handle out of the box. > Certainly all these can be done as extensions to RelaxNg as well, but even > after taking RelaxNg > as your base, you still have a big work to do. And once your specification > is complete you need > to build custom tools to understand the statements. (For YANG > we already have > tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools) Are you implying that the act of writing, review, and maintaining a brand new 150 page specification on YANG is not a lot of work? I am quite sure that a motivated group could define just the additional semantics in substantially fewer pages or text, and that there would be many more participants in the IETF who could make credible comments on it. > > -------------------------------------------------------------------------------------------- > > For NETCONF readability by operators, untrained in modeling languages, is > a crucial > requirement. The question is after how many hours (not days) of training > can an operator grok a > YANG model or a RelaxNg model? I feel YANG is easier. I am hardly a Relax expert. I glanced at the Relax tutorial and the the Relax book for just under two hours in order to start *writing* schema. I have shown relax schema to implementors with no previous experience, explained how define and ref work on the whiteboard for 5 minutes and then seen working accessors in under an hour. The W3C, OASIS, OpenGIS and others are all using Relax for all of its specifications that use XML going forward. Perhaps you should spend an hour or two and see what you are missing. > One important advantage of YANG is that the number of features in YANG is > much smaller then in > RelaxNg. This is a preposterous statement. There is no need for an operator to learn features of Relax (or XSD even) that they will never use in order to read and write schema. I do not understand the finer points of content. I don't need to currently and I can easily skip over and ignore these parts of the spec. > If we would count the number of features excluding stuff that is missing > from RelaxNg, > the difference would become even more pronounced. > > Generally YANG uses the terminology that network management people are > familiar with e.g. > container, augment, configuration data. Learning the RelaxNg terminology > takes time. Maybe I have different implementors, but the implementor is more likely to have some XML experience than to be a "network management person". Following the principle mentioned in Section 3.1 of draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and simplicity for the reader takes precedence: As a consequence, preference should be give to solutions that simplify the task of readers. Reduction of the efforts required by writers is of secondary importance and the reduction of the efforts required by tool developers is of least important preference. While this perhaps seems obvious, it is at times difficult to take according design decisions, especially if the group working on a new data modeling language is dominated by tool developers or data model writers. > In the network management world there is a general dislike for so called > "little rules". Things > like > - you can use RelaxNg but don't use attributes > - you can use RelaxNg but don't use mixed pattern > - you can use RelaxNg but don't redefine or remove patterns > > With RelaxNg we will need a number of such rules. With a problem specific > solution - YANG - > the number of such rules is minimal. > I disagree. It looks like you have lots of implicit little rules in the YANG draft. A network management person might have become desensitized to these rules to the point of not noticing them, but they are there and there are plenty of them. thanks, -rohan > > Balazs > > > Rohan Mahy wrote: > > Hi Martin, > > > > More comments inline. > > > > On Nov 27, 2007 4:03 AM, Martin Bjorklund > > wrote: > > > > Hi, > > > > "Rohan Mahy" > > wrote: > > > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and > > > thought immediately that all of the problems the draft is trying > to > > > address looked very suitable to use RELAX NG as a schema > language. > > > Looking at section F.2 (Why not RELAX NG) I did not see any > specific > > > examples motivating the apparently contradictory statements that > > Relax > > > is not expressive enough and Relax is too expressive. > [BALAZS]: Relax can say a number of things we don't need, but can't say a > number of other > things we do. If you have thousands of words for ice cream but no words > for colors then your > language is too big and too small at the same time. > > > > What we mean with this is that generic XML schema languages such as > > RelaxNG and XSD are designed to specify the grammar for (almost) any > > XML instance document. For example they both support mixed content > > and XML attributes, neither of which we use in YANG. You could of > > course just state that these constructs MUST NOT be used. > > > > > > Yes, these languages are used to define many schema that do not support > > mixed content. Defining a set of templates in Relax would make it very > > clear how the new data should be organized, and is very easy for readers > > to parse and validate with boatloads of existing tools. Most netconf > > implementors will already have an XML parser that will automatically > > validate against either XSD or Relax schema. > > > > > > None of these languages support important configuration management > > concepts like default values (XSD has a default construct, but it is > > not the same); you cannot see if a parameter represents > configuration > > or state data (since it's very domain specific). In RelaxNG there > is > > not support (by design) for integrity contraints and keys. None of > > the languages have support for specific augmentation (this is > > important e.g. for vendors to add vendor-specific stuff to standard > > data models). > > > > > > I understand that you want semantic data mixed with your syntax data. I > > don't think you need to define a new schema language to do this. Relax > > allows arbitrary annotations in other namespaces, and these annotations > > can have semantic meaning. Rather than define a whole new syntax as > > well, I am much more comfortable defining additional semantics layered > > on top of an existing schema which validates the syntax. > > > > > > We also note in the draft that both languages are extensible, and > with > > an extensible language you can add whatever you want. > > > > All this means that the existing tools might not be that simple to > > use. These tools are not aware of any restrictions on the usage > > imposed by NETCONF, and they do not understand the NETCONF-specific > > extensions. > > > > > > This is a tautological statement. The existing tools will automatically > > catch large categories of errors automatically (that's as simple as it > > gets). If you want additional semantic checking, you will define those > > rules whether you write a whole new language or not. > > > > > > Another question regarding existing tools is what exactly these > tools > > are supposed to be used for? Probably not instance document > (NETCONF > > PDU) validation, unless all elements are defined as optional, since > > e.g. in an edit-config request you just include the elements you > want > > to modify. > > > > > keyref and instance-identifier are probably better served by > > referencing > > > an 'id' attribute and using the 'ID' type > > > > The problem with the ID type is that its value is global to a > > document. If the document is the entire configuration datastore, > all > > IDs will have to be unique. Since you can reference any key (or > maybe > > even any leaf), every key (or leaf) will have to have it's own > unique > > ID. This won't scale and would be very difficult to maintain. > > > > > > In RAI we had some rather painful experience with referencing keys in > > XCAP (RFC 4825) which also uses XPath expressions to point at subparts > > or subtrees of an XML document. You can certainly maintain a unique key > > within a list which is not generated from the data in each record. Not > > doing so "won't scale and would be very difficult to maintain". > > However, this argument is orthogonal to our main topic. > > > > > > > Below, I also show examples of the YANG concepts of leaf node, > > > leaf-list, container, and list expressed in YANG, how it would be > > > expressed in NETCONF, and expressed in RELAX NG. > > > > Here's another one: > > > > in module foo: > > > > rpc my-rpc { > > input { > > leaf foo { type string; } > > } > > output { > > leaf-list bar { type int32; } > > leaf baz { type int32; } > > } > > } > > > > in module bar: > > > > augment /foo:my-rpc/foo:output { > > leaf data { type int32; } > > } > > > > > > How would this translate to RelaxNG? > > > > > > I am assuming that this would generate the following XML in Netconf: > > > > > > some string > > > > > > > > > > 4134 > > 3882 > > 112334 > > 82382 > > > > > > I was not clear exactly the significance of "module foo" and "module > > bar". If I understood correctly, module foo defines the "my-rpc" RPC > > call, and module bar just extends the response. I will call these " > > my-rpc.rng" and "my-rpc-extension1.rng" respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > my-rpc > > > > > > > > > > > > > > > > > > > > > > > > my-rpc > > > > > > Note that I used a Relax annotation to convey extra semantic data. This > > is ignored during relax syntax validation, but available to the > > implementation if it wants to use this additional semantic information. > > An example of this is described in the book in chapter 13.3: > > http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html > > > > The "augment" is accomplished using a define with interleave: > > > > > > > > > > > > > > > > > > > > > > > > Finally, if you are allergic to angle brackets, you can do all this in > > compact form as well: > > > > # my-rpc.rnc > > include "netconf-rpc.rnc" > > rpc-requests |= element foo { xsd:string } > > rpc-responses |= { > > element bar { xsd:int }+, > > element baz { xsd:int } > > } > > > > # my-rpc-extension1.rnc > > include "my-rpc.rnc" > > my-rpc-response &= element data { xsd:int } > > > > > > For a more full example, I invite you to look at how Jari Urpalainen did > > this for the PIDF family of XML schemas to allow full automatic syntax > > validation. While his draft is recently expired, I have archived a copy > > here: > > > http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt > > < > http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt > > > > > > Also section 10.2 "Merging Grammars" in the Relax NG book describes this > > very nicely: > > http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html > > > > > > thanks, > > -rohan > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > ------=_Part_5182_2026779.1196274350548 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Comments inline.

On Nov 28, 2007 8:04 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello,
I am no expert in RelaxNg but here are some thoughts why I like Yang better.

I have the feeling once you extend RelaxNg with all the necessary bits, half your statements
will start with <other:xxx>.

We will never know unless we try the exercise. It seems you are suggesting that we don't even try. However, I see a pretty small number of additional semantic items you list below:
- an indicator of a default value (if any)
- a flag that indicates whether a subtree is atomic for edit-config
- an indicator that the schema is an rpc method and what its matching request or response is
- a flag that indicates whether a subtree is configuration or operational data (read-write or read-only).

Setting that aside for a moment, even if half the statements in a schema are annotation, the other half can still do something very, very useful.  They can validate the syntax and structure of the XML received on the wire automatically in a piece of code (the XML parser) that the implementation probably already has. 

If we decided we wanted to build something like YANG, we would still need a tool to generate valid XSD or Relax from the YANG definitions to turn on validation in the XML parser.

There are many aspects that can be somewhat tricky and/or simply time consuming, and are
missing from RelaxNg:

These aspects are not *missing* from Relax NG.  Some of these things are not in the scope of the Relax NG schema, but can be defined as an additional layer on top of a specific Relax schema.  We can even write schema which describes what syntax is allowed for these annotations in a netconf-semantics namespace.
 
- what does a default mean for configuration data

this is semantic.
 
- what is considered a compatible or incompatible change

I believe I already covered this. Adding an additional choice (adding a new rpc method), adding via interleave (adding additional data within a container), and copying and redefining via restriction or addition (reusing parts of one container for a new container) are all pretty easy.
 
- ordering of items within list, leaf-lists

The schema I described preserves ordering.
 
- netconf edit-config semantics

semantic

- differentiating between configuration and operational data

semantic

- differentiating between RPCs, notifications and data containers (in YANG you have separate
statements)

This is easy to do using pure syntax.  As in my example, to add an RPC method or response, you just "combine with choice" and you insure that the method isn't used as a notification or a data container.
 
- connecting RPC request definitions with RPC reply definitions
 
This is semantic.  I provided an example of how to link these.

- definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter, etc.). Nothing
special but work to do even for RelaxNg

To me this strongly motivates using Relax for the syntax. A language to define new data types has already been invented and it works very well.

- Netconf specific error messages

If you are talking about error messages sent on the wire, this is a syntactic issue that Relax can handle out of the box.
 
Certainly all these can be done as extensions to RelaxNg as well, but even after taking RelaxNg
as your base, you still have a big work to do. And once your specification is complete you need
to build custom tools to understand the <other:xxx> statements. (For YANG we already have
tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools)

Are you implying that the act of writing, review, and maintaining a brand new 150 page specification on YANG is not a lot of work?  I am quite sure that a motivated group could define just the additional semantics in substantially fewer pages or text, and that there would be many more participants in the IETF who could make credible comments on it.

 
--------------------------------------------------------------------------------------------

For NETCONF readability by operators, untrained in modeling languages, is a crucial
requirement. The question is after how many hours (not days) of training can an operator grok a
YANG model or a RelaxNg model? I feel YANG is easier.

I am hardly a Relax expert. I glanced at the Relax tutorial and the the Relax book for just under two hours in order to start *writing* schema.  I have shown relax schema to implementors with no previous experience, explained how define and ref work on the whiteboard for 5 minutes and then seen working accessors in under an hour.  The W3C, OASIS, OpenGIS and others are all using Relax for all of its specifications that use XML going forward. Perhaps you should spend an hour or two and see what you are missing.
 
One important advantage of YANG is that the number of features in YANG is much smaller then in
RelaxNg.

This is a preposterous statement. There is no need for an operator to learn features of Relax (or XSD even) that they will never use in order to read and write schema. I do not understand the finer points of <mixed> content. I don't need to currently and I can easily skip over and ignore these parts of the spec.
 
If we would count the number of features excluding stuff that is missing from RelaxNg,
  the difference would become even more pronounced.

Generally YANG uses the terminology that network management people are familiar with e.g.
container, augment, configuration data. Learning the RelaxNg terminology takes time.

Maybe I have different implementors, but the implementor is more likely to have some XML experience than to be a "network management person".  Following the principle mentioned in Section 3.1 of draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and simplicity for the reader takes precedence:

   As a consequence, preference should be give to solutions that
   simplify the task of readers.  Reduction of the efforts required by
   writers is of secondary importance and the reduction of the efforts
   required by tool developers is of least important preference.  While
   this perhaps seems obvious, it is at times difficult to take
   according design decisions, especially if the group working on a new
   data modeling language is dominated by tool developers or data model
   writers.

 
In the network management world there is a general dislike for so called "little rules". Things
like
- you can use RelaxNg but don't use attributes
- you can use RelaxNg but don't use mixed pattern
- you can use RelaxNg but don't redefine or remove patterns

With RelaxNg we will need a number of such rules. With a problem specific solution - YANG -
the number of such rules is minimal.

I disagree. It looks like you have lots of implicit little rules in the YANG draft. A network management person might have become desensitized to these rules to the point of not noticing them, but they are there and there are plenty of them.

thanks,
-rohan
 

Balazs


Rohan Mahy wrote:
> Hi Martin,
>
> More comments inline.
>
> On Nov 27, 2007 4:03 AM, Martin Bjorklund <mbj@tail-f.com
> <mailto: mbj@tail-f.com>> wrote:
>
>     Hi,
>
>     "Rohan Mahy" <rohan.mahy@gmail.com <mailto: rohan.mahy@gmail.com>> wrote:
>      > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and
>      > thought immediately that all of the problems the draft is trying to
>      > address looked very suitable to use RELAX NG as a schema language.
>      > Looking at section F.2 (Why not RELAX NG) I did not see any specific
>      > examples motivating the apparently contradictory statements that
>     Relax
>      > is not expressive enough and Relax is too expressive.
[BALAZS]: Relax can say a number of things we don't need, but can't say a number of other
things we do. If you have thousands of words for ice cream but no words for colors then your
language is too big and too small at the same time.
>
>     What we mean with this is that generic XML schema languages such as
>     RelaxNG and XSD are designed to specify the grammar for (almost) any
>     XML instance document.  For example they both support mixed content
>     and XML attributes, neither of which we use in YANG.  You could of
>     course just state that these constructs MUST NOT be used.
>
>
> Yes, these languages are used to define many schema that do not support
> mixed content. Defining a set of templates in Relax would make it very
> clear how the new data should be organized, and is very easy for readers
> to parse and validate with boatloads of existing tools.  Most netconf
> implementors will already have an XML parser that will automatically
> validate against either XSD or Relax schema.
>
>
>     None of these languages support important configuration management
>     concepts like default values (XSD has a default construct, but it is
>     not the same); you cannot see if a parameter represents configuration
>     or state data (since it's very domain specific).  In RelaxNG there is
>     not support (by design) for integrity contraints and keys.  None of
>     the languages have support for specific augmentation (this is
>     important e.g. for vendors to add vendor-specific stuff to standard
>     data models).
>
>
> I understand that you want semantic data mixed with your syntax data. I
> don't think you need to define a new schema language to do this. Relax
> allows arbitrary annotations in other namespaces, and these annotations
> can have semantic meaning.  Rather than define a whole new syntax as
> well, I am much more comfortable defining additional semantics layered
> on top of an existing schema which validates the syntax.
>
>
>     We also note in the draft that both languages are extensible, and with
>     an extensible language you can add whatever you want.
>
>     All this means that the existing tools might not be that simple to
>     use.  These tools are not aware of any restrictions on the usage
>     imposed by NETCONF, and they do not understand the NETCONF-specific
>     extensions.
>
>
> This is a tautological statement. The existing tools will automatically
> catch large categories of errors automatically (that's as simple as it
> gets). If you want additional semantic checking, you will define those
> rules whether you write a whole new language or not.
>
>
>     Another question regarding existing tools is what exactly these tools
>     are supposed to be used for?  Probably not instance document (NETCONF
>     PDU) validation, unless all elements are defined as optional, since
>     e.g. in an edit-config request you just include the elements you want
>     to modify.
>
>      > keyref and instance-identifier are probably better served by
>     referencing
>      > an 'id' attribute and using the 'ID' type
>
>     The problem with the ID type is that its value is global to a
>     document.  If the document is the entire configuration datastore, all
>     IDs will have to be unique.  Since you can reference any key (or maybe
>     even any leaf), every key (or leaf) will have to have it's own unique
>     ID.  This won't scale and would be very difficult to maintain.
>
>
> In RAI we had some rather painful experience with referencing keys in
> XCAP (RFC 4825) which also uses XPath expressions to point at subparts
> or subtrees of an XML document. You can certainly maintain a unique key
> within a list which is not generated from the data in each record.  Not
> doing so "won't scale and would be very difficult to maintain".
> However, this argument is orthogonal to our main topic.
>
>
>      > Below, I also show examples of the YANG concepts of leaf node,
>      > leaf-list, container, and list expressed in YANG, how it would be
>      > expressed in NETCONF, and expressed in RELAX NG.
>
>     Here's another one:
>
>     in module foo:
>
>       rpc my-rpc {
>         input {
>           leaf foo { type string; }
>         }
>         output {
>           leaf-list bar { type int32; }
>           leaf baz      { type int32; }
>         }
>       }
>
>     in module bar:
>
>      augment /foo:my-rpc/foo:output {
>         leaf data { type int32; }
>      }
>
>
>     How would this translate to RelaxNG?
>
>
> I am assuming that this would generate the following XML in Netconf:
> <rpc message-id="45">
>   <my-rpc>
>     <foo>some string</foo>
>   </my-prc>
> </rpc>
>
> <rpc-result message-id="45">
>   <bar>4134</bar>
>   <bar>3882</bar>
>   <baz>112334</baz>
>   <data>82382</data>
> </rpc-result>
>
> I was not clear exactly the significance of "module foo" and "module
> bar".  If I understood correctly, module foo defines the "my-rpc" RPC
> call, and module bar just extends the response.  I will call these "
> my-rpc.rng" and  "my-rpc-extension1.rng" respectively.
>
>
> <!-- my-rpc.rng  -->
> <include href=" netconf-rpc.rng"/>
>
> <define name="rpc-requests" combine="choice">
>   <ref name="my-rpc-request"/>
> </define>
>
> <define name="rpc-responses" combine="choice">
>   <ref name="my-rpc-response"/>
> </define>
>
> <define name="my-rpc-request">
>   <element name="foo">
>     <data type="string"/>
>   </element>
>   <netconf:rpc-method type="request">my-rpc</netconf:rpc-method>
> </define>
>
> <define name="my-rpc-response">
>   <oneOrMore>
>     <element name="bar">
>       <data type="int"/>
>     </element>
>   </oneOrMore>
>   <element name="baz">
>     <data type="int"/>
>   </element>
>   <netconf:rpc-method type="response">my-rpc</netconf:rpc-method>
> </define>
>
> Note that I used a Relax annotation to convey extra semantic data.  This
> is ignored during relax syntax validation, but available to the
> implementation if it wants to use this additional semantic information.
> An example of this is described in the book in chapter 13.3:
> http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html
>
> The "augment" is accomplished using a define with interleave:
>
> <!-- my-rpc-extension1.rng -->
>
> <include href="my-rpc.rng"/>
>
> <define name="my-rpc-response" combine="interleave">
>   <element name="data">
>     <data type="int"/>
>   </element>
> </define>
>
> Finally, if you are allergic to angle brackets, you can do all this in
> compact form as well:
>
> # my-rpc.rnc
> include "netconf-rpc.rnc"
> rpc-requests |= element foo { xsd:string }
> rpc-responses |= {
>   element bar { xsd:int }+,
>   element baz { xsd:int }
> }
>
> # my-rpc-extension1.rnc
> include "my-rpc.rnc"
> my-rpc-response &= element data { xsd:int }
>
>
> For a more full example, I invite you to look at how Jari Urpalainen did
> this for the PIDF family of XML schemas to allow full automatic syntax
> validation. While his draft is recently expired, I have archived a copy
> here:
> http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt
> < http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt>
>
> Also section 10.2 "Merging Grammars" in the Relax NG book describes this
> very nicely:
> http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html
> < http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html>
>
> thanks,
> -rohan

--
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

------=_Part_5182_2026779.1196274350548-- From discuss-bounces@apps.ietf.org Wed Nov 28 17:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUzp-0005cK-QP; Wed, 28 Nov 2007 17:03:05 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxUzo-0005cA-MQ for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUzo-0005c2-CU for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:03:04 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxUzl-00065I-ES for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:03:04 -0500 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id EBD6A1B80C5; Wed, 28 Nov 2007 23:02:57 +0100 (CET) Date: Wed, 28 Nov 2007 23:02:44 +0100 (CET) Message-Id: <20071128.230244.254578150.mbj@tail-f.com> To: rohan.mahy@gmail.com Subject: Re: analysis of YANG vs. RELAX NG From: Martin Bjorklund In-Reply-To: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, "Rohan Mahy" wrote: > Setting that aside for a moment, even if half the statements in a schema are > annotation, the other half can still do something very, very useful. They > can validate the syntax and structure of the XML received on the wire > automatically in a piece of code (the XML parser) that the implementation > probably already has. Note that in order to validate the different NETCONF messages, you would either need more than one schema, or a very lax schema which will validate messages/documents which are not actually valid NETCONF. As one very simple example, suppose we have these in the data model: leaf ifAdminStatus { config true; type ...; } leaf ifOperStatus { config false; type ...; } In a only ifAdminStatus can occur. In a both can occur. In an , there can be an nc:operation attribute on the ifAdminStatus, but that attribute cannot be present in a . > If we decided we wanted to build something like YANG, we would still need a > tool to generate valid XSD or Relax from the YANG definitions to turn on > validation in the XML parser. One such tool is available from www.yang-central.org. It currently supports a single XSD output, but adding e.g. RelaxNG should be possible. YANG is based on three different vendor-specific languages, which all three have tools that generate XSD. Three of the people in the YANG gang have existing NETCONF implementations. None of these implementations are actually using XSD or RelaxNG to do validation in the parser, (partly) for the reasons listed above. [...] > These aspects are not *missing* from Relax NG. Some of these things are not > in the scope of the Relax NG schema, but can be defined as an additional > layer on top of a specific Relax schema. In my experience, people who design data models for device configuration and monitoring do not typically think in terms of patterns which match an XML instance document. Instead they might think in terms of objects with certain attributes, operations and notifications, or in terms of a hierarchical structure of config parameters. From an operator perspective I also believe (although I don't really know) that it's more common to think about which config parameters can be set, than which patterns might match some virtual XML instance document. Thus, IMO a domain specific language with a smaller semantic gap between the language and how people think about and understand the problem will be more appropriate. /martin From discuss-bounces@apps.ietf.org Wed Nov 28 17:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVdE-0007Dn-2O; Wed, 28 Nov 2007 17:43:48 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxVdD-0007Dh-9a for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVdD-0007DZ-03 for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:43:47 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVdC-0007iU-Gc for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:43:46 -0500 Received: by nz-out-0506.google.com with SMTP id v1so1093820nzb for ; Wed, 28 Nov 2007 14:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=HnEssfXdDmXQmcsNRH9x9FHKHE8QKUP8VJlwChLBpxc=; b=jyUaS0bmM0U1Ln0MEEDhoJGwpOd1SajHhqYO5MIuRmXEnUYnIR+Ltx6g+zV9eTRkl2ljgBPoM42ZQCqan38HOBkpiWLJdi0vOyWglRzuQ1dn1bcjpWfqmrkejt7k0bLRaPMd2LGROt0JSXpAO+11KOMAHiU+mcl2juZTIn0Um34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pt4kvPKlyw01AQ1BrxF0JpLmdhxOghKAKLN+M8Gi4NJ3R1cMMphBVNUQeKk9wb8ihLZjgOJwzJkKYIaK6tnVyjbY70lr4/NnHRUB8mr9rlk/cZTIzVh3w7cc9ygKrJj1qWMSNEf5OYh1lKDcaf+uTP0ucweKzvxwYbYG0XPhcTs= Received: by 10.142.127.10 with SMTP id z10mr395049wfc.1196289825196; Wed, 28 Nov 2007 14:43:45 -0800 (PST) Received: by 10.142.214.15 with HTTP; Wed, 28 Nov 2007 14:43:45 -0800 (PST) Message-ID: <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> Date: Wed, 28 Nov 2007 14:43:45 -0800 From: "Rohan Mahy" To: "Martin Bjorklund" Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <20071128.230244.254578150.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6608_16830146.1196289825208" References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_6608_16830146.1196289825208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Martin, On Nov 28, 2007 2:02 PM, Martin Bjorklund wrote: > Hi, > > "Rohan Mahy" wrote: > > Setting that aside for a moment, even if half the statements in a schema > are > > annotation, the other half can still do something very, very useful. > They > > can validate the syntax and structure of the XML received on the wire > > automatically in a piece of code (the XML parser) that the > implementation > > probably already has. > > Note that in order to validate the different NETCONF messages, you > would either need more than one schema, or a very lax schema which > will validate messages/documents which are not actually valid NETCONF. > As one very simple example, suppose we have these in the data model: > > leaf ifAdminStatus { > config true; > type ...; > } > leaf ifOperStatus { > config false; > type ...; > } > > In a only ifAdminStatus can occur. In a both can > occur. In an , there can be an nc:operation attribute on > the ifAdminStatus, but that attribute cannot be present in a . You can express this very easily like this: or in short form: get-config &= ifAdminStatus get &= ifAdminStatus get &= ifOperStatus thanks, -rohan ------=_Part_6608_16830146.1196289825208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Martin,

On Nov 28, 2007 2:02 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

"Rohan Mahy" <rohan.mahy@gmail.com> wrote:
> Setting that aside for a moment, even if half the statements in a schema are
> annotation, the other half can still do something very, very useful.  They
> can validate the syntax and structure of the XML received on the wire
> automatically in a piece of code (the XML parser) that the implementation
> probably already has.

Note that in order to validate the different NETCONF messages, you
would either need more than one schema, or a very lax schema which
will validate messages/documents which are not actually valid NETCONF.
As one very simple example, suppose we have these in the data model:

  leaf ifAdminStatus {
     config true;
     type ...;
  }
  leaf ifOperStatus {
     config false;
     type ...;
  }

In a <get-config> only ifAdminStatus can occur.  In a <get> both can
occur.  In an <edit-config>, there can be an nc:operation attribute on
the ifAdminStatus, but that attribute cannot be present in a <get>.

You can express this very easily like this:

<define name="get-config" combine="interleave">
  <ref name="ifAdminStatus"/>
</define>

<define name="get" combine="interleave">
  <ref name="ifAdminStatus"/>
</define>

<define name="get" combine="interleave">
  <ref name="ifOperStatus"/>
</define>

or in short form:

get-config &= ifAdminStatus
get &= ifAdminStatus
get &= ifOperStatus


thanks,
-rohan
------=_Part_6608_16830146.1196289825208-- From discuss-bounces@apps.ietf.org Wed Nov 28 17:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVq2-0002mV-Oh; Wed, 28 Nov 2007 17:57:02 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxVq0-0002mP-Pv for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:57:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVq0-0002mH-G9 for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:57:00 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVpy-0008De-OO for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:57:00 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4BC38A1C3; Wed, 28 Nov 2007 23:56:57 +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 21038-03; Wed, 28 Nov 2007 23:56:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62CF68A1A7; Wed, 28 Nov 2007 23:56:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 08777401C09; Wed, 28 Nov 2007 23:56:52 +0100 (CET) Date: Wed, 28 Nov 2007 23:56:52 +0100 From: Juergen Schoenwaelder To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071128225652.GA10228@elstar.local> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> 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: 8abaac9e10c826e8252866cbe6766464 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, Nov 28, 2007 at 02:43:45PM -0800, Rohan Mahy wrote: > You can express this very easily like this: > > > > > > > > > > > > > > or in short form: > > get-config &= ifAdminStatus > get &= ifAdminStatus > get &= ifOperStatus You are suggesting to extend the definition of the NETCONF operations get, get-config, edit-config etc. for every possible data item they might carry? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Wed Nov 28 17:57:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVqv-0003JI-9t; Wed, 28 Nov 2007 17:57:57 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxVqu-0003JC-BD for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVqu-0003IK-0q for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:57:56 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVqr-0008FW-Fl for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:57:56 -0500 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 7ADFF1B80C5; Wed, 28 Nov 2007 23:57:52 +0100 (CET) Date: Wed, 28 Nov 2007 23:57:50 +0100 (CET) Message-Id: <20071128.235750.175042294.mbj@tail-f.com> To: rohan.mahy@gmail.com Subject: Re: analysis of YANG vs. RELAX NG From: Martin Bjorklund In-Reply-To: <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> References: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, "Rohan Mahy" wrote: > Hi Martin, > > On Nov 28, 2007 2:02 PM, Martin Bjorklund wrote: > > > Hi, > > > > "Rohan Mahy" wrote: > > > Setting that aside for a moment, even if half the statements in a schema > > are > > > annotation, the other half can still do something very, very useful. > > They > > > can validate the syntax and structure of the XML received on the wire > > > automatically in a piece of code (the XML parser) that the > > implementation > > > probably already has. > > > > Note that in order to validate the different NETCONF messages, you > > would either need more than one schema, or a very lax schema which > > will validate messages/documents which are not actually valid NETCONF. > > As one very simple example, suppose we have these in the data model: > > > > leaf ifAdminStatus { > > config true; > > type ...; > > } > > leaf ifOperStatus { > > config false; > > type ...; > > } > > > > In a only ifAdminStatus can occur. In a both can > > occur. In an , there can be an nc:operation attribute on > > the ifAdminStatus, but that attribute cannot be present in a . > > > You can express this very easily like this: > > > > > > > > > > > > > > or in short form: > > get-config &= ifAdminStatus > get &= ifAdminStatus > get &= ifOperStatus But then you also have edit-config, where the nc:operation attribute has to be added for ifAdminStatus, and you have copy-config where the attribute must not be added. So you would have to explicitly add each leaf to these four rpcs...? And I'm not even sure this approach would work for deep structures, where some leafs are config and some are not: container interfaces { leaf ifNumber { config false; type int32; } list interface { key ifIndex; leaf ifIndex { type uint32; } leaf ifAdminStatus { config true; ... } leaf ifOperStatus { config false; ... } ... } } /martin From discuss-bounces@apps.ietf.org Wed Nov 28 18:34:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWQ5-0005ea-CA; Wed, 28 Nov 2007 18:34:17 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxWQ3-0005eP-Sk for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:34:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWQ3-0005eG-IH for discuss@apps.ietf.org; Wed, 28 Nov 2007 18:34:15 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWQ2-0001EO-1B for discuss@apps.ietf.org; Wed, 28 Nov 2007 18:34:15 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77BA1142206; Wed, 28 Nov 2007 15:34:14 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGE706XWYTB1; Wed, 28 Nov 2007 15:34:09 -0800 (PST) Received: from [192.168.1.103] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C84AF1421FD; Wed, 28 Nov 2007 15:34:08 -0800 (PST) In-Reply-To: <20071128.230244.254578150.mbj@tail-f.com> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-12--1057685930 Message-Id: <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> From: Lisa Dusseault Subject: Re: analysis of YANG vs. RELAX NG Date: Wed, 28 Nov 2007 15:34:06 -0800 To: Martin Bjorklund X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-12--1057685930 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This is another aspect I'd like to understand better: On Nov 28, 2007, at 2:02 PM, Martin Bjorklund wrote: > Note that in order to validate the different NETCONF messages, you > would either need more than one schema, or a very lax schema which > will validate messages/documents which are not actually valid NETCONF. Validating XML really limits the customizability, the very extensibility of the XML. You can't add so much as a or element without it failing at the other end. Is the goal here to strictly limit netconf data to only standardized and implemented schemas? thanks, lisa --Apple-Mail-12--1057685930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 This is another aspect I'd like = to understand better:

On Nov 28, 2007, at 2:02 PM, = Martin Bjorklund wrote:

Note that in order to = validate the different NETCONF messages, you

would either need more than = one schema, or a very lax schema which

will validate messages/documents which = are not actually valid NETCONF.

=

Validating XML really limits the = customizability, the very extensibility of the XML.=A0 You can't add so = much as a <custom-text-description> or <debug-info-only> = element without it failing at the other end.=A0 Is the goal here to = strictly limit netconf data to only standardized and implemented = schemas?=A0=A0

thanks,
lisa
<= /BODY>= --Apple-Mail-12--1057685930-- From discuss-bounces@apps.ietf.org Wed Nov 28 20:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXmw-00025w-T3; Wed, 28 Nov 2007 20:01:58 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxXmv-00025M-2m for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXmu-00024v-MN for discuss@apps.ietf.org; Wed, 28 Nov 2007 20:01:56 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxXms-0004Fh-Vb for discuss@apps.ietf.org; Wed, 28 Nov 2007 20:01:56 -0500 Received: (qmail 26228 invoked from network); 29 Nov 2007 01:01:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.121.107.88 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2007 01:01:53 -0000 X-YMail-OSG: lskllUoVM1kEpRYjBQCAW6.I7esQD27gQCg_xjT2Jkz9.zHsKRKiKyatICCmIWMwAQidk0mlXo3ldbs2j7O1wCg. Message-ID: <474E0F71.2050003@andybierman.com> Date: Wed, 28 Nov 2007 17:01:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Why NETCONF needs a data modeling language Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: yang@ietf.org, NETCONF Goes On X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, There are a few questions that the IESG and others have asked, which I will try to address: Q1) Why does NETCONF need a DML at all? Q2) Why is NETCONF special? Q3) Why won't lots of other WGs want to define their own protocol-specific DMLs? Q4) Why isn't XSD or RelaxNG good enough? A1) NETCONF needs a formal description of the conceptual data within a NETCONF configuration database, in order to facilitate inter-operable implementations of NETCONF-related tools, such as agents, managers, and translators. A textual representation is needed, to easily integrate semantic and syntactic information, in one file. Translation or separation would introduce errors. A protocol-specific data model definition is much more than an XML instance document description. NETCONF needs its own MIB language, just like SNMP needs SMIv2. If vendors were given an information model instead of a data model, then they would be free to invent their own data model mappings. This would be a disaster for multi-vendor interoperability. Without a single, authoritative, precise definition of the syntax and semantics wrt/ NETCONF protocol handling, it is impossible for 3rd party application developers to even attempt to support NETCONF. A2) NETCONF is a network management protocol, like SNMP. It happens to use XML encoding and Xpath filtering, but it is a network management protocol. As such, network operators need to understand the conceptual management data available on a device (just like the CLI or the MIBs). XSD and RelaxNG are both complicated. Network operators are probably not trained programmers like protocol developers. There are way more operators than there are protocol developers, and they are much less likely to be involved in the standards process, than the protocol developer. The NETCONF WG evaluated XSD and RelaxNG last year. Examples of data models including the DIFFSERV Info Model were examined. Nobody got excited about RNG. For a real data model, RNG seemed to be just as impenetrable as XSD. Data model development in the NETCONF WG has been brutally slow with XSD. XSD is a good language to use if you want to spend a long time learning what to do, and then spend a long time fixing what you did wrong. Relatively few WG members have actually been able to learn either XSD or RNG. Unlike other protocols that might use XML, a NETCONF data model is likely to be orders of magnitude larger. So there is lots more data, that needs to be understood by lots of non-programmers. A3) If there are other WGs in the IETF who happen to use XML for representation of conceptual configuration databases, then I suppose they might ask for a new DML. I suppose they will have to justify their request, no different than creating a new protocol in the first place. If they are just using XML to define fairly static protocol PDUs, then XSD or RNG should be used instead. A4) A YANG data model defines conceptual data within a NETCONF agent, just like SMIv2 does for SNMP. It does not just define valid PDUs, like other protocols. Instead, the specialized DML provides a concise description of all conceivable protocol behavior related to the management data. XSD and RNG do not even distinguish between read-only and read-write data. They are clearly not intended to be used a DMLs for conceptual datastores, like those found in SNMP or NETCONF. Instead, they describes XML instance documents. I have implemented a NETCONF agent, and IMO, 'standard' validation tools are useless. Since and allow an almost infinite combination of actual PDUs, the only thing these tools can do is identify and reject 'junk' namespaces and element names not supported by the agent. They cannot help at all with validating or automating NETCONF protocol operations or generating responses. YANG describes NETCONF configuration databases. IMO, YANG is way more readable than RelaxNG, but that is subjective. The SMIng WG got hung up for a long time trying to define objective criteria to evaluate DMLs, but in the end this was a total failure. For more information on how NETCONF uses XML, see sec. 1.2 of: http://www.ietf.org/internet-drafts/draft-bierman-ncx-smi-00.txt Andy From discuss-bounces@apps.ietf.org Wed Nov 28 20:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxYFy-0002Mw-W4; Wed, 28 Nov 2007 20:31:58 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxYFy-0002Mq-1s for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:31:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxYFx-0002Mh-OX for discuss@apps.ietf.org; Wed, 28 Nov 2007 20:31:57 -0500 Received: from el-out-1112.google.com ([209.85.162.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxYFx-0005CU-Cu for discuss@apps.ietf.org; Wed, 28 Nov 2007 20:31:57 -0500 Received: by el-out-1112.google.com with SMTP id n30so722188elf for ; Wed, 28 Nov 2007 17:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=C/eRnQUd/BtLRjRKUBjCTxAJKLcJ08hGBT41BK9LQ6E=; b=NJza6pwcEqV3TG94XItIEwDeHZrNK6O0CgFX6SE/x2lI6HINtM7+tPSGX9flUlH0y8e16Z1VT3+ver3Q10fR9du5znbn5vqmMkOtPUmn7pSPa5DsHhnvOZPI6zCyYGAmeasieIedYo0qAYNkMHJF9t+K0isSyh5xOKtUMByMB00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XUvk//ueqJAk4jHMpGQrUpnM69c/aMOqtts4TzhCHE8ZeDd6kjNdMRObsecfXNzYxiL0EeNYjJ9K7isEyfUBccORb/GavYaJC0JRgq2XEan6GWRQUh7+XTN7i6NaCJ9uH3Z2fp2nOwJPhj5Ml3nwlN+N7XActUDXQd9dSJWB3UM= Received: by 10.142.239.11 with SMTP id m11mr1742843wfh.1196299916167; Wed, 28 Nov 2007 17:31:56 -0800 (PST) Received: by 10.142.214.15 with HTTP; Wed, 28 Nov 2007 17:31:56 -0800 (PST) Message-ID: <953beacc0711281731p37007a69wc3923ed88cfba224@mail.gmail.com> Date: Wed, 28 Nov 2007 17:31:56 -0800 From: "Rohan Mahy" To: j.schoenwaelder@jacobs-university.de Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <20071128225652.GA10228@elstar.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7171_14561445.1196299916143" References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> <20071128225652.GA10228@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_7171_14561445.1196299916143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Juergen, On Nov 28, 2007 2:56 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Nov 28, 2007 at 02:43:45PM -0800, Rohan Mahy wrote: > > > You can express this very easily like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > or in short form: > > > > get-config &= ifAdminStatus > > get &= ifAdminStatus > > get &= ifOperStatus > > You are suggesting to extend the definition of the NETCONF operations > get, get-config, edit-config etc. for every possible data item they > might carry? I am suggesting that an implementation "extend" the definition of each netconf operation to include each top-level data item they actually understand and use. I hope you see the distinction. thanks, -rohan ------=_Part_7171_14561445.1196299916143 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Juergen,

On Nov 28, 2007 2:56 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Nov 28, 2007 at 02:43:45PM -0800, Rohan Mahy wrote:

> You can express this very easily like this:
>
> <define name="get-config" combine="interleave">
>   <ref name="ifAdminStatus"/>
> </define>
>
> <define name="get" combine="interleave">
>   <ref name="ifAdminStatus"/>
> </define>
>
> <define name="get" combine="interleave">
>   <ref name="ifOperStatus"/>
> </define>
>
> or in short form:
>
> get-config &= ifAdminStatus
> get &= ifAdminStatus
> get &= ifOperStatus

You are suggesting to extend the definition of the NETCONF operations
get, get-config, edit-config etc. for every possible data item they
might carry?

I am suggesting that an implementation "extend" the definition of each netconf operation to include each top-level data item they actually understand and use.  I hope you see the distinction.

thanks,
-rohan
------=_Part_7171_14561445.1196299916143-- From discuss-bounces@apps.ietf.org Wed Nov 28 23:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixapr-000332-0s; Wed, 28 Nov 2007 23:17:11 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixapp-00032a-Ve for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 23:17:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixapp-00032R-KH for discuss@apps.ietf.org; Wed, 28 Nov 2007 23:17:09 -0500 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixapm-0002yA-CM for discuss@apps.ietf.org; Wed, 28 Nov 2007 23:17:09 -0500 Received: by wr-out-0506.google.com with SMTP id 70so1355145wra for ; Wed, 28 Nov 2007 20:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=6Ed99SuaAimYpZMgXj2FdqvVWDrdzz7mwQouGVxHDt8=; b=wwhynZm+0nloWeyVHzofFvT9ntKnUax4leP0ouHwiSSL64+vPLgcrw5+ve+QDU/37S+hNITWm7mnYJSnS2xwOagdsQ1rC9Bj65WDMah1B/rn2sba/RZmHgqcWx0LBbtr0Un1BiwSAGkTGJIa30s8WO7PUBy/6vkYKQcSSm4w3ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=oCJO2t8buvQ/5zP23rlcGvrUSoKU2HKPsp70/CoUycK/rHo4UiKWKUzCWBebzLxDPwaJQ99BESs8W3zd7H0RVC4QeIcQpAu5gW6xpOBeLoh69NA7onhFsXLzjtMMXiWgw0oQ/bzyo9CP1H+DOUSPk4WJ7GKmWa5ubz4rH2XlN9g= Received: by 10.142.128.6 with SMTP id a6mr1758191wfd.1196309824611; Wed, 28 Nov 2007 20:17:04 -0800 (PST) Received: by 10.142.214.15 with HTTP; Wed, 28 Nov 2007 20:17:04 -0800 (PST) Message-ID: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> Date: Wed, 28 Nov 2007 20:17:04 -0800 From: "Rohan Mahy" To: "Andy Bierman" Subject: Re: Why NETCONF needs a data modeling language In-Reply-To: <474E0F71.2050003@andybierman.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7641_25750232.1196309824605" References: <474E0F71.2050003@andybierman.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_7641_25750232.1196309824605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Andy, I want to comment first on one specific aspect of your message. You talk about XSD and Relax as if they are somehow similar in complexity. XSD is an absolutely terrible schema definition language. It is hard to read, harder to write, and extremely inflexible when it comes to schema extensibility. The W3C no longer uses XSD because it is an absolutely awful PITA. They use Relax NG instead because it is actually pleasant to use, has a nice extensibility model, and it is easy to learn and to use. I have some additional comments inline. On Nov 28, 2007 5:01 PM, Andy Bierman wrote: > Hi, > > There are a few questions that the IESG and others have asked, > which I will try to address: > > Q1) Why does NETCONF need a DML at all? > Q2) Why is NETCONF special? > Q3) Why won't lots of other WGs want to define their own > protocol-specific DMLs? > Q4) Why isn't XSD or RelaxNG good enough? > > > > A1) > > NETCONF needs a formal description of the conceptual data > within a NETCONF configuration database, in order to facilitate > inter-operable implementations of NETCONF-related tools, > such as agents, managers, and translators. Agreed. A textual representation is needed, to easily integrate > semantic and syntactic information, in one file. Translation > or separation would introduce errors. Letting this one sit. > A protocol-specific data model definition is much more > than an XML instance document description. I agree. > NETCONF needs > its own MIB language, just like SNMP needs SMIv2. I don't think you've made a strong case here. You might be right, but your statements above do not strongly motivate a new language. I don't think we can take it on blind faith that we need to do things in Netconf the way SNMP did them. I think it is very important to look at the reasons we thought that SNMP needed to be a certain way, but we also need to acknowledge that SNMP was hardly a success as a configuration protocol, and try to find out why. It is possible that the data model was too rigid for practical configuration use. If vendors were given an information model instead of a data model, > then they would be free to invent their own data model mappings. > This would be a disaster for multi-vendor interoperability. > Without a single, authoritative, precise definition of the > syntax and semantics wrt/ NETCONF protocol handling, it is > impossible for 3rd party application developers to even attempt > to support NETCONF. How do you see NETCONF playing out differently from the LDAP experience? Do you think that LDAP has been a success as an interoperable protocol? > A2) > > NETCONF is a network management protocol, like SNMP. > It happens to use XML encoding and Xpath filtering, > but it is a network management protocol. As such, > network operators need to understand the conceptual > management data available on a device (just like the CLI or the MIBs). > > XSD and RelaxNG are both complicated. I think XSD is just plain awful and unintuitive. I'm not sure it is complicated. I don't think Relax NG is complicated. The specification and the tutorial are both short and logical. > Network operators are probably not trained programmers like > protocol developers. There are way more operators than there > are protocol developers, and they are much less likely to > be involved in the standards process, than the protocol developer. I completely agree with the statements above yet I came to the opposite conclusion. I think operators are much more familiar and comfortable with web standards than with MIB languages. The typical consumers of XML documents are technical non-programmers (like most operators) and "soft" programmers who do web programming. A large portion of these folks are using scripting languages like python to "screen scrape" XHTML. That crowd is going to be VERY comfortable with existing XML tools. > The NETCONF WG evaluated XSD and RelaxNG last year. > Examples of data models including the DIFFSERV Info Model > were examined. Nobody got excited about RNG. For a real > data model, RNG seemed to be just as impenetrable as XSD. > > Data model development in the NETCONF WG has been brutally > slow with XSD. XSD is a good language to use if you want > to spend a long time learning what to do, and then spend > a long time fixing what you did wrong. Relatively few > WG members have actually been able to learn either XSD or RNG. I don't think XSD is good for anything actually. I am extremely skeptical that anyone who spent more than a few hours was acutally unable to learn Relax NG. I am certainly happy to give a tutorial on the topic in Vancouver if anyone is interested. > Unlike other protocols that might use XML, a NETCONF data model > is likely to be orders of magnitude larger. So there is lots more data, > that needs to be understood by lots of non-programmers. > > A3) > > If there are other WGs in the IETF who happen to use XML > for representation of conceptual configuration databases, > then I suppose they might ask for a new DML. I suppose they > will have to justify their request, no different than creating > a new protocol in the first place. At IETF, we have protocols conveying interesting data using XML coming out our ears. For example. in the SIPPING WG we have the SIP UA profile framework which needs some data definitions. > If they are just using XML to define fairly static protocol PDUs, None of these groups is interested in "fairly static" data. They are looking for data which is easily vendor extensible. > then XSD or RNG should be used instead. > > A4) > > A YANG data model defines conceptual data within a NETCONF agent, > just like SMIv2 does for SNMP. It does not just define > valid PDUs, like other protocols. Instead, the specialized DML > provides a concise description of all conceivable protocol behavior > related to the management data. > > XSD and RNG do not even distinguish between read-only and read-write data. > They are clearly not intended to be used a DMLs for conceptual > datastores, like those found in SNMP or NETCONF. > Instead, they describes XML instance documents. > > I have implemented a NETCONF agent, and IMO, 'standard' validation > tools are useless. Since and allow > an almost infinite combination of actual PDUs, the only > thing these tools can do is identify and reject 'junk' > namespaces and element names not supported by the agent. > They cannot help at all with validating or automating > NETCONF protocol operations or generating responses. > > YANG describes NETCONF configuration databases. > IMO, YANG is way more readable than RelaxNG, but > that is subjective. Look at the following Relax NG in compact form, side-by-side with YANG. container aaa { container bbb { leaf foo { type string; } leaf bar { type uint32; } } } element aaa { element bbb { element foo { xsd:string }, element bar { xsd:unsignedInt } } } This hardly seems like a big difference to me. > The SMIng WG got hung up for > a long time trying to define objective criteria > to evaluate DMLs, but in the end this was a total failure. thanks, -rohan ------=_Part_7641_25750232.1196309824605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Andy,

I want to comment first on one specific aspect of your message.  You talk about XSD and Relax as if they are somehow similar in complexity. XSD is an absolutely terrible schema definition language. It is hard to read, harder to write, and extremely inflexible when it comes to schema extensibility. The W3C no longer uses XSD because it is an absolutely awful PITA.  They use Relax NG instead because it is actually pleasant to use, has a nice extensibility model, and it is easy to learn and to use.

I have some additional comments inline.

On Nov 28, 2007 5:01 PM, Andy Bierman <ietf@andybierman.com> wrote:
Hi,

There are a few questions that the IESG and others have asked,
which I will try to address:

  Q1) Why does NETCONF need a DML at all?
  Q2) Why is NETCONF special?
  Q3) Why won't lots of other WGs want to define their own
      protocol-specific DMLs?
  Q4) Why isn't XSD or RelaxNG good enough?



A1)

NETCONF needs a formal description of the conceptual data
within a NETCONF configuration database, in order to facilitate
inter-operable implementations of NETCONF-related tools,
such as agents, managers, and translators.

Agreed.

A textual representation is needed, to easily integrate
semantic and syntactic information, in one file.  Translation
or separation would introduce errors.

Letting this one sit.
 
A protocol-specific data model definition is much more
than an XML instance document description.  

I agree.
 
NETCONF needs
its own MIB language, just like SNMP needs SMIv2.

I don't think you've made a strong case here. You might be right, but your statements above do not strongly motivate a new language. 

I don't think we can take it on blind faith that we need to do things in Netconf the way SNMP did them. I think it is very important to look at the reasons we thought that SNMP needed to be a certain way, but we also need to acknowledge that SNMP was hardly a success as a configuration protocol, and try to find out why. It is possible that the data model was too rigid for practical configuration use.

If vendors were given an information model instead of a data model,
then they would be free to invent their own data model mappings.
This would be a disaster for multi-vendor interoperability.
Without a single, authoritative, precise definition of the
syntax and semantics wrt/ NETCONF protocol handling, it is
impossible for 3rd party application developers to even attempt
to support NETCONF.

How do you see NETCONF playing out differently from the LDAP experience?  Do you think that LDAP has been a success as an interoperable protocol?
 
A2)

NETCONF is a network management protocol, like SNMP.
It happens to use XML encoding and Xpath filtering,
but it is a network management protocol.  As such,
network operators need to understand the conceptual
management data available on a device (just like the CLI or the MIBs).

XSD and RelaxNG are both complicated.

I think XSD is just plain awful and unintuitive. I'm not sure it is complicated.  I don't think Relax NG is complicated. The specification and the tutorial are both short and logical.
 
Network operators are probably not trained programmers like
protocol developers. There are way more operators than there
are protocol developers, and they are much less likely to
be involved in the standards process, than the protocol developer.

I completely agree with the statements above yet I came to the opposite conclusion. I think operators are much more familiar and comfortable with web standards than with MIB languages. The typical consumers of XML documents are technical non-programmers (like most operators) and "soft" programmers who do web programming.  A large portion of these folks are using scripting languages like python to "screen scrape" XHTML.  That crowd is going to be VERY comfortable with existing XML tools.
 
The NETCONF WG evaluated XSD and RelaxNG last year.
Examples of data models including the DIFFSERV Info Model
were examined.  Nobody got excited about RNG.  For a real
data model, RNG seemed to be just as impenetrable as XSD.

Data model development in the NETCONF WG has been brutally
slow with XSD.  XSD is a good language to use if you want
to spend a long time learning what to do, and then spend
a long time fixing what you did wrong.  Relatively few
WG members have actually been able to learn either XSD or RNG.

I don't think XSD is good for anything actually.
I am extremely skeptical that anyone who spent more than a few hours was acutally unable to learn Relax NG.
I am certainly happy to give a tutorial on the topic in Vancouver if anyone is interested.
 
Unlike other protocols that might use XML, a NETCONF data model
is likely to be orders of magnitude larger.  So there is lots more data,
that needs to be understood by lots of non-programmers.

A3)

If there are other WGs in the IETF who happen to use XML
for representation of conceptual configuration databases,
then I suppose they might ask for a new DML.  I suppose they
will have to justify their request, no different than creating
a new protocol in the first place.

At IETF, we have protocols conveying interesting data using XML coming out our ears. For example. in the SIPPING WG we have the SIP UA profile framework which needs some data definitions.
 
If they are just using XML to define fairly static protocol PDUs,

None of these groups is interested in "fairly static" data.  They are looking for data which is easily vendor extensible.
 
then XSD or RNG should be used instead.

A4)

A YANG data model defines conceptual data within a NETCONF agent,
just like SMIv2 does for SNMP.  It does not just define
valid PDUs, like other protocols.  Instead, the specialized DML
provides a concise description of all conceivable protocol behavior
related to the management data.

XSD and RNG do not even distinguish between read-only and read-write data.
They are clearly not intended to be used a DMLs for conceptual
datastores, like those found in SNMP or NETCONF.
Instead, they describes XML instance documents.

I have implemented a NETCONF agent, and IMO, 'standard' validation
tools are useless.  Since <get> and <edit-config> allow
an almost infinite combination of actual PDUs, the only
thing these tools can do is identify and reject 'junk'
namespaces and element names not supported by the agent.
They cannot help at all with validating or automating
NETCONF protocol operations or generating <rpc-error> responses.

YANG describes NETCONF configuration databases.
IMO, YANG is way more readable than RelaxNG, but
that is subjective.  

Look at the following Relax NG in compact form, side-by-side with YANG.

container aaa {
   container bbb {
      leaf foo { type string; }
      leaf bar { type uint32; }
   }
}

element aaa {
   element bbb {
      element foo { xsd:string },
      element bar { xsd:unsignedInt }
   }
}

This hardly seems like a big difference to me.
 
The SMIng WG got hung up for
a long time trying to define objective criteria
to evaluate DMLs, but in the end this was a total failure.


thanks,
-rohan
------=_Part_7641_25750232.1196309824605-- From discuss-bounces@apps.ietf.org Thu Nov 29 02:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxeD0-0005IK-Mp; Thu, 29 Nov 2007 02:53:18 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxeCz-0005I3-LN for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 02:53:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxeCz-0005Hv-Bo for discuss@apps.ietf.org; Thu, 29 Nov 2007 02:53:17 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxeCx-0004Uz-An for discuss@apps.ietf.org; Thu, 29 Nov 2007 02:53:16 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23E818A211; Thu, 29 Nov 2007 08:53:14 +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 19764-02; Thu, 29 Nov 2007 08:53:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EFD58A20B; Thu, 29 Nov 2007 08:53:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 40EAD401E05; Thu, 29 Nov 2007 08:53:09 +0100 (CET) Date: Thu, 29 Nov 2007 08:53:09 +0100 From: Juergen Schoenwaelder To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071129075309.GA10453@elstar.local> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> <20071128225652.GA10228@elstar.local> <953beacc0711281731p37007a69wc3923ed88cfba224@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953beacc0711281731p37007a69wc3923ed88cfba224@mail.gmail.com> 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, Nov 28, 2007 at 05:31:56PM -0800, Rohan Mahy wrote: > > You are suggesting to extend the definition of the NETCONF operations > > get, get-config, edit-config etc. for every possible data item they > > might carry? > > I am suggesting that an implementation "extend" the definition of each > netconf operation to include each top-level data item they actually > understand and use. I hope you see the distinction. The phrase "implementation 'extend' the definition" sounds to me like there is some little tool taking a data model and turning it into something you can use for validation. But then it might also be the case that I do not really understand the distinction you are trying to make. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Thu Nov 29 03:16: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 1IxeZ7-00007N-E6; Thu, 29 Nov 2007 03:16:09 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxeZ6-0008U3-Aq for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 03:16:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxeZ5-0008Rq-R3 for discuss@apps.ietf.org; Thu, 29 Nov 2007 03:16:07 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxeZ5-0006CE-7l for discuss@apps.ietf.org; Thu, 29 Nov 2007 03:16:07 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E0F58A1CF; Thu, 29 Nov 2007 09:16:06 +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 21500-10; Thu, 29 Nov 2007 09:16:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 476678A116; Thu, 29 Nov 2007 09:16:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 13D44401EDC; Thu, 29 Nov 2007 09:16:01 +0100 (CET) Date: Thu, 29 Nov 2007 09:16:00 +0100 From: Juergen Schoenwaelder To: Lisa Dusseault Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071129081600.GC10453@elstar.local> References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.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: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, Nov 28, 2007 at 03:34:06PM -0800, Lisa Dusseault wrote: > This is another aspect I'd like to understand better: > > On Nov 28, 2007, at 2:02 PM, Martin Bjorklund wrote: > >> Note that in order to validate the different NETCONF messages, you >> would either need more than one schema, or a very lax schema which >> will validate messages/documents which are not actually valid NETCONF. > > Validating XML really limits the customizability, the very extensibility of > the XML. You can't add so much as a or > element without it failing at the other end. Is the goal > here to strictly limit netconf data to only standardized and implemented > schemas? The point Martin and Any were trying to make is that validation against a schema within a NETCONF implementation does not make too much sense; you have to validate the data exchanged against the datastore. And the implementations we are aware of do this without using generix XML schema validators. And yes, since we are talking about configuration, we do expect that easy support for vendor extensions is crucial. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Thu Nov 29 04:17:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfWi-0004nW-My; Thu, 29 Nov 2007 04:17:44 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxfWh-0004iB-Aw for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 04:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfWg-0004hz-Uz for discuss@apps.ietf.org; Thu, 29 Nov 2007 04:17:42 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxfWf-0006VP-94 for discuss@apps.ietf.org; Thu, 29 Nov 2007 04:17:42 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 43EA720860; Thu, 29 Nov 2007 10:17:38 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-8d-474e83b208d1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 15ECC203CF; Thu, 29 Nov 2007 10:17:38 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:17:34 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:17:33 +0100 Message-ID: <474E83A4.3050000@ericsson.com> Date: Thu, 29 Nov 2007 10:17:24 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> In-Reply-To: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 09:17:33.0777 (UTC) FILETIME=[ACD64410:01C83268] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Rohan, Thanks for your response. Here are some replies. Balazs Rohan Mahy wrote: ... > These aspects are not *missing* from Relax NG. Some of these things are > not in the scope of the Relax NG schema, but can be defined as an > additional layer on top of a specific Relax schema. [BALAZS]: Yes but if you need to extend RelaxNg, you loose much/most of the advantage of using a standard language. As we agreed all the extensions will need custom tools. These tools are already available for Yang, but not for RelaxNg. The experience with SNMP/SMI tools in the last decades also tells us that at the end nearly all SNMP tools were custom built and not based on standard ASN.1 tools. So the gain of following the standard is even more limited. > We can even write > schema which describes what syntax is allowed for these annotations in a > netconf-semantics namespace. > > > - what does a default mean for configuration data > > > this is semantic. > [BALAZS]: Yes, you recognized one of our main points: NETCONF needs semantics and processing rules. These have to be defined. Current schema languages don really do this. Thats one of our reasons to do YANG. A quote from the book RelaxNg by Eric van der List you recommended: "XML reintroduces a clean separation between data and processing. " However Netconf does need rules about processing, so RelaxNg is not enough for us. We can reintroduce processing hints into RelaxNg, but is that still RelaxNg. Processing features needed include: - handling semantics of NETCONF edit-config - the meaning of default data for operational and configuration data - ordering of list data - automatic creation of some data (containers) - placement of data in normal structures, notifications or RPCs - others ??? > > Maybe I have different implementors, but the implementor is more likely > to have some XML experience than to be a "network management person". > Following the principle mentioned in Section 3.1 of > draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and > simplicity for the reader takes precedence: > > As a consequence, preference should be give to solutions that > simplify the task of readers. Reduction of the efforts required by > writers is of secondary importance and the reduction of the efforts > required by tool developers is of least important preference. While > this perhaps seems obvious, it is at times difficult to take > according design decisions, especially if the group working on a new > data modeling language is dominated by tool developers or data model > writers. > [BALAZS]: Yes as the above quote says it is NOT the implementors but the readers i.e. network operators that are important. I think they are much more familiar with the concept of a managed object or a list then "Pattern Compositions". From discuss-bounces@apps.ietf.org Thu Nov 29 04:48:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixg0N-0005s5-BA; Thu, 29 Nov 2007 04:48:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixg0M-0005rl-Ay for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 04:48:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixg0L-0005rZ-UX for discuss@apps.ietf.org; Thu, 29 Nov 2007 04:48:21 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixg0L-0004Bs-FS for discuss@apps.ietf.org; Thu, 29 Nov 2007 04:48:21 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5A744204E7; Thu, 29 Nov 2007 10:48:18 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-d3-474e8ae2ba16 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 49EA720518; Thu, 29 Nov 2007 10:48:18 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:48:18 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:48:18 +0100 Message-ID: <474E8AD8.8070808@ericsson.com> Date: Thu, 29 Nov 2007 10:48:08 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> In-Reply-To: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 09:48:18.0119 (UTC) FILETIME=[F8268570:01C8326C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Rohan, Rohan Mahy wrote: > On Nov 28, 2007 8:04 AM, Balazs Lengyel >> I have the feeling once you extend RelaxNg with all the necessary >> bits, half your statements >> will start with . > > We will never know unless we try the exercise. It seems you are > suggesting that we don't even try. [BALAZS]: Your question is very valid, but it has some costs. A serious effort to bring the RelaxNg based solution to todays level in Yang would cost according to my guess at least 500 manhours. After this we might still conclude that a domain specific effort (YANG) is better. Are you willing to get involved and invest 2 months (possibly more) of dedicated work? regards Balazs From discuss-bounces@apps.ietf.org Thu Nov 29 04:57:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixg8t-0008GP-K1; Thu, 29 Nov 2007 04:57:11 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixg8s-0008De-6o for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 04:57:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixg8r-0008DU-TO for discuss@apps.ietf.org; Thu, 29 Nov 2007 04:57:09 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixg8q-0005ox-6f for discuss@apps.ietf.org; Thu, 29 Nov 2007 04:57:09 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 88F53205B3; Thu, 29 Nov 2007 10:57:07 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-10-474e8cf3d218 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7AAC220857; Thu, 29 Nov 2007 10:57:07 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:57:07 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:57:07 +0100 Message-ID: <474E8CE9.10900@ericsson.com> Date: Thu, 29 Nov 2007 10:56:57 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> In-Reply-To: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 09:57:07.0058 (UTC) FILETIME=[336C3520:01C8326E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Rohan, Some questions/answers below. Balazs Rohan Mahy wrote: > Hi, > > Comments inline. > > On Nov 28, 2007 8:04 AM, Balazs Lengyel > wrote: > > Hello, > I am no expert in RelaxNg but here are some thoughts why I like Yang > better. > > I have the feeling once you extend RelaxNg with all the necessary > bits, half your statements > will start with . > > > We will never know unless we try the exercise. It seems you are However, I see a pretty small number > of additional semantic items you list below: > - an indicator of a default value (if any) > - a flag that indicates whether a subtree is atomic for edit-config > - an indicator that the schema is an rpc method and what its matching > request or response is > - a flag that indicates whether a subtree is configuration or > operational data (read-write or read-only). [BALAZS]: Please add - what does a default value mean for operation data? - a flag stating if a part of configuration is current, deprecated, obsolete - a flag indicating if a bit of writable data is stored in non-volatile storage - information indicating whether the sort order in a list is set by the user or the managed system - a number of documentation options. And it is not enough to just say documentation, we need separate tags/elements for description, contact, revision info etc. - enterprise specific extensions, do you need to define them or just use them - formal descriptions of constraint e.g. if encryption method is non-null then we need a password - references between different parts of the model e.g. this subscriber should use XXX application server. And simple ID based referencing is not enough as I want to state that here you can only reference application servers but not DNS servers. - how do you handle data models with multiple roots, that are not well formed XML. (This is a current, existing customer demand not a theoretical question.) - how do you refer to managed object instances e.g. a the observed speed of interface eth0 - etc. -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From discuss-bounces@apps.ietf.org Thu Nov 29 05:11: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 1IxgNC-0006Sw-QX; Thu, 29 Nov 2007 05:11:58 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxgNB-0006Sc-5a for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:11:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgNA-0006SR-Ph for discuss@apps.ietf.org; Thu, 29 Nov 2007 05:11:56 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxgNA-00007i-4n for discuss@apps.ietf.org; Thu, 29 Nov 2007 05:11:56 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AAFDF20778; Thu, 29 Nov 2007 11:11:55 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-01-474e906be032 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 976732072E; Thu, 29 Nov 2007 11:11:55 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 11:11:55 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 11:11:55 +0100 Message-ID: <474E9061.9040209@ericsson.com> Date: Thu, 29 Nov 2007 11:11:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> In-Reply-To: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 10:11:55.0296 (UTC) FILETIME=[44DA9200:01C83270] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Rohan, Further comments below. regards Balazs Rohan Mahy wrote: > - what is considered a compatible or incompatible change > > > I believe I already covered this. Adding an additional choice (adding a > new rpc method), adding via interleave (adding additional data within a > container), and copying and redefining via restriction or addition > (reusing parts of one container for a new container) are all pretty easy. [BALAZS]: So if I change the default value of a leaf/attribute is that compatible? Do I have to rename my model in this case? If I extend/restrict the value range of a variable is that compatible? I see a number of questions here that are not obvious for me. I feel they need work. > > > - ordering of items within list, leaf-lists > > > The schema I described preserves ordering. [BALAZS]: Yes but is that the order in which the user inputs the leafs, or some order defined by the system? If it is user defined how do you insert in the middle. For me your answer is not complete. As we say in Hungary: "The devil lurks in the details. And there are many little devils still hiding here. > > - differentiating between RPCs, notifications and data containers > (in YANG you have separate > statements) > > > This is easy to do using pure syntax. As in my example, to add an RPC > method or response, you just "combine with choice" and you insure that > the method isn't used as a notification or a data container. [BALAZS]: yes but more work > > - Netconf specific error messages > > > If you are talking about error messages sent on the wire, this is a > syntactic issue that Relax can handle out of the box. [BALAZS]: I mean questions like what will be the content of the NETCONF element be on the wire, if the uniqueness constraint on interface names is violated? By the way how do you declare it in RelaxNg that interface names must be unique? > > > One important advantage of YANG is that the number of features in > YANG is much smaller then in > RelaxNg. > > > This is a preposterous statement. There is no need for an operator to > learn features of Relax (or XSD even) that they will never use in order > to read and write schema. [BALAZS]: I agree that there is no need to learn RelaxNg fully. But there are some dangerous constructs in RelaxNg that they need to understand e.g. like redefining patterns. Or is this not a problem? > In the network management world there is a general dislike for so > called "little rules". Things > like > - you can use RelaxNg but don't use attributes > - you can use RelaxNg but don't use mixed pattern > - you can use RelaxNg but don't redefine or remove patterns > > With RelaxNg we will need a number of such rules. With a problem > specific solution - YANG - > the number of such rules is minimal. > > > I disagree. It looks like you have lots of implicit little rules in the > YANG draft. A network management person might have become desensitized > to these rules to the point of not noticing them, but they are there and > there are plenty of them. > [BALAZS]: Could you please list YANG's implicit little rules. We will try to remove as many as possible. regards Balazs From discuss-bounces@apps.ietf.org Thu Nov 29 06:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxhfZ-0003PN-As; Thu, 29 Nov 2007 06:35:01 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxhfY-0003PE-4r for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 06:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxhfX-0003Ow-O5 for discuss@apps.ietf.org; Thu, 29 Nov 2007 06:34:59 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxhfV-0008U5-Qu for discuss@apps.ietf.org; Thu, 29 Nov 2007 06:34:59 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 122048A243; Thu, 29 Nov 2007 12:34:57 +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 08286-03; Thu, 29 Nov 2007 12:34:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F0E88A241; Thu, 29 Nov 2007 12:34:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E527D4022B7; Thu, 29 Nov 2007 12:34:46 +0100 (CET) Date: Thu, 29 Nov 2007 12:34:46 +0100 From: Juergen Schoenwaelder To: Rohan Mahy Subject: Re: Why NETCONF needs a data modeling language Message-ID: <20071129113446.GB10751@elstar.local> References: <474E0F71.2050003@andybierman.com> <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> 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: 6e922792024732fb1bb6f346e63517e4 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote: > > NETCONF needs > > its own MIB language, just like SNMP needs SMIv2. > > I don't think you've made a strong case here. You might be right, but your > statements above do not strongly motivate a new language. NETCONF needs a new language; whether it is a domain specific language like YANG or an "adapted subset" of some existing XML schema language does not change that fact that we will need a NETCONF data modeling language and that we will need tools to understand that language. > I don't think we can take it on blind faith that we need to do things in > Netconf the way SNMP did them. I think it is very important to look at the > reasons we thought that SNMP needed to be a certain way, but we also need to > acknowledge that SNMP was hardly a success as a configuration protocol, and > try to find out why. It is possible that the data model was too rigid for > practical configuration use. There has been a long discussion about why SNMP failed before the NETCONF effort was started, all going back to IAB workshop [RFC 3535] and lots of followup email discussions. I am not sure it is terrible useful to redo this exercise. From what I recall, the rigidity of the SMI was never mentioned as a major issue why SNMP failed to be a good configuration protocol. > Look at the following Relax NG in compact form, side-by-side with YANG. > > container aaa { > container bbb { > leaf foo { type string; } > leaf bar { type uint32; } > } > } > > element aaa { > element bbb { > element foo { xsd:string }, > element bar { xsd:unsignedInt } > } > } > > This hardly seems like a big difference to me. I am not sure which point you are trying to make using examples that ignore almost all NETCONF specifics. But even then, if you spell out the additional NETCONF specific semantics which are hidden because there are suitable defaults for the most common cases, then the YANG example above actually expands to the following: container aaa { config true; status current; container bbb { status current; config true; leaf foo { type string; config true; status current; mandatory false; } leaf bar { type uint32; config true; status current; mandatory false; } } } Statements like 'config true;' are essential for the processing of NETCONF messages and also for validating content exchanged in NETCONF messages (and this is why for example generic XML validation tools are only of limited value for NETCONF implementors). I am sure one can define an adapted subset of RNG which takes care of all this and then at the end this adapted subset likely works like YANG. However, given the SMI and ASN.1 experience, I do question a) that doing so will lead to a large reuse of available RNG tools for processing NETCONF data models (since they don't know the RNG subset nor the semantic additions) b) that the effort to specify such an extended subset will be less than the effort for defining a domain specific language like YANG c) that the effort to implement tools understanding the adapted subset of RNG will be less than writing proper tools for a domain specific language from scratch d) that there will be long term (say 20 year) reliable change control exercised by the organization that has change control over NETCONF /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Thu Nov 29 08:03:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixj3S-0005QN-TD; Thu, 29 Nov 2007 08:03:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ix4A2-0000rv-MM for discuss-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4A2-0000rk-1a for discuss@apps.ietf.org; Tue, 27 Nov 2007 12:23:50 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix4A1-00054c-OP for discuss@apps.ietf.org; Tue, 27 Nov 2007 12:23:50 -0500 Received: from bigdog02 ([::ffff:65.170.117.156]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 27 Nov 2007 12:23:48 -0500 id 0158C3D0.474C52A4.00003352 Message-Id: <60DDCFE1-30DC-4AE1-99D7-C45A1E9D3868@hxr.us> From: Andrew Newton To: discuss@apps.ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: analysis of YANG vs. RELAX NG Date: Tue, 27 Nov 2007 12:23:48 -0500 References: <953beacc0711262148me3c119coebc756a44322b6e9@mail.gmail.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: -0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Thu, 29 Nov 2007 08:03:45 -0500 Cc: Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Nov 27, 2007, at 11:54 AM, Paul Hoffman wrote: > FWIW, I bought a copy of the book "RELAX NG" by van der Vlist and > found it to be quite easy to understand. After reading it (well, > about half of it), I found RELAX NG much less threatening than after > reading a bunch of web resources. If it is the O'Reilly book, it can also be found on-line here: http://books.xmlschemata.org/relaxng/page2.html And yes, that is a good book on the subject. -andy From discuss-bounces@apps.ietf.org Thu Nov 29 08:18: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 1IxjHR-0004ra-4S; Thu, 29 Nov 2007 08:18:13 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxjHQ-0004rQ-DI for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 08:18:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjHP-0004pi-VN for discuss@apps.ietf.org; Thu, 29 Nov 2007 08:18:11 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxjHN-0001v7-Kl for discuss@apps.ietf.org; Thu, 29 Nov 2007 08:18:11 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 05:18:03 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 05:18:02 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lATDI1E01926; Thu, 29 Nov 2007 05:18:01 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lATDEklv047248; Thu, 29 Nov 2007 13:14:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200711291314.lATDEklv047248@idle.juniper.net> To: "Rohan Mahy" Subject: Re: Why NETCONF needs a data modeling language In-reply-to: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> Date: Thu, 29 Nov 2007 08:14:45 -0500 From: Phil Shafer X-OriginalArrivalTime: 29 Nov 2007 13:18:02.0739 (UTC) FILETIME=[452B2430:01C8328A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org "Rohan Mahy" writes: >The W3C no longer uses XSD because it is an absolutely awful PITA. Are you saying that w3c has stopped using xsd? Can you point me to a reference for that? Thanks, Phil From discuss-bounces@apps.ietf.org Thu Nov 29 11:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlzv-0000EU-RV; Thu, 29 Nov 2007 11:12:19 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixlzv-00009L-1Y for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlzu-00008v-NM for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:12:18 -0500 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixlzu-0007yx-CF for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:12:18 -0500 Received: by wr-out-0506.google.com with SMTP id 70so1520361wra for ; Thu, 29 Nov 2007 08:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=OohzOXp4fs5xlzZo+NlAzuE56Ci0ckRGKDzbAoiXIzY=; b=M4GrP6EyeKW62M2pEQq2QGqu1riDCl0Efq5M40iHk9EfCtqYMVGq9sEZ3VKvc9O93eQ25t2Jj/+cSgm5VPCNZwo04FLRXDgCnpg56GDIxDdhVJCtrmuwac5fo+mlxb/TwHrJIY80i4HVxqlbzVkDPXsgaF7+Bu24r0ZVXlGANx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=R/kA8NpHSa51/nlEYDpqPnLB7ZVp/N7jOS0p/oSESF6xRIori31xHPvH6+ti3QBfDn/6ybrGEue1dY996BNvJZEZhY6C6kHKnZyMsYX613AVpjMPzDXE3V1yUo9mrcM5C4XQ3FLnI+euoBF8M2e+7mIfe29ZtrHNFTLrKtmjo5o= Received: by 10.142.104.9 with SMTP id b9mr1956024wfc.1196352736725; Thu, 29 Nov 2007 08:12:16 -0800 (PST) Received: by 10.142.214.15 with HTTP; Thu, 29 Nov 2007 08:12:16 -0800 (PST) Message-ID: <953beacc0711290812t68d2cc09se1f4ff0578cc5836@mail.gmail.com> Date: Thu, 29 Nov 2007 08:12:16 -0800 From: "Rohan Mahy" To: "Phil Shafer" Subject: Re: Why NETCONF needs a data modeling language In-Reply-To: <200711291314.lATDEklv047248@idle.juniper.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1904_6233573.1196352736719" References: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <200711291314.lATDEklv047248@idle.juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_1904_6233573.1196352736719 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Phil, Organically as a practical matter, new work in W3C that uses XML is definitely using Relax NG. I don't think there is an official policy statement or something like that. A telling example is the XHTML2.0 spec (work in progresss) at http://www.w3.org/TR/xhtml2/ . It is supposed to have Normative schema in RNG (Sect B+C), XSD (Sect D+E), and DTD (Sect F+G). Only Relax is filled in. I have spoken with folks active in other W3 working groups and they report a similar pattern. thanks, -rohan On Nov 29, 2007 5:14 AM, Phil Shafer wrote: > "Rohan Mahy" writes: > >The W3C no longer uses XSD because it is an absolutely awful PITA. > > Are you saying that w3c has stopped using xsd? Can you > point me to a reference for that? > > Thanks, > Phil > ------=_Part_1904_6233573.1196352736719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Phil,

Organically as a practical matter, new work in W3C that uses XML is definitely using Relax NG.  I don't think there is an official policy statement or something like that.  A telling example is the XHTML2.0 spec (work in progresss) at http://www.w3.org/TR/xhtml2/ . It is supposed to have Normative schema in RNG (Sect B+C), XSD (Sect D+E), and DTD (Sect F+G).  Only Relax is filled in. I have spoken with folks active in other W3 working groups and they report a similar pattern.

thanks,
-rohan

On Nov 29, 2007 5:14 AM, Phil Shafer <phil@juniper.net> wrote:
"Rohan Mahy" writes:
>The W3C no longer uses XSD because it is an absolutely awful PITA.

Are you saying that w3c has stopped using xsd?  Can you
point me to a reference for that?

Thanks,
 Phil

------=_Part_1904_6233573.1196352736719-- From discuss-bounces@apps.ietf.org Thu Nov 29 11:24: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 1IxmBX-0005jH-2d; Thu, 29 Nov 2007 11:24:19 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmBV-0005is-Gy for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:24:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmBV-0005ig-7N for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:24:17 -0500 Received: from el-out-1112.google.com ([209.85.162.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmBU-0001Vx-OB for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:24:17 -0500 Received: by el-out-1112.google.com with SMTP id n30so848291elf for ; Thu, 29 Nov 2007 08:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=7N44N+8D0Ijm/H9qumunxAFR7aM1eHBkcW3Cs9hW+fM=; b=FkhugOg+wGYPP1v61ZrAAFlkIedjmmLef279tK4zJ7Uk1bjzd8ORAVnIH8RkMjLp5WTHD0dWiPEhXtiMZeMf7vuS0W8vBkoR/rwszWlGLwqPgxRS3XEUnXYp6iRG4okbu7VM+o4mXuKHofCGUMtR3DgiGuD8ccSdbd+5YH7cGKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LW2yGmeyD14CtV/+B/Cim6ERhTvw7eJCz7cnzr/bIJ2C8uC6OqFO7MZWRF7CMYKD4pAtc3DfTmS85MHp//iMhzwpg+dkutbXwxJp3yJkD4Ia2hLuI41huQqZ5GJJ6ejd53xx4yQF2HEIUuPValTEfaPtSSf+e2JNLhP1zM+G/QI= Received: by 10.143.37.20 with SMTP id p20mr170690wfj.1196353455752; Thu, 29 Nov 2007 08:24:15 -0800 (PST) Received: by 10.142.214.15 with HTTP; Thu, 29 Nov 2007 08:24:15 -0800 (PST) Message-ID: <953beacc0711290824k50d781dfm21e06f3dcc898236@mail.gmail.com> Date: Thu, 29 Nov 2007 08:24:15 -0800 From: "Rohan Mahy" To: j.schoenwaelder@jacobs-university.de Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <20071129075309.GA10453@elstar.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2006_26535213.1196353455742" References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com> <20071128225652.GA10228@elstar.local> <953beacc0711281731p37007a69wc3923ed88cfba224@mail.gmail.com> <20071129075309.GA10453@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_2006_26535213.1196353455742 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Juergen, If you want to do strict validation of things like RPC methods on the receiving implementation, the implementation can contain a list of all the RPC methods it supports (an effective schema). If this level of validation is not desired, we can ignore this concept. thanks, -rohan On Nov 28, 2007 11:53 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Nov 28, 2007 at 05:31:56PM -0800, Rohan Mahy wrote: > > > > You are suggesting to extend the definition of the NETCONF operations > > > get, get-config, edit-config etc. for every possible data item they > > > might carry? > > > > I am suggesting that an implementation "extend" the definition of each > > netconf operation to include each top-level data item they actually > > understand and use. I hope you see the distinction. > > The phrase "implementation 'extend' the definition" sounds to me like > there is some little tool taking a data model and turning it into > something you can use for validation. But then it might also be the > case that I do not really understand the distinction you are trying to > make. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ------=_Part_2006_26535213.1196353455742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Juergen,

If you want to do strict validation of things like RPC methods on the receiving implementation, the implementation can contain a list of all the RPC methods it supports (an effective schema). If this level of validation is not desired, we can ignore this concept.

thanks,
-rohan

On Nov 28, 2007 11:53 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Nov 28, 2007 at 05:31:56PM -0800, Rohan Mahy wrote:

> > You are suggesting to extend the definition of the NETCONF operations
> > get, get-config, edit-config etc. for every possible data item they
> > might carry?
>
> I am suggesting that an implementation "extend" the definition of each
> netconf operation to include each top-level data item they actually
> understand and use.  I hope you see the distinction.

The phrase "implementation 'extend' the definition" sounds to me like
there is some little tool taking a data model and turning it into
something you can use for validation. But then it might also be the
case that I do not really understand the distinction you are trying to
make.

/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/>

------=_Part_2006_26535213.1196353455742-- From discuss-bounces@apps.ietf.org Thu Nov 29 11:30: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 1IxmHF-00089K-57; Thu, 29 Nov 2007 11:30:13 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmHD-00086Y-1N for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:30:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmHC-00086P-O7 for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:30:10 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmHC-0002a5-1h for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:30:10 -0500 Received: by wr-out-0506.google.com with SMTP id 70so1526422wra for ; Thu, 29 Nov 2007 08:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=IrEIDYaOvS2GHmOuOFjurE0fTheiQSBZayGOYJvckTE=; b=gGiMEh4CHBBIBmQuvdP93wmkxEyuUW7WveJsFCQdWTqdgjLV/1OhVrpEukIaeNhg9pVEpp1mxB5aZd/qz+IUOCSVetclbH+oKn9pvIquLOLnKey3PKZd2I7l20vlOrff2SeSnd1qrG7UHok9Msd68Br0eeD+KgDNORax6R6nPcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aPIdJfhxl/t9BJ5N6VhDRAEUAcOsIbiZnGTCgG1qrVGdAr0cUQ67UCibghydQ60MiVsWSw+3kLwq6VLIGO+rN9M4oLCtCVEZjgnArRBKW1+QZtoDi9gFUUx2G/LYr07oHg4z2+dVO0kM6ZFCsWuIcvSwKbnrY3L6caH2UJdHqBU= Received: by 10.142.104.9 with SMTP id b9mr1971866wfc.1196353808127; Thu, 29 Nov 2007 08:30:08 -0800 (PST) Received: by 10.142.214.15 with HTTP; Thu, 29 Nov 2007 08:30:08 -0800 (PST) Message-ID: <953beacc0711290830wfb945a3r7e6deac48d71ab75@mail.gmail.com> Date: Thu, 29 Nov 2007 08:30:08 -0800 From: "Rohan Mahy" To: "Balazs Lengyel" Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <474E8AD8.8070808@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2053_14560929.1196353808122" References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E8AD8.8070808@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_2053_14560929.1196353808122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Balazs, I don't think anyone is suggesting spending 3 months of full time effort trying something to see if it works, but I think spending a few days is a reasonable cost to invest. By comparison, the YANG team is asking the IETF community and the full IESG to review and possibly comment on their work to the tune of dozens or hundreds of man-hours of work. thanks, -rohan On Nov 29, 2007 1:48 AM, Balazs Lengyel wrote: > Hello Rohan, > > Rohan Mahy wrote: > > On Nov 28, 2007 8:04 AM, Balazs Lengyel > > >> I have the feeling once you extend RelaxNg with all the necessary > >> bits, half your statements > >> will start with . > > > > We will never know unless we try the exercise. It seems you are > > suggesting that we don't even try. > > [BALAZS]: Your question is very valid, but it has some costs. A serious > effort to bring the > RelaxNg based solution to todays level in Yang would cost according to my > guess at least 500 > manhours. After this we might still conclude that a domain specific effort > (YANG) is better. > Are you willing to get involved and invest 2 months (possibly more) of > dedicated work? > > regards Balazs > ------=_Part_2053_14560929.1196353808122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Balazs,

I don't think anyone is suggesting spending 3 months of full time effort trying something to see if it works, but I think spending a few days is a reasonable cost to invest.  By comparison, the YANG team is asking the IETF community and the full IESG to review and possibly comment on their work to the tune of dozens or hundreds of man-hours of work.

thanks,
-rohan

On Nov 29, 2007 1:48 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello Rohan,

Rohan Mahy wrote:
> On Nov 28, 2007 8:04 AM, Balazs Lengyel <balazs.lengyel@ericsson.com
>
>>     I have the feeling once you extend RelaxNg with all the necessary
>>     bits, half your statements
>>     will start with <other:xxx>.
>
> We will never know unless we try the exercise. It seems you are
> suggesting that we don't even try.

[BALAZS]: Your question is very valid, but it has some costs. A serious effort to bring the
RelaxNg based solution to todays level in Yang would cost according to my guess at least 500
manhours. After this we might still conclude that a domain specific effort (YANG) is better.
Are you willing to get involved and invest 2 months (possibly more) of dedicated work?

regards Balazs

------=_Part_2053_14560929.1196353808122-- From discuss-bounces@apps.ietf.org Thu Nov 29 11:39:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmQe-0003Ol-Cq; Thu, 29 Nov 2007 11:39:56 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmQd-0003IC-GT for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmQd-0003Fx-5I for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:39:55 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmQa-0004Eg-Qf for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:39:55 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 37196204E6; Thu, 29 Nov 2007 17:39:52 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-b8-474eeb5836bd Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 275F4201F4; Thu, 29 Nov 2007 17:39:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 17:39:51 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 17:39:51 +0100 Message-ID: <474EEB54.2090400@ericsson.com> Date: Thu, 29 Nov 2007 17:39:48 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E8AD8.8070808@ericsson.com> <953beacc0711290830wfb945a3r7e6deac48d71ab75@mail.gmail.com> In-Reply-To: <953beacc0711290830wfb945a3r7e6deac48d71ab75@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 16:39:51.0795 (UTC) FILETIME=[76BA7430:01C832A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Rohan, See inline. Rohan Mahy wrote: > Hi Balazs, > > I don't think anyone is suggesting spending 3 months of full time effort > trying something to see if it works, but I think spending a few days is > a reasonable cost to invest. [BALAZS]: It might look unreasonable, but I think sadly that is the real cost. There ARE so many little details to check. > By comparison, the YANG team is asking the > IETF community and the full IESG to review and possibly comment on their > work to the tune of dozens or hundreds of man-hours of work. [BALAZS]: True. Is there any alternative? > > thanks, > -rohan > > On Nov 29, 2007 1:48 AM, Balazs Lengyel > wrote: > > Hello Rohan, > > Rohan Mahy wrote: > > On Nov 28, 2007 8:04 AM, Balazs Lengyel > > > > >> I have the feeling once you extend RelaxNg with all the > necessary > >> bits, half your statements > >> will start with . > > > > We will never know unless we try the exercise. It seems you are > > suggesting that we don't even try. > > [BALAZS]: Your question is very valid, but it has some costs. A > serious effort to bring the > RelaxNg based solution to todays level in Yang would cost according > to my guess at least 500 > manhours. After this we might still conclude that a domain specific > effort (YANG) is better. > Are you willing to get involved and invest 2 months (possibly more) > of dedicated work? > > regards Balazs From discuss-bounces@apps.ietf.org Thu Nov 29 11:49: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 1IxmZn-0004I1-OY; Thu, 29 Nov 2007 11:49:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmZm-0004HQ-0i for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmZl-0004HF-N8 for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:49:21 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmZk-0005s2-SC for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:49:21 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id lATGnJYG007547 for ; Thu, 29 Nov 2007 11:49:19 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lATGn6rA076376 for ; Thu, 29 Nov 2007 09:49:07 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lATGn2Np001569 for ; Thu, 29 Nov 2007 09:49:03 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lATGn2lp001565; Thu, 29 Nov 2007 09:49:02 -0700 In-Reply-To: <953beacc0711290812t68d2cc09se1f4ff0578cc5836@mail.gmail.com> To: "Rohan Mahy" MIME-Version: 1.0 Subject: Re: Why NETCONF needs a data modeling language X-Mailer: Lotus Notes Release 7.0.1P Oct 16, 2006 From: Chris Cross Message-ID: Date: Thu, 29 Nov 2007 11:49:01 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2FP2HF300 | September 14, 2007) at 11/29/2007 09:49:02, Serialize complete at 11/29/2007 09:49:02 Content-Type: multipart/alternative; boundary="=_alternative 005C5A30852573A2_=" X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: NETCONF Goes On , discuss@apps.ietf.org, yang@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multipart message in MIME format. --=_alternative 005C5A30852573A2_= Content-Type: text/plain; charset="US-ASCII" Rohan, Some would argue that the XHTML2 document is a special case, as it has been a W3C political PITA ;-) Can you provide another example? Chris "Rohan Mahy" wrote on 11/29/2007 11:12:16 AM: > Hi Phil, > > Organically as a practical matter, new work in W3C that uses XML is > definitely using Relax NG. I don't think there is an official > policy statement or something like that. A telling example is the > XHTML2.0 spec (work in progresss) at http://www.w3.org/TR/xhtml2/ . > It is supposed to have Normative schema in RNG (Sect B+C), XSD (Sect > D+E), and DTD (Sect F+G). Only Relax is filled in. I have spoken > with folks active in other W3 working groups and they report a > similar pattern. > > thanks, > -rohan > On Nov 29, 2007 5:14 AM, Phil Shafer wrote: > "Rohan Mahy" writes: > >The W3C no longer uses XSD because it is an absolutely awful PITA. > Are you saying that w3c has stopped using xsd? Can you > point me to a reference for that? > > Thanks, > Phil --=_alternative 005C5A30852573A2_= Content-Type: text/html; charset="US-ASCII"

Rohan,
Some would argue that the XHTML2 document is a special case, as it has been a W3C political PITA ;-) Can you provide another example?

Chris

"Rohan Mahy" <rohan.mahy@gmail.com> wrote on 11/29/2007 11:12:16 AM:

> Hi Phil,
>
> Organically as a practical matter, new work in W3C that uses XML is
> definitely using Relax NG.  I don't think there is an official
> policy statement or something like that.  A telling example is the
> XHTML2.0 spec (work in progresss) at http://www.w3.org/TR/xhtml2/ .
> It is supposed to have Normative schema in RNG (Sect B+C), XSD (Sect
> D+E), and DTD (Sect F+G).  Only Relax is filled in. I have spoken
> with folks active in other W3 working groups and they report a
> similar pattern.
>
> thanks,
> -rohan
> On Nov 29, 2007 5:14 AM, Phil Shafer <phil@juniper.net> wrote:
> "Rohan Mahy" writes:
> >The W3C no longer uses XSD because it is an absolutely awful PITA.
> Are you saying that w3c has stopped using xsd?  Can you
> point me to a reference for that?
>
> Thanks,
>  Phil --=_alternative 005C5A30852573A2_=-- From discuss-bounces@apps.ietf.org Thu Nov 29 11:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmdT-0007xw-PI; Thu, 29 Nov 2007 11:53:11 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmdS-0007xW-Kl for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmdS-0007xL-BI for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmdR-0006Yj-Rw for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 08:52:54 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 08:51:48 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lATGplE44251; Thu, 29 Nov 2007 08:51:47 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lATGmYsT048635; Thu, 29 Nov 2007 16:48:34 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200711291648.lATGmYsT048635@idle.juniper.net> To: "Rohan Mahy" Subject: Re: analysis of YANG vs. RELAX NG In-reply-to: <953beacc0711290824k50d781dfm21e06f3dcc898236@mail.gmail.com> Date: Thu, 29 Nov 2007 11:48:34 -0500 From: Phil Shafer X-OriginalArrivalTime: 29 Nov 2007 16:51:48.0067 (UTC) FILETIME=[21A8E330:01C832A8] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org "Rohan Mahy" writes: >If you want to do strict validation of things like RPC methods on the >receiving implementation, the implementation can contain a list of all the >RPC methods it supports (an effective schema). If this level of validation >is not desired, we can ignore this concept. The issue isn't validation of the messages, but validation of the NETCONF datastore. We want to be modeling the data inside the NETCONF datastore, thinking more in terms of the object instances than the xml content being sent over the wire. XSD and RNG model the syntax of the xml content, not the semantics of the databases that NETCONF is building. If I say that a particular node is mandatory in the datastore, I'm not saying that it must appear in every XML RPC that's manipulating the datastore. If is a mandatory leaf under , I can perform an RPC that creates under without that RPC containing . The validation tests are only meaningful to the complete data contents, not for individual RPCs. The constraints imposed by the YANG module definition must be complied with to have a valid configuration datastore, but do not apply to each operation. The semantics YANG provides are also important for defining the operations that are available over NETCONF. For example, when the order of entries in a list are maintained in an order defined by the user, you use YANG's "ordered-by user" statement to indicate that the list entries can be modified using the "insert" attribute. And saying that a container is operational data (rather than configuration) tells me that this container will be in the output of a suitable RPC, within the proper hierarchy and keys defined in the YANG module. With YANG, I don't need distinct schemas to describe the scenarios where I traffic my YANG module's data, if I drive my validation from a YANG-enabled parser. But I can derive those schemas from my YANG module as needed. In many respects, YANG is similar to the approach of WSDL and WADL, which puts high-level concepts in specific high-level statements, but allows easy translation to XML schema languages. You can think of YANG as an IDL for NETCONF, but it does considerably more, in terms of modeling the configuration. Thanks, Phil From discuss-bounces@apps.ietf.org Thu Nov 29 12:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixn5d-000895-3u; Thu, 29 Nov 2007 12:22:17 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixn5b-0007ww-5k for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixn5a-0007wn-SR for discuss@apps.ietf.org; Thu, 29 Nov 2007 12:22:14 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixn5a-0002zE-Af for discuss@apps.ietf.org; Thu, 29 Nov 2007 12:22:14 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 09:22:06 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 09:21:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lATHLLE50720; Thu, 29 Nov 2007 09:21:21 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lATHI8tS048970; Thu, 29 Nov 2007 17:18:08 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200711291718.lATHI8tS048970@idle.juniper.net> To: "Rohan Mahy" Subject: Re: Why NETCONF needs a data modeling language In-reply-to: <953beacc0711290812t68d2cc09se1f4ff0578cc5836@mail.gmail.com> Date: Thu, 29 Nov 2007 12:18:08 -0500 From: Phil Shafer X-OriginalArrivalTime: 29 Nov 2007 17:21:22.0486 (UTC) FILETIME=[434BBD60:01C832AC] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org "Rohan Mahy" writes: >Organically as a practical matter, new work in W3C that uses XML is >definitely using Relax NG. I don't think there is an official policy >statement or something like that. A telling example is the XHTML2.0 spec >(work in progresss) at http://www.w3.org/TR/xhtml2/ . It is supposed to have >Normative schema in RNG (Sect B+C), XSD (Sect D+E), and DTD (Sect F+G). >Only Relax is filled in. I have spoken with folks active in other W3 working >groups and they report a similar pattern. This only means that the author's of xhtml2 like rng more than xsd (and dtd). I surely don't blame them, but the fact that there's a section for xsd conflicts your statement that "W3C no longer uses XSD". In my world, we've seen no requests for rng. No idea why. I know the WSDL world drinks XSD for breakfast, and are probably the heavy users. Me, I still think XSD is a "write-only" language. Anyway, this is way off topic..... Thanks, Phil From discuss-bounces@apps.ietf.org Thu Nov 29 14:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixod9-0006fb-CB; Thu, 29 Nov 2007 14:00:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixod8-0006fR-PA for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 14:00:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixod8-0006fI-FV for discuss@apps.ietf.org; Thu, 29 Nov 2007 14:00:58 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixod7-0004Pn-A1 for discuss@apps.ietf.org; Thu, 29 Nov 2007 14:00:58 -0500 Received: by nz-out-0506.google.com with SMTP id v1so1351091nzb for ; Thu, 29 Nov 2007 11:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=0Zi5uL4cHuGj4e7Cgl2H4IUhW3lihopp1rlUVAipmHc=; b=wo+o+UWdYgmVfnp8kwPm64p1CwjMW+BfIkqGlkluBZ/1yNeQoNTr1iIWBxhmk6CgvbUHcp8kcyqyEAoMRBKB4Hr47S0Tri/E860moDmrrYR9gPYNlfQxwpzF/Kw/icuZH7qeC2NhwTWzGxB4Tz9HxC94mfbAEn+sTjRfp/9Jg1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=xQ8b3wHOveJn86DrsjOCE44h7wKxVye39HiscX16KTbpbMJYMsw9MfsZaC0XuIE2baJ/1QZ80BXZJDJcDb19l/ZKzwl1ZWvAOIxBTHQQYCDROV9mGO/dWvC6I+tUkqN4BZsG9kJd13FM4COCi3RnUEqY/U4dOh2noN8RuSw7xuM= Received: by 10.142.125.5 with SMTP id x5mr356918wfc.1196362855823; Thu, 29 Nov 2007 11:00:55 -0800 (PST) Received: by 10.142.214.15 with HTTP; Thu, 29 Nov 2007 11:00:55 -0800 (PST) Message-ID: <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> Date: Thu, 29 Nov 2007 11:00:55 -0800 From: "Rohan Mahy" To: "Balazs Lengyel" Subject: Re: analysis of YANG vs. RELAX NG In-Reply-To: <474E83A4.3050000@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3115_10710629.1196362855740" References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E83A4.3050000@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_3115_10710629.1196362855740 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Nov 29, 2007 1:17 AM, Balazs Lengyel wrote: > Hello Rohan, > Thanks for your response. Here are some replies. > Balazs > > Rohan Mahy wrote: > ... > > These aspects are not *missing* from Relax NG. Some of these things are > > not in the scope of the Relax NG schema, but can be defined as an > > additional layer on top of a specific Relax schema. > [BALAZS]: Yes but if you need to extend RelaxNg, you loose much/most of > the advantage of using > a standard language. As we agreed all the extensions will need custom > tools. These tools are > already available for Yang, but not for RelaxNg. The experience with > SNMP/SMI tools in the last > decades also tells us that at the end nearly all SNMP tools were custom > built and not based on > standard ASN.1 tools. So the gain of following the standard is even more > limited. > > We can even write > > schema which describes what syntax is allowed for these annotations in a > > netconf-semantics namespace. > > > > > > - what does a default mean for configuration data > > > > > > this is semantic. > > > [BALAZS]: Yes, you recognized one of our main points: NETCONF needs > semantics and processing > rules. These have to be defined. Current schema languages don really do > this. Thats one of our > reasons to do YANG. > A quote from the book RelaxNg by Eric van der List you recommended: > > "XML reintroduces a clean separation between data and processing. " yes However Netconf does need rules about processing, yes > so RelaxNg is not enough for us. This does not logically follow. You need chocolate and you need peanut butter, but it does not follow logically that you need a Reese's Peanut Butter Cup. I am proposing that you could combine syntax and semantics, or you can layer one on top of the other. Right now YANG is neither pure semantics, nor pure syntax. For example the distinction between the leaf-list and list objects in YANG is pretty syntactic. (One of the YANG team's "little-rules"). Likewise, creating containers automatically is a syntactic construction. (Another "little-rule", but at least this one is explicit). Defining new data types in YANG is completely gratuitous syntax. I think having semantics for configuration information in general would be a boon for the IETF, as we have several protocol that are used for configuration. Providing a way to describe semantics of common configuration concepts like default values, list keys, constraints among non-parent-child objects, all looks like great work to me, but I don't want to this so tied to NETCONF that I cannot use it elsewhere for other configuration data. I also don't want this rigidly attached to a specific syntax either. A lot of existing XML-based data formats use attributes extensively. Some XML-based languages (ex: GML) implement the equivalent of leaf-list using a single attribute with whitespace separated values (there is even a built-in data type (called "list") to handle this case). thanks, -rohan We can > reintroduce processing hints into RelaxNg, but is that still RelaxNg. > Processing features > needed include: > - handling semantics of NETCONF edit-config > - the meaning of default data for operational and configuration data > - ordering of list data > - automatic creation of some data (containers) > - placement of data in normal structures, notifications or RPCs > - others ??? > > > > > Maybe I have different implementors, but the implementor is more likely > > to have some XML experience than to be a "network management person". > > Following the principle mentioned in Section 3.1 of > > draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and > > simplicity for the reader takes precedence: > > > > As a consequence, preference should be give to solutions that > > simplify the task of readers. Reduction of the efforts required by > > writers is of secondary importance and the reduction of the efforts > > required by tool developers is of least important preference. While > > this perhaps seems obvious, it is at times difficult to take > > according design decisions, especially if the group working on a new > > data modeling language is dominated by tool developers or data model > > writers. > > > [BALAZS]: Yes as the above quote says it is NOT the implementors but the > readers i.e. network > operators that are important. I think they are much more familiar with the > concept of a managed > object or a list then "Pattern Compositions". > ------=_Part_3115_10710629.1196362855740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


------=_Part_3115_10710629.1196362855740-- From discuss-bounces@apps.ietf.org Thu Nov 29 14:27:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixp2O-0004vf-QY; Thu, 29 Nov 2007 14:27:04 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ixp2O-0004ro-7z for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 14:27:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixp2N-0004r3-UM for discuss@apps.ietf.org; Thu, 29 Nov 2007 14:27:03 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixp2M-0004E8-Dm for discuss@apps.ietf.org; Thu, 29 Nov 2007 14:27:03 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pSIOfp4jPdHaQmnVI3k0EcwYr6dJm9g4WIZCGBt/oWPN1oO2UvgiORNl99hT8OZ8; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.161] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ixp2K-0008BL-Mx for discuss@apps.ietf.org; Thu, 29 Nov 2007 14:27:01 -0500 Message-ID: <080901c832be$0dde32e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20071127.130355.18118495.mbj@tail-f.com><953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com><474D9194.3060103@ericsson.com><953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com><474E83A4.3050000@ericsson.com> <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> Subject: Re: analysis of YANG vs. RELAX NG Date: Thu, 29 Nov 2007 11:28:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a92cceabdd0a2632e80c7ca42a731e8c2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.161 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi - > From: "Rohan Mahy" > To: "Balazs Lengyel" > Cc: > Sent: Thursday, November 29, 2007 11:00 AM > Subject: Re: analysis of YANG vs. RELAX NG ... > I think having semantics for configuration information in general would be a > boon for the IETF, as we have several protocol that are used for > configuration. Providing a way to describe semantics of common > configuration concepts like default values, list keys, constraints among > non-parent-child objects, all looks like great work to me, but I don't want > to this so tied to NETCONF that I cannot use it elsewhere for other > configuration data. This is an admirable goal, but those of us who survived the GDMO / SMI wars have good reason to be wary here. Even something as simple as parent-child constraints can play out in protocol-specific ways. It might be nice in theory to have one language for everything, but there are good reasons why C displaced PL/1, and why attempts to use the SMI with CMIP, or GDMO with SNMP, never achieved much traction in the marketplace. Part of the problem is the risk that a language sufficiently expressive to define any legal model in all the protocol environments will be able to define models which will be broken in at least one of the protocol environments. (Consider the conflict, both syntactic and semantic, between SMI's "INDEX" and GDMO "NAME-BINDING", even though their purpose is the same, both from an information model and from a data model perspective.) > I also don't want this rigidly attached to a specific syntax either. A lot > of existing XML-based data formats use attributes extensively. Some > XML-based languages (ex: GML) implement the equivalent of leaf-list using a > single attribute with whitespace separated values (there is even a built-in > data type (called "list") to handle this case). ... If the data modeling language doesn't let us know unambiguously how things can show up on the wire, there's not much point, in my opinion. Randy From discuss-bounces@apps.ietf.org Thu Nov 29 15:06:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpeN-0005fU-OS; Thu, 29 Nov 2007 15:06:19 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxpeM-0005em-9H for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 15:06:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpeL-0005ca-Uk for discuss@apps.ietf.org; Thu, 29 Nov 2007 15:06:17 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxpeJ-0006oD-Is for discuss@apps.ietf.org; Thu, 29 Nov 2007 15:06:17 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 425DE8A263; Thu, 29 Nov 2007 21:06:14 +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 32275-01-2; Thu, 29 Nov 2007 21:06:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74FEA8A259; Thu, 29 Nov 2007 21:06:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 042EE4034C4; Thu, 29 Nov 2007 21:06:04 +0100 (CET) Date: Thu, 29 Nov 2007 21:06:04 +0100 From: Juergen Schoenwaelder To: Rohan Mahy Subject: Re: analysis of YANG vs. RELAX NG Message-ID: <20071129200604.GD12255@elstar.local> References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E83A4.3050000@ericsson.com> <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> 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: d0bdc596f8dd1c226c458f0b4df27a88 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Nov 29, 2007 at 11:00:55AM -0800, Rohan Mahy wrote: > I am proposing that you could combine syntax and semantics, or you can layer > one on top of the other. Right now YANG is neither pure semantics, nor pure > syntax. For example the distinction between the leaf-list and list objects > in YANG is pretty syntactic. (One of the YANG team's "little-rules"). > Likewise, creating containers automatically is a syntactic construction. > (Another "little-rule", but at least this one is explicit). Defining new > data types in YANG is completely gratuitous syntax. Perhaps it helps me if you can define what you consider syntactic and what semantic. Having your definition will help me to understand what you have in mind and where you draw the line. I must note that types have been extremely successful in terms of actual reuse in the SMI world. You may consider data types "gratuitous syntax" but they are damn useful from our experience in writing data models. > I think having semantics for configuration information in general > would be a boon for the IETF, as we have several protocol that are > used for configuration. Providing a way to describe semantics of > common configuration concepts like default values, list keys, > constraints among non-parent-child objects, all looks like great > work to me, but I don't want to this so tied to NETCONF that I > cannot use it elsewhere for other configuration data. > > I also don't want this rigidly attached to a specific syntax either. > A lot of existing XML-based data formats use attributes > extensively. Some XML-based languages (ex: GML) implement the > equivalent of leaf-list using a single attribute with whitespace > separated values (there is even a built-in data type (called "list") > to handle this case). There are specific reasons why YANG does not support white space separated lists. I am sure Phil is happy to tell you how much fun these white space separated values can be and why we prefer to have every value within its own element in an instance document. (Well, actually even RFC 4741 states that subtree filtering on list content and mixed content is not supported.) I have been involved in a project where we tried to develop a data modelling language (called SMIng) that is protocol independent. From this experience, I have serious doubts that semantics decoupled from syntax will work anytime soon. There are relative obvious issues where for example the underlying naming system impacts the way you can formulate expressions. And then there are issues that only pop up once you really do it in practice, e.g. dealing with exceptions or errors. (In YANG, you can say that a violation of a given constraint leads to a specific NETCONF error report. Once you all do this in a decoupled semantics layer, you end up having to abstract the error/exception reporting mechanisms, which in my experience does not make the result necessarily easier to use). My personal eye opener in the SMIng project happened when started to move from toy examples to model something of moderate complexity (we picked DiffServ at that time because it actually has a nice informal information model plus a MIB module which does supports configuration). But don't get me wrong, I do not want to discourage anyone from trying it - perhaps there are people who can solve this challenge. My only concern is that it will take years to get it done with no clear signs upfront that it will actually work. The YANG mission is much less ambitious and down to earth, simply driven by the goal to create a vendor independent domain specific data modeling languages that can replace proprietary solutions that have already been created. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From discuss-bounces@apps.ietf.org Thu Nov 29 16:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrNF-0005WF-Ej; Thu, 29 Nov 2007 16:56:45 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxrNC-0005Vt-He for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 16:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrNC-0005Vh-5g for discuss@apps.ietf.org; Thu, 29 Nov 2007 16:56:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrNB-00084W-GY for discuss@apps.ietf.org; Thu, 29 Nov 2007 16:56:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE021210FC for ; Thu, 29 Nov 2007 22:56:40 +0100 (CET) X-AuditID: c1b4fb3e-b16a4bb00000459d-5a-474f3598b486 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E55C4210F5 for ; Thu, 29 Nov 2007 22:56:40 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 22:56:40 +0100 Received: from [153.88.21.8] ([153.88.21.8]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 22:56:40 +0100 From: David Partain Organization: Ericsson AB To: discuss@apps.ietf.org Subject: a very drafty draft on the "whys" of YANG Date: Thu, 29 Nov 2007 22:56:40 +0100 User-Agent: KMail/1.9.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711292256.40299.david.partain@ericsson.com> X-OriginalArrivalTime: 29 Nov 2007 21:56:40.0560 (UTC) FILETIME=[B8D5CF00:01C832D2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, http://www.eecs.jacobs-university.de/users/schoenw/draft-lengyel-why-yang-00.txt presents some of the arguments for YANG as a domain-specific modeling language for NETCONF. My thanks to Balazs for putting this together. Hopefully, it will aid in the discussion on Monday. Cheers, David From discuss-bounces@apps.ietf.org Fri Nov 30 12:10:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9Ng-0001D2-Cm; Fri, 30 Nov 2007 12:10:24 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iy9Nf-0001CT-B5 for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9Ne-0001Bn-Uj for discuss@apps.ietf.org; Fri, 30 Nov 2007 12:10:22 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9Nd-00057c-8h for discuss@apps.ietf.org; Fri, 30 Nov 2007 12:10:22 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 311F31B80C8; Fri, 30 Nov 2007 18:10:17 +0100 (CET) Date: Fri, 30 Nov 2007 18:10:15 +0100 (CET) Message-Id: <20071130.181015.170292466.mbj@tail-f.com> To: rohan.mahy@gmail.com Subject: Re: Why NETCONF needs a data modeling language From: Martin Bjorklund In-Reply-To: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> References: <474E0F71.2050003@andybierman.com> <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: yang@ietf.org, discuss@apps.ietf.org, ngo@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Rohan, "Rohan Mahy" wrote: > Look at the following Relax NG in compact form, side-by-side with YANG. > > container aaa { > container bbb { > leaf foo { type string; } > leaf bar { type uint32; } > } > } > > element aaa { > element bbb { > element foo { xsd:string }, > element bar { xsd:unsignedInt } > } > } > > This hardly seems like a big difference to me. I take the liberty to slightly modify this example into: container aaa { container bbb { leaf ifAdminStatus { type string; description "The desired state of the interface."; mandatory true; } leaf ifOperStatus { type string; description "The current operational state of the interface."; config false; } } } It's still a bit simplified, e.g. the type is just a string; it should really be an enumeration. The plain RNC is then: element aaa { element bbb { element ifAdminStatus { type xsd:string }?, element ifOperStatus { type xsd:string }? } } First of all, these two examples may look similar, but they have different meaning. The YANG example defines objects in the (configuration) data tree. The RelaxNG example defines a pattern which is used to validate some XML instance document. Anyway, if we want to make this RNC as extensible as the corresponding YANG version, we follow the recommendations in chapter 12 of the book: element aaa = aaa-content aaa-content = element bbb { bbb-content } bbb-content = element ifAdminStatus { ifAdminStatus-content }?, element ifOperStatus { ifOperStatus-content }? ifAdminStatus-content = type xsd:string ifOperStatus-content = type xsd:string Next, we add the YANG specific annotations: element aaa = aaa-content aaa-content = element bbb { bbb-content } bbb-content = [ yang:mandatory [ "true" ] yang:description [ "The desired state of the interface." ] ] element ifAdminStatus { ifAdminStatus-content }?, [ yang:description [ "The current operational state of the interface." ] ] element ifOperStatus { ifOperStatus-content }? >> yang:config [ "false" ] # I don't know if initial or # following annotations are # better (or even equal). ifAdminStatus-content = type xsd:string ifOperStatus-content = type xsd:string This is starting to become a bit difficult to grasp at first sight. Maybe we should follow the recommendation in the book and work with the XML notation instead. On a higher level, what exactly is the interpretation of adding e.g. the yang:mandatory true annotation to ifAdminStatus? The annotation is added to the pattern which matches the xml element . But that is just the encoding of the underlying object. What happens with this annotation if ifAdminStatus is not present in an instance document? Should we modify the meaning of the RelaxNG patterns and say that they also somehow define objects in the configuration data tree? This schema will validate replies only, since it contains both config and non-config data. According to your email, we'll have to add these to the definitions of get, get-config, edit-config, and copy-config: get-reply-content &= aaa get-config-reply-content &= # hmm... how do I do this w/o copy&paste? I just want # to add aaa/bbb/ifAdminstatus. edit-config-content &= # hmm... how do I do this w/o copy&paste? I just want # to add aaa/bbb/ifAdminstatus, but also add some nc:opertaion # attributes. All of this (and the other things we've discussed (and the things we haven't yet discussed :) ) can probably be solved by writing rules to restrict the usage of RelaxNG, add the necessary annotations (around 20), and write down extra interpretion of the RelaxNG constructs we're using, but my conclusion is the same as Juergen's list a-d in his latest email. To this list I'd like to add the readibility issue. /martin From discuss-bounces@apps.ietf.org Fri Nov 30 13:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAUs-0003dn-Kr; Fri, 30 Nov 2007 13:21:54 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyAUr-0003cR-3t for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 13:21:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAUq-0003cF-QS for discuss@apps.ietf.org; Fri, 30 Nov 2007 13:21:52 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyAUo-0007a8-KM for discuss@apps.ietf.org; Fri, 30 Nov 2007 13:21:52 -0500 Received: by wa-out-1112.google.com with SMTP id m16so2758501waf for ; Fri, 30 Nov 2007 10:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=Y2uEMlNI3eTDJThTwY/rH7TPu6AHMDbeS7EnlkCCXto=; b=kmsmTuEWO5wqs1RD8gbImnTg9xdp6GMfNm7INYUCNeUg+MRqMnimxJI627zrEjj0lIzKTNaAvHmeveW1vXOiMZaSkYha+wN5ESXoP8UgtxhJxW5kpHC18dUBmJTKnTv3XPwDJtfixXG7T6HyyFGl+1sI96DUsRcTx2JlYoVqCV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=EgsAmgPtT8YJtcXNiXol1ONORa/JwSRoP8kr97MmIyvM+D4JEdD9agu9H7KoF8Y8NfkZj8JoKRFROtx24gIQNDwIq4N35/Sdlu+uy7L23uTScS3cVtWY/fZFX6ZOWAHlYPFzlooaPZczsBDq6BwH8jPUCM7+if3oxKy5A2PNAck= Received: by 10.114.57.1 with SMTP id f1mr227718waa.1196446907858; Fri, 30 Nov 2007 10:21:47 -0800 (PST) Received: by 10.114.161.15 with HTTP; Fri, 30 Nov 2007 10:21:47 -0800 (PST) Message-ID: <517bf110711301021u651701aclff2a63ee37877d2@mail.gmail.com> Date: Fri, 30 Nov 2007 10:21:47 -0800 From: "Tim Bray" To: "Apps Discuss" Subject: My XML session Sunday 3PM MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 2dac57928af93b26 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Since my agenda isn't posted on the IETF70 site, it might be helpful for people planning their Sundays to know it, and be sure to stay away: - How to think about whether XML is a good choice or not for use in an Internet protocol. There are alternatives which are often superior choices. - If you are going to use XML, how to think about inventing your own language as opposed to using an existing one, with a review of some popular languages you might want to consider adopting. - If you are going to design your own language, how you might go about doing so. This would include discussion of: -- verbosity vs. terseness -- the use of schemas, and the choice of available schema languages -- extensibility -- i18n and encoding issues Plus, the crowd will probably be small, so if you have your own XML/IETF issue that needs discussion, bring it along. -T From discuss-bounces@apps.ietf.org Fri Nov 30 14:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBf7-0001Qs-Qt; Fri, 30 Nov 2007 14:36:33 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyBf7-0001Qb-FJ for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 14:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBf7-0001QR-5n for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:36:33 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyBf5-0000dn-7v for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:36:33 -0500 Received: (qmail 58448 invoked from network); 30 Nov 2007 19:27:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@207.215.248.215 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2007 19:27:40 -0000 X-YMail-OSG: p5nTzfsVM1lWvK8VEhVUyAXZIua6kmtdlOs9Ee51fb08CbPZ Message-ID: <475064A5.1060300@andybierman.com> Date: Fri, 30 Nov 2007 11:29:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Harrington Subject: Re: Why NETCONF needs a data modeling language References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> In-Reply-To: <241201c83366$9acf8070$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org David Harrington wrote: > >> Hi, >> >> There are a few questions that the IESG and others have asked, >> which I will try to address: >> >> Q1) Why does NETCONF need a DML at all? >> Q2) Why is NETCONF special? >> Q3) Why won't lots of other WGs want to define their own >> protocol-specific DMLs? >> Q4) Why isn't XSD or RelaxNG good enough? > > I'll take a whack at answering the same questions. > > A1) Why does NETCONF need a DML at all? > > to promote vendor-neutral interoperable management. > > It is much easier to develop standards when everybody uses the same > basic language to communicate; this "common language for shared > communication" is also reflected in the IETF decision to use English > text and ASCII documents. > This is a good point. I always thought it was important that if I knew how to read one MIB module, I knew how to read them all. If though I know how to read XSD (and most of RNG), vendors and WGs are all over the map wrt/ how they are used. IMO, there are language-independent issues, such as data organization and data naming, that are discussed in draft-bierman-ncx-smi-00.txt. We should at least try to understand the difference between the landscape 10 years from now, with and without any data organization conventions. These issues need to be dealt with consistently, regardless of the DML being used. Even if YANG is used, the XSD translation needs to match in every way. > This is not just about being able to standardize **device > management**; it is a basic step to permit the standardization of > **network management** and possibly **services management". The DML is > a basic building block. > > A2) Why is NETCONF special? > > It is and it isn't. Netconf is only one protocol used for network > management. > > It has some unique requirements, such as using a document-based > approach and differentiating the data for config versus state and for > dealing with different time-defined contexts such as running and > startup configs. This differs from other network management protocols, > such as SNMP and syslog and ipfix, which use their own data formats, > and usually deal only with the currently-running config. Netconf is a > tool designed to meet the special requirements of configuration, and > the DML needs to support special features not found in other NM-DMLs. > > Netconf is not special, in that any language used for network > management is likely to have certain common requirements. NM data > models are commonly used directly by humans, in their raw form, such > as when they troubleshoot problems using network sniffers. NM data > models are also commonly used by NMS applications that can handle the > translations into a more human-readable format. Designers of NM tools > (e.g., protocols and data models) thus need to pay close attention to > who will use the information, and to assume that the data will be used > both directly by humans and by applications. Operators have complained > strongly that OIDs are very hard to work with in raw form, yet > operators frequently need to deal with the raw form of the data. Not just the OIDs, although they are horrible. Also the limited data modeling capability, primitive protocol operations, and the very small granularity of data access. NETCONF addresses many of the short-comings of SNMP, which one would expect when given 15 years of hindsight to start with. > > A3) Why won't lots of other WGs want to define their own > protocol-specific DMLs? > >..... > A4) Why isn't XSD or RelaxNG good enough? > > As mentioned in A2, NM data models need to be both machine- and > human-readable. XSD is machine-readable, but it is a tough language > for humans. RelaxNG seems better. > > As discussed further in a different email, Netconf will almost > certainly need a DML suited to its requirements, and if RelaxNG is > found to be human-friendly-enough, we would almost certainly still > need to select a subset and adapt it to meet configuration > requirements. So the benefit of using RelaxNG over a domain-specific > DML may be lost by using an adapted-subset of RelaxNG. > > Most operators already understand languages like Perl and C and > Javascript, because they already need to write lots of scripts to > manage their networks. Most implementers of NM support in > internetworking devices work in C or a variant of C. It makes a lot of > sense to use a language with a C-like syntax for these people, rather > than forcing them to learn yet another language that was designed for > some other purpose. It is not an accident that YANG looks familiar to people who know SMI and C. YANG uses something similar to the RNG-compact clause format, which is very readable, and very extensible. YANG has some subtle improvements over SMI, besides the obvious ones. In SMIv2 we write: InterfaceIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub- layer must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization." SYNTAX Integer32 (1..2147483647) In YANG: typedef InterfaceIndex { smiext:DISPLAY-HINT "d"; status current; description "A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub- layer must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization."; type int32 { range "1..max"; } } Note 3 things: 1) keywords that start a clause can have a prefix, meaning that they are language extensions, defined elsewhere with the 'extension' clause. 2) strings are usually quoted, but if they don't contain whitespace, or a few special tokens, they can be unquoted, like 'current'. 3) The range clause has 'min' and 'max' keywords, so you don't have to hunt down a previous example and paste in '2147483647' anymore. The compiler will fill it in for you. > > [soap] > somebody commented that the designers of XSD and RelaxNG really > understand how to design DMLs, implying that the OPS community does > not. Many of the people involved in the ongoing DML discussions over > the years, and now, are MIB Doctors and operators and protocol > designers, and have had years of experience designing and working with > SMI and network management. They understand the requirements of a DML > for NM far more than the designers of XSD or RelaxNG, who were not > designing their DMLs for NM purposes. > [end soap] > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > Andy From discuss-bounces@apps.ietf.org Fri Nov 30 14:38: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 1IyBhT-0003Pi-1y; Fri, 30 Nov 2007 14:38:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyBhR-0003PD-Nu for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 14:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBhR-0003P0-E5 for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:38:57 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyBhR-0001Du-0n for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:38:57 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 806991B80C5; Fri, 30 Nov 2007 20:38:54 +0100 (CET) Date: Fri, 30 Nov 2007 20:38:49 +0100 (CET) Message-Id: <20071130.203849.128933561.mbj@tail-f.com> To: rohan.mahy@gmail.com Subject: Re: analysis of YANG vs. RELAX NG From: Martin Bjorklund In-Reply-To: <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> References: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E83A4.3050000@ericsson.com> <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, I really appreciate your comments on the YANG draft. If there are other little rules you have found, please let us know. "Rohan Mahy" wrote: > For example the distinction between the leaf-list and list objects > in YANG is pretty syntactic. (One of the YANG team's > "little-rules"). I can understand if you argue that leaf-list is not necessary, since we have list. But why is having leaf-list a little-rule? We think leaf-list is useful of course, but that's not the point (I think). > Likewise, creating containers automatically is a syntactic construction. > (Another "little-rule", but at least this one is explicit). I think that this is something we can fix. I think the problem lies more in the current description of the concept (of containers used for structuring purpose), than in the concept itself. The underlying idea is that if a container is used for structural purposes only, then it doesn't have to be present in the XML encoding unless necessary. I.e. if it currently doesn't have any children, then it doesn't have to be encoded. > Defining new data types in YANG is completely gratuitous syntax. I'm sorry, I don't understand what this means. Could you explain what you mean? /martin From discuss-bounces@apps.ietf.org Fri Nov 30 14:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBwp-0008CA-4S; Fri, 30 Nov 2007 14:54:51 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyBwn-0008Bk-SY for discuss-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 14:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBwn-0008BS-Io for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:54:49 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyBwl-0004PP-91 for discuss@apps.ietf.org; Fri, 30 Nov 2007 14:54:49 -0500 Received: (qmail 82334 invoked from network); 30 Nov 2007 19:54:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.164.104 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2007 19:54:02 -0000 X-YMail-OSG: lHJOV7kVM1mx91auVTpROfAE8YANZ952VKNHWsTBaL2Q1VPj Message-ID: <47506AD3.7060206@andybierman.com> Date: Fri, 30 Nov 2007 11:56:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: analysis of YANG vs. RELAX NG References: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <474E83A4.3050000@ericsson.com> <953beacc0711291100lfe8cb6xeba5ac28b091b6fb@mail.gmail.com> <20071130.203849.128933561.mbj@tail-f.com> In-Reply-To: <20071130.203849.128933561.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Martin Bjorklund wrote: > Hi, >... >> Defining new data types in YANG is completely gratuitous syntax. > > I'm sorry, I don't understand what this means. Could you explain what > you mean? > I am confused by this as well. I think this means the extra types in YANG that are not in RNG. They are mostly NETCONF-specific, or at least NM-specific. The choice of builtin types is somewhat subjective. Some of the 'extra' types could be derived types instead. Almost all types could just be 'string', and we don't need to bother with any data-typing at all. Indeed, that is a choice the data model writer could make, although IMO it is bad SW design. > > /martin > > > > Andy
On Nov 29, 2007 1:17 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello Rohan,
Thanks for your response. Here are some replies.
Balazs

Rohan Mahy wrote:
...
> These aspects are not *missing* from Relax NG.  Some of these things are
> not in the scope of the Relax NG schema, but can be defined as an
> additional layer on top of a specific Relax schema.
[BALAZS]: Yes but if you need to extend RelaxNg, you loose much/most of the advantage of using
a standard language. As we agreed all the extensions will need custom tools. These tools are
already available for Yang, but not for RelaxNg. The experience with SNMP/SMI tools in the last
decades also tells us that at the end nearly all SNMP tools were custom built and not based on
standard ASN.1 tools. So the gain of following the standard is even more limited.
> We can even write
> schema which describes what syntax is allowed for these annotations in a
> netconf-semantics namespace.
>
>
>     - what does a default mean for configuration data
>
>
> this is semantic.
>
[BALAZS]: Yes, you recognized one of our main points: NETCONF needs semantics and processing
rules. These have to be defined. Current schema languages don really do this. Thats one of our
reasons to do YANG.
A quote from the book RelaxNg by Eric van der List you recommended:

"XML reintroduces a clean separation between data and processing. "

yes

However Netconf does need rules about processing,

yes
 
so RelaxNg is not enough for us.

This does not logically follow.  You need chocolate and you need peanut butter, but it does not follow logically that you need a Reese's Peanut Butter Cup.

I am proposing that you could combine syntax and semantics, or you can layer one on top of the other. Right now YANG is neither pure semantics, nor pure syntax. For example the distinction between the leaf-list and list objects in YANG is pretty syntactic. (One of the YANG team's "little-rules").  Likewise, creating containers automatically is a syntactic construction. (Another "little-rule", but at least this one is explicit). Defining new data types in YANG is completely gratuitous syntax.

I think having semantics for configuration information in general would be a boon for the IETF, as we have several protocol that are used for configuration.  Providing a way to describe semantics of common configuration concepts like default values, list keys, constraints among non-parent-child objects, all looks like great work to me, but I don't want to this so tied to NETCONF that I cannot use it elsewhere for other configuration data. 

I also don't want this rigidly attached to a specific syntax either.  A lot of existing XML-based data formats use attributes extensively. Some XML-based languages (ex: GML) implement the equivalent of leaf-list using a single attribute with whitespace separated values (there is even a built-in data type (called "list") to handle this case). 

thanks,
-rohan


We can
reintroduce processing hints into RelaxNg, but is that still RelaxNg. Processing features
needed include:
- handling semantics of NETCONF edit-config
- the meaning of default data for operational and configuration data
- ordering of list data
- automatic creation of some data (containers)
- placement of data in normal structures, notifications or RPCs
- others ???


 
>
> Maybe I have different implementors, but the implementor is more likely
> to have some XML experience than to be a "network management person".
> Following the principle mentioned in Section 3.1 of
> draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and
> simplicity for the reader takes precedence:
>
>    As a consequence, preference should be give to solutions that
>    simplify the task of readers.  Reduction of the efforts required by
>    writers is of secondary importance and the reduction of the efforts
>    required by tool developers is of least important preference.  While
>    this perhaps seems obvious, it is at times difficult to take
>    according design decisions, especially if the group working on a new
>    data modeling language is dominated by tool developers or data model
>    writers.
>
[BALAZS]: Yes as the above quote says it is NOT the implementors but the readers i.e. network
operators that are important. I think they are much more familiar with the concept of a managed
object or a list then "Pattern Compositions".