[vmeet] Making remote hubs more formal, more complete, and more integrated
Hi. For obvious reasons, there is some renewed/increased interest in use of remote hubs for IETF meetings. Although there has been quite a bit of activity with hubs in recent years, I believe the expectations and requirements for them have been kept informal (and possibly idiosyncratic, with each hub doing whatever locals prefer.) If we believe we are going to be relying on the use of remote hubs more, we should try to clarify what services they need to provide and how their operation should be incorporated into the conduct of face-to-face IETF meetings. By way of example... Should they support multiple, parallel sessions, so that different groups of hub participants can 'attend' different, parallel sessions? Should the interaction between hub participants and participants at the 'main' venue be subject to particular procedures/style? Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] what's been working/failed/tried in hubs?
On 10/7/2016 1:12 PM, Christian O'Flaherty wrote: There were hubs that failed because remote participation was impossible (low quality) From this, do you have a sense of the minimum connectivity and other resource requirements, for successful technical operation of a hub? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Meetecho sessions start/stop time
On 4/11/2016 2:44 AM, Dan York wrote: ... I've alway run a separate Jabber client connected into each working group chat when remote. That's a useful hack, but it's a hack. Helpful now, but should not be necessary, IMO. Meetecho's software needs to be much more reliable. This marks its (well-deserved) transition to being an essential infrastructure capability for the IETF. I think the session start/stop issue actually requires a change in the model for operating Meetecho. One thought is to make a 'session' needs be much longer-lived -- in some cases, even persistent -- and able to proceed only with a jabber session. It can then add and remove audio and video as needed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Meetecho sessions start/stop time
On 4/10/2016 11:04 AM, John C Klensin wrote: There were a couple of times when I was typing something into Jabber (via Meetecho) when the session ended. That resulted in the screen, and Jabber session, abruptly clearing, so I couldn't finish the message for the Jabber log, copy the partially-finished one so I could later send something similar in email, or otherwise salvage what had been typed already. IETF Meeting Jabber sessions, outside of Meetecho, are long-lived. So the problem being described is quite basic. Unfortunately the only reasonable solution is to permit continued use of jabber, but possibly better to permit a "session not active" form of session participation (both before and after the session) with use of jabber. This could have a number of benefits, for preparation, coordination and -- in the current example -- finishing one's thoughts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Suggestion
On 4/10/2016 10:05 AM, Meetecho IETF support wrote: as you may remember, this feature is already there. Yes. The challenge is to get people in the face2face room to participate. From the experiments, this appears to involve a combination of an interface for them to use and, of course, the training to get that use. Based on those experiments, this issue appears to be a significant challenge in terms of usability design... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Meetecho suggestion for IETF-96 and beyond
On 4/10/2016 5:35 AM, Adam Roach wrote: In Firefox, whenever a page is making any sound, there will be speaker icon in the corresponding tab. You can click on the speaker icon to mute that tab (and click again to unmute). I suspect that Chrome may have a similar affordance for muting individual tabs. I'd never noticed that before, but tripped across it a day or two ago. Quite nice! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Experience as a remote attendee
It seems to me the loads on the Meetecho servers and network may only be possible during an event week... But there may be other ways to add load. Perhaps if there was an announced testing/debugging sessions on Fri or Sat prior we could get a lot of people to join. Friday would be best b/c +1 d/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Suggestion
On 4/8/2016 11:57 AM, HANSEN, TONY L wrote: Running a tech cockpit might be a task that could/should be offloaded from the chairs. When I was a chair, I found having to fiddle with ack. didn't mean to mandate it as a chair task, if it needn't be. all of the "tech stuff" to be distracting from actually paying attention to the meeting itself, which is where my focus as a chair needed to be. Exactly. That was the main point I intended. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Suggestion
On 4/8/2016 10:03 AM, Ray Pelletier wrote: I really like the idea of the chair cockpit. For example, we could get Meetecho to pre-load the slides that have been loaded in to the tools site (and all of the associated drafts), have their laptop connected to both projectors, and have their laptop be the place where you navigate the decks. The meetecho team was fantastically helpful this week, springing into action whenever you said their name in the jabber channel. That could be made more discoverable in a tweaked UI. In practical terms, this needs one person focused on running the meeting and a second person, sitting next to the first, running the meeting's integrated tech cockpit. More generally: We should formulate basic operational scenarios for each relevant actor (chair running the meeting, chair operating the cockpit, presenters in the room, presenters not in the room, audience in the room, audience not in the room. And we should formulate templates for how they interact. I think we are remarkably close to being able to make things work quite well. Maybe not reaching the magical 'seamlessly', but quite well. From my experience this week, the biggest deficiency is queue management. The virtual queue, for remote participants, worked usefully, but have in-room folk be in a separate queue creates a juggling problem operationally. Things will get far simpler if/when we figure out a workable way to get in-room folk also be listed in the virtual queue.[*] I suspect there is also an issue with the virtual queue, in terms of remote hubs, if they also have in-room microphones. Anyhow, defining the scenarios we want to support and targeting them is what we should do. And if we want this to be real for IETF 100, we'd better target a serious dress rehearsal for IETF 98. d/ [*] I suspect we are also going to want two or more cameras in a room, so that folk can see chairs, in-room speaker, and audience-at-microphone simultaneously. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Remote Hub Meeting: Open to All
On 4/6/2016 8:05 AM, John C Klensin wrote: owever, this identifies a more fundamental problem that I've commented on enough in the past to be sick of complaining about. Especially if one is either busy or inexperienced, having to bounce back and forth among multiple web pages to figure out As you mote, there are islands of significant improvement. I'm pretty sure, however, that what is needed is more than bridges connecting the islands, and very probably a much more integrative model. What we are lacking are models for /use/ of the meeting information. In UI design, two related approaches are task-based design and activity-based design.[*] We need perhaps 5-7 prototypical descriptions of how the meeting information gets used and then design the pages to facilitate such use. d/ [*] Don Norman likes to cite the Logitech Harmony remote as an example of how this approach differs from normal UI design. Rather than the user needing to turn on and off various devices and set various parameters, they simply punch a single button to "watch TV" or "listen to radio" and the underlying scripts and state information know what to turn off/on, adjust. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Remote Hub Meeting: Open to All
On 4/6/2016 7:43 AM, nalini.elk...@insidethestack.com wrote: I hadn't realized these were becoming so popular. That's really quite good news. I think the IETF doesn't list those, yet, but it probably should become a standard part of the IETF's meeting web pages. They are on the meeting Wiki: https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=ietf95#remote_hubs But actually, I am fighting to get them to be on a web page that persists across IETF meetings because a number of the hubs are not just to watch IETF meetings remotely. Sorry, yes. I now recall when that entry was created (as a placeholder initially.) I suspect there are quite a few changes needed to support remote hubs as an integral part of IETF meeting planning and operation, including for interim meetings... A permanent wiki page for them is probably a good start. I say 'wiki' for two reasons. First, I think it will take some experimentation to decide what the form and content of such pages need to be, and second, this needs to be an on-going, collaborative 'design' effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Remote Hub Meeting: Open to All
On 4/6/2016 7:08 AM, nalini.elk...@insidethestack.com wrote: All, We will be having a meeting to discuss remote hubs. This is for the entire community. Excellent! It will be in Buen Ayre B at 8:30 Thursday. It is probably obvious, especially for this topic, so please don't take offense to my asking whether this will be broadcast by meetecho, so remote folk can participate...? We have many hubs in Latin America and India already. There is talk of starting hubs in the Philippines, Russia, and Africa. There is even a hub in the U.S! I hadn't realized these were becoming so popular. That's really quite good news. I think the IETF doesn't list those, yet, but it probably should become a standard part of the IETF's meeting web pages. We would also like to discuss the following 2 new initiatives that could be a collaboration between remote hubs & the mentoring program: 1. IETF Pre-School (I am open to name change!) Description: People have 5 minutes to present an idea for a draft. They can use 2 foils. Objective: To find others to collaborate on draft & possible mentor(s) Problem: New authors need help with their first draft & finding possible collaborators. Mentoring Assistance: We can help do a webinar for people to present their ideas if people do not have a remote hub handy or wish to have more collaborators. I like this idea quite a bit. It forces the advocate to be concise and it takes little time. But it is a universal idea and not part of remote hubs? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Remote participation
On 3/29/2012 12:50 PM, Tony Hansen wrote: There are several separable things that are currently commonly conflated via the back end channel: taking notes/minutes, keeping a running indication of what slide is currently being presented, having real-time transcription of what was said, a forum for side-comments, and as a channel for remote participants. Having *all* of them on a single jabber channel is messy and makes it much harder for remote participants to actually participate -- even someone watching the jabber log diligently for comments to be channeled can get confused as to which things need channeling and which things are the many other things going on that channel. One WG I was involved with this week effectively used the etherpad minutes taker for doing the notes/minutes and indicating who was talking. This removed all of that stuff from the jabber stream and allowed the jabber to be a more effective channel mechanism. Meetecho combines jabber with presentation slides. jabber can be selectively displayed. (Etherpad remains separate.) This conveniently permits a single display to contain the information streams of slides and remote postings. (however it does effectively require all slides be uploaded to a single, controlling machine.) For my small working group (repute) with an agenda that was not tightly packed and with a small number of remote participants, it was convenient to keep jabber showing and to have an open room 'chat' among /all/ participants. That is, we did not need the time or organization discipline that comes with tight, slide-based presentations and/or many active participants at the microphone. For the more typical case that does need more session management, we are used to having someone speak for a jabber participant. What the Meetecho arrangement allows is, instead, keeping jabber off the screen, except when it's a jabber poster's turn, and then display their text rather than having someone running up and down at the mic channeling them. There are more conveniences to the jabber/slide integration, since the next slide displayed has its number and title injected into jabber, thereby synchronizing the jabber record nicely. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] IETF83 and draft-ietf-genarea-rps-reqs-03
So does that mean that Paul's requirements spec needs to have an SLA item on how rapidly someone shakes a leg if there is an outage? ... Yes, we might need that. In my limited experience, local A/V issues at the physical meeting can have a large impact on our ability to deliver vmeet services to remote participants. As I recall, Paul's mandate is to produce a functional specification, not a contract/requirements service document. That is, what should be the functional capabilities of remote participation service, not what are the critical operational parameters written into contracts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] financial question
Michael, On 1/20/2012 10:04 AM, Michael Richardson wrote: If such a fee were to offset this "reduction", then the push towards RPS might be revenue neutral, or even positive, and that would help remove some of the hurdles. Hmmm. Since Paul concurs with my assessment that the current thread on IETF financials is out of scope and since you are continuing the topic, I think I'm going to put on my vmeet list administrator hat right now. Please terminate this topic. There might be some legitimate cost-related discussion that is relevant to the current project, at some point, but this isn't it and this isn't the time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] financial question
On 1/20/2012 9:25 AM, Wes Beebee wrote: Peter - I thought that the point was to determine whether the IETF is financially incentivized to facilitate remote participation or whether the bar for enhancing remote participation was something other than technological or social. Except that that isn't in scope for the current project. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] financial question
On 1/20/2012 3:41 AM, Yoav Nir wrote: There is a financial question that I think is relevant, though. What is the budget for this? But requirements that may seem reasonable if your budget is $100,000 per meeting would not if your budget is $10,000 per meeting. There are perhaps four different axes that determine what we can deploy: 1. State of the industry in terms of products What range of capabilities is available or will be shortly? 2. Functional desires of our community What specific services match our needs, desires and style? 3. Operational constraints What are the venue and staffing capabilities? 4. Funding How much can we spend? The current project formally targets #2. Functional choices are, of course, entirely constrained by what products are available, unless we want to start doing product research and development, which is a risky and expensive path. Venue constraints include the mundane, such as plugging the remote participation system into the room public address system. Clearly we should not target functions that are restricted to products that cannot be used in the places we go... Whatever the current funding is for remote participation, it seems likely that it will change, with changes in the functionality we decide to provide. In an exercise like the current project, there is a tension between paying too much attention to mundane constraints and too little attention. Too little produces a specification that can't be realized. Too much distracts from producing /any/ specification or produces one that is far too limited. I suggest that the group has not yet worked far enough on specifying the desired functionality to need to need to focus on either operations or funding. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] financial question
On 1/19/2012 12:55 PM, Michael Richardson wrote: Specifically, how much of the meeting cost is variable (more attendees means more costs), how much is fixed (so, 2 meetings a year might reduce that cost). <http://iaoc.ietf.org/budget.html> Let me know what information you believe is missing from this set. (I am on the IAOC and am supposed to pay attention to such things...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] draft-ietf-genarea-rps-reqs comments
On 1/6/2012 7:44 AM, Randy Bush wrote: i think a good exercise would be to write two sets of bullets that fill less than one page that list short term functions we need and could realistically expect in a year and then long term wishful ideas. and expect that the latter will change a lot as we learn. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] draft-ietf-genarea-rps-reqs comments
On 1/6/2012 7:05 AM, Eliot Lear wrote:
On 1/6/12 2:54 AM, Fred Baker wrote:
following the meeting online ("remote attendees"). In the past
decade, the IETF has tried to make it easier for remote attendees to
"decades"? We started using the MBONE tools in 1992...
Indeed I recall someone making a comment in the Amsterdam '93 plenary using vat
<http://ee.lbl.gov/vat/>.
I don't remember which IETF it was but it was in the US, where a plenary
included a voip demonstration by serious voice audience participation from
Germany and Australia, as I recall. This was my first sense of how profoundly
things were going to be able to change.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Getting input on remote participation in WG interim meetings
On 12/6/2011 2:43 PM, Bob Hinden wrote: The only other alternative, is to spread the pain around so that a series of meetings are held at different times. That way the people in one region are not always inconvenienced. Everyone has a meeting in the middle of the night once every three meetings. IMO, somewhere between roughly 6am and roughly midnight, the inconvenience is relatively minor. 3am, for example, isn't minor. For most folk, so is 5am and 2am. The simple rule, for pan-global meetings, is to have 3am be mid-pacific. (If you've got participants in Australia, New Zealand and/or Hawaii or Western Alaska, there is no reasonable balance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Getting input on remote participation in WG interim meetings
On 12/6/2011 11:02 AM, Fred Baker wrote: ll of them. It's*Really*Hard* to find a time when it is daylight in Asia, Europe, and North America Given that 7am Pacific is midnight in Tokyo, yeah, it's a bit difficult... The practical tradeoff for virtual meetings is starting at 6am Pacific or 7am Pacific. At that, you get at most a two-hour window for the meeting. This argues for the multiple, shorter meetings that has already been suggested in this thread. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Fwd: Experiment: tools for remote participation in IETF80
On 1/23/2011 12:59 AM, Gonzalo Camarillo wrote: thanks for your comments. My answers inline: I went to download a client and it occurred to me that it would help to have a server available before the meeting, so that participants can familiarize themselves with using the service. The latest ietf.org home page has a "chat live with the ietf community" button that starts a jabber session to a common address. Something similar for this new tool might be useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Fwd: Experiment: tools for remote participation in IETF80
On 1/22/2011 12:19 AM, Gonzalo Camarillo wrote: Hi John, yes, that is the Simon Pietro we were talking about. With respect to the actual tool, I am more interested in the server part, which uses IETF protocols. The same way as folks use different XMPP clients to access the jabber chat rooms, people can use any SIP client to access this. We have been asked many times why we never used some of the RAI technologies at the IETFs. Simon Pietro (and his people at the university) volunteered to set up and support the server during the next IETF. Since there is no additional support needed to try this out, I decided to let the WG chairs know. Some of the WG chairs already used Skype during the last IETF meeting in their sessions. Using SIP-based VoIP clients instead should not make any difference. Gonzalo, This all sounds quite good. Thanks! An unfortunate aspect to the web site is that it does not contain information about, or for joining, the group that created the tool. Adding that will take some of the burden off you from having to vouch for this stuff. It might also increase the pool of participants. Speaking of which, this suggests that there is going to be a team at the meeting installing and running this stuff? As I understand it, a major impediment to use of this sort of tool at an IETF meeting is the challenge of linking the room sound system into the Internet voice-based mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Fwd: WebEx and Remote Presentations
On 6/24/2010 9:05 PM, IETF Chair wrote: Too much time is spent getting WebEx and the room audio system to cooperate. Russ, Thanks for forwarding the note to the list. I can't say the conclusion is a large surprise. This stuff seems to be right on the edge of having broad utility, but still on the wrong side of the edge. If it is possible for you or someone else to post a quick summary of the details describing the problems, it might prove useful to have that set of experience in the archive. One could imagine drawing from it for specifying future criteria... Again, thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] IETF Island in Second Life
On 1/19/2010 2:54 PM, Lisa Dusseault wrote: Hi, Is anybody interested in virtual reality meetings? Definitely. Thanks! In fact, I'd like to set up a test-drive session for the group, using this. We've already done some others (webex and elluminate) that were useful exercises. The impetus for this group came out of a plenary at the meeting where the virtual worlds BOF was first held. The potential of mixing VW constructs into the mix of voice and presentation mechanisms struck me as significantly enriching the remote conferencing experience, by virtue (pun?) of providing some spatial information. f/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Stockholm
Wes Beebee (wbeebee) wrote: It seemed like just a normal phone call on my end today in the WebEx session. Wes, many thanks for the quick report. Glad things went well. Also, even though I'm in Boxborough, MA and the other side was Stockholm, I didn't notice much of a delay in question/answer from my side. Perhaps this was because people were very polite, waited their turn, and did not talk over each other. I suspect that a question/answer segment is the most challenging to make work well for remote participation, because it involves multiple people who are active and can have fast shifts from one participant to the other. Do you have a sense of the number of people who were active during the Q/A segment? Your observation that participants were careful and polite is significant. Compared with having speaker and audience in the same room, can you offer any other comments about what was different and whether it could have caused problems? Any other comments about the experience? Again, thanks? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Notes and Screenshots from Elluminate demonstration meeting
John Buford wrote: For today's Elluminate demo, notes are below and screnshots are at: Thanks for sending that out, John! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] Reminder and details: Elluminate demonstration meeting: Tuesday, 26 May 7am Pacific time
Folks, Howdy. For those who can join in, as we discussed earlier there will be a meeting to play with the Elluminate <http://www.elluminate.com> product, tomorrow: Tuesday, 26 May 2009 0700 Pacific Daylight time Using Elluminate. Equivalent times -- 10 AM EDT 4 PM - Amsterdam 10 PM - Hong Kong Midnight - Sydney More generally: <http://www.timeanddate.com/worldclock/fixedtime.html?month=5&day=26&year=2009&hour=7&min=0&sec=0&p1=283> Information from Elluminate -- To join as a Participant, use the link below and type in your name on the sign in page: https://sas.elluminate.com/m.jnlp?sid=poctest&password=M.0EB1D7830FF565CB7FE75262DA87D1 All the recordings created in your vOffice will be available using the link below. At the conclusion of a recorded session, individual recording links can be obtained from this page and distributed to users. https://sas.elluminate.com/mrtbl?suid=M.2067000814FE525C245D8B5F506BE4 Available Resources Training and Documentation: Live online training sessions, recorded training sessions and user guides for all users are available from http://www.elluminate.com/support/training/. Technical Resources: Elluminate’s Support website at http://www.elluminate.com/support/ provides several technical resources for all of your users including a section for "First Time Users" which provides links to install the required software. Evaluation Resources: Tools and resources to help you evaluate Elluminate Live! are available from http://www.elluminate.com/support/docs/poc.jsp. The primary goal of the session will be to gain familiarity with the Elluminate product. For verisimilitude, the formal meeting goal will be to discuss and refine requirements for tools used to support interim meetings. If we can also discuss requirements for IETF Week meetings, that would be great. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] timeframe
John Leslie wrote: Our timeframe is too short to rule out "hacks" for Stockholm. For the IETF after that, we should be able to automate things. The timeframe for vmeet is whatever we set it to be. My own participation came from suggesting that we work towards replacing at least one IETF week with virtual meetings. There is no way that is happening immediately. It's a goal, but we are not trying to meet it instantly. Since there already are virtual interim meetings, here too we do not have to have an "immediate" deadline. That's why I think we can and should target capabilities beyond what the IETF currently use, balancing against easy, reliable use so that folks will not feel that it is a burden to participate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Supporting interim meetings
Brian Rosen wrote: Again, we have tested delay. It matters a lot. I didn't say it didn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Supporting interim meetings
I agree with Dave. There was some push-back about the suggestion for including a white-board function. I have certainly been in meetings where text was created collaboratively and in real-time. Charter-bashing is perhaps the most common example. Whether that is through a "shared whiteboard" or simple broadcast powerpoint revisions is secondary, IMO. But we need to be able to have materials changeable in realtime through collaborative efforts. My own concerns: 1) Participants need to figure out who's speaking. There are many ways to help them, but it deserves to be high among our concerns. Good point. Yes. 2) Snapshots of slides and/or whiteboards can help keep folks on the same page. Things change during meetings, and it's very easy for human memories to diverge. I'm not clear what capability you are suggesting, beyond what's already been listed. 3) There really should be a "record" of a meeting. This is, admittedly, an art form; but folks don't want to listen to an audio recording or even read a transcript of every word spoken. It very likely would be helpful if such a record could be visible in real-time to some participants. (I don't claim to be particularly good at doing this, but there _are_ folks who are good at it.) We currently have a jabber transcript, with a scribe, and a separate note taker. Are you suggesting something beyond these? 4) Every meeting should create "action items" that someone is responsible for following-up on. (Some are group items; some private.) These deserve far more visibility than they usually get. What sort of tool is involved in this, different from what is already in use? 5) Separate applications is very likely better than one integrated application. Webex drives me crazy by taking over organization of the screen. I don't want anything else interacting with my Jabber application. Interesting point. The tradeoff is that tools that aren't integrated each require separate registration and management. 6) VoIP-as-we-know-it doesn't meld well with POTS conferencing. Until VoIP can have consistent delay -- ideally Brian's 150 msec, but definitely under 500 msec -- we'll probably have to do without it. The lengthy discussion about these details was facinating, but too many people have had entirely too many, acceptable experiences with group conversations that were a mix of telephone and voip. 7) Learning curve is way too high for most telepresence packages. Folks simply _won't_ learn how to use them effectively. Formal Concern about the learning curve is certainly warranted. However we need to be careful about firm, pre-hoc assertions of what is and is not acceptable in terms of what the human factors folk call usability. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] The philosophy behind the list of recommendations.
John Leslie wrote: - audio bridge (could be VoIP, or POTS, that is a detail) - access to charts - IM capability as a side channel We have been running virtual meetings with that much for some time now, any many folks are used to it. By human nature, if we provide a tool that folks aren't used to, they'll gravitate back to _that_ model they're used to. So, while I support Dave's call for more than that, we can't just make a list -- we need to explain _why_ each feature we recommend is a significant improvement over bare-bones. and Dave Cridland wrote: > I've been asking around for solutions to these issues which are based > around open standards. While I fully understand, and indeed support, the > need for an "out of the box" solution to this, I'd like an "out of the > box" solution that used a suite of open standards to achieve these goals. Folks, We DO need to be clear about our reasons for choosing anything different from what we do today and the reasons for making the choices we recommend. On the matter of using products based on open standards, I'm frankly viewing that as desirable rather than mandatory. The reason is that I am pretty sure we do not want to block our use if the only acceptable solution happens to be proprietary. Our need is too strong, I believe. As for choosing functions that go beyond what is already in use, here is the reasoning driving the candidate choices I've listed: There is a difference between camping and staying at a 5-star hotel. In the range of capabilities for remote participation in an meeting, the current set of capabilities that we use are closer to the former than the latter. Remote participation is currently quite limited in number and style. We are seeking much greater use. I believe that seriously supporting truly inclusive participation for long-term, regular virtual meetings, the tools need to attain a level of capability, integration and ease of use that is considerably better than we currently employ. We need a lower barrier to use and we need better functionality to aid a wider range of meeting content and style. We might not need a 5-star set of tools, but we need a lot more than a tent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] [Fwd: [rt.amsl.com #15164] 'attendance' numbers for interimmeetings]
no, except for the ipsecme, per Thomas. d/ Olivier MJ Crepin-Leblond wrote: Any knowledge of what software they were using? O. - Original Message - From: "Dave CROCKER" To: Sent: Tuesday, May 12, 2009 6:40 PM Subject: [vmeet] [Fwd: [rt.amsl.com #15164] 'attendance' numbers for interimmeetings] Folks, FYI, here's some data on interim meeting participation: -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] [Fwd: [rt.amsl.com #15164] 'attendance' numbers for interim meetings]
Folks, FYI, here's some data on interim meeting participation: Original Message Subject: [rt.amsl.com #15164] 'attendance' numbers for interim meetings Date: Tue, 12 May 2009 09:35:20 -0700 From: Cindy Morgan via RT Reply-To: iesg-secret...@ietf.org To: dcroc...@bbiw.net Hi Dave, This is the information that we have available from the minutes of interim meetings over the last two years: IPSECME Feb 2009: ~20 (audio conference so exact number unavailable) GEOPRIV Jun 2008: 15 TICTOC Jun 2008: 30 MEXT Feb 2008: 20 LEMONADE May 2007: 14 HOKEYJan 2007: 16 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] TOOL: TeamSpeak
The system Thomas cited as used by IPSecME for an interim: <http://teamspeak.com/> <http://en.wikipedia.org/wiki/Teamspeak> This is a VOIP tool. * Address book for easier management of multiple TeamSpeak servers * Moderate channels for more control when hosting large group meetings * Toggle group or channel leaders as "Channel Commanders" to improve communication * Assign key-bindings for instant private chat and other functions * Whisper functions so you can speak privately to inidividuals, groups of persons, or users in other channels * Kicking/banning features which allow you to get rid of problem users in seconds * Record conversations via the client in native WAV format -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] TOOL: Elluminate -- virtual meeting planned
Folks, Elluminate - <http://elluminate.com/> They have a 'free for 3' service that Fred, Eliot and I experimented with a few weeks ago. It seems to be an entirely credible product. I've gotten Elluminate to authorize our having a larger session, for up to 25 people, so that we can conduct a session on a par with what we did for Webex. I'll propose a 2 hour session, 2 weeks from now. Initial suggestion: Tuesday, 26 may, 7am pacific daylight time. We should target a real session, trying to achieve real work, even though we are likely to have to devote a major portion to tutorial on the tool. We can also consider a second session, a la the webex process, for folks to each get a turn at hosting with the tool. Yes? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
[vmeet] Supporting interim meetings (was Re: Duties of WG Chairs)
sense that we require it. NICE-TO-HAVE 5. IM Existing IETF jabber can suffice, IMO. IM integrated into the conferencing tool would be nice, but only if it is on a par with the jabber service we are used to. 6. Telephone bridge (in, out) mumble. This adds quite a bit of expense. I could argue /against/ supporting it at all(!) 7. ??? Comments? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
