Juergen Schoenwaelder <[email protected]> wrote: > 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).
Yes, I think this is what we should say. /martin > 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
