Re: [YANG] new pyang errors

Ladislav Lhotka <lhotka@cesnet.cz> Fri, 25 January 2008 10:02 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 1JILNx-0008EZ-4A; Fri, 25 Jan 2008 05:02:09 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILNw-0008EI-41 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:02:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILNv-0008E2-QN for yang@ietf.org; Fri, 25 Jan 2008 05:02:07 -0500
Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILNt-0001I6-UQ for yang@ietf.org; Fri, 25 Jan 2008 05:02:07 -0500
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7A668D800BD for <yang@ietf.org>; Fri, 25 Jan 2008 11:02:05 +0100 (CET)
Subject: Re: [YANG] new pyang errors
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: yang@ietf.org
In-Reply-To: <200801250311.m0P3Bhbo036061@idle.juniper.net>
References: <200801250311.m0P3Bhbo036061@idle.juniper.net>
Content-Type: text/plain; charset=utf-8
Organization: CESNET
Date: Fri, 25 Jan 2008 11:02:05 +0100
Message-Id: <1201255325.24635.70.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
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

Phil Shafer píše v Čt 24. 01. 2008 v 22:11 -0500:
> Ladislav Lhotka writes:
> >In my interpretation the mandatory/optional and default concepts are
> >orthogonal. The former relates to the structure (leaf must or needn't
> >exist) whereas the latter to the value.
> 
> They aren't orthogonal.  Your intepretation leads to the logic Andy
> laid out earlier:
> 
>   Q1: Is it mandatory?
>      true -->
>        Q2: Does it have a default?
>           false -->
>               A: Then the leaf must be explicitly set

I guess I differ from Andy here: in my view the agent will fill here a
value that satisfies the DM, even though it is not a default specified
in the DM (i.e, it is vendor's internal default). For example, if IP
address is mandatory on an interface but no default is defined in the
DM, the device could set it to 0.0.0.0. From the viewpoint of validating
the configuration (my item 2), it is valid - the mandatory element
exists and its value (presumably) conforms to inet:ip-address. True, the
interface is not fully operational, but this has nothing to do with
validity of the configuration wrt the DM.

>           true -->
>               A: Then the agent must implicitly create it w/ the default
>      false -->
>         A: no one does anything
> 

> 
> How?  If I give the user a form to fill in with the full name (which
> I assume I should since the data model says it's there), and the user
> gives me one, I'll send it to the device.  Will the device throw it
> away?  This will lead to much weeping and gnashing of teeth.

In most cases a warning would be appropriate. I think though such
situations are hardly avoidable. I take your example:

     leaf mtu {
         type uint {
             range 576..8192;
         }
     }

What if a device supports only a subset of this range and the user tries
to set it to a value outside of this subset? Or should the range
statement in fact mean that this data model requires each implementation
to support the entire range?

> 
> >Again, my model: if a parameter is optional then the client cannot be
> >surprised if it is not in the configuration obtained by get-config and
> >attempts to set it are ignored or return a warning.
> 
> This would be disasterous and would render the entire effort of
> data modeling moot.  The data model is supposed to move us out
> of the Wild West and into a more civilized world.  If the locals
> can ignore parts of the law, then there is no law.  If you can't
> even find out what parts of the law are being ignored, you're lost.

If the law says something is optional, I can assume it's possible not to
have it.

> 
> >I fully agree, we only differ in the interpretation of a YANG statement.
> 
> It seems we disagree on much more than that.  Should we step back
> and think about what problem we're trying to solve?
> 
Okay, what I am trying to solve:

I'd like to have first rather generic data models that can be used by a
broad range of devices. This is IMO possible only if the data models are
relatively liberal. The first important step for me is to be able to
decide whether an entire configuration is valid (in a static XML-like
sense) and what it means for the NETCONF PDUs. This would already be a
big boon - the knobs would be standardised. I am not saying the other
aspects of validity (behaviour of the devices and managers) are
unimportant but these are separate problems that should be addressed
separately.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C



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