IETF 101
The IETF 101 meeting was held from March 17-23, 2018 in London, UK
Presentations
Internet Drafts
-
draft-trammell-taps-interface
- Brian Trammell, Michael Welzl, Theresa Enghardt, Gorry Fairhurst, Mirja Kühlewind, Colin Perkins, Philipp S. Tiesel, and Chris Wood, An Abstract Application Layer Interface to Transport Services (.txt|.pdf), Internet Engineering Task Force, March 2018, Work in progress (draft-trammell-taps-interface-00.txt).
-
This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime. It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from.
-
draft-pauly-taps-transport-security
- Tommy Pauly, Colin Perkins, Kyle Rose, and Chris Wood, A Survey of Transport Security Protocols (.txt|.pdf), Internet Engineering Task Force, March 2018, Work in progress (draft-pauly-taps-transport-security-02.txt).
-
We've submitted an update to the TAPS transport protocol security survey draft. I've become a co-author due to contributing text on Secure RTP, but the other authors did most of the work here.
-
draft-pauly-taps-arch
- Tommy Pauly, Brian Trammell, Anna Brunstrom, Gorry Fairhurst, Colin Perkins, Philipp S. Tiesel, and Chris Wood, An Architecture for Transport Services (.txt|.pdf), Internet Engineering Task Force, March 2018, Work in progress (draft-pauly-taps-arch-00.txt).
-
This document provides an overview of the architecture of Transport Services, a system for exposing the features of transport protocols to applications. This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services. It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services.
-
draft-ietf-mmusic-rfc4566bis
- Ali Begen, Paul Kyzivat, Colin Perkins, and Mark Handley, SDP: Session Description Protocol (.txt|.pdf), Internet Engineering Task Force, February 2018, Work in progress (draft-ietf-mmusic-rfc4566bis-25.txt).
-
This version addresses document shepherd review comments from Flemming Andreasen.
-
draft-ietf-avtcore-cc-feedback-message
- Zaheduzzaman Sarker, Colin Perkins, Varun Singh, and Michael A. Ramalho, RTP Control Protocol (RTCP) Feedback for Congestion Control (.txt|.pdf), Internet Engineering Task Force, March 2018, Work in progress (draft-ietf-avtcore-cc-feedback-message-01.txt).
-
We've submitted an update to the RTCP congestion control feedback draft. This makes a number of technical changes:
- Updates the unit of measurement of the arrival time offset field to use a 1024Hz clock, rather than a 1000Hz clock, to give exact offsets from the Report Timestamp.
- Clarify that if no packets are received from an SSRC in a reporting interval, then no report block is sent for that SSRC. Suggest that a regular SR/RR packet SHOULD be sent instead in this case, since the non-increased extended highest sequence number received field of that SR/RR packet will inform the sender that no packets have been received.
- Give guidance on what sequence number range should be included in each report. State that they should cover consecutive ranges, and not overlap, but state behaviour if they do overlap. State that reports more than one quarter of the sequence number space ahead or behind the previous report MUST be ignored.
- Expand guidance on feedback timing, and reference draft-ietf-rmcat-rtp-cc-feedback for details.
- Clarify that sequence number wrap-around should be accounted for, and note sequence number calculations use modulo arithmetic.
- Rather than leave the format and clock source used for the Report Timestamp (RTS) field unspecified, mandate that it uses the same clock as used for RTCP SR/RR NTP timestamp fields, and is formatted as the middle 32 bits of an NTP format timestamp (as described in Section 4 of RFC 3550).
In addition, there has significant editorial improvements and clarifications throughout. The draft will be discussed at the IETF 101 meeting in London, in a few weeks.
-
draft-fairhurst-tsvwg-transport-encrypt
- Gorry Fairhurst and Colin Perkins, The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet (.txt|.pdf), Internet Engineering Task Force, February 2018, Work in progress (draft-fairhurst-tsvwg-transport-encrypt-06.txt).
-
This revision has sought to improve the readability and presentation of the security story. It also adds a (currently draft) conclusion, and includes (as always) a request for further inputs - especially from people about their current practice using transport existing header information.
- Gorry Fairhurst and Colin Perkins, The Impact of Transport Header Encryption on Operation and Evolution of the Internet (.txt|.pdf), Internet Engineering Task Force, December 2017, Work in progress (draft-fairhurst-tsvwg-transport-encrypt-05.txt).
-
This is a relatively minor update, based on feedback from the presentation in the OPSEC WG at IETF 100, along with detailed review comments by Mohamed Boucadair.
-
draft-brunstrom-taps-impl
- Anna Brunstrom, Tommy Pauly, Theresa Enghardt, Karl-Johan Grinnemo, Tom Jones, Philipp S. Tiesel, Colin Perkins, and Michael Welzl, Implementing Interfaces to Transport Services (.txt|.pdf), Internet Engineering Task Force, March 2018, Work in progress (draft-brunstrom-taps-impl-00.txt).
-
This draft provides guidance for implementations of the proposed IETF Transport Services architecture.