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

[Brian Trammell <[e-mail]>]

hi Spencer, all,

a quick response to one point, inline; more later...

On 26 May 2014, at 18:55, Spencer Dawkins <[e-mail]> wrote:

>>> My understanding on how and why the
>>> group meets would depends on understanding more of this thread.
>> The intention of the meeting on Saturday is more or less to continue the discussion we're having right now, in person, in front of a whiteboard; the format is "by-invitation brainstorming session" as opposed to an IAB workshop, for example, mainly because the whiteboard's there, and larger workshops are less productive per unit time.
> 
> On openness ... nothing we've talked about is a secret from the community.

Indeed, the list archives are also open.

> We created this mailing list because we had enough person-to-person e-mail flying around about next steps that we needed one, but this isn't a cabal. The IETF doesn't do that, except in places like Nomcom.
> 
> The IAB actually can restrict participation - open IAB workshop calls for participation/papers are a relatively recent innovation. So I'm hoping the IAB does consider this to be a workshop, but of course I don't control that ("please do the right thing").

We're calling the Saturday evening thing a "side meeting" as opposed to a "workshop", as there was no call for position papers or vetting thereof, rather invitation sent to people we figured would have something to say, given where we think the problem lies (if you're on this list, you're invited, apologies if that's not been clear). 

To elaborate on what I said in my previous message: the _sole_ reason for doing it this way as opposed to with an open call is to limit the _number_ rather than the _set_ of people in the room, because we know what we have is kind of a vague and uncooked idea, and we would like a chance to talk it over with a small group of knowledgable people who've thought a lot about the space before taking it to the wider community. As we're seeing in this thread, there's a _whole lot_ of overlap with TAPS, and a few ideas we think are architecturally related but which don't quite fit, and we'd like to figure out the best way to get everything that needs to get done to address this problem done.

Cheers,

Brian