Robert Wilton <[email protected]> wrote: > Hi, > > On 15/03/2017 07:28, Martin Bjorklund wrote: > > Phil Shafer <[email protected]> wrote: > >> Martin Bjorklund writes: > >>> Phil Shafer <[email protected]> wrote: > >>>> Martin Bjorklund writes: > >>>>>> What are your thoughts on this? Surely, an augment should not have to > >>>>>> contain if-feature statements of all parents of the augmented node. > >>>>> The spec says: > >>>>> > >>>>> When a server implements a module containing an "augment" statement, > >>>>> that implies that the server's implementation of the augmented module > >>>>> contains the additional nodes. > >>>>> > >>>>> Compare with a simple augment of a node w/o an if-feature. In this > >>>>> case, if the server implements the augmenting module, it MUST also > >>>>> implement the augmented module. > >>>> It implements the module, but it doesn't implement the nodes > >>>> since it doesn't express the feature. IMHO this is a tool > >>>> bug and/or an errata,since otherwise one has to carry features > >>>> forward, repeating the if-feature using the original modules > >>>> prefix:feature-name on every augment of feature-based nodes. > >>> Well, I agree that it would have been better to state that if a server > >>> doesn't implement the augment target, then it doesn't implement the > >>> augment either. But the text is pretty clear; this is not how it > >>> works. This is not appropriate to "fix" in an errata. > >> I'm missing the part of the text that's clear. The above quoted > >> section certainly doesn't say this. That text is saying "if you > >> implement a module that augments a set of nodes, then the server's > >> schema for that original set of nodes now includes the new set of > >> nodes". It's referring to schema nodes. > > It explicitly says that server's *implementation* of the augmented > > module contains the additional nodes. > Section "5.6.5. Implementing a Module", doesn't mention features at > all. > Section "5.6.2. Optional Features" doesn't mention implementation at > all. It only writes about portions of a model that are conditional, > supported, or valid. > Section "7.20.1. The "feature" Statement" also doesn't mention > implementation, it only writes about portions of the model being > conditional. > > So, I find the text that you are quoting as ambiguous in respect to > its applicability to features. > > > > > > > If you don't advertise a certain module, I don't think you can claim > > that your implementation contains that module. > I agree with this. > > > > > And similarly, if you don't advertise a feature, I don't think you can > > claim that your implementation implements nodes that are conditional > > on that feature. > I'm not convinced that the RFC text supports this view. The nodes > could be implemented but conditionally not supported.
The same can be said about a whole module; it could be implemented but temporarily disabled. > >> And if those schema nodes are conditional based on if-feature, then > >> those nodes are still in the schema, but are not supported by a > >> server unless the if-feature condition evaluates to true. > >> > >> I don't see a conflict, > >> it's just a case that we didn't think about > >> or write about. > > This I agree with. > > > >> It's a case that's not clearly handled in the spec, > >> for which reasonable implementations can disagree. That's a bug > >> in the spec and it that can be clarified via errata. > I also think that this needs to be clarified one way or the other. > > I would also prefer it to be allowed to augment a node that is > conditional on an if-feature without having to restate the if-feature > condition, in exactly the same way that it is allowed to augment a > node with a when statement without having to restate the when > statement in the augmentation. Just to be clear - I prefer this as well. I also think the same thing applies to normal augment w/o features; if you implement module A that has an augment of B, and you don't implement B, you should still be able to state that you implement A. But I don't think it can be done in an errata. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
