Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

Spencer Dawkins at IETF <> Thu, 11 June 2020 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A96A83A0890 for <>; Thu, 11 Jun 2020 13:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_FROM=0.001, HTML_MESSAGE=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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3wFyjoLS1Kbx for <>; Thu, 11 Jun 2020 13:57:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B11B3A088E for <>; Thu, 11 Jun 2020 13:57:45 -0700 (PDT)
Received: by with SMTP id 9so8606797ljv.5 for <>; Thu, 11 Jun 2020 13:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uUVTTGXaciPyyg6et9QNrJljDbuUYGdgz9zmIfgHCNA=; b=pLyVCINVSxE5AISAUcruwJ+qbv2iPPk/MbTbTSQQv5QsWjpkeBSxWQIC6tVKNZv0Aq /3Tkw+YO+eqX+bDLKAPb8YcVAflzkkEJHR5Ja5K5hesqSXoed6fzg5zKTF0KAIzT32Cb uhI5Bdn/MhY5+7KBJcdJLRQ8G6ZvvlKrYXHWJqm0z+VS8JWREfOHSWf3HVplJ7TXBcwM YUSOtM768s8ijKpUgtRPpP/snjI3/vrSidKVvmBcxwYET/3sKQdijqjt88qc0zM10dcT oS64ZCdLO168RvPiG9HBXq5a7R//SmpQhTPf+cfJBXENY7pIitQxEcj85Xme1bv7jdQl NX8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uUVTTGXaciPyyg6et9QNrJljDbuUYGdgz9zmIfgHCNA=; b=aZOaQJ7qvboE+n11vqd/f1EFhPCnPPyOfI+oF83nGmV8dV0Gie+9mQV1X3fXoK91KY yMcc9tjrD8GLaLJb7PLWPoADpaMlRRJ1Kyk7IxzIlHSZr3mbDfggsoJw2oa0n/9l2NiB 7E8OTP0FnUMKOIPqdROvHqE4Pc2Lmt3D1pGFXVOP6QsiPlNx4im4JtnW/Ft48uq+FDkB Edj/5Bh09yC5xfKBC0SdtuKfG/DNsGtKvkfSeZXmhnmHZ3gkCVH5pn/9QqG5UkowdQ4k TAAjXnyt0eYA1VNrObzOxyRQ0Dsg8+NkX21LnUqBhBulZv4tUJQvuprNYGYgloMzaGgW lo6g==
X-Gm-Message-State: AOAM532qtjP73VgjeJaGOU4uxvJqL5Vko4iVgzQZaH9NbBc9T2KN7N6G Azfb8vPa7s+iZo1SE7AzAWipppKn9krz4pn6XHE=
X-Google-Smtp-Source: ABdhPJzvksO1Lj78CU2B40JgZCta4Fl8hDYIvT++voPKLIlEa6nc1pfSZUoBi2ePLD9c8vjb1c1NhNj2BCXTEnE8WjU=
X-Received: by 2002:a2e:974e:: with SMTP id f14mr5047125ljj.102.1591909063608; Thu, 11 Jun 2020 13:57:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <1676009.p4SS4celVB@linux-9daj>
In-Reply-To: <1676009.p4SS4celVB@linux-9daj>
From: Spencer Dawkins at IETF <>
Date: Thu, 11 Jun 2020 15:57:17 -0500
Message-ID: <>
To: Paul Vixie <>
Cc: "" <>, Mike Bishop <>
Content-Type: multipart/alternative; boundary="000000000000404d9e05a7d5369d"
Archived-At: <>
Subject: Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jun 2020 20:57:49 -0000

I have opinions about this draft that I've been pretty vocal about to the
working group during the past couple of years and in the first two WGLCs,
but just to follow up on this point:

On Wed, Jun 10, 2020 at 2:02 PM Paul Vixie <> wrote:

> On Wednesday, 10 June 2020 15:45:50 UTC Mike Bishop wrote:


> > On the whole, I think this document could be suitable for publication as
> an
> > Informational RFC; it provides real-world context for a trade-off that
> > every protocol designer needs to consider carefully.  However, I don’t
> > believe its current state reflects, in Ekr’s words, “the IETF community's
> > view of the relative priority of these concerns.”
> the ietf community is incredibly narrow compared to the world it serves.
> very
> few of the people and companies whose future will be chosen for them by
> ietf
> work can afford the time or travel it takes to be represented. this may be
> an
> inconvenient truth, but it is my reason for considering whether this
> document
> reflects the broader view of the world's digital economy. i think it does.

Keeping in mind that the target is publication as an Informational RFC, I
believe the governing BCP definition is still, which says

4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

Does anyone think that's been updated?

If this document was targeting publication as a BCP, concerns about whether
this document reflects the consensus of the Internet community would be on
target, but it's targeting Informational, and should be evaluated with that
target in mind.



p.s. Funny story - IESGs that EKR and I served on, among others, talked
about whether the RFC 2026 definition of Informational made sense in the
21st century, but ADs are busy, and the definition never changed. ISTM
that at a minimum, the text should say "*might* not represent an Internet
community consensus or recommendation", rather than "*does* not represent
does not represent an Internet community consensus or recommendation".

Now that we have a GENDISPATCH working group, there's actually a place that
the community can go to talk about that definition, if anyone wants to.