Re: [arch-d] Call for Comment: <draft-trammell-wire-image-04> (The Wire Image of a Network Protocol)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Sat, 15 September 2018 22:21 UTC

Return-Path: <spencerdawkins.ietf@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 D2735130E53; Sat, 15 Sep 2018 15:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 v8zX2isZq50p; Sat, 15 Sep 2018 15:21:40 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 275F0130DD0; Sat, 15 Sep 2018 15:21:40 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id c4-v6so6288888ybl.6; Sat, 15 Sep 2018 15:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oQq6b4zTXrHjK+ElaHoYbfQ6/YG5s5JoXi2FTEOHTIk=; b=Zy9vifpfezD46d287ScF77XJI99TOvUW0BCRFqaD4hv079dslQL6S3B1RC3fdWeo32 4SA4HP9vNOH0eaaWQuWHbEiLFtE9nhPV42Jqa3aPO6KN7aBHo4ImOuGGZxsKlhWIIbJ2 HQzmnxJbR+9tUGqMC+EowDdrO0dFUyT67BS7YI5BydThc++AQEt1QU9ujFViofYyAxQs MbMUksOLut5UFIOyknp57sK61x1sMB8RKtI+ND/IBuKyYwNunBYuWfY+d5NQ3jhcTFKL yORyb3nGA2WUsfvnDvHqbyWETt8f6FiYAvS5RikqCZT5/E3b+OMhTUZBtIEDht5T0s4H hJ0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oQq6b4zTXrHjK+ElaHoYbfQ6/YG5s5JoXi2FTEOHTIk=; b=q7XHJvyHt10RhkwAgqBliJLJYBYMnsvPwNsbUiLRUycwZ/3vrxm9TiTm+EybRgStud FMENeJdU54OBdY3yyh/LcfKhPZcAjPLbfO/q+kZa0n6T5e/Zt/IeljUOGjJRw5shjgik rhn9D6bYYlqozPhge9fU3cXiD9tJKlbgBTg/aNp9TbJQOosUwmac0s8ykf7xIIlXHdkK gW3uwUEDBB6O4jhJkRTbnhwEQYBlEHrlHxptsh77DfO45wK2BaxrQLuwJbpk40P6q+wr 20lijDZ0n5WeeRgAX7Bp6yYchn3wa0bQk/2kencBC2EXXnqvo6KYoRLnJnG1CBmw2MET ZPwA==
X-Gm-Message-State: APzg51DT2tKaJpORSDZqcpUHrN1rFr9q4vXCnjCAEJqGXJwzVkjavS9J 2jLEhsOlHjv80nb9B/sz/5mFfXzrC9wpMt9Hdlw=
X-Google-Smtp-Source: ANB0VdZIsF6qfUtHq5DLpPYjwLmXJENihWNhXqBlp0T5Y9tOw+e76jSm7t/FSIlPzuheGxUiWf7wb8WRRI6zdFvYng4=
X-Received: by 2002:a25:610f:: with SMTP id v15-v6mr7717011ybb.428.1537050099198; Sat, 15 Sep 2018 15:21:39 -0700 (PDT)
MIME-Version: 1.0
References: <153619287953.19753.5995314701986579146.idtracker@ietfa.amsl.com> <8b52dce5-1ee4-b40b-e1ba-e7c9b241dd82@cs.tcd.ie> <6080E931-DEB6-48C8-BEB1-96A69112F67A@trammell.ch> <255e0d12-fbce-1448-90db-daadc4e39c3f@cs.tcd.ie> <m236ubsn8p.wl-randy@psg.com> <3836209E-60C5-4F55-A5AB-8D9EB6E4B935@trammell.ch> <m2r2hur98u.wl-randy@psg.com> <D27B05E4-C622-4AA7-BA2D-17654C77D132@huitema.net>
In-Reply-To: <D27B05E4-C622-4AA7-BA2D-17654C77D132@huitema.net>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sat, 15 Sep 2018 17:21:25 -0500
Message-ID: <CAKKJt-dQVi0FboO6s+cV=kbcD_PHhvyK3EG5HJXV4kd62NEakQ@mail.gmail.com>
Subject: Re: [arch-d] Call for Comment: <draft-trammell-wire-image-04> (The Wire Image of a Network Protocol)
To: Christian Huitema <huitema@huitema.net>
Cc: Randy Bush <randy@psg.com>, IAB IAB <iab@iab.org>, IETF list <ietf@ietf.org>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002a2f350575f05d9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/w97Df6JFNBM02aFxm5puG8YY8fo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <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: Sat, 15 Sep 2018 22:21:43 -0000

On Sat, Sep 15, 2018, 12:09 Christian Huitema <huitema@huitema.net> wrote:

> On Sep 15, 2018, at 9:55 AM, Randy Bush <randy@psg.com> wrote:
>
> >> Ok. The motivation for this draft is indeed he increasing deployment
> >> and coverage of encryption down the stack, which we take as a given. A
> >> few sentences to make this context clear could be useful.
> >
> > i kind of liked just saying that strong encryption is becoming
> > ubiquitous, is here to stay, and the ietf thinks that is a good thing.
> > this has consequences for applications and middleboxes that have grown
> > used to being able to see the traffic in cleartext.
> >
> >> The whole point of this line of work is to define a solution space for
> >> the (technical) problems that arise when “strong encryption is here to
> >> stay”
> >
> > for some of the consequences, there is no "solution."  this may not be a
> > bug.
>
> We discussed that a lot when reviewing Kathleen's draft. There is a grab
> bag of stuff that have been put under the "network management" umbrella,
> from monitoring whether a given path is still working to being able to
> insert or replace ads. There is no doubt that some of that is legit and
> useful. The question then is where to place the line between "yes that's
> useful" and "forget about it". And then, how to best accommodate the useful
> part when most of the packet is encrypted.
>

Speaking as the AD who approved the SPUD BOF[1], the ACCORD BOF[2], and the
PLUS BOF[3], and speaking only from a TSV perspective, I believe the status
is unchanged today from the day that we walked out of the PLUS BOF, which
is that the IETF is deadlocked and will remain deadlocked until one of two
things happens.

   - Either we deliver the kind of transport performance we want to achieve
   for QUIC, using only end-to-end mechanisms, with no involvement from
   network elements, which leads us in one direction, or
   - We can't do that, which leads in a different direction.

I see no reason to debate this further until one of those two things
happen, from a TSV perspective. Your mileage may vary, of course,
especially if you're traveling at another level of the protocol stack ...

It's also worth pointing out that Nomcom has issued their third call for
nominations for the IESG, IAB, and IETF Chair positions, if someone has a
different plan ...

Otherwise, enjoy your weekends, of course. And make good choices ...

Spencer, the eternally outgoing TSV AD

p.s. For those in other rooms at the time, so who have useful alibis,

   - [1] SPUD was https://www.ietf.org/proceedings/92/spud.html.
   - [2] ACCORD was https://www.ietf.org/proceedings/95/accord.html.
   - [3] PLUS was https://www.ietf.org/proceedings/96/plus.html, but
   honestly, must be seen at
   http://oldrecs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_PLUS&chapter=chapter_1
   to be appreciated.

-- Christian Huitema
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>