Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

Andy Bierman <andy@yumaworks.com> Sun, 07 October 2018 16:50 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0712DD85 for <netmod@ietfa.amsl.com>; Sun, 7 Oct 2018 09:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rj-Q8GKWCvq for <netmod@ietfa.amsl.com>; Sun, 7 Oct 2018 09:50:01 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8C5127333 for <netmod@ietf.org>; Sun, 7 Oct 2018 09:50:00 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id u21-v6so15701476lja.8 for <netmod@ietf.org>; Sun, 07 Oct 2018 09:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=h6p3h1abnE25ADD1navDvpqIS1XZ0e2YUSl7Qo3wlOc=; b=qGaeLovnJ4GBh9RwSqyVpORenpt00iVggcT27PNGEF04d7FuIAlhJdXG4g5EephP+O p1FNDuU4LbuJ0ytNw/bXyDbOC7SFCke2bk30awvCV1cT2mTgJzo+txfOmpO56xcxZ5GM Nyt0jZbVp61hpRsgDvfMUrgRQOTjlmBT74vE2uXzFrnruFK1G4jycOTDocnL9gRnYTWY VRSNAQMI4hKZpC3NcdDeX7RBrzATyP6lmemoI9kqFr8rwuaWTI1LfCR4cFbO5FGI3a1s Yb4tR3Q1JJymPiJtlpla8nvs0aPLgqLph3Q5AnxuFlx2oF80KfveRzwCLt8XvCpp3Dzt mhHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=h6p3h1abnE25ADD1navDvpqIS1XZ0e2YUSl7Qo3wlOc=; b=HXMIH0Egrn4QhFrvm+4ML5dvi1BEqogfHFEUE54Vhfj7K7SZNsRj1mOKc+aTznjGPh U/TU2ycQDmMvbWLxO1z1kgbzy3B8HN3pjX8m6QNDozEWCs6Im8xPfkEhWsk6/w7+Zrvi koxIdIRf9gTVpBGQKmWHRDfhf/u/UMvaRpiY/V2VwPJ5akOn1N6LPFwtbc+Ms4K8SZ6/ sxmfNpCp6S1gqtxCR4hZCGeifeQL4sfLIpLAWLFOVnPS2wDoikoKhTbe30mYGQEZFwU+ 2RpM8CBQjiNgkLXWoI6Fr3IEqBaf5ssk+Mmu6upcwg/4WMoF0Pf7ZG6KwZoQsQHaiQ4i bduA==
X-Gm-Message-State: ABuFfogkOVfhhdgK6qfxIFBACAxpM77yFN9v7Gnh8UdW14VGZZdx9prc LkoBhjG63b9MoXUqRrOTm/MlMQUsr/izlOr9OooeTg==
X-Google-Smtp-Source: ACcGV627BENu2JcVeH5KnI1pQKRwJ6qfXxgNfkmSOVA7PcNWydVASVZS0eUcVdcQhdSZtTntojSzrYb76Ph/uuwznbU=
X-Received: by 2002:a2e:9047:: with SMTP id n7-v6mr10856813ljg.10.1538930998772; Sun, 07 Oct 2018 09:49:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Sun, 7 Oct 2018 09:49:57 -0700 (PDT)
In-Reply-To: <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de>
References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <CABCOCHS4GOVYC0FRJEtCpzQ+VB=u6g0LDEmL1ULqysBA=yhzNg@mail.gmail.com> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Sun, 7 Oct 2018 09:49:57 -0700
Message-ID: <CABCOCHTZMabKuu-T4mGAwiaeWDpSWZopFB42W8A+u7g6ZvRg7w@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Lou Berger <lberger@labn.net>, Ignas Bagdonas <ibagdona@gmail.com>, NetMod WG <netmod@ietf.org>, Warren Kumari <warren@kumari.net>, RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: multipart/alternative; boundary="0000000000008419120577a64b8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FfhWly0ujsoLhpFVsUXwpSbkcoU>
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Oct 2018 16:50:04 -0000

On Sat, Oct 6, 2018 at 11:47 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote:
> > On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <lberger@labn.net> 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.
>
>
5.3.4 <https://tools.ietf.org/html/rfc8342#section-5.3.4>.  Origin
Metadata Annotation

   As configuration flows into <operational>, it is conceptually marked
   with a metadata annotation [RFC7952
<https://tools.ietf.org/html/rfc7952>] that indicates its origin.*
The
   origin applies to all configuration nodes except non-presence
   containers. *



    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 must be specified.*";
     }



Can somebody explain the rationale for the highlighted text from 5.3.4?
There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the top-level
container
than in each of the child nodes.




/js
>

Andy


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