Re: [Stackevo] Moving forward after the SPUD BoF

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 <ietf@trammell.ch> 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 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 spud@ietf.org 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 stackevo-discuss@iab.org 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 spud@ietf.org.
>
> Does this seem like a good way forward to the Program?
>
> Many thanks, cheers,
>
> Brian (stackevo lead hat)
>
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo
>
>