* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Taps Status Pages

Transport Services (Active WG)
Tsv Area: Martin Duke, Magnus Westerlund | 2014-Sep-23 —  

IETF-93 taps agenda

Session 2015-07-23 1300-1500: Karlin I/II - taps chatroom


          Transport Services (TAPS) Working Group
          Thursday, July 23, 1300-1500
          Karlin I/II
          Note: all discussion is regarding completion of
          0. Administrivia (5 min)
          1. Review of schedule for taking draft-ietf-taps-transports to working
             group last call this year.  (5 min)
          2. Review of protocols we don't have text for yet.  (We're looking at
             you, RTP.) (5 min)
             Q: Are there any other missing protocols worth holding up the
          3. Document Review (30 min)
             Discussion of "refactored" transport protocol components.  In -06
             we have redefined the components of TCP to be closer (in our
             opinion) to the actual interactions between each of the behaviors
             of the protocol. This is necessarily messier than starting from a
             "clean" set of features and working backward, as TCP was not
             designed as a composition of behaviors, rather evolving around a
             set of constraints.
             Q: Is this an acceptable approach?
          4. Substantive Discussion: Features (30 min)
             Regardless of how we decompose the protocols, we do know enough
             about *some* transport service features to start writing detailed
             information about the features -- the discussion here will focus on
             draft-gjessing-taps-minset and/or section 4 of
             Q: Administrative question: where is the split between these
             Q: Primary technical question: what do we know about the features
                that belong in this minimum set that we can start writing?
          5. Substantive Discussion: Interfaces (30 min)
             Discussion on interfaces/APIs and how we should consider them as
             input for the TAPS effort.  There are three broad areas of
             questions about the eventual interface that TAPS will provide: (a)
             what are the knobs? (and who gets to turn them: app developer,
             user, administrator, kernel developer, etc)?  (b) what are the
             meters (and who gets to see them)?  (c) what are the patterns of
             interaction supported by existing interfaces?
             Q: Does this start work on the second document or is there
                something we can take from (abstract and concrete) interfaces
                already deployed that would inform the decomposition of
                transport protocols/services?

Generated from PyHt script /wg/taps/agenda.pyht Latest update: 24 Oct 2012 16:51 GMT -