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

Lou Berger <> Mon, 08 October 2018 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 454BC130E28 for <>; Mon, 8 Oct 2018 09:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gf5IverL0m5c for <>; Mon, 8 Oct 2018 09:34:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC9B0130E8F for <>; Mon, 8 Oct 2018 09:34:04 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id F0CFF176E75 for <>; Mon, 8 Oct 2018 10:04:48 -0600 (MDT)
Received: from ([]) 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;; 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 ([]:51736 helo=[IPv6:::1]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <>) id 1g9Xz6-00148R-2O; Mon, 08 Oct 2018 10:02:16 -0600
To: Robert Wilton <>, Andy Bierman <>, Ignas Bagdonas <>, NetMod WG <>, Warren Kumari <>, RFC Errata System <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Lou Berger <>
Message-ID: <>
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: <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1g9Xz6-00148R-2O
X-Source-Sender: ([IPv6:::1]) []:51736
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <>
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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


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