On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote: > 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. >
Still some text needs to be written explaining that breaking old clients by adding new mandatory nodes is a no go. I did not ask to enumerate all situations where it is allowed, I am looking for text that clearly says what people have to look out for if they add mandatory nodes. /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
