On Wed, Feb 26, 2020 at 12:36 PM Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
Actually, I doubt very much that we have all the pieces to have virtual
meetings that are as effective / useful / ... as face-to-face meetings.
IETF probably doesn't. But the wider IT community can probably add what is missing.
I would not be surprised if we have all the tools to have useful virtual
meetings for those cases when we can not or do not wish to have
face-to-face meetings.
I am pretty sure of that. There are plenty of proprietary systems that work pretty well. But communications systems are so much less effective when we all have to use the same proprietary provider.
But we should also remember that assembling systemic solutions from the
protocol parts is a different skill from the set the IETF tends to look
for and use from its participants. So it is not obvious how we get from
here to there.
That skill set may be rare but I am not the only person in IETF who has done that type of work and a project doesn't need very many of them. I am having difficulty remembering the last time the IETF tried to do that type of thing, probably MIME or the Web. We are not going to succeed if we don't try. Isn't that type of thinking what the IAB is supposed to provide?
But just doing a gap analysis between what we have now and where we need to be would be helpful.
Right now, all the major platform vendors support video and audio capture but working out how to generate a stream of data that is standards compliant... is an effort. And they all have their own programming models. And part of that is necessary because many of the CPUs are not actually capable of doing video compression, the hard parts are being done by co-processors.
As I see it, the three core technologies we need to integrate here are streaming video compression, QUIC datagrams and end-to-end cryptography. What we need now is to work out how to make them work together. We do have a proposal in this vein for Vancouver but it is over reliable channels. We should think about unreliable channels as well.