> On 18 Aug 2015, at 13:09, Martin Bjorklund <[email protected]> wrote: > > Hi, > > Ladislav Lhotka <[email protected]> wrote: >> 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; >> ... >> } > > Working with what we currently have, I think this would look a bit > better if you instead did: > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > container tlsa { // name change > presence "TLSA data"; > leaf certificate-usage { > mandatory true; > …
Right, using the same name for the presence container won’t work if rdata for multiple rr types are defined in the same module. But the main problem still remains: container “tlsa” needn’t be present, which leads to an invalid resource record. The server would have no choice but reject such configuration. I don’t get how this helps old clients. > > I think the model itself is quite ok with this design, but the > instance data contains the type information encoded twice; once in the > the 'type' leaf and once in the container 'tlsa'. Since the 'type' > leaf is part of the key, it cannot easily be removed. > > > As for this issue in general, I think we all agreed that it would be > nice if we could allow such data to be mandatory, but noone came up > with any proposal for how to do this. The "safe" use case we > discussed was when the identity was defined in the same module as the > augment, but that is not the case in you module, where all identities > are defined in a central module. … as it is with interface types. I think it would be better to remove the restriction altogether. If a parameter is mandatory by its substance, it should be defined as mandatory in the data model. And if somebody wants to break old (or someone else’s) clients, there are other ways for achieving it. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
