[saag] Re: [rfc-i] RFCs vs Standards

Eric Rescorla <ekr@rtfm.com> Wed, 11 December 2024 12:26 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB9C151556 for <saag@ietfa.amsl.com>; Wed, 11 Dec 2024 04:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.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 B5o0W8_Brw5w for <saag@ietfa.amsl.com>; Wed, 11 Dec 2024 04:26:53 -0800 (PST)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AB1C151701 for <saag@ietf.org>; Wed, 11 Dec 2024 04:26:53 -0800 (PST)
Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-e2bd7d8aaf8so5055401276.3 for <saag@ietf.org>; Wed, 11 Dec 2024 04:26:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1733920012; x=1734524812; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wWFly033GZeFJs5LnuXE49B8eHYCtLdrzS2HCBzoNhc=; b=s3VAOC5HeElb4+TdzJdo/nx88fSLdDop6niXm1p1sXRvo9qt+KTv/PvEvrSPtO4k9m V3BpT3WOiypoYT6Uir/E+f3I0KIIl+3gTerei5kBJ/s7mxOYXw1oZXhDkXw93irWOnc2 G9tCkvR4HKods8OX850SMJzTK3D1N6L5AVVJnSKvEdK4f5dgpubCG6bkcBwKHMsBV3Cy d4pbu0ihzZjYGQDtDN7IUxNLuJjEMpHdcTxdTtIie6jTrNM1X65SKHX7ODl9BNF/hfWv xBO/rJsIhNBj/dw1f7XKJLeViaYFdDowQnmcQcsQX2IaXDfoVGsCflHJ6pVH2pbSOKJX /zBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733920012; x=1734524812; h=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=wWFly033GZeFJs5LnuXE49B8eHYCtLdrzS2HCBzoNhc=; b=Z7yCIRWaaXNPbsvfQlbiYbyoafgJvupaF2MZ9vlyA+9KbeaDJS1gXhFV1pOfOJ8k6i zXbiCHWc5PC8KeDE6nbJL3lOZmaY02CEqu1MYDD43hbJ6ND04dz/LbUS5tUeft1oyNb4 CwbpU9WuRudARGe6ZHksi98zcWnkZcCH/sJ5hzeUiNoUnUBn6iwQsefF/JpwfKaNYBJl KpgT2fIeZScVJ/TapMKvZWRP+OlJulIViqbqX9CPc4XCa4vO4KdFRfKKvAJ+n5OIsI+o 2/65yuFrXlIWOcMb2Vw07kvexWTDW7OP9lCjb8d/Dbmo9RZvrROkLPyEmxvfoCqiaV6P kqWA==
X-Forwarded-Encrypted: i=1; AJvYcCX1a9J2v4Td6hYtGLaG0sMPKdZSZZXIvB9/pby/13h8pqIyKBWNpbYP5Sal9WnAaxNEPhE5@ietf.org
X-Gm-Message-State: AOJu0YxwQaGAeLu8z3SDE9s9h0Z0m4zQw7hFS7vDEDILvksJFt65tPL+ 3/uH7rw278cR4DHoreVkHv/Eb1Ce6fSmwxqvkckJq4SnUkfVDHeKMU36DuX02RN60HNzpGlgXA+ ua85bQ8e2ErH0JZJWYTFD82qgzXZsGBOfkeIMKg==
X-Gm-Gg: ASbGncsnDirwADtkQNmbJpr46YdWlzssRNft03DIYMbsgupvWA9DtCrq88qpD0wcwRZ lMozSp4yQj7Ct0UaxUGfBdj5T7Af0DqCdxv4=
X-Google-Smtp-Source: AGHT+IHXcwGXKRDGE1Fm9KnmLA1LMhwDzGbeyd6u/zGv+tPsFWti4Mwrp4gCUj75Yq3SRX39HzzDw6hift9ErevVqnc=
X-Received: by 2002:a05:6902:18d5:b0:e38:8a7d:d291 with SMTP id 3f1490d57ef6-e3c8e42e3c2mr2530770276.10.1733920012627; Wed, 11 Dec 2024 04:26:52 -0800 (PST)
MIME-Version: 1.0
References: <BE95E617-C929-43BA-BB40-41E189A8158B@akamai.com> <SY8P300MB0711C796AB6095C788556516EE292@SY8P300MB0711.AUSP300.PROD.OUTLOOK.COM> <15450.1732763286@obiwan.sandelman.ca> <3029EB03-6E7A-47CB-9682-F511CB51EE17@akamai.com> <10065.1732826193@obiwan.sandelman.ca> <CACsn0cmWVeFdJ3dzMj5SV4XpJF4rssULtfQ1moeefoq-Evhk=g@mail.gmail.com> <CAGL5yWb=tLvMOYFKT3ffVbcy7BAD=i4B0VHEUdkvwRvZ3X3Bsw@mail.gmail.com> <m2mshh4v8l.wl-randy@psg.com> <CABcZeBMjxNbBMYU2p3_a8-5VCExgmY-7XLof7die05YOEX-38A@mail.gmail.com> <70419651-6443-4393-9ca1-8a1c98a68db0@cs.tcd.ie> <CABcZeBNtBRxi5zSf9OvUip2AtyVD6Wt9+kQESuUzo-=Kur9+ZQ@mail.gmail.com> <fac981d9-2fe9-4a84-8af1-845acd72af58@cs.tcd.ie> <14124.1733073164@obiwan.sandelman.ca> <d52ee080-814b-46fd-9e0f-41349941eeac@cs.tcd.ie> <GVXPR07MB9678DF2C14EA44B28C3DA372893D2@GVXPR07MB9678.eurprd07.prod.outlook.com> <F304B6BA-6969-4C62-A217-88E76F82CDC2@tzi.org> <C74E3E9D-E892-48B4-87BE-CD634081AA23@akamai.com> <030FD3D1-8BC9-4C92-84EE-9CD18F451E73@tzi.org> <5249aa71-52c2-4f20-b2ae-62eaf75c82b7@lear.ch>
In-Reply-To: <5249aa71-52c2-4f20-b2ae-62eaf75c82b7@lear.ch>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 11 Dec 2024 04:26:16 -0800
Message-ID: <CABcZeBPB=9+zT4HM+NnakNDsC_6wZkw25CZTWBD2kqZcW+98qA@mail.gmail.com>
To: Eliot Lear <lear@lear.ch>
Content-Type: multipart/alternative; boundary="0000000000006c13b60628fdb673"
Message-ID-Hash: STJAXDNKPZ5ZM3T3IKQSV4N4Z77OH5C6
X-Message-ID-Hash: STJAXDNKPZ5ZM3T3IKQSV4N4Z77OH5C6
X-MailFrom: ekr@rtfm.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-saag.ietf.org-0; header-match-saag.ietf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>, Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, IETF SAAG <saag@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [saag] Re: [rfc-i] RFCs vs Standards
List-Id: Security Area Advisory Group <saag.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/rlRm4A003qS1JwW8yHI02vQhbTg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Owner: <mailto:saag-owner@ietf.org>
List-Post: <mailto:saag@ietf.org>
List-Subscribe: <mailto:saag-join@ietf.org>
List-Unsubscribe: <mailto:saag-leave@ietf.org>

