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

Robert Varga <> Thu, 30 September 2021 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 031D53A15F8; Thu, 30 Sep 2021 15:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ENTA56xB3A2K; Thu, 30 Sep 2021 15:35:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F116A3A15F6; Thu, 30 Sep 2021 15:35:38 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id A3BC4243C3B; Fri, 1 Oct 2021 00:35:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1633041334; bh=wonEjOT8poCqk7jVoc6Di+dkmY0TAFtanhUnePRXIZ4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=F4mvNoln0zm7txGTBFqV8WgnJomdQ/G++RLHvoZhxBeNh9MPn6uMFN9HxSzU4bfpk dd7A/rwMEC6DREquuUSIpy9I45hQ+U+VzaXZkycSB2m4Ytwb35HOwYPSkEsGIkNjb2 jDEuGOnAT9pLU8hVFUO9IEON1E3fRpW9mmRPipV8=
Message-ID: <>
Date: Fri, 1 Oct 2021 00:35:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0
Content-Language: en-US
To: John Scudder <>, Dhruv Dhody <>
Cc: "" <>,, "" <>, "" <>
References: <> <> <>
From: Robert Varga <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------U9nTIXECMVV1ezJpE10pBchL"
Archived-At: <>
Subject: Re: [Pce] [Technical Errata Reported] RFC8231 (6627)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Sep 2021 22:35:46 -0000

On 30/09/2021 20:42, John Scudder wrote:
> Hi Dhruv,

Hello John, Dhruv, everyone,

(goes off to find and dust off the co-author hat)

> Regarding whether this is a verifiable erratum or not, the submitter 
> notes, “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 use of the word “proposal” suggests to me that this goes beyond the 
> scope of an erratum, which is limited to correcting errors in a manner 
> consistent with the consensus at time of publication 
> ( 
> <>). 
> Unless there was specific consensus for the proposed sorting order, it 
> seems to me the erratum oversteps this boundary.

(now with the co-author hat on, still fits after all these years!)

This one specifically is tricky.

When we introduced draft-crabbe-pce-stateful-pce-00, while it was doing 
the bare minimum required, the WG felt it already had too big a scope -- 
it ended up being split into two (or three?) documents in the end.

The fact that RFC5440's insistence on object ordering is resulting in 
exponential complexity in terms of what each new document needs to cope 
with in terms of reconciling all previously-published document, and 
worse, all concurrently-existing drafts.

If memory serves right, we discussed this with Adrian (and JP?), and the 
agreement was to specifically limit RFC8231-to-be to extend (and 
therefore consider) ONLY RFC5440, i.e. specifically place integration 
with other extensions out of scope.

So the document reflects WG consensus accurately, and I do not believe 
the errata at hand should be accepted.

> Thanks for your reference to draft-cmfg-pce-pcep-grammar-02. Looking at 
> the list traffic, it doesn’t appear there was much (any, really) 
> discussion of it, unfortunately.

Yes, this is exactly the kind of follow up we envisioned to happen 

  It also led me to find
> <> 
> , where the AD at the time (Adrian) rejected erratum 3672, which is 
> similar to 6627 in that it complains about ambiguous ordering and asks 
> for a fix. Adrian ends his rejection comment with
> “In rejecting this Errata report I note that the reported error is not a 
> typo,
> but a deliberate decision of the authors and working group. The fix, 
> therefore,
> if it is to be applied needs to be achieved through a consensus document.”
> AFAICT this reasoning applies equally in the current case. Actually, it 
> applies even more so, because the WG was offered 
> draft-cmfg-pce-pcep-grammar-02 and didn’t do anything with it, which 
> implies a lack of consensus to go forward with a solution to the 
> identified problem.

So I watched this from the sidelines already, but I believe it was more 
of a lack of determination to iron out all the issues and drive the 

> I do agree that since this topic won't be going away, it seems worth 
> expending some effort to solve it instead of ignoring it. Unless someone 
> wants to make the argument that the RBNF grammar isn’t subject to IETF 
> consensus, I’m not sure the methods you suggest are suitable, at least 
> not without some additional consideration for how to make sure they 
> reliably reflect consensus.
> Finally I note this other paragraph from Adrian’s message:
> “Discussion of this point led to a debate about whether the RBNF is 
> normative and
> should be "compilable". Some hold the view that being conservative in 
> what you
> send and liberal in what you receive could only make this text normative for
> building messages not parsing them. Others noted that, as with RSVP, the 
> object
> ordering is advisory not mandatory except as where noted explicitly in 
> the text.”
> (FYI the discussion he references is here: 
> <>)

Exactly. The crux of the issue is that RFC5440 prescribes a rigid 
protocol structure, which does not lend itself to extensible data modeling.

> This implies to me that there’s at least one other possible way forward, 
> which would be to update RFC5440, making object ordering optional. 
> Something like this:
> OLD:
> An implementation MUST form the PCEP
>     messages using the object ordering specified in this document.
> NEW:
> An implementation SHOULD form the PCEP
>     messages using the object ordering specified in this and subsequent
> documents when an ordering can be unambiguously determined; an
> implementation MUST be prepared to receive a PCEP
> message with objects in any order.
> In other words, fix the problem by fiat, retroactively declaring it to 
> be a non-problem. Let me be the first to say that this proposal might be 
> technically unsound for some reason, but since it was mentioned in the 
> earlier email and represents a different way forward, I thought I’d 
> include it here.

Exactly. The WG needs to make decision as to how to clean the house. 
There are two options, both of which you have referenced:

- publish a standards track document which will tie together all current 
documents, updating them as needed to resolve conflicts like the one in 
this erratum

- publish a 5440bis with saner object ordering, a compatibility section 
and all that jazz

Unless one of these is implemented, this problem will keep coming back 
and it will get worse with each new published document.

> I’ll wait for further discussion, but for now my plan is to reject the 
> erratum for the same reason 3672 was rejected.

I am okay with either holding it or rejecting it -- whichever makes more 
sense with respect to the WG's plan of solving the underlying problem.