Re: [YANG] default values

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 17 January 2008 13:57 UTC

Return-path: <yang-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFVFQ-0001sq-2v; Thu, 17 Jan 2008 08:57:36 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFVFO-0001sW-Jp for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 08:57:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFVFO-0001rg-6p for yang@ietf.org; Thu, 17 Jan 2008 08:57:34 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFVFL-0006kU-FJ for yang@ietf.org; Thu, 17 Jan 2008 08:57:31 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B7578A270; Thu, 17 Jan 2008 14:57:30 +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 28441-09; Thu, 17 Jan 2008 14:57:25 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0B718A39A; Thu, 17 Jan 2008 14:57:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 29755468ED0; Thu, 17 Jan 2008 14:57:24 +0100 (CET)
Date: Thu, 17 Jan 2008 14:57:24 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: [YANG] default values
Message-ID: <20080117135724.GC29301@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@cesnet.cz>, yang@ietf.org
References: <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <DCABA351-3933-4AED-A6E6-80C5F85E3F9C@jdscons.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1200571644.10666.91.camel@missotis>
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: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: yang@ietf.org
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: YANG modeling Language for NETCONF <yang.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/yang>
List-Post: <mailto:yang@ietf.org>
List-Help: <mailto:yang-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=subscribe>
Errors-To: yang-bounces@ietf.org

On Thu, Jan 17, 2008 at 01:07:24PM +0100, Ladislav Lhotka wrote:

> > I have no clue what you mean with "validating XML documents in the
> > NETCONF context".
> 
> The NETCONF messages exchanged between the server and client are
> serialised XML and validation means that the other side is able to tell
> whether the received data are legal. It's not so important whether you
> perform this check on the serialised XML, DOM tree or otherwise. YANG
> draft always speaks about XML representations and nothing else.

No, you are missing an important piece. While an XML fragment shipped
in a NETCONF message may be valid, it might not lead to a valid
configuration. I don't think it is true that the YANG draft "always
speaks about XML representations and nothing else".

Regarding defaults, the question boils down to whether a NETCONF
client can assume that specified defaults are used or whether to be on
the safe side the client has to either set defaults itself or check
what was set by the server.

The alternative would be to have a mechanism allowing implementations
to post the defaults they are going to use rather than hard wiring
defaults in the specification. So a vendor can augment a standard with
the defaults that the vendor's implementation is using. This surely
adds some complexity. An even further reaching mechanism would be to
make the defaults being used by an implementation itself writable,
e.g. by introducing a template mechanism which adds defaults for stuff
not defined explicitely by a NETCONF client.

Our goal was to start with something simple, allowing us to add more
powerful mechanism via extensions over time once we see that they are
really needed (that is there is enough uptake of NETCONF / YANG).

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


_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang