On Thu, Aug 13, 2015 at 10:44 AM, 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. > > > 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. > That's really too bad because YANG has no way of saying "this group of 4 YANG modules are intended to be used together". You can pretend it does, but the RFC says differently. It is difficult if not impossible to write guidelines that insure that an individual YANG module is updated with mandatory nodes in a way that does not make assumptions about how the previous module revision was used. Since there is no way in YANG to say "the server MUST provide the base module plus augments module X and Y", there is no way to do what Lada wants. With the 'unstable' or 'experimental' attribute, it would be OK to update the base module directly and add mandatory nodes. There is no reason augment has to be used. That is a subjective design choice. Andy > > > (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. > > > > > 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. > > 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. > > 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]> >> [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
