Re: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

Dino Farinacci <farinacci@gmail.com> Fri, 06 January 2023 00:56 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A6AC1377F1; Thu, 5 Jan 2023 16:56:47 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RiPMuEuLQQ8d; Thu, 5 Jan 2023 16:56:45 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42ED0C151521; Thu, 5 Jan 2023 16:56:45 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id c6so131213pls.4; Thu, 05 Jan 2023 16:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ITALKmR2YWRQE2UWareo8d39+VlrkjzaRGRfTyc69Lk=; b=YmGRQM1fiVU3nWa9CdeVVodqRir6nOv7R+jyqzohqcNc9ffhd917hJqNVXHRo74Rrx 1tKHKIoLk8S0izXnQvxd13gRE1UalCYMtV0F/hhegHRCcJjOIDG+FRRlTjKW+44z48Kb FwHflsoQKUrJ2y+rjEhFFPL+B+sEKCOFwVxUlu7BhaGzqbrB6gDE9FV/tPCqI1sBE6vn Ekg9lJ9a83CYgzQqU9IHgA1iLMezPvdZ1eyfNYitW+ku4hIrK0rrW2It1zk4MZLiVBZJ Q5YFd9NLWLHNUmmwA980OFEKqPxeCG2ZGkt4nWmVG6KnRfZqm0CisdYfexl4R0enMYpK hpSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ITALKmR2YWRQE2UWareo8d39+VlrkjzaRGRfTyc69Lk=; b=yTVAJvHQOv4SunGIWCGGO41CbkRfLEjDfgvzmIseWIwy7mOA3ayPlrsVW7KPFL8F12 zfGO/NoI45KRQBPO6qfogC3+aZsmtnzIDKS4KxU1TluVUCq4ZwD7QH0MCcXVppdefFkV S+o/3eeWClkZtNN/N2d1yG6do4uIvcazI1odD5LI68cxhq+t+ULdywR2WnXR151pBbVZ HsCuMxH8viWW508Bt+Yu51WH0+USrRBkG3yjSbY4TSGL19kSrP7H7no1sJ9koVBptZl8 bBW5mVqA13C+Q/rPclajeaiWMyxTK4ndkXqH4iX+BjhHiahBqOvlErg69dV6PDv93fF5 VcAg==
X-Gm-Message-State: AFqh2kprFNjekMwaDLTAh/q3eBC+ANMAwzhPjr98HzIfVtC6joCd+Yum jhOCY6n5pniHh++NRmufS4o=
X-Google-Smtp-Source: AMrXdXv7cOvdbnYoY6LK7Cnfsn7MF6B7VECvePbIw1Djpy588VuXAB7CeGS312A6z/dgjDZye+M6yA==
X-Received: by 2002:a05:6a21:e302:b0:a3:d6:8795 with SMTP id cb2-20020a056a21e30200b000a300d68795mr66857870pzc.17.1672966604243; Thu, 05 Jan 2023 16:56:44 -0800 (PST)
Received: from smtpclient.apple ([2605:59c8:3064:2610:c955:63e4:6c52:ab56]) by smtp.gmail.com with ESMTPSA id x21-20020a170902ea9500b00192a04bc621sm15224602plb.170.2023.01.05.16.56.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2023 16:56:43 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAMm+LwgdmHkA3PKrXb85Dt+pUg-Q5mJwY4kdktgvhB5Twwv3Ww@mail.gmail.com>
Date: Thu, 05 Jan 2023 16:56:41 -0800
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>, pearg@irtf.org, hrpc@irtf.org, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, saag <saag@ietf.org>, Antoine FRESSANCOURT <antoine.fressancourt=40huawei.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <36BA0408-2523-440F-A011-7921A1868A66@gmail.com>
References: <3c3230f3783b4ec9a8a9e3bb87cc2a8d@huawei.com> <08C49067-DB4C-41AB-A6F3-B96BDBE0A4BC@yahoo.co.uk> <CAKr6gn0tFXEV-h7LH1_Ts5iQRw_mGEi=TqS7hsyK-SqDFmmY-A@mail.gmail.com> <C09B3D18-2871-491F-B76C-630A2DCA439A@gmail.com> <EFCEFAA6-3638-4CE0-91DD-3E38FE00DF29@gmail.com> <1F71EB99-3657-4A20-8B28-2AFB743A9762@gmail.com> <1B0A222E-21E5-413E-8B2C-9C0CBCDB0773@gmail.com> <CAMm+LwgdmHkA3PKrXb85Dt+pUg-Q5mJwY4kdktgvhB5Twwv3Ww@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/h4iOIJFqGxr249Anozbjrml4HV8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2023 00:56:47 -0000

> Wall street is likely to be in a unique class here.

Definitely a domain specific case.

> I don't think we need to consider multicast a failure if it doesn't end up being used because the functionality is being provided at a higher level in the stack.

Yes, but the worse place to do packet replication is at the appliation source. You simply kill the lower speed access links that leave the source. Which means you can only put content sources in centralized places with a lot of resources.

> At some point we should do a QUIC like transport for Multicast/Packet Duplication.

Ditto above comment.

Dino