Re: [YANG] new pyang errors

Phil Shafer <phil@juniper.net> Wed, 23 January 2008 20:58 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 1JHmfm-0004Rg-BJ; Wed, 23 Jan 2008 15:58:14 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmfk-0004RJ-9W for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 15:58:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmfh-0004Pr-TG for yang@ietf.org; Wed, 23 Jan 2008 15:58:11 -0500
Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmfh-0001O2-Df for yang@ietf.org; Wed, 23 Jan 2008 15:58:09 -0500
Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jan 2008 12:57:41 PST
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jan 2008 12:58:04 -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 m0NKw4914920; Wed, 23 Jan 2008 12:58:04 -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 m0NKw1MF024713; Wed, 23 Jan 2008 20:58:01 GMT (envelope-from phil@idle.juniper.net)
Message-Id: <200801232058.m0NKw1MF024713@idle.juniper.net>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: [YANG] new pyang errors
In-reply-to: <1201093098.17304.156.camel@missotis>
Date: Wed, 23 Jan 2008 15:58:00 -0500
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 23 Jan 2008 20:58:04.0492 (UTC) FILETIME=[A5D0A8C0:01C85E02]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: yang@ietf.org
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

Ladislav Lhotka writes:
>My definition of mandatory: mandatory configuration parameters are those
>that are essential for device or protocol operation. It doesn't matter
>whether they are set by the user/application, supplied from non-volatile
>memory or perhaps even hardwired.

Why would you need or want to mark is as mandatory if the value
is hardwired?  What are you trying to say by calling a parameter
"mandatory" and who are you trying to say it to?

If the application need do nothing with such hardwired parameters,
why does it need to distinquish them?

If the device need to nothing <ditto>?

YANG defines constraints on the XML that passes between the client and
server.  Nearly every statement in a YANG module defines a rule which
that XML must follow, both during protocol operations and the valid
configuration being built.

Mandatory is such a constraint, and should be an indication to the
NETCONF client application that it needs to do something explicit
to satisfy this constraint.  If the mandatory parameter isn't set,
the configuration isn't valid.

If we allow this mandatory constraint to be satisfied via mechanisms
that do not involve the client and server, why have it?  How is the
application to discern the difference between a real constraint and
a parameter that the fairy god mother daemon fills in?

>A (full) configuration is valid only
>if it contains all values that are declared as mandatory in the DM. 

This is a definition that both sides of the debate can love, which
is a problem.

Thanks,
 Phil


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