Juergen Schoenwaelder <[email protected]> writes: > On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote: > >> >> Let's look at a slightly more complex hypothetical case to tease >> >> out how folks *want* things to work. Assume the following have >> >> been defined: >> >> >> >> - base module M >> >> - augmentation Q >> >> - augmentation R >> >> >> >> On a server claiming to supporting the modules containing M, Q, >> >> and R, respectively, which of the following might one encounter >> >> concurrently? >> >> >> >> - plain M >> >> - M+Q >> >> - M+R >> >> - M+Q+R >> > >> >It depends on what you mean by "encounter" but in terms of datastore >> >validity the only possible answer IMO is M+Q+R. >> >> By "encounter" I mean if a client asks the server for all of its Ms, >> and the server also supports Q and R, are all of the Ms *guaranteed* >> to be M+Q+R, or is it possible that some of the Ms might lack Q or >> lack R of lack both? If what netmod gives us is strictly M+Q+R, >> how would one model a system inhabited by a mixture of the four >> kinds of Ms? > > Retrieval is easy since a client is going to ignore data it does not > understand and the server is expected to report what makes sense from > the server's perspective. The question is relevant for writing: Is a > client programmed based on M going to work even if a server supports > M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC > 6020 wanted to achieve this by forbidding mandatory nodes in > augmentations. > > Y26-02 says that a presence container may be used to avoid breaking an > old client. Frankly, it seems not totally clear to me what the > sentence in section 7.15 of RFC 6020 really means: > > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > Does this rule only apply to nodes directly added under the target > node or does it apply to the whole hierarchy added? In the later case, > this would still cause a problem with the presence container work > around.
Yes, it's unclear but IMO it is about mandatory nodes directly below the target node - a similar rule for module updates is in sec. 11. > > The recent suggestion to replace MUST NOT with SHOULD NOT in this > sentence may be seen as a softer variant of Y26-01. However, I think > we would, in addition, have to describe when it is OK to have > mandatory nodes in augmentations and when not. Simply saying SHOULD > NOT instead of MUST NOT will not help people to understand the issues > around this. The definition in RFC 2119 is: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. I think it should suffice if data model designers are aware of the fact that certain augments may break old clients, and give some reasoning if they use them anyway. > > When this issue was discussed in the past, it turned out to be > difficult to find someone to write the necessary text explaining when > augmenting mandatory nodes is safe and when not. Are we doing better > now? I don't think we can enumerate all cases where it is allowed because YANG doesn't follow any rigid structure and there may be a variety of different designs. I'd prefer to explain the ramifications of defining mandatory nodes in augments (and also in module updates) and leave it to the model designer to judge whether there are valid reasons to override the "SHOULD NOT" - and YANG doctors should verify it in IETF models. I think the point is that parameters are mandatory not because a spiteful module author defines them so but rather because the system cannot work without them. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > 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
