DISPATCH Hybrid Meeting @IETF-114

Monday 25 July 2022

Room: Liberty C, Ballroom

10:00-12:00 UTC-4

Log into the IETF datatracker to access:

• MeetEcho

• Notes

• Jabber

DISPATCH Meeting

Status and Agenda Bash - Chairs and ADs (10 min)

Some queuing issues through MeetEcho - queue to be manually managed.

Binary Application Record Encoding (BARE) (20 min)

Presenter: Jiri Vlasak

draft-devault-bare-07

Messages

Richard Barnes: I appreciate where this work is coming from. What we did
with compact encoding and TLS encoding is 90% similar to this. It would
be useful to have a spec that just encapsulated the syntax as opposed to
continue referencing section four of rfc446 and to extend it a little
bit to cover what people expect from a modern encoding system. I agree
there's a bunch of other binary encoding systems, but we've had success
with making standards around TLS syntax so my inclination is that I'm
supportive of a small focused WG to align this work with TLS syntax and
address the difference.

Eric Rescorla: I'm concerned with the deployment situation - lots of
existing things like this, none of them are standards - indicates there
isn't much interest in standardising it. It would be unhelpful to
standardise without a market desire right now. So which large
constituencies wish to use this technology?

Jiri Vlasak: BARE is used at least by SourceHut, the company of the
creator of the encoding, and they use it for web tokens for storing web
tokens and communications with clients. This is the usecase which is
used today.

Eric Rescorla: We can agree that SourceHut is much smaller than Facebook
and Google.

Jiri Vlasak: Also feedback from mailing list that some researchers would
also like to use it so they can use something other than JSON for
receiving data from the sensors because of measurements. This is why we
have full compliance with IEEE 754 floating numbers.

Eric Rescorla: My comment is this should go nowhere until more people
want it and SourceHut is not even close to enough.

Jiri Vlasak: If you need a giant company like Google to pick up this
specification, I can offer nothing - I don't have such a company.
However, there is a need for standardisation like BARE that would be
simply implemented, safe, concise and practical.

Kirsty Paine: An implementation is an implementation, it doesn't need to
be anti-competitive in that only a certain size of implementor counts.
However the point might be more about having multiple vendors interested
as noted in Jabber.

Cullen Jennings: I think it would be useful to standardise something
along these lines at IETF, because we keep rebuilding it and doing a
slightly different variant each time - in TLS, then in MLS - and now in
several drafts I'm writing. I think it would help us write drafts to
have a tool we could pull out of the box if we sometimes wanted it.
Sometimes we would use CBOR, sometimes this, sometimes other things. So
I think it would be useful to pick one of these - maybe this one, maybe
the TLS one, I don't really care - but to form something that we can
refer to and is standardised, and is roughly along about the level of
weight and complexity of what you're proposing here. Basically it has
exactly the sort of characteristics that something you are proposing. If
there were no other proposals, I would be fine with BARE, it suits my
needs exactly. I think it would be worth doing something like this - not
sure if a small WG is the right way, or a small bake-off with a few
proposals, but I'd be in favour of having something.

Kirsty Paine: Someone in Jabber agreed with you.

Barry Leiba: Agree with Eric. The overhead to standardise something like
this in IETF is high. We need to be sure that we need it and that it
will be adopted, that there is a pressing need. I am one of the CBOR
co-chair, I would support discussing it in CBOR. I think Paul's comment
is right that this should have been discussed in CBOR, if this adds or
if CBOR can be enhanced, and then whether to see if this is still
needed. Highly recommend that it is not AD sponsored for the work like
this as the previous AD. Needs a WG - whether CBOR or a new one. But
let's make sure there is a need for it first.

John Klensin: I agree with Barry and Eric. Every additional one of these
leads to an interoperability problem because it pulls us into a
different direction. I worry about the need for this, I worry about the
compression arguments given the world and bandwidths we live in today.
If we proceed with this, I'd rather see an IRTF RG or an ART area design
team gather all the formats and study it to agree on something. A single
standard for this class of things would be fine, starting the discussion
in CBOR would be fine - but I don't want several of things moving in
different directions creating an interoperability problem for the
Internet.

David Schinazi: +1 to the folks who said this before. The reason we have
17 non-standards is that every company builds their own to fit their
specific needs. That's why Google has protobuf because we don't want to
standardise here and not be able to change it as they like. Don't see
the need to proceed in IETF until other vendors are interested in
implementing this, there needs to be market interest from outside one
implementor.

Kirsty Paine: We need to see more interests/adoption/support rather than
only one company for the work to proceed - the problem space is a
reasonable thing to address but we need a collective agreement on the
proposal to proceed with and multiple implementors who will hand over
change control.

