Re: [Last-Call] Opsdir last call review of draft-ietf-quic-manageability-14

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 14 February 2022 15:58 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 31E513A1092; Mon, 14 Feb 2022 07:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qerTaGOqd0oS; Mon, 14 Feb 2022 07:58:19 -0800 (PST)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 49C383A0D3D; Mon, 14 Feb 2022 07:58:19 -0800 (PST)
Received: by mail-vk1-xa2e.google.com with SMTP id a6so9069292vkc.3; Mon, 14 Feb 2022 07:58:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xKvDpTNeUU3cpIh2R297pigv1d3/Tn40ZajzEDNhjX4=; b=oqO5Q8fzgThifs4wA99n4Oq/IKUQqUsy2TIAad0TZJG4VEh7lEuPPKZQPm8/eoQCGe jbYJn/wl0iH4AAqO6m6O4cd1XBTpd12XP2A/N6vgY+tjfbFUihV2OrUicZlzwfKOjmE8 RMWVNoV4FeFtkhspjaAukMC3j3tqTz7uMTTKkdRQrztKyIsiKOeICJMGrD+9Fx+P1fb5 FmVeg/rqgQkXXpVDOuaGAo2izv/UF5cyQrh4j27ZcILsTooPB4Vxv0/Fmje2YehtXRGG nqPSvDwifSRHZGn0DODRcZJV86zIzxN3MehcWGrqaIdNvbZ7Po9TiGmu4r/AxJ+jrU61 Xu5g==
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=xKvDpTNeUU3cpIh2R297pigv1d3/Tn40ZajzEDNhjX4=; b=hxPqX//oQSWwCF3zk6mWtEXeElzXsLZlgaHvjG+WW/dj38q6FQIQnFd3Du+CLYxmtA O0TqTbg2l7bWHatFtzpa+/yVPPWNID6JJT9Le6UcNpEXP0ba+Pc3qd4apkxTUEyLGfcT vAvMRhD5H/n26I8k9nPzohznNTwDBDHpiGH3LyOP8MSedPPZMZuQzTVeueIjh+33GW+o 4kgAkS4KZJfaxWNDnTuzxdR4yo1ku40c/ohvDb4Dl7dNNZYfyy3OSmqIomX9vnKT9Xzw yNYYTRGaAjzXbUOvsXAp+rZmM0K3oNK4j1CpuKUMfRo2CBKRN5Meox0rOjr+7ORlMHHR 7iNg==
X-Gm-Message-State: AOAM531bllBw94Nncai5NcHzh7F23veDts5XBYZta6eMwjJwn4u0KLIO okXhCMj7BzndHEYohpC8LFZRhu/13vlYzwGG7/o=
X-Google-Smtp-Source: ABdhPJwK9AHg8sKH4csa9AZ2o/8zr8EAMv5skmJdcZeoKDkXghv3JSbLGr9vDHPIo127UM/5had3w0b8+Pl1CvpgJyE=
X-Received: by 2002:a05:6122:1692:: with SMTP id 18mr24859vkl.25.1644854295318; Mon, 14 Feb 2022 07:58:15 -0800 (PST)
MIME-Version: 1.0
References: <CH0PR02MB7980CA04E5EADBF6D25AD8F2D3319@CH0PR02MB7980.namprd02.prod.outlook.com>
In-Reply-To: <CH0PR02MB7980CA04E5EADBF6D25AD8F2D3319@CH0PR02MB7980.namprd02.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 14 Feb 2022 09:57:49 -0600
Message-ID: <CAKKJt-fnM-zcw931HuzWheHA2bqtnAZUn0c_saFJvo-e3Um4jg@mail.gmail.com>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-quic-manageability-14
To: "MORTON JR., AL" <acmorton@att.com>
Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-quic-manageability.all@ietf.org" <draft-ietf-quic-manageability.all@ietf.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fad58205d7fc7bc4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QijpPT0b_jsDfD-3vVyoR5pqizw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 14 Feb 2022 15:58:25 -0000

Popping up because my name was invoked ("poof!")

On Sat, Feb 12, 2022 at 1:06 PM MORTON JR., AL <acmorton@att.com> wrote:

> Hi Mirja, Thanks for your replies.
>
> I replied below: some concerns with assumptions about operators in a doc
> for operators, and TCP-f-something (use a single term) is still
> unresolved...
>

<snip>


> >     4.5.  Filtering Behavior
> >
> >        [RFC4787] describes possible packet filtering behaviors that
> relate
> >        to NATs but is often also used is other scenarios where packet
> >        filtering is desired.  Though the guidance there holds, a
> >        particularly unwise behavior admits a handful of UDP packets and
> then
> >        makes a decision to whether or not filter later packets in the
> same
> >        connection.  QUIC applications are encouraged to fail over to TCP
> if
> >     [acm]
> >     is "fail over" or "fallback" the preferred term?
> >     (using only one will help)
> [acm]
> Still need to pick-one here, and everywhere...
>
> Spencer and others had some replies/follow-up comments here.
>

After discussion, Spencer's comment degenerated into "pick one".

I'm not speaking for others who replied/followed up on this, but I was
thinking that it would be possible to use fairly precise terms to describe
what the QUIC implementation was trying to do.

After reflecting on what other people said, I'm thinking that the precision
I was hoping for won't be helpful for passive observers, and (for extra
credit) would be even less helpful if/when we deploy
https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ and a passive
observer isn't seeing all of the paths in use. 😀

So I'm thinking that anything we agree on for this document may not survive
the use of QUIC for new applications.

Do The Right Thing, of course.

Best,

Spencer

p.s.  😈 I can't wait for the day someone uses QUIC datagrams for an
application that can rely on DCCP as its f******* protocol, and all the
network operators are still looking for TCP traffic - but let's not *even *go
there in this document! 😈