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

[Lou Berger <[e-mail]>]

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 <[e-mail]>
>>>>
>>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod