On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote: > On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <[email protected]> wrote: > > > My personal opinion (with any hat on) is that it isn't appropriate to make > > a technical change that impacts implementation in an errata. > > Clarifications of original intent, corrections of inconsistencies and > > editorial corrections are perfectly appropriate. I'm happy to learn that > > this intended use/scope of errata is wrong. > > > > > Strongly agree. > Errata cannot be used to change technical decisions. > It can only be used to correct text that is incorrect. >
So far so good but we all know that at the end its a judgement call. The intention of the text was to ensure that there is always a defined origin value. One way to achieve that is to have an origin defined at the root. But there are obviously other possibilities to achieve the intended goal, as the example demonstrates. While we can for sure add an origin at the root in the example, it serves no purpose. In other words, the example demonstrates that we failed to reinforce this by saying "every config data node needs to have a defined origin value and one way to achieve that is to define origin's are the roots of the subtrees" but instead we created the rule "all roots of the subtrees must have a defined origin value", which in certain approaches to maintain origin metadata and generate origin attributes is more a CLR. But sure, if people want to close this discussion on formal grounds, so be it. We will just have introduced a CLR. /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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
