Subject: [vmeet] FRAME: multi-hub meetings

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 1 Apr 2009 13:32:31 -0400

I'm not sure I understand exactly what is and isn't a framework, but  
there's no better label for this thought...

I think we should pay special attention to the international  
complexities of IETF attendance.  In general it's much easier to go to  
a conference in your own geographic/geopolitical region.  The rising  
cost and hassle of international travel isn't the only reason for the  
vmeet discussion, but it's a big one that probably has different and  
separable solutions.

In particular, what about a multiple-hub system, in which IETF met  
simultaneously in 3 or 5 different cities in different parts of the  
world?  Such a scenario would preserve the intangible shoulder-rubbing  
value of face-to-face meetings while reducing the cost and difficulty  
of travel for nearly everyone.  But it would also suggest a need for  
tools specifically oriented to richly linking a few large distributed  
rooms together.

Note that I'm not favoring doing this *instead* of better enabling  
individual remote participation.  I think they are different  
modalities that address different aspects of the problem, and could  
probably be made to work together.  And it would have the added  
advantage of putting the rest of the world on something closer to an  
equal footing with North America for IETF participation.   -- Nathaniel

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 20:09:32 +0200

Hi Nathaniel,

> tools specifically oriented to richly linking a few large distributed 

This can be done for plenaries, but I think it is difficult for small 
groups, as it requires well planned floor moderation between the meeting 
points, and that is as much a human problem as anything else.  We do 
large internal meetings, for instance, at Cisco using Cisco 
Telepresence, and it seems to work fine.

Let me add one additional point:  my own experience working remotely has 
been that if you don't have strong management of the meeting, and you do 
have people who are "local" (e.g., in the room), then the remote ones 
get marginalized.  For the IETF, this is the price I expected to pay for 
not having paid an admission fee or traveled all the way to SF.  Is this 
where expectations should be?

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 01 Apr 2009 11:14:49 -0700

Nathaniel Borenstein wrote:
>     But it would also suggest a need for tools
> specifically oriented to richly linking a few large distributed rooms 
> together.

Do you know of any tools, currently in use, that can support this mode, at IETF 
scale?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 1 Apr 2009 15:00:50 -0400

On Apr 1, 2009, at 2:09 PM, Eliot Lear wrote:

>> world?  Such a scenario would preserve the intangible shoulder- 
>> rubbing value of face-to-face meetings while reducing the cost and  
>> difficulty of travel for nearly everyone.  But it would also  
>> suggest a need for tools specifically oriented to richly linking a  
>> few large distributed rooms together.
>
> This can be done for plenaries, but I think it is difficult for  
> small groups, as it requires well planned floor moderation between  
> the meeting points, and that is as much a human problem as anything  
> else.  We do large internal meetings, for instance, at Cisco using  
> Cisco Telepresence, and it seems to work fine.

Yes, but I think this is a more general issue, not just a multi-hub  
issue -- I think good distributed meetings will be at most 50%  
technology, and most of the rest will be organization, moderation,  
etiquette, etc.

> Let me add one additional point:  my own experience working remotely  
> has been that if you don't have strong management of the meeting,  
> and you do have people who are "local" (e.g., in the room), then the  
> remote ones get marginalized.  For the IETF, this is the price I  
> expected to pay for not having paid an admission fee or traveled all  
> the way to SF.  Is this where expectations should be?

I agree that strong management is a requirement, but I don't think  
it's an unrealistic one.  -- nsb

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 1 Apr 2009 15:07:33 -0400

On Apr 1, 2009, at 2:14 PM, Dave CROCKER wrote:

>> specifically oriented to richly linking a few large distributed  
>> rooms together.
>
> Do you know of any tools, currently in use, that can support this  
> mode, at IETF scale?

Actually I probably misspoke -- it's less that the tools will  
necessarily be specialized for this purpose,  but more the way we  
configure and deploy the tools than the tools themselves.  Video and  
audio conferencing as a technology work in a variety of settings, but  
require some planning and configuring to properly deploy across a  
multi-hub meeting.  And it only increases the need (as expressed by  
Eliot) for moderators, etiquette, etc.

So really I guess all I'm saying is that multi-hub meetings are  
another scenario that should be part of our considerations.  -- nsb

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 01 Apr 2009 12:53:06 -0700

