Re: [Udp35] Trying to learn about udp35

Brian Trammell <ietf@trammell.ch> Wed, 21 May 2014 22:22 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: udp35@ietfa.amsl.com
Delivered-To: udp35@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF8D1A03BC for <udp35@ietfa.amsl.com>; Wed, 21 May 2014 15:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 nz599TCePD-7 for <udp35@ietfa.amsl.com>; Wed, 21 May 2014 15:22:11 -0700 (PDT)
Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 73B831A00EA for <udp35@ietf.org>; Wed, 21 May 2014 15:22:11 -0700 (PDT)
Received: from [10.0.27.104] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id B322F1A001E; Thu, 22 May 2014 00:22:09 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <9F7FA388-3AA3-496F-B727-E2D8872B82C5@ifi.uio.no>
Date: Thu, 22 May 2014 00:22:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <989971F8-203E-4087-87EF-CEA1214DE9C9@trammell.ch>
References: <CAGD1bZYA4esRRYfSeRjBnJv4pGyRyg3x7xBBd_C=-NfxDD9rpA@mail.gmail.com> <537A3BA5.2070406@gmail.com> <CAGD1bZas6ur_uS=YaPedXqLCaVcxk+kGo=bO+axFQdTJaB5eHw@mail.gmail.com> <E81DA188-091C-4E23-BAC7-09702F9C66E3@trammell.ch> <9F7FA388-3AA3-496F-B727-E2D8872B82C5@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/udp35/YhGjEr1mjmZ_oV6qwOXZrXf5Is4
Cc: Jana Iyengar <jri@google.com>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, udp35@ietf.org
Subject: Re: [Udp35] Trying to learn about udp35
X-BeenThere: udp35@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Life beyond UDP <udp35.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/udp35>, <mailto:udp35-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/udp35/>
List-Post: <mailto:udp35@ietf.org>
List-Help: <mailto:udp35-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/udp35>, <mailto:udp35-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 22:22:13 -0000

hi Michael,

a brief reply now to be followed by a more in-depth one...
 
On 21 May 2014, at 19:05, Michael Welzl <michawe@ifi.uio.no> wrote:

> Hi all,
> 
> Glad to be onboard!
> 
> As for the slide deck, it looks very interesting but it also reminds me of much that we have already discussed in the TAPS effort. Note that this non-WG-forming BOF in London was preceded by a bar BOF, which was preceded by more work ... e.g. we have worked out a draft charter at some point, and agreed to do things pretty similar to what seems to be proposed in these slides. Now surely I'm missing the bigger picture here, but I'd like to make a plea to not go back to square one

This is absolutely not the intention; to some extent what we've done since London is look at the problem from a slightly different angle ("what are the architectural implications of the difficulty of evolving transport, and why is it hard to evolve?" as opposed to "how can we improve the interface to transport so that we can offer new services?"), and we've come to basically the same idea of the problem that TAPS has -- yes, indeed, the interface is part of the problem. This convergence is a good thing...

> but instead continue from where things already are at (see https://sites.google.com/site/transportprotocolservices/ ). 

...and now that we're here, we'd like to brainstorm in Toronto about the way forward. We want to make sure the work that's been done in the TAPS effort is successful.

> If this means having a WG-forming BoF in Toronto, then I guess it's about time to get this organized.


While it's clear that the TAPS charter as formulated addresses the same problem, and that most if not all of the various technical pieces remain the same, it's not clear to me personally that binding the solutions to these problems to a (single) IETF-defined API is the best way to ensure this work sees wide implementation and adoption. There are other paths: providing building blocks to API designers, just accepting the fact that people are already designing APIs and providing them guidance (especially on how not to break things, e.g. CC), doing one of these latter things and building an API on top of that, etc... and this is part of what we want to talk about in Toronto.

> I can imagine that we want to do more than what we have written into our charter, but what I'm suggesting is not to wait with piece A of the puzzle just because we in fact want pieces A, B and perhaps C too, and we have to still find out if/how to do pieces B and C. I'm having a hard time imagining that piece A just won't fit, whatever B and C may look like, so why not get A done?!

The charter, especially its formulation of the problem statement, is a good starting point; to borrow your terminology, I'll try to follow up tomorrow or Friday with specific suggestions on how we might (lightly) tweak A to better fit aspects of the problem space we didn't really get into either in our premeeting or during the BoF in London.

I note that the first concrete deliverable we've identified is essentially item 1 on the proposed TAPS charter; this analysis work should absolutely continue regardless of progress in forming any future WG -- indeed, formation of a working group would be likely to slow this work down, as opposed to speeding it up. Such an item could be published on the IAB stream if a WG isn't formed in the meantime. 

Cheers,

Brian

> Cheers,
> Michael
> 
> 
> On 21. mai 2014, at 12:30, Brian Trammell <ietf@trammell.ch> wrote:
> 
>> hi Jana, all,
>> 
>> Apologies for silence to date on this point; I'm traveling way too much this month. The basic problem statement is hidden in the slide deck I presented at the IESG/IAB meeting in Cancun, attached. We'll want to have a level setting call (most probably early next week) to expand upon this.
>> 
>> Cheers,
>> 
>> Brian
>> 
>> <udp35-cancun.pdf>
>> On 20 May 2014, at 19:54, Jana Iyengar <jri@google.com> wrote:
>> 
>>> Thanks for the update, Spencer; I'll look for the poll. I would like to make travel arrangements soon, and I'm waiting to hear about when the pre-IETF meeting will be held so that I can book accordingly. I'd like to book soon, so I hope to hear about the schedule soon ... but if nothing's been finalized yet, I understand.
>>> 
>>> 
>>> On Mon, May 19, 2014 at 10:13 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>>> 
>>> On 05/13/2014 10:47 AM, Jana Iyengar wrote:
>>> Hello all,
>>> 
>>> I'm writing to learn more about udp35 and the secret cabal meeting that is allegedly happening Saturday evening before the IETF. Can someone post a link or some summary of the goals of this group?
>>> 
>>> Thanks much!
>>> - jana
>>> 
>>> Hi, Jana,
>>> 
>>> If I understood correctly, the plan is that we'll schedule a conference call Real Soon Now to level-set folks, just as soon as someone sends out a doodle poll so we can figure out when :-)
>>> 
>>> So, please stay tuned ...
>>> 
>>> Spencer
>>> 
>>> _______________________________________________
>>> Udp35 mailing list
>>> Udp35@ietf.org
>>> https://www.ietf.org/mailman/listinfo/udp35
>>> 
>>> _______________________________________________
>>> Udp35 mailing list
>>> Udp35@ietf.org
>>> https://www.ietf.org/mailman/listinfo/udp35
>> 
>> _______________________________________________
>> Udp35 mailing list
>> Udp35@ietf.org
>> https://www.ietf.org/mailman/listinfo/udp35
>