Search RFCs

RFC Editor

Found 2 records.

Status:Verified (1)

RFC 8342, "Network Management Datastore Architecture (NMDA)", March 2018

Errata ID:5362
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rohit R Ranade
Date Reported: 2018-05-17
Verifier Name: Ignas Bagdonas
Date Verified: 2018-05-21

Section 2 says:

The convention adopted by the interfaces   data model [RFC8343] and the IP data model [RFC8344] was to use two   separate branches rooted at the root of the data tree: one branch for   configuration data objects and one branch for operational state data   objects.

It should say:

The convention adopted by the interfaces   data model [RFC7223] and the IP data model [RFC7277] was to use two   separate branches rooted at the root of the data tree: one branch for   configuration data objects and one branch for operational state data   objects.

Notes:

The duplication of definition and separation of operational state data and configuration data happened in RFC7223 and RFC7277. RFC8343 and RFC8344 have corrected this using NMDA architecture.

The Informative References section should point to RFCs 7223 and 7277.

Status:Reported (1)

RFC 8342, "Network Management Datastore Architecture (NMDA)", March 2018

Errata ID:5514
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rohit R Ranade
Date Reported: 2018-10-05

Section C.1 says:

   <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>

It should say:

   <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.

Report New Errata