# DISPATCH Hybrid Meeting @IETF-116 {#dispatch-hybrid-meeting-ietf-116} Monday 27 March 2023 Room: G401-G402 09:30-11:30 Local Log into the IETF datatracker to access: * [MeetEcho][1] * [Notes][2] * [Zulip][3] ## DISPATCH Meeting {#dispatch-meeting} ### Status and Agenda Bash - Chairs and ADs (10 min) {#status-and-agenda-bash---chairs-and-ads-10-min} Note that transcription is enabled -- request to speak clearly. Note Well presented Meeting tips presented, especially since this is the first session. Use the onsite tool so we have a unified queue. Wear a mask unless actively speaking. Six presentations scheduled -- full schedule! #### DISPATCH chair rotation -- Murray {#dispatch-chair-rotation--murray} Jim Fenton rotating in as co-chair in place of Kirsty. Thanks to Jim for stepping in, and to Kirsty for her time chairing dispatch. ### Multiformats (20 min) {#multiformats-20-min} Presenter: Manu Sporny (Remote) [draft-multiformats-multibase][4] [draft-multiformats-multihash/][5] [Messages][6] Multiformats are a self-describing data format header. Labels for data. Currently used to identify base15, base64, etc.; types of public keys; and codecs. Multiformats widely used by W3C and others. 17 implementations. Want to document it. Multibase: base-encoding for a string. Multihash: binary header, identifies type and length of hash Presenter prefers AD-sponsored path. Maybe CFRG? Thinks it's too early for a WG. Chatter on Zulip, re: the dispatch question Michael Richardson:AD sponsored RFC, seems like it has to be STD in order to create a registry. John Klensin: Referring to my email of a few hours ago, if there is nothing to do other than publish, why not just set up an IANA registry for the codes and dispatch to the ISE? Pete Resnick: exactly Discussion: Sean Turner: channeling Richard Barnes: my impression is that these multiX things are usually pretty domain-specific, wonder whether there's a need for a global thing Murray: AD sponsored is difficult due to workload Martin Durst: detail question, not sure it affects dispatch outcome Jonathan Rosenburg: Why no magic cookie? Thinks too small for a WG, I would have said AD-sponsored John Klensin: global registry needed, if IANA registry is needed, then the IESG can sign it off, and it can be an informational document. Parallel specification in W3C and IETF invites confusion. Pete Resnick +1 to @John Klensin : if needed, ISE to create an IANA registry. Cullen: This isn't CFRG. Not good to do through ISE because of the IANA registry needed. What are the current policies for deciding who gets a new string and who doesn't? Manu: Github repo with 3 people decide who get the high/low numbers. Cullen: hopefully the same people would do it for IANA as experts. Sounds nuts that we spin up a small WG but that may be the best option, eliminating all other options. Ted Hardie: needs a small wG, more than AD sponsored. Gives a place for people to concentrate discussion. Ekr: WG or AD-sponsored, if you want to change anything, real implementation and make real changes needs to be WG. By definition, the WG still requires AD involvement. Christopher Allen: This belongs in IETF rather than W3C. Parallel problem with CBOR where lots of new IANA registrations are needed. So a small WG could fix both of these challenges. Harald Alvestrand: Comparing this format with ASN.1. Can't determine end of string. ISE with IANA registrations. Obviously needs registration things. Manu: it's a variable length integer, not just 26-characters; very big space. Harald: It's poorly thought out but deployed so it needs registering. ISE preferred. Martin Thomson: Extensibility mechanism inherent in it, we have a difficult interoperability question. To the extent that this is documenting things that are deployed and in use, then ISE would be preferred. Mark Nottingham: I don't have a strong feeling technically, want to responin discussion. We should have the ability to do small short-term working groups and exercise that capability. Zulip: Jonathan Rosenberg: My opinion after this discussion: if there is no desire for it changing, informational. If so - small wg. Pete Resnick: timezone database is an example of something done outside IETF isn't involved with. Don't think IETF needs to be involved in this. Justin Richer: Thinks a WG makes sense. There is engineering to be done here (gives examples). Dispatch outcome: Consensus is that the work is valuable. There seems to be consensus that the work should come to IETF for the purposes of interoperability and knowledge recording, and IANA registrations. There are two clear paths forward, depending on the way the authors want to bring the work to IETF. Option 1: ISE as an informational draft with IANA registrations; Option 2: a small, no-BoF-required, WG spun up to address this problem specifically. Which option depends on how the authors want to take the work forward, how much change control they want to give to the IETF, and to what extent this is "documenting what is already done" vs. creating a space to expand and continue the work. ### Gordian Envelope & Deterministic CBOR (20 min) {#gordian-envelope--deterministic-cbor-20-min} Presenter: Christopher Allen & Wolf McNally (Remote) [Gordian Envelope & dCBOR (slides-116-dispatch-gordian-envelope-dcbor)][7] [draft-mcnally-envelope][8] [draft-mcnally-deterministic-cbor/][9] for [RFC8949 §4.2][10] [Messages][11] Presentation from Wolf McNally, Blockchain Commons: Gordian Envelope - IDs for deterministic CBOR and envelope Envelope contains subjects and assertions, assertion contains predicate and object (can be sub-envelopes) Envelopes are based on dCBOR. (deteministic profile). Need to have only one way to represent data. No existing CBOR implementations that do this currently, so they invented a couple. Richard Barnes (Zulip): my impression here is:(1) Dispatch dCBOR to the CBOR WG, if anywhere (2) Envelopes would need a full BoF, giant piece of work Rohan Mahy: Trying to figure out dividing line between envelope stuff and dCBOR. Wes Hardaker: Not sure where this is expected to be used. Are there specific use cases? Blockchain? Christopher: privacy through elision and noncorrelation; Mastodon with greater privacy David Schinazi: (not a blockchain enthusiast) The slides don't help the dispatching decisions. Chop it up into smaller pieces to make it less generic. Dispatch dCBOR to CBOR, no action on envelope. Alex Chernyakhovsky: Concerns about the envelope part of this; too generic， please come back with more specific use cases. Eric Rescorla: Premature without an actual consumer in IETF that wants to use this. Christopher Allen: This isn't blockchain; it uses hash trees but lots of other things do too. It is privacy focused, which should be important to IETF. Dispatch outcome: Dispatch dcCBOR parts of this work to CBOR WG. The envelopes part is very broad, so needs more fleshing out, refining and scoping - potentially a full BoF required and new WG, but more information needed. The envelope draft needs a requirements and user cases section. ### Protocol for interactive low-latency media transmission system (20 min) {#protocol-for-interactive-low-latency-media-transmission-system-20-min} Presenter: Dapeng Liu (Remote) [draft-liu-protocol-interactive-media-transmission][12] [Messages][13] Pete Resnick (zulip): Is the simple dispatch solution "MOQ" or "WISH"? Jonathan Rosenberg (zulip): Yes dispatch to moq I think Ted (zulip): not within charter (MOQ). Ben Schwartz: It's closest to the "sector" of WISH, but definitely outside WISH's current narrow charter. Bernard Aboba: Sounds like MOQ to me, doesn't sound like the type of thing WISH has been doing. Ted Hardie (zulip): I think this is based on a gap analysis that presumes people want a single method, without regards to the underlying transmisison system. That does not match my experience. (on the mic) As Chair, it applies to more than only MOQ, so it doesn't apply to only us and shouldn't go forward just in MOQ. Interesting idea as an abstraction, more work required. Shouldn't go forward in its current form. Spencer Dawkins: Agree with Ted. Perhaps discuss on MOQ mailing list. Sean Turner (zulip): Definitely outside of WISH as currently written. Cullen Jennings: Question about scope of work. Answer: should work with transmission protocol. Cullen: No strong opinion, seems like this could solve a problem for MOQ. Dispatch outcomes: No dispatch action at this time. The author needs to: refine the draft further, so that the community can understand scope and interaction across many protocols (not only MOQ); discuss with MOQ chairs to understand if it could be compelling enough to instigate a MOQ recharter; and discuss with others in IETF to understand where else a spanning, higher-level signalling standard could be helpful. ### Opus codec Updates (20 min) {#opus-codec-updates-20-min} Presenter: Jean-Marc Valin (On site) [draft-valin-opus-extension][14] [draft-valin-opus-dred][15] [Messages][16] Jean-Marc is playing the audio samples. Much more resilient to loss. Proposed paths: reopen codec WG or create new mlcodec WG Jonathan Rosenberg: Amazing, really interesting. No-brainer, clearly a WG, whether you reopen it or start a new one. Scope question - it's only for red Stephan Wenger: (inaudible, typed on zulip) Recommend WG. Can’t take IETF rec text to other orgs. Mo Zanaty: new WG, don't recommend reopening codec as it would be limited does it have it (reopen codec WG with narrow charter) Magnus Westerlund: Is this a rubberstamping exercise? Answer: Definitely not. Benjamin Schwartz: New WG, but with broader charter to consider other codec work as well. Need some process work to figure out how to fit the neural network stuff in. Jean-Marc: Instead to standardise this not see-saw, want to avoid a huge neural network. We are trying to define the minimal amount that needs to be standardised to allow for interoperability. Robert Sparks: Want to speak specifically to not-defining your decoder in a language jammed at the back of an RFC. Amplifying what Magnus said, the work being proposed is more approachable than a lot of detailed implementaton information in the original codec work. Deserves a new WG. Cullen Jennings: Recommend a new WG. Make one of the goals of the charter be: "work out how to standardise things like this", that's the way the world is going and we need to do that to be relevant. Jonathan Lennox: I agree it should be a WG, not sure of scope. Initial scope to be worked out. Dispatch outcome: Strong interest in the work; create a new WG rather than re-open the existing one, charter to be worked out with ADs and shared on list. ### Emergency 911 Services over Wi-Fi (10 min) {#emergency-911-services-over-wi-fi-10-min} Presenter: Sri Gundavelli (On site) [draft-gundavelli-dispatch-e911-wifi][17] Ted Hardie: Remember ECRIT is still open. Suggest taking the work there. Jonathan Rosenberg: If it just needs a new profile on the access point, there isn't anything for IETF to do. Sri: Some standardization work is still needed. Bernard Aboba: Geolocation interaction David Schinazi: Do you have support from device makers? Sri: Not yet. Dispatch outcome: Clarify which parts are for standardisation, take some parts to ECRIT for their input and view. Then, potentially come back for a dispatch or advance the work with ECRIT, if they find it relevant. ### Dispatch summary {#dispatch-summary} **Multiformats dispatch outcome:** Consensus is that the work is valuable. There seems to be consensus that the work should come to IETF for the purposes of interoperability and knowledge recording, and IANA registrations. There are two clear paths forward, depending on the way the authors want to bring the work to IETF. Option 1: ISE as an informational draft with IANA registrations; Option 2: a small, no-BoF-required, WG spun up to address this problem specifically. Which option depends on how the authors want to take the work forward, how much change control they want to give to the IETF, and to what extent this is "documenting what is already done" vs. creating a space to expand and continue the work. **dcCBOR & Envelopes dispatch outcome:** Dispatch dcCBOR parts of this work to CBOR WG. The envelopes part is very broad, so needs more fleshing out, refining and scoping - potentially a full BoF required and new WG, but more information needed. The envelope draft needs a requirements and user cases section. **Low-latency media transmission system dispatch outcome:** No dispatch action at this time. The author needs to: refine the draft further, so that the community can understand scope and interaction across many protocols (not only MOQ); discuss with MOQ chairs to understand if it could be compelling enough to instigate a MOQ recharter; and discuss with others in IETF to understand where else a spanning, higher-level signalling standard could be helpful. **Opus codec dispatch outcome:** Strong interest in the work; create a new WG rather than re-open the existing one, charter to be worked out with ADs and shared on list. **e911 dispatch outcome:** Clarify which parts are for standardisation, and take some parts to ECRIT for their input and view. Then, potentially come back for a dispatch or advance the work with ECRIT, if they find it relevant. ## ART AREA Meeting {#art-area-meeting} * * * ### BoFs, updates and meetings of interest - ADs (1 min) {#bofs-updates-and-meetings-of-interest---ads-1-min} Please go to the secdispatch meeting for the email item being dispatched there. Francesca: use the new HTTP directorate for HTTP review. ### Structured Email (SML) BOF (5 min) {#structured-email-sml-bof-5-min} Presenter: Hans-Joerg Happel (On site) [Structured Email (SML)][18] Please go to the BoF for SML Tuesday morning at 9:30am local time. More details can be found here: https://datatracker.ietf.org/group/sml/meetings/ ### Flextime & AOB (0 min) {#flextime--aob-0-min} [1]: https://meetecho.ietf.org/conference/?group=dispatch&short=dispatch&item=1 [2]: https://notes.ietf.org/notes-ietf-116-dispatch [3]: https://zulip.ietf.org/login/#narrow/stream/dispatch [4]: https://datatracker.ietf.org/doc/draft-multiformats-multibase/ [5]: https://datatracker.ietf.org/doc/draft-multiformats-multihash/ [6]: https://mailarchive.ietf.org/arch/msg/dispatch/Q9aUoF01Upbvl7STjJvjoU8hlHM/ [7]: https://datatracker.ietf.org/meeting/116/materials/slides-116-dispatch-gordian-envelope-dcbor-00.pdf [8]: https://datatracker.ietf.org/doc/draft-mcnally-envelope/ [9]: https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/ [10]: https://datatracker.ietf.org/doc/html/rfc8949#section-4.2 [11]: https://mailarchive.ietf.org/arch/msg/dispatch/rgbPbRS0Oq_hekpMK2mPDdUK2pU/ [12]: https://datatracker.ietf.org/doc/draft-liu-protocol-interactive-media-transmission/ [13]: https://mailarchive.ietf.org/arch/msg/dispatch/Sx1EeYyynPM-2AEm4lrXUDVH4Kg/ [14]: https://datatracker.ietf.org/doc/draft-valin-opus-extension/ [15]: https://datatracker.ietf.org/doc/draft-valin-opus-dred/ [16]: https://mailarchive.ietf.org/arch/msg/dispatch/pBXW4rWl0oC2Cgck9bJUDq-iXY8/ [17]: https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi [18]: https://datatracker.ietf.org/doc/bofreq-happel-structured-email/