Nathaniel,

If the hubs are to be interconnected, then this is considerably different from 
the star topology from having a single physical room and others coming into it.

I wouldn't automatically expect that tools able to support a star would support 
a mesh.

d/

Nathaniel Borenstein wrote:
> So really I guess all I'm saying is that multi-hub meetings are another 
> scenario that should be part of our considerations.  -- nsb
> 

-- 

   Dave Crocker

---

From: Doug Otis <[email-masked]>
Date: Wed, 1 Apr 2009 14:17:45 -0700

On Apr 1, 2009, at 12:07 PM, Nathaniel Borenstein wrote:

>>>   But it would also suggest a need for tools specifically oriented  
>>> to richly linking a few large distributed rooms together.
>>
> audio conferencing as a technology work in a variety of settings,  
> but require some planning and configuring to properly deploy across  
> a multi-hub meeting.  And it only increases the need (as expressed  
> by Eliot) for moderators, etiquette, etc.
>

Working for an organization that loves to have meetings, video  
conferencing staged between regional meeting places has become the  
norm, where the time of day becomes a major consideration.

One might imagine audio, video and side projection selections could be  
managed through a dedicated net-book assigned to each meeting room.  A  
net-book and projector could bridge between room audio/visual, and  
external audio/visual presentations.  One also might imagine virtual  
queues forming behind managed external resources, perhaps in the form  
of voice mail.  Local participants become impatient waiting for typed  
responses, and MIC: questions read from XMPP often lack helpful  
inflections.  A managed audio feed could offer nearly immediate and  
less stressful interaction directed to room specific follow-up  
addresses.  In this manner, technologies that support interaction  
between a small number of participants could be extended to act as  
managed remote microphones, for example.  Perhaps registration fees  
paid by remote participants could fund reliable bridges aimed  
specifically at fulling remote-microphone functions.  Remote  
participation fees may also help reduce concerns of the service being  
abused.

-Doug

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Apr 2009 17:37:41 -0700

On Apr 1, 2009, at 10:32 AM, Nathaniel Borenstein wrote:

> difficulty of travel for nearly everyone.  But it would also suggest  
> a need for tools specifically oriented to richly linking a few large  
> distributed rooms together.

I suspect there would be issues. First, I can't definitely say it  
would cost more, but apart from donated facilities I don't see how it  
would cost less. Second, it has three non-optimal outcomes:

  - we actually don't have shoulder-rubbing with people in other  
sites. The shoulder-rubbing is IMHO important to getting the work  
done, so that is an issue.

  - If the meeting runs on local wall clock time, we will wind up by  
some algorithm (likely by area) having some meetings in one place and  
some meetings in another. For those that are involved in multiple  
working groups, that means attending all of the places, which means  
that they can't be held during the same week and it actually causes  
more travel and travel-related cost.

  - If the meetings run simultaneously in all places and use video  
linkage to interconnect them, we have to pick a time zone to consider  
the meeting as running in. To get an idea of the implications of that,  
take a look at http://tinyurl.com/c7kh54, which postulates a meeting  
running simultaneously in Tokyo, Vancouver, and Paris. You haven't  
experienced jet-lag until you have tried to be productive in a meeting  
on another continent when your body swears at is 3:00 AM.

Eliot and I work for a global company that routinely has multi- 
continent meetings using video and audio technology. The technology  
exists and can be made to serve the purpose. As far as actually having

---

From: joel jaeggli <[email-masked]>
Date: Fri, 3 Apr 2009 00:34:20 -0700

On Thu, Apr 2, 2009 at 5:37 PM, Fred Baker <[email-masked]> wrote:
>  - If the meeting runs on local wall clock time, we will wind up by some
> algorithm (likely by area) having some meetings in one place and some
> meetings in another. For those that are involved in multiple working groups,
> that means attending all of the places, which means that they can't be held
> during the same week and it actually causes more travel and travel-related
> cost.

The great irony of remote participation today is it's much easier to
remotely participate in a full days worth of meetings when they are in
the same or adjacent timezone... The occasional meeting at odd hours
works, but a full week when you're offset 8, 10, 12 hours is murder.

