Re: Working with IEEE 802
Phillip Hallam-Baker <phill@hallambaker.com> Tue, 20 September 2016 15:13 UTC
Return-Path: <hallam@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 1847112B836; Tue, 20 Sep 2016 08:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 K2apOC6B0M-x; Tue, 20 Sep 2016 08:13:52 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 75EA412B705; Tue, 20 Sep 2016 07:52:45 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id z190so17388958qkc.3; Tue, 20 Sep 2016 07:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kMfaEnVFvhWO3RmF3kj4/647ezR5xLjrVnXYSrQR600=; b=ofq0X6voYK95Ra30wwUAh+SZ+2jdP31ZVoGKz9KUI6QjDtvqjCH306EfxsxUliRwuU Xt3Ft5rTT2b86mj4w4azo2JbYfY4+3AznvwGF6oJHb2GLdN6FmkRCEQRoSzcvmOKxoQ6 Wy9kPXhM0zurQZcxG6xRfRZ7+CrowAOrqN8jgV7ehP5FE1di03CL75QBDBW3p7kKt/5a zH0u0PZ/NSxbobHA9WgoGNVQRV2vVTzNCkgBBDfH0lnq/0eucGxe1WGbg2dMS5man2K0 CXl7FsMkPtp6I3a56omEhKOwe8m9R29NzT4+FJoy+AVurH++AREurfWAGx/LfVivjLwB JDoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kMfaEnVFvhWO3RmF3kj4/647ezR5xLjrVnXYSrQR600=; b=mPVZi1oIRbz8mG0ul6lAzL33x1vMJ9BfWdp+jRoiu3v/f2eAVchcCfLx/+jWhOn7rV AQp8qOjB1JnhS7AqE2PRbr74JWzF9ZBtRNNEjEsAByACICk8aYv7os4p2HumujcpCGTJ 9zhuXtffA4ORHWgeGwGYctfCkwb79hPLm3SN5TzSLvzq+FAFqU5yZTUCHNoC9BgEK76B cPzoL2iofz7OBdPKFequ8rOYf0yWx+3y8c/nzIXAX69DwZAsZOaj76m/W/f8UHrdmbv+ Sw9BrzRpAugdcrIOBUlmYhthuRxhWIylaj1ag6yxpUgbdrnTcMUlOOuXPb1Tu5RQdam2 OVBg==
X-Gm-Message-State: AE9vXwO9rKcmBJ2VAikoaJyWX57+eSuu6BfP86o7+mjQpt2PnQEh3Iq4VVUy0X2K+/kww2iK+CgdSQUkUdRp7A==
X-Received: by 10.55.6.8 with SMTP id 8mr36584717qkg.5.1474383164317; Tue, 20 Sep 2016 07:52:44 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.55.209.87 with HTTP; Tue, 20 Sep 2016 07:52:43 -0700 (PDT)
In-Reply-To: <62DCC364-7455-4FCA-8844-603452567C83@ietf.org>
References: <62DCC364-7455-4FCA-8844-603452567C83@ietf.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 20 Sep 2016 10:52:43 -0400
X-Google-Sender-Auth: 8mYKS4hSgdw4q3pW46ygFENRN7M
Message-ID: <CAMm+Lwj_sNT7nLY5Q3YgCdp+K=xDYczXf6H232txwsy14VZT2A@mail.gmail.com>
Subject: Re: Working with IEEE 802
To: IETF Discussion Mailing List <ietf@ietf.org>, IETF Chair <chair@ietf.org>
Content-Type: multipart/alternative; boundary="001a114da112c5ab36053cf1949e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/knf46GsWpgeIM_99jagXlnDGBos>
Cc: IETF Announcement List <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 20 Sep 2016 15:13:55 -0000
Liaisons are good. But I have noticed that each of the SDOs I have been involved in (IEEE, IETF, W3C, OASIS) is very interested in liaising with the SDOs that were established before it was started and not so interested in liaising with those that came after. There is also a distinct bias towards talking to the layers in the stack beyond the one a given SDO works at, In short, SDOs tend to look back and look down when they should be looking forward and looking up. Right now we have something of a situation with HTTP/2 and QUIC that I don't think many folk in the HTTP world realize is happening. HTTP was of course designed as transport for HTML above all else but even from the start we realized that it also made a decent presentation layer for what became Web Services, at any ate it was better than anything else around. HTTP/2 broke that connection, the protocol is 100% optimized for HTML and Web browser transport. HTTP/2 is not a good transport for Web Services. It could have tried to be both but the WG didn't want to do that. And that was probably the right thing to do. Because the needs of Web browsing and Web services are actually rather different. It is clear to me that Web Services should look to transition from HTTP/1.1 to whatever QUIC becomes. and that is not a bad outcome. My problem is that this is an outcome that we appear to have arrived at by chance rather than with a dialogue with the stakeholders in the Web Services world, 95% of which are outside IETF. The principal SDO developing Web Services is OASIS but we don't seem to be talking to them much or even acknowledge their existence. And beyond that I am aware of roughly a dozen more SDOs either being formed, operating or collapsing in the IoT space. I think that the pairwise model of dialogue isn't scaling. We need to have some forum at which all the SDOs meet and exchange ideas. So rather than spending the next three years building QUIC in a corner and then presenting it as a fait accompli to the Web Service developer community and then waiting ten years for adoption, get them involved at the start. And rather than having the design process being decided by one large vendor who nobody else can dare say boo to, have the other parties round the table and have skin in the game. Looking down in the stack, there are features that I really want to see go away because they have moved up the stack. When Ethernet was first introduced, all the machines on a network sat on the same coax cable. So Ethernet absolutely had to have a link layer mechanism for identifying packet destinations. Today, networks are rather different. My wired LAN in the house has about a hundred IP enabled devices on it. But the behavior of that network is very difficult to predict because much of the routing is happening in stupid switches at the Ethernet layer rather than at the IP layer which is actually designed for the task. I have solid engineering reasons for wanting Ethernet layer routing to just go away as fast as it possibly can and replace my opaque Ethernet switches with IP routers. The problem I have with the idea of 'working together' is that this sort of change which is natural and obvious is the sort of thing that I suspect most folk are not going to want to propose in IEEE for fear of causing a rupture in relations. And don't get me started on our ICANN entanglements. I have no idea why so many of you are so keen to invest so much IETF time and political capital in promoting a project that doesn't actually advantage IETF at all.
- Working with IEEE 802 IETF Chair
- Re: Working with IEEE 802 Abdussalam Baryun
- Re: Working with IEEE 802 Phillip Hallam-Baker
- Re: Working with IEEE 802 GTW
- Re: Working with IEEE 802 joel jaeggli
- Re: Working with IEEE 802 Barry Leiba
- Re: Working with IEEE 802 Spencer Dawkins at IETF
- Re: Working with IEEE 802 Kalilou Dama