Re: Multicast to the Browser
"Morten V. Pedersen" <[email protected]> Thu, 24 Oct 2019 06:47:10 +0200
| Newsgroups | gmane.ietf.mboned |
|---|---|
| Message-ID | <[email protected]> |
Hi Jake, Thanks for talking the initiative on this - I believe this is a great start and definitely valuable. We have long been wanting to do something like this, and I believe that are many great applications e.g. within education etc. (see for example https://youtu.be/LuHRXIRZu-s used for presentations etc. where no projector is available). I would support mboned looking at this. All the best, Morten On 9/27/19 6:03 AM, Holland, Jake wrote: > Hi mboned, > > I have finally posted a few docs that give an outline of the architecture > we're proposing to make multicast safe enough to run arbitrary interdomain > traffic, and to use it on web pages. > > This is a slightly more concrete version of the hand-waving I did at the > meeting in Montreal, and hopefully explains what we're aiming for a little > more clearly. > > > WICG proposal: > https://discourse.wicg.io/t/proposal-multicastreceiver-api/3939 > > > That refers to a few IETF drafts. I'd like to request some time in Singapore > to go over them. > > I'm also requesting feedback about these docs at your earliest convenience, > as well as any comments you've got on whether these I-Ds are appropriate > for adoption in mboned (and if not, what you'd suggest instead): > > 1. DORMS (or: how to get metadata about multicast groups from senders): > https://tools.ietf.org/html/draft-jholland-mboned-dorms-01 > > I'll argue that this is in-scope for mboned, and hopefully not too hard > a read. Its main point is to provide a vehicle for the metadata for the > other 2 docs, plus other future extensions. > > > 2. CBACC (or: how to ensure the subscribed capacity level stays safe): > https://tools.ietf.org/html/draft-jholland-mboned-cbacc-00 > > Although I think this doc will need review from TSV, I believe early work > and perhaps adoption is appropriate within mboned, since it's targeted at > enabling interdomain multicast support. > > > 3. AMBI (or: how to authenticate the traffic, assuming you can send > some out-of-band hashes securely): > https://tools.ietf.org/html/draft-jholland-mboned-ambi-04 > > This one will of course need security review, and perhaps would be best > done in the security area, especially if we can re-open msec. > > However, when we last presented the pre-split AMBI+ALTA proposal in > secdispatch, they said we should go find more people who are interested > and come back. > > In my ideal world, I'd like to go back to secdispatch, ideally in Singapore, > with some consensus from mboned that this is a worthwhile direction that > would be valuable if it can be made to work (or to get advice from mboned > that it's not, if it's not). > > So to anyone who can read the doc and post an opinion on that point, I'd be > very grateful. > > > Cheers, > Jake > > > _______________________________________________ > MBONED mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mboned _______________________________________________ MBONED mailing list [email protected] https://www.ietf.org/mailman/listinfo/mboned