Re: [tsvwg] L4S drafts: Next Steps

Jonathan Morton <chromatix99@gmail.com> Thu, 11 March 2021 22:55 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D37D3A10C1 for <tsvwg@ietfa.amsl.com>; Thu, 11 Mar 2021 14:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 Cu6XBTQIdXAP for <tsvwg@ietfa.amsl.com>; Thu, 11 Mar 2021 14:55:53 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 04C6E3A10BF for <tsvwg@ietf.org>; Thu, 11 Mar 2021 14:55:52 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id z25so4308577lja.3 for <tsvwg@ietf.org>; Thu, 11 Mar 2021 14:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vDpwFUtkvjRLWL11fyfuVjfgANBTeTqsKyIaF0kOV4I=; b=WZHUZTgRZUDmFYJy45GovBGz98cvBytqK3xEWchMJYHMEtQ06/EFm7Lau7/KEXCKDt Y6VK9cPZRiBfeLopNnzD7/+st63n9wkEyxzba0POChv9dw1Fm+wieQGSWvwvsMbUE75D POLg6w2/AIvKl8KowIDjpmUJ3xctSxNH2fh/owR90FclDa1pLrw49/XsO/o7w+rRZ3ik CobtOyKxPkgbeHS49Gg5vriP1W+UDPP6VXRT1qpnYtmZuqSeFdsLZ/EYtoGARxL2bbES U7zmn1xnj3OMDbIxmDmz0NL5kDZT5F4d+DcG8eEn09+ErdBAwUCYmnsFPEmyH5k39IiM vu+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vDpwFUtkvjRLWL11fyfuVjfgANBTeTqsKyIaF0kOV4I=; b=OhosP47C64aoRGZU5lFRrZ59TerD3QZXIuPOkU8lfd7RSJ8oA8Oc1BlrTxi1muOeUI vCAZQYDnARBoWyWoiuY7ttJjjKl2pp2forta06gJxBDxZiED6h+BtFWyv3/uYh7Ns61r hSUrN/HsfRPg7AdEuY8BCpA17l6n8SE/mglfXw+WF31/ppvKFYrPuoF1IiasxuxG0EbW ZzH1oKMsNTSskTvz9bwOIsV0FL/yUOuq5CNyJCs/ptEzvXXi0hfOaJX2jdj2ADN1Utht 9zRK6YWehBDmbbjzkeyXRtiAFZ7T//13AJcIgz9McPFaVJrouQHBVNNb+Qo9wlK0xe1j 24WQ==
X-Gm-Message-State: AOAM531x8DEstIIMmVaVBz9TWZ5I6DoRkgUWZ+FIC1zSqAU+14CiRPsp 542KqjOLj3Y/VxusWofMqNW753higgQ=
X-Google-Smtp-Source: ABdhPJxv6AhH2+7gWAznrfLit074cA8IcZi8VfcSbmMKN3eWqwMqO+jRV/F2BUFo5ThWrc7AlIuD6w==
X-Received: by 2002:a2e:9183:: with SMTP id f3mr663330ljg.109.1615503349653; Thu, 11 Mar 2021 14:55:49 -0800 (PST)
Received: from jonathartonsmbp.lan (87-93-215-52.bb.dnainternet.fi. [87.93.215.52]) by smtp.gmail.com with ESMTPSA id c16sm1218182lfb.302.2021.03.11.14.55.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Mar 2021 14:55:49 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <375666b8-1123-a635-1cd6-eb496835369a@bobbriscoe.net>
Date: Fri, 12 Mar 2021 00:55:47 +0200
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2963CA47-2A15-4335-96A5-EB5F653498F2@gmail.com>
References: <MN2PR19MB4045FAC079C74FC262005BF483F10@MN2PR19MB4045.namprd19.prod.outlook.com> <92283815-f81a-ba86-fe63-7925e23e31f6@bobbriscoe.net> <MN2PR19MB404513C22FE4025C31261BC783CC0@MN2PR19MB4045.namprd19.prod.outlook.com> <5d8f0031-1aee-9e41-7860-04a46a89607e@bobbriscoe.net> <MN2PR19MB4045305CA7D5673C554BCBA383919@MN2PR19MB4045.namprd19.prod.outlook.com> <ee0c9cd2-608c-ef69-ef84-892cd4f17204@bobbriscoe.net> <MN2PR19MB404522F073A03BA2F866604E83909@MN2PR19MB4045.namprd19.prod.outlook.com> <83559d3f-6004-118a-cde2-ec999fc8c483@bobbriscoe.net> <DE5B87E4-DD60-435E-80AD-01C09F13D173@gmail.com> <375666b8-1123-a635-1cd6-eb496835369a@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4ucviytubslRaozwwy4FYIvdcyI>
Subject: Re: [tsvwg] L4S drafts: Next Steps
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 22:55:55 -0000

> On 12 Mar, 2021, at 12:07 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> The concern is requiring unnecessary work to prove things that are "bring me a different rock" exercises.

That does appear to be *your* concern at the moment.  I am merely trying to interpret the concerns of other people for your benefit.  Neither you nor I are the sole arbiters of what valid concerns may or may not exist.  I would however encourage you to consider what I have recently said about "externalised risk"; I can find a link to the YouTube recording of my talk the other day, if that would be helpful.

What I believe David Black is referring to - and I'm sure he'll correct me if necessary - is the (hopefully uncontroversial) notion that a specification is useless if it cannot be implemented, and indeed not very useful if distinct implementations are not automatically interoperable with each other.  This is part of the IETF credo of "rough consensus and running code".

As he explained, it is not necessary for two independent implementations to actually exist for an Experimental or Proposed Standard RFC, so long as there's a reasonable expectation that a second complete implementation is achievable by an ordinarily skilled practitioner of the art (to borrow some patent law jargon).  The existence of *one* complete implementation would, however, appear to be a prerequisite for such a determination.  If such an implementation is open-source and well documented, it's reasonable to expect a second implementer to refer to it in minor cases of doubt - but the major facets of requirement must also be well described in the specification.

I have entirely separate concerns about the specification itself, which I will keep to other threads.

 - Jonathan Morton