I collaborate routinely with a number of colleagues on CET which given
the 10 hour offset results in a lot of compromise, it's tolerable, but
not on a continuous basis.

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 02 Apr 2009 10:23:02 +0200

Nathaniel,

Just as a FYI. We are going to use TelePresence to have a conference 
(The R'09 twin world congress on resource management, 
http://www.r2009.org/) at two locations at the same time (Nagoya, Japan 
and Davos, Switzerland) in September. As it turns out is indeed more the 
organization that is hard rather than the technology (admittedly, that 
is largely because we have great teams in Switzerland and Japan), not to 
mention issues like timezone differences.

We hope to leverage the experience we gather to use TP in other 
conferences as well.

We are still working on the virtual beer though...

Klaas

>>> world?  Such a scenario would preserve the intangible 
>>> shoulder-rubbing value of face-to-face meetings while reducing the 
>>> cost and difficulty of travel for nearly everyone.  But it would also 
>> groups, as it requires well planned floor moderation between the 
>> meeting points, and that is as much a human problem as anything else.  
>> We do large internal meetings, for instance, at Cisco using Cisco 
>> has been that if you don't have strong management of the meeting, and 
>> you do have people who are "local" (e.g., in the room), then the 
> I agree that strong management is a requirement, but I don't think it's 
> an unrealistic one.  -- nsb

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 3 Apr 2009 15:55:10 -0400

The problem for timezones is manageable for hour-long meetings, as  
long as you schedule the meeting at 10 am ET, which seems to fall  
roughly within the plausible-if-inconvenient time frame for the  
majority of active participants in North America, Europe and Korea/ 
China/Japan/India. As soon as you exceed that hour, somebody is going  
to miss family dinner or stay beyond their normal bed time.

Henning

On Apr 2, 2009, at 4:23 AM, Klaas Wierenga wrote:

