Re: analysis of YANG vs. RELAX NG

"Randy Presuhn" <randy_presuhn@mindspring.com> Thu, 29 November 2007 19:27 UTC

Return-path: <discuss-bounces@apps.ietf.org>
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 <randy_presuhn@mindspring.com>
To: discuss@apps.ietf.org
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 <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Hi -

> From: "Rohan Mahy" <rohan.mahy@gmail.com>
> To: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
> Cc: <discuss@apps.ietf.org>
> 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