> On 09 Sep 2015, at 21:10, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Wed, Sep 9, 2015 at 11:56 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > On 09 Sep 2015, at 17:25, Robert Wilton <rwil...@cisco.com> wrote: > > > > Hi Andy, > > > > On 07/09/2015 18:41, Andy Bierman wrote: > >> > >> Your example shows the YANG conformance problems fairly well. > >> Clearly the IETF (and others) want to use advanced design patterns > >> in which conformance to the base module (M) is insufficient to describe > >> the actual API requirements. > >> > >> YANG uses revision dates to identify versions. > >> There is no such thing as a major vs. minor revision. > >> I agree with Lada that it is possible to have major revision update > >> where the old clients should not be used anymore. > >> > >> I already suggested relaxing the MUST NOT to a SHOULD NOT, > >> wrt/ adding mandatory nodes. > > I support that - it seems to strike the right pragmatic balance to me. > > I support that, too. > > > > I don't think it really addresses the design pattern very well. > > You want to claim that M and Q are both being developed at the same time, > so it's OK that Q adds mandatory nodes to M. YANG has no such rule. > YANG says a server can implement M and never implement Q. > YANG says a server may implement M and then add Q in a future release. > These conformance mechanisms do not align with your expectations > of how YANG can/should be used.
There seems to be an impedance mismatch between us at this point. You are saying that a server can implement ietf-interfaces only. That’s correct but the server implementor can easily see that it doesn’t make much sense because nothing very useful can be done with it. So what? It is similar to the situation before OS software packages were introduced: One had to know (or read in the documentation, or later in the output of a configure script) that package X needs either Y or Z to work correctly, and install one of them beforehand. It was more laborious but one could make things work even then. It would be great to have a formalism that allows for stating that module M requires Q, but I think multi-module data models can be designed and effectively used without it. Issue Y26 is about something else, namely allowing an augmenting module Q to introduce mandatory nodes, and if the server advertises both M and Q, the client should get the message that the nodes from Q are mandatory. The formulation “A module SHOULD NOT augment another with mandatory nodes” is indeed an acceptable compromise - nodes that positively need to be mandatory can be tagged as “mandatory true”. Lada > > > Lada > > > Andy > > > > > Thanks, > > Rob > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
