Skip to main content

Minutes IETF105: dispatch
minutes-105-dispatch-01

Meeting Minutes Dispatch (dispatch) WG
Date and time 2019-07-22 22:10
Title Minutes IETF105: dispatch
State Active
Other versions plain text
Last updated 2019-07-25

minutes-105-dispatch-01
Dispatch Mon, Jul 22 1810-1910
IETF 105

Chairs: Mary Barnes, Ben Campbell
Note takers: Vijay K. Gurbani and Pete Resnick

Recording:
https://play.conf.meetecho.com/Playout/?session=IETF105-DISPATCH-20190722-1810

Notes also include ART area portion of the session.

DISPATCH Summary:
=================
There is interest in the Web Transport topic. The work requires coordination
with W3C.  The next recommended step is to develop a BoF proposal for IETF-106.

ART Area Summary:
=================

Cullen Jennings presented RIPP and asked for feedback. This may come back to
DISPATCH once the proposal is more refined.

Devon O'Brien led a discussion on the applicability of BCP 190 to RFC6962-bis.
This needs further discussion on the list. Adam Roach (as ART AD) recommended
that the interested parties organize a side meeting while people are at IETF.

Notes by Vijay K. Gurbani
===========================

Mary Barnes bashed the agenda, agenda accepted without any changes.  The chairs
reminded the WG members of IETF 106 deadlines.  Please see chair slides for
deadlines [1].

Web Transport - Victor Vasiliev

This is new work being proposed to consolidate bidirectional data streams
between a web client and server that does not suffer from HoL blocking and
supports a single transport object capable of multiplexing distinct streams.

Victor went through the slides and opened up the floor for discussion.

A robust discussion ensued that indicated support for the work from WG members
(non exhaustive list: Martin Thompson, Justin Uberti, Jana Iyengar, and Cullen
Jennings).  There were opinions expressed that a BoF session seems to be a good
next step for this work (again, non-exhaustive list: Brian Trammell, Ted
Hardie).  The relationship to TAPS was brought up a couple of times, perhaps
something to focus on in a BoF session.  Also expressed was an interest was to
coordinate this work with W3C as this works deals with APIs and getting APIs
right is universally considered a complex task to accomplish well.

At the end of the discussion period, Ben Campbell summarized the discussion as:
1. Appears there is interest in this work.
2. BoF in the next IETF seems a reasonable next step.
3. Coordinate this work with W3C.

The remaining half hour of the meeting time was dedicated to ART area meeting. 
On agenda were two topics: RIPP and BCP 190 applicability to TRANS.  The chairs
also went through BoFs and side meetings.  Three side meetings: international
SHAKEN (Tue, 1700-1800), web transport (Tue, 1500-1730), HTTP priorities (Wed,
1830-1945).

Real time Internet Peering Protocol (RIPP), Cullen Jennings [2]

Cullen presented the work with a caveat that the work was in very early stages,
and not even the co-authors agree on all aspects contained in the draft.

Discussion ensued after Cullen presented his work.  Generally, there were more
clarifying-sort of questions (PSTN codec was primarily G711, so what is the
negotiation for? Why replace SIP is it is 60% of interconnected VoIP?). 
Eventually the discussion ran out of time and Cullen exhorted the WG members to
go to Github and explore the code related to the project.

BCP 190 Applicability to TRANS, Devon O’Brien [3]

This works seeks to get a variance on applying the requirements of Section 2.3
of BCP 190 to rfc6962-bis draft.  Devon presented his slides followed by a
discussion.

The views expressed during the discussion had a large range with some opinions
asking for a variance of adhering to S2.3 of BCP 190 to other views that sought
to deprecate BCP 190 altogether.  It was not clear that a decision was reached
as the discussion spilled over the last remaining minute of the alloted session
time.

[1]
https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-chairs-agenda-and-status

[2] https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-ripp
[3]
https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-rfc-6962-bis-and-bcp-190

Notes by Pete Resnick:
=====================

DISPATCH Sesssion IETF 105
Meeting minutes
(Action items and discussion points)

