Re: [netmod] guidelines for top-level nodes in RFC 8407
On 2019-03-22 14:45, Ladislav Lhotka wrote: Martin Bjorklund writes: IMO it doesn't violate the spirit of the rule. So the question is; is this allowed? 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] guidelines for top-level nodes in RFC 8407
Martin Bjorklund writes:
> 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;
> }
>}
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
>
>
> /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
>>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] guidelines for top-level nodes in RFC 8407
Ladislav Lhotka 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
> . 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] guidelines for top-level nodes in RFC 8407
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 . 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
> 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
[netmod] guidelines for top-level nodes in RFC 8407
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.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
