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

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 29 March 2024 00:08 UTC

Return-Path: <mjethanandani@gmail.com>
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 4D2F9C151997 for <netconf@ietfa.amsl.com>; Thu, 28 Mar 2024 17:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRn41wWZGBMD for <netconf@ietfa.amsl.com>; Thu, 28 Mar 2024 17:08:16 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC15BC15198D for <netconf@ietf.org>; Thu, 28 Mar 2024 17:08:16 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5d42e7ab8a9so925934a12.3 for <netconf@ietf.org>; Thu, 28 Mar 2024 17:08:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711670896; x=1712275696; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=3s75pBt7qNwllphHQKTwZE19cy1L4eZ1wsiJY/FrH9s=; b=Z6TpKLTLU+LKYQtfEKUUH+kPbBfW7NACcst5677mHVovSnpgVb8pQlI850LEm5UQlk qY7xta3kpHFnRhGF9VjOtlReZIcyM7B/Pt+A42OJZ62Kuq3yJJ1+njCK8n993UIXW4Q2 +vlZ5lbajq7jEHbDrfC48ZWdtBCETeycpn+dZ7RFpDwIzuSp/0KKQINucHjjMJulqszS Pc0cOGpmIwxPT2gv+jXjNG1nAgf1cFof9AzI7hHs1M43RcIeQx6VSVEXymJO3C1zxX4D 9ujRn1aaSwY8d0Oto6MwNyx43ricVqcDyUhnD+eggLf+X+403T2D1z/3pdpNA6QN/AHq MipA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711670896; x=1712275696; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3s75pBt7qNwllphHQKTwZE19cy1L4eZ1wsiJY/FrH9s=; b=IXkaqub/e0fMHJKxJP9dBs7xB38PX4SgySEPa0pnTG6w0Q2nmWckoZrTc8wy6uzDXx jvCFk+Gwj+yTqoDGNzo4cu4QBpm8+HrL24VY8dmSW9UGcsRnal3FJGbOjD7eU4Yo/bwH 2h6UTSrEa49T1g/Wod+BtAU3lsde1Dm40Mge0UKKOqC3FNa+OVYCXMkl/12XFVxoc0Vw aqoU4c0AiaAY+P0cpdrHukdlB9304R/QLys7ijHCPFHdr8HjB9wo956qSXsRBocau7yJ KfPlNhZ3qlYhiCHRL6gMqZJ9VRR4F+Nh2ae1ObEcztYHtv1YmmWeZxouybOg2l9t56Es nxuQ==
X-Forwarded-Encrypted: i=1; AJvYcCWThtQ8C6X4bMyQ+VpgNe12MkW/3fsn+/t/IjEzGQWYpK8nl6oOhcx1H6jyR02+ReH/MKk04MwGlbcVzWyKxZNd
X-Gm-Message-State: AOJu0Ywi0ZI0jFxiLR8AEM+7ndwSl3UTloVGF9msX6DZkbHByBU6LhzE H9e0aRSO8IlLB7FVPLzbpOn8W+7F2XVTLwdSxX66w9JwP2hw9tct
X-Google-Smtp-Source: AGHT+IEL/LI1UhbYOiTjicif6cuUGlxIkKnwA9sQC+iyxuKL7EbRHf/6LI1jHJ6Fg0sXhOsh+zQoBA==
X-Received: by 2002:a05:6a20:7d9f:b0:1a3:c619:2d16 with SMTP id v31-20020a056a207d9f00b001a3c6192d16mr737019pzj.44.1711670895850; Thu, 28 Mar 2024 17:08:15 -0700 (PDT)
Received: from smtpclient.apple ([70.234.233.187]) by smtp.gmail.com with ESMTPSA id e28-20020a63545c000000b005cf5bf78b74sm1873113pgm.17.2024.03.28.17.08.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2024 17:08:13 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <687044FC-D8BD-4FE6-8CA4-796F0C29D463@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A9E2AFD-096F-4FE6-8A30-4CC25E63EAC4"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
Date: Thu, 28 Mar 2024 17:08:12 -0700
In-Reply-To: <0100018e87668101-f89754d6-16b7-4af8-b629-d7d2d160f0b2-000000@email.amazonses.com>
Cc: Andy Bierman <andy@yumaworks.com>, RFC Editor <rfc-editor@rfc-editor.org>, mbj@tail-f.com, Warren Kumari <warren@kumari.net>, NETCONF WG <netconf@ietf.org>
To: Kent Watsen <kent+ietf@watsen.net>
References: <20240323173810.33A49E6634@rfcpa.amsl.com> <0100018e809ecc8b-b17354dc-f70c-437a-b915-b8ed4086bffb-000000@email.amazonses.com> <DBDBA573-AEB6-4231-9684-E1C0E23660C6@gmail.com> <CABCOCHT-hY8+pd=05bgAmZdnVmN_HuARzX6WrOXp2imD0RpuAg@mail.gmail.com> <A5FFCFE0-57AC-44F1-B6A4-2FCD352A8CA7@gmail.com> <CABCOCHR3FxYdh3atxpSmGuxAa4KP+oXRgaK2AZe9ANvJ=zs=TQ@mail.gmail.com> <6E1A4F42-8579-48E0-949C-F52414C1C8CE@gmail.com> <0100018e87668101-f89754d6-16b7-4af8-b629-d7d2d160f0b2-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/hc5ppTAGzKHcU7jMTrKxQcbWteM>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (7866)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 29 Mar 2024 00:08:21 -0000

