Re: [IPv6] [Technical Errata Reported] RFC8754 (7102)

Erik Kline <ek.ietf@gmail.com> Mon, 29 May 2023 22:40 UTC

Return-Path: <ek.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA23C14CF17 for <ipv6@ietfa.amsl.com>; Mon, 29 May 2023 15:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, 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 2iPvc18lI6Qh for <ipv6@ietfa.amsl.com>; Mon, 29 May 2023 15:40:37 -0700 (PDT)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 ACBBAC14CF1D for <ipv6@ietf.org>; Mon, 29 May 2023 15:40:37 -0700 (PDT)
Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-456f1cc1791so1171176e0c.2 for <ipv6@ietf.org>; Mon, 29 May 2023 15:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685400036; x=1687992036; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hMXLKIFxLT+e64/oZPpFnG3ipbcWfD+LANdOCIi5lzQ=; b=l/QACwugxb3WlmEHFtoifPhn5Qwa1CB8q+puTWN0VRoo5lGMvGegNSl7+W0X7GChWW 3Z9oGv13f7T/XNV/dXZkzi0idyAIKbiSbfCI1US/eM4zYrbv8BRX45xg7uYgr1XMR1jQ 1MYW8p/o4htq0xjGqYjvwf8mwU1zwkvklj0Mbwm5gaflVtTAY9GTT4y/aXWr1OOMxTNv rkLgAIsjiANPoE53Fgz6EohNlFNgZsgByNI08xRJk2N3rAzJlmdRbgXnyPe/0DlNu//Y Ej8zQ+92SniMOyzRIYjXAtHG5b2v9phf5i6Kp/FCRuuVvCsShlPHFNgen0wUT+7Dg2kF pFwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685400036; x=1687992036; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hMXLKIFxLT+e64/oZPpFnG3ipbcWfD+LANdOCIi5lzQ=; b=P9EMfnLfOLzeqN0Gl2ISoexscmwVX2+Ioe5xhnmw9/Ms1jAiqHPIKbqeWKkepaf49z 9i80CKVDCLboAewTWR2tBDhUF4nYRpqJHZNHgj7n0zgisovz8xw0CYpxjbABpvOCP4CR AVSZhL6UruV3jwf80ToD29+BxDuu0MnrchOY36wzaMFlB37WOAkb9NUaa9y81mtvk62l tRRN8RZ7gILV/W94GEqfOXchTb7tPKaTrbjF0ax197LUHd2u2vnn5a3fNj9a3HhQ2ufi eYmKUtMvPay+AyKwFDcQ2ojmcwPxtcZI3fc/ZejRXMjlplqu5tPJYthwBV7ulWz+1BZx 1iOg==
X-Gm-Message-State: AC+VfDyawjUrKvLIMeX1GOgTt20fxxg3afGuF8UlXu1Fxz+ieeLvT/op T4jllb3h6FBwKb/10x9L59vSYLlMkjXGMdySOk8=
X-Google-Smtp-Source: ACHHUZ40eg5KwZbPYn/9JnSOa63MbxeMjSXo92H67eVwTQsKZtwR9aEY2XK/yTBUVYo+D4YL40yfMgr3JnY8QnOzNic=
X-Received: by 2002:a1f:5c89:0:b0:457:9843:32bb with SMTP id q131-20020a1f5c89000000b00457984332bbmr41405vkb.4.1685400036292; Mon, 29 May 2023 15:40:36 -0700 (PDT)
MIME-Version: 1.0
References: <20220823193827.8334B877CD@rfcpa.amsl.com>
In-Reply-To: <20220823193827.8334B877CD@rfcpa.amsl.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Mon, 29 May 2023 15:40:25 -0700
Message-ID: <CAMGpriUPOnWWBYynvbH=2CL_4FgAD6Yut1SMKOuqHzEwXEHJZQ@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: cfilsfil@cisco.com, ddukes@cisco.com, stefano@previdi.net, john@leddy.net, satoru.matsushima@g.softbank.co.jp, daniel.voyer@bell.ca, evyncke@cisco.com, bob.hinden@gmail.com, otroan@employees.org, furry13@gmail.com, ipv6@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jPjN5Pd-W_vtr7AewRIAi_RqoKA>
Subject: Re: [IPv6] [Technical Errata Reported] RFC8754 (7102)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2023 22:40:41 -0000

There has been a request to engage in some word-smithing before
returning this to Verified.

May I ask that it be put back into Reported state while this is discussed?

On Tue, Aug 23, 2022 at 12:38 PM RFC Errata System
<rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC8754,
> "IPv6 Segment Routing Header (SRH)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7102
>
> --------------------------------------
> Type: Technical
> Reported by: Darren Dukes <ddukes@cisco.com>
>
> Section: 2
>
> Original Text
> -------------
> Segments Left:  Defined in [RFC8200], Section 4.4.
>
> Corrected Text
> --------------
> Segments Left:  Defined in [RFC8200], Section 4.4.
> Specifically, for the SRH, the number of segments
> remaining in the Segment List.
>
> Notes
> -----
> RFC8754 describes “The encoding of IPv6 segments in the SRH” where IPv6 segments are defined in RFC8402.  RFC8402 describes binding SIDs and adjacency SIDs for SRv6. Both these SID types identify more than a single explicitly listed intermediate node to be visited.
> The current definition of Segments Left only indicates it is defined in RFC8200, and RFC8200 defines it as “Number of route  segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination”.
>
> Previous versions of draft-ietf-6man-segment-routing-header (0-11) referenced RFC2460/RFC8200 and described the Segments Left field by use in the SRH; as an index into the Segment List. This was removed in later versions (12/13) to consolidate the use of segments left to be specific to the segment processed (now section 4.3.1).  However, that removed the definition of its meaning in the SRH which led to the current issue.
>
> The corrected text restores the meaning of Segments Left for the SRH in relation to Segment List (which is not defined in RFC8200), while still leaving its use during segment processing to the segment definition (section 4.3.1 or future documents).
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8754 (draft-ietf-6man-segment-routing-header-26)
> --------------------------------------
> Title               : IPv6 Segment Routing Header (SRH)
> Publication Date    : March 2020
> Author(s)           : C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer
> Category            : PROPOSED STANDARD
> Source              : IPv6 Maintenance
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG