Re: [Udp35] TAPS BOF and moving the transport API forward

Michael Welzl <michawe@ifi.uio.no> Mon, 26 May 2014 09:51 UTC

Return-Path: <michawe@ifi.uio.no>
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 D83A61A00B0 for <udp35@ietfa.amsl.com>; Mon, 26 May 2014 02:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 39ZTd7sV1UlG for <udp35@ietfa.amsl.com>; Mon, 26 May 2014 02:51:00 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AA71A00A3 for <udp35@ietf.org>; Mon, 26 May 2014 02:51:00 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1WorYU-0008Gh-Ek; Mon, 26 May 2014 11:50:54 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1WorYT-00024o-Qj; Mon, 26 May 2014 11:50:54 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <64EA69DB-0643-4485-84B6-7440533878E2@trammell.ch>
Date: Mon, 26 May 2014 11:50:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D804CF7-E124-4B99-862E-6010F48FFB71@ifi.uio.no>
References: <537B6932.9050809@erg.abdn.ac.uk> <537BA5CF.4000602@gmail.com> <2f67fd4139a3a40a2df96f1e7db57a95.squirrel@www.erg.abdn.ac.uk> <537DD281.5030408@gmail.com> <A8BF265F-DAEB-426C-9616-0A60AAD6A35F@ifi.uio.no> <966E90E6-5DD3-4897-8891-9ABBB3203274@trammell.ch> <AF068429-8094-4558-9038-A443377B02DD@ifi.uio.no> <8EC8A658-5FA9-464B-8B09-6D3A94222B13@trammell.ch> <6B4A2FF8-E4BA-4355-B792-F99D8970D9C8@ifi.uio.no> <A2BE43E7-5635-4CA2-9F3A-9CEFD277F283@ifi.uio.no> <64EA69DB-0643-4485-84B6-7440533878E2@trammell.ch>
To: Brian Trammell <ietf@trammell.ch>
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 20 sum msgs/h 9 total rcpts 16738 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 2E4B077ADA67BFAD8C9FC0138DC10201361C8EE9
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 5458 max/h 16 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/udp35/1kNpMa06a4p4K3umGX07HqRa1-I
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Martin Stiemerling <mls.ietf@gmail.com>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, udp35@ietf.org
Subject: Re: [Udp35] TAPS BOF and moving the transport API forward
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: Mon, 26 May 2014 09:51:03 -0000

On 26. mai 2014, at 11:00, Brian Trammell wrote:

> hi Michael, all,
> 
> On 26 May 2014, at 10:03, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
>> ... so, now:
>> 
>> 1) we agree that a few things need to be done ASAP no matter what (define the "supply side")
>> 2) we may have to refine our views a little bit about what needs to be done immediately
>> 
>> - and this should not be done as an update to the TAPS charter, leading to a WG-forming TAPS BoF in Toronto, because... ?
> 
> ...since the responsible ADs are the ones who make the decision here, if their opinion differs from mine, what they say goes; but...
> 
> ...because IMO (1) it's not clear that having a TAPS WG in the TSV area would give us the best combination of efficiency and wider participation from the communities (represented by RAI and APP) that would use it, (2) I'm afraid we'd have the same derails we had in London which would take cycles away from work we already have a pretty clear boundary drawn around, (3) there are _clearly_ things outside the scope of TAPS that are nonetheless related (essentially anything under the "signaling" heading, which itself seems split into two things) s.t. we need more understanding about those relationships, and (4) the current scope of agreement is a single document (albeit a somewhat large and quite important one), which would appear to me to draw heavily on the present draft-monpetit-* (unless the current group had something else in mind), for which WG formation seems kind of a heavyweight process.

Even if we limit this to the easy to agree on supply-side-only, I think we're talking about more than one document:
- what services should be offered?
- how to implement a system providing them (happy eyeballing etc.)?
- as part of "how to implement", signaling to make sure both sides know what's going on (you suggested it, fine by me)


> Indeed, for a TAPS WG we'd need to find two non-author co-chairs, who would have to work pretty hard to avoid a derail on the API issue at a Toronto BoF, and keep the charter that comes out of the BoF focused enough that all the new contributions you'd get would further the current work on this document. My reticence here comes from a suspicion that this will be hard to do.
> 
> I don't see how "not creating a working group" equates with "delaying the work"; indeed, you've already got a mailing list, a core team of contributors, documents in pretty good shape, etc.; i.e. you've already pretty much built a working group. Now, if there is some (political) reason that the work needs to be seen as being done within a WG in the IETF, let's talk about that. But otherwise it seems to me we could publish this one document on the IAB stream as a product of the (soon-to-be-renamed TCP/)IP Evolution program in the IAB with somewhat less overhead, and use this (more architectural) document after publication as background for engineering work done in (a) future WG(s).

So this is the bit that concerns me. See my recent email to Spencer / the udp35 list: first and foremost I think it's going to be a problem to motivate folks (in particular, academics) to get active when it's not a WG, as a WG is seen as a sign of willingness on behalf of the IETF to do something in this space.

My thinking is mostly guided by:
- when can I give an update to the TAPS mailing list?  (because I think that's what everyone's waiting for)
- what do I tell them?
- how will they react?

I just don't feel very good about sending them a message that says: "A decision has been made. There is lots of interest, yet at this time a WG doesn't seem to be most constructive - the IAB wants us to go ahead as we are, to document the "supply side" of things and write 1-2 RFCs via the IAB stream". I can try that if that's really the best option, I'm just raising a concern.


>> Don't get me wrong, I understand the need for the meeting on Saturday in Toronto, indeed there are more things that we should try to agree on, but since we already agree (to some level of detail) what TAPS should be doing, why do we delay it?
> 
> I'm not at all adamant about this; if there's wider agreement now that the "dimensions-of-transport" work is probably best done in a TSV area working group, we could also parallelize this: put together a smaller charter as a starting point for a Toronto WG-forming BoF to which the outcome of Saturday's discussions could be input.

That would sound good to me, based on the above;


> (But on that point I defer to the responsible ADs. :) )

Me too...  I just asked, but I'll shut up now  :)

Cheers,
Michael