Hi, IMO this is issue is closed. I see no reason to re-open it. YANG does not allow augments to add mandatory nodes.
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 > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
