Re: [Stackevo] Updated description for stack evolution program

I'd suggest that it'd be better to get the IETF to do it than for the IAB program to do it.

-Dave (chair of the now-closed BEHAVE WG)

-----Original Message-----
From: Stackevo [mailto:stackevo-bounces@iab.org] On Behalf Of Brian Trammell
Sent: Wednesday, July 8, 2015 6:28 AM
To: Aaron Falk
Cc: Stackevo; IAB Board
Subject: Re: [Stackevo] Updated description for stack evolution program

hi Aaron,

Sorry it's taken a bit for me to get back to you on this one...

> On 26 Jun 2015, at 22:24, Aaron Falk <aaron.falk@gmail.com> wrote:
> 
> Hey Brian-
> 
> I've just been reading draft-iab-semi-report-00 and the new StackEvo webpage.  The report suggests followon work of giving advice to middlebox implementors but there appears to be no mention of it in the StackEvo description.  Did this get lost on the cutting room floor? Or was it a deliberate omission?

This got lost on the cutting room floor. I'd suggest adding the following text to the current work list, between (5) and (6):

(6) Development of guidelines for middlebox implementation, implementation, and deployment in order to reduce inadvertent or accidental impact on stack ossification in existing and new middlebox designs. This work will draw in part on the work of the BEHAVE working group, and on experience with STUN, TURN, and ICE, but will be generalized to apply to middlebox applications other than network address translation.

I would suggest adding this to the list at the same time that we add more text to (5).

Thoughts?

Thanks, cheers,

Brian

> 
> 6.3. Guidelines for middlebox design and deployment
> 
> The workshop identified the potential to update [RFC3234] to provide guidelines on middlebox design, implementation, and deployment in order to reduce inadvertent or accidental impact on stack ossification in existing and new middlebox designs. This document will be produced by the IAB IP Stack Evolution program, drawing in part on the work of the BEHAVE working group, and on experience with STUN, TURN, and ICE, all of which focus more specifically on network address translation.
> 
> 
> --aaron
> 
> On Thu, Jun 11, 2015 at 3:43 PM, Brian Trammell <ietf@trammell.ch> wrote:
> Greetings, all,
> 
> One more pass, reflecting comments from yesterday, adding 7305 and 
> including a placeholder for text we don't have yet: new reference 5 to 
> work on stacks on constrained devices (also discussed at the London 
> retreat, thanks Ralph for reminding me of this, and thanks in advance 
> for providing said text ;) )
> 
> Once we have this, I think we're done. Thanks, everyone!
> 
> Cheers,
> 
> Brian
> 
> Description
> 
> The IP Stack Evolution program covers various topics in the evolution of IPv4 and IPv6, the transport protocols running over IP, and the overall protocol stack architecture. The program addresses challenges that affect the stack in some way and where the IETF community requires architectural guidance, responding to community requests as well as actively monitoring work within IETF WGs which touch on relevant topics.
> 
> There is an observed trend of functionality moving “up the stack”: where the “waist” was once IP, now most applications run over TCP/IP, or even HTTP/TCP/IP; the stack has become increasingly ossified. This is in response both to reduced path transparency within the Internet — middleboxes that limit the protocols of the traffic that can pass through them — as well as insufficiently flexible interfaces for platform and application developers. The emergence of both new application requirements demanding more flexibility from the stack, especially at layer 4, as well as the increasing ubiquity of encryption to protect against pervasive surveillance, provides an opportunity to re-evaluate and reverse this trend.
> 
> This program aims to provide architectural guidance, and a point of coordination for work at the architectural level to improve the present situation of ossification in the Internet protocol stack. Where a working group relevant to a particular aspect of IP stack evolution exists, the program will facilitate cross-group and cross-area coordination. The program also produces documents on the IAB stream providing general guidance on and covering architectural aspects of stack evolution.
> 
> Current active work in the program includes:
> 
> (1) Definition of requirements and principles 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). This work follows discussions at the IAB SEMI (Stack Evolution in a Middlebox Internet) workshop and the SPUD (Substrate Protocol for User Datagrams) BoF at IETF 92 in Dallas. Discussion of this work occurs on the SPUD mailing list: spud@ietf.org.
> 
> (2) Evolution of interfaces to transport and network-layer services: improving the access of applications to the specific transport services they need (e.g. reliability, latency guarantees, congestion control properties, message boundary and order preservation, etc.) beyond the traditional SOCK_STREAM and SOCK_DGRAM interfaces. Further architectural work in this space awaits the results of related engineering being done in the IETF TAPS Working Group (mailing list: taps@ietf.org), the activities of which the program monitors.
> 
> (3) Discussion of principles for making new protocols within the IP stack deployable, following in part on RFC 5218 "What Makes for a Successful Protocol".
> 
> (4) Definition of principles for the use of encapsulation at various layers within the protocol stack. UDP-based encapsulations are not only useful for evolution above the IP layer, but in many tunneling contexts as well. The probable commonalities among all these applications of encapsulation might be useful in simplifying their implementation, deployment, and use.
> 
> (5) Architectural guidance on the creation of new protocol stacks for constrained devices [Erik and Ralph to provide text to flesh this out].
> 
> (6) Architectural guidance for stack evolution should be informed by 
> empirical evidence where possible and appropriate, so the program 
> encourages efforts to collect, disseminate, and analyze data 
> pertaining to the present state of the Internet with respect to its 
> other activities. Work here currently focuses on the potential 
> establishment of an IRTF research group to coordinate measurement of 
> path transparency issues caused by middleboxes, following on the HOPS 
> ("How Ossified is the Protocol Stack") Bar BoF at IETF 92 in Dallas. 
> Discussion of this work occurs on the HOPS mailing list: hops@ietf.org
> 
> (7) Architectural guidance on traffic filtering and blocking, to result in the publication of draft-iab-filtering-considerations.
> 
> 
> This program has itself evolved from the IP Evolution Program, which looked at general architectural issues in the evolution of IPv4 and IPv6 and the overall protocol stack architecture, and produced the following documents:
> 
> IAB Thoughts on IPv6 Network Address Translation (RFC 5902) Evolution 
> of the IP Model (RFC 6250) Smart Objects Workshop Report (RFC 6574) 
> Architectural Considerations of IP Anycast (RFC 7094) Report from the 
> IAB Workshop on Internet Technology Adoption and Transition (ITAT) 
> (RFC 7305)
> 
> 
> 
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo
> 
> 
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo