Re: [YANG] default values

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 17 January 2008 15:22 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 1JFWZP-0002ou-Cc; Thu, 17 Jan 2008 10:22:19 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFWZO-0002op-4O for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 10:22:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWZN-0002oh-Qp for yang@ietf.org; Thu, 17 Jan 2008 10:22:17 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFWZL-0006O0-Ci for yang@ietf.org; Thu, 17 Jan 2008 10:22:17 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C14198A3C5; Thu, 17 Jan 2008 16:22: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 04510-07-9; Thu, 17 Jan 2008 16:22: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 9F19D8A2DD; Thu, 17 Jan 2008 16:22:01 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0D0E4468FE9; Thu, 17 Jan 2008 16:22:01 +0100 (CET)
Date: Thu, 17 Jan 2008 16:22:00 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: [YANG] default values
Message-ID: <20080117152200.GA29447@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@cesnet.cz>, yang@ietf.org
References: <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> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1200582110.19372.43.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
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 04:01:50PM +0100, Ladislav Lhotka wrote:
 
> At the start of a NETCONF session, the values in the
> running/startup/whatever configuration may be different even if the
> server's factory defaults follow the standards. The client can't IMO
> safely avoid checking or setting all variables in server's
> configuration.

Sure. But when I create something new without specifying all defaults,
do I know what I get? In SNMP, you don't. In YANG, you do.
 
> > 
> > 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).
> 
> I think this applies to the default statement, too. I am arguing it's
> not needed for NETCONF operation and may complicate things.

So if I understand right, your proposal is to remove the default
statement, not to change its semantics, correct?

/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