Re: [YANG] new pyang errors

Phil Shafer <phil@juniper.net> Fri, 25 January 2008 03:12 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 1JIEzU-0007Pp-Dh; Thu, 24 Jan 2008 22:12:28 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIEzT-0007LP-QN for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 22:12:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIEzT-0007HA-CE for yang@ietf.org; Thu, 24 Jan 2008 22:12:27 -0500
Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIEzS-0005iX-MJ for yang@ietf.org; Thu, 24 Jan 2008 22:12:27 -0500
Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 19:12:22 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 19:11:48 -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 m0P3Blq01302; Thu, 24 Jan 2008 19:11:47 -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 m0P3Bhbo036061; Fri, 25 Jan 2008 03:11:44 GMT (envelope-from phil@idle.juniper.net)
Message-Id: <200801250311.m0P3Bhbo036061@idle.juniper.net>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: [YANG] new pyang errors
In-reply-to: <1201197939.20662.194.camel@missotis>
Date: Thu, 24 Jan 2008 22:11:43 -0500
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 25 Jan 2008 03:11:48.0332 (UTC) FILETIME=[05E0DAC0:01C85F00]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
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:
>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
          true -->
              A: Then the agent must implicitly create it w/ the default
     false -->
        A: no one does anything

I want to see the question as:

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

Internally, when the subcomponent fetches data from the database,
you may have logic like:

   value = isconfig(x) ? value(x) : default(x);

So if I don't make an mtu leaf, the software that asks for the mtu
can get the default value without forcing this into the config.
 
>Your view of mandatory brings another one:
>4. client behaviour (must set mandatory parameters)
>Each of these views differs in some aspects from the others. I would
>myself prefer to concentrate on 2 and try to infer what it means for 1.

I'm not adding this aspect.  The client must know what parameters
it needs to set.  I'm just wanting the answer to this aspect to
be simple.  If it's mandatory, the client will need to set it.  If
it's mandatory and not present, the server will fail the config.

>In some cases this mapping is automatic, some cases are defined in the
>YANG draft and some are not clear yet (to me at least).

Please let me know where it isn't clear and we can fix the draft.

>> Here I completely and strongly disagree.  A data model defines how
>> data works.  If you tell a client that your support this data model
>> and you don't implement "full-name", your telling a fib.  Customers
>> will catch you and bludgeon you about the head and shoulders.
>
>No, since it's optional (but of course lada:optional != phil:optional).
>Both the device and manager can live without full names being in the
>database.

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.

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

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

Thanks,
 Phil


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