On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <[email protected]> wrote:
> Hi Andy, Lada, > > On 13/08/2015 15:46, Andy Bierman wrote: > > 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. > > > I still don't see how a P-container really solves the problem since any > child mandatory nodes aren't really mandatory, or at least not in the way > that is actually intended. > > The concepts behind old-manager/new-agent protection mechanisms go back a couple decades (with SNMP). There is no way that a vendor can control all the applications using a particular module, and therefore mandate a flag-day upgrade on all clients, in order to upgrade some servers. YANG is very limited wrt/ adding new functionality, A designer must guess correctly on all mandatory nodes on the first version. If this a bug, then it should be fixed properly, instead of just pretending it's OK to break existing client apps. (YANG packages do not fix this problem BTW) Perhaps we need a new module-level "release" statement. release stable; release unstable; release experimental; Then all the very strict YANG change control rules can be relaxed on unstable and experimental modules. E.g. in Lada's example having the P-container implies that for a given RR > type it is acceptable to either not provide any extra RR specific config > (i.e. no P-container), or if RR specific config is provided then some > fields must always be provided, and others can be left out. I.e. the > P-container also needs to be mandatory for the configuration to be sane. > > A P-container insulates the old client because it would not know to create it, and the mandatory child nodes are only checked if the P-container exists. > To me, in this scenario, it feels that you might as well forego both the > P-container and mandatory marking. > > Thanks, > Rob > > > Andy > > 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 [email protected]https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
