Re: Why NETCONF needs a data modeling language

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 29 November 2007 11:35 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 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 <j.schoenwaelder@jacobs-university.de>
To: Rohan Mahy <rohan.mahy@gmail.com>
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 <ngo@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 <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

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         <http://www.jacobs-university.de/>