Minutes IETF111: dispatch
minutes-111-dispatch-00

# DISPATCH Virtual Meeting @IETF-111

Monday 26 July 2021
19:00-21:00 UTC

[MeetEcho](https://meetings.conf.meetecho.com/ietf111/?group=dispatch&short=&item=1)
[Notes](https://codimd.ietf.org/notes-ietf-111-dispatch)
[Jabber](xmpp:dispatch@jabber.ietf.org?join)

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

The NoteWell was recited.

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

### JWS Clear Text JSON Signature Option (JWS/CT) (20 min)
Presenter: Samuel Erdtman
[draft-jordan-jws-ct](https://datatracker.ietf.org/doc/draft-jordan-jws-ct/)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/au-e9vF3TdhomM9hCKhlYKNHeZU/)
[DISPATCH options](
https://mailarchive.ietf.org/arch/msg/dispatch/ldkB_LnEQxFxpDTPwjfeMDXAMP0/)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-jws-clear-text-json-signature-option-jwsct/)

Presentation:

It is often desirable to present a signed JSON document as cleartext (i.e. do
not base64 encode). This can be done by applying RFC8785 Canonicalization to
the payload and adding a detached signature.

Carsten Bormann: Comments in chat. This is bikeshed material. This is a more
complicated issue. Naming is critical.

Sean Turner: Do you think this RFC will be referenced by other WGs? Rules
dictate this is at most informational if you intend to go the ISE.

Samuel Erdtman: Have been discussions on making it an extension to JOSE, not
expecting other WGs to adopt this. More of an in the wild use. Would like a
stable reference.

Eric Resorla: Not sure if it is a bad idea but ISE is the appropriate route.

Canonicalization is needed but should not be mandated for on the wire, the
endpoints should canonicalize as part of verification.

Cullen Jennings: When we say send this to the ISE we say IETF shouldn't do this
(now).

Pete Resnick: Idea of a signature that doesn't require ASCII armor is
interesting but this approach is not appropriate to IETF. May want to change
approach to make it compatible.

Show of hands poll: SHOULD THE IETF TAKE THIS ON? (IF NOT, "DO NOT RAISE HAND"
COULD INDICATE GOING TO ISE)

Raise Hand: 10
Do Not Raise Hand: 28

### image/webp mime-type registration (10 min)
Presenter: James Zern
[draft-zern-webp](https://datatracker.ietf.org/doc/draft-zern-webp/)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/XtRV8K2DTym_aL7eovkB13D0KFU/)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-slides-111-dispatch-draft-zern-webp/)

Presentaion:

WebP is an image format that supports lossy and lossless compression with alpha
transparency and animation capabilities. It is supported in all major browsers.

Barry Leiba: Doesn't even need an RFC, just write out spec and submit to IANA
as expert review request.

James Zern: Had tried submission was told it should go via an RFC.

Murray Kucherawy: Had suggested this as an option.

Barry Leiba: Media types don't require a consensus document.

Tim Bray: This is requesting standards tree

Barry Leiba: Thats OK.

Tim Bray: If there is a document, then just register it, if not, then should be
a document.

James Zern: We have three separate documents, not one. They cover the bases.

Cullen Jennings: Its not the definition of bits, but some of the tags could do
to be better described, does not matter where that happens.

### NICER (usage profile of ICE) (20 min)
Presenter: Harald Alvestrand
[draft-oreland-dispatch-ice-nicer](https://datatracker.ietf.org/doc/draft-oreland-dispatch-ice-nicer/)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/XtRV8K2DTym_aL7eovkB13D0KFU/)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-nicer-nicer-ice-based-on-rtt/)

Harald Alvestrand: Presentation

Proposal to improve connection establishment. Curently ICE tries many paths,
picks one and sticks to it, this is not always optimal. NICER keeps the
non-best paths and keeps probing so that choice of path is under constant
review.

Bernard Aboba: Some of the constraints you specify seem arbitrary, why isn't it
possible to change at any time? this is taking something that is out there and
making it better.

Eric Rescorla: Can see some answers are wrong - this is not AD sponsored. Looks
like it could go to MMUSIc which currently owns ICE.

Johnathan Rosenberg: This attempts to minize the controller changes but number
is not zero. Since controller has to upgrade, should consider going further. My
preference would be something with richer set of tools. Would support MMUSIC or
another WG to avoid this fragmentation.

Harald Alvestrand: Must avoid kitchen sink issue.

Justin Uberti: I think there is real value here and we can make a useful
contribution without a boat anchor.

Cullen Jennings: I think this needs a working group, maybe not MMUSIC though. I
don't know why ICE was there in the first place. Charter a new WG with
responsibility for ICE in general.

Harald Alvestrand: MPLS?

Cullen Jennings: I think it is more general. This work leads to more general
solutions. We are within striking distance but need more than a few bullet
points. Needs new WG.

Johnathan Lennox: MMUSIC is a bit too much of a grab-bag, a new WG is a better
idea.

Phillip Hallam-Baker: FIPE side meeting Tuesday is discussing some of this.
Scope for near term extension and for longer term research. Onion routing, link
level feedback.

Kirsty Paine: Looks like a lot of support for the work, question is MMUSIC or
new WG.

### SDP Security Descriptions is NOT RECOMMENDED and Historic (10 min)
Presenter: John Mattsson
[draft-mattsson-dispatch-sdes-dont-dont-dont](https://datatracker.ietf.org/doc/draft-mattsson-dispatch-sdes-dont-dont-dont)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/j0n6mubcHh3JqWICDqGlsqlX9xM/)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-sdp-security-descriptions-dont-dont-dont/)

John Mattsson: Presentation

Security Descriptions introduced in SDRP have many security issues. New systems
(e.g. WebRTC) have prohibited use. Proposing reclassification as HISTORIC and
phaseout strategy.

Cullen Jennings: Needs more discussion before decision is made. Are you aware
of any system that is vulnerable to SSRC collisions?

John Mattsson: No

Cullen Jennings: Security descriptions do allow for security proofs. That is
why SDES is widely used even for secure systems.

Chair: Think we need this discussion with the experts.

Cullen Jennings: MMUSIC isn't a security group, clearly the wrong place to
discuss. Main alternative to this is not WebRTC, it is a patented tech.

John Mattsson: SDES is easy to make secuyrity proofs because it makes
assumptions.

Cullen Jennings: Question is what the alternative is. We can discuss offline.

Roman Shpount: The alternatives don't solve all the problems. We need a new
group to develop an alternative before we deprecate SEDS. We need to do a lot
of work.

Bernard Aboba: Need to look at the scenario in which SDES is to be used. Took
an enormous amount of time to get it deployed. Only got secure signal very
recently. Barrier to deployment is very high.

Eric Rescorla: It is clear SDES is a nightmare. Agree deprecation without
alternatives is bad. Need to work out how to fix them. The installed base is
significant. Probably requires a new WG to understand arguments and validity.
In favor of forming a WG.

### The "large file in email" problem (10 min)
Presenter: Bron Gondwana
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-gondwana-email-big-files-problem/)

People want to send larger files than SMTP can handle. There are many different
approaches users have to navigate. We need a stardard approach.

PHB: Malware is a major security issue. Needs to be a WG.

Michael Richardson: Needs to be a WG. Problem is who pays for storage. Need to
consider asynchronous nature.

Neil Jenkins: People clearly want to do this with email. Standardized version
is worthwhile.

John Levine: This is a very old problem, we had it on usenet. There's two
approaches, external body or divide into chunks.  Suggest WG look at both
approaches (h/t Ned) and how they have failed in the past.

Outcomes (all outcomes are preliminary and will go to the list to be confirmed)
* JWS Clear Text JSON Signature Option: chairs did not hear support for the
IETF taking on this work at this time; dispatch will not recommend doing so. *
image/webp mime-type registration: Murray Kucherawy is deciding between expert
review and AD sponsorship * NICER (usage profile of ICE): to be decided by ADs
to determine if ice-revisited as a broader topic for a WG would be right, or
this would be better in MMUSIC as a standalone item * SDP Security Descriptions
is NOT RECOMMENDED and Historic: consensus was sub-optimal. There was support
for revisting the space currently standardised by SDP, but not on direction
(whether to do a deprecation with/without replacement). Future paths suggested
included: mmusic, a new WG, more work required for it to be ready, or a BoF (in
chat) to vet the idea further. * The “large file in email” problem: recommend
new WG, charter to dispatch list for discussion

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

### BoFs, updates and meetings of interest - ADs (10 min)

### FFV1 v4 - new codec spec from CELLAR WG (5 min)
Presenter: Michael Richardson
[FFV1-v4 Github](https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-cellar-wg-overview/)

### IPv6 Zone Identifiers in URIs (RFC6874bis) (10 min)
Presenter: Brian Carpenter
[draft-carpenter-6man-rfc6874bis](https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/)
[Messages](https://mailarchive.ietf.org/arch/msg/ipv6/i5LUQN9vU9MryNWtvS_M_O7Wgjc/)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-ipv6-zone-identifiers-in-uris-rfc6874bis/)

Larry Masinter: Would start the discussion in the browser world.

### Reliable (unreliable) streaming protocol (10 mins)
Presenter: Kirill Pugin
[draft-kpugin-rush](https://datatracker.ietf.org/doc/draft-kpugin-rush/)
[Messages](https://mailarchive.ietf.org/arch/msg/avt/F-dp-TQrKxDjAanl1_gaRhNWGuM/)
[Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-rush-reliable-unreliable-streaming-protocol/)

Juliusz Choboczek: Everything going out on same channel and encrypted, right?
How can router distinguish different flows?

Kirill Pugin: It doesn't.

### AOB