> On 13 Aug 2015, at 19:44, Robert Wilton <[email protected]> wrote: > > Hi Andy, > > On 13/08/2015 17:08, Andy Bierman wrote: >> >> >> 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. >> > Yes, I agree in principle, but I'm not sure whether the default set of YANG > modules has yet reaches the maturity that enforcing this rule truly makes > sense. It feels that many of the YANG modules (even those have been > standardized) are still some what at the experimental stage. This is > effectively the same point that you make below.
Right. Another thing is that augment was IMO originally intended to allow for adding optional or vendor-specific parameters to a base data model. However, as it turned out, it is in fact used as an essential tool for developing *base* data models in a modular fashion. I have also argued several times that a client cherry-picking modules advertised by the server is fundamentally unsafe - it may work but may also break things. > >> >> 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. > > In Lada's case there is no base version, all of his modules are being newly > defined. So, in this scenario, ideally that RR-type specific modules should > be allowed to augment with mandatory nodes since this must effectively be > backwards compatible. > > >> >> (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. > > Yes, this may make sense for other scenarios, but I don't see that it helps > with either of the problems that Lada or I have described. It doesn’t, it is just hand-waving. > >> >> >> >> 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. > Yes, but in Lada's example, the P-container doesn't really help anyone, since > the server has to now handle the case that the RR-type has been specified but > the corresponding P-container isn't present. If it is possible for the > server to handle this scenario then the mandatory child fields don't have > to be mandatory either because some sensible default must exist. This > implies that all servers would likely reject the configuration as being > invalid if the P-container isn't also present. > > As I see it, having a P-container here only protects a old client in the > scenario that it was mis-configured in the first place, i.e. using a > particular RR-type without the corresponding mandatory nodes being specified > ... which a sane server should have rejected the config for previously. > > I don't really want to flog a dead horse, but I do think that the mandatory > rule could be relaxed to state that it cannot be used to introduce non > backwards compatible nodes. The text could specify the specific conditions > where it is allowed to be used in a augmentation. We tried to identify such situations but it is not that easy. I think the restriction should be removed and explain backward compatibility issues in 6087bis. Module authors then have to decide whether a certain node needs to be defined as mandatory. If we clutter new modules with unnecessary p-containers, there will be no way back. > > Or, alternatively, perhaps allow for a must statement to simulate a mandatory > keyword in these cases - although I don't think that this solution is > particularly clear or clean. Exactly, it is an ugly hack to the same effect. Lada > > Thanks, > Rob > > >> >> >> 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 list >>> >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
