Minutes IETF116: dispatch: Mon 00:30
minutes-116-dispatch-202303270030-00
| Meeting Minutes | Dispatch (dispatch) WG | |
|---|---|---|
| Date and time | 2023-03-27 00:30 | |
| Title | Minutes IETF116: dispatch: Mon 00:30 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2023-03-26 |
DISPATCH Hybrid Meeting @IETF-116
Monday 27 March 2023
Room: G401-G402
09:30-11:30 Local
Log into the IETF datatracker to access:
DISPATCH Meeting
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
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)
Presenter: Manu Sporny (Remote)
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)
Presenter: Christopher Allen & Wolf McNally (Remote)
Gordian Envelope & dCBOR
(slides-116-dispatch-gordian-envelope-dcbor)
draft-mcnally-deterministic-cbor/ for RFC8949 §4.2
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)
Presenter: Dapeng Liu (Remote)
draft-liu-protocol-interactive-media-transmission
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)
Presenter: Jean-Marc Valin (On site)
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)
Presenter: Sri Gundavelli (On site)
draft-gundavelli-dispatch-e911-wifi
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
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
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)
Presenter: Hans-Joerg Happel (On site)
Structured Email (SML)
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/