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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
