Re: [Pce] [Technical Errata Reported] RFC8231 (6627)

Dhruv Dhody <dd@dhruvdhody.com> Thu, 30 September 2021 16:04 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4243A0D79 for <pce@ietfa.amsl.com>; Thu, 30 Sep 2021 09:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20210112.gappssmtp.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 Cdg036phcIJ2 for <pce@ietfa.amsl.com>; Thu, 30 Sep 2021 09:04:42 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F033A0D7C for <pce@ietf.org>; Thu, 30 Sep 2021 09:04:41 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id n2so4349584plk.12 for <pce@ietf.org>; Thu, 30 Sep 2021 09:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QMhdWMByOnIJ+I8sfbe1A8vHSSLJRg42jYSleIGPTnE=; b=SuL5cps9/x7OuSFvsoHEzfrCyaId+8EY4plqgwk/2duRdZgZTYdoE59Qfc/ghPao6D R0yrZOhVylXdC4OALKNH7EcoRCxFKuTycNsE0SlS9zj14Jp2XjKLmcQaUB1qK6VRfsuD cmrOo0cZvK/bjrazXU5GNYTwfTAOSfgkhD3o+gAddh2btQPGWF3pVKFDUan8Kskf55RZ M3ObH4mWt7ZnkgMODf5WsW7thY37skg36ywS3sMMtsIwqdKQO38Qv8RB6UGoNDCDi2F0 t6qBAUUAxS1nR090/9qMsbvn0SEzr2SEn0JEOIZau2baZCqUFuLHwWtidnnNXmekxi+A 76yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QMhdWMByOnIJ+I8sfbe1A8vHSSLJRg42jYSleIGPTnE=; b=ARhkfIjoLG96S9zXUI4XEwMVMXuQzyTCQ6Z3QXDmb2LY+OPKZ7iB+BZwSGLshcFugf C04yspW7FujlIYvj4o0orEVonNmbZ4TplSR2npm0150B5KWGdykV1M6aTMRCQzOq/Rih Km/gXwOtejVtEBUyk08NgBVteSfbhyp+KCbYHyELoee3IM+HkK5hw2hvbjyTuRfrOfuU jXFZAT4AVzZhx83qPjo9y8O7vnG5Ax1efwXH74OtUdWy2QL7Qh/J5iIQ5lWUl0li/jW0 eDYdFYPSbfhXer5RYsOuk4xkP+jrAc6GkxyHZt239ynIlSjNtwhfHTCwHSqTP0vZzRt9 CiyQ==
X-Gm-Message-State: AOAM5303ZbrEF0QN1p9ABpjhvcrUrLfK1XgkKEh2PWvi+g1IKjuOVUOc gP+VX1ep8hHUnd84nafH4s59uwAtONcCFiQw+YzYGA==
X-Google-Smtp-Source: ABdhPJxyxqwK2AZb2KuEWIaSG9lxvhZfmqbQnhznarwaWcQHhyz7IvL2nvZTFyaH373XaRztCunyCOTNBpXxbRDOBTw=
X-Received: by 2002:a17:902:a5c2:b0:13e:4f02:222 with SMTP id t2-20020a170902a5c200b0013e4f020222mr6260197plq.68.1633017880932; Thu, 30 Sep 2021 09:04:40 -0700 (PDT)
MIME-Version: 1.0
References: <20210701093814.2EEDEF4071F@rfc-editor.org>
In-Reply-To: <20210701093814.2EEDEF4071F@rfc-editor.org>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 30 Sep 2021 21:34:04 +0530
Message-ID: <CAP7zK5ahkBhxg6L3oe6hCWzxL253gY1q=u2RYDKMdPog+hrrmg@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: edward.crabbe@oracle.com, inaminei@google.com, jmedved@cisco.com, robert.varga@pantheon.tech, Alvaro Retana <aretana.ietf@gmail.com>, John Scudder <jgs@juniper.net>, martin.vigoureux@nokia.com, Julien Meuric <julien.meuric@orange.com>, Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>, pce@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b482c005cd389a28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/tQgWenJlBotqJ-_IA3nc0p5RRi0>
Subject: Re: [Pce] [Technical Errata Reported] RFC8231 (6627)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2021 16:04:47 -0000

Hi John, WG,

Oscar is correct in pointing this issue with RBNF when multiple I-Ds extend
the PCEP message. The erratum could be marked as "Held for Document Update"
so that any future update to RFC8231 could handle it.

Note that the RBNF grammar inconsistency was discussed in the past [1].
Since PCEP messages will keep getting extended it might be worth checking
if a living document (wiki, GitHub) could be used to maintain the full RBNF
of PCEP messages.

Thanks!
Dhruv & Julien

[1] https://www.ietf.org/archive/id/draft-cmfg-pce-pcep-grammar-02.txt

On Thu, Jul 1, 2021 at 3:08 PM RFC Errata System <rfc-editor@rfc-editor.org>
wrote:

> The following errata report has been submitted for RFC8231,
> "Path Computation Element Communication Protocol (PCEP) Extensions for
> Stateful PCE".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6627
>
> --------------------------------------
> Type: Technical
> Reported by: Oscar Gonzalez de Dios <oscar.gonzalezdedios@telefonica.com>
>
> Section: 6.4
>
> Original Text
> -------------
>   <request>::= <RP>
>                       <END-POINTS>
>                       [<LSP>]
>                       [<LSPA>]
>                       [<BANDWIDTH>]
>                       [<metric-list>]
>                       [<RRO>[<BANDWIDTH>]]
>                       [<IRO>]
>                       [<LOAD-BALANCING>]
>
> Corrected Text
> --------------
>   <request>::= <RP>
>                       <END-POINTS>
>                       [<LSP>]
>                       [<CLASSTYPE>]
>                       [<LSPA>]
>                       [<BANDWIDTH>]
>                       [<metric-list>]
>                       [<RRO>[<BANDWIDTH>]]
>                       [<IRO>]
>                       [<LOAD-BALANCING>]
>
> Notes
> -----
> RFC 5455 defines the CLASSTYPE object and specifies that the CLASSTYPE
> object MUST
>    be inserted after the END-POINT objects. RFC 8231 defines the LSP
> object and specifies that  the LSP object MUST be inserted after the
> END-POINTS object. Hence, it is not clear if CLASSTYPE or LSP goes after
> END-POINTS. Hence, to disambiguate and avoid interoperability issues, the
> proposal is to include the CLASSTYPE object in the updated grammar. The
> order would be <END-POINTS>[<LSP>][<CLASSTYPE>]
>
> 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.
>
> --------------------------------------
> RFC8231 (draft-ietf-pce-stateful-pce-21)
> --------------------------------------
> Title               : Path Computation Element Communication Protocol
> (PCEP) Extensions for Stateful PCE
> Publication Date    : September 2017
> Author(s)           : E. Crabbe, I. Minei, J. Medved, R. Varga
> Category            : PROPOSED STANDARD
> Source              : Path Computation Element
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
>