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