On 15/03/2017 10:20, Martin Bjorklund wrote:
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.
Does this just leave the behaviour as undefined then? I.e. it is up to
the implementation to decide whether they error the augmentation.
Rob
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
