GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7663

Internet Architecture Board (IAB) B. Trammell, Ed. Request for Comments: 7663 M. Kuehlewind, Ed. Category: Informational ETH Zurich ISSN: 2070-1721 October 2015

                    Report from the IAB Workshop
         on Stack Evolution in a Middlebox Internet (SEMI)

Abstract

 The Internet Architecture Board (IAB) through its IP Stack Evolution
 program, the Internet Society, and the Swiss Federal Institute of
 Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox
 Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore
 the ability to evolve the transport layer in the presence of
 middlebox- and interface-related ossification of the stack.  The goal
 of the workshop was to produce architectural and engineering guidance
 on future work to break the logjam, focusing on incrementally
 deployable approaches with clear incentives to deployment both on the
 endpoints (in new transport layers and applications) as well as on
 middleboxes (run by network operators).  This document summarizes the
 contributions to the workshop and provides an overview of the
 discussion at the workshop, as well as the outcomes and next steps
 identified by the workshop.  The views and positions documented in
 this report are those of the workshop participants and do not
 necessarily reflect IAB views and positions.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Architecture Board (IAB)
 and represents information that the IAB has deemed valuable to
 provide for permanent record.  It represents the consensus of the
 Internet Architecture Board (IAB).  Documents approved for
 publication by the IAB are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7663.

Trammell & Kuehlewind Informational [Page 1] RFC 7663 SEMI Workshop October 2015

Copyright Notice

 Copyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.1.  Organization of This Report . . . . . . . . . . . . . . .   4
 2.  The Situation in Review . . . . . . . . . . . . . . . . . . .   4
 3.  Incentives for Stack Ossification and Evolution . . . . . . .   5
 4.  The Role and Rule of Middleboxes  . . . . . . . . . . . . . .   6
 5.  Evolving the Transport Layer  . . . . . . . . . . . . . . . .   6
 6.  Outcomes  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.1.  Minimal Signaling for Encapsulated Transports . . . . . .   7
   6.2.  Middlebox Measurement . . . . . . . . . . . . . . . . . .   8
   6.3.  Guidelines for Middlebox Design and Deployment  . . . . .   9
   6.4.  Architectural Guidelines for Transport Stack Evolution  .   9
   6.5.  Additional Activities in the IETF and IAB . . . . . . . .  10
   6.6.  Additional Activities in Other Venues . . . . . . . . . .  10
 7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
 8.  Informative References  . . . . . . . . . . . . . . . . . . .  10
 Appendix A.  Attendees  . . . . . . . . . . . . . . . . . . . . .  13
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Trammell & Kuehlewind Informational [Page 2] RFC 7663 SEMI Workshop October 2015

1. Introduction

 The transport layer of the Internet has become ossified, squeezed
 between narrow interfaces (from BSD sockets to pseudo-transport over
 HTTPS) and increasing in-network modification of traffic by
 middleboxes that make assumptions about the protocols running through
 them.  This ossification makes it difficult to innovate in the
 transport layer, through the deployment of new protocols or the
 extension of existing ones.  At the same time, emerging applications
 require functionality that existing protocols can provide only
 inefficiently, if at all.
 To begin to address this problem, the IAB, within the scope of its IP
 Stack Evolution Program, organized a workshop to discuss approaches
 to de-ossify transport, especially with respect to interactions with
 middleboxes and new methods for implementing transport protocols.
 Recognizing that the end-to-end principle has long been compromised,
 we start with the fundamental question of matching paths through the
 Internet with certain characteristics to application and transport
 requirements.
 We posed the following questions in the call for papers: Which paths
 through the Internet are actually available to applications?  Which
 transports can be used over these paths?  How can applications
 cooperate with network elements to improve path establishment and
 discovery?  Can common transport functionality and standardization
 help application developers to implement and deploy such approaches
 in today's Internet?  Could cooperative approaches give us a way to
 rebalance the Internet back toward its end-to-end roots?
 The call for papers encouraged a focus on approaches that are
 incrementally deployable within the present Internet.  Identified
 topics included the following:
 o  Development and deployment of transport-like features in
    application-layer protocols
 o  Methods for discovery of path characteristics and protocol
    availability along a path
 o  Methods for middlebox detection and characterization of middlebox
    behavior and functionality
 o  Methods for NAT and middlebox traversal in the establishment of
    end-to-end paths
 o  Mechanisms for cooperative path-endpoint signaling, and lessons
    learned from existing approaches

