[{"author": "Ted Hardie", "text": "

If you can take notes locally, we can integrate them later

", "time": "2022-07-27T14:00:08Z"}, {"author": "Richard Barnes", "text": "

lol, kudos to the chairs, can't believe this is the first Gritty i've seen this IETF

", "time": "2022-07-27T14:00:11Z"}, {"author": "Cullen Jennings", "text": "

test

", "time": "2022-07-27T14:00:46Z"}, {"author": "Richard Barnes", "text": "

ack

", "time": "2022-07-27T14:01:52Z"}, {"author": "Richard Barnes", "text": "

there is like 1500ms of latency on the chat, kind of baffling

", "time": "2022-07-27T14:02:07Z"}, {"author": "Juliusz Chroboczek", "text": "

Meetecho, I'm getting distortion from Ted Hardie's mike.

", "time": "2022-07-27T14:02:31Z"}, {"author": "Lucas Pardue", "text": "

me too

", "time": "2022-07-27T14:02:52Z"}, {"author": "Hang Shi", "text": "

Ok, I can take notes locally

", "time": "2022-07-27T14:03:01Z"}, {"author": "Suhas Nandakumar", "text": "

Morning Everyone

", "time": "2022-07-27T14:03:35Z"}, {"author": "Alan Frindell", "text": "

Also appreciate any other help for the note takers

", "time": "2022-07-27T14:03:55Z"}, {"author": "Murray Kucherawy", "text": "

+1, thanks for those assisting

", "time": "2022-07-27T14:04:18Z"}, {"author": "Murray Kucherawy", "text": "

~100 people in the room for those curious

", "time": "2022-07-27T14:04:37Z"}, {"author": "Kyle Rose", "text": "

Ted, I think you are clipping. You should lower the gain of your mic, not just move farther from it.

", "time": "2022-07-27T14:04:50Z"}, {"author": "Tommy Jensen", "text": "

is the double negative in the final question intentional?

", "time": "2022-07-27T14:05:25Z"}, {"author": "Murray Kucherawy", "text": "

It is not.

", "time": "2022-07-27T14:05:41Z"}, {"author": "Spencer Dawkins", "text": "

Hmmm - the questions don't include \"willing to write/edit documents\". I guess plenty of people have already stepped forward.

", "time": "2022-07-27T14:07:46Z"}, {"author": "Kirill Pugin", "text": "

q: does it imply that protocol will be on top of QUIC datagrams only?

", "time": "2022-07-27T14:09:56Z"}, {"author": "Murray Kucherawy", "text": "

The charter said streams or datagrams, I think.

", "time": "2022-07-27T14:10:11Z"}, {"author": "Jonathan Lennox", "text": "

I feel like there's something wonky about the grammar of the bullet point

\n", "time": "2022-07-27T14:10:19Z"}, {"author": "Martin Thomson", "text": "

@Kirill Pugin the charter says streams or datagrams or both

", "time": "2022-07-27T14:10:20Z"}, {"author": "Alex Chernyakhovsky", "text": "

you can do adaptive streaming with QUIC pluggable congestion controllers on streams

", "time": "2022-07-27T14:10:30Z"}, {"author": "Kirill Pugin", "text": "

@Martin Thomson, yes, I was confused by milestones, where it says \"WG adoption of Protocol Specification for Datagram Extension to Media Publication
\nProtocol over QUIC\"

", "time": "2022-07-27T14:11:27Z"}, {"author": "Pete Resnick", "text": "
    \n
  1. \"will be a push protocol for sending media\"
    2. \n
  2. \"The mechanism to name and receive media will enable:
    \n\u2022 Requesting the server start sending\"
    \n??? Sounds like a pull to me.
    3. \n
", "time": "2022-07-27T14:11:46Z"}, {"author": "Murray Kucherawy", "text": "

Perhaps: \"This solution will address X, Y, and Z, and may cover other use cases.\"

", "time": "2022-07-27T14:11:49Z"}, {"author": "Glenn Deen", "text": "

Is the intent to develop a single solution that addresses ALL or multiple, possibly related, but possibly distinct solutions?

", "time": "2022-07-27T14:11:53Z"}, {"author": "Glenn Deen", "text": "

cause this is very broad covering a lot of media with very different charateristics and demands

", "time": "2022-07-27T14:12:32Z"}, {"author": "Kyle Rose", "text": "

Mic

", "time": "2022-07-27T14:12:36Z"}, {"author": "Jonathan Lennox", "text": "

Can someone post the link to the github repo for PRs?

", "time": "2022-07-27T14:13:19Z"}, {"author": "Pete Resnick", "text": "

Hey! I just said what Victor said! :wink:

", "time": "2022-07-27T14:13:37Z"}, {"author": "Suhas Nandakumar", "text": "

https://github.com/moq-wg/moq-charter

", "time": "2022-07-27T14:13:44Z"}, {"author": "Pete Resnick", "text": "

Why even call it a push protocol?

", "time": "2022-07-27T14:13:57Z"}, {"author": "Martin Thomson", "text": "

https://github.com/moq-wg/moq-charter/blob/main/charter.md

", "time": "2022-07-27T14:13:59Z"}, {"author": "Kirill Pugin", "text": "

@Victor, should we change \"request media and encodings\" to \"receive media and encodings\"

", "time": "2022-07-27T14:14:18Z"}, {"author": "Eric Kinnear", "text": "

@Ted Hardie audio better but still a bit distorted, any way to lower the gain a bit?

", "time": "2022-07-27T14:14:45Z"}, {"author": "Lucas Pardue", "text": "

s/request/solicit

", "time": "2022-07-27T14:14:49Z"}, {"author": "Pete Resnick", "text": "

\"Push\" seems to me to imply \"unsolicited\".

", "time": "2022-07-27T14:15:01Z"}, {"author": "Lucas Pardue", "text": "

;)

", "time": "2022-07-27T14:15:13Z"}, {"author": "Martin Thomson", "text": "

\"solicit\" is just a synonym. can we be clear about what the semantics of the protocol will look like?

", "time": "2022-07-27T14:15:34Z"}, {"author": "Lucas Pardue", "text": "

+1 MT

", "time": "2022-07-27T14:15:48Z"}, {"author": "Martin Thomson", "text": "

It seems to me that what you really have for distribution is pull. Push for ingest works.

", "time": "2022-07-27T14:16:18Z"}, {"author": "Kirill Pugin", "text": "

push for distribution also can work

", "time": "2022-07-27T14:16:37Z"}, {"author": "Alan Frindell", "text": "

I think the intent is that the media is pushed, rather than requested segment by segment

", "time": "2022-07-27T14:16:52Z"}, {"author": "Kirill Pugin", "text": "

but it needs to be bidir as Cullen is saying right now

", "time": "2022-07-27T14:17:02Z"}, {"author": "Lucas Pardue", "text": "

it's sounds like pub/sub

", "time": "2022-07-27T14:17:10Z"}, {"author": "Kirill Pugin", "text": "

@Lucas, exactly! :D

", "time": "2022-07-27T14:17:20Z"}, {"author": "Martin Thomson", "text": "

@Alan Frindell if you are pushing in response to a request, it's a response to a request, even if there is lots of stuff that you need to send

", "time": "2022-07-27T14:17:41Z"}, {"author": "Alan Frindell", "text": "

agreed

", "time": "2022-07-27T14:17:52Z"}, {"author": "Glenn Deen", "text": "

+1 to Kyle's point

", "time": "2022-07-27T14:18:00Z"}, {"author": "Ali Begen", "text": "

Gaming requires interactivity in almost all modern games.

", "time": "2022-07-27T14:18:15Z"}, {"author": "Christian Huitema", "text": "

The DNS over QUIC use case was ther efrom the beginning

", "time": "2022-07-27T14:18:31Z"}, {"author": "Pete Resnick", "text": "

+1 to Luke.

", "time": "2022-07-27T14:18:53Z"}, {"author": "Martin Thomson", "text": "

@Juliusz Chroboczek @Kyle Rose you are still in queue

", "time": "2022-07-27T14:18:58Z"}, {"author": "Murray Kucherawy", "text": "

Please remember to depart the queue once you've said your bit.

", "time": "2022-07-27T14:19:07Z"}, {"author": "Juliusz Chroboczek", "text": "

Thanks, corrected.

", "time": "2022-07-27T14:19:11Z"}, {"author": "Spencer Dawkins", "text": "

Could the chairs ask \"who else would have said this at the mike?\", rather than wait for each of us to get up and say the same thing?

", "time": "2022-07-27T14:19:16Z"}, {"author": "Christian Huitema", "text": "

Having at least 2 use cases is a good way to avoid over-specialization

", "time": "2022-07-27T14:19:22Z"}, {"author": "Kyle Rose", "text": "

Sorry, I mean game streaming (e.g., twitch)

", "time": "2022-07-27T14:19:26Z"}, {"author": "Mirja K\u00fchlewind", "text": "

the chairs can/should remove them from the queue

", "time": "2022-07-27T14:19:29Z"}, {"author": "Kyle Rose", "text": "

Gaming is surely low-latency interactive like video conferencing

", "time": "2022-07-27T14:19:38Z"}, {"author": "Ali Begen", "text": "

ack

", "time": "2022-07-27T14:20:14Z"}, {"author": "Juliusz Chroboczek", "text": "

I think Kyle was thinking of the twitch usecase, which is just video-streaming with a medium-latency chat in the opposite direction.

", "time": "2022-07-27T14:20:31Z"}, {"author": "Spencer Dawkins", "text": "

I'm going to say something about \"low-latency\", but I'll try not to say the same thing again ...

", "time": "2022-07-27T14:20:36Z"}, {"author": "Martin Thomson", "text": "

@Victor Vasiliev ... Luke's point was that this is a design detail, not something that needs to be encoded in a charter.

", "time": "2022-07-27T14:21:07Z"}, {"author": "Kyle Rose", "text": "

Ideally, everything is low latency. So we obv need to come up with definitions for kinda-low latency, definitely low latency, super low latency, ultra low latency, and nearly-instantaneous low-latency.

", "time": "2022-07-27T14:21:54Z"}, {"author": "Lucas Pardue", "text": "

the solution is to just use numbers of your upper latency bound

", "time": "2022-07-27T14:22:29Z"}, {"author": "Alex Chernyakhovsky", "text": "

Is the issue \"low-latency\", or is the issue \"interactive\"? Latency is important for live streams/meetings, but it's way the heck more important for cloud gaming

", "time": "2022-07-27T14:22:55Z"}, {"author": "Juliusz Chroboczek", "text": "

I'm okay with that if people agree it's in scope.

", "time": "2022-07-27T14:22:56Z"}, {"author": "Juliusz Chroboczek", "text": "

Thanks.

", "time": "2022-07-27T14:23:01Z"}, {"author": "Spencer Dawkins", "text": "

+1 Bernard, but we should seriously be asking \"who agrees with that statement\" as we go.

", "time": "2022-07-27T14:24:07Z"}, {"author": "Murray Kucherawy", "text": "

If we fork this into multiple working groups, would it be multiple working groups with the same participants anyway? Would that force serialization of the work?

", "time": "2022-07-27T14:24:22Z"}, {"author": "Cullen Jennings", "text": "

https://github.com/moq-wg/moq-charter/pull/52 proposed change to charter ti reove push

", "time": "2022-07-27T14:24:42Z"}, {"author": "Gorry Fairhurst", "text": "

Is it possible to encourage using the tool to track who is talking... it's slightly harder for a remote particpant to see who was talking when people wear masks?

", "time": "2022-07-27T14:25:19Z"}, {"author": "Jonathan Lennox", "text": "

https://github.com/moq-wg/moq-charter/pull/51 PR to fix the grammar issue I mentioned, and to make the rate adaptation bullet point more general

", "time": "2022-07-27T14:25:48Z"}, {"author": "Murray Kucherawy", "text": "

The tool should show you through animation who's talking. The browser version does at least.

", "time": "2022-07-27T14:26:06Z"}, {"author": "Kyle Rose", "text": "

Christian Huitema said:

\n
\n

Having at least 2 use cases is a good way to avoid over-specialization

\n
\n

Agreed, but 2 is still a lot smaller than the N being discussed here. And as I think we're seeing with QUIC, it's mostly important that enough people with different use cases be involved enough to say \"keep in mind we want to do X in the future, so don't bake in something that precludes that\". IMO, this effort will be most successful if it focuses on a clear, well-defined use case as a first deliverable.

", "time": "2022-07-27T14:26:12Z"}, {"author": "Spencer Dawkins", "text": "

Gorry Fairhurst said:

\n
\n

Is it possible to encourage using the tool to track who is talking... it's slightly harder for a remote particpant to see who was talking when people wear masks?

\n
\n

It's not a breeze for us, either! I'm not complaining, just noting this is a challenge.

", "time": "2022-07-27T14:26:29Z"}, {"author": "Spencer Dawkins", "text": "

+1 Kyle

", "time": "2022-07-27T14:27:13Z"}, {"author": "Murray Kucherawy", "text": "

+1 Ted.

", "time": "2022-07-27T14:27:16Z"}, {"author": "Pete Resnick", "text": "

Ted's mic has very good gain. :wink:

", "time": "2022-07-27T14:28:21Z"}, {"author": "Kiran Makhijani", "text": "

if the use cases are limited or modified - will it also change the type of endpoints involved?

", "time": "2022-07-27T14:29:55Z"}, {"author": "Pete Resnick", "text": "

Note that limiting the use cases in the charter doesn't mean that the WG can't ever work on other use cases; it just requires going back to the IESG to re-charter.

", "time": "2022-07-27T14:32:17Z"}, {"author": "Murray Kucherawy", "text": "

+1 Pete

", "time": "2022-07-27T14:32:55Z"}, {"author": "Murray Kucherawy", "text": "

Which is not to say that's a requirement, just one possible path.

", "time": "2022-07-27T14:33:22Z"}, {"author": "Juliusz Chroboczek", "text": "

Which draft was just referred to?

", "time": "2022-07-27T14:33:41Z"}, {"author": "Juliusz Chroboczek", "text": "

\"individual draft has no stnading\"?

", "time": "2022-07-27T14:33:59Z"}, {"author": "Alan Frindell", "text": "

as in not adopted by any working group I assume?

", "time": "2022-07-27T14:34:19Z"}, {"author": "Murray Kucherawy", "text": "

I imagine there's some risk that if you say \"A first, then B\", you can develop A without considering B at all, and the risk of boxing yourself in increases.

", "time": "2022-07-27T14:34:27Z"}, {"author": "Ted Hardie", "text": "

I would say \"media distribution\" protocol is the building block we're aiming for.

", "time": "2022-07-27T14:34:45Z"}, {"author": "Juliusz Chroboczek", "text": "

I'd like to know which concrete draft that is.

", "time": "2022-07-27T14:34:54Z"}, {"author": "Ted Hardie", "text": "

If you specialize too early in that, you end up with a bad building block for the others.

", "time": "2022-07-27T14:35:06Z"}, {"author": "James Gruessing", "text": "

There is no \"Distribution\" without \"Contribution\" Ted ;)

", "time": "2022-07-27T14:35:11Z"}, {"author": "Kirill Pugin", "text": "

+100 to what @Cullen is saying

", "time": "2022-07-27T14:35:13Z"}, {"author": "Suhas Nandakumar", "text": "

+1 on what fluffy said

", "time": "2022-07-27T14:35:13Z"}, {"author": "Alan Frindell", "text": "

https://datatracker.ietf.org/doc/html/draft-gruessing-moq-requirements

", "time": "2022-07-27T14:35:25Z"}, {"author": "Pete Resnick", "text": "

Thanks Cullen. That helped clarify what the desire is. Perhaps that should be said in the charter.

", "time": "2022-07-27T14:35:39Z"}, {"author": "Ted Hardie", "text": "

contribution is just inbound distribution

", "time": "2022-07-27T14:35:40Z"}, {"author": "Spencer Dawkins", "text": "

Which draft was just referred to?

\n

10:33
\n\"individual draft has no stnading\"?

", "time": "2022-07-27T14:35:42Z"}, {"author": "Glenn Deen", "text": "

a unified tool is a spork, but we all still prefer spoons, knifes, and forks because they do their tasks really well together.

", "time": "2022-07-27T14:35:52Z"}, {"author": "Juliusz Chroboczek", "text": "

Thanks Alan.

", "time": "2022-07-27T14:35:52Z"}, {"author": "Spencer Dawkins", "text": "

Which draft was just referred to?

\n

10:33
\n\"individual draft has no stnading\"?

", "time": "2022-07-27T14:36:05Z"}, {"author": "Pete Resnick", "text": "

What Fluffy said was not clear to me in the current charter text.

", "time": "2022-07-27T14:37:00Z"}, {"author": "Spencer Dawkins", "text": "

Thanks, Alan - that's the one. And the draft hasn't been adopted by any working group, because we're trying to create the working group now :smile:

", "time": "2022-07-27T14:37:16Z"}, {"author": "Glenn Deen", "text": "

cases like inject depend highly reliable behavior whereas most distribution cases do not - that's just one big difference.

", "time": "2022-07-27T14:37:35Z"}, {"author": "Ted Hardie", "text": "

@Glenn, I don't think we're looking at swiss army knife here, but Lego blocks; from those you can build lots of things.

", "time": "2022-07-27T14:37:40Z"}, {"author": "Kiran Makhijani", "text": "

maybe saying 'live streaming usecases' in the charter is a better way to go about it.

", "time": "2022-07-27T14:38:06Z"}, {"author": "Martin Thomson", "text": "

I've never heard mandatory pronounced as mandate-ory. I know it makes sense, but that threw me.

", "time": "2022-07-27T14:40:34Z"}, {"author": "Glenn Deen", "text": "

@Ted - that's not what I'm hearing when it's described as a unified tool. Perhaps integrated tool?

", "time": "2022-07-27T14:40:45Z"}, {"author": "Eric Rescorla", "text": "

-1 on \"ends-to-ends\"

", "time": "2022-07-27T14:40:48Z"}, {"author": "Kyle Rose", "text": "

So, I'm confused: are we designing a generic media distribution system or a point-to-point transport on top of QUIC? The latter is reasonably well-defined, even if the required properties will differ based on the specific use case (as Glenn noted); but the former is exactly the kind of worm-can this group really, really needs to avoid.

", "time": "2022-07-27T14:40:57Z"}, {"author": "Juliusz Chroboczek", "text": "

Martin: welcome to the world of non-native speakers... we're thrown off by the pronunciation of English constantly ;-)

", "time": "2022-07-27T14:41:13Z"}, {"author": "Eric Rescorla", "text": "

Are the slides here somewhere?

", "time": "2022-07-27T14:41:33Z"}, {"author": "Alex Chernyakhovsky", "text": "

I don't understand what ends-to-ends means

", "time": "2022-07-27T14:41:39Z"}, {"author": "Kyle Rose", "text": "

Pub/sub-style one-to-many or many-to-many distribution should explicitly be out of scope for this effort.

", "time": "2022-07-27T14:41:56Z"}, {"author": "Martin Thomson", "text": "

Eric Rescorla said:

\n
\n

Are the slides here somewhere?

\n
\n

https://datatracker.ietf.org/meeting/114/materials/slides-114-moq-chair-slides-for-moq-bof-00

", "time": "2022-07-27T14:41:58Z"}, {"author": "Behcet Sarikaya", "text": "

Folks nobody is making the notes

", "time": "2022-07-27T14:42:20Z"}, {"author": "Pete Resnick", "text": "

Juliusz Chroboczek said:

\n
\n

Martin: welcome to the world of non-native speakers... we're thrown off by the pronunciation of English constantly ;-)

\n
\n

So are we.

", "time": "2022-07-27T14:42:35Z"}, {"author": "Ted Hardie", "text": "

The note taker is taking them locally because of a tool issue

", "time": "2022-07-27T14:42:41Z"}, {"author": "Kirill Pugin", "text": "

@Behcet, aren't Lucas is and someone else taking notes?

", "time": "2022-07-27T14:42:49Z"}, {"author": "Kirill Pugin", "text": "

maybe they do it not in the tool

", "time": "2022-07-27T14:43:02Z"}, {"author": "Lucas Pardue", "text": "

Luca*

", "time": "2022-07-27T14:43:15Z"}, {"author": "Behcet Sarikaya", "text": "

@Kirill Pugin that's what Ted is saying

", "time": "2022-07-27T14:43:40Z"}, {"author": "Kirill Pugin", "text": "

@Behcet Sarikaya, yeah I just slow at typing :D

", "time": "2022-07-27T14:44:10Z"}, {"author": "Jonathan Rosenberg", "text": "

I think it would be a good outcome here to have a protocol that can seamlessly move from real-time to buffered; the fact that we have a hard line today between protocols for these is a bad thing, not a good one.

", "time": "2022-07-27T14:44:30Z"}, {"author": "Kirill Pugin", "text": "

hm... noob question: why my tagging people doesn't work? :D

", "time": "2022-07-27T14:44:35Z"}, {"author": "Ted Hardie", "text": "

Just in case that wasn't clear, that was MOP not MoQ

", "time": "2022-07-27T14:44:39Z"}, {"author": "Jonathan Lennox", "text": "

MOPS

", "time": "2022-07-27T14:44:50Z"}, {"author": "Lucas Pardue", "text": "

this is a MOPS-to-MoQ push

", "time": "2022-07-27T14:45:30Z"}, {"author": "Glenn Deen", "text": "

+1 to Leslie's great points

", "time": "2022-07-27T14:45:50Z"}, {"author": "Kirill Pugin", "text": "

@Jonathan Rosenberg
\n+1, that what I was trying to say, probably not very well

", "time": "2022-07-27T14:45:58Z"}, {"author": "Juliusz Chroboczek", "text": "

Kirill, you were reasonably clear.

", "time": "2022-07-27T14:46:23Z"}, {"author": "Suhas Nandakumar", "text": "

+1 to what Jonathan said

", "time": "2022-07-27T14:46:26Z"}, {"author": "Spencer Dawkins", "text": "

Also +1 to Leslie about the relationship with MOPS.

", "time": "2022-07-27T14:48:08Z"}, {"author": "Christian Huitema", "text": "

To EKR: if we have relays, then encryption of content prevents relays from accessing it

", "time": "2022-07-27T14:48:09Z"}, {"author": "Jonathan Rosenberg", "text": "

+1 to @Eric Rescorla 's comment on \"NO on ends-to-ends\"

", "time": "2022-07-27T14:48:15Z"}, {"author": "Eric Rescorla", "text": "

Christian: yes, that was my impression, but my point is that this charter doesn't really say that

", "time": "2022-07-27T14:48:32Z"}, {"author": "Glenn Deen", "text": "

to EKR's point - QUIC encryption only protects on the wire, it does not protect at caching or reception.

", "time": "2022-07-27T14:49:15Z"}, {"author": "Alex Chernyakhovsky", "text": "

Can encryption of content be left to existing DRM systems?

", "time": "2022-07-27T14:49:18Z"}, {"author": "Luke Curley", "text": "

I interpret it as a way of saying \"support DRM\"

", "time": "2022-07-27T14:49:24Z"}, {"author": "Eric Rescorla", "text": "

Glenn: yes, I understand this point. My point is that the charter is unclear

", "time": "2022-07-27T14:49:34Z"}, {"author": "Luke Curley", "text": "

while exposing metadata to relays

", "time": "2022-07-27T14:49:39Z"}, {"author": "Martin Thomson", "text": "

@Eric Rescorla https://github.com/moq-wg/moq-charter/issues/57

", "time": "2022-07-27T14:49:50Z"}, {"author": "James Gruessing", "text": "

Luke: Was hoping that we'd treat DRM in an opaque fashion much like existing protocols today.

", "time": "2022-07-27T14:50:34Z"}, {"author": "Christian Huitema", "text": "

DRM is controversial. Maintaining confidentiality of the content of a multiparty conversation, less so.

", "time": "2022-07-27T14:50:37Z"}, {"author": "Alex Chernyakhovsky", "text": "

where is the usecase for confidentiality with relays outside of DRM coming from?

", "time": "2022-07-27T14:51:09Z"}, {"author": "Kirill Pugin", "text": "

Agree with @Christian, DRM have different goal than e2e encryption

", "time": "2022-07-27T14:51:25Z"}, {"author": "Jonathan Rosenberg", "text": "

@Alex Chernyakhovsky - audio and video conferencing

", "time": "2022-07-27T14:51:26Z"}, {"author": "Glenn Deen", "text": "

DRM is involves rights management - aka compliance with a complex set of use rules. Encryption at rest and protection from disclosure isn't necessarily DRM.

", "time": "2022-07-27T14:51:33Z"}, {"author": "Juliusz Chroboczek", "text": "

Re end-to-end, I think the charter is reasonably clear.

", "time": "2022-07-27T14:51:42Z"}, {"author": "Eric Rescorla", "text": "

@Alex Chernyakhovsky I would assume it comes from the same reason as any other E2E encryption, e.g., for messaging

", "time": "2022-07-27T14:52:04Z"}, {"author": "Martin Thomson", "text": "

@Eric Rescorla also https://github.com/moq-wg/moq-charter/issues/58

", "time": "2022-07-27T14:52:45Z"}, {"author": "Juliusz Chroboczek", "text": "

Alex: sharing confidential data with your colleagues without Zoom doing industrial espionage?

", "time": "2022-07-27T14:52:58Z"}, {"author": "Alex Chernyakhovsky", "text": "

But in E2E messaging we usually separate transport encryption from message encryption, and they're layered, no?

", "time": "2022-07-27T14:53:00Z"}, {"author": "Alex Chernyakhovsky", "text": "

does the same technique not work here?

", "time": "2022-07-27T14:53:10Z"}, {"author": "Eric Rescorla", "text": "

that is the case here as well. the transport encryption is quic

", "time": "2022-07-27T14:53:15Z"}, {"author": "Martin Thomson", "text": "

Alex Chernyakhovsky said:

\n
\n

does the same technique not work here?

\n
\n

Yes, maybe. But probably not.

", "time": "2022-07-27T14:53:26Z"}, {"author": "Luke Curley", "text": "

would explicitly mentioning DRM make more sense instead of hand-waving \"encryption\"?

", "time": "2022-07-27T14:53:29Z"}, {"author": "Eric Rescorla", "text": "

The message encryption is this

", "time": "2022-07-27T14:53:29Z"}, {"author": "Juliusz Chroboczek", "text": "

Alex: if you want the relay to be able to drop frames on congestion, you need to send some metadata in the clear.

", "time": "2022-07-27T14:53:41Z"}, {"author": "Lucas Pardue", "text": "

-1 to mentioning DRM

", "time": "2022-07-27T14:53:52Z"}, {"author": "Martin Thomson", "text": "

I say probably not because e2ee for messaging generally doesn't involve selective leaks to enable certain actions by intermediaries.

", "time": "2022-07-27T14:54:04Z"}, {"author": "Kirill Pugin", "text": "

-1 to DRM

", "time": "2022-07-27T14:54:27Z"}, {"author": "Eric Rescorla", "text": "

@MT: is that really true? For instance, e-mail with OpenPGP has addressing information in the clear (over TLS, of course)

", "time": "2022-07-27T14:54:41Z"}, {"author": "Juliusz Chroboczek", "text": "

You also need an integrity scheme that is not broken when you drop droppable frames.

", "time": "2022-07-27T14:54:47Z"}, {"author": "Kirill Pugin", "text": "

DRM more politics than technical problem

", "time": "2022-07-27T14:54:50Z"}, {"author": "Glenn Deen", "text": "

on encryption - consider the case of a private conversation where caching nodes can read the message in the clear from the cache.

", "time": "2022-07-27T14:54:52Z"}, {"author": "Martin Thomson", "text": "

@Eric Rescorla I think that the difference here is that the requirements for media might extend beyond addressing/reachability info.

", "time": "2022-07-27T14:55:15Z"}, {"author": "Alex Chernyakhovsky", "text": "

hm, if we want to drop frames, shouldn't there be work at the media layer so e.g., h264 or av1 have a concept of an encrypted frame...?

", "time": "2022-07-27T14:55:42Z"}, {"author": "Alex Chernyakhovsky", "text": "

otherwise I don't understand how we can expose a rich enough metadata that won't be fragile to new media formats

", "time": "2022-07-27T14:56:24Z"}, {"author": "Juliusz Chroboczek", "text": "

No, encryption happens at a higher layer. What the modern codecs provide is information in the header that indicates which pieces of data can be dropped without breaking subsequent frames.

", "time": "2022-07-27T14:56:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

is that actually a property of the codec, and not the container?

", "time": "2022-07-27T14:57:17Z"}, {"author": "Christian Huitema", "text": "

.. and that \"indication of what can be dropped\" needs to be available to the relays.

", "time": "2022-07-27T14:57:17Z"}, {"author": "Kirill Pugin", "text": "

@Juliusz, does that mean that encryption layer needs to be aware of that codec information?

", "time": "2022-07-27T14:57:22Z"}, {"author": "Juliusz Chroboczek", "text": "

Yes, unfortunately the metadata is codec-specific. So either you have codec-specific code in the relays, or you map all of the codec-specific data to a common data structure.

", "time": "2022-07-27T14:57:44Z"}, {"author": "Richard Barnes", "text": "

EKR's point about authentication is good. Maybe this protocol should assure that metadata is always E2E authenticated, and may be E2E encrypted.

", "time": "2022-07-27T14:57:48Z"}, {"author": "Eric Rescorla", "text": "

@Ted Hardie I would prefer the opposite: an MTI which can be overrided in specific use cases

", "time": "2022-07-27T14:58:05Z"}, {"author": "Juliusz Chroboczek", "text": "

@Kirill, yes, that's currently the case.

", "time": "2022-07-27T14:58:08Z"}, {"author": "Spencer Dawkins", "text": "

+1 to where Ted is headed ...

", "time": "2022-07-27T14:58:31Z"}, {"author": "James Gruessing", "text": "

+1 to ekr, and that mandatory format support stifles future agility in implementations

", "time": "2022-07-27T14:58:46Z"}, {"author": "Cullen Jennings", "text": "

I think the only data in the metadata is stuff that the system absoltyely can't work without the cache and server seeing.

", "time": "2022-07-27T14:58:49Z"}, {"author": "Luke Curley", "text": "

\"mandatory for some\" doesn't sound mandatory

", "time": "2022-07-27T14:58:49Z"}, {"author": "Alissa Cooper", "text": "

as long as \"MTI that can be overriden\" is just MTI without mandatory to use

", "time": "2022-07-27T14:59:12Z"}, {"author": "Richard Barnes", "text": "

E2E encryption does not preclude transcoding, it just requires that the transcoder be an end to the encryption

", "time": "2022-07-27T14:59:31Z"}, {"author": "Cullen Jennings", "text": "

Mandatory === \"we WISH YOU WOULD BUT KNOW YOU WON\"T\" - what's the RFC on that

", "time": "2022-07-27T15:00:48Z"}, {"author": "Richard Barnes", "text": "

RFC 6919

", "time": "2022-07-27T15:00:55Z"}, {"author": "Richard Barnes", "text": "

MUST (BUT WE KNOW YOU WON'T) https://datatracker.ietf.org/doc/html/rfc6919#section-1

", "time": "2022-07-27T15:01:15Z"}, {"author": "Ted Hardie", "text": "

Is there anyone in chat who feels they can write a PR that captures the changed encryption wording being proposed?

", "time": "2022-07-27T15:02:54Z"}, {"author": "Richard Barnes", "text": "

i can take a stab at it. what's the repo URL?

", "time": "2022-07-27T15:03:11Z"}, {"author": "Kirill Pugin", "text": "

why wouldn't we do caching for Live streaming?

", "time": "2022-07-27T15:03:12Z"}, {"author": "Kirill Pugin", "text": "

we do...

", "time": "2022-07-27T15:03:17Z"}, {"author": "Suhas Nandakumar", "text": "

https://github.com/moq-wg/moq-charter.

", "time": "2022-07-27T15:03:29Z"}, {"author": "Alex Chernyakhovsky", "text": "

the effect of caching for livestreaming diminishes as the buffer size of the stream decreases (ultra low latency, for example)

", "time": "2022-07-27T15:04:49Z"}, {"author": "Ali Begen", "text": "

The viewers dont decide on the codecs or the formats, the platforms they use pick them.

", "time": "2022-07-27T15:04:59Z"}, {"author": "Kirill Pugin", "text": "

@Luke, are you suggesting that we support only 1 format? what if in 10 years there is better format?

", "time": "2022-07-27T15:05:00Z"}, {"author": "Ted Hardie", "text": "

Once again, MTI doesn't mean Mandatory to Use; it does give you a way to confirm inter-operation.

", "time": "2022-07-27T15:05:32Z"}, {"author": "Kirill Pugin", "text": "

@Alex, well, if you have 1M viewers on ultra low latency - do you really want them all to go to your origin?

", "time": "2022-07-27T15:05:40Z"}, {"author": "Tommy Jensen", "text": "

@kirill I thought the point was to not require any specific format so that in future the one format can be chosen by the implementor? Not that we only define one here.

", "time": "2022-07-27T15:05:51Z"}, {"author": "Alex Chernyakhovsky", "text": "

No, we don't go to origin. But we do fanout from RAM

", "time": "2022-07-27T15:06:06Z"}, {"author": "Kirill Pugin", "text": "

RAM is cache - no?

", "time": "2022-07-27T15:06:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

I generally call things \"caching\" if we write it to durable storage

", "time": "2022-07-27T15:06:17Z"}, {"author": "Glenn Deen", "text": "

btw. DRM key management is usually done by separate a callout to a key server by a player. So that's not even the case I think we're discussing here about encryption.

", "time": "2022-07-27T15:06:20Z"}, {"author": "Christian Huitema", "text": "

If there is a specific broadcast, it makes sense to have a specific codec for that broadcast. If the broadcaster selects a poor;y supported codec, there will be fewer viewers...

", "time": "2022-07-27T15:06:21Z"}, {"author": "Eric Rescorla", "text": "

https://github.com/moq-wg/moq-charter/pull/59

", "time": "2022-07-27T15:06:51Z"}, {"author": "Alex Chernyakhovsky", "text": "

(because ram buffers mostly exist to save the storage media from to many iops, and we don't bother in the YT Live implementation to even think about hitting storage for ultra low latency streams)

", "time": "2022-07-27T15:07:06Z"}, {"author": "Lucas Pardue", "text": "

without an MTI format, you will possibly have to support all formats the different platforms decide to pick for coverage

", "time": "2022-07-27T15:07:17Z"}, {"author": "Luke Curley", "text": "

the charter allows peers to request encodings, so I interpret requesting the mandatory to implement encoding means that it must work

", "time": "2022-07-27T15:07:26Z"}, {"author": "Eric Rescorla", "text": "

@Luke Curley that is the usual intent

", "time": "2022-07-27T15:07:38Z"}, {"author": "Kirill Pugin", "text": "

@Alex, what if you have 1M viewing stream at 1s latency and 1M viewing same stream at 10s latency?

", "time": "2022-07-27T15:07:40Z"}, {"author": "Alex Chernyakhovsky", "text": "

I don't think YT supports multiple latency values for a single stream

", "time": "2022-07-27T15:08:09Z"}, {"author": "Alex Chernyakhovsky", "text": "

it's decided by the producer iirc

", "time": "2022-07-27T15:08:15Z"}, {"author": "Alex Chernyakhovsky", "text": "

so I don't have any experience with that sort of situation

", "time": "2022-07-27T15:08:21Z"}, {"author": "Juliusz Chroboczek", "text": "

I haven't thought about it seriously, but what about MTI for the receiver? E.g. a guarantee that if you send AV1+Opus, then all receivers must accept it?

", "time": "2022-07-27T15:08:31Z"}, {"author": "Luke Curley", "text": "

yeah, so if GIF is mandatory to implement, and a viewer requests GIF, then I must produce GIF even if 99% of viewers are using the better PNG format

", "time": "2022-07-27T15:08:48Z"}, {"author": "Eric Rescorla", "text": "

@Luke Curley depending on how it's written, yes. Sometimes it's just a requirement on clients

", "time": "2022-07-27T15:09:16Z"}, {"author": "Juliusz Chroboczek", "text": "

No, the opposite \u2014 if you put GIF on your webpage, then all compliant browsers will see the image.

", "time": "2022-07-27T15:09:28Z"}, {"author": "Luke Curley", "text": "

(using image formats to avoid codec wars)

", "time": "2022-07-27T15:09:29Z"}, {"author": "Christian Huitema", "text": "

Even for realtime, we can have events like clients loosing connectivity and reconnecting. You want to sevre them enough data from the cache to avoid big glitches in the video.

", "time": "2022-07-27T15:09:46Z"}, {"author": "Richard Barnes", "text": "

Encryption PR https://github.com/moq-wg/moq-charter/pull/60

", "time": "2022-07-27T15:10:12Z"}, {"author": "Alex Chernyakhovsky", "text": "

if a client loses connectivity for longer than the buffer size, there will always be big glitches in video

", "time": "2022-07-27T15:10:24Z"}, {"author": "Kirill Pugin", "text": "

fwiw, I am +1 on not requiring specific format - it gets outdated too quickly

", "time": "2022-07-27T15:10:32Z"}, {"author": "Richard Barnes", "text": "

(PR adopts EKR's suggestion for E2E authentication of metadata)

", "time": "2022-07-27T15:10:37Z"}, {"author": "Lucas Pardue", "text": "

if a client reqursts GIF and you don't want to, tell them to GOAWAY

", "time": "2022-07-27T15:10:44Z"}, {"author": "Luke Curley", "text": "

yeah for video distribution, we would not serve the viewer GIF because it's too expensive, as it requires transcoding and duplicated caching

", "time": "2022-07-27T15:11:07Z"}, {"author": "Suhas Nandakumar", "text": "

+1 on Lucaas

", "time": "2022-07-27T15:11:17Z"}, {"author": "Lucas Pardue", "text": "

that seems entirely reasonable Luke

", "time": "2022-07-27T15:11:25Z"}, {"author": "Glenn Deen", "text": "

The idea is that metadata is not monolithic.

", "time": "2022-07-27T15:11:51Z"}, {"author": "Luke Curley", "text": "

what does it mean to deny a mandatory codec? that seems contrary to the goal of interop

", "time": "2022-07-27T15:12:02Z"}, {"author": "Glenn Deen", "text": "

(Sorry I've lost my voice and can't join the mic)

", "time": "2022-07-27T15:12:05Z"}, {"author": "Behcet Sarikaya", "text": "

can someone summarize what Spencer said?

", "time": "2022-07-27T15:12:32Z"}, {"author": "Luke Curley", "text": "

the draft would say \"you MUST support gif\" but my server would lose the connection if you tried to use it

", "time": "2022-07-27T15:12:52Z"}, {"author": "Luke Curley", "text": "

seems like a spec violation to me

", "time": "2022-07-27T15:14:00Z"}, {"author": "Eric Rescorla", "text": "

yes, it is a spec violation

", "time": "2022-07-27T15:14:15Z"}, {"author": "Luke Curley", "text": "

at least in spirit

", "time": "2022-07-27T15:14:23Z"}, {"author": "Lucas Pardue", "text": "

I think it depends what what \"support \" really means

", "time": "2022-07-27T15:14:49Z"}, {"author": "Lucas Pardue", "text": "

if you're pushing GIFs at my relay, I doubt I care at all

", "time": "2022-07-27T15:15:12Z"}, {"author": "Murray Kucherawy", "text": "

Alan has dropped offline but may not know it.

", "time": "2022-07-27T15:15:46Z"}, {"author": "Alissa Cooper", "text": "

Can someone clarify the intended relationship between \"format\" \"container\" and \"codec\"? Not sure that question got answered.

", "time": "2022-07-27T15:16:46Z"}, {"author": "Christian Huitema", "text": "

Maybe call that \"transport data\" instead of \"metadata\", and limit it to what is explicitly standardize.

", "time": "2022-07-27T15:17:26Z"}, {"author": "Alex Chernyakhovsky", "text": "

I have been assuming \"format\" means a particular container and codec pair. Container is the outer framing layer that contains 1 or more streams (e.g., audio + video) of data specified in some codec (e.g., h264 vs av1 or mp3 vs aac)

", "time": "2022-07-27T15:17:49Z"}, {"author": "Kirill Pugin", "text": "

but it may not be transport, like timestamp of the frame for example

", "time": "2022-07-27T15:17:57Z"}, {"author": "Juliusz Chroboczek", "text": "

FWIW, AV1 calls it the \"dependency descriptor\", but I think that's too specific.

", "time": "2022-07-27T15:18:19Z"}, {"author": "Spencer Dawkins", "text": "

Christian Huitema said:

\n
\n

Maybe call that \"transport data\" instead of \"metadata\", and limit it to what is explicitly standardize.

\n
\n

That's a reasonable suggestion. I am now wondering how stable that would be (measured in years), but that's a follow-on question.

", "time": "2022-07-27T15:19:07Z"}, {"author": "Spencer Dawkins", "text": "

Alex Chernyakhovsky said:

\n
\n

I have been assuming \"format\" means a particular container and codec pair. Container is the outer framing layer that contains 1 or more streams (e.g., audio + video) of data specified in some codec (e.g., h264 vs av1 or mp3 vs aac)

\n
\n

Yeah, this probably ought to be a charter that includes definitions ...

", "time": "2022-07-27T15:20:12Z"}, {"author": "James Gruessing", "text": "

I propose \"Media information\". Metadata is too confusing, \"transport data\" likewise as we're describing the car not the road it's driving on.

", "time": "2022-07-27T15:20:33Z"}, {"author": "Eric Rescorla", "text": "

https://github.com/moq-wg/moq-charter/pull/61

", "time": "2022-07-27T15:22:45Z"}, {"author": "Luke Curley", "text": "

there's quite a bit of overlap between \"container\" and \"transport\"

", "time": "2022-07-27T15:22:56Z"}, {"author": "Cullen Jennings", "text": "

Either of https://github.com/moq-wg/moq-charter/pull/60/files and https://github.com/moq-wg/moq-charter/pull/59/files would be good imporvements to the security stuff

", "time": "2022-07-27T15:23:08Z"}, {"author": "Suhas Nandakumar", "text": "

@ekr PR loks good

", "time": "2022-07-27T15:23:19Z"}, {"author": "Suhas Nandakumar", "text": "

Agree PR#59 is a good addition

", "time": "2022-07-27T15:23:47Z"}, {"author": "Alex Chernyakhovsky", "text": "

container vs transport is hard. You could imagine stripping away containers and having everything live in the stream and having a super integrated thing. But that seems weird

", "time": "2022-07-27T15:24:03Z"}, {"author": "Luke Curley", "text": "

like the timestamp could be easy to parse in the transport, but it's also easy to parse in the container

", "time": "2022-07-27T15:24:12Z"}, {"author": "Spencer Dawkins", "text": "

+1 Mo on MTI being an endpoint thing. We have too much experience with mechanisms that require host and midpoint upgrades in order for updated mechanisms to work at all.

", "time": "2022-07-27T15:24:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

timestamp is weird because a general solution for timestamp is you could produce an out of band timestamp->byterange mapping and now you're done

", "time": "2022-07-27T15:24:45Z"}, {"author": "Alex Chernyakhovsky", "text": "

the transport requires no knowledge of the underlying format but suddenly you can now do seeks seamlessly

", "time": "2022-07-27T15:24:57Z"}, {"author": "Luke Curley", "text": "

it really depends on if you encrypt the container, or just the underlying media

", "time": "2022-07-27T15:25:09Z"}, {"author": "Juliusz Chroboczek", "text": "

Alex, RTP doesn't use any of the containers you're familiar with, every codec supported by RTP specifies a packetisation scheme that maps sequences of frames (roughly speaking) into a sequence of RTP packets.

", "time": "2022-07-27T15:25:14Z"}, {"author": "Alex Chernyakhovsky", "text": "

of course, the thing producing this mapping needs to have knowledge of the container

", "time": "2022-07-27T15:25:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Juliusz Chroboczek fair enough, point taken

", "time": "2022-07-27T15:25:49Z"}, {"author": "Spencer Dawkins", "text": "

Alex Chernyakhovsky said:

\n
\n

timestamp is weird because a general solution for timestamp is you could produce an out of band timestamp->byterange mapping and now you're done

\n
\n

Are we talking about the same timestamps? Timestamps in the media, QUIC timestamps, both, or something else?

", "time": "2022-07-27T15:26:00Z"}, {"author": "Luke Curley", "text": "

media presentation timestamps

", "time": "2022-07-27T15:26:24Z"}, {"author": "Luke Curley", "text": "

aka when the frame should be shown

", "time": "2022-07-27T15:26:36Z"}, {"author": "Behcet Sarikaya", "text": "

now the chair (Ted) talking

", "time": "2022-07-27T15:27:08Z"}, {"author": "Luke Curley", "text": "

IMO any decision making should be done based on the media timestamps and never on the transport timestamps

", "time": "2022-07-27T15:27:17Z"}, {"author": "Luke Curley", "text": "

otherwise stuff like b-frames become a nightmare

", "time": "2022-07-27T15:27:35Z"}, {"author": "Alex Chernyakhovsky", "text": "

What do you mean by that, Luke? I could imagine something looking at the data rate from transport timestamps and realizing it can't support the current format resolution

", "time": "2022-07-27T15:27:44Z"}, {"author": "Spencer Dawkins", "text": "

@Ted Hardie and @Alan Frindell , do you want me to write a PR for the live media change in scope, providing a pointer to the definition?

", "time": "2022-07-27T15:28:31Z"}, {"author": "Behcet Sarikaya", "text": "

left side of room dont see it

", "time": "2022-07-27T15:28:40Z"}, {"author": "Eric Kinnear", "text": "

@Ted Hardie can you click the \"Files Changed\" tab so it'll show all the changes rolled together?

", "time": "2022-07-27T15:28:49Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

https://github.com/moq-wg/moq-charter/pull/60/files

", "time": "2022-07-27T15:29:19Z"}, {"author": "Eric Kinnear", "text": "

Thank you!

", "time": "2022-07-27T15:29:19Z"}, {"author": "Behcet Sarikaya", "text": "

I can see the PR

", "time": "2022-07-27T15:31:03Z"}, {"author": "Richard Barnes", "text": "

PR lgtm

", "time": "2022-07-27T15:31:16Z"}, {"author": "Spencer Dawkins", "text": "

That looks about right.

", "time": "2022-07-27T15:31:18Z"}, {"author": "Erik Nygren", "text": "

Opened another PR to clarify the caching reasons:\"* cache friendly media mechanisms, including for semi-live, DVR, and VOD use-cases\"(added the \"including...\")

", "time": "2022-07-27T15:31:27Z"}, {"author": "Pete Resnick", "text": "

\"Github is neither a git nor a hub\". Discuss...

", "time": "2022-07-27T15:32:49Z"}, {"author": "Martin Thomson", "text": "

Should the BoF question also include whether the IETF is the right place with the right people?

", "time": "2022-07-27T15:33:48Z"}, {"author": "Spencer Dawkins", "text": "

Wait. Are we talking about the problem statement at the beginning of the BOF, or the problem statement after discussion?

", "time": "2022-07-27T15:34:11Z"}, {"author": "Behcet Sarikaya", "text": "

Ted was online

", "time": "2022-07-27T15:34:53Z"}, {"author": "Juliusz Chroboczek", "text": "

Let's mandate Cullent to solve the problem, then wait six months for him to come back with a complete solution and send it to the IESG ;-)

", "time": "2022-07-27T15:34:55Z"}, {"author": "Spencer Dawkins", "text": "

I answered assuming that ...

", "time": "2022-07-27T15:34:59Z"}, {"author": "Pete Resnick", "text": "

I like people actively not raising their hands to review. :rolling_on_the_floor_laughing:

", "time": "2022-07-27T15:36:00Z"}, {"author": "Pete Resnick", "text": "

\"I definitely shall not review!\"

", "time": "2022-07-27T15:36:40Z"}, {"author": "Spencer Dawkins", "text": "

Pete Resnick said:

\n
\n

\"I definitely shall not review!\"

\n
\n

\"And you can't make me!!!\"

", "time": "2022-07-27T15:37:14Z"}, {"author": "Martin Thomson", "text": "

commenting on the mailing list that the work should cease is still commenting on the mailing list

", "time": "2022-07-27T15:37:57Z"}, {"author": "Jake Holland", "text": "

these answers make no promises on quality of review comments tho, right?

", "time": "2022-07-27T15:38:22Z"}, {"author": "Kyle Rose", "text": "

\"I reviewed the draft. There are words.\"

", "time": "2022-07-27T15:39:33Z"}, {"author": "Juliusz Chroboczek", "text": "

Absolutely. I can, in good faith, make a promise to make stupid comments.

", "time": "2022-07-27T15:39:37Z"}, {"author": "Pete Resnick", "text": "

Caveat that the chairs should review the discussion both in the chat and in the room to make sure that all charter clarifications were captured, forming the WG seems fine.

", "time": "2022-07-27T15:40:25Z"}, {"author": "Martin Thomson", "text": "

\"I am aware of the existence of a draft. I have not read it.\"

", "time": "2022-07-27T15:40:28Z"}, {"author": "Jonathan Lennox", "text": "

\"I heard a rumor a draft exists, but I have not personally verified this, and honestly I'm dubious.\"

", "time": "2022-07-27T15:41:08Z"}, {"author": "Kyle Rose", "text": "

\"This document is Ready (to Expire Unpublished).\"

", "time": "2022-07-27T15:41:11Z"}, {"author": "Murray Kucherawy", "text": "

Did the poll stats get recorded someplace? They never popped up here. Might be connectivity again.

", "time": "2022-07-27T15:41:42Z"}, {"author": "Richard Barnes", "text": "

all presentations must be pirate-themed from now on

", "time": "2022-07-27T15:41:46Z"}, {"author": "Martin Thomson", "text": "

@Suhas Nandakumar please enunciate more crisply

", "time": "2022-07-27T15:41:59Z"}, {"author": "Behcet Sarikaya", "text": "

QuicR presentation now

", "time": "2022-07-27T15:41:59Z"}, {"author": "Lucas Pardue", "text": "

lol

", "time": "2022-07-27T15:42:05Z"}, {"author": "Behcet Sarikaya", "text": "

doing Jabber scribe voluntarily :smile:

", "time": "2022-07-27T15:42:43Z"}, {"author": "Spencer Dawkins", "text": "

I'm thinking that BOFs should be able to request interims, right?

", "time": "2022-07-27T15:43:11Z"}, {"author": "Will Law", "text": "

Suhas was clear for online audience

", "time": "2022-07-27T15:43:13Z"}, {"author": "Martin Thomson", "text": "

the speakers in these rooms are awful, it would seem

", "time": "2022-07-27T15:43:29Z"}, {"author": "Spencer Dawkins", "text": "

+1

", "time": "2022-07-27T15:45:30Z"}, {"author": "Juliusz Chroboczek", "text": "

Cullen: are there any more details on QuicR?

", "time": "2022-07-27T15:45:36Z"}, {"author": "Tommy Jensen", "text": "

breakfast* :(

", "time": "2022-07-27T15:45:43Z"}, {"author": "Christian Huitema", "text": "

... lunch, or breakfast...

", "time": "2022-07-27T15:45:47Z"}, {"author": "Behcet Sarikaya", "text": "

BOF adjourns

", "time": "2022-07-27T15:45:50Z"}, {"author": "Lucas Pardue", "text": "

thank you BoF'ers

", "time": "2022-07-27T15:45:51Z"}]