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

[Ladislav Lhotka <[e-mail]>]

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.

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

> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67