Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06

Robert Wilton <> Wed, 09 May 2018 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C19C1275F4 for <>; Wed, 9 May 2018 10:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.611
X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 137SuvjXSjOv for <>; Wed, 9 May 2018 10:01:14 -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 6E5141200F1 for <>; Wed, 9 May 2018 10:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2402; q=dns/txt; s=iport; t=1525885274; x=1527094874; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dATP6C6XRs7MPILcEr9DcTcAE3yFOCj93YtC9dEWI8Q=; b=EmKxXRib/OGbMoCFjtRoYP0vG7AA3W8KKaIyWepyh/MUFnOXYDk8a9x/ gcTTHwWcqMVet0i3FegzED3rLoMmEzFFNO8zhjIOukFofrYfhgGqqtYrb BCQqePpZXV++3j3Y+pas1ZVmg+FaOzoiwoGTBSrSqKlg20QmrD5zLsaUl A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwBTKPNa/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMUgRB6hBeIYI1jKYEPkyqBeAuEbAKDDjYWAQIBAQEBAQECbCi?= =?us-ascii?q?FKAEBAQECASMPAQVGCwsYAgImAgJXBgEMCAEBF4MIAoF3CKkAghyEWINtgki?= =?us-ascii?q?BCYhwP4EPI4JohF2DFoJUApgsCI5JBoE1hh2FEYdCg2mFJIElIwEwgVIzGgg?= =?us-ascii?q?bFYJ/kE4+kVQBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,382,1520899200"; d="scan'208";a="3737424"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 17:01:12 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w49H1C0x030890; Wed, 9 May 2018 17:01:12 GMT
To: Rohit R Ranade <>, "" <>
References: <> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <> <20180509095352.zahi7yuljb7ucd4x@elstar.local> <> <20180509164735.nkwvt52wk76lm6p2@elstar.local>
From: Robert Wilton <>
Message-ID: <>
Date: Wed, 9 May 2018 18:01:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180509164735.nkwvt52wk76lm6p2@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 May 2018 17:01:16 -0000

On 09/05/2018 17:47, Juergen Schoenwaelder wrote:
> On Wed, May 09, 2018 at 05:15:12PM +0100, Robert Wilton wrote:
>> +1 for a generic solution.
>> At the moment RFC 8040 states that ETAGS only apply to configuration, so
>> they don't necessarily help with operational data.
>> Perhaps we should be introducing something like ETAG support for operational
>> as well.  Although, we would need to careful consider the implementation
>> performance impact.  Given that operational data may come from multiple
>> daemons, it may be very hard to efficiently generate reliable ETAGs that
>> span across large chunks of operational data.
> Yes, there is fast changing data and slow changing data, there is
> expensive data (in terms of instrumentation) and there is inexpensive
> data. I think the solution is to let the server decide an which data
> to provide etags (or something equivalent).
This sounds like a reasonable starting point.

>   HTTP also has all the
> Cache-Control magic - I have no clue whether RESTCONF implementations
> and in particular RESTCONF clients do honor HTTP caching mechanisms
> and maintain local caches at the HTTP interaction level.
I don't know either.

>   It seems HTTP
> has a lot to offer here (no surprise) and it is not clear what needs
> backporting to NETCONF or whether we are better off making RESTCONF do
> all the things NETCONF does - or we do both and the implementations
> will ultimately decide. In the long run, maintaining two protocols
> providing similar functionality does not seem to be effective.
I think that having the flexibility of a binary encoding is likely to 
become more important over time, particularly for dynamic configuration, 
or streaming telemetry.  From the previous discussions, it looks almost 
trivial to add binary encoding support into RESTCONF, but a lot of work 
to add it to NETCONF.

One thing that I prefer in RESTCONF is being able to provide a config 
update as a single tree update that includes both merge and delete 
operations as annotations within the tree.  This seems like an efficient 
way to generate and send a delta of a configuration from a client to the 

But possibly a useful discussion to have may be what the members of the 
NETCONF WG perceives is the future for the IETF network management 


> /js