> (The R'09 twin world congress on resource management, http://www.r2009.org/) 
>  at two locations at the same time (Nagoya, Japan and Davos,  
> Switzerland) in September. As it turns out is indeed more the  
> organization that is hard rather than the technology (admittedly,  
> that is largely because we have great teams in Switzerland and  
> Japan), not to mention issues like timezone differences.
>

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 03 Apr 2009 13:10:49 -0700

Henning Schulzrinne wrote:
> The problem for timezones is manageable for hour-long meetings, as long 
> as you schedule the meeting at 10 am ET, which seems to fall roughly 
> within the plausible-if-inconvenient time frame for the majority of 
> active participants in North America, Europe and 
> Korea/China/Japan/India. As soon as you exceed that hour, somebody is 
> going to miss family dinner or stay beyond their normal bed time.

Right.  The Internet can't fix timezones.  Hence, as long as we have day-long 
physical meetings, remote participants are likely to be somewhat inconvenienced, 
and many/most will be severely inconvenienced.

(The combination of North America, Europe, Eastern Asia is bad.  It gets a lot 
worse if AU/NZ and/or Hawaii are included in the mix.  The simple rule is that 
truly global remote participation is certain to mess at least one set of 
participants up badly.  My definition of badly is the AM of night.)

My guess is that as long as we have a physical meeting, there won't be much we 
can do (except, perhaps, consider the venue in terms of timezone impact, along 
with the other, minor venue considerations...)  For a fully remote meeting, we 
might find that the entire approach to scheduling will change.

But right now, our task is technology and function.

d/
-- 

   Dave Crocker

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 6 Apr 2009 10:43:32 -0400

> done, so that is an issue.

But there really is a limit on the number of shoulders you can rub in  
a week.  It's not ideal, but if some people from each hub have non- 
IETF opportunities to rub shoulders, as they certainly do, both,  
you're going to get a reasonable amount of socialization of ideas.

I'm not saying it's ideal, just that we might be able to get a result  
that is, say, half as effective as the current meetings for shoulder- 
rubbing, but opens up the process to three times as many  
participants.  That might turn out to be a reasonable tradeoff.  --  
Nathaniel

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 6 Apr 2009 10:54:04 -0400

So, as we struggle with the tradeoff between location and time, it  
seems to me we have at least 3 possible structures for an enhanced  
IETF meeting:

-- Physical meeting like today, with better remote tools

-- Completely distributed meeting, probably spread out over several  
weeks to exploit the most internationally acceptable times of day.

-- Hybrid meeting, with multiple clusters (hubs) facilitating  
"shoulder-rubbing".

The first is geographically the worst -- the remote people will always  
be second-class citizens,  The third is worst for time zones problems,  
though it would be fun watching a hotel's staff feed us lunch at 3  
AM.  Should we be considering the second -- a 100% virtual IETF  
meeting -- or is that out of scope for this discussion?  -- Nathaniel

On Apr 3, 2009, at 4:10 PM, Dave CROCKER wrote:

>> China/Japan/India. As soon as you exceed that hour, somebody is  
> Right.  The Internet can't fix timezones.  Hence, as long as we have  
> day-long physical meetings, remote participants are likely to be  
> somewhat inconvenienced, and many/most will be severely  
> inconvenienced.
>
> (The combination of North America, Europe, Eastern Asia is bad.  It  
> gets a lot worse if AU/NZ and/or Hawaii are included in the mix.   
> The simple rule is that truly global remote participation is certain  
> to mess at least one set of participants up badly.  My definition of  
> badly is the AM of night.)
>
> My guess is that as long as we have a physical meeting, there won't  
> be much we can do (except, perhaps, consider the venue in terms of  
> timezone impact, along with the other, minor venue  
> considerations...)  For a fully remote meeting, we might find that  
> the entire approach to scheduling will change.
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html.
> https://www.ietf.org/mailman/listinfo/vmeet

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Apr 2009 11:10:35 -0400

While probably somewhat off-topic, the second model might address the  
current problem of almost all work getting done (all I-Ds being  
updated, etc.) in the two weeks before the IETF meeting. I think we'd  
be much more effective if working groups were more distributed across  
time.

Henning

On Apr 6, 2009, at 10:54 AM, Nathaniel Borenstein wrote:

> The first is geographically the worst -- the remote people will  
> always be second-class citizens,  The third is worst for time zones  
> problems, though it would be fun watching a hotel's staff feed us  
> lunch at 3 AM.  Should we be considering the second -- a 100%  
> virtual IETF meeting -- or is that out of scope for this  
> discussion?  -- Nathaniel
>
>
>> Right.  The Internet can't fix timezones.  Hence, as long as we  
>> have day-long physical meetings, remote participants are likely to  
>> be somewhat inconvenienced, and many/most will be severely  
>> inconvenienced.
>>
>> The simple rule is that truly global remote participation is  
>> certain to mess at least one set of participants up badly.  My  
>> definition of badly is the AM of night.)
>>

---

From: Scott Brim <[email-masked]>
Date: Mon, 6 Apr 2009 11:42:16 -0400

Excerpts from Nathaniel Borenstein on Mon, Apr 06, 2009 10:54:04AM -0400:
> So, as we struggle with the tradeoff between location and time, it seems 
> to me we have at least 3 possible structures for an enhanced IETF 
> meeting:
>
> though it would be fun watching a hotel's staff feed us lunch at 3 AM.  
> Should we be considering the second -- a 100% virtual IETF meeting -- or 
> is that out of scope for this discussion?  -- Nathaniel

This leads me to: email as we do it now, but punctuated by moderators,
so that there are particular times for particular topics, deadlines,
etc.  There can be more media-rich meetings between particular people
on particular topics where they are not able to work things out in
mail?

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Apr 2009 08:56:03 -0700

For the moment, I believe the charter is to discuss your first option.  
At some point, I could imagine dropping the concept of plenary  
meetings and replacing them with webex-like interim meetings to some  
extent. I seriously doubt that we will become travel-free, though, as  
there are aspects of physical meetings that you aren't going to  
replace with remote attendance except in sci-fi. You can look someone  
in the eye, but how do you shake their hand?

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Apr 2009 08:56:51 -0700

On Apr 6, 2009, at 8:10 AM, Henning Schulzrinne wrote:

> While probably somewhat off-topic, the second model might address  
> the current problem of almost all work getting done (all I-Ds being  
> updated, etc.) in the two weeks before the IETF meeting. I think  
> we'd be much more effective if working groups were more distributed  
> across time.

Would there be deadlines? The thing that happens two weeks before a  
meeting that precipitates the flurry of drafts is a deadline...

