[Stackevo] Moving forward after the SPUD BoF

[Brian Trammell <[e-mail]>]

Greetings, all,

At this morning's meeting of the partial IAB to discuss the scope of the Programs, we discussed specifically how to organize the work in and around the IP Stack Evolution Program  in order to maintain the momentum coming out of the SPUD BoF, being open to the community (and improving communications on that point), while resolving the great deal of confusion we still see about what SPUD is.

I think we're all on the same page now, and I'd like to propose the following way to move forward:

I'd like to ask the Stack Evolution program to work on a new architectural considerations document addressing our first work item "...for encapsulation-based approaches to work around path transparency issues and to allow explicit cooperation between endpoints and devices on path, while cryptographically protecting information which should remain end-to-end (including transport headers)."

A proposed title: Architectural Considerations for Encapsulations for Transport Evolution with Explicit Path Cooperation (draft-stackevo-explicit-encap)

This document will take its input from draft-trammell-spud-req, draft-kuehlewind-spud-use-cases, draft-hardie-spud-use-cases, and draft-trammell-stackevo-newtea as appropriate; input from related documents that have been sent to the [e-mail] list and related lists (e.g. draft-mihaly-enablers-for-tlp-evolution, which Aaron pointed out is on the tsvarea agenda this time 'round); experience gained from continuing experimentation the SPUD prototype described by draft-hildebrand-spud-prototype (and available at https://github.com/iptube/SPUDlib), as well as from other protocols / prototyping efforts that have some or all of the properties of such an approach (e.g. implementations of draft-huitema-tls-dtls-as-subtransport, QUIC).

This document will not be phrased in terms of requirements; these could be developed from these principles and considerations at the point at which it is obvious that there is engineering to do, as input to a WG-forming BoF. This document will progress forward within the Stack Evolution program with an intention to publish it on the IAB stream. It uses the acronym SPUD to refer to the history of the BoF and the SPUDlib prototype, when appropriate.

I'd like to ask those of us who have been working on the SPUD requirements effort, as well as any other interested people within the Program, to help to take the present documents plus the output of our meeting on Saturday into this new document. I'm willing to hold the editor's pen on this unless anyone else would like to volunteer. From here we'd like to continue the work of determining whether there is any protocol work to do in the IETF on this subject, and/or whether there is a potential IRTF RG in this work.

In addition, we have created a new, open [e-mail] mailing list to discuss this document and work surrounding it (including with the prototypes), as well as individual documents related to its scope or other work of the program. We'll announce this to [e-mail].

Does this seem like a good way forward to the Program?

Many thanks, cheers,

Brian (stackevo lead hat)