Hi Kent,

Yes, I can change that line also. The Section now reads as “Global”. 

With that change, and getting rid of duplicates, we are left with 3 instances of text that need to be updated. Please confirm before I update the Errata.

Thanks.

Section:
—————
Global

Original Text:
————————
Text occurs in three places

1)    Section 3.5.3

      The leaf-list value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1 and 2.5 of
      [RFC3986].


2)    Section 3.5.3

      The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1 and 2.5 of
      [RFC3986]. 


3)    Section 5.1

      The contents of any query parameter value MUST be encoded according
      to Section 3.4 of [RFC3986].  Any reserved characters MUST be
      percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].


Corrected Text:
——————————
1)    Section 3.5.3

      The leaf-list value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
      [RFC3986].

2)    Section 3.5.3

      The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
      [RFC3986]. 

3)    Section 5.1
      
      The contents of any query parameter value MUST be encoded according
      to Section 3.4 of [RFC3986].  Any reserved characters MUST be
      percent-encoded, according to Sections 2.1, 2.2, and 2.5 of [RFC3986].

Notes:
--------
The reserved character list is defined in section 2.2 of RFC 3986

> On Mar 28, 2024, at 4:30 PM, Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> Hi Mahesh,
> 
> I cannot tell from your edit, but in the original Errata, just *before* the line that says “Original Text”, there is the line "Section 3.5.3 says:”.   I think that Andy means that this line should change also.  Does your edit change this line also?
> 
> IDK if it is editable.  When filing an Errata, there is a field called “Section” separate from the Original/Corrected text sections.  This field is intended to be either a section number (presumably Andy entered “3.5.3”) or the string “GLOBAL” (which likely should be the value now, given that there is more than one section).  Are you able to change this value too?
> 
> Kent // contributor
> 
> 
>> On Mar 28, 2024, at 4:53 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> 
>> Ok. How about this?
>> 
>> Original Text:
>> ------------------
>> 
>> Text occurs in five places
>> 
>> 1)
>> 
>>       The leaf-list value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>       [RFC3986].
>> 
>> 
>> 2)
>> 
>>       The key value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>       [RFC3986]. 
>> 
>> 3)    
>> 
>>       The leaf-list value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>       [RFC3986].
>> 
>> 4)    
>> 
>>       The key value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>       [RFC3986].  The comma (",") character MUST be percent-encoded if
>>       it is present in the key value.
>> 
>> 
>> 5)    
>> 
>>       The contents of any query parameter value MUST be encoded according
>>       to Section 3.4 of [RFC3986].  Any reserved characters MUST be
>>       percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].
>> 
>> Corrected Text:
>> ---------------------
>> 
>> 1)
>> 
>>       The leaf-list value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>       [RFC3986].
>> 
>> 2)
>> 
>>       The key value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>       [RFC3986]. 
>> 
>> 3)    
>> 
>>       The leaf-list value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>       [RFC3986].
>> 
>> 4)    
>> 
>>       The key value is specified as a string, using the canonical
>>       representation for the YANG data type.  Any reserved characters
>>       MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>       [RFC3986].  The comma (",") character MUST be percent-encoded if
>>       it is present in the key value.
>> 
>> 5)    
>>       
>>       The contents of any query parameter value MUST be encoded according
>>       to Section 3.4 of [RFC3986].  Any reserved characters MUST be
>>       percent-encoded, according to Sections 2.1, 2.2, and 2.5 of [RFC3986].
>> 
>> Notes:
>> ————
>>      The reserved character list is defined in section 2.2 of RFC 3986
>> 
>>> On Mar 28, 2024, at 12:39 PM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>> 
>>> 
>>> 
>>> On Thu, Mar 28, 2024 at 12:25 PM Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>>> Apparently, I can edit the Errata. Please confirm that this is all the corrections we are making:
>>> 
>>> Original Text:
>>> -----------------
>>> 
>>> Text occurs in three places
>>> 
>>> 
>>> Now there are 2 sections to identify:
>>> 
>>> 1) sec. 3.5.3 (para 4)
>>> 2) sec. 3.5.3 (para 5)
>>> 3) sec. 5.1 (para 3)
>>> 
>>> Andy
>>> 
>>> 1)   
>>> 
>>>      The leaf-list value is specified as a string, using the canonical
>>>       representation for the YANG data type.  Any reserved characters
>>>       MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>>       [RFC3986].
>>> 
>>> 
>>> 2)  
>>> 
>>>      The key value is specified as a string, using the canonical
>>>       representation for the YANG data type.  Any reserved characters
>>>       MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>>       [RFC3986]. 
>>> 
>>> 3)    
>>> 
>>>        The contents of any query parameter value MUST be encoded according
>>>         to Section 3.4 of [RFC3986].  Any reserved characters MUST be
>>>         percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].
>>> 
>>> 
>>> Corrected Text:
>>> --------------------
>>> 
>>> 1)
>>> 
>>>       The leaf-list value is specified as a string, using the canonical
>>>       representation for the YANG data type.  Any reserved characters
>>>       MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>>       [RFC3986].
>>> 
>>> 2)
>>> 
>>>       The key value is specified as a string, using the canonical
>>>       representation for the YANG data type.  Any reserved characters
>>>       MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>>       [RFC3986]. 
>>> 
>>> 3)  
>>> 
>>>      The contents of any query parameter value MUST be encoded according
>>>       to Section 3.4 of [RFC3986].  Any reserved characters MUST be
>>>       percent-encoded, according to Sections 2.1, 2.2, and 2.5 of [RFC3986].
>>> 
>>> Notes:
>>> ---------
>>>       The reserved character list is defined in section 2.2 of RFC 3986
>>> 
>>>> On Mar 28, 2024, at 11:05 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Thu, Mar 28, 2024 at 9:25 AM Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>>>> Hi Kent/Andy,
>>>> 
>>>> Should I reject the Errata so it can be filed again?
>>>> 
>>>> 
>>>> I guess so -- I don't think there is any way to edit this one
>>>> 
>>>> Andy
>>>>  
>>>>> On Mar 27, 2024, at 8:54 AM, Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net>> wrote:
>>>>> 
>>>>> This errata is incomplete.
>>>>> The issue occurs three times.  
>>>>> The occurrence in Section 5.1 is missing.
>>>>> 
>>>>> K.
>>>>> 
>>>>> 
>>>>>> On Mar 23, 2024, at 1:38 PM, RFC Errata System <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> wrote:
>>>>>> 
>>>>>> The following errata report has been submitted for RFC8040,
>>>>>> "RESTCONF Protocol".
>>>>>> 
>>>>>> --------------------------------------
>>>>>> You may review the report below and at:
>>>>>> https://www.rfc-editor.org/errata/eid7866 <https://www.rfc-editor.org/errata/eid7866>
>>>>>> 
>>>>>> --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>>
>>>>>> 
>>>>>> Section: 3.5.3
>>>>>> 
>>>>>> Original Text
>>>>>> -------------
>>>>>> Text occurs in two places
>>>>>> 
>>>>>> 1)
>>>>>> 
>>>>>>     The leaf-list value is specified as a string, using the canonical
>>>>>>     representation for the YANG data type.  Any reserved characters
>>>>>>     MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>>>>>     [RFC3986].
>>>>>> 
>>>>>> 
>>>>>> 2)
>>>>>> 
>>>>>>     The key value is specified as a string, using the canonical
>>>>>>     representation for the YANG data type.  Any reserved characters
>>>>>>     MUST be percent-encoded, according to Sections 2.1 and 2.5 of
>>>>>>     [RFC3986]. 
>>>>>> 
>>>>>> 
>>>>>> Corrected Text
>>>>>> --------------
>>>>>> 
>>>>>> 1)
>>>>>> 
>>>>>>     The leaf-list value is specified as a string, using the canonical
>>>>>>     representation for the YANG data type.  Any reserved characters
>>>>>>     MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>>>>>     [RFC3986].
>>>>>> 
>>>>>> 2)
>>>>>> 
>>>>>>     The key value is specified as a string, using the canonical
>>>>>>     representation for the YANG data type.  Any reserved characters
>>>>>>     MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
>>>>>>     [RFC3986]. 
>>>>>> 
>>>>>> 
>>>>>> Notes
>>>>>> -----
>>>>>> The reserved character list is defined in section 2.2 of RFC 3986
>>>>>> 
>>>>>> Instructions:
>>>>>> -------------
>>>>>> This erratum is currently posted as "Reported". (If it is spam, it 
>>>>>> will be removed shortly by the RFC Production Center.) Please
>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>> rejected. When a decision is reached, the verifying party  
>>>>>> will log in to change the status and edit the report, if necessary.
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC8040 (draft-ietf-netconf-restconf-18)
>>>>>> --------------------------------------
>>>>>> Title               : RESTCONF Protocol
>>>>>> Publication Date    : January 2017
>>>>>> Author(s)           : A. Bierman, M. Bjorklund, K. Watsen
>>>>>> Category            : PROPOSED STANDARD
>>>>>> Source              : Network Configuration
>>>>>> Stream              : IETF
>>>>>> Verifying Party     : IESG
>>>>> 
>>>> 
>>>> 
>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> 
>> 
>> 
>> 
>> 
>> 
> 


Mahesh Jethanandani
mjethanandani@gmail.com