Hi Lada,
Thanks for the explanation.
Initially I was concerned that there would be a higher server
implementation cost of using a must statement over a when statement, but
given that the container/leaves are under a choice statement then it
seems that the must statement can presumably be implemented as
efficiently as a when statement in this scenario.
Thanks,
Rob
On 07/09/2015 11:52, Ladislav Lhotka wrote:
Hi Rob,
I generally prefer must to when, except in augments, because it is IMO a much
cleaner concept that also has analogies in standard XML schema languages. When
manipulates the schema based on arbitrary values in an instance document (that
is supposed to be validated with the schema), and because of that it requires
extra rules and sometimes even temporary manipulation with the instance
document to work correctly, see
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.5
In contrast, must expressions are evaluated in the context of an instance
document and there are no concerns about circular references, order of
evaluation etc.
Lada
On 07 Sep 2015, at 12:05, Robert Wilton <[email protected]> wrote:
Hi Lada,
I've just take a quick look at your DNS model referenced below. For your
containers under the choice rdata-content you have used must statements to
enforce the constraint.
E.g.
...
choice rdata-content {
mandatory "true";
...
container A {
must "../../type = 'ianadns:A'";
I was wondering what the reason was that you choose to use must statements
rather than equivalent when statements?
The reason that I'm asking is that I had used when statements for a similar
construct that I had used for VLANs encapsulation, and I guess I would normally
choose a when statement out of preference over a must statement, hence the
desire to understand the rationale for the alternative.
Thanks,
Rob
On 26/08/2015 09:28, Ladislav Lhotka wrote:
Hi,
I changed the DNS zone data model to use this pattern - it looks
good and works great:
- module:
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang
- tree:
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree
Lada
Martin Bjorklund
<[email protected]>
writes:
Hi,
I think this could work (thanks Robert; maybe this is what you
meant!):
container zones {
list zone {
...
list rrset {
...
leaf type {
type identityref { ... }
}
list rdata {
key id;
...
choice type-specific-params {
mandatory true;
// to be augmented with type-specific nodes
}
}
}
}
}
And then in another module:
augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
+ "/type-specific-parameters" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
+ "'TLSA')";
leaf certificate-usage {
mandatory true;
...
}
}
The empty mandatory choice formally tells the client that additional
cases are expected.
(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)
This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.
/martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
