Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-01.txt

Aaron Falk <> Thu, 07 July 2016 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A37812D770 for <>; Thu, 7 Jul 2016 15:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dayVVUOU0tUf for <>; Thu, 7 Jul 2016 15:37:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7CC312D0EB for <>; Thu, 7 Jul 2016 15:37:02 -0700 (PDT)
Received: by with SMTP id t127so27427985qkf.1 for <>; Thu, 07 Jul 2016 15:37:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ePf050OeVpKmXl+jPwbvl4i8cckND/bo6e9J/CUTbAg=; b=B63qnhF/NvTdfByapRShsOIm20NDJhaUtcyv0jj6spm2NeS7qN3YiDdRDtunddGfLn TH5KISKKjIS8msP2sqAMdhqPWcAqxkhP86+p5hpF0GXiHhKX3eUEzymF6/SvwVftWDU3 s/KklcY93umR42PQqx/Wmh7FHer8HvWuaYKkTBr7oAejmoGKwDwEo1sF2u6M05lR1V+c UODgu+jKBP9u0eE9UPlp/99jFSFUlFcDt2dKT74AuU9uZ2vpL5+OT1kqSITePgldZozF Aq0RLSEOI1YjA/90OSLmxYddm6x7/XjLOgBgns0GlluZH/0V51peLWSNjuWeFQ39xopr apNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ePf050OeVpKmXl+jPwbvl4i8cckND/bo6e9J/CUTbAg=; b=JQIJprL26oQnY5XLb6yn1WlBYM2LyR3O1LsQbHOX4IfuShH8YTYsBu7Ej0B71Cx1AK Qtc7jVj6+WOmPRR/uqzoHTWGA9V2yreKrBmNJwRY8J53tPTOXgqFBGqFoSMNaJG7sv3F 3jPLyifnFhVvlGBfWHvYtdX2n9xJ9XJhTbODQFz2lOtzuqufYQSh5Z+RU7y0M0CHcwii g1HsVKPSWOf5yrEU/c6itADwzjpQVTMre4CKXmbX7liPR52wlTCNGnckHNfUiktAjabw 9srv8KDSMxsjQJW7ug1UZKBwVDHnlS1J7uGMubbSikDrYIIv9TobwOXIixv1H4THAprW +22Q==
X-Gm-Message-State: ALyK8tJGCVF1G3wC+5kMQKA5IUt7rNZeb7PxKk+tyxsEm57YX1V0i3XAj6wdT4KVi8hAbg==
X-Received: by with SMTP id q189mr3270671qkb.155.1467931022014; Thu, 07 Jul 2016 15:37:02 -0700 (PDT)
Received: from ?IPv6:2001:4878:8000:60:64be:3eee:ece8:cc4d? ([2001:4878:8000:60:64be:3eee:ece8:cc4d]) by with ESMTPSA id 29sm2198044qtx.4.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 15:37:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5403952E-D13B-400A-9D6B-6EE08B6FF08D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Aaron Falk <>
In-Reply-To: <>
Date: Thu, 7 Jul 2016 18:37:00 -0400
Message-Id: <>
References: <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Blake Matheny <>, Natasha Rooney <>, spud <>
Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jul 2016 22:37:11 -0000

Hi Tom-

One explicit goal of PLUS is to enable controlled communication between endpoints and devices on the network path. As I understand it, TOU is designed to preclude that communication.  As this is a BoF about chartering a working group around PLUS, the TOU draft neither addresses PLUS motivation (e.g., why we need to communicate to middleboxes?) or architecture (e.g., how could we make this communication work in an world with pervasive encryption?).  Since there was some email discussion of your draft on this list, Brian has tried to address the distinction between PLUS and TOU in his slide deck <> (specifically, slide 20) and I encourage you to send any clarification comments to him.

To be clear, this isn’t a reflection on the merits of your proposal, only that it doesn’t address the goals of the BoF: to determine whether the IETF should take on the work described in the PLUS charter.  Indeed, one could consider TOU to be a competing proposal from an applications perspective, one based on a different set of requirements.  I would suggest that it might be a totally reasonable fit with the TSVWG and you might seek agenda time in that working group.  If you are going to discuss TOU in a wg in Berlin, I encourage you to drop a note to the spud list with the specifics.



> On Jul 6, 2016, at 8:00 PM, Tom Herbert <> wrote:
> Hello,
> I just posted a new version -01 of Transport Over UDP. The major
> changes are more elaboration of disassociated location, making session
> numbers not be symmetric, more details on session negotiation, peer
> address and port learning described, don't use addresses in pseudo
> header with TOU, and handling for TCP resets.
> I would like to present TOU at the PLUS BOF if possible.
> Thanks,
> Tom
> ---------- Forwarded message ----------
> From:  <>
> Date: Wed, Jul 6, 2016 at 4:50 PM
> Subject: New Version Notification for draft-herbert-transports-over-udp-01.txt
> To: Tom Herbert <>
> A new version of I-D, draft-herbert-transports-over-udp-01.txt
> has been successfully submitted by Tom Herbert and posted to the
> IETF repository.
> Name:           draft-herbert-transports-over-udp
> Revision:       01
> Title:          Transport layer protocols over UDP
> Document date:  2016-07-06
> Group:          Individual Submission
> Pages:          18
> URL:
> Status:
> Htmlized:
> Diff:
> Abstract:
>   This specification defines a mechanism to encapsulate layer 4
>   transport protocols over UDP. Such encapsulation facilitates
>   deployment of alternate transport protocols or transport protocol
>   features on the Internet. DTLS can be employed to encrypt the
>   encapsulated transport header in a packet thus minimizing the
>   exposure of transport layer information to the network and so
>   promoting the end-to-end networking principle. Transport connection
>   identification can be disassociated from network location (IP
>   addresses) to provide connection persistence for mobility and across
>   state eviction in NAT.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> Spud mailing list