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

Robert Wilton <> Mon, 08 October 2018 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C550130DC4 for <>; Mon, 8 Oct 2018 03:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.957
X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OSExx2ytP6vJ for <>; Mon, 8 Oct 2018 03:01:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C36B130D7A for <>; Mon, 8 Oct 2018 03:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2629; q=dns/txt; s=iport; t=1538992886; x=1540202486; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=uYePRCY7LKlV9mbSNIdo9iTqKG919zQgZ4CvZUEbGlg=; b=JSNvH/lrO6Z9yCEhPCFzsA8C6nrCXYiNBOETJO12LZU5/2UA7OjGFlMO uVe+0EmVYl9o8qo2jNJhXQr+2auryrq2zj85h4DrdbZOw5C/O5aYPFXOR B21hJZinMFyvCNdZAC7XU9SqQ1Z8A7GhZuZZF/OI8Vqm+ASv6kWnnlNcF g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,356,1534809600"; d="scan'208";a="7017895"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2018 10:01:24 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id w98A1OGD004098; Mon, 8 Oct 2018 10:01:24 GMT
To: Andy Bierman <>, Lou Berger <>, Ignas Bagdonas <>, NetMod WG <>, Warren Kumari <>, RFC Errata System <>
References: <> <> <> <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Mon, 08 Oct 2018 11:01:23 +0100
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
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 10:01:29 -0000

So there seem to be two available solutions here:

(i) The server MUST provide an origin value for the top level datanode, 
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.

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


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