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

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Mar 2019 10:24:00 +0100 (CET)

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

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?

IMO it doesn't violate the spirit of the rule.  So the question is; is
this allowed?

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Mar 2019 11:12:16 +0100

>    Top-level database data definitions MUST NOT be mandatory.

The term "database" is somewhat unclear. Other documents use "datastore".

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

> 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

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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Mar 2019 13:33:46 +0100 (CET)

> remember correctly, the NACM module has some.

Yes I agree.

>          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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Mar 2019 14:45:42 +0100

Martin Bjorklund <[email-masked]> writes:

...

>            "If foo is 42, then bar must be be set";

Or just

    container top {
      must 'foo != 42 and not(bar) or foo = 42 and bar';
      ...
    }

It also depends on whether you want to let automatically nuke bar if foo
is changed from 42 to something else. I prefer to keep it and report a
semantic error during validation.

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

Well, the interaction between mandatory and when has already caused a
lot of confusion. Some people even thought it was clear but their
interpretation was wrong. :-)

Lada

---

From: Per Hedeland <[email-masked]>
Date: Fri, 22 Mar 2019 18:09:20 +0100

>>>> IMO it doesn't violate the spirit of the rule.  So the question is; is

It seems to me that it would make sense to apply the same logic as
for "remote" augments to this rule - from RFC 7950:

    If the augmentation adds mandatory nodes (see Section 3) that
    represent configuration to a target node in another module, the
    augmentation MUST be made conditional with a "when" statement.  Care
    must be taken when defining the "when" expression [...]

I.e. the answer to your (original) question would in that case be
"yes" (at least for YANG 1.1 modules...).

--Per Hedeland