Re: [Stackevo] Next steps post-SPUD BoF

[Brian Trammell <[e-mail]>]

Sent from my iPhone

> On 17 Apr 2015, at 12:56, Michael Welzl <[e-mail]> wrote:
> 
> 
>> On 17 Apr 2015, at 11:43, Brian Trammell <[e-mail]> wrote:
>> 
>> hi Michael,
>> 
>> sorry for the delay here, just realized a week had gone by...
>> 
>>>> On 10 Apr 2015, at 15:48, Michael Welzl <[e-mail]> wrote:
>>>> 
>>>> 
>>>> On 10 Apr 2015, at 15:28, Brian Trammell <[e-mail]> wrote:
>>>> 
>>>> Greetings, all,
>>>> 
>>>> First, I'd like to welcome Robert Sparks, Spencer Dawkins, Aaron Falk, and David Black to the IP Stack Evolution program!
>>>> 
>>>> Following a call between the SPUD BoF chairs and proponents earlier this week, it seems to us that moving toward forming a working group is not appropriate at this time. We're not doing engineering yet, and even forming a smallish WG to publish an experimental prototype protocol RFC would merely serve to reinforce the community's uneasiness expressed during the BoF about draft-hildebrand-spud-prototype becoming The Production SPUD Protocol with very little modification.
>>>> 
>>>> We have the beginnings of a set of research questions, mainly focusing on which information to selectively expose and incentives to do so, but there's not an RG charter there yet. (Indeed, in trying to figure out what of SPUD or SPUD-adjacent work *should* have a RG chartered around them, after a five minute conversation on IETF Friday afternoon, Mirja, Gorry, and I came up with "HOPS should be an RG." But that's a different thread.)
>>>> 
>>>> In short, we're still doing architecture, so the most appropriate home for this work right now is the IAB, and this program. Since the community is engaged in discussion on UDP encapsulation and middlebox cooperation on the [e-mail] list, we'll keep that discussion going, as well as discussion about experimentation with the SPUDlib prototype.
>>>> 
>>>> I have a document, draft-trammell-stackevo-newtea, which I'd like to see evolve into a set of architectural guidelines for encapsulations for transport evolution, following list discussion... this might be more appropriately named draft-xxx-spud-arch, since it what it really aims to talk about is "architecture for encapsulations that look like SPUD."  Also, following the example of the privsec program, I'd also like to select a "show runner" for the SPUD focus area; at this point, mainly to keep an eye on the list and to identify / find authors for anything we think might need to be a document coming out of that discussion.
>>>> 
>>>> Thoughts?
>>> 
>>> I like the idea of an RG a lot - not only HOPS but really also SPUD, because of the use cases. I haven't seen much convincing stuff there (in the "trust-but-verify" direction, I mean) and I think it can be done, and a RG seems to me to be a good basis for that?!
>> 
>> So the idea would be specifically to separate *what* to express in selective exposure approaches -- as opposed to any of the questions as to *how* -- and to work on this problem within an RG? Yeah, that's a good idea, though I'm not sure how separable the discussions will stay in practice, and I still think we'll need an experimental environment to play with these things.
> 
> Yes, but even more "what to do with it" than just "what to express".

Ah. Yep, that makes even more sense.

> I think we have plenty of not-so-great research based on expressing all kinds of things for the sake of transports and using them in unconvincing ways...  e.g. all the TCP-over-wireless stuff...  about time to try to clean this up and see which convincing ways could be made?
> 
>> (Would you be willing to help with draft RG charter language for such a group? ;) )
> 
> Yes, if we're talking relaxed deadlines here...  then of course the larger amount of work is to get a community to be active around this.

The easiest way to get this started is as a conversation on the spud list. There's lots of energy there from people who have problems they think spud might help solve, as well as from people who see problems that spud may cause that they would like to avoid. Put all that together and you kind of get the shape of the space of investigation... Turning those wish lists into a research plan is a bit harder, though, and we need to make a distinction between engineering requirements and open research questions...

> Just because I say I think it could make sense doesn't mean I'm sure we'll get that community, or that I'm willing to send dozens of emails around to make that happen  (e.g. consider the work Arjuna is doing for GAIA - great success but maaaaaany cycles...)

Ack. I hope this is more a matter of directing and drawing productive boxes around work already being done, though...

Cheers,

Brian