nalini.elkins | 1 Dec 17:47 2015

Minutes of Remote Hubs "Bar BOF" : IETF94 - Yokohama


Everyone,

I have written up the discussion at the Remote Hubs "Bar BOF" in Yokohama.  I have tried to organize this somewhat for coherency.  If there are any corrections or additions, please let me know.

The next steps as I see them:

1.  Add something to the IETF web site for Remote Hubs.   Please let me know if someone wants to help with this.

2.  Create an I-D out of the discussion below.  This will serve as community memory.  If anyone is interested in helping with this, please let me know.  At a minimum, we should have one participant from each of the major geographic regions.

3.  It occurs to me that to schedule a remote hub, we need to know what the agenda is.  For example, I am talking with one group in the U.S. that may be interested in only attending the TLS WG session.  But, we don't know when it is!  So, how do we schedule and publicize?

Thank you all for your help & please let me know any comments.

Nalini Elkins

 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Minutes:

The meeting started with a question was posed by Scott Bradner.   "Before we go any further, what is a remote hub?  Let's define it."

Various answers were given to this:

·         A remote hub can be anything where more than one person gathers to listen / participate in IETF sessions.  It can be as simple as someone's living room to major hubs with 7 rooms, telepresence and many people in each.  (Such large remote hubs do not actually exist at this point – but they could in the future.)
·         It is NOT necessarily an entire set of IETF sessions viewed in real time.
·         A remote hub for a full IETF meeting may not be practical.   Remote hub for a working group or a few sessions may work better.  At least in the beginning.
·         There also appear to be regional differences in how hubs are organized.   Latin America has previously run quite a few remote hubs as does India.  The two regions are different in how they arose, where they meet, and what they do.
·         Templates for remote hubs may not work because hubs may be very different across cultures and of very different sizes.
·         Alia Atlas added “I am delighted to see efforts. It doesn't have to be a large community. The remote hubs serve as socialization to spread the IETF culture and to build a sense of community.”
·         Lee Howard noted that “There is nobody from Africa in the room. We [Time Warner Cable] can help with 5 conference rooms”.

·         Goals for remote hubs:
o   Networking: hallway conversations and local connections 
o   Get more people working with the IETF
o   Not just attend,  but participate.   Get more work done
o   Build community             

Remote hubs seem to be springing up organically in quite a few regions.  Some history of remote hubs:
                    Alvaro Retano stated “We started in LACNIC.  The first one was in the Hawaii IETF. 50 people attending from hubs.   In Dallas IETF, we had 100  - 200 people and 20 hubs.”   Latin America has many remote hubs and plans for many more.  They are organic and may be quite small with only a few individuals interested in a particular topic
                    Christian O'Flaherty from the LACNIC region added: “We haven't spent any money at all. Many don't even have a projector. Just a PC.   Having 3-4 people discussing is more interesting than attending a meeting by themselves.”
                    Anand Raje reported that India has 23 hubs and over 500 members participating remotely at large universities as a part of the Indian IETF Capacity Building program.  See “IICB.org”

The qualities sought for remote hubs:
                    The hubs should be self-sustaining and organize themselves.  (That is not necessarily driven by  a central group)       

The pros for remote hubs are:
                    Not everyone can come to the meetings.   Provide that experience. 
                    A remote hub can help to create local communities.   Some felt that building the related communities is the most important benefit. 
                    Some felt that increasing participation in IETF is the most important benefit
                    There may be topics of local interest.
                    The remote hub can continue to work outside of the IETF meetings. 
                    A remote hub should be a better experience than attending remotely alone.    Provides a group of interested individuals or community with opportunities for networking. 

The cons for remote hubs:
                    What if the quality of the network connection is poor?   If I have important work to do, I may just attend from home where I can better control the connection.
                    What if others do not want to attend the same sessions that I do? 
                    John Klensin: brought up two observations:
1.       This is logistically a complicated deal.   Need space or conference room for the hub.
2.       Time zone can be quite challenging

Questions yet to be answered for remote hubs:
                    What if interest in a given hub spans many tracks??  Especially if simultaneous session demand exists.  Between 5-7 rooms may be needed to cover various areas. Should there be a hub and “Spoke” arrangement for different rooms/interests?
                    Will people travel within their country (air and hotel) as a “cheaper’ alternative to travelling internationally?
                    Why would people travel domestically any significant distance, rather than just set up another remote location?
                    How far should we expect someone to travel to a remote hub?   Should staying overnight be assumed viable? 
                    Would someone travel to the remote hub for just one session?  May need to schedule so that everyone at that hub would attend two or three consecutive sessions to make the travel worthwhile.
                    Scheduling across time zones could be an issue,  especially if time zone of meeting is Asia.  Can remote hubs use recordings and watch together to address time zone differences. 
                    Can remote hubs be a viable alternative for ACTIVE participants?    What about a chair or director?  
                    Does IETF sponsor any remote hubs?    
                    Can remote hubs approach the experience of attending the meetings?
                    Is there a cost to participate in a IETF meeting at a remote hub?   Physical meeting attendees pay $800, will remote hub attendees have any expenses?                
                    Are there any costs involved in running a remote hub? 
                    Is any training or certification needed to be a hub? 