Trammell & Kuehlewind Informational [Page 3] RFC 7663 SEMI Workshop October 2015

 o  Economic considerations and incentives for cooperation in
    middlebox deployment
 The Internet Architecture Board (IAB) holds occasional workshops
 designed to consider long-term issues and strategies for the
 Internet, and to suggest future directions for the Internet
 architecture.  This long-term planning function of the IAB is
 complementary to the ongoing engineering efforts performed by working
 groups of the Internet Engineering Task Force (IETF), under the
 leadership of the Internet Engineering Steering Group (IESG) and area
 directorates.
 The SEMI workshop followed in part from the IAB's longer term
 interest in the evolution of the Internet and the adoption of
 Internet protocols, including the Internet Technology Adoption and
 Transition workshop [RFC7305], "What Makes for a Successful Protocol"
 [RFC5218], back to Deering's plenary talk [deering-plenary] at IETF
 51 in 2001.

1.1. Organization of This Report

 This workshop report summarizes the contributions to, and discussions
 at the workshop, organized by topic.  We started with a summary of
 the current situation with respect to stack ossification, and
 explored the incentives that have made it that way and the role of
 incentives in evolution.  Many contributions were broadly split into
 two areas: middlebox measurement, classification, and approaches to
 defense against middlebox modification of packets; and approaches to
 support transport evolution.  All accepted position papers and
 detailed transcripts of discussion are available at
 https://www.iab.org/activities/workshops/semi/.
 The outcomes of the workshop are discussed in Section 6, including
 progress after the workshop toward each of the identified work items
 as of the time of publication of this report.

2. The Situation in Review

 At the time of Deering's talk in 2001, network address translation
 (NAT) was identified as the key challenge to the Internet
 architecture.  Since then, the NAT traversal problem has been largely
 solved, but the boxes in the middle are getting smarter and more
 varied.
 SEMI, as the IP Stack Evolution program in general, is far from the
 first attempt to solve the problems caused by middlebox interference
 in the end-to-end model.  Just within the IETF, the MIDCOM, NSIS, and

Trammell & Kuehlewind Informational [Page 4] RFC 7663 SEMI Workshop October 2015

 BEHAVE efforts have addressed this problem, and the TRAM working
 group is updating the NAT traversal outcomes of MIDCOM to reflect
 current reality.
 We believe we have an opportunity to improve the situation in the
 present, however, due to a convergence of forces.  While the tussle
 between security and middleboxes is not new, the accelerating
 deployment of cryptography for integrity and confidentiality makes
 many packet inspection and packet modification operations obsolete,
 creating pressure to improve the situation.  There is also new energy
 in the IETF around work that requires transport-layer flexibility
 we're not sure we have (e.g., WebRTC) as well as flexibility at the
 transport interface (TAPS).

3. Incentives for Stack Ossification and Evolution

 The current situation is, of course, the result of a variety of
 processes, and the convergence of incentives for network operators,
 content providers, network equipment vendors, application developers,
 operating system developers, and end users.  Moore's Law makes it
 easier to deploy more processing on-path, network operators need to
 find ways to add value, enterprises find it more scalable to deploy
 functionality in-network than on endpoints, and middleboxes are
 something vendors can vend.  These trends increase ossification of
 the network stack.
 Any effort to reduce the resulting ossification in order to make it
 easier to evolve the transport stack, then, must consider the
 incentives to deployment of new approaches by each of these actors.
 As Christian Huitema [huitema-semi] pointed out, encryption provides
 a powerful incentive here: putting a transport protocol atop a
 cryptographic protocol atop UDP resets the transport versus middlebox
 tussle by making inspection and modification above the encryption and
 demux layer impossible.  Any transport evolution strategy using this
 approach must also deliver better performance or functionality (e.g.,
 setup latency) than existing approaches while being as deployable as
 these approaches, or moreso.
 Indeed, significant positive net value at each organization where
 change is required -- operators, application developers, equipment
 vendors, enterprise and private users -- is best to drive deployment
 of a new protocol, said Dave Thaler, pointing to [RFC5218].  All
 tussles in networking stem from conflicting incentives unavoidable in
 a free market.  For upper-layer protocols, incentives tend to favor
 protocols that work anywhere, use the most efficient mechanism that
 works, and are as simple as possible from an implementation,
 maintenance, and management standpoint.  For lower-layer protocols,

