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

Dhruv Dhody <dd@dhruvdhody.com> Fri, 01 October 2021 06:49 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 0E6EE3A0879 for <pce@ietfa.amsl.com>; Thu, 30 Sep 2021 23:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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] 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 6Am_uU6f_rEM for <pce@ietfa.amsl.com>; Thu, 30 Sep 2021 23:49:24 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 3A6783A0878 for <pce@ietf.org>; Thu, 30 Sep 2021 23:49:24 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id j4so4210366plx.4 for <pce@ietf.org>; Thu, 30 Sep 2021 23:49:24 -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=GcATY/EQwq8/nRG7F+bR+MiOmTNzFv1/PrF4HxmwW18=; b=SGvB+OKJlJctzcB9e6Gd41o8RsSlJkzWGY1IVpWQWriUhvQ7WLY6gej7MUfN9W7gYL c8bkwXSBm8e9UUmNY9DAPDC6vMsvJilLaal8T0up6papUpmuuWI6Ia379Z1s2TR9av5m 9Z3ZjgWdBnII3hs07Qo2+qnwROkNVicBXEUtAi++g39UZzkczII+OgaRWVPPppdpSek9 NIRT+Ngk2BMQhBxDrkBfW+ByL2eXlgYcyX5o+Ynz7ATFIbLCb9T1uj782vJZ+/R0M+LT XVQ5+5/sRV1uut8NuNcPXPX8WnX+1JAQdYvegpDV8pbhTEl/xP63fgr3yjdeUFPzBWfH rb7g==
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=GcATY/EQwq8/nRG7F+bR+MiOmTNzFv1/PrF4HxmwW18=; b=LmyCijCGGr4maGiVjW8DD+4XPV3LYkuP/JWfngEc17uEvEv2d38EVPgWgVeRleZ3Gv DaRd8TQLZeAZslqlRQ0T9iygjX+FWTmcBOM+LFACH37WKjDOmqTZaM+YPt35B5ZN+mLX 1IDrQgs6gSUOaR5/vxOKDTdxvYjwCiEllmZBq6R5BmEfFdhI97CeSbG4qzWil/WjveIX BBNN3au4eVyWhJ6+Dij/BA0ZCcUgG/uo7CVM08kx7KC64valdUoItoC5nfsNiIhrgzKd PbES86BbAtQQGBhSGhvI2aM11CtQ8EmO37JGcpOFm9gCkrwdNClelPzMDKTtK5aORexE c01A==
X-Gm-Message-State: AOAM533hm6FEFqoszRtZK7jdwKvwkSr0WH3X3kqA+2JlLV5FZs7W0gy4 Khe9HVZNnyW8E8EArpyL8KrQ9IiSWsUm/W/OPMxWKPwJg5yt4g==
X-Google-Smtp-Source: ABdhPJyMTqFeRy/tbA8B/spTpQ/oylynv3z/Zk8a+pQTM7oZRHVeH5ik+NecwHUL06sDpCx4Nqncs1sm17+uBalaJvI=
X-Received: by 2002:a17:90b:350e:: with SMTP id ls14mr11003328pjb.120.1633070963226; Thu, 30 Sep 2021 23:49:23 -0700 (PDT)
MIME-Version: 1.0
References: <20210701093814.2EEDEF4071F@rfc-editor.org> <CAP7zK5ahkBhxg6L3oe6hCWzxL253gY1q=u2RYDKMdPog+hrrmg@mail.gmail.com> <120267A4-8BD9-47F1-97E2-CB7613EF8157@juniper.net> <31a2d4f5-9110-66d9-e28b-498f4021d031@hq.sk>
In-Reply-To: <31a2d4f5-9110-66d9-e28b-498f4021d031@hq.sk>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Fri, 1 Oct 2021 12:18:46 +0530
Message-ID: <CAP7zK5ZEKZvs3Gb7W=W+NRPc7adFxqVxNS4EXcqJZ4_OG=CJvQ@mail.gmail.com>
To: Robert Varga <nite@hq.sk>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "robert.varga@pantheon.tech" <robert.varga@pantheon.tech>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "EXT-edward.crabbe@oracle.com" <edward.crabbe@oracle.com>, "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a811c005cd44f656"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/TitVyDGH727nve43P1aXmMnr-R0>
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: Fri, 01 Oct 2021 06:49:26 -0000

Hi,

Just to clarify the suggestion to have complete RBNF grammar at a living
document was just for informational purposes (and not to bypass the IETF
process). It stemmed from trying a different approach than the one already
attempted in the past.

I am all for trying the approach suggested by John and Robert.

<snip>
>
> 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
>
>
[Dhruv]: Or an independent document that only focuses on PCEP object
ordering and updates RFC 5440 (and any other document that uses "MUST" for
object ordering).

Thanks!
Dhruv