TAPS Interim May 2023

• Issues for draft-ietf-taps-arch, -interface, -impl

  • ETA on remaining updates: w/o 22 May

• Implementation update

  • Preso by Tommy
  • Brian: should probably plan to update RFCs after there has been
    some application adoption. Should plan to do that before moving
    to Internet Standard.
  • Would QUIC wg adopt mapping work?
  • Martin Re going dormant: RMCAT left wg open until docs were
    published. Addl candidate work: transport discovery draft would
    like to ask implementers to consider taking up this topic. Are
    any implementers interested?
  • Additional implementers are more likely to appear when RFCs are
    published.
  • Concerns about activation energy required to re-open a closed
    wg. However, small diffs to RFCs could go through TSVWG.
  • Brian is volunteering to collaborate with Tommy and Michael on a
    blog post on TAPS
  • Zahed as AD: WG will stay open at least until AUTH48 is complete
    on the current docs. Then, I prefer to close the WG and keep the
    mailing list open as discussion venue.
  • Martin: need more OS support before pressing applications to
    implement
  • Aaron: Is the hackathon a useful venue to make TAPS approachable
    for implementers? Or outreach at conferences like Netdev?
  • Tommy: TAPS can be part of libraries, doesn't need to be baked
    into the OS.
  • Aaron: Would an ISOC grant for implementers help?
  • Brian: Yes, but we want to identify the implementers first.

• What can we do now to foster deployment of TAPS?

  • Q: do we have all of the 'missing pieces'?

    • Colin (in chat): For missing pieces: understanding what
      parts of TAPS can be implemented over Sockets and what parts
      need OS-specific APIs to implement might be useful for
      language implementers.

  • Is TAPS useful without an HTTP binding?

    • Phillip: found that socket options for HTTPS is really hard.
      TAPS would be an enabler for folks who use HTTP APIs
      frequently.
    • Zahed: need to consider WEBTRANS work in IETF. Probably need
      to convince them.
    • Phillip: There's lots of REST applications which would
      benefit from TAPS.

• Discoverability/configuration

  • From Devon:
    > Most of my questions / comments / contributions have been
    > about discoverability / configuration, and I wondered if
    > there'd be interest in exploring the policy and configuration
    > space for Transport Services. I'm thinking along the lines of
    > APIs for configuration tools to manage or discover policy
    > (e.g. enumerate local endpoints, gather properties, collect /
    > set resolver configurations).

• Mappings: QUIC, HTTP, any others?

  • Status of QUIC mapping doc?
    • Tommy: Happy to keep working on it as time permits, happy to
      help with HTTP. It would be useful to have other
      contributors. Looking for a co-author.
    • Zahed: Martin said a QUIC mapping would have a larger
      audience in QUIC. Anyone have comments?
    • Tommy: Years ago, we talked to QUIC about it and there
      wasn't appetite. Now, my guess is that they still wouldn't
      take it on, we didn't do the TCP mappings in TCPM. I don't
      think the people in the QUIC WG would use the mapping,
      they're application developers. It's more likely we would
      review that work in QUIC but do it here or in TSVWG.
    • Aaron: Previously TAPS has tried to engage with the Apps
      area, we never had much participating from them.
    • Proposal: Engage with developers at Hackathons post RFC
      publication

• Next steps

  • No meeting at IETF 117
  • Finish the existing documents
  • Write an IETF blog post, to come out around when the RFC comes
    out.
  • Proposal to have a side meeting (Prague?) for planning how to
    engage developers