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

[Lou Berger <[e-mail]>]

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