Re: [YANG] new pyang errors

Andy Bierman <ietf@andybierman.com> Wed, 23 January 2008 06:21 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 1JHYzY-0007AI-7u; Wed, 23 Jan 2008 01:21:44 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYzW-0007A2-TU for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:21:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYzW-00079u-6d for yang@ietf.org; Wed, 23 Jan 2008 01:21:42 -0500
Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHYzV-0000oD-IJ for yang@ietf.org; Wed, 23 Jan 2008 01:21:42 -0500
Received: (qmail 46962 invoked from network); 23 Jan 2008 06:21:40 -0000
Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2008 06:21:40 -0000
X-YMail-OSG: cAlJxDMVM1nTVhdr7rHLoZXxoJdRPcWjqvKQRCExkCuwH1S9Xow4oGC1vJoB78Lj7zH5d4CcgQRNpGAcK6OPnGpa
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4796DD12.1@andybierman.com>
Date: Tue, 22 Jan 2008 22:22:10 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
Subject: Re: [YANG] new pyang errors
References: <200801230532.m0N5W7Tt019859@idle.juniper.net>
In-Reply-To: <200801230532.m0N5W7Tt019859@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
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

Phil Shafer wrote:
> Ladislav Lhotka writes:
>> Relying on common universal
>> defaults would make the system fragile.
> 
> As will shipping voluminous defaults.

huh -- it uses up an extra second of bandwidth so the system is fragile?


> 
> Visibility into defaults is a distinct issue from carrying the
> defaults in the configuration database.  If I have an object with
> 50 fields where only 2 or 3 are set on each instance, carting around
> fully-fleshed configs will be incredibly annoying.
> 
> My view of configuration is that if you set it, it should be there.
> If you didn't set it, it shouldn't be there.  If you want extra
> information, ask for it.  But the normal view of configuration
> should be restricted to only what the user or application expressed
> configured.
> 

There are lots of scenarios that cause an operator or application
to need to full configuration, not just the values that do not have
the default value.  Many people (including me) do not view this
scenario as the same as the node is not present:

   1) relying on external documentation is too costly on the operator
      and fragile.  Only direct response from the agent is sufficient.
      Looking up answer X to question Y at server Z to find out
      what agent A will answer when asked question Y is full of problems.

   2) augment 'when' clauses could make it confusing as too whether
      a missing node is because it isn't there or because it has a
      default value

   3) more complex agent conformance and variance mechanisms than
      the current ones (i.e., none) could make it unclear whether
      an object is missing due to non-applicability or due to
      non-conformance.

   4) A buggy agent may report all kinds of capabilities and conformance
      and still set a default to a different value than the document.


Andy


> This leads directly to my interpretation of "mandatory".  A mandatory
> config statement is one that some user or application must expressly
> configure.  If the configuration is valid without the statement,
> then it's not mandatory.
> 
> The "mandatory"-ness describes the interaction between the device and
> applications configuring it.  If the application must create the statement,
> then the statement is mandatory.  The "mandatory plus default" interpretation
> Andy's using is more of a description of the interaction between the on-box
> management software and the other on-box software components.  IMHO this is
> less interesting and more internals that YANG should be describing.
> 
> Thanks,
>  Phil
> 
> 
> _______________________________________________
> YANG mailing list
> YANG@ietf.org
> https://www1.ietf.org/mailman/listinfo/yang
> 
> 



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