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

Kent Watsen <kent+ietf@watsen.net> Thu, 03 September 2020 12:25 UTC

Return-Path: <0100017453eda313-6583dabe-0ade-4773-a88d-27486a090808-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0860F3A0A6D for <netconf@ietfa.amsl.com>; Thu, 3 Sep 2020 05:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljd1ernvzgAU for <netconf@ietfa.amsl.com>; Thu, 3 Sep 2020 05:25:18 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446FD3A0A16 for <netconf@ietf.org>; Thu, 3 Sep 2020 05:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599135917; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DK/u/svrnUYt3bIlNWiL3unZP8/lvYxC86V3AWxP3KU=; b=a5k7/kSCFPkmJXVgGX14khw1H7LMfcXur3/lkxbXz5JBjD/iHGRbnU15Rc3AaGDK FRgMNKNpXr+0WeDS4bwsltEhmYOAc8qYr9Sq0JH2UybsnQ3HZlBRHDsqPcsgM5wtrUP T4HrI8v5/MvbVoYDV6SQqlU3ddvQJVqMdquKwg8c=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100017453eda313-6583dabe-0ade-4773-a88d-27486a090808-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FF88E6E-2E37-431F-A54D-D71AEA54B817"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 3 Sep 2020 12:25:16 +0000
In-Reply-To: <20200903.073723.641805022613525310.id@4668.se>
Cc: Andy Bierman <andy@yumaworks.com>, "netconf@ietf.org" <netconf@ietf.org>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
References: <CABCOCHRTsyju+3e1jUSTzFswpvG5KzARWyQXM_M8AukxJqPkZw@mail.gmail.com> <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> <20200903.073723.641805022613525310.id@4668.se>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.09.03-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GRqsQFN0hGgOG2eWuEB_v7AWGvM>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2020 12:25:21 -0000

I don’t think that I’m able to edit this errata for Section 4.5.  If I could, I would submit again with the new text that fixes the *entries* language.

I think that the AD needs to “reject” this Errata (EID 6271).  We could file separate errata to fix the “entries” language in Sections 4.5, 4.8.5, and 4.8.6, but I’m unsure it’s worth it.

So I just filed a new errata https://www.rfc-editor.org/errata/eid6277 <https://www.rfc-editor.org/errata/eid6277> to fix just the “insert” query parameter "default" issue.

K.


> On Sep 3, 2020, at 1:37 AM, Martin Björklund <mbj+ietf@4668.se> wrote:
> 
> Kent Watsen <kent+ietf@watsen.net> wrote:
>> 
>> 
>>> On Sep 2, 2020, at 12:24 PM, Kent Watsen <kent+ietf@watsen.net> wrote:
>>> 
>>>    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.
>> 
>> The text above allows/suggests that are four “insert” values MAY
>> always be explicitly passed (and presumably processed).  Do we want to
>> support the case where a PUT is used only to move an element?
>> i.e. the passed “replacement” data is identical to what exists on the
>> server, only the insert/point have an effect?
>> 
>> Or should this strategy be that the insert/point can always be passed
>> (in a PUT for an "ordered-by user” list or leaf-list), but they only
>> have meaning (i.e., are processed) when/if the object is being
>> created, and otherwise ignored?
> 
> No, move (and possibly modify the entry) is supported.  Section 4.8.6
> says:
> 
>   The "point" query parameter is used to specify the insertion point
>   for a data resource that is being created or moved within an
>                                             ^^^^^^^^
>   "ordered-by user" list or leaf-list.
> 
> 
> /martin