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

Kent Watsen <> Wed, 02 September 2020 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ECCE3A0E06 for <>; Wed, 2 Sep 2020 13:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 prGkD2KrxFKT for <>; Wed, 2 Sep 2020 13:07:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBA4A3A0E05 for <>; Wed, 2 Sep 2020 13:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1599077270; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=VjRXWiRS4S8YxsON2sQODh/0m67S287guS/zMrfSJH4=; b=FxgyvAUB1DasTX6GD3zcrTrpNnaQu4bx5YXjXU3fG0dFkQZ0MjIA65mcogv2fuwU NusYsQsjnCk67jKMPSF15M0iC3wJG3HV/HUnXF4aWgaTtDGQvBjSornTXQe6n3eeRFZ rMWnNSoUHfgFZkbdl1oXAZ/X+ipo1PDXDG2nHuoo=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Kent Watsen <>
In-Reply-To: <>
Date: Wed, 2 Sep 2020 20:07:50 +0000
Cc: Andy Bierman <>, Warren Kumari <>, Robert Wilton <>, Mahesh Jethanandani <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <> <>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.09.02-
Archived-At: <>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271)
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: Wed, 02 Sep 2020 20:07:53 -0000

Hi Martin,

>>    NEWER:
>>        The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query
>>        parameters MUST be supported by the PUT method for data resources.
>>        These parameters are only allowed if the target resource is an
>>        entry of an "ordered-by user" list or leaf-list.
> This isn't quite correct (the target resource in POST is not a list
> entry), and it isn't needed IMO.  The text in4.8.5 and 4.8.6 says the
> same thing already, so we don't need to say it here as well.  Esp. not
> in an errata.

But this is in Section 4.5, which only regards PUT.

That said, I also noticed redundant text regarding where the query-parameters are allowed.  Generally, it seems such text should be in Sections 4.8.5 and 4.8.6, more so than Section 4.5...

>> 2) for the “insert” query parameter
>>    In Section 4.8.5: The "insert" Query Parameter
>>    OLD:
>>       The default value is "last".
>>       This parameter is only supported for the POST and PUT methods.  It is
>>       also only supported if the target resource is a data resource, and
>>       that data represents a YANG list or leaf-list that is
>>       "ordered-by user”.
>>    NEW:
>>       The default value is “last”, with exception to when used with PUT
>>       and the target resource already exists, in which case the default
>>       is to replace the target resource without altering its position in the
>>       "ordered-by user” list or leaf-list.
> Ok, but is the grammar correct "with exception to when..."?

There’s a fork in this thread on this point.  Let’s see how that resolves first…

>>       This parameter is only supported for the POST and PUT methods.
>>       It is also only supported if the target resource is a data resource 
>>       that is an entry of an "ordered-by user" list or leaf-list.
> I prefer the old text over this.

But Section 3.5 (Data Resource) clearly says that “list entry" and "leaf-leaf entry" are data resources (not “list” and “leaf-list”).

>> Thoughts?
>> Separately, but related, is it possible to PUT on an "ordered-by
>> user” leaf-list?   Presumably, the operation changes the implicit
>> “key” field...
> Section 4.5 says:
>   If the target resource represents a YANG leaf-list, then the PUT
>   method MUST NOTchange the value of the leaf-list instance.

Ah-ha, very good.  And, interestingly, if not "changing the value of the leaf-list instance”, then it seems the only thing it could be used for it to move the entry’s position - right?

> /Martin