Ladislav Lhotka <[email protected]> wrote: > Robert Wilton <[email protected]> writes: > > > Hi Andy, > > > > Picking up a slightly old thread after PTO ... > > > > On 24/08/2015 22:50, Andy Bierman wrote: > >> > >> > >> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi Randy, > >> > >> On 24/08/2015 20:20, Randy Presuhn wrote: > >> > >> Hi - > >> > >> From: Ladislav Lhotka <[email protected] <mailto:[email protected]>> > >> Sent: Aug 24, 2015 11:44 AM > >> To: Andy Bierman <[email protected] > >> <mailto:[email protected]>> > >> Cc: "[email protected] <mailto:[email protected]>" > >> <[email protected] <mailto:[email protected]>> > >> Subject: Re: [netmod] Y26 again, sorry > >> > >> ... > >> > >> YANG does not provide any mechanism to REQUIRE modules > >> A and B > >> to both be implemented on a server. You may think it > >> should, but > >> currently the YANG conformance is for an individual > >> module. > >> > >> There are sections on conformance and conformance > >> announcement, > >> and they say nothing like this. In my view, the data model > >> comprises > >> *all* modules advertised by the server. I think your > >> interpretation > >> of conformance might be an extrapolation from SNMP/SMI > >> times, but, > >> for better or worse, it really has no support in the YANG > >> spec. > >> > >> It sounds as though you might be talking past each other. > >> I believe part of Andy's point is that clients will need to deal > >> with servers that do not implement (and thus do not advertise) > >> the augmenting module. But there's (I think) a more interesting > >> issue beneath this. > >> > >> Let's start with module M. Let's say M is for "modem" (to pick > >> an obsolete but widely understood resource). > >> Two different augmenting modules, F (for FSK - frequency > >> shift keying) and Q (for QAM - quadrature amplitude modulation) > >> are developed. Let us say that F and Q are mutually incompatible. > >> > >> A system with multiple Ms could well have both M+F and M+Q modems, > >> but (if we claim F & Q are incompatible) could not have M+F+Q. > >> If naked M is to be prohibited in systems (also) supporting F or Q > >> or both, we don't currently have a mechanism to do so. > >> > >> Could this be achieved by augmenting from a choice statement? > >> > >> M defines the choice statement but with no case statements. > >> > >> F and Q both implement separate case statements that augment the > >> choice statement in M. The case statements have containers which > >> hold the parameters related to F or Q. > >> > >> M without F or Q is meaningless. > >> M+F or M+Q works, but the choice statement means that you cannot > >> have M+F+Q. > >> > >> > >> nice solution > >> > >> This is perhaps the cleanest way to add mandatory nodes to a module. > >> The old client will not attempt to create the new case. > >> > >> As I said before, I am OK with changing MUST NOT to SHOULD NOT > >> add mandatory nodes, and then add MAY when X, Y, Z conditions are met. > >> > >> Two conditions so far: > >> > >> (1) augment + when <new flag set that old client will not set> > >> > >> (2) augment choice with a new case-stmt > >> > >> (1) is hard to define, but not (2) > > > > So, Lada is using (2) for DNS zones which works. Does the Y26 text need > > to be updated to explicitly allow this, or is this implicitly allowed > > anyway? > > It is allowed in YANG 1.0. > > > > > Unfortunately (2) won't work for my model augmentation issue, of wanting > > to enforce that a sub-interface has to have a parent interface-ref. > > As > > ietf-interfaces could also use the same mandatory choice pattern but > it seems too late now. This is an example why the strict module update rules > are counter-productive at this stage - instead if adopting the best current > practice we have to resort to kludges.
Can you explain what you would like to do with ietf-interfaces, and why that is not allowed according to the upgrade rules? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
