> > 1. poll WG chairs from the last IETF to see how many people contributed
> > things in real time from remote locations.
>
> Well, not relevant; most people listen, just as they
> do when they are present (and BTW, this is a completely
> legitimate reason to do the multicasts).
I think it's somewhat relevant, as folks who aren't providing
immediate feedback might prefer to time-shift anyway, and if
they're time-shifting they could download higher-quality video
than can feasibly be transmitted using multicast, use different
video formats, etc.
> > 2. if we have a list of email addresses of multicast participants from
> > the last IETF, ask those folks how well it worked for them.
>
> Surveys of this type are hard to do, but it would be
> interesting to understand what worked. Extrapolating
> from that to what the user problem is, however, is
> likely impossible (after the fact), and so the data
> will be less useful that one might like.
again, it would provide at least some indication about how much this
facility is being used.
> > 3. for the next meeting, update the IETF web pages to describe how to
> > attend the meeting via multicast - where to get the tools for your
> > particular platform, how to determine whether your ISP supports
> > multicast, and so on.
>
> Much of this information is available on
> http://videolab.uoregon.edu
thanks for the pointer. perhaps the IETF web pages regarding meetings
could be updated to include that pointer, or the information from that site?
> Finally, its our (IETF) technology. If its not good
> enough for us to use, then we might want to think about
> what we're doing and why.
quite true. though multicast is hardly alone in this regard.
> Its also important to note that
> for the 1-to-many case of IETF broadcast, the problems
> that we face in todays multicast world will be somewhat
> eased by SSM deployment.
Keith