On Tue, Dec 10, 2024 at 12:47 PM Eliot Lear <lear@lear.ch> wrote:

> And this is where we run into problems, because the moment you change that
> boiler plate, you will devalue the RFC series and create support and
> interoperability problems as people end up implementing different versions
> of a specification. And to be clear, IANA is the LEAST of our problems.
> The IETF needs a way to have not-ready-for-prime-time DRAFT work without
> fear ofcreating a mess.
>
I think this assumes facts not in evidence.

Of course, we don't have the controlled experiment of removing the
boilerplate, but what we *do* have is the experience of WGs/communities who
have done Internet scale deployment based on I-Ds (HTTP/2, TLS, QUIC,
WebRTC) and then successfully transitioned the community over to the
eventual RFC. At least some of those communities are also the ones who
permit code point registration based on I-Ds (TLS, QUIC) and have not in
fact experienced the issues you raise about confusion about what to
implement.

Obviously, opinions may vary, but in my experience, is to take a more
flexible approach to the coordination problem, namely, having robust
mechanisms for distinguishing which version someone is implementing and
handling that situation appropriately (e.g., in the case of draft versions
of TLS 1.3, negotiating TLS 1.2). This allows for some version diversity
prior to RFC publication but also allows the community to converge on the
new published version once it exists (which, as I said, we have done
successfully in the cases above). You're of course free to believe that
this was somehow facilitated by the disclaimer on the top of the I-Ds, but
that's not my belief, nor, I suspect, of many others who have been heavily
involved in the aforementioned transitions.

I do appreciate that there are (principally non-interactive) protocol
settings where this type of mechanism does not work as well, and it's
possible that your argument above has some force, but I'd like to see some
evidence of that beyond your assertion of it.

-Ekr