Subject: [Stackevo] the future of the SPUD work

From: Brian Trammell <[email-masked]>
Date: Wed, 20 Apr 2016 07:02:40 +0200

Greetings, all,

Responding to an request from Robert (and others, precisely who I don't recall), here's an update on the state of the SPUD work (my view, as of today) for the members of the program.

Mirja, Joe, and I had a couple of meetings in January and February, and we've tightened up and updated the use cases (draft-kuehlewind-spud-use-cases) and requirements (draft-trammell-spud-req) documents with some help from the other contributors. We also reviewed the requirements in the MAMI project plenaryin early February, which led to some clarifications of the requirements. (see https://mami-project.eu for details on MAMI; tl;dr in an IETF context is "small EU-funded research project to explore HOPS + SPUD from January 2016 through June 2018"). The requirements document, at least, will need one more pass to address comments from Gorry and some further changes that came up in Mirja's last pass over the document, and we intend to submit this before the end of next week.

At that point the requirements and use cases documents will be reasonably complete. Next up is a detailed security model for how to deal with untrusted and, if necessary and useful, partially-trusted middleboxes (i.e., under control of the entity behind of the endpoints).

We've also discussed mechanisms to implement these requirements, which would lead to updates to the prototype document. I'm kind of wary of updating that document, since the prototype was always meant for experimentation (and thought experimentation) with mechanisms to clarify these requirements, which it has IMO done well. But people seem always to refer to the prototype and ignore the requirements, so having a document that is up to date and in line with the requirements seems useful.

Things are lining up, IMO, to transition this work to engineering. Our target at this time is to put together a BoF proposal and draft charter for the specification of an experimental protocol to meet these requirements for Berlin (i.e., documents and charter ready by 3 June).

Thoughts?

Cheers,

Brian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Apr 2016 09:09:48 -0700

Howdy,

A couple of comments in-line.

On Tue, Apr 19, 2016 at 10:02 PM, Brian Trammell <[email-masked]> wrote:

> Greetings, all,
>
> Responding to an request from Robert (and others, precisely who I don't
> recall), here's an update on the state of the SPUD work (my view, as of
> today) for the members of the program.
>
> Mirja, Joe, and I had a couple of meetings in January and February, and
> we've tightened up and updated the use cases
> (draft-kuehlewind-spud-use-cases) and requirements
> (draft-trammell-spud-req) documents with some help from the other
> contributors. We also reviewed the requirements in the MAMI project
> plenaryin early February, which led to some clarifications of the
> requirements. (see https://mami-project.eu for details on MAMI; tl;dr in
> an IETF context is "small EU-funded research project to explore HOPS + SPUD
> from January 2016 through June 2018"). The requirements document, at least,
> will need one more pass to address comments from Gorry and some further
> changes that came up in Mirja's last pass over the document, and we intend
> to submit this before the end of next week.
>
> At that point the requirements and use cases documents will be reasonably
> complete. Next up is a detailed security model for how to deal with
> untrusted and, if necessary and useful, partially-trusted middleboxes
> (i.e., under control of the entity behind of the endpoints).
>
>
I'm interested in contributing to the security model work; are we doing it
on this list, or do you mean the MAMI project will produce it?

> We've also discussed mechanisms to implement these requirements, which
> would lead to updates to the prototype document. I'm kind of wary of
> updating that document, since the prototype was always meant for
> experimentation (and thought experimentation) with mechanisms to clarify
> these requirements, which it has IMO done well. But people seem always to
> refer to the prototype and ignore the requirements, so having a document
> that is up to date and in line with the requirements seems useful.
>

I think a useful output of all of this, perhaps in blog-post form, would be
a rumination on "Using code to explore architectural questions".  There
were a startlingly large number of people who saw commits and assumed that
the approach was done, rather than seeing the code as part of how you
worked out what *ought* to be done.  Given the general utility of trying
things out as part of an exploration, we really need to start pushing the
message that you don't need to be wary of implementation per se.

>
> Things are lining up, IMO, to transition this work to engineering. Our
> target at this time is to put together a BoF proposal and draft charter for
> the specification of an experimental protocol to meet these requirements
> for Berlin (i.e., documents and charter ready by 3 June).
>
> Happy to help out on this as well.

Ted

> Thoughts?
>
> Cheers,
>
> Brian
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 27 Apr 2016 09:57:02 +0200

Hi Ted,

apologies for the delay getting back to this; my latency will be high until June.

briefly, inline:

Sent from my iPhone

> On 20 Apr 2016, at 18:09, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> I'm interested in contributing to the security model work; are we doing it on this list, or do you mean the MAMI project will produce it?

IMO we should do this on the [email-masked] list; the MAMI people who are paying attention this will contribute there as well.

> I think a useful output of all of this, perhaps in blog-post form, would be a rumination on "Using code to explore architectural questions".  There were a startlingly large number of people who saw commits and assumed that the approach was done, rather than seeing the code as part of how you worked out what *ought* to be done.  Given the general utility of trying things out as part of an exploration, we really need to start pushing the message that you don't need to be wary of implementation per se.

Plus many, and I think this should go out on the ietf blog. Will talk to Jari about this.

> Happy to help out on this as well.

Excellent. Mirja and I have blocked off Friday, to work on this, and expect to share a starting point on the stackevo@ list then.

Cheers,

Briab