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


On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote:
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:
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


On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:
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

On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:
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 <rohitrran...@huawei.com>

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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to