Trammell & Kuehlewind Informational [Page 5] RFC 7663 SEMI Workshop October 2015

 incentives tend toward ignoring and or disabling optional features,
 as there is a positive feedback cycle between being rarely used and
 rarely implemented.

4. The Role and Rule of Middleboxes

 Middleboxes are commonplace in the Internet and constrain the ability
 to deploy new protocols and protocol extensions.  Engineering around
 this problem requires a "bestiary" of middleboxes, a classification
 of which kinds of impairments middleboxes cause and how often,
 according to Benoit Donnet [edeline-semi].
 Even though the trend towards Network Function Visualization (NFV)
 allows for faster update-cycle of middleboxes and thereby more
 flexibility, the function provided by middleboxes will stay.  In
 fact, service chaining may lead to more and more add-ons to address
 and manage problems in the network, in turn further increasing the
 complexity of network management.  Ted Hardie [hardie-semi] warned
 that each instance may add a new queue and may increase the
 bufferbloat problem that is counterproductive for new emerging
 latency-sensitive applications.  However, this new flexibility also
 provides a chance to move functionality back to the end host.
 Alternately, more appropriate in-network functionality could benefit
 from additional information in application and path characteristics,
 though this in turn implies a variety of complicated trust
 relationships among nodes in the network.  In any case, an increasing
 trend of in-network functionality can be observed, especially in
 mobile networks.
 Costin Raiciu [raiciu-semi] stated that middleboxes make the Internet
 unpredictable, leading to a trade-off between efficiency and
 reachability.  While constructive cooperation with middleboxes to
 establish a clear contract between the network and the endpoint might
 be one approach to address this challenge, enforcement of contract in
 less cooperative environments might require extensive tunneling.
 Raiciu's contribution on "ninja tunneling" illustrates one such
 approach.

5. Evolving the Transport Layer

 For evolution in the transport layer itself, various proposals have
 been discussed, reaching from the development of new protocols
 (potentially as user-level stacks) encapsulated in UDP as a transport
 identification sub-header to the use of TCP as a substrate where the
 semantics of TCP are relaxed (e.g., regarding reliability, ordering,
 flow control, etc.) and a more flexible API is provided to the
 application.

