Hi,
although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.
I am currently working on a data model for DNS zone data and the schema
is like this:
module: dns-zones
+--rw zones
+--rw zone* [name]
+--rw name inet:domain-name
+--rw description? string
+--rw class? ianadns:class
+--rw rrset* [owner type]
+--rw owner inet:domain-name
+--rw type identityref
+--rw description? string
+--rw ttl positive-int32
+--rw rdata* [id]
+--rw id string
+--rw description? string
The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:
augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
+ "'TLSA')";
container rdata { // <=================
presence "TLSA data";
leaf certificate-usage {
mandatory true;
...
}
...
}
}
Note the superfluous presence container "rdata". It that just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.
As this situation is likely to be very common, I wonder: do we really
want to do that?
[1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
Thanks, Lada
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
