Re: [netconf] [Technical Errata Reported] RFC8040 (6342)

Andy Bierman <> Tue, 24 November 2020 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D0FF3A0C38 for <>; Tue, 24 Nov 2020 13:31:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 66DJ3ps9wybb for <>; Tue, 24 Nov 2020 13:31:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EDD23A0C63 for <>; Tue, 24 Nov 2020 13:31:25 -0800 (PST)
Received: by with SMTP id u19so137895lfr.7 for <>; Tue, 24 Nov 2020 13:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cdLswaqd95pW8cZIOqsWKWo4HVOOx+n8eMBZI1bNtF0=; b=06JeanUGa2bCHUEvWYG4lPBJdNk8fE8sKUXrg4saKASWh6pHR9GHLv8PZ9i3NsUJe2 eAuVBKmwGw3kb4tNCq2MhCOabgNf4gAesP6Ap+ZWaQ7Gh8/XpvZPH6EcCMf7Eo1CeLyR X1BA6xeUyDpGUmVgC5f1resbRKM4kQO+n9bp6w4CUCFxts2ZpTksewvlBw9TZSwjV1EP qrb2LrjDgvFQ4MZlgHRpeki/Q73CLCcABvGpaPQknejAHe1u07PiY7NqEPJuV6MVHM9l +dcv0+YhRCmvomlbHHT8snNvMIWFWXvccZVJYbnnjiJoHqT56qqkOzIWKnhuwVOb8EMd sncQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cdLswaqd95pW8cZIOqsWKWo4HVOOx+n8eMBZI1bNtF0=; b=cfZHG2jkXduImqtKDDg1RXaf8R8wJo2gLopjmi9x/bIyhLS30u7dds9O9JElUGxQQu zwoMyjDaiGbCpIDvRymb9hHHsm5f+QyR/XKkBWROjdXAMFPjVv4zpeThxuhotfHeupK9 OE7+myzGIE2sqo5/3kbcXg7PCKaokDZB+T6m7W7oqihevfqZdpXI+KD5j4k4aQbw5KQQ Xf5gXQPwVBQrCcQEviB7RtznjGErkXAvcgcxFLv+t3TwnNqLw8/s22GlwNmNCx84ZRSL HVNw3r7CdikKy+KNgZXDCvDYdI6n7HZv3iL258Lfv1vyfYP4dycI6NiVJNg8V581PrlH wybw==
X-Gm-Message-State: AOAM531Ww/WI8ost6IsvrhYGvytm9+hfjBIj80qgQO4owb7I/Ec+lbxA TS6g2STpzgqW0M/TAao02mQyYlbLypktlz3Tg8n+Xg==
X-Google-Smtp-Source: ABdhPJwDXykkU4sxLfn8Sn/YBBnOfgboSLhJxBRQ3OiAZbTj2FFxhN8V6SOwlBjf5KRA6GpuFhndeWAzr3arUPAjEQ4=
X-Received: by 2002:ac2:4182:: with SMTP id z2mr32469lfh.451.1606253483340; Tue, 24 Nov 2020 13:31:23 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Tue, 24 Nov 2020 13:31:12 -0800
Message-ID: <>
To: Kent Watsen <>
Cc: Martin Björklund <>, RFC Editor <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000004b4ac105b4e108eb"
Archived-At: <>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 21:31:41 -0000

On Mon, Nov 23, 2020 at 9:27 AM Kent Watsen <> wrote:

> +1 on rejecting the errata.  PUT replaces the resource, PATCH modifies it.
> Any node not present in a PUT representation is assumed to be deleted, but
> it is not allowed to delete keys, hence why keys MUST always to present in
> a PUT.
> Although we have several customers that would like to rename list entries,
> and sometimes think RESTCONF allows it.  I do not think any YANG-based
> protocol
> allows list keys to be modified.  You have to delete and re-create the
> list entry.
> I think this is something for YANG-next to consider, so it is done
> consistently across
> all protocols.
> YANG-next or RESTCONF-next?
> I think that it is unique to RESTCONF since only RC (not considering COAP)
> targets specific resources.

I think any YANG list with keys can have this problem.
IMO it is better to define the common semantics in YANG and let the
decide how to encode them on the wire.

The workaround (of course) is to pick an arbitrary integer or label as the
so there is no reason to change it.

That said, the feature might be something that could be added via an I-D,
> as opposed to an 8440-bis.
Not to restart this thread, but I prefer yang-next vs. lots of add-on RFCs.
Yes it is harder for standards writers to produce, but easier to use in the
long run
for the vendors and operators.

> K.