---

From: joel jaeggli <[email-masked]>
Date: Mon, 6 Apr 2009 09:06:41 -0700

what's an internationally acceptable time of the day?  Even on the us
west coast I think of the markets being open in NY as internationally
acceptable but my colleagues in tel aviv would consider that an
inconvenience...

There's also the issue of friday vs sunday which is tollerable (imho)
if you do it occasionally around a big meeting but not if it impacts
you a lot.

On Mon, Apr 6, 2009 at 7:54 AM, Nathaniel Borenstein <[email-masked]> wrote:
> So, as we struggle with the tradeoff between location and time, it seems to
> me we have at least 3 possible structures for an enhanced IETF meeting:
>
> -- Completely distributed meeting, probably spread out over several weeks to
> exploit the most internationally acceptable times of day.
>
> The first is geographically the worst -- the remote people will always be
> second-class citizens,  The third is worst for time zones problems, though
> it would be fun watching a hotel's staff feed us lunch at 3 AM.  Should we
> be considering the second -- a 100% virtual IETF meeting -- or is that out
> of scope for this discussion?  -- Nathaniel
>
>
>>> as you schedule the meeting at 10 am ET, which seems to fall roughly within
>>> the plausible-if-inconvenient time frame for the majority of active
>>> participants in North America, Europe and Korea/China/Japan/India. As soon
>>> as you exceed that hour, somebody is going to miss family dinner or stay
>>> beyond their normal bed time.
>>
>>
>> day-long physical meetings, remote participants are likely to be somewhat
>> inconvenienced, and many/most will be severely inconvenienced.
>>
>> (The combination of North America, Europe, Eastern Asia is bad.  It gets a
>> lot worse if AU/NZ and/or Hawaii are included in the mix.  The simple rule
>> is that truly global remote participation is certain to mess at least one
>> set of participants up badly.  My definition of badly is the AM of night.)
>>
>> My guess is that as long as we have a physical meeting, there won't be
>> much we can do (except, perhaps, consider the venue in terms of timezone
>> impact, along with the other, minor venue considerations...)  For a fully
>> remote meeting, we might find that the entire approach to scheduling will
>> change.
>>

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 6 Apr 2009 12:16:46 -0400

> acceptable but my colleagues in tel aviv would consider that an

I was alluding to an early comment on the list that described 10 AM  
Eastern US time (I think?) as the least-bad "sweet spot" given the  
typical IETF constituency.  I wasn't looking at it deeply, but I can  
confirm that IBM meetings that require Asia, Europe, and America al to  
attend generaly occur around that time.  My point was just that there  
are probably on a few hours each day that are as good as it gets, so  
some meetings might be better stretched out over several weeks to take  
advantage of such times.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 6 Apr 2009 11:17:22 -0500

... there certainly could be deadlines.

We did pretty well in MEDIACTRL last year with conference calls every two or 
three weeks, and expecting editors to revise drafts before the next 
conference call. In my role as editor for a SIP Forum doc, I'm pretty 
focused on a draft revision before a conference call on Thursday (I 
committed to a Tuesday delivery for my revision).

Thanks,

Spencer

>> current problem of almost all work getting done (all I-Ds being  updated, 
>> etc.) in the two weeks before the IETF meeting. I think  we'd be much 
>> more effective if working groups were more distributed  across time.
>

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Mon, 6 Apr 2009 18:28:26 +0200

Hello all,
I think that this discussion list is going to be quite interesting and
useful.

Now it is essential that when you participate remotely to the IETF, that you
have be able to participate while not being able to use audio, or video.
Visual or audio impairments (blindness, deafness, hard of hearing or speech
impairments) should not be a reason to miss out the fun.

But I see you thinking...
How many deaf/blind/speech impaired people are there at the IETF? Should we
bother?

True, we are there, and a small group. 

But here is the cinch: the IETF is a great bunch of non native English
speakers. So we all happen to be hearing or speech impaired when you cannot
understand the accent of the speaker. Or when your written English is much
better than your spoken English. 
So, a good solution for this problem is something that is called Real-Time
Text, RTT (see www.realtimetext.org) that can send all the speech
transcribed into text and received immediately with minimal delay. Character
by Character/Word by word to you.

