Minutes IETF107: dispatch
minutes-107-dispatch-01

IETF 107 - DISPATCH WG / ART Area session
Audio Conference- Virtual Meeting - 22::00 UTC 23 March 2020
conference call recording: https://www.youtube.com/watch?v=CYqB6Xk4NTE

The chairs would like to express their gratitude to Jean Mahoney and
Bron Gondwana for leading the note taking effort and for E Sam
covering the jabber relay.

Dispatch Action Summary

The chair discussion acknowledged the limitations of a virtual
meeting. The call was structured to take questions at the end of the
presentations in order to better coordinate the speaking
queue. Attendees were asked to rely on the list more heavily than is
usual for Dispatch given the circumstances of a virtual meeting and
the difficulties in measuring consensus in that environment.

The agenda was modified based on a suggestion from the chairs to defer
the ASAP work to the list as we are close to a proposed charter and
that forum seems easier for wordsmithing. No other agenda
modifications were proposed.

Due to the unusual format of the meeting it was less clear than usual
what items were being discussed as DISPATCH and what as ART area. The
chairs will improve on that in the future.

Much of the meeting time was spent discussing email security in a
discussion lead by Michael Peddemors. The general feeling in the
‘room’ was that an eventual BoF was the right outcome for this worth
but a first step should be bringing a proposed charter and statements
of interest to the dispatch list.

Brad Peabody discussed work related to UUID v6 on a FYI basis.

Mark Nottingham discussed work related to Link Hints. After some
discussion the idea of a potential WG devoted to HTTP APIs was
raised. Mark will investigate the viability of that approach and
placed the Link Hint work on hold pending the outcome.

Maxim Sharabayko discussed SRT (Secure Reliable Transport) - an
existing low latency video protocol being introduced to the IETF
here. There was substantial discussion about how its features
interacted with existing IETF protocols and how it is expected to
evolve in the future. The discussion is captured in the minutes below
and on the audio recording. Maxim indicated that the existing version
of the protocol would be unlikely to yield technical change control to
the IETF, but the authors would be interested in collaborating on the
future. The dispatch advice given was to consider the Individual
Submission path for potential publication of work the IETF would not
be contributing engineering work to and afterwards explore again with
dispatch how the IETF could collaborate on the evolution of SRT.

Detailed notes follow:

DISPATCH / ART Area @ IETF107 Virtual Meeting - 23 March 2020 22:10-0:10
WebEx: https://ietf.webex.com/
Jabber Chat: xmpp:dispatch@jabber.ietf.org?join

Chairs: Patrick McManus, Ben Campbell
Notetakers: Jean Mahoney, Bron Gondwana
Jabber Scribe: E Sam

**********************************************************************
              Agenda & Minutes IETF 107 DISPATCH and ART AREA
**********************************************************************

DISPATCH Meeting
----------------

### Status and Agenda Bash - Chairs and ADs (15 min)

### Client-ID and Email Security - Michael Peddemors (30 min)

