Re: IETF areas re-organisation steps

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 26 December 2014 20:16 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFED31ACE3C for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 12:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.123
X-Spam-Level:
X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 pdl0-PZ69Mel for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 12:16:50 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279CC1ACE35 for <ietf@ietf.org>; Fri, 26 Dec 2014 12:16:50 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id gm9so9327362lab.12 for <ietf@ietf.org>; Fri, 26 Dec 2014 12:16:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JHW83ZLPWvGUM0dO4uLGQv1T0KSX63E2NwEOTEsf6Vg=; b=f0hXTcfQIzqS/8UTpquziO4fK2O9UKTsQt3uFsrT+X57v1jkE9FPzYI+mB1lqUtPl5 3yA62YDl33fTAqC6/lRZuXrTj7JslgKUyAgOkKAAENYlomsiknZPybaVlY/7JC3PUbp4 oNFy7fdZlkwzfvfibjsfo8ltiSCyuQN9j1RjSV7rpoN0UcB2qi+jnjv4vuu/Jphz5HWW LSirorUGBwkc0On07ZN9awDdJmbBeuW6lfXw2FYjQcSPx8IQyIPsPAo/IPWboVzO/ShC eHESBY6TISe5FWNtAKHFAhC+YYYoLRCmTFHykGr4nFViRz867XvOodMfTf7FXwCX++vJ F9Kg==
MIME-Version: 1.0
X-Received: by 10.153.11.170 with SMTP id ej10mr45105187lad.24.1419625008535; Fri, 26 Dec 2014 12:16:48 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.19.42 with HTTP; Fri, 26 Dec 2014 12:16:48 -0800 (PST)
In-Reply-To: <549D9A14.2050103@dcrocker.net>
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net> <549D8C57.8090402@nostrum.com> <EE91C0E7-0ED8-4AC2-8490-EF1D70ECC480@vpnc.org> <549D9A14.2050103@dcrocker.net>
Date: Fri, 26 Dec 2014 20:16:48 +0000
X-Google-Sender-Auth: HuL6OGjcxduJQSv0DV4qj44G0rw
Message-ID: <CAMm+Lwh+02o9f4L4kU0TLygeNOxtZtNAnHFzvX5Sm5ZZZahbAw@mail.gmail.com>
Subject: Re: IETF areas re-organisation steps
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary="001a11347914592100050b243445"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/mnXeiJMx6iPnuvcUIMF8weQqRzc
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 26 Dec 2014 20:16:52 -0000

On Fri, Dec 26, 2014 at 5:25 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 12/26/2014 8:50 AM, Paul Hoffman wrote:
> > Maybe we can take a short hiatus from our relentless cute naming and
> call it what it is: UPPER.
>
> That's reasonable.
>
> An alternative that is equally un-cute but highlights one of the more
> salient aspects of this realm of work:
>
>    End2End (E2E)
>
> The technologies in this new area all reside in the end systems, rather
> than the underlying packet-switching infrastructure.


But where do the endpoints lie?

The funny thing about the mail system we are using for this conversation is
that it is not end-2-end. The application endpoints are mail clients and/or
Web browsers. There are multiple transport endpoints, the inbound and
outbound MTAs, spam filters, the list serve...

When we get into the trust and security issues the endpoints are people and
organizations, not machines.


I see a division between two types of 'applications' work. One is work
defining actual applications. Things like Jabber, Mail, Minion Rush, Chat,
etc. In the early days of the Internet, the IETF had 100% of the
applications work. Today there are tens of thousands of applications in
widespread use. It is clearly beyond the capacity of the IETF to support
development of all such protocols even if it tried.

The other type of applications work is to provide standardized
infrastructure that can be used to build applications. So just like there
are standards for screw sizes, pitches, heads, etc. and these are vitally
important to people who make cars, boats and airplane engines, there should
be standards for applications infrastructure, like how to map an API to a
JSON based Web Service.