Chairs slides:
https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-chairs-agenda-and-status

Victor Vasiliev (VV) - Presentation on Web Transport

https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-webtransport

Comments:

Eric Rescorla (EKR): You have the same problem between WebSocket and
QuicTransport when it comes to proxy (?) VV: We will look into this Roberto
Peon (RP): Being able to read things piecemeal is important Martin Thompson
(MT): I'm somewhat supportive; understand that WebRTC isn't a great tool for
this. Getting APIs right is complicated. Must coordinate with W3C. Also adding
to EKR, it's not just TCP; you could predict cipher text and make a UDP packet
look like DNS packet. Justin Uberti (JU): This could be really useful Jana
Iyengar (JI): I like the direction you're talking about. Is there anything
beyond an API in this? You're going to have to build what's underneath into the
protocol. Ties into the TAPS discussions. What's the difference between this
and TAPS? VV: There some bits that need to be defined on the wire part. Bernard
Aboba (BA): Is there difference in the security requirements and the
functionality? VV: There are slightly different threat models. Both require
TLS. BA: The EKR threats wouldn't exist in QUIC but would exist in HTTP with
fallback. Cullen Jennings (CJ): We do need something simpler than WebRTC.
Something along these lines. Ted Hardie (TH): This is big enough for a BOF, not
to some other WG. We may be making the same mistakes made in RTCWeb. We need
the BOF to define design spaces. May end up just wanting QUIC with data channel
capabilities. VV: Agree that we need a specific list of requirements. Wu ():
We've done something similar in HTTP2. Contact offline. Brian Trammel (BT):
Yes, we need a BOF, probably Singapore. This sounds like it really needs TAPS
(3 different underlying protocols, etc.). If TAPS doesn't cover something, let
us know. VV: We want something TAPS like, but it's too high-level. BT: We'll
talk offline. Seth Blank (SB): EKR: Sad that people don't like data channels.
Way too big to AD sponsor; get a BOF David Benjamin (DB): Is this built on QUIC
Transport? VV: No. RP: Problem with QUIC Transport VV: Don't want HTTP overhead
RP: Let's fix HTTP with some extensions MT: W3C is going to have to build an
API. Need to respond to a request from them and then work on the WG. We have a
liaison.

Chair: Several people with interest, should form BOF, coordinate with W3C

ARTAREA Session IETF 105
Meeting minutes

Chair slides:
https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-chairs-agenda-and-status

Additional BOF/Side meeting/New groups mentions:
Email encryption side meeting
RUM - New WG

IESG currently discussing whether to reduce to 2 ART ADs. Input is not
unwelcome.

Cullen Jennings - Presentation on Real Time Internet Peering Protocol (RIPP)

https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-ripp

BA: It would be interesting to see how this might work in WebTransport
CJ: Yes, I'd like to look at that
Roni Even (RE): What's the use case? How does this relate to PSTN?
CJ: To be able to do in web what we did in existing telephony
Eric Burger (EB): Interconnected VoIP?
CJ: Whatever
CJ: Working on GitHub; contributors welcome
Ben Kaduk: (Slide typo - authentication vs. authorization)

Devon O'Brien - Presentation on RFC 6962-bis and BCP 190

https://datatracker.ietf.org/meeting/105/materials/slides-105-dispatch-rfc-6962-bis-and-bcp-190

Adam Roach (AR): Note that .well-known RFC cited has been obsoleted
Jacob Hoffman-Andrews (JH): The 6962 API is fine; we should keep it in v2.
(Review of get-off-my-lawn issues.) Adding unnecessary interactions introduces
bugs. VV: Nobody should ever be forced to follow the section of the BCP 190 if
it doesn't make sense. No need to add extra complexity. Andrew Ayer (AA): Cert
tranparency needs to be verifiable. Need flexibility to not do BCP 190. CJ:
It's clear that the best current practice is to use prefixes. We should
deprecate BCP 190. AR: We'll try to set up a side meeting on this.

End of session