How should IETF support / help remote hubs?
                    Web pages to get information out about remote hubs and what they are covering, schedules and other details/logistics. 
                    Potentially providing emails lists.
                    Ray Peltier offered complete support for remote hubs and to facilitate.  Maybe regional hosts are needed.

 
Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
<div><div>
<div class="">
<div class="" role="presentation" tabindex="0"><div class=""><div class=""><div class=""><div class="">
<div class="" align="center"><br></div>
<div class="" align="center" dir="ltr">Everyone,</div>
<div class="" align="center" dir="ltr"><br></div>
<div class="" align="center" dir="ltr">I have written up the discussion at the Remote Hubs "Bar BOF" in Yokohama. &nbsp;I have tried to organize this somewhat for coherency. &nbsp;If there are any corrections or additions, please let me know.</div>
<div class="" align="center" dir="ltr"><br class=""></div>
<div class="" align="center" dir="ltr">The next steps as I see them:</div>
<div class="" align="center" dir="ltr"><br class=""></div>
<div class="" align="center" dir="ltr">1. &nbsp;Add something to the IETF web site for Remote Hubs. &nbsp; Please let me know if someone wants to help with this.</div>
<div class="" align="center" dir="ltr"><br class=""></div>
<div class="" align="center" dir="ltr">2. &nbsp;Create an I-D out of the discussion below. &nbsp;This will serve as community memory. &nbsp;If anyone is interested in helping with this, please let me know. &nbsp;At a minimum, we should have one participant from each of the major geographic regions.</div>
<div class="" align="center" dir="ltr"><br class=""></div>
<div class="" align="center" dir="ltr">3. &nbsp;It occurs to me that to schedule a remote hub, we need to know what the agenda is. &nbsp;For example, I am talking with one group in the U.S. that may be interested in only attending the TLS WG session. &nbsp;But, we don't know when it is! &nbsp;So, how do we schedule and publicize?</div>
<div class="" align="center" dir="ltr"><br class=""></div>
<div class="" align="center" dir="ltr">Thank you all for your help &amp; please let me know any comments.</div>
<div class="" align="center" dir="ltr"><br class=""></div>
<div class="" align="center" dir="ltr">Nalini Elkins</div>
<div class="" align="center"><br class=""></div>
<div class="" align="center">&nbsp;</div>
<div class="">----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------</div>
<div class="">Minutes:</div>
<div class=""><br class=""></div>
<div class="">The meeting started with a question was posed by Scott Bradner.&nbsp;&nbsp; "Before we go any further, what is a remote hub?&nbsp; Let's define it."</div>
<div class=""><br class=""></div>
<div class="">Various answers were given to this:</div>
<div class=""><br class=""></div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>A remote hub can be anything where more than one person gathers to listen / participate in IETF sessions.&nbsp; It can be as simple as someone's living room to major hubs with 7 rooms, telepresence and many people in each.&nbsp; (Such large remote hubs do not actually exist at this point &ndash; but they could in the future.)</div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>It is NOT necessarily an entire set of IETF sessions viewed in real time.</div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>A remote hub for a full IETF meeting may not be practical.&nbsp;&nbsp; Remote hub for a working group or a few sessions may work better.&nbsp; At least in the beginning.</div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>There also appear to be regional differences in how hubs are organized.&nbsp;&nbsp; Latin America has previously run quite a few remote hubs as does India.&nbsp; The two regions are different in how they arose, where they meet, and what they do.</div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>Templates for remote hubs may not work because hubs may be very different across cultures and of very different sizes.</div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>Alia Atlas added &ldquo;I am delighted to see efforts. It doesn't have to be a large community. The remote hubs serve as socialization to spread the IETF culture and to build a sense of community.&rdquo;</div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>Lee Howard noted that &ldquo;There is nobody from Africa in the room. We [Time Warner Cable] can help with 5 conference rooms&rdquo;.</div>
<div class=""><br class=""></div>
<div class="">
<span class="">&middot;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>Goals for remote hubs:</div>
<div class="">
<span class="">o<span class="">&nbsp;&nbsp;&nbsp;</span></span>Networking: hallway conversations and local connections&nbsp;</div>
<div class="">
<span class="">o<span class="">&nbsp;&nbsp;&nbsp;</span></span>Get more people working with the IETF</div>
<div class="">
<span class="">o<span class="">&nbsp;&nbsp;&nbsp;</span></span>Not just attend,&nbsp; but participate.&nbsp;&nbsp; Get more work done</div>
<div class="">
<span class="">o<span class="">&nbsp;&nbsp;&nbsp;</span></span>Build community&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</div>
<div class=""><br class=""></div>
<div class="">Remote hubs seem to be springing up organically in quite a few regions.&nbsp; Some history of remote hubs:</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Alvaro Retano stated &ldquo;We started in LACNIC.&nbsp; The first one was in the Hawaii IETF. 50 people attending from hubs.&nbsp;&nbsp; In Dallas IETF, we had 100&nbsp; - 200 people and 20 hubs.&rdquo;&nbsp;&nbsp; Latin America has many remote hubs and plans for many more.&nbsp; They are organic and may be quite small with only a few individuals interested in a particular topic</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Christian O'Flaherty from the LACNIC region added: &ldquo;We haven't spent any money at all. Many don't even have a projector. Just a PC. &nbsp;&nbsp;Having 3-4 people discussing is more interesting than attending a meeting by themselves.&rdquo;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Anand Raje reported that India has 23 hubs and over 500 members participating remotely at large universities as a part of the Indian IETF Capacity Building program.&nbsp; See &ldquo;IICB.org&rdquo;</div>
<div class=""><br class=""></div>
<div class="">The qualities sought for remote hubs:</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>The hubs should be self-sustaining and organize themselves.&nbsp; (That is not necessarily driven by&nbsp; a central group)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</div>
<div class=""><br class=""></div>
<div class="">The pros for remote hubs are:</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Not everyone can come to the meetings.&nbsp;&nbsp; Provide that experience.&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>A remote hub can help to create local communities. &nbsp;&nbsp;Some felt that building the related communities is the most important benefit.&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Some felt that increasing participation in IETF is the most important benefit</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>There may be topics of local interest.</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>The remote hub can continue to work outside of the IETF meetings.&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>A remote hub should be a better experience than attending remotely alone.&nbsp;&nbsp;&nbsp; Provides a group of interested individuals or community with opportunities for networking.&nbsp;</div>
<div class=""><br class=""></div>
<div class="">The cons for remote hubs:</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>What if the quality of the network connection is poor? &nbsp;&nbsp;If I have important work to do, I may just attend from home where I can better control the connection.</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>What if others do not want to attend the same sessions that I do?&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>John Klensin: brought up two observations:</div>
<div class="">1.<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>This is logistically a complicated deal.&nbsp;&nbsp; Need space or conference room for the hub.</div>
<div class="">2.<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Time zone can be quite challenging</div>
<div class=""><br class=""></div>
<div class="">Questions yet to be answered for remote hubs:</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>What if interest in a given hub spans many tracks??&nbsp; Especially if simultaneous session demand exists.&nbsp; Between 5-7 rooms may be needed to cover various areas. Should there be a hub and &ldquo;Spoke&rdquo; arrangement for different rooms/interests?</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Will people travel within their country (air and hotel) as a &ldquo;cheaper&rsquo; alternative to travelling internationally?</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="">Why would people travel domestically any significant distance, rather than just set up another remote location?</span>
</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>How far should we expect someone to travel to a remote hub?&nbsp;&nbsp; Should staying overnight be assumed viable?&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Would someone travel to the remote hub for just one session?&nbsp; May need to schedule so that everyone at that hub would attend two or three consecutive sessions to make the travel worthwhile.</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Scheduling across time zones could be an issue,&nbsp; especially if time zone of meeting is Asia.&nbsp; Can remote hubs use recordings and watch together to address time zone differences.&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Can remote hubs be a viable alternative for ACTIVE participants?&nbsp;&nbsp;&nbsp; What about a chair or director? &nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Does IETF sponsor any remote hubs?&nbsp;&nbsp;&nbsp;&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Can remote hubs approach the experience of attending the meetings?</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Is there a cost to participate in a IETF meeting at a remote hub?&nbsp;&nbsp; Physical meeting attendees pay $800, will remote hub attendees have any expenses?&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Are there any costs involved in running a remote hub?&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Is any training or certification needed to be a hub?&nbsp;</div>
<div class=""><br class=""></div>
<div class="">How should IETF support / help remote hubs?</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Web pages to get information out about remote hubs and what they are covering, schedules and other details/logistics.&nbsp;</div>
<div class="">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Potentially providing emails lists.</div>
<div class=""></div>
<div class="" dir="ltr">&bull;<span class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Ray Peltier offered complete support for remote hubs and to facilitate.&nbsp; Maybe regional hosts are needed.</div>
<div class=""></div>
<div class=""><br></div>
</div></div></div></div></div>
<div class=""></div>
</div>
<div class=""><div class=""><div class=""><div class=""><div class="" dir="ltr"></div></div></div></div></div>
<div></div>
<div>&nbsp;</div>
<div class="signature">Thanks,<div><br></div>
<div>Nalini Elkins</div>
<div>Inside Products, Inc.</div>
<div>www.insidethestack.com</div>
<div>(831) 659-8360</div>
</div>
</div></div>
John C Klensin | 5 Nov 01:23 2015

