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