Re: [YANG] new pyang errors

Phil Shafer <phil@juniper.net> Thu, 24 January 2008 16:33 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 1JI50l-0004No-3l; Thu, 24 Jan 2008 11:33:07 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI50k-0004Ng-4U for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 11:33:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI50j-0004NY-Qn for yang@ietf.org; Thu, 24 Jan 2008 11:33:05 -0500
Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI50j-0002Is-AW for yang@ietf.org; Thu, 24 Jan 2008 11:33:05 -0500
Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 08:32:36 PST
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 08:29:26 -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 m0OGTQ953020; Thu, 24 Jan 2008 08:29:26 -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 m0OGTMe5030462; Thu, 24 Jan 2008 16:29:22 GMT (envelope-from phil@idle.juniper.net)
Message-Id: <200801241629.m0OGTMe5030462@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
Subject: Re: [YANG] new pyang errors
In-reply-to: <4798B8C3.6020902@andybierman.com>
Date: Thu, 24 Jan 2008 11:29:22 -0500
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 24 Jan 2008 16:29:26.0844 (UTC) FILETIME=[495C7FC0:01C85EA6]
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: yang@ietf.org, Ladislav Lhotka <lhotka@cesnet.cz>
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Andy Bierman writes:
>IMO this overlap between 'default' and 'mandatory' is not relevant.

Well, the issue we started with was what happens when there's a
default with mandatory true, but let's move on....

>If mandatory=false, then the default is ignored in the agent.

"ignored"?  No, it's used internally as the default when
the leaf doesn't exist.

>In your interpretation, mandatory=true causes the agent to
>ignore the default.

Same comment.

>Your view of mandatory is inconsistent with the rest of YANG,
>which (correctly) focuses on the description of valid NETCONF configuration
>databases, not the PDUs.

I don't agree.  YANG defines a data model, which consists in part
of a set of constraints on the data that appears inside valid
databases for that model.  Out of these constraints flow (fairly
easily) constraints on the NETCONF operations used to manipulate
the data in that database, which leads to constraints on those PDUs.
I don't see this at at odds with the rest of YANG.

>When focusing on the config, what
>difference does it make if the manager explicitly sets the mtu to 1500,
>or if the agent sets it to 1500 by default?  The data model should describe
>what a valid mtu leaf looks like in the config, and nothing more.

Why do we model data?  What are we trying to get out of the data
model?  My goal is to provide a formal description between the
device and client applications to allow those client applications
to manipulate data on the devices with a strong understanding of
what the data means and a rich set of operations for manipulating
that data.  We develop a contract between the client and server so
both sides agree that what an "mtu" means and what the valid values
are, when it needs to be set and what it means if it is not set.

So thing of the data model from that device/application point of
view and hopefully you'll understand why the term mandatory should
describe the requirement that something external must set this value.

Think of what "required" means on a web page.  It means that you
the user need to fill in a value.  If the web server knows an
appropriate default, it can fill it in and you don't need to do
anything.

Thanks,
 Phil


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