So, you can see the person via video, you can hear the person via audio, and
you can understand the person using RTT. :-)

And when there is a stutter in the audio or video...the RTT will happily
keep streaming to your computer/phone etc.
So, you can still attend the IETF remotely while losing 90% of your
bandwidth.
Or be able to follow the IETF in your bed while your wife is asleep next to
you.

I will help and participate where I can to make sure that everybody can
participate to the IETF remotely. Regardless location, ability, disability
and available technology. We can at least try together.

Arnoud

---------------------------------------------------------------------
Arnoud van Wijk
Disability Projects Coordinator
email: [email-masked]
SIP (ToIP) [email-masked]
FAX +31412614000                            
Internet Society (ISOC)       "The Internet is for everyone"
http://www.isoc.org
----------------------------------------------------------------------

---

From: joel jaeggli <[email-masked]>
Date: Mon, 6 Apr 2009 11:05:29 -0700

On Mon, Apr 6, 2009 at 9:16 AM, Nathaniel Borenstein <[email-masked]> wrote:
> I was alluding to an early comment on the list that described 10 AM Eastern
> US time (I think?) as the least-bad "sweet spot" given the typical IETF
> constituency.  I wasn't looking at it deeply, but I can confirm that IBM
> meetings that require Asia, Europe, and America al to attend generaly occur
> around that time.  My point was just that there are probably on a few hours
> each day that are as good as it gets, so some meetings might be better
> stretched out over several weeks to take advantage of such times.

Right, we actually use the same window of time (0700 pst/pdt) quite
extensively on the theory that it's the least bad. But it
inconveniences the same people all the time, and it's not like you can
start 3 hours of meetings at that point and not have it go from
inconvenient to infeasible.

---

From: John Leslie <[email-masked]>
Date: Mon, 6 Apr 2009 15:19:45 -0400

> -- Hybrid meeting, with multiple clusters (hubs) facilitating  

   Ideally, we should have a bag-of-tricks that works for all three...

> meeting -- or is that out of scope for this discussion?

   Admittedly, it is not what sparked the formation of this list; but
I hope Dave doesn't rule it out of scope.

   The second seems most promising to me, both for the range of ideas
and tools we would discuss, and for the immediate applicability to
our scheduling problem -- that IETF week is running longer than most
of us are willing to spend.

   Also, of course, there are the schedule conflicts... I admit to
having tried to follow two sessions at once by sitting in one while
I follow the other by audio and jabber. (It doesn't work very well,
of course, but it is marginally better than missing the second
entirely.)

   When I get away with this trick, it's because most WGs spend the
majority of their F2F time in presentations, many of which I can
get away with only half-following. ;^)

   How about talking through the design of a "completely distributed"
meeting where the presenter takes questions in real-time, but the
"attendees" can listen and follow the slides at their own pace and
own timezone? If some of those happen to be in the same room as the
presenter, let them choose whether to watch and listen in real-time
or to pace video and audio to allow spot research or higher-priority
interrupts.

   (Assume infinite bandwidth and a spherical cow, of course. ;^)

--
John Leslie <[email-masked]>

---

From: "Olivier MJ Crepin-Leblond" <[email-masked]>
Date: Mon, 6 Apr 2009 23:09:42 +0200

> -- Hybrid meeting, with multiple clusters (hubs) facilitating 

It seems that people here like option 2. I am uneasy about going all 
cyberspace.
Physical meetings just like today are still required, and probably at 
the same frequency as today. However, I think that it is undeniable 
that completely distributed interim e-meetings are also required, at 
the pace at which each working group progresses.

The timing of these e-meetings cannot be cast in stone. At ICANN & 
ISOC Chapter e-meetings, we've had times ranging from 10:00 UTC to 
21:00 UTC. Many were particularly challenging because we were located 
on all 5 continents. No matter what time we chose, there was always 
someone out there struggling to keep awake at 3:00am local time. In 
the interest of fairness, perhaps should one choose, say, three time 
spans which would be rotated accordingly at each e-meeting, so that 
the same folk do not end up missing on sleep. Start checking out your 
time zone charts...

Kind regards,

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 06 Apr 2009 17:18:03 -0400

(I've changed the Subject, because I believe the issue being raised is about a 
particular type of technology that might be useful.

My question is:  why should the conferencing service provide this feature, 
rather than have those users who need it add it on their own?

d/

-- 

   Dave Crocker

---

From: Peter Dambier <[email-masked]>
Date: Mon, 06 Apr 2009 23:25:32 +0200

Dave CROCKER wrote:
> (I've changed the Subject, because I believe the issue being raised is
> about a particular type of technology that might be useful.
> 
> My question is:  why should the conferencing service provide this
> feature, rather than have those users who need it add it on their own?
> 
> d/
> 

I have seen it working at a visually disabled friend.

>From what I have seen it is much easier implemented and a lot more
flexible if implemented at the client site.

You can even babelfish it - make it translate.

Peter

>> better than your spoken English. So, a good solution for this problem
>> is something that is called Real-Time

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48

---

From: John Leslie <[email-masked]>
Date: Mon, 6 Apr 2009 17:42:30 -0400

> rather than have those users who need it add it on their own?

   My understanding is that realtimetext.org deals with the protocol to
_transmit_ text in real-time, not the software/hardware to _transcribe_
speech to text.

   While the _use_ of RTT is pointless unless there is something to feed
it, inclusion of the _capability_ to have "synchronized" RTT seems like
a good idea.

   Of course, it might be unwise to _gate_upon_ such a capability being
included...

---

From: John Leslie <[email-masked]>
Date: Mon, 6 Apr 2009 17:46:31 -0400

> It seems that people here like option 2. I am uneasy about going all 

   I don't think folks want to abandon in-person meetings...

   But what about the presentations which take up so much of our F2F
time at IETF weeks? Might it not make sense to structure some of
these under option 2?

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Tue, 7 Apr 2009 17:41:26 +0200

I did change the subject to cover the message.
As John pointed out, I was talking about speech that is immediately
transcribed in text. And the text is then send out in real-time in a
streaming way. You would be able to receive the text on a character by
character to word by word basis. (depending the speed of the conversation).

Until technology is advanced enough to have speech to text by a computer,
right now it will use a human transcriber/real-time text interpreter. 

So, if you are remotely participating, or are in a parallel session, you can
follow the discussions in text and thanks to the real-time delivery, follow
it with minimal delay.

To answer the question why the conference service should offer real-time
text transcribing.
It is to ensure that everyone can follow the IETF meeting and has the
freedom to combine it with audio and video as well if that is
possible/desired.

I do not know how many of you have attended an ICANN meeting? You may have
seen the remote participation service using text that is send via your web
browser.
By using RTT, it will be an improved version of it.

If you want more information on real-time text (RTT), you can have a look at
www.realtimetext.org
Or go straight at RFC4103 and RFC5194.

But I am convinced that it is a very good idea to add the ability to use
real-time text to the conference service.

/Arnoud

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: maandag 6 april 2009 23:43
> To: [email-masked]
> Cc: Arnoud van Wijk; [email-masked]
> Subject: Re: [vmeet] TECH: text to speech
> 
> feature,

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 7 Apr 2009 13:18:16 -0400

> Until technology is advanced enough to have speech to text by a
computer, right 
> now it will use a human transcriber/real-time text interpreter. 

As useful as RTT would be to remote participants, I suspect that no one
would sign up for the human transcriber job (the chairs have a hard
enough time trying to get people to write the minutes!).  However, if we
had computer speech to text that was reliable enough - and could be
integrated seamlessly into already existing IETF process (ie. happen
automatically for all streaming audio), I think everyone would be happy
with that.

- Wes

---

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Apr 2009 13:23:39 -0400

> I do not know how many of you have attended an ICANN meeting? You
> may have seen the remote participation service using text that is
> send via your web browser.  By using RTT, it will be an improved
> version of it.

One small point you don't mention. :-) This service costs serious $$
to provide. This just isn't an option for us to consider, even we all
agreed it would be a great thing to have.

Thomas

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Tue, 7 Apr 2009 19:35:35 +0200

Hi Wes,
There are professional transcribers who will do this.
SIP/SIPPING/MMUSIC/ECRIT and some events DO have a real-time text
Transcriber right now.
I use a transcriber to be able to attend such meetings due my deafness.

So, this service is not that unrealistic. It is quite possible to have such
real-time text service.

/Arnoud

> From: Wes Beebee (wbeebee) [mailto:[email-masked]]
> Sent: dinsdag 7 april 2009 19:18
> To: Arnoud van Wijk; John Leslie; [email-masked]
> Cc: [email-masked]
> Subject: RE: [vmeet] TECH Speech to Text and RTT to deliver
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 09 Apr 2009 10:31:43 -0400

John Leslie wrote:
> time at IETF weeks? 

This might be what you meant, but even if it isn't, a 'mode' worth considering 
is to have full presentations (slides and voice) uploaded 1+ days before a 
meeting, so that meeting time is only for discussion.

So, presentations become asynchronous, canned packages that can be seen/heard 
any time.

This makes it considerably easier to force meeting time to be used only for 
problem-solving.

It has the added benefit of aiding comprehension be non-native English listeners.

d/
-- 

   Dave Crocker

---

From: John Leslie <[email-masked]>
Date: Fri, 17 Apr 2009 11:26:07 -0400

Dave CROCKER <[email-masked]> wrote:
> This might be what you meant, but even if it isn't, a 'mode' worth 
> considering is to have full presentations (slides and voice) uploaded 1+ 
> days before a meeting, so that meeting time is only for discussion.
> 
> So, presentations become asynchronous, canned packages that can be 
> seen/heard any time.

   This would, IMHO, be valuable result.

> This makes it considerably easier to force meeting time to be used only
> for problem-solving.

   Currently, most WGCs:

- request a slot long enough to cover what they guess will be needed;

- publish a call for presentations;

- receive requests/suggestions;

- allocate the meeting time by presentation length;

- try to hold folks to the allocated time;

- close off the question line when running over; and

- take the occasional hum.

   It seems like an interesting experiment to have presenters drone on
as long as they "need" for a recording which participants may choose
to listen and watch at their own pace, with Working Group meeting time
limited to discussions.

   There are, of course, some presentations which make no effort to
cover the draft as a whole -- instead detailing the open issues. That,
IMHO, is a better use of WG meeting time; but even that could probably
benefit from being available a day earlier.

   The practical side of this is that the "last minute" seems to be the
only effective driver for finishing presentations. (It's quite common
to see folks in one session preparing their slides for the next!)

   So one must ask, "How would WGCs effectively enforce a 'last minute'
24 hours earlier?"

> It has the added benefit of aiding comprehension be non-native English 

   :^)

---

From: Doug Otis <[email-masked]>
Date: Fri, 17 Apr 2009 10:32:53 -0700

On Apr 17, 2009, at 8:26 AM, John Leslie wrote:

>> considering is to have full presentations (slides and voice)  
>> uploaded 1+ days before a meeting, so that meeting time is only for  
>> discussion.
>>
>> This makes it considerably easier to force meeting time to be used  
>> only for problem-solving.
>
>   Currently, most WGCs:
>

WebEx supports raising your hand (an icon next to your name), AND  
conducting polls!  The same as hum,  but more accurate and recorded.

> to listen and watch at their own pace, with Working Group meeting  
> time limited to discussions.

And have the meeting reference the presentation as a link that should  
been posted before the presentation cut-off.  :^)

> cover the draft as a whole -- instead detailing the open issues.  
> That, IMHO, is a better use of WG meeting time; but even that could  
> probably benefit from being available a day earlier.
>
>   The practical side of this is that the "last minute" seems to be  
> the only effective driver for finishing presentations. (It's quite  
> common to see folks in one session preparing their slides for the  
> next!)

This group might also review the practical aspects of enabling the  
room to hear remote participant's questions.  This might be something  
as simple as a switch on the output of a net-box attached to the  
projector displaying slides.  Perhaps a WebEx expert knows how this  
might be controlled by the "host" or "presenter" in software.  This  
input will need to be disabled when the room PA is being used for  
local participants.

>   So one must ask, "How would WGCs effectively enforce a 'last  
> minute' 24 hours earlier?"
>

Agreed.  This does seem to open a new era in how meetings might be  
conducted.

A small fee for remote participation might be appropriate to better  
ensure the service is not abused.  Without a service of this nature,  
remote participation is dramatically more difficult.

-Doug