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 On Mon, May 04, 2020 at 02:04:41PM +0200, Martin Björklund wrote: > Kent Watsen <[email protected]> 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: > > The origin for any top-level configuration data nodes, except > non-presence containers, must be specified. > > 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: > > 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) > > > <[email protected]> wrote: > > > > > > Are there any other comments on the proposed resolution of this > > > erratum? > > > > > > Regards, > > > Rob > > > > > > > > >> -----Original Message----- > > >> From: netmod <[email protected]> On Behalf Of Martin Björklund > > >> Sent: 28 April 2020 16:47 > > >> To: [email protected] > > >> Cc: [email protected] > > >> Subject: Re: [netmod] Erratum 5514 on NMDA [RFC 8342] > > >> > > >> "Rob Wilton \(rwilton\)" <[email protected]> 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 protected] > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
