On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <lber...@labn.net> 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. > 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. > > Strongly agree. Errata cannot be used to change technical decisions. It can only be used to correct text that is incorrect.
> Lou > Andy > > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
