> On 13 Aug 2015, at 22:15, Andy Bierman <[email protected]> wrote: > > > > On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka <[email protected]> wrote: > > > On 13 Aug 2015, at 21:31, Andy Bierman <[email protected]> wrote: > > > > Hi, > > > > IMO this is issue is closed. > > I see no reason to re-open it. > > YANG does not allow augments to add mandatory nodes. > > I strongly disagree with this attitude, this is a normal IETF procedure. > Things can be changed even during WGLC. > > Virtual interims aren’t good for discussing non-trivial technical issues. > > > I am not hearing any new arguments for changing this rule for augments.
The argument isn’t new, I just hope to find more support for it. And the argument is: With the way how augments are used in existing modules, it is not reasonable to used restricted YANG inside them. And the p-container solves nothing. Lada > It's up to the co-chairs whether they want to re-open this issue. > > > Lada > > > Andy > > > > > > > > Andy > > > > > > On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka <[email protected]> wrote: > > > > > 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 > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > 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
