Hi Rob,
On 10/8/2018 9:51 AM, Robert Wilton wrote:
Hi Lou,
On 08/10/2018 13:57, Lou Berger wrote:
Hi Rob/All,
Keep in mind that the document says what it says and that to change
text really requires a new version.
On 10/8/2018 6:01 AM, Robert Wilton wrote:
So there seem to be two available solutions here:
(i) The server MUST provide an origin value for the top level datanode,
This is pretty close to what Andy previously quoted:
md:annotation origin {
type origin-ref;
description
"The 'origin' annotation can be present on any configuration
data node in the operational state datastore. It specifies
from where the node originated. If not specified for a given
configuration data node, then the origin is the same as the
origin of its parent node in the data tree. The origin for
any top-level configuration data nodes must be specified.";
}
I think it's clear that the reviewers, notably myself as shepherd,
missed that this is a lowercase "must" and should have asked for
clarification during the review process.
So I think that the logic for it being must rather than MUST is that it
is in a YANG module, and we didn't want to tie the YANG module to RFC
2119 language.
I'm not sure this is a great argument. Using conformance language in
such cases maybe exactly what is needed - but this is a different
discussion.
Having an errata saying this "must" really is a "MUST" is quite
reasonable from my perspective.
I'm not convinced that this has to change.
but for NP containers it can use whatever origin value it likes - since
the origin value imparts no direct meaning other than the default origin
that descendants acquire if they haven't provided an explicit origin.
In this case we would probably add a line of text to clarify this
behavior of choosing a suitable origin value for top level NP
containers.
I guess I'd need to see that specific language to understand if a new
requirement or recommended behavior is being prescribed. If it is, we
need a new document to do so.
The additional sentence (added at the paragraph above) could be
something along the lines of:
"For top level nodes that are non-presence containers, where the origin
has no direct meaning other than as a hierarchical default origin, the
server may choose any convenient origin value".
But equally, perhaps the existing test is sufficient without requiring
any changes at all.
I agree, it's not clear that this change is need as it is *already* what
is allowed.
Then the errata that is required is the one that
Rohit submitted.
so the errata should be corrected
Lou
Thanks,
Rob
(ii) The requirement is weakened as Juergen has described previously.
Solution (i) minimizes the impact of the change to the RFC, but probably
constrains server implementations slightly more than is strictly
required.
Solution (ii) gives a bit more flexibility to server implementations but
in theory could break client implementation that rely on a top level
origin always being provided. Although, in reality I would expect a
robust client implementation to either not care, or choose a suitable
default origin (e.g. "unknown") if an explicit origin hasn't been
provided.
If solution (ii) is beyond the scope of what is allowed in an errata
then it would seem that we should go with solution (i) instead. But how
do we get to a final decision?
Either we agree that s/must/MUST in an errata or start a new (update
or bis) draft to update the behavior. It would also be fine to flag
the issue in the errata without specific resolution, with the
understanding that the issue would need to be resolved, in an update
or bis, at some point in the future.
Lou
Thanks,
Rob
On 07/10/2018 18:09, Juergen Schoenwaelder wrote:
On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote:
Can somebody explain the rationale for the highlighted text from
5.3.4?
Note the difference between "applies to" and "carries". A non-presence
container has no relevance for configuration and hence an origin value
does not *apply* to a non-presence container. Still, a non-presence
container can *carry* an origin attribute.
There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the
top-level
container than in each of the child nodes.
There is no requirement to produce efficient encodings. This is up to
implementations, the cost of calculating a minimal encodings may be
high for systems that like to stream information. That said, even
toplevel origin attributes are not sufficient to guarantee an
efficient encoding. If most child nodes have an origin different than
what is stated in the toplevel container, you gain little.
The requirement really is that an origin must be defined for all
configuration data nodes (except np-containers). The way how this
is done is up to implementations. If implementations want to set
default origins at the toplevel, so be it.
/js
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
