Hi,
I'm not sure how many times we need to go over this issue... YANG conformance is based on the YANG module. YANG has no concept of conformance beyond this simplistic approach, You cannot assume (ever, under any conditions) that module foo AND bar will both be present on a server. Therefore if a client is written to work with "foo", it has no responsibility at all to know that "bar" adds a mandatory node to a "foo" subtree. The extra P-container is needed to make sure clients written to work with module "foo" do not break when new nodes are added via augments. We already decided not to do anything useful wrt/ Y45, so we are stuck with the YANG module as the unit of conformance. Andy On Thu, Aug 13, 2015 at 7:07 AM, 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; > ... > } > ... > } > } > > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
