Re: [dispatch] HELIUM at Dispatch

Adam Roach <adam@nostrum.com> Wed, 11 July 2018 19:15 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70564130EA0 for <dispatch@ietfa.amsl.com>; Wed, 11 Jul 2018 12:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=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 R4WyNf9Sgb21 for <dispatch@ietfa.amsl.com>; Wed, 11 Jul 2018 12:15:48 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 08EE0130EFF for <dispatch@ietf.org>; Wed, 11 Jul 2018 12:15:48 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6BJFivl068325 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 14:15:46 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Dispatch WG <dispatch@ietf.org>
References: <CAHbrMsCpBV+GWcOeXEZ9K9ZrdajhdyGNhpjoGOOjadsC5yx7rA@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <3dd27329-e0e8-5e85-c1f9-f12e584a980b@nostrum.com>
Date: Wed, 11 Jul 2018 14:15:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <CAHbrMsCpBV+GWcOeXEZ9K9ZrdajhdyGNhpjoGOOjadsC5yx7rA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------BF1D9D0C73AB38F6794AD20F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/K3ZozHc5aITn1gdQ_tEERSsw1dE>
Subject: Re: [dispatch] HELIUM at Dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2018 19:15:52 -0000

[as an individual]

This is small, but it's going to be a recurring papercut if this works 
gains traction: I'm having a really hard time reading a document talking 
about "HIP" that is in no way related to 
https://datatracker.ietf.org/wg/hip/about/ -- please consider renaming 
this protocol.

It would probably also be worthwhile explaining how the features of 
HELIUM are significantly different than RFC 1928. I see raw IP tunneling 
and WebSocket support as differentiators, but it's not clear that this 
requires restarting the protocol from ground zero rather than extending 
an existing extensible protocol.

Lest my suggestion above be perceived as tongue-in-cheek, I'm dead 
serious: RFC 1928 is used extensively by the Tor network, and there is a 
fair body of deployed code in modern use, at least in that context.

/a

On 7/11/18 12:27 PM, Ben Schwartz wrote:
> Hi Dispatch,
>
> One of the drafts on the Dispatch agenda for next week is HELIUM: 
> https://tools.ietf.org/html/draft-schwartz-httpbis-helium-00.
>
> There has been some discussion on the HTTP list (e.g. 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0041.html), 
> but the most detailed presentation on this proposal will be here in 
> Dispatch.
>
> HELIUM has relevance to privacy protection, P2P through NAT, VPNs, 
> advanced IP features, QUIC, and congestion control, among other 
> topics.  I hope anyone who's interested will read the draft (or at 
> least the introduction) before our session on Monday.
>
> Thanks,
> Ben
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch