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
