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

Lou Berger <lberger@labn.net> Mon, 08 October 2018 13:02 UTC

Return-Path: <lberger@labn.net>
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 EE0AF130DDC for <netmod@ietfa.amsl.com>; Mon, 8 Oct 2018 06:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 y_wcEgNqvQwb for <netmod@ietfa.amsl.com>; Mon, 8 Oct 2018 06:02:01 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEC2130DD4 for <netmod@ietf.org>; Mon, 8 Oct 2018 06:02:01 -0700 (PDT)
Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 5203A43340 for <netmod@ietf.org>; Mon, 8 Oct 2018 06:57:36 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9V6OgnCDso6eD9V6OgCtxy; Mon, 08 Oct 2018 06:57:36 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fVzdKljpW6xgTbVO9VRqKm++bWkIM9tWm6Ib26qzK8I=; b=sCdOmFeDYJoWKQ5n/roiwazIuK /l0UaMGxs0N//80/7l2eEPpSeUegzGyMiP/v0T+cX4bUchJASnZhjvKL0eCzSYRnmuPYv/CmZkxhf Y3uzHHO/qN0LadVjyN9M2aFYa;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:60808 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1g9V6N-000DyS-Pm; Mon, 08 Oct 2018 06:57:35 -0600
To: Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Ignas Bagdonas <ibagdona@gmail.com>, NetMod WG <netmod@ietf.org>, Warren Kumari <warren@kumari.net>, RFC Errata System <rfc-editor@rfc-editor.org>
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> <CABCOCHTZMabKuu-T4mGAwiaeWDpSWZopFB42W8A+u7g6ZvRg7w@mail.gmail.com> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net>
Date: Mon, 8 Oct 2018 08:57:33 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1g9V6N-000DyS-Pm
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:60808
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Org: HG=bhcustomer;ORG=bluehost;
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CVvTPW679J9TAiW7OKQaNtmckBA>
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: Mon, 08 Oct 2018 13:02:04 -0000

Hi Rob/All,

Keep in mind that the document says what it says and that to change text 
really requires a new version.

On 10/8/2018 6:01 AM, Robert Wilton wrote:
> So there seem to be two available solutions here:
>
> (i) The server MUST provide an origin value for the top level datanode,
This is pretty close to what Andy previously quoted:

      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.";
      }


I think it's clear that the reviewers, notably myself as shepherd, 
missed that this is a lowercase "must" and should have asked for 
clarification during the review process.

Having an errata saying this "must" really is a "MUST" is quite 
reasonable from my perspective.

> but for NP containers it can use whatever origin value it likes - since
> the origin value imparts no direct meaning other than the default origin
> that descendants acquire if they haven't provided an explicit origin.

> In this case we would probably add a line of text to clarify this
> behavior of choosing a suitable origin value for top level NP containers.
I guess I'd need to see that specific language to understand if a new 
requirement or recommended behavior is being prescribed.  If it is, we 
need a new document to do so.

> (ii) The requirement is weakened as Juergen has described previously.
>
>
> Solution (i) minimizes the impact of the change to the RFC, but probably
> constrains server implementations slightly more than is strictly required.
>
> Solution (ii) gives a bit more flexibility to server implementations but
> in theory could break client implementation that rely on a top level
> origin always being provided.  Although, in reality I would expect a
> robust client implementation to either not care, or choose a suitable
> default origin (e.g. "unknown") if an explicit origin hasn't been provided.
>
> If solution (ii) is beyond the scope of what is allowed in an errata
> then it would seem that we should go with solution (i) instead.  But how
> do we get to a final decision?

Either we agree that s/must/MUST in an errata or start a new (update or 
bis) draft  to update the behavior.  It would also be fine to flag the 
issue in the errata without specific resolution, with the understanding 
that the issue would need to be resolved, in an update or bis, at some 
point in the future.

Lou

>
> Thanks,
> Rob
>
>
> On 07/10/2018 18:09, Juergen Schoenwaelder wrote:
>> On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote:
>>> Can somebody explain the rationale for the highlighted text from 5.3.4?
>> Note the difference between "applies to" and "carries". A non-presence
>> container has no relevance for configuration and hence an origin value
>> does not *apply* to a non-presence container. Still, a non-presence
>> container can *carry* an origin attribute.
>>
>>> 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.
>> There is no requirement to produce efficient encodings. This is up to
>> implementations, the cost of calculating a minimal encodings may be
>> high for systems that like to stream information. That said, even
>> toplevel origin attributes are not sufficient to guarantee an
>> efficient encoding. If most child nodes have an origin different than
>> what is stated in the toplevel container, you gain little.
>>
>> The requirement really is that an origin must be defined for all
>> configuration data nodes (except np-containers). The way how this
>> is done	is up to implementations. If implementations want to set
>> default	origins	at the toplevel, so be it.
>>
>> /js
>>
>