Quick post-meeting thoughts

Hi.

A few comments made in the last few minutes of the meeting
illustrates another part of what I was trying to get at when I
suggested it was important to be clear about objectives and
expectations.

A "try it, some will work and some won't" approach is
appropriate, indeed optimal, for many notions of what a remote
hub is about.  However, if there is a WG for which I (or some
other remote participant) is critical (e.g., a WG Chair or
co-chair, document-editor, or key technical contributor, then
the situation is much more like that of a virtual meeting with
some participants present: if the technology and arrangements
don't work, then the whole meeting, is at risk of failure.  The
recent discussion on the IETF list about the Meetecho issues
during the plenary is probably worth looking at as an
illustration. For that type of situation, very much unlike some
people gathering together to observe a WG session together and
discuss it (and various other scenarios)  "too bad, it didn't
work, we will try again another time" is just not acceptable.

Using myself as an example, I'd far prefer to be participating
with others at a hub arrangement to sitting in my home office if
the logistics were reasonable.  However, if the setup for the
hub were "best efforts, we hope it will work out but maybe it
won't" and I was critical to the relevant WG, I'd need to stay
home just to minimize the number of variables.  On the other
hand, if there was a handy hub and a WG is was interested in but
not heavily involved with, I'd probably drop in on the hub if
that were feasible, just as I'd drop in on the WG session if I
were physically at IETF and didn't have conflicts.

Ray, who is probably the key person who would get screamed at if
a virtual interim meeting ended up not being accessible to some
key participants, may be able to add more perspective to this.

>From my point of view, any of a large collection of models
("templates"?) would be reasonable, helpful, and probably worth
experimenting with.  However, there are circumstances in with
failures are more acceptable than others and it seems to me that
it is really important to know the differences and be clear
about them.

Good discussion.  Thanks for including me.
    john

p.s. If the person from China who spoke late in the session (I
wasn't able to get a name) would drop me a note offlist, I may
have a suggestion or two that might be useful.

Tom Pusateri | 31 Oct 21:36 2015

Calculating sessions local start time

In the IETF iPhone/iPad app, if you go to Settings and scroll down to the bottom to Time, you can switch on
local time and the schedule will be shown in your local time zone.

This is handy if you're remote but want to listen in live.

If you select a session while its live, you will see a green Audio button in the session detail which will
stream the live audio. Tou can then bring up the slides and follow along. 

Tom

nalini.elkins | 21 Oct 22:36 2015

Remote Hub Bar BOF

Hello All,

We want to do a small meeting at IETF94 - a Bar BOF to discuss the idea of Remote Hubs.  (I am still waiting for the room assignment) but the time will be Thursday, Nov. 5th 7:45am-8:45am.  Please let me know if you are interested.


Issues
-------

1.  Many people cannot afford to attend IETF meetings live.

2.  It can be more interesting and useful to attend remote meetings as a group.  The face-to-face (F2F) interaction adds a great deal to the overall process.

3.  Some regions (Latin America, India) have already started remote hubs.  We can learn from each other.

4.  We are starting Regional Mentoring.  Such mentors can work with remote hubs.


Agenda
------

1.  We come up with some templates for remote hubs in our meeting

2.  We have some goals for remote hubs for IETF95.  For example:

U.S. : 5 hubs
Latin / South America: 5 hubs
India : 5 hubs

... etc.

A hub can decide which remote hub template they want to use.

3. We do an I-D describing our thoughts (due date: Jan. 1st, 2016)

4.  We post the I-D on the IETF discussion list for comments.  (Due date: Jan 10, 2016)

5.  We try to meet our goals for remote hubs!  (Due date: February 15, 2016)



Comments?

Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


<div><div>
<div>
<span>Hello All,</span><br>
</div>
<div>
<div>
<div class="y_msg_container">
<br>We want to do a small meeting at IETF94 - a Bar BOF to discuss the idea of Remote Hubs.&nbsp; (I am still waiting for the room assignment) but the time will be Thursday, Nov. 5th 7:45am-8:45am.&nbsp; Please let me know if you are interested.<br><br><br>Issues<br>-------<br><br>1.&nbsp; Many people cannot afford to attend IETF meetings live.<br><br>2.&nbsp; It can be more interesting and useful to attend remote meetings as a group.&nbsp; The face-to-face (F2F) interaction adds a great deal to the overall process.<br><br>3.&nbsp; Some regions (Latin America, India) have already started remote hubs.&nbsp; We can learn from each other. <br><br>4.&nbsp; We are starting Regional Mentoring.&nbsp; Such mentors can work with remote hubs.<br><br><br>Agenda<br>------<br><br>1.&nbsp; We come up with some templates for remote hubs in our meeting <br><br>2.&nbsp; We have some goals for remote hubs for IETF95.&nbsp; For example: <br><br>U.S. : 5 hubs <br>Latin / South America: 5 hubs <br>India : 5 hubs <br><br>... etc. <br><br>A hub can decide which remote hub template they want to use. <br><br>3. We do an I-D describing our thoughts (due date: Jan. 1st, 2016) <br><br>4.&nbsp; We post the I-D on the IETF discussion list for comments.&nbsp; (Due date: Jan 10, 2016) <br><br>5.&nbsp; We try to meet our goals for remote hubs!&nbsp; (Due date: February 15, 2016) <br><br><br><br>Comments?<br><br>Thanks,<br><br>Nalini Elkins<br>Inside Products, Inc.<br>www.insidethestack.com<br>(831) 659-8360<br><br><br>
</div> </div> </div>  </div></div>
Toerless Eckert | 24 Mar 20:13 2015
Picon

How to log into meetecho as chair ?

Trying to understand

https://www.youtube.com/watch?v=m8pIhJiS0Y8&feature=youtu.be

But it doesn't say at the beginning which URL to log into,
and the URLs i found on the remote participation IETF page wasn't
offering me any login option... Confused...

Is there an actual body present here who can walk me through that meetecho experiment ?

Cheers
    Toerless

Russ Housley | 11 Feb 06:56 2015

Fwd: report on use of JITSI for the ROLL virtual Interim meeting


> From: Michael Richardson <mcr+ietf@...>
> Date: February 10, 2015 1:23:10 PM EST
> To: Emil Ivov <emcho@...>,
jitsi@..., Bernard Aboba <bernarda@...>
> Cc: Harald Alvestrand <harald@...>,
iesg@..., Joe Hildebrand
<jhildebr@...>, Ines Robles <maria.ines.robles@...>
> Subject: report on use of JITSI for the ROLL virtual Interim meeting
> 
> 
> {this email is FYI, and doesn't really require any action.
> tl;dr>  it worked well enough for our meeting, thank you. }
> 
> The ROLL Virtual Interim meeting that occured today was done using the
> JITSI.tools interface.  That we were going to do JITSI was announced with the
> original announcement (4 weeks ago), but of course, many did not bother
> testing their environment until the last moment.
> 
> We published a 5 revisions of slides, with the first revision going out more
> than a week beforehand, and the last version about three hours before
> hand. They went out as PDF, and were uploaded to the proceedings site each
> time.  We think that it is pretty important that the slides be out ahead of
> time so people know what to expect, and that they go up in PDF, so that
> people can read them on any platform.
> 
> I did try to the "Share Prezi" link in JITSI (which I had not seen before),
> but I did not realize that Prezi is a cloud based slide creation system, and
> that I could not just point at a PDF file somewhere... too bad, that would
> have been nice.  I will actually consider having my laptop host the "slide
> sharing" screen next time seperate from my own use, as that would let people
> see me and the slides. I understand that G+, webex and other systems are
> going in that direction as well.
> 
> A few people had to reload the page; and there was the usual "does my
> microphone even work", and also "oops, I'm still muted" problems that occur
> on all teleconference.
> 
> Emil and I had previously set up a SIP bridge for audio, and it did work at
> one point, but SIP spammers/attackers on my PBX forced us to add some
> whitelist ACLs.  Despite dropping those, the SIP bridge did not work again,
> and we did not re-establish communication.  The lack of an available audio
> bridge was an issue for a number of participants.  While I was going to
> either call one or two participants from my SIP bridge, I also thought I
> might dial the bridge into a webex bridge, for those that I could not dial,
> could not dial me, or if my SOHO VDSL2 ran out of bandwidth.  I wanted to
> repoint the SIP bridge to a location with better connectivity, but I wanted
> it work first.
> 
> We had between 10 and 12 participants in the conference, and I think that we
> had the right set of people there.  It worked well once we got going.  Two
> participants were initially on Cisco VPNs, and they found they had to turn
> off the VPN, and then they had to either reload the page, or they had to
> restart the browser in order to get audio to work.  I know that Alvaro Retano
> tried to join from his cisco office, and that it failed because of his
> corporate firewall, which of course, he couldn't just "turn off". I've been
> told that this is a known pain point for webrtc, and I guess that the SEMI
> workshop talked about this too.
> 
> I would like to encourage the IESG and IAB to hold a few calls a year on
> JITSI, in order to make it clear to respective IT departments that this
> technology is critically important.  Dog food.
> 
> I want to say that today, that ietf.webex.com tells me again that I have a
> completely unsupported platform and browser; it did this to me last week for
> a day and then stopped. I can not even start the call which I could
> previously do (and then use the PSTN to connect).  This worked most of the
> time up to last week (but webex has NEVER worked for computer audio, and I
> can't share slides, the screen sharing, when it works is mostly a fail)  This
> almost totalled one nomcom call last week.  Joe and I have talked in the past
> about webex' lack of support for common technical user platforms, and I wish
> the IETF would move to formerly abandon it.
> 
> It would also be nice if we had an official SIP bridge that could get audio
> to the PSTN, ideally controlled from within JITSI.
> 
> {The 2013/2014 nomcom used G+ Hangouts, and we were able to use the Google
> internal one which permitted >9 participants as we had a Google person who
> had access to it.  The 2014/2015 Nomcom tried a call or two with JITSI, but
> the audio bridge problem was more severe}
> 
> --
> Michael Richardson <mcr+IETF@...>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

Hosnieh Rafiee | 7 Mar 16:45 2014

Re: [89attendees] Remote participation is pretty good

John,

> 
> > Just a far suggestion
> >
> > It would be good that there was possibility like a classroom  that the
> >remote participant could really talk (raise their  hands and the jabber
> >scripter gives him/her permission for
> > microphone) and talk. Then I guess the remote participant  wasn't
> >something different than the real participant ...
> 
> Sadly (from my point of view), we know how to do this at least moderately
> well.  It requires some conventions about how the Jabber user (or other
> remote) participant gets the attention of someone in the room and how the
> person in the room gets the attention of the chair, ideally on a priority
basis to
> compensate for the "slow typing" problem you mention.  It ideally requires
> someone watching the Jabber list carefully who is not also charged with
> scribing and a convention about what entries that are typed into Jabber
are to
> go to the microphone (prefixing comments with "Mic:" has been used a lot.
> 
> In Vancouver, we tried giving Jabber scribes and others who were likely to
> carry messages to the microphone special hats so they could easily be seen
by
> chairs, but I'm not convinced it accomplished anything.  And, of course,
if
> there are conventions, everyone needs to be told about them.
> 
> Of course, more advanced technologies like Meetecho and WebEx can help
> too, but also require attention.
> 
> But I think the problem is rather more in our taking remote participation
> seriously enough to actually execute on what I think we know how to do
than
> in not knowing how.  And, also, probably sadly, being an old timer and
> complaining a lot helps too.

This is why I said it is a wild idea...  (it is like the future of IETF
meetings... sorry I think, I am more looking ahead rather than the present).
I just imagine a case where instead of everyone lining at the microphone,
they just use the same software as the remote participant use only for
questioning section and the application gives the permission of mic to each
requester based on FIFO algorithm. Consider a scenario where A is a remote
participant and B is at IETF. Both use software X (at the moment meetecho).

In a time of questions, to have a fairness, only the jabber scribes or admin
of this activate" question status". The application X gives permission to
the participants based on FIFO. For the app, it does not matter whether the
participant is remote or there. If the participant is there and it is his
time, he just start talking on the mic at the room. If it is not there, the
speaker on the admin device or recording device is enabled and let
participant A to talk. Just when folks loging to the app by their names,
they also tells the application whether they are there or remote. This is
good only for microphone permission process. The software can also assign
times to the person who wants to ask question and activate the mic for that
period.  So, this is both fair for both remote and present participant and
also a good time management. The microphone of the room can also enable or
disable via the recording system so, it is only enabled when someone in the
room has permission to talk.

If you're interested I can tell you much of these kinds of fancy ideas and
stories :-)

Hosnieh

Hosnieh Rafiee | 7 Mar 13:59 2014

just a suggestion

I copied my message that I sent to All attendees here 
-------------------------------
Just a far suggestion
It would be good that there was possibility like a classroom that the remote
participant could really talk (raise their hands and the jabber scripter
gives him/her permission for microphone) and talk. Then I guess the remote
participant wasn't something different than the real participant 

Of course it is just a wild idea.. and needs infrastructure and works.

Thanks for all jabber scripter, all organizers, all people who helped the
remote participant to feel like they are there.

Hosnieh

IETF Secretariat | 28 Jun 23:07 2013
Picon

New Non-WG Mailing List: vmeet -- IETF remote participation meeting services discussion

A new IETF non-working group email list has been created.

List address: vmeet@...
Archive: http://www.ietf.org/mail-archive/web/vmeet/current/maillist.html
To subscribe: https://www.ietf.org/mailman/listinfo/vmeet

Purpose: Explore, specify and develop improved services for remotely participating in IETF meetings.
Look for eventually supporting virtual meetings that have no physical venue. A modest form of a virtual
meeting is a small-group conference call, such as regularly conducted by the IESG, IAB and IAOC.

For additional information, please contact the list administrators.
John Leslie | 1 Oct 16:22 2012
Picon

WebEx on MacOSX

   After a system update Thursday (10.7.5), WebEx stopped working on
my Mac; and sternly refuses to get any better.

   I find Issue 152617 in chromium:
...
" Chrome autoupdated to 22.0.1229.79, and WebEx fails after the restart.

   Since a number of IETF activities depend on WebEx, I sincerely hope
this will find a resolution soon...

--
John Leslie <john@...>
Simon Pietro Romano | 12 Sep 15:54 2012
Picon
Gravatar

Feedback on draft-ietf-genarea-rps-reqs-07

Hi Paul and vmeetters,

thank you for submitting a revised version (-07) of your draft. Please find below my comments, preceded by the usual disclaimer about the length of my message ;-).
I'll take some excerpts of the draft and let them be followed by my comments/observations. As a general comment, I personally think that the document mixes technical and non-technical requirements for the RPS and I find this a bit confusing. Technical requirements are those directly coupled to the functionality that the RPS will have to make available and would be easily described (or mapped) with a formal modeling approach like UML, in much the same way as with any other software requirements specification. Non-technical requirements are most of the times related to 'policies', which, as I have often claimed on IETF mailing list discussions, are always orthogonal to (and hence independent from)  technical details of a system. I'll try to make this clear in my detailed review, but for the sake of clarity I'll give you an example of what I'm saying right below:

- technical requirement:
**Requirement 07-02**: All tools in the RPS MUST be able to use both IPv4 and IPv6 addresses natively. - non-technical (policy-based) requirement:

**Requirement 07-07**: Both local and remote attendees SHOULD be able to easily contact a single entity who is available throughout the meeting if they find problems with any of the RPS tools, and to get fairly rapid response. This entity needs to be able to handle as RPS tool problems in the meeting rooms, or be able to quickly contact someone who can address those problems. My personal preference would be to have a clear distinction between the above classes of requirements. I think this would also make it easier, in the future, to edit a formal
software requirements specification for potential bidders.

This said, I also found a third category of requirements which in my view fall in a specific class which I would call something like "Requirements for the seamless integration of the future RPS system with the current IETF tools and meeting materials portal". To provide you an example of this third class of requirements, I'll copy/paste a couple below:
**Requirement 07-49**: The RPS MUST automatically convert PowerPoint presentations to PDF and make both available for distribution at the same time. NOTE: in the requirement below I assume that with the expression "make both available for distribution" you are referring to slides publication on the meeting materials page, right? **Requirement 07-50**: Presenters MUST be able to update their slides on the IETF site up to just before their presentation, if such update is allowed by the WG chairs. NOTE: this last example is in my view actually a mix of a "policy-based" and an "integration" requirement. So, let's get started with the details.
**Requirement 07-09**: The deployment of the tools here MUST take into account making the tools accessible to as many IETF attendees as possible. Such deployment is likely to include technical accommodations for those with visual and hearing disabilities.
 Agreed. But this formulation sounds a bit too generic. What kind of accommodations do you have in mind? As an example, for deaf people, you might be thinking of remote transcription services like "Remote CART" (Communication Access Real-time Translation) captioning, perhaps based on standards like XEP-0301 (Real-Time Text for XMPP -- http://www.xmpp.org/extensions/xep-0301.html). In any case, I would make this part more explicit.

**Requirement 07-10**: All remote attendees at regular IETF meetings and interim meetings who make contributions MUST register with the IETF Secretariat before contributing using any of the RPS tools. This is out of scope for the RPS. I think the basic idea behind section 2.1 is that the IETF secretariat should in the future envisage different registration options (local attendee, remote contributing attendee, remote non-contributing attendee) and the RPS should have access to such information when logging users into the system, so to be capable of associating them with a specific role. In summary, from the RPS's point of view, the only requirement should be that it be capable of supporting different user roles, once again configured through policies. You actually mention something like this when you state, at the end of the section, that "registration might happen in the IETF's Datatracker".

Coming to section 2.3 on Audio, I have already stated on this ML (http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html) that I strongly believe the priorities you identify in the document are not in the right order. I cannot think of a 'future' RPS which is not capable of reliably supporting audio from remote attendees (both those who have to give presentations and those who just want to make sporadic comments).  I know this brings in some technical obstacles, but I nonetheless insist on this point.
With respect to the specific requirements you identify:

**Requirement 07-20**: The RPS MUST enable relay of messages from IM to the mic to be able to happen as quickly as if the remote attendee was local. It is not clear to me what you mean by "as quickly as if the remote attendee was local".
From a technical standpoint, this should translate in something similar to what I was proposing in the already cited mail, i.e. a solution which automatically announces a request for attention coming, via the jabber room, from a remote: in a few words, if a remote writes a sentence in the chat and lets it be preceded by the [mic] prefix, the RPS should automatically play a predefined 'attention sound' inside the room.

**Requirement 07-21**: The person relaying from IM to the mic must be available throughout the WG meeting. To date, this has been done by WG volunteers in the room. In the future, it could be done the same way, or maybe could be facilitated by hiring people to attend meetings for the specific purpose of being IM-to-mic scribes, this part seems to be out of scope for the RPS
or maybe could be done with tools that allow copy-and-paste of text from IM to a speech synthesizer that reads it to the room. with respect to this part, you should obviously also look after moderation in this case (I copy-and-paste the sentence, but the sentence itself should be read to the room
at the right time, i.e. when the the user's turn to gain the floor arrives).

**Requirement 07-24**: A WG chair MUST be able to control the sound coming from any particular remote attendee. This control MUST allow reduction in volume, all the way to complete muting, of the remote speaker. This requirement, together with others that I will discuss, might be put in a general technical sub-category associated with floor control. With respect to this, I also remark
that if we start talking about moderation and floor control, we have to be careful when identifying roles, meaning that we should avoid making a direct logical link between
the WG chair (who is physically chairing the session) and the moderator (who is actually 'chairing' one or multiple floors/media): the two roles might easily be played by distinct
persons (this is, again, a matter of policies).

**Requirement 07-26**: The audio system used by the RPS MUST be able to integrate with systems commonly used in the venues used for IETF meetings. These venue systems typically include line-level audio outputs from mixers that combine all the mic inputs into a single stream. Some venue systems also allow for headphone level inputs from PCs to be mixed into the audio stream. Right. With reference to this part, you might want to have a look at what we are asking for when it comes to support sessions with Meetecho:

http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf

**Requirement 07-39**: The IETF Secretariat MUST be able to easily set up the individuals allowed to use the floor control system for a particular meeting and to change the settings at any time, including during the meeting.
Isn't this out of scope for the RPS (policy-related)?

**Requirement 07-40**: The chair SHOULD be able to monitor the sound levels of the audio being delivered to remote attendees to be sure that they can hear what is going on in the room. Beware that this calls for remote monitoring on the client side, which not as easy as one might expect. I would better state that the chair should be able to
'adjust' the sound of the audio of remotes, based on their feedback about the perceived quality.

**Requirement 07-43**: When video is allowed for remote attendees to give presentations (as described in Section 2.3.3), the audience in the room SHOULD be able to see the presenter speaking. Doesn't this simply translate in a requirement to have a secondary beamer in the room which is projecting the remote speaker's video (which would be out of scope for the RPS)?

The whole section 2.5 is in my view related to the third category of requirements I introduced above ("Requirements for the seamless integration of the future RPS system with the current IETF tools and meeting materials portal").
I think that a requirement for the RPS here would just be that of being able to show (in the meeting virtual room) the slides that have been uploaded to the meeting materials page. This might, e.g., be done through a conversion of ppt/pptx/pdf/odp/etc files to whatever the RPS uses internally (e.g. a sequence of images, a low-rate video, etc.).

**Requirement 07-53**: The slide stream MUST represent the slides as they are projected in the room, allowing the presenter to go back and forth, as well as to edit slides in real time. This makes it clear to the remote attendees which set of slides, and which slide number, is being currently shown. Real-time editing of the slides is a tough requirement, indeed. If you think of how this is typically done, the most likely option here would be to have the speaker make his presentation by using some sort of application sharing tool (e.g., by sharing his powerpoint application running on his laptop). I think we should relax this requirement, by associating a MUST to just showing slides and browsing back and forth through the presentation. Slide annotations might then be done by using a whiteboard or some similar tool. What is your feeling about this?

**Requirement 07-60**: A much-lower priority requirement is the ability for group-editing of graphics.
As before, this is a tough one. What do you mean by group editing of graphics? Are you thinking of a sort of shared "Paint", a whiteboard, or what?

**Requirement 07-61**: The RPS MUST support storage and distribution of recordings of the audio, video, and slide presentations for all WG meetings. I would also specify that it is highly desirable to have "synchronized" recordings of the meeting media.

**Requirement 07-64**: Users MUST be able to easily find the archives of the recordings and instant messaging transcripts of a particular WG or BoF session at a particular meeting. This is out of scope for the RPS (policies).

**Requirement 07-66**: The RPS MUST support recording and storage of recordings of the audio, video, and slide presentations of interim meetings as well as regular IETF meetings. Once again, from the RPS perspective, there should be no difference at all between recordings of a regular meeting and recordings of an interim.

**Requirement 07-67**: Given that interim meetings are often run without the help of the IETF Secretariat, making these recordings MUST be easy for WG chairs. Why should the chairs bother about the recordings? I think the RPS should be capable of making recordings in an automated fashion. The chairs
should just don't care about the inner workings.

**Requirement 07-74**: The RPS MUST allow a session to be moved from one room to another during the session This is needed because the Secretariat sometimes need to swap the rooms for WGs when it becomes clear that one is too full and another room has excess space. Apart from the unavoidable association between the mixer in the room and the virtual room in the RPS, this should have no other impact on the RPS itself.

**Requirement 07-79**: Remote attendees MUST be able to easily find all the material they need to effectively participate, including links to audio, video, instant messaging, slides, and so on. This material MUST be available well before the time of the meeting. The page with the meeting material SHOULD allow the remote attendee to easily perform a time conversion to and from the local time at the IETF meeting. Out of scope for the RPS (policies).

**Requirement 07-84**: The RPS SHOULD have a central location where the specifics about how remote participation is supported for every WG interim meeting. This will reduce the problems often seen where messages about how to participate in an interim meeting get buried in the WG mailing list. I don't understand this one, but looks like a policy-related issue.

Hope you'll find this feedback useful.

Cheers,

Simon


















-- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano-7EJwN6hzp+g@public.gmane.org http://www.comics.unina.it/simonpietro.romano <<Molti mi dicono che lo scoraggiamento è l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/
<div>
    Hi Paul and vmeetters,<br><br>
    thank you for submitting a revised version (-07) of your draft.
    Please find below my comments, preceded by the usual disclaimer
    about the length of my message ;-).<br>
    I'll take some excerpts of the draft and let them be followed by my
    comments/observations. As a general comment, I personally think that
    the document mixes technical and non-technical requirements for the
    RPS and I find this a bit confusing. Technical requirements are
    those directly coupled to the functionality that the RPS will have
    to make available and would be easily described (or mapped) with a
    formal modeling approach like UML, in much the same way as with any
    other software requirements specification. Non-technical
    requirements are most of the times related to 'policies', which, as
    I have often claimed on IETF mailing list discussions, are always
    orthogonal to (and hence independent from)&nbsp; technical details of a
    system. I'll try to make this clear in my detailed review, but for
    the sake of clarity I'll give you an example of what I'm saying
    right below:<br><br>
    - technical requirement: <br>**Requirement 07-02**: All tools in the RPS MUST be able to use both
   IPv4 and IPv6 addresses natively.

    - non-technical (policy-based) requirement:<br><br>**Requirement 07-07**: Both local and remote attendees SHOULD be able
   to easily contact a single entity who is available throughout the
   meeting if they find problems with any of the RPS tools, and to get
   fairly rapid response.  This entity needs to be able to handle as RPS
   tool problems in the meeting rooms, or be able to quickly contact
   someone who can address those problems.

    My personal preference would be to have a clear distinction between
    the above classes of requirements. I think this would also make it
    easier, in the future, to edit a formal<br>
    software requirements specification for potential bidders.<br><br>
    This said, I also found a third category of requirements which in my
    view fall in a specific class which I would call something like
    "Requirements for the seamless integration of the future RPS system
    with the current IETF tools and meeting materials portal". To
    provide you an example of this third class of requirements, I'll
    copy/paste a couple below:<br>**Requirement 07-49**: The RPS MUST automatically convert PowerPoint
   presentations to PDF and make both available for distribution at the
   same time.

NOTE: in the requirement below I assume that with the expression "make both available for distribution" you are referring to slides publication on the 
meeting materials page, right?

**Requirement 07-50**: Presenters MUST be able to update their slides
   on the IETF site up to just before their presentation, if such update
   is allowed by the WG chairs.

    NOTE: this last example is in my view actually a mix of a "policy-based" and an "integration" requirement.

So, let's get started with the details.

    <br>**Requirement 07-09**: The deployment of the tools here MUST take
   into account making the tools accessible to as many IETF attendees as
   possible.  Such deployment is likely to include technical
   accommodations for those with visual and hearing disabilities.

    <br>
    &nbsp;Agreed. But this formulation sounds a bit too generic. What kind of
    accommodations do you have in mind? As an example, for deaf people,
    you might be thinking of remote transcription services like "Remote
    CART" (Communication Access Real-time Translation) captioning,
    perhaps based on standards like XEP-0301 (Real-Time Text for XMPP --
    <a class="moz-txt-link-freetext" href="http://www.xmpp.org/extensions/xep-0301.html">http://www.xmpp.org/extensions/xep-0301.html</a>). In any case, I would
    make this part more explicit.<br><br>**Requirement 07-10**: All remote attendees at regular IETF meetings
   and interim meetings who make contributions MUST register with the
   IETF Secretariat before contributing using any of the RPS tools.
    This is out of scope for the RPS. I think the basic idea behind
    section 2.1 is that the IETF secretariat should in the future
    envisage different registration options (local attendee, remote
    contributing attendee, remote non-contributing attendee) and the RPS
    should have access to such information when logging users into the
    system, so to be capable of associating them with a specific role.
    In summary, from the RPS's point of view, the only requirement
    should be that it be capable of supporting different user roles,
    once again configured through policies. You actually mention
    something like this when you state, at the end of the section, that
    "registration might happen in the IETF's Datatracker".<br><br>
    Coming to section 2.3 on Audio, I have already stated on this ML
    (<a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html">http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html</a>)
    that I strongly believe the priorities you identify in the document
    are not in the right order. I cannot think of a 'future' RPS which
    is not capable of reliably supporting audio from remote attendees
    (both those who have to give presentations and those who just want
    to make sporadic comments).&nbsp; I know this brings in some technical
    obstacles, but I nonetheless insist on this point. <br>
    With respect to the specific requirements you identify:<br><br>**Requirement 07-20**: The RPS MUST enable relay of messages from IM
   to the mic to be able to happen as quickly as if the remote attendee
   was local.

    It is not clear to me what you mean by "as quickly as if the remote
    attendee was local".<br>
    From a technical standpoint, this should translate in something
    similar to what I was proposing in the already cited mail, i.e. a
    solution which automatically announces a request for attention
    coming, via the jabber room, from a remote: in a few words, if a
    remote writes a sentence in the chat and lets it be preceded by the
    [mic] prefix, the RPS should automatically play a predefined
    'attention sound' inside the room.<br><br>**Requirement 07-21**: The person relaying from IM to the mic must be
   available throughout the WG meeting.  To date, this has been done by
   WG volunteers in the room.  In the future, it could be done the same
   way, or maybe could be facilitated by hiring people to attend
   meetings for the specific purpose of being IM-to-mic scribes, 

    this part seems to be out of scope for the RPS<br>
   or maybe could be done with tools that allow copy-and-paste of text from
   IM to a speech synthesizer that reads it to the room.

    with respect to this part, you should obviously also look after
    moderation in this case (I copy-and-paste the sentence, but the
    sentence itself should be read to the room<br>
    at the right time, i.e. when the the user's turn to gain the floor
    arrives).<br><br>**Requirement 07-24**: A WG chair MUST be able to control the sound
   coming from any particular remote attendee.  This control MUST allow
   reduction in volume, all the way to complete muting, of the remote
   speaker.

    This requirement, together with others that I will discuss, might be
    put in a general technical sub-category associated with floor
    control. With respect to this, I also remark<br>
    that if we start talking about moderation and floor control, we have
    to be careful when identifying roles, meaning that we should avoid
    making a direct logical link between<br>
    the WG chair (who is physically chairing the session) and the
    moderator (who is actually 'chairing' one or multiple floors/media):
    the two roles might easily be played by distinct<br>
    persons (this is, again, a matter of policies).<br><br>**Requirement 07-26**: The audio system used by the RPS MUST be able
   to integrate with systems commonly used in the venues used for IETF
   meetings.  These venue systems typically include line-level audio
   outputs from mixers that combine all the mic inputs into a single
   stream.  Some venue systems also allow for headphone level inputs
   from PCs to be mixed into the audio stream.
    Right. With reference to this part, you might want to have a look at
    what we are asking for when it comes to support sessions with
    Meetecho:<br><br><a class="moz-txt-link-freetext" href="http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf">http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf</a><br><br> **Requirement 07-39**: The IETF Secretariat MUST be able to easily
   set up the individuals allowed to use the floor control system for a
   particular meeting and to change the settings at any time, including
   during the meeting.
    <br>
    Isn't this out of scope for the RPS (policy-related)?<br><br>**Requirement 07-40**: The chair SHOULD be able to monitor the sound
   levels of the audio being delivered to remote attendees to be sure
   that they can hear what is going on in the room.

    Beware that this calls for remote monitoring on the client side,
    which not as easy as one might expect. I would better state that the
    chair should be able to <br>
    'adjust' the sound of the audio of remotes, based on their feedback
    about the perceived quality.<br><br>**Requirement 07-43**: When video is allowed for remote attendees to
   give presentations (as described in <a href="http://tools.ietf.org/html/draft-ietf-genarea-rps-reqs-07#section-2.3.3">Section 2.3.3</a>), the audience in
   the room SHOULD be able to see the presenter speaking.

    Doesn't this simply translate in a requirement to have a secondary
    beamer in the room which is projecting the remote speaker's video
    (which would be out of scope for the RPS)?<br><br>
    The whole section 2.5 is in my view related to the third category of
    requirements I introduced above ("Requirements for the seamless
    integration of the future RPS system with the current IETF tools and
    meeting materials portal"). <br>
    I think that a requirement for the RPS here would just be that of
    being able to show (in the meeting virtual room) the slides that
    have been uploaded to the meeting materials page. This might, e.g.,
    be done through a conversion of ppt/pptx/pdf/odp/etc files to
    whatever the RPS uses internally (e.g. a sequence of images, a
    low-rate video, etc.).<br><br>**Requirement 07-53**: The slide stream MUST represent the slides as
   they are projected in the room, allowing the presenter to go back and
   forth, as well as to edit slides in real time.  This makes it clear
   to the remote attendees which set of slides, and which slide number,
   is being currently shown.

    Real-time editing of the slides is a tough requirement, indeed. If
    you think of how this is typically done, the most likely option here
    would be to have the speaker make his presentation by using some
    sort of application sharing tool (e.g., by sharing his powerpoint
    application running on his laptop). I think we should relax this
    requirement, by associating a MUST to just showing slides and
    browsing back and forth through the presentation. Slide annotations
    might then be done by using a whiteboard or some similar tool. What
    is your feeling about this?<br><br>**Requirement 07-60**: A much-lower priority requirement is the
   ability for group-editing of graphics.
    <br>
    As before, this is a tough one. What do you mean by group editing of
    graphics? Are you thinking of a sort of shared "Paint", a
    whiteboard, or what?<br><br> **Requirement 07-61**: The RPS MUST support storage and distribution
   of recordings of the audio, video, and slide presentations for all WG
   meetings.

    I would also specify that it is highly desirable to have
    "synchronized" recordings of the meeting media.<br><br> **Requirement 07-64**: Users MUST be able to easily find the archives
   of the recordings and instant messaging transcripts of a particular
   WG or BoF session at a particular meeting.

    This is out of scope for the RPS (policies).<br><br>**Requirement 07-66**: The RPS MUST support recording and storage of
   recordings of the audio, video, and slide presentations of interim
   meetings as well as regular IETF meetings.

    Once again, from the RPS perspective, there should be no difference
    at all between recordings of a regular meeting and recordings of an
    interim.<br><br> **Requirement 07-67**: Given that interim meetings are often run
   without the help of the IETF Secretariat, making these recordings
  MUST be easy for WG chairs.

    Why should the chairs bother about the recordings? I think the RPS
    should be capable of making recordings in an automated fashion. The
    chairs <br>
    should just don't care about the inner workings.<br><br> **Requirement 07-74**: The RPS MUST allow a session to be moved from
   one room to another during the session This is needed because the
   Secretariat sometimes need to swap the rooms for WGs when it becomes
   clear that one is too full and another room has excess space.

    Apart from the unavoidable association between the mixer in the room
    and the virtual room in the RPS, this should have no other impact on
    the RPS itself.<br><br> **Requirement 07-79**: Remote attendees MUST be able to easily find
   all the material they need to effectively participate, including
   links to audio, video, instant messaging, slides, and so on.  This
   material MUST be available well before the time of the meeting.  The
   page with the meeting material SHOULD allow the remote attendee to
   easily perform a time conversion to and from the local time at the
   IETF meeting.

    Out of scope for the RPS (policies).<br><br> **Requirement 07-84**: The RPS SHOULD have a central location where
   the specifics about how remote participation is supported for every
   WG interim meeting.  This will reduce the problems often seen where
   messages about how to participate in an interim meeting get buried in
   the WG mailing list.

    I don't understand this one, but looks like a policy-related issue.<br><br>
    Hope you'll find this feedback useful.<br><br>
    Cheers,<br><br>
    Simon<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
    -- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: <a class="moz-txt-link-abbreviated" href="mailto:spromano@...">spromano@...</a>
          <a class="moz-txt-link-freetext" href="http://www.comics.unina.it/simonpietro.romano">http://www.comics.unina.it/simonpietro.romano</a>

    &lt;&lt;Molti mi dicono che lo scoraggiamento &egrave; l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio&gt;&gt;. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

  </div>

Gmane