Trammell & Kuehlewind Informational [Page 6] RFC 7663 SEMI Workshop October 2015

 Discussion on evolution during the workshop divided amicably along
 two lines: working to fix the deployability of TCP extensions
 (referred to in discussion as "the TCP Liberation Front") versus
 working to build new encapsulation-based mechanisms to allow wholly
 new protocols to be deployed (referred to in discussion as "the
 People's Front of UDP").  David Black [black-semi] pointed out that
 UDP encapsulation has to be adapted and separately discussed for
 every use case, which can be a long and painful process.  UDP
 encapsulation can be an approach to develop more specialized
 protocols that helps to address special needs of certain
 applications.  However, Stuart Cheshire [cheshire-semi] (as presented
 by Brian Trammell) pointed out that designing a new protocol instead
 of fixing/extending TCP might not always solve the problem.
 To address the extensibility problem of TCP, Bob Briscoe proposed
 Inner Space [briscoe-semi].  Here, the general principle is to extend
 layer X's header within layer X+1; in the case of TCP, additional TCP
 header and option space is provided within the TCP payload, such that
 it cannot presently be inspected and modified by middleboxes.
 Further, instead of only focusing on those cases where new extensions
 and protocols are not deployable, Micheal Welzl [welzl-semi] points
 out that there are also a lot of paths in the network that are not
 ossified.  To enable deployment on these paths, an end host would
 need to probe or use a happy-eyeball-like approach [RFC6555] and
 potentially fallback.  The TAPS working group implements the first
 step to decouple applications from transport protocols allowing for
 the needed flexibility in the transport layer.

6. Outcomes

 The SEMI workshop identified several areas for further work, outlined
 below.

6.1. Minimal Signaling for Encapsulated Transports

 Assuming that a way forward for transport evolution in user space
 would involve encapsulation in UDP datagrams, the workshop identified
 that it may be useful to have a facility built atop UDP to provide
 minimal signaling of the semantics of a flow that would otherwise be
 available in TCP: at the very least, indications of first and last
 packets in a flow to assist firewalls and NATs in policy decision and
 state maintenance.  This facility could also provide minimal
 application-to-path and path-to-application signaling, though there
 was less agreement on exactly what should or could be signaled here.

Trammell & Kuehlewind Informational [Page 7] RFC 7663 SEMI Workshop October 2015

 The workshop did note that, given the increasing deployment of
 encryption in the Internet, this facility should cooperate with
 Datagram Transport Layer Security (DTLS) [RFC6347] in order to
 selectively expose information about traffic flows where the
 transport headers and payload themselves are encrypted.
 To develop this concept further, it was decided to propose a BoF
 session that would not form a working group, SPUD (Substrate Protocol
 for User Datagrams), at the IETF 92 meeting in March in Dallas.  A
 document on use cases [SPUD-USE], a prototype specification for a
 shim protocol over UDP [SPUD-PROTO], and a separate specification of
 the use of DTLS as a subtransport layer [TLS-DTLS] were prepared
 following discussions at SEMI and presented at the BoF.
 Clear from discussion before and during the SPUD BoF, and drawing on
 experience with previous endpoint-to-middle and middle-to-endpoint
 signaling approaches, is that any selective exposure of traffic
 metadata outside a relatively restricted trust domain must be
 declarative as opposed to imperative, non-negotiated, and advisory.
 Each exposed parameter should also be independently verifiable, so
 that each entity can assign its own trust to other entities.  Basic
 transport over the substrate must continue working even if signaling
 is ignored or stripped, to support incremental deployment.  These
 restrictions on vocabulary are discussed further in [EXP-COOP].
 There was much interest in the room in continuing work on an approach
 like the one under discussion.  It was relatively clear that the
 state of the discussion and prototyping activity now is not yet
 mature enough for standardization within an IETF working group.  An
 appropriate venue for continuing the work remains unclear.
 Discussion continues on the spud mailing list (spud@ietf.org).  The
 UDP shim layer prototype is described by [SPUD-PROTO].

6.2. Middlebox Measurement

 Discussion about the impairments caused by middleboxes quickly
 identified the need to get more and better data about how prevalent
 certain types of impairments are in the network.  It doesn't make
 much sense, for instance, to engineer complex workarounds for certain
 types of impairments into transport protocols if those impairments
 are relatively rare.  There are dedicated measurement studies for
 certain types of impairment, but the workshop noted that prevalence
 data might be available from error logs from TCP stacks and
 applications on both clients and servers: these entities are in a
 position to know when attempts to use particular transport features
 failed, providing an opportunity to measure the network as a side
 effect of using it.  Many clients already have a feature for sending

Trammell & Kuehlewind Informational [Page 8] RFC 7663 SEMI Workshop October 2015

 these bug reports back to their developers.  These present
 opportunities to bring data to bear on discussion and decisions about
 protocol engineering in an Internet full of middleboxes.
 The HOPS (How Ossified is the Protocol Stack) informal birds of a
 feather session ("Bar BoF") was held at the IETF 92 meeting in
 Dallas, to discuss approaches to get aggregated data from these logs
 about potential middlebox impairment, focusing on common data formats
 and issues of preserving end-user privacy.  While some discussion
 focused on aggregating impairment observations at the network level,
 initial work will focus on making relative prevalence information
 available on an Internet-wide scope.  The first activity identified
 has been to match the types of data required to answer questions
 relevant to protocol engineering to the data that currently is or can
 easily be collected.
 A mailing list (hops@ietf.org) has been established to continue
 discussion.

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.  The IAB Stack
 Evolution Program will follow up on this with the participants in the
 now-closed BEHAVE working group, as it most closely follows the work
 of that group.  It will draw 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.

6.4. Architectural Guidelines for Transport Stack Evolution

 The workshop identified the need for architectural guidance in
 general for transport stack evolution: tradeoffs between user- and
 kernel-space implementations, tradeoffs in and considerations for
 encapsulations (especially UDP), tradeoffs in implicit versus
 explicit interaction with devices along the path, and so on.  This
 document will be produced by the IAB IP Stack Evolution Program; the
 new transport encapsulations document [EXP-COOP] may evolve into the
 basis for this work.
 Further, due to the underlying discuss on trust and a needed "balance
 of power" between the end hosts and the network, the workshop
 participants concluded that it is necessary to define approaches
 based on the cryptographic protocol to enable transport protocol
 extensibility.

Trammell & Kuehlewind Informational [Page 9] RFC 7663 SEMI Workshop October 2015

6.5. Additional Activities in the IETF and IAB

 The workshop identified the need to socialize ideas connected to
 transport stack evolution within the IETF community, including
 presentations in the transport and applications open area meetings on
 protocol extensibility, UDP encapsulation considerations, and the
 application of TLS/DTLS in order to prevent middlebox meddling.  Much
 of the energy coming out of the workshop went into the SPUD BoF (see
 Section 6.1), so these presentations will be given at future
 meetings.
 There are also clear interactions between the future work following
 the SEMI workshop and the IAB's Privacy and Security Program; Privacy
 and Security program members will be encouraged to follow
 developments in transport stack evolution to help especially with
 privacy implications of the outcomes of the workshop.

6.6. Additional Activities in Other Venues

 Bob Briscoe informally liaised the SEMI workshop discussions to the
 ETSI Network Function Virtualization (NFV) Industry Specification
 Group (ISG) following the workshop, focusing as well on the
 implications of end-to-end encryption on the present and future of
 in-network functionality.  In the ISG's Security Working Group, he
 proposed text for best practices on middlebox access to data in the
 presence of end-to-end encryption.

7. Security Considerations

 This document presents no security considerations.

8. Informative References

 [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
            Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
            <http://www.rfc-editor.org/info/rfc3234>.
 [RFC5218]  Thaler, D. and B. Aboba, "What Makes For a Successful
            Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
            <http://www.rfc-editor.org/info/rfc5218>.
 [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
            Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
            January 2012, <http://www.rfc-editor.org/info/rfc6347>.
 [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
            Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
            2012, <http://www.rfc-editor.org/info/rfc6555>.

Trammell & Kuehlewind Informational [Page 10] RFC 7663 SEMI Workshop October 2015

 [RFC7305]  Lear, E., Ed., "Report from the IAB Workshop on Internet
            Technology Adoption and Transition (ITAT)", RFC 7305,
            DOI 10.17487/RFC7305, July 2014,
            <http://www.rfc-editor.org/info/rfc7305>.
 [SPUD-USE] Hardie, T., "Use Cases for SPUD", Work in Progress,
            draft-hardie-spud-use-cases-01, February 2015.
 [SPUD-PROTO]
            Hildebrand, J. and B. Trammell, "Substrate Protocol for
            User Datagrams (SPUD) Prototype", Work in Progress,
            draft-hildebrand-spud-prototype-03, March 2015.
 [TLS-DTLS] Huitema, C., Rescorla, E., and J. Jana, "DTLS as
            Subtransport protocol", Work in Progress,
            draft-huitema-tls-dtls-as-subtransport-00, March 2015.
 [EXP-COOP] Trammell, B., Ed., "Architectural Considerations for
            Transport Evolution with Explicit Path Cooperation", Work
            in Progress, draft-trammell-stackevo-explicit-coop-00,
            September 2015.
 [black-semi]
            Black, D., "UDP Encapsulation: Framework Considerations",
            January 2015, <https://www.iab.org/wp-content/
            IAB-uploads/2014/12/semi2015_black.pdf>.
 [briscoe-semi]
            Briscoe, B., "Tunneling Through Inner Space", October
            2014, <https://www.iab.org/wp-content/IAB-uploads/2014/12/
            semi2015_briscoe.pdf>.
 [cheshire-semi]
            Cheshire, S., "Restoring the Reputation of the
            Much-Maligned TCP", January 2015, <https://www.iab.org/
            wp-content/IAB-uploads/2015/01/semi2015-cheshire.pdf>.
 [deering-plenary]
            Deering, S., "Watching the Waist of the Protocol
            Hourglass", August 2001,
            <https://www.ietf.org/proceedings/51/slides/plenary-1>.
 [edeline-semi]
            Edeline, K. and B. Donnet, "On a Middlebox
            Classification", January 2015, <https://www.iab.org/
            wp-content/IAB-uploads/2014/12/semi2015_edeline.pdf>.

Trammell & Kuehlewind Informational [Page 11] RFC 7663 SEMI Workshop October 2015

 [hardie-semi]
            Hardie, T., "Network Function Virtualization and Path
            Character", January 2015, <https://www.iab.org/wp-content/
            IAB-uploads/2014/12/semi2015_hardie.pdf>.
 [huitema-semi]
            Huitema, C., "The Secure Transport Tussle", October 2014,
            <https://www.iab.org/wp-content/IAB-uploads/2014/12/
            semi2015_huitema.pdf>.
 [raiciu-semi]
            Raiciu, C., Olteanu, V., and , "Good Cop, Bad Cop: Forcing
            Middleboxes to Cooperate", January 2015,
            <https://www.iab.org/wp-content/IAB-uploads/2015/01/
            ninja.pdf>.
 [welzl-semi]
            Welzl, M., Fairhurst, G., and D. Ros, "Ossification: a
            result of not even trying?", January 2015,
            <https://www.iab.org/wp-content/IAB-uploads/2014/12/
            semi2015_welzl.pdf>.

Trammell & Kuehlewind Informational [Page 12] RFC 7663 SEMI Workshop October 2015

Appendix A. Attendees

 The following people attended the SEMI workshop:
 Mary Barnes, Richard Barnes, David Black, Marc Blanchet, Bob Briscoe,
 Ken Calvert, Spencer Dawkins, Benoit Donnet, Lars Eggert, Gorry
 Fairhurst, Aaron Falk, Mat Ford, Ted Hardie, Joe Hildebrand, Russ
 Housley, Felipe Huici, Christian Huitema, Jana Iyengar, Mirja
 Kuehlewind, Eliot Lear, Barry Leiba, Xing Li, Szilveszter Nadas, Erik
 Nordmark, Colin Perkins, Bernhard Plattner, Miroslav Ponec, Costin
 Raiciu, Philipp Schmidt, Martin Stiemerling, Dave Thaler, Brian
 Trammell, Michael Welzl, Brandon Williams, Dan Wing, and Aaron Yi
 Ding.
 Additionally, Stuart Cheshire and Eric Rescorla contributed to the
 workshop but were unable to attend.

Acknowledgments

 The IAB thanks the SEMI Program Committee: Brian Trammell, Mirja
 Kuehlewind, Joe Hildebrand, Eliot Lear, Mat Ford, Gorry Fairhurst,
 and Martin Stiemerling.  We additionally thank Prof. Dr. Bernhard
 Plattner of the Communication Systems Group at ETH for hosting the
 workshop, and the Internet Society for its support.  Thanks to
 Suzanne Woolf and Aaron Falk for the feedback and review.

Authors' Addresses

 Brian Trammell (editor)
 ETH Zurich
 Gloriastrasse 35
 8092 Zurich
 Switzerland
 Email: ietf@trammell.ch
 Mirja Kuehlewind (editor)
 ETH Zurich
 Gloriastrasse 35
 8092 Zurich
 Switzerland
 Email: mirja.kuehlewind@tik.ee.ethz.ch

Trammell & Kuehlewind Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7663.txt · Last modified: 2015/10/20 20:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki