Mark C. Langston <[EMAIL PROTECTED]> wrote:

(re the problem of accessing the RealServer from behind a firewall)
> While I may be the only
> one complaining at this point, I find it hard to imagine that this
> will always be the case, and I would think that making things as easy
> to access as possible would be the ultimate goal.

Absolutely agreed that I should make whatever configuration changes are
necessary on the Berkman end.  I hope I indicated the same last month.
Indeed, my position on the subject hasn't changed; rather I was previously
not so hopeful re my ability to resolve this problem.

For those who care about the technical details:
<http://service.real.com/firewall/adminrs.html> says to enable the HTTP
server *ON PORT 80* in order to let the Realserver transmit via HTTP.
That's a problem for me, for all the Berkman RealServers are web servers
also and thus have "real" web servers on port 80.  Furthermore, Harvard
gives us only one IP per system, so I can't bind RealServer to one IP and
the web server to another.  So, perhaps I'll need to make a dedicated
RealServer that doesn't also serve web content; then I'll enable HTTP on the
usual port, and things may work properly.

However, I just bound the RealServer to port 8080 on cyber.law.harvard.edu,
and I with that change made I was able to get a connection even with my
Transport preferences set to HTTP Only (Options - Preferences - Transport
tab - Use Specified Transport - choose HTTP Only in the RTSP and PNA dialog
boxes in the G2 player, which I believe simulates the situation you face
from behind the firewall).  So your problem may already be solved, in fact,
at least with respect to the portion of our RealMedia content hosted on
cyber.law.harvard.edu rather than one of our other RealServers.  Let's
follow up off-list on this subject.

> Nothing, as such.  Perhaps I'm unclear on the relationship.  Is the NC
> paying Berkman for these services, or is it voluntary?

The Names Council is covering Berkman's costs -- primarily the cost of my
time, also their share of the cost of equipment -- in running these
webcasts.  We think cost recovery makes sense for relationships like this
one -- for services that could also be provided by an outside company.  In
the interest of complete disclosure, I should mention that the DNSO
currently lacks funds to pay for Berkman's webcasting service, so Berkman
has agreed to delay payment until after the Santiago meeting at which the
DNSO anticipates receiving funding for this expense (and, I believe, others
too).

> E-mail seems to be ubiquitous, but the
> way it was handled at the 6/25 meeting wasn't very fair, as the pDNC
> was able to ignore or brush off any email they didn't deem worthy of
> discussion, instead of being at least forced to acknowledge it, as they
> would a statement made by an individual in person.

> Furthermore, the manner in which the e-mails were dealt with -- i.e.,
> the haphazard, afterthought fashion present in San Jose -- didn't seem
> fair at all.

I'm not familiar with precisely what happened at the 6/25 meeting so I can't
respond to these concerns, though perhaps one of the NC members will have
something to say on the subject.

