Re: [Last-Call] Opsdir last call review of draft-ietf-quic-bit-grease-03

Scott Bradner <sob@sobco.com> Tue, 24 May 2022 14:40 UTC

Return-Path: <sob@sobco.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0BC185147; Tue, 24 May 2022 07:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level:
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 DgNf9MojYD1O; Tue, 24 May 2022 07:40:00 -0700 (PDT)
Received: from sobco.sobco.com (173-166-5-71-newengland.hfc.comcastbusiness.net [173.166.5.71]) by ietfa.amsl.com (Postfix) with ESMTP id C59ABC183F97; Tue, 24 May 2022 07:39:58 -0700 (PDT)
Received: from smtpclient.apple (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 4993B5F1B94; Tue, 24 May 2022 10:39:57 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-quic-bit-grease-03
From: Scott Bradner <sob@sobco.com>
In-Reply-To: <da8b0a9e-6ce1-4739-9b5b-dd61f2c76475@beta.fastmail.com>
Date: Tue, 24 May 2022 10:39:56 -0400
Cc: ops-dir@ietf.org, draft-ietf-quic-bit-grease.all@ietf.org, last-call@ietf.org, quic@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D3255FA-F41C-4DCD-B9A3-2D2C11C49189@sobco.com>
References: <165300608176.45061.8788283452343771333@ietfa.amsl.com> <00923c7f-3478-4397-a832-3e94d702bca0@beta.fastmail.com> <AB83A30B-69E7-42FE-98EB-21DE69AF816D@sobco.com> <da8b0a9e-6ce1-4739-9b5b-dd61f2c76475@beta.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/H7hdTc9Eyyv88lU1PClHQH6rpRk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 14:40:05 -0000

I think we should just say we disagree and leave it at that

I'm for any help we can to implementors but ...

Scott

> On May 22, 2022, at 8:32 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Fri, May 20, 2022, at 20:59, Scott Bradner wrote:
>> the IETF has a long standing problem with implementors understating 
>> what RFCs are needed to be implemented when
>> implementing a protocol (TCP is a good example - RFC 7414 was done to 
>> provide a roadmap) - anything that helps
>> implementors know"what QUIC is" has to be a good idea
> 
> Yes, I agree that this has been a problem.  But I think that I disagree with your prognosis.
> 
> I see the problem not as a discoverability issue.  https://www.iana.org/assignments/quic/quic.xhtml#quic-transport exists and provides many of the same pointers you suggest we add here.
> 
> The natural end state of using Updates on every extension is close what we have in the registry, with a filter on whether the specification ends up in an IETF RFC.  This does the future implementer no favours beyond what they might learn by searching for "QUIC RFC".
> 
> The true value in RFC 7414 (and RFC 5411 for SIP) is not the existence of a collection of pointers, but how those pointers are contextualized.  These documents provide a map of the space.
> 
> An undifferentiated collection of Updates is of little help to implementers, particularly if the value of those pointers is degraded by the inclusion of features that are largely discretionary, which is definitely the case here.
> 
> I would prefer to reserve Updates for changes that are essential.  Examples that spring to mind: the CRC change in SCTP in RFC 3309, the addition of QUIC to RFC 7983, or the transcript hash for TLS in RFC 7627 (and TCP has a bunch of these).  So this is less about "cheap", but more about preserving this resource.
> 
>