Re: [netmod] guidelines for top-level nodes in RFC 8407

Martin Bjorklund <mbj@tail-f.com> Fri, 22 March 2019 12:34 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB50C12797D for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2019 05:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h93BMUpFnDCm for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2019 05:34:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C612787F for <netmod@ietf.org>; Fri, 22 Mar 2019 05:33:59 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id BEC771AE00A0; Fri, 22 Mar 2019 13:33:56 +0100 (CET)
Date: Fri, 22 Mar 2019 13:33:46 +0100 (CET)
Message-Id: <20190322.133346.1421769722882415136.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz>
References: <20190322.102400.1417118397166044745.mbj@tail-f.com> <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VW298etGxkU2S4KmjTp7oXGSWn8>
Subject: Re: [netmod] guidelines for top-level nodes in RFC 8407
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2019 12:34:02 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> On Fri, 2019-03-22 at 10:24 +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > RFC 8407, section 4.10 says:
> > 
> >    A mandatory database data definition is defined as a node that a
> >    client must provide for the database to be valid.  The server is not
> >    required to provide a value.
> > 
> >    Top-level database data definitions MUST NOT be mandatory.
> 
> The term "database" is somewhat unclear. Other documents use "datastore".
> 
> > 
> > The objective for this rule is to avoid a situation where a module cannot
> > be loaded w/o providing additional config, or a situation where you
> > can't boot a server w/o additional config.
> 
> In fact, this issue is related to the semantics of a particular datastore. For
> example, mandatory top-level nodes make a very good sense in
> <operational>. If I
> remember correctly, the NACM module has some.

Yes I agree.

> > Consider this snippet:
> > 
> >   container top {
> >     leaf foo {
> >       type int32;
> >       default 0;
> >     }
> >     leaf bar {
> >       when '../foo = 42';
> >       mandatory true;
> >       type int32;
> >     }
> >   }
> > 
> > 
> > Is /top/bar considered a mandatory top level node?
> 
> Of course it is, as well as the /top, per definition in RFC 7950:
> 
>    o  mandatory node: A mandatory node is one of:
> 
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
> 
>       *  A list or leaf-list node with a "min-elements" statement with a
>          value greater than zero.
> 
>       *  A container node without a "presence" statement and that has at
>          least one mandatory node as a child.

Ok.  So in this case I suppose I can do:

   container top {
     leaf foo {
       type int32;
       default 0;
       must '. != 42 or ../bar' {
         description
           "If foo is 42, then bar must be be set";
       }
     }
     leaf bar {
       when '../foo = 42';
       type int32;
     }
   }

It accomplishes the same thing, but it is less clear.


/martin


> > IMO it doesn't violate the spirit of the rule.  So the question is; is
> > this allowed?
> 
> My answer is that the mandatory property is a syntactic/schema constraint
> whereas "when" should be treated as a semantic rule because its expression has
> to be evaluated on a particular instance. As such, it should not interfere with
> schema constraints including mandatory.
> 
> If the when expression is more complicated (e.g. involves data from
> other modules), it may not be possible to determine just by looking
> at a single module whether an empty datastore is valid or not.
> 
> Even in your trivial example, what if an implementation adds a deviation module
> changing the default for /top/foo to 42?
> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > P.S. the real data model is a potential solution to a problem with
> > ietf-alarms from draft-ietf-ccamp-alarm-module:
> > 
> >       leaf notify-status-changes {
> >         type enumeration {
> >           enum all-state-changes {
> >             ...
> >           }
> >           enum raise-and-clear {
> >             ...
> >           }
> >           enum severity-level {
> >             ...
> >           }
> >         }
> >         default "all-state-changes";
> >         description
> >           ...
> >       }
> >       leaf notify-severity-level {
> >         when '../notify-status-changes = "severity-level"';
> >         type severity;
> >         mandatory true;
> >         ...
> >       }
> > 
> > 
> > pyang complains that this violates the cited rule.
> > 
> > D.S.
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>