Transport Services (TAPS) Working Group
Thursday, July 23, 1300-1500 
Karlin I/II


Note: all discussion is regarding completion of
draft-ietf-taps-transports-06


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
      document?

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
   draft-ietf-taps-transports.

   Q: Administrative question: where is the split between these
      documents?

   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?