Dispatch outcome: A possible WG or discussion forum on this problem
space, as it repeatedly comes up, but not necessarily this proposal -
needs to be more widely applicable than only one company (possibly this
is why it has not been standardised thus far, because it is
company-specific) and have multiple implementors. Therefore: find more
supporters and then return with this proposal (and possibly others) for
WG-scoping.

Transparently decrypting URIs (20 min)

Presenter: Bron Gondwana

Slides

Messages

Ted Hardie: It is a scope question. Back on Slide 4, you had party A, B,
C, but it's not clear what happens if you got more parties like D, E,
F... Does each party use the same decryption key? It's hard to see with
a shared key how it couldn't be shared further. It would be useful to
clarify the scope.

Bron Gondwana: Realistically, if you get a copy of the URI with the key,
you are Party B; if not, you are Party C. There can be 1 or n of each of
these parties. The key is a small version of the large data,
conceptually. So if you have the key, you can see the content.
Otherwise, you cannot.

Ted Hardie: Need to think if you would be better having two URIs that
have a relationship, like this is a URI where you can retrieve the key
and a URI where you can find the data.

Bron Gondwana: How do you pass that in the existing channels that accept
exactly one URI?

Ted Hardie: Everything can be solved with one more layer of indirection.
What you're describing doesn't have strong confidentiality
characteristics in the multi-party case. So you need to write a draft
for the security consideration describing about the confidentiality
characteristics as well as others.

Bron Gondwana: Yes, this is very early stage. Does the IETF want to do
this? If so, where should it happen? A lot more design work to do.

Ted Hardie: Dispatch answer is not yet.

Bron Gondwana: The confidentiality is Party B can leak the key to
whoever they want to. But we want to make it hard to do that
accidentally. Same as if you sent them the raw file. But we dont want
them to leak easily.

John Levine: It is not a new problem, had this issue going back about 20
years. When email was medium-sized, we evolved and now it's even bigger.
Trying to invent a new URI format would give heartburn to the people who
worry about the URI syntax.

Bron Gondwana: I don't want to do it at that level, don't want another
custom format. So would prefer to do it with a system library.

John Levine: So it is basically adding a decryption key to the URI?

Bron Gondwana: Yes. In a way it doesnot get to the server automatically.

Kirsty Paine: Does that affect your view in the dispatch outcome?

John Levine: Still think it's a problem worth solving. Ted and I hear
different issues, so it needs more details. If there weren't an
appropriate WG, if it came from email, I suppose it goes to one of those
email WGs.

Bron Gondwana: I don't think an email WG is the right place. Don't want
to do it in the MIME headers. It is better to do it inside URI.

John Levine: I do think it's worth solving the problem because people do
this at a hacky level.

Kirsty Paine: Ok, you think it is worth doing but more details are
needed in the draft.

Eric Rescorla: Generally worth doing. Not so concerned about security
properties, as you said - someone can just leak the raw file. This seems
small, so HTTP is a good fit, seems like it sort of belongs - or else
will have to be a new group, which seems heavyweight. But Mark
Nottingham will correct. TIGRESS has a bigger remit where this might get
lost in this.

Mark Nottingham: Area prone to over-engineering if we're not careful.
You could fragment the URI, which requires a format, with a fragment
identifier. The important thing is to describe the security properties
in the draft and move from there. Other venues or approaches might
become difficult.

Dispatch outcome: Work is worth doing, more specifics need detailing
so that the work can be properly assessed and sent to the right place.
Some hear S/MIME similarities, others hear HTTP. Return with a draft for
the work to progress.

Privacy Considerations for Web Feed Readers (20 min)

Presenter: Mark Nottingham

draft-nottingham-feed-privacy-00

Messages

Paul Hoffman: Surprised not to see more support. This is good - adding
privacy, even talking about privacy - this is a good thing. RSS feeds
are still around - would make sense to improve this poor current state.

Jabber shows support for getting folks thinking about RSS feeds more.

Dispatch outcome: Creation of a non-WG mailing list on this topic
(possibly feeds@ ietf, not only privacy-focused).

New UUID Formats (20 min)

Presenter: Kyzer Davis

draft-peabody-dispatch-new-uuid-format-04

Messages

David Schinazi: This is exactly what we would like to hear. I would like
to see this published, it seems useful. Dispatch opinion is that
AD-sponsorship would be the simplest way forward, or a tightly scoped WG
with one deliverable would work.

