Subject: [netmod] [Technical Errata Reported] RFC8342 (5514)

From: RFC Errata System <[email-masked]>
Date: Fri, 5 Oct 2018 02:48:08 -0700 (PDT)

The following errata report has been submitted for RFC8342,
"Network Management Datastore Architecture (NMDA)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5514

--------------------------------------
Type: Technical
Reported by: Rohit R Ranade <[email-masked]>

Section: C.1

Original Text
-------------
   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

Corrected Text
--------------
   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
       or:origin="or:intended">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

Notes
-----
There was no "origin" attribute to the "system" top-level container, though it is a configuration node.
As per the extension definition "The origin for any top-level configuration data nodes must be specified."

To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown".

This has already been discussed in the mail chain, but also mentioned here to help readers in future.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8342 (draft-ietf-netmod-revised-datastores-10)
--------------------------------------
Title               : Network Management Datastore Architecture (NMDA)
Publication Date    : March 2018
Author(s)           : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton
Category            : PROPOSED STANDARD
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Oct 2018 12:14:27 +0200

Hi,

the authors have been discussing whether the top-level requirement is
too strict but there has not been a clear conclusion yet I think. In
the example, all nodes to have a defined origin and hence the origin
at the root will have zero effect.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 5 Oct 2018 11:39:30 +0100

I agree that we need to reach a conclusion on the discussion before we 
can know what to do with this errata.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Fri, 5 Oct 2018 08:14:33 -0400

Juergen,

     The document says what it says, i.e., "The origin for any top-level 
configuration data nodes must be specified."  Changes to this would 
require a BIS or an RFC that updates this document.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Oct 2018 16:28:16 +0200

Well, if you think an errata does not work, we can file a one page
document with N pages of boilerplate around it.

/js

On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote:
> configuration data nodes must be specified."  Changes to this would require
> a BIS or an RFC that updates this document.
> 
> Lou
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Lou Berger <[email-masked]>
Date: Fri, 5 Oct 2018 12:12:56 -0400

My personal opinion (with any hat on) is that it isn't appropriate to 
make a technical change that impacts implementation in an errata.  
Clarifications of original intent, corrections of inconsistencies and 
editorial corrections are perfectly appropriate.  I'm happy to learn 
that this intended use/scope of errata is wrong.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Oct 2018 09:53:32 -0700

On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <[email-masked]> wrote:

> My personal opinion (with any hat on) is that it isn't appropriate to make
> a technical change that impacts implementation in an errata.
> editorial corrections are perfectly appropriate.  I'm happy to learn that
> this intended use/scope of errata is wrong.
>
>
Strongly agree.
Errata cannot be used to change technical decisions.
It can only be used to correct text that is incorrect.

> Lou

Andy

>>> require
>>>>> As per the extension definition "The origin for any top-level
>>>>> configuration data nodes must be specified."
>>>>>
>>>>> To choose an extension for top-level container in such cases, I would
>>>>> prefer one of the origin of its children and used "intended". , instead of
>>>>> "unknown".
>>>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 7 Oct 2018 08:47:21 +0200

> It can only be used to correct text that is incorrect.

So far so good but we all know that at the end its a judgement call.

The intention of the text was to ensure that there is always a defined
origin value. One way to achieve that is to have an origin defined at
the root. But there are obviously other possibilities to achieve the
intended goal, as the example demonstrates. While we can for sure add
an origin at the root in the example, it serves no purpose. In other
words, the example demonstrates that we failed to reinforce this by
saying "every config data node needs to have a defined origin value
and one way to achieve that is to define origin's are the roots of the
subtrees" but instead we created the rule "all roots of the subtrees
must have a defined origin value", which in certain approaches to
maintain origin metadata and generate origin attributes is more a CLR.

But sure, if people want to close this discussion on formal grounds,
so be it. We will just have introduced a CLR.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Oct 2018 09:49:57 -0700

On Sat, Oct 6, 2018 at 11:47 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> make
> that
5.3.4 <https://tools.ietf.org/html/rfc8342#section-5.3.4>.  Origin
Metadata Annotation

   As configuration flows into <operational>, it is conceptually marked
   with a metadata annotation [RFC7952
<https://tools.ietf.org/html/rfc7952>] that indicates its origin.*
The
   origin applies to all configuration nodes except non-presence
   containers. *

    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.*";
     }

Can somebody explain the rationale for the highlighted text from 5.3.4?
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.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 7 Oct 2018 19:09:07 +0200

> 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.

> 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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Oct 2018 11:01:23 +0100

So there seem to be two available solutions here:

(i) The server MUST provide an origin value for the top level datanode, 
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.

(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?

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Oct 2018 08:57:33 -0400

Hi Rob/All,

Keep in mind that the document says what it says and that to change text 
really requires a new version.

> (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.

Having an errata saying this "must" really is a "MUST" is quite 
reasonable from my perspective.

> 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.

> 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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Oct 2018 14:51:26 +0100

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.
>
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.

> reasonable from my perspective.
I'm not convinced that this has to change.

> 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.  Then the errata that is required is the one that 
Rohit submitted.

Thanks,
Rob

> 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
>>
>>
> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Oct 2018 16:13:57 +0200

On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote:
> 
> 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.
> 
> Having an errata saying this "must" really is a "MUST" is quite reasonable
> from my perspective.

As explained, technically speaking, the "must" is pointless in certain
situations. Making it a MUST does not make things any better.

/js

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Oct 2018 12:03:18 -0400

> situations. Making it a MUST does not make things any better.
Okay - then all that needs to be done is clarify the errata and decide 
if you want to author a new draft on the behavior/text you'd like to change.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Oct 2018 12:02:14 -0400

Hi Rob,

> is in a YANG module, and we didn't want to tie the YANG module to RFC
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.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Oct 2018 10:16:18 -0700

On Mon, Oct 8, 2018 at 9:03 AM, Lou Berger <[email-masked]> wrote:

> Okay - then all that needs to be done is clarify the errata and decide if
> you want to author a new draft on the behavior/text you'd like to change.
>
>

After reading the RFC details, it seems that the example is intentional
based on
the text about NP-containers.

I think an errata could be used because the sentence about a top-level
origin must be defined
could be interpreted to define "top-level" as the topmost level for which
the origin property
is applicable.  It appears the intent was to exclude NP-containers from
this requirement.

Thanks,

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Oct 2018 17:54:35 +0000

> After reading the RFC details, it seems that the example is intentional based on
> I think an errata could be used because the sentence about a top-level origin must be defined
> could be interpreted to define "top-level" as the topmost level for which the origin property
> is applicable.  It appears the intent was to exclude NP-containers from this requirement.

Yes, it was intentional to exclude np-containers, I view something like:

OLD:
    The origin for any top-level configuration data nodes must be specified.
NEW:
    The origin for any top-level configuration data nodes, except
    non-presence containers, must be specified.

to be almost editorial in nature.  That said, I also do not think that it’s needed, in that I think
one could argue that an np-container isn’t actually “configuration” at all, it’s just implicitly
there providing a skeleton to hang stuff off of.

RFC 8342 says:

   o  configuration: Data that is required to get a device from its
      initial default state into a desired operational state.

An np-container doesn’t actually do this.   RFC 7950 says:

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

Bingo.  RFC 7950 also says:

   o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list,  anydata, and anyxml.

Note that it says “container” without clarification.  Clearly an np-container isn’t “data”
so, if there is to be an errata, perhaps it should be against  RFC 7950, for instance:

NEW
   o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of presence container, leaf, leaf-list, list,  anydata, and anyxml.

Kent // contributor