Subject: Re: [netmod] Erratum 5514 on NMDA [RFC 8342]

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 4 May 2020 10:05:33 +0000

Are there any other comments on the proposed resolution of this erratum?

Regards,
Rob

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Björklund
> Sent: 28 April 2020 16:47
> To: rwilton=[email-masked]
> Cc: [email-masked]
> Subject: Re: [netmod] Erratum 5514 on NMDA [RFC 8342]
> 
> "Rob Wilton \(rwilton\)" <rwilton=[email-masked]> wrote:
> > Hi,
> >
> > There is one open erratum on NMDA from 2018 that I would like to
> > process.
> >
> > The erratum is here: https://www.rfc-editor.org/errata/eid5514
> >
> > There has been quite a lot of discussion on this erratum previously on
> > the NETMOD alias.  The last email in the thread was
> >
> https://mailarchive.ietf.org/arch/msg/netmod/LHJZmf5gtESX6Nobwst0OwXbGG4/
> >
> > >From my reading of the discussion, I don't think that there is clear
> > >WG consensus between the two competing concerns:
> > (1) The origin for any top-level configuration data nodes must be
> > specified (section 7, YANG annotation definition).
> > (2) The origin applies to all configuration nodes except non-presence
> > containers (section 5.3.4).
> >
> > Hence my proposal is to mark this as "Hold for Document Update" with
> > Kent's proposed resolution of changing the description in the YANG
> > model.
> >
> > OLD:
> >     The origin for any top-level configuration data nodes must be
> >     specified.
> >
> > NEW:
> >     The origin for any top-level configuration data nodes, except
> >     non-presence containers, must be specified.
> >
> > For reference, this will mean that the extension [NEW] is defined as:
> >
> >      md:annotation origin {
> >        type origin-ref;
> >        description
> >          "The 'origin' annotation can be present on any configuration
> >           data node in the operational state datastore.  It specifies
> >           from where the node originated.  If not specified for a given
> >           configuration data node, then the origin is the same as the
> >           origin of its parent node in the data tree.  The origin for
> >           any top-level configuration data nodes, except non-presence
> >           containers,  must be specified.";
> >      }
> >
> > Please can you let me know if you support or object to this
> > resolution.  I'll leave it a week to see if there is consensus before
> > processing the erratum.
> 
> I think this is ok.
> 
> 
> /martin
> 
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 May 2020 11:57:27 +0000

One small concern with the proposed NEW text is that it suggests that an NP-container is configuration, which I think is untrue.  Thusly, maybe the following tweak is better?

s/except/which excludes/

NEWER:
    The origin for any top-level configuration data nodes, which excludes
    non-presence containers, must be specified.

Still, my preferred fix is captured at the end of the linked mail archive (i.e., fix the source definition for “data node” in RFC 7950...and reject this errata). 

K.  // contributor 

> On May 4, 2020, at 6:15 AM, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
>

---

From: Martin Björklund <[email-masked]>
Date: Mon, 04 May 2020 14:04:41 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> One small concern with the proposed NEW text is that it suggests that
> an NP-container is configuration, which I think is untrue.

An NP-container can represent config data, so I think that part of
Rob's suggested text is ok.

Here's Rob's proposed text:

This doesn't say that a list within a top-level NP-container MUST have
"origin".

E.g.:

  container top {
    container second {
      list foo {
         ...
      }
    }
  }

Here /top/second/foo must have origin.

/martin

Thusly,
> maybe the following tweak is better?
> 
> s/except/which excludes/
> 
> NEWER:
> Still, my preferred fix is captured at the end of the linked mail
> archive (i..e., fix the source definition for “data node” in RFC
> 7950....and reject this errata).
> 
> K.  // contributor 
> 
> 
> > On May 4, 2020, at 6:15 AM, Rob Wilton (rwilton)
> > <rwilton=[email-masked]> wrote:
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 May 2020 14:20:28 +0200

If I put an origin on every config leaf and config p-container, why
would I need another origin somewhere up in the np-container hierachy?
We seem to make rules that to some extend miss the point we are really
trying to make, namely that every config leaf and config p-container
must have an origin (defined directly or inherited). If you choose to
inherit origin attributes, it follows that there must be a place to
inherit from (but that place does not have to be the root or a root).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Björklund <[email-masked]>
Date: Mon, 04 May 2020 14:39:23 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> must have an origin (defined directly or inherited).

Yes, I think this is what we should say.

/martin

> If you choose to

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 May 2020 13:39:33 +0000

> Martin writes:
>> Juergen writes: 

yes, this is the true intent and, stated this way, sidesteps the discussion as to if an NP-container is configuration. 

K. // contributor