Cullen Jennings: Forming a WG to support UUIDs, lots of subtle
complexities. Having a long-term place for these updates would be
helpful, why things are the way they are would be helpful. Lots of
errata on those drafts, wow! We should be maintaining those better.
Favour of a WG group.

Alissa Cooper: Agree with Barry not AD Sponsored.
Eric Rescorla: It should be focused WG.
Murray: Who want to help charter? I can take the AD role.

Dispatch outcome: Weak support for a WG forming; take to dispatch
mailing list to find volunteers to form a charter for this - will
discuss and work out whether it's a small, tightly-focused WG on one
draft or a longer-term care-taker for UUIDs and maintenance.

Discarding Priority of RTP Video Packets (10 min)

Presenter: Lijun Dong

draft-dong-priority-rtp-packet-00

Messages

Mo Zanaty: These are two separate problems. One is the priority in the
RTP header. The other is to map to the DSCP, then that goes to TSV area.

Pete Resnick: People who can evaluate this are in AVTCore, dispatch
should be to send there for assessment. Someone said on Jabber perhaps
TSVwg could take on the DSCP bits.

Magnus Westerland: Perhaps you could take this to AVTCore. Multi-stream
aspect of this makes doing this across all media streams blindly
non-optimised! What are you trying to accomplish here? But AVTCore is a
good place to discuss RTP and usage.

Lijun Dong: Want to use those bits in the network layer when congestion
happens, instead of randomly discarding packets, if the router can know
which packet is better for decoding, maybe it's better to expose those
bits.

Magnus Westerland: You still need to explain the application, because
it's not clear that this is the best way to achieve that.

Mo Zanaty: You don't want restrict yourself to Layer 2, DSCP. Look at
WiFi, upstream priorities, mobile networks, RANs etc. DSCP is not going
to give a lot of benefits, especially since it's not carried through
interoperably. If you really want to optimise, you have to do it across
layers and give guidance at each layer.

Lijun Dong: I agree that DSCP has the remarking issue that won't be
carried end to end.

Mirja Kuhlewind: You need to show not only the use case, but that this
is an improvement on the current performance. Show what you gain. TSVWG
and AVTCore are fine places to go.

Mirja Kuhlewind: ECN also reflects the network congestion.

Omer Shapira: From Apple. UDP is not sensitive reordering.

Lijun Dong: I am aware of this issue.

Toerless Eckert: There are results to show the benefits of dropping
packets of video.

Jonathan Lennox: AVTCore chair, agrees it's in scope for AVTCore and
TSVWG do the DSCP part.

Dispatch outcome: The use case needs clarifying, and that gains in
performance need demonstrating (also from the list). Update these
aspects, and take to AVTCore and TSVWG for the DSCP-specific aspects.

Summary - DISPATCH outcomes

BARE dispatch outcome: possible WG or discussion forum on this topic,
as it repeatedly comes up, but not necessarily this proposal - needs to
be more widely applicable than only one company (possibly this is why it
has not been standardised thus far, because it is company-specific).
Therefore: find more supporters and then return with this proposal (and
possibly others) for WG-scoping.

Transparently decrypting URIs dispatch outcome: Work is worth doing,
more specifics need detailing so that the work can be properly assessed
and sent to the right place. Some hear S/MIME similarities, others hear
HTTP. Return with a draft for the work to progress.

Web Feed Reader dispatch outcome: Creation of a non-WG mailing list on
this topic (possibly feeds@ ietf, not only privacy-focused).

UUID dispatch outcome: Weak support for a WG forming; take to dispatch
mailing list to find volunteers to form a charter for this - will
discuss and work out whether it's a small, tightly-focused WG on one
draft or a longer-term care-taker for UUIDs and maintenance.

Discarding Priority of RTP Video Packets dispatch outcome: The use
case needs clarifying, and that gains in performance need demonstrating
(also from the list). Update these aspects, and take to AVTCore and
TSVWG for the DSCP-specific aspects.

ART AREA Meeting

---

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

Murray Kucherawy presenting on ART area topics, including:

• a clarification on the errata process and a call for help - please
  help out with processing errata.
• please volunteer to be a document shepherd, IANA requests, working
  group chairs, etc.
• review team members - contact Barry Leiba to volunteer, about 1-5
  per year
• i18ndir

Flextime & AOB (10 min)

MIMI side meeting & SPIN draft: IETF has been working for decades on
interoperability between app-to-app video calls, messaging,
conferencing. None of that works because of business commercial reasons,
but the Digital Markets Act might change things and that's why MIMI is
being formed.

Draft:
https://www.ietf.org/archive/id/draft-rosenberg-dispatch-spin-00.txt

Meeting at 4pm today in the Philadelphia South room, mezzanine level.