Subject: [Stackevo] Moving forward after the SPUD BoF

From: Brian Trammell <[email-masked]>
Date: Mon, 20 Jul 2015 23:57:42 +0200

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 [email-masked] 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 [email-masked] 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 [email-masked].

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

Many thanks, cheers,

Brian (stackevo lead hat)

---

From: Aaron Falk <[email-masked]>
Date: Tue, 21 Jul 2015 15:39:04 +0200

I like this approach, although the new doc title is a bit clunky.  I think
it will be important to keep an eye on the work and if it seems researchy,
meaning we are coming up with more questions than answers, it might be time
to move it to a research group.  In conversation you've said that HOPS-RG
may be the place for this but if that is your plan, HOPS may not be the
best name.

--aaron

On Mon, Jul 20, 2015 at 11:57 PM, Brian Trammell <[email-masked]> wrote:

> 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'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 [email-masked] 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 [email-masked] 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 [email-masked].
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Jul 2015 13:49:44 +0200

> On 21 Jul 2015, at 15:39, Aaron Falk <[email-masked]> wrote:
> 
> I like this approach, although the new doc title is a bit clunky.

Thanks. Agreed. Have you got suggestions that are less clunky while being equally (or better, more) accurate?

> I think it will be important to keep an eye on the work and if it seems researchy, meaning we are coming up with more questions than answers, it might be time to move it to a research group.  In conversation you've said that HOPS-RG may be the place for this but if that is your plan, HOPS may not be the best name.

If the next question from HOPS is "how do we work around this" as opposed to "how do we hunt the middleboxes down and melt them to slag", then maybe.

Thanks, cheers,

Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Jul 2015 13:54:38 +0200

Hi Brian,

Just one single comment.

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

Encapsulation is the wrong word.  If we were to use it in this context
then we must consider TCP an encapsulation.  And this is true with any
layered approach.  We are not even sure if we have an instantiated layer
on the wire here at all.  And so from a title perspective I would just
drop "for Encapsulations"..

Eliot

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Jul 2015 14:19:40 +0200

hi Eliot,

> On 22 Jul 2015, at 13:54, Eliot Lear <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Just one single comment.
> 

That makes sense.

Thanks, cheers,

Brian

---

From: Aaron Falk <[email-masked]>
Date: Wed, 22 Jul 2015 14:33:54 +0200

> > drop "for Encapsulations"..

+1