Re: [netmod] [Technical Errata Reported] RFC8342 (5514)
Lou Berger <lberger@labn.net> Mon, 08 October 2018 16:34 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 454BC130E28 for <netmod@ietfa.amsl.com>; Mon, 8 Oct 2018 09:34:07 -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 Gf5IverL0m5c for <netmod@ietfa.amsl.com>; Mon, 8 Oct 2018 09:34:05 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 EC9B0130E8F for <netmod@ietf.org>; Mon, 8 Oct 2018 09:34:04 -0700 (PDT)
Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id F0CFF176E75 for <netmod@ietf.org>; Mon, 8 Oct 2018 10:04:48 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9XzOgqIdRo6eD9Y0NgFysk; Mon, 08 Oct 2018 10:04:44 -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=7RXJ/M9GZ11GoB/UR+ganZTOp0XHKGLfmChFumcT5qg=; b=1uo+Uop2AQK4Imz1vAPspxuvlY RGoZPDIbEZr7speJPPloo9dRrstCLnqy1PpvmLldyBQ+hWtPw7gbz9JtJug/L7RkH2zTyGt+kM2i7 vOju5YsNVnihNbNQIOSPirpPt;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:51736 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 1g9Xz6-00148R-2O; Mon, 08 Oct 2018 10:02:16 -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> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> <cd75f603-90bb-72dd-434b-6022856495ba@cisco.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <3234b791-81c3-2bfc-43b8-c5a56bfd33f3@labn.net>
Date: Mon, 08 Oct 2018 12:02:14 -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: <cd75f603-90bb-72dd-434b-6022856495ba@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: 1g9Xz6-00148R-2O
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]:51736
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pjy5zvBjgc7lkTGjrxTcP7SPVMI>
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 16:34:14 -0000
Hi Rob, On 10/8/2018 9:51 AM, Robert Wilton wrote: > Hi Lou, > > > On 08/10/2018 13:57, Lou Berger wrote: >> 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. > So I think that the logic for it being must rather than MUST is that it > is in a YANG module, and we didn't want to tie the YANG module to RFC > 2119 language. I'm not sure this is a great argument. Using conformance language in such cases maybe exactly what is needed - but this is a different discussion. > >> Having an errata saying this "must" really is a "MUST" is quite >> reasonable from my perspective. > I'm not convinced that this has to change. > >>> 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. > The additional sentence (added at the paragraph above) could be > something along the lines of: > > "For top level nodes that are non-presence containers, where the origin > has no direct meaning other than as a hierarchical default origin, the > server may choose any convenient origin value". > > But equally, perhaps the existing test is sufficient without requiring > any changes at all. I agree, it's not clear that this change is need as it is *already* what is allowed. > Then the errata that is required is the one that > Rohit submitted. so the errata should be corrected Lou > > Thanks, > Rob > > >>> (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 >>>> >> . >> >
- [netmod] [Technical Errata Reported] RFC8342 (551… RFC Errata System
- Re: [netmod] [Technical Errata Reported] RFC8342 … Juergen Schoenwaelder
- Re: [netmod] [Technical Errata Reported] RFC8342 … Robert Wilton
- Re: [netmod] [Technical Errata Reported] RFC8342 … Lou Berger
- Re: [netmod] [Technical Errata Reported] RFC8342 … Juergen Schoenwaelder
- Re: [netmod] [Technical Errata Reported] RFC8342 … Lou Berger
- Re: [netmod] [Technical Errata Reported] RFC8342 … Andy Bierman
- Re: [netmod] [Technical Errata Reported] RFC8342 … Juergen Schoenwaelder
- Re: [netmod] [Technical Errata Reported] RFC8342 … Andy Bierman
- Re: [netmod] [Technical Errata Reported] RFC8342 … Juergen Schoenwaelder
- Re: [netmod] [Technical Errata Reported] RFC8342 … Robert Wilton
- Re: [netmod] [Technical Errata Reported] RFC8342 … Lou Berger
- Re: [netmod] [Technical Errata Reported] RFC8342 … Robert Wilton
- Re: [netmod] [Technical Errata Reported] RFC8342 … Juergen Schoenwaelder
- Re: [netmod] [Technical Errata Reported] RFC8342 … Lou Berger
- Re: [netmod] [Technical Errata Reported] RFC8342 … Lou Berger
- Re: [netmod] [Technical Errata Reported] RFC8342 … Andy Bierman
- Re: [netmod] [Technical Errata Reported] RFC8342 … Kent Watsen
- Re: [netmod] [Technical Errata Reported] RFC8342 … Rohit R Ranade