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