Re: [Udp35] Trying to learn about udp35

[Michael Welzl <[e-mail]>]

Hi,

Thanks a lot for your response, I greatly appreciate that!  In line:


On 22. mai 2014, at 00:22, Brian Trammell wrote:

> hi Michael,
> 
> a brief reply now to be followed by a more in-depth one...
> 
> On 21 May 2014, at 19:05, Michael Welzl <[e-mail]> 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.

Sounds good to me!


>> 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.

So this is really the crux of the debate, and the reason why I said "let's please not rinse and repeat":

- at the Bar BOF in Vancouver, we got feedback saying "this shouldn't be one API, in one place. There should only be services defined, and they can then be supported in various ways; anyway people aren't using the socket interface much, anymore"

- then, we incorporated this in the charter ( https://sites.google.com/site/transportprotocolservices/charter-proposal-before-bof ), by writing that we'll specify services, and only *describe* at least one *example* API with one possible implementation.

- because the London BoF was non-WG-forming, the charter wasn't presented; I think this led to some misunderstanding of Gorry's presentation, which showed *one possible implementation* of this - folks took it to mean that this is the only architecture we're proposing, we want to do one single API, and some ended up saying the same things that were already said at the Bar BOF.

So now we're already sitting with this charter that, *before* London, already incorporated much of the feedback that we received in London again. And now you write "not sure that a (single) IETF-defined API is the best way ..."   :-)    => see. That shows me that my "square one" concern was at least not completely unfounded.


>> 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.

Great, thanks!


> 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. 

Okay... indeed that was my thinking - that at least some of the outputs in the TAPS charter should be done anyway, no matter what the bigger plans are. As for a WG slowing things down, I wasn't aware of that being possible but that's just me not knowing as much about IETF internals as (all of) you.

Again, thanks for your response, it does shed some light on things.

Cheers,
Michael