It seems to me that, at the minimum, a meeting with remote participation
should publish on the web the full text of all remote comments received.  We
tend to classify them into substantive (almost everything) and
non-substantive ("can you please turn up the volume?" and "my realplayer
isn't working") which we think is helpful, but beyond that we don't filter
the archives.

The NC may already have published the messages they received on 6/25, or
they may for some reason have decided not to, but I was unable to find such
messages in a quick perusal of their site.  That said, if the messages are
in fact not available, I'd be slow to blame them for the alleged
"closedness" -- they have so much other work to do, so many pressing demands
on their time, so little staff support available (none, I believe!), that I
can easily imagine such details falling through the cracks.  My experience
with "post-production" of ICANN open meetings has been that creating the
archive sites like <http://cyber.law.harvard.edu/icann/berlin/archive> is
indeed a significant investment of time -- several person-hours at best,
considerably more at worst.  It's not clear to me that the DNSO has the
infrastructure in place to put such sites together as yet, and although I'm
as anxious as you to see their online presence expand, I don't fault them
for not yet having risen to a pretty significant challenge.

> Perhaps what should be done is to have an individual
> whose responsibility is to approach the mic and address the members
> with the content of the email, unadulterated, in the same manner a
> physical attendee would, would be the best solution.

Presumably you mean to suggest this also for Santiago and for ICANN open
meetings generally.

It's an interesting possibility, and something we're considering for
Santiago.  I'm thinking perhaps it shouldn't be the responsibility of the
meeting chair (Esther, in the ICANN open meetings) to *filter* remote
comments -- to recognize them, yes, just as she recognizes speakers queuing
at a microphone.  But someone else might actually read the messages to the
group, not to mention choose which messages to read (assuming that there is
a "choosing" process going on -- not yet decided).

Suppose a member of the Berkman team were to read two selected remote
comments after every four in-room comments?  He or she might do so from the
mic or from a podium -- from where is not so important, more important is
that there would be a sort of schedule for recognizing and responding to
remote comments.  Thoughts?

> And it should be made clear that all email is to be addressed, not
> simply those deemed "worthy".  The members do not have that option
> with physical attendees, and they should not be allowed to do it
> with email.

I don't know.  What do you do when, hypothetically, remote comments are
coming in at the rate of two a minute while the pace of the meeting allows a
remote comment to be recognized, say, every other minute?  Should they
really just queue, so that the first three comments on an agenda item get
read, while the rest simply go up on the web?  I'm not sure I like the
incentives that regime creates: send your message early (maybe even
pre-write it!), and don't worry too much about content or substance.  I'd be
inclined at least to consider a system whereby some trusted individual or
individuals pick what he/she/they consider the "best" (i.e. most
thought-provoking, most worrisome, most important, etc.) messages received
up to that point.  If message number eight on an agenda item really does
make the most interesting point that hasn't been raised or even thought of
before, I'd hate to see message two (repeating the same point as message
one!) read to the group while message eight lies unconsidered.

> 2.  Unless the members in the teleconference are on cell phones,
> chances are they're near a networked computer.  Furthermore, they
> are supposedly knowledgable in computers and networking issues.
> Therefore, would it not make much more sense to hold these meetings
> online, in a real-time interactive forum (e.g., a private IRC server)
> than via telephone?

In the context of the NC meetings, I'll leave it to them to respond.

For the ICANN Open Meetings, there's a real-space group so real-time
many-way text messaging doesn't seem like the right solution for the remote
participation "problem" we've previously been discussing.  However, it might
make a good complement to the primary remote participation system.  Suppose
that, in addition to the formal comment submission system (for sending
messages for consideration by the real-space group), the online participants
had a IRC-style forum to talk amongst themselves, with archives available in
the meeting archive, perhaps with the chat displayed on a side screen at
times during the meeting?

> True, this would require some people to become familiar with
> clients for the chosen real-time forum.  But since they're
> already being required to become familiar with RealPlayer, this
> shouldn't be that much of an issue.  At least, no more than
> the existing issues surrounding the webcasting.

I do think that the RealPlayer has a somewhat greater installed base than
any IRC client, and I'd venture that the RealPlayer, for all its faults, is
easier to use.  Nonetheless, I don't deny the merits of your suggestion.  My
main worry is that the "side screen" suggestion (in my prior paragraph)
might be distracting to the real-space meeting.  (Thoughts on that concern?)
Otherwise, though, I'm generally inclined to adopt a real-time chat
solution, whether IRC or Java-based or some hybrid of the two or something
else altogether.  (Recommendations?  Preferences?  I've got Webboard's chat
system and iChat already at my disposal; using other software is certainly
possible, though.)

> Finally, there would be an instant record of all decisions made.

Indeed.  If anyone on-list would like to donate transcription services (or
put forward the $100/hour transcription fees of the transcribers I know of
up here), I'd *LOVE* to get the Singapore and Berlin meetings transcribed.
Maybe it's too late now -- perhaps no one cares about that "ancient
history."  But it's awfully nice to have a text transcript, I think, and
it's been disappointing that, recently, the resources haven't been available
to make that happen.

> 5) The maintenance and/or introduction of remote participation on an
> equal footing and with as much psychological presence as that held by
> physical participants.

Nicely stated, and agreed.  I'd like to think we're getting there: ICANN's
Singapore Open Meeting, for whatever its alleged faults, allowed the remote
participation that all of the IFWP meetings lacked, I believe.  And Berlin's
Open Meeting received more comments than the November Cambridge meeting,
Open RCS Workshop, and Singapore Meeting put together.  One might argue that
we're moving too slowly, but I do think we're moving in the right direction.

Ben

Reply via email to