[SMTP-ClientID](https://tools.ietf.org/html/draft-storey-smtp-client-id-08)
[IMAP-ClientID](https://tools.ietf.org/html/draft-yu-imap-client-id-03)

### Automatic Peering for SIP Trunks - Kaustubh Inamdar/Sreekanth Narayanan(15
min)

Discussion: Should DISPATCH recommend formation of a mini-working group with a
charter similar to the proposed?

[Proposed
Charter](https://mailarchive.ietf.org/arch/msg/dispatch/o3ijbrtRX5lpGuY-eqZ_nGf_f_E)

This item may be removed during agenda-bashing.

ART AREA Meeting
----------------

### BoFs and meetings of interest - ADs and BoF Chairs (10 min)

### UUID Format Update - Brad Peabody (15 min)

[Draft](https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-00)

### HTTP Link Hints  - Mark Nottingham - (5 min)

[Draft](https://tools.ietf.org/html/draft-nottingham-link-hint-02)

### If time permits:  Secure Reliable Transport SRT

Discussion: Where does discussion of this belong?

[draft][https://tools.ietf.org/html/draft-sharabayko-mops-srt-00]

### AOB

**********************************************************************
         MINUTES
**********************************************************************

Patrick introductions:
        * We will take questions at the end

There was no agenda bashing from the floor. The chairs moved the ASAP
discussion to the list.

Client-ID - Michael Peddemors
   * Suggest via Dispatch - find new home at IETF.

   John Levine: this is worth a working group - make it clear that this is
   client to server. Not a fan of CLIENTID though, it's just another password
   to steal.  Maybe a time-based password. Yes WG, No this draft. ekr: Likewise
   From Jabber: sftcd, Alexey Melnikov: +1 - plus about 7 others! sftcd: only
   valid Michael: need to make a home first ekr: is this encrypted or not?  If
   it's only sent over encrypted then password is pretty good (though shared
   passwords are still a problem) dkg: this wouldn't be a human-generated
   password so can be high entropy (so scripted password guessers not a
   problem) Ben Campbell: If creating a WG then we need to create a charter. 
   These drafts may or may not be an input.  Worth exploring this. Michael:
   what is the problem statement the working group is attempting so solve? 
   Suggest top 3 methods of email compromise. Seth Blank: WG makes sense,
   concerned about scope + broadness of problem area.  Top 3 attacks is wrong
   place to start, and CLIENTID is wrong place to start.  Credential easy to
   forge like HELO name. Seth: want do do away with pre-establised
   sender/receiver secrets - there's a bootstrapping + global accessibility
   problem. Pete Resnick: we need a more focused problem statement rather than
   just two protocols to go after.  Suggest write a few paragraphs that will
   form part of a charter.  Are there IPR statements on this? Michael: we've
   already made IPR statements on this.  It's our goal to have the whole world
   adopt these.  We've contributed code to open source projects.  Only
   intellectual property is around threat detection, which is above and beyond
   actual spec. Pete: you want to fill out IPR disclosure form? Michael:
   already did. Richard Barnes: If a WG were to be formed, we need to have an
   idea what problem is being solved.  E.g. if it's already deployed.  There's
   also prior art in the web space, we should lean on that. Michael: there's
   deployed us.  Sanebox, Bluehost, etc... even Thunderbird.  Couple of million
   users in North America. Spencer: Is there carrier interest? Michael: there's
   ongoing discussions with major carriers.  Some of our customers are midlevel
   carriers who are excited.  Enterprise is excited too. dkg: this is not how
   we'd be designing a security mechanism today.  This isn't the right draft.
   Murray: is there any experience that's already been had with this that you
   could point to. Richard Barnes: Not hearing energy to form a group - would
   need to see a charter first Seth Blank: what's interesting is "where can we
   add 2 factor"? Cullen: ... Would need to see a charter. Pete: is it
   appropriate for Michael to post things like a mushy charter and feedback
   from implementers in dispatch list, or do we need a new list first? Ben:
   we'll hear from Barry! Barry: a bit more discussion on Dispatch is fine, but
   more than that would need a new mailing list. There's interest in 2fa for
   email - maybe Michael should join a group doing that. Bron: don't forget
   JMAP!  Also is TxAuth right? Michael: don't think TxAuth is the right thing
   - that's very targetted and quite unrelated. Michael: should have a separate
   mailing list where we can engage all the various people - worried they don't
   have a voice on dispatch. Barry: the email people who are part of IETF are
   already here on dispatch.  If you have other people not part of IETF to
   bring in, a separate email list is good. Ben Campbell: Have talked about a
   charter and a WG - does anybody think it needs to go to a bof. Mark
   Nottingham: it should go to a BOF. sftcd: if there's interest, don't need a
   BOF. Pete Resnick: a BOF is appropriate, but don't need to wait to work on
   charter - let's do that first! Barry: what Pete said.  Right thing to do now
   is somebody make a non-wg mailing list request and send it to me. I will
   create it. Bron: should we reanimate an old one? Barry: think it's different
   enough. Patrick: next step is a proposed charter abnd list. hard to
   summarize, we'll create a summary to the list with our understanding.
drafting a potential charter, and finding a place for the work.

UUID version 6 - Brad Peabody presenting
https://datatracker.ietf.org/meeting/107/materials/slides-107-dispatch-uuid-v6-slides-brad-peabody-00

* ted.h: this points to creating an identifer which is not a UUID, this handily
  avoids the "3 different places standardized UUIDs at the same time" issue.
* Richard Salz: what do you mean by sorting?
  Brad: if you have it as a database key, what order is it returned in?  So
  e.g. a database table of users where UUID is key, want it to sort in order.
* Richard Barnes: Why do we need a specification here?  The usecases so far are
internal to a database, why do you need a spec for inter-vendor interop?
  Brad: it will need to be read by other tooling, so we it needs to be
  transportable, e.g. other systems.
* ekr: this is fine, but it doesn't guarantee uniqueness.
* from jabber: does IETF own UUIDs?
Stuart Card - UUID v 6 is facing the same issues as DRIP, meeting wed night.

BoFs and meetings of interest -
We looked at the upcoming events during the week. Pete Resnick described
gendispatch agenda topics. Richard Barnes covered secdispatch.

Link-Header: Mark Nottingham
 - presented in 2013 in ART area meeting.
 - looking for feedback about what to do next?  Maybe HTTP - but not really
 http. - independent or AD or HTTP API specs?

Seth Blank: something like this is a hot topic at M3AAWG right now.
Want to describe what's in a HTTP payload.  Might be a good place to
discuss this at M3AAWG.  Would love to connect Mark with that group.
Mark: thanks!  A little cautious.
Seth: at M3AAWG there's a set of specific usecases.  Concrete problems.
Harold Alvestrand: don't understand the security model of this.
Reminds me of bundles - pieces shipped together.  "I'm going to tell
you what you'd find at this other place".
Mark: it's more "here's how you could interact with this".
Spencer Dawkins: experience with AD sponsored drafts when proponents don't have
much energy is not good. Richard Barnes: there's specs for things like "here's
the REST APIs on this server". from jabber: maybe this should be a W3C thing,
particularly for M3AAWG. Robert Sparks: is there an easy place to find the
painful water that's already gone under the bridge? Mark: I wanted this in
dispatch. Barry: let's treat it like Dispatch... what do YOU want? Mark: be
interesting to do a WG for http APIs in general, but maybe this is small.
Barry: maybe this could be a seed.  Alexey via Jabber concurs. Devil is in the
details. Patrick: httpbis could process this one, but if there are others then
we can create a group. Mark: it's waited for a long time, doesn't hurt if it
waits a little longer. Ben Campbell: should we re-ask dispatch questions on the
mailing list?  Or have we learned enough to make a dispatch decision already?
Mark: why don't I explore idea of what the charter for the APIs group would
look like.

SRT protocol:  Maxim - we have time!

Spencer Dawkins: thanks for bringing this - question: do you intend to work on
this further or publish what you've got?  Should this be informational?
Spencer: other working groups have done "informational v1" followed by working
on v2 for standards track. Richard Barnes: how much tolerance is there for
changes?
 Maxim: SRT is very open to changes in encryption mechanism and in other parts.
  Would like to have some proposals.
ekr: What functionality does this have that QUIC doesn't that makes it better?
 Maxim: QUIC proposes a datagram extension - UDP with encryption and feedback. 
 SRT also brings latency management, de-jittering, packet ordering.
dkg: via jabber - could this be a queueing discipline for specific streams in
QUIC? Spencer: likewise with transport protocols, how possible is it to evolve?
E.g. new congestion control mechanisms.
 Maxim: yes we're flexible with congestion control.
Cullen Jennings: where would I find out about congestion control?
 Maxim: yes, Github code is the right place now.
Bernard Aboba: Is there a plan to implement something like SRT on the web? 
Because you don't get direct UDP access - they way to get it is QUIC.
 Maxim: A lot of browsers already support QUIC because it is implemented in the
 chrome engine. Would be good to have SRT there too. Alternatively on app
 sockets, but that would be tougher.
Colin Perkins: how does this relate to RTP?  It seems similar.
 Maxim: SRT isn't something that can't be found in other protocols - with RTP
 you have unreliable delivery of UDP, then you need an additional control
 channel over TCP.  With SRT you get it all in one protocol.
Colin: people have been multiplexing stuff with RTP for a long time.
 Maxim: yes, but you get it all out of the box with SRT. Furthermore, SRT is
 agnostic to what content to deliver.

Patrick: question "is this document existing or do work"?
 Maxim: would be good to do informational first, and potential to extend.
Patrick: start with ISE.  Independent Stream.