Subject: [vmeet] Remote Participation Hubs

From: <[email-masked]>
Date: Thu, 15 Jun 2017 14:50:14 +0000 (UTC)

All,

We have submitted the first of three drafts discussing Remote Hubs.   Please provide comments on the VMEET list.

Three types of remote hubs are defined.  Each has its own characteristics.

  - Remote Participation Hubs
  - Remote Viewing Hubs
  - Enduring Local Meetups

The first document defines a Remote Participation Hub (RPH).  Other documents are coming to define the other types of hubs.  A common structure of sections will be
used as far as possible for all hub types.

URL:            https://www.ietf.org/internet-drafts/draft-elkins-ietf-remote-participation-hubs-00.txt
Status:        https://datatracker.ietf.org/doc/draft-elkins-ietf-remote-participation-hubs/
Htmlized:      https://tools.ietf.org/html/draft-elkins-ietf-remote-participation-hubs-00
Htmlized:      https://datatracker.ietf.org/doc/html/draft-elkins-ietf-remote-participation-hubs-00

Thanks,

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

---

From: John Leslie <[email-masked]>
Date: Thu, 15 Jun 2017 23:06:16 -0400

[email-masked] <[email-masked]> wrote:
> 
> We have submitted the first of three drafts discussing Remote Hubs.
> Please provide comments on the VMEET list.
> 
> The first document defines a Remote Participation Hub (RPH).
> Other documents are coming to define the other types of hubs.
> A common structure of sections will be used as far as possible for all
> hub types.
>  

   This reads as overly bureaucratic; and IMHO fails to describe a useful
concept.

   IETF weeks have always been intended to attract participants to work
they are not already familiar with.

   But even if we were to abandon that, it would still be necessary to
provide an opportunity for participants at a Remote Participation Hub
to also, at a minimum, follow other sessions not managed by the folks
in charge of the Remote Participation Hub.

   Without that ability, experienced IETF folks would have to decline
to be phsically present at a Remote Participation Hub.

   Thus, I regard managing a Remote Participation Hub (in accordance with
this document) as pointless.

   I do understand that there exist companies that would be willing to
provide a room for their employees to "attend" a single session; but
this IMHO is outside the ethos of the IETF, and should not be allowed
to increase the burden on the folks who arrange and manage IETF weeks.
(There is no reason companies can't already do that without creating
the bureaucratic burden.)

   A more useful definiton af "Remote Participation Hib" would be a
place where experienced IETF participants may meet together to
"participate" in an IETF week without the current burdens of travel,
visas, etc., and invite potential IETF participants to get a taste
of what an IETF week is like.

--
John Leslie <[email-masked]>

---

From: Vishnu Ram <[email-masked]>
Date: Fri, 16 Jun 2017 14:30:40 +0530

Hi Nalini,

thanks for this well-written draft.

I have some comments:

1) section 4.6.1 Bandwidth: it would be good to talk about wifi
connectivity here.
Many hosts have limitations on the wifi password and access to wifi.
In many cases, only employees are allowed to access the enterprise wifi.
Either a guest access has to be provided to the attendees or it should
be made clear in advance that no wifi will be provided.

2) In some cases, the timezone difference will make sure that the RPH
will happen at night.

in such cases, i would suggest necessary guidelines for off-work-hour
dos-and-donts be provided to the RPH attendees.

3) section 4.7: if the host is an enterprise,
it would be good to work out the security passes/paperwork for the TBH
attendees beforehand.

4) section 4.2: considering that the participation is remote, testing
and verification of connectivity,

quality of sound and responsiveness and delays should be understood at
least a day before.

5) if presentations are to be made by authors from RPH, then what are
the guidelines?

thanks

Vishnu.

2017-06-15 20:20 GMT+05:30 <[email-masked]>:

> The first document defines a Remote Participation Hub (RPH).  Other
> documents are coming to define the other types of hubs.  A common structure
> of sections will be

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 16 Jun 2017 05:51:19 -0400

+1

Ray
> On Jun 15, 2017, at 11:06 PM, John Leslie <[email-masked]> wrote:
> 
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html.
> https://www.ietf.org/mailman/listinfo/vmeet

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 16 Jun 2017 13:23:41 +0000 (UTC)

John,
Thank you for your comments.   Please see my responses inline.

> they are not already familiar with.
I think that you will get an argument on that.   For example, there are people who have told me that they believe the core reason for an IETF week is to allow work to progress on drafts currently underway in a WG.   Others who believe thatthe core function of an IETF meeting is the hallway track.   Suffice it to saythat there are multiple motivations for attending an IETF meeting.
Please note there are other drafts coming.   The "Remote Viewing Hub"may be more what you are thinking of as attracting participants to workthat they are not familiar with or performing outreach functions.
The reason for all the "bureaucratic" rules is that I have had a number ofpeople comment to me about what will happen if we really have veryactive members in multiple remote hubs.   For example,  what will happen if there is a problem in queuing?   What will happen if someone is preventedfrom coming to the microphone?  In a single face-to-face IETF meeting,  thisis likely to be noticed.   Will there be a record of what decisions were madeand how?   Like it or not, there are many rules that we abide by incurrent face-to-face IETF meetings.   
What happens if the "main" WG meeting is run at a remote location?
What happens if we have 100 different remote locations where "real" activity was happening?   This draft on Remote Participation Hubs is anattempt to play out just that scenario.   BTW, I have heard it suggested bysome people - as in "Why doesn't everyone just come in remotely?"

> But even if we were to abandon that, it would still be necessary to> provide an opportunity for participants at a Remote Participation Hub> to also, at a minimum, follow other sessions not managed by the folks
They are welcome to do that the way they do that today.   Or bysetting up a Remote Viewing Hub.

> to be phsically present at a Remote Participation Hub.
Certainly, this is an option for them.

> this document) as pointless.
See above.

> the bureaucratic burden.)

See above.  Also, I am not sure where you see that a RPH is a single session.  It is certainly not intentional.   Might you point me to the statement sothat I can correct it?  An RPH makes its own decisions about what sessionsit wishes to do.  Some may do all; others only one.   

> A more useful definiton af "Remote Participation Hib" would be a> place where experienced IETF participants may meet together to
I believe that this conflates two functions that I have tried very hardto separate.   Participation implies much more than merely viewing.
I believe that remote participation / viewing is the future.  Having said that,   we need to think very carefully about what can go wrong.In my company, we do some brainstorming before making strategic decisions.  We ask ourselves, "Three years have gone by.   Everythinghas gone wrong.   What happened?"   This way, we have a chance to think out and hopefully prevent problems before they arise.
"Participation" must be separated from "Viewing".   They implytwo very different levels of engagement.
Thanks,Nalini

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Jun 2017 14:09:55 -0400

--On Thursday, June 15, 2017 14:50 +0000
[email-masked] wrote:

> All,
> 
> We have submitted the first of three drafts discussing Remote
> Hubs.   Please provide comments on the VMEET list.
> 
> A common structure of sections will be used as far as possible
> for all hub types.
>...

Nalini,

While I admire your energy and desire to more forward on all
fronts at once, I think the effort to get better and more
extensive remote participation would be best pursued by your
concentrating on Remote Viewing Hubs (and local discussions,
etc., as needed) and Local Meetings (no matter how enduring or
persistent) and letting Remote Participation Hubs go for a
while, perhaps returning to them after experience accumulates
and our knowledge and tools improve.

I have several reasons for that conclusion, some of which
overlap John Leslie's comments (which I will try to avoid
duplicating).   The note below hits just a few high points of
special concern to me before moving to the conclusion implied by
the previous paragraph.

>From one perspective, my problems start with an interesting
assertion in the Introduction to the I-D: 

	"A Remote Participation Hub is functionally equivalent
	to an IETF face-to-face meeting."

"Functionally equivalent" implies the ability to attend informal
sessions like the Newcomper's Meet and Greet and to have
spontaneous discussions in the halls, over lunch, and at events
like Bits-and-Bytes with subsets of the community that are less
homogeneous than Remote Hubs will tend to be; to get an
introduction (if needed) and have informal conversations
(restaurants, halls, informal meeting spaces, coffee shops,
bars) with WG Chairs, ADs, document authors or editors, or
others; to grab an author at the end of a WG session (or have
the author grab you) to continue a discussion; and so on.  Even
though some of the text later in the document can be seen as
qualifying that very broad equivalence statement, at least at
the current state of the technology and our procedures claiming
a remote hub is "functionally equivalent" to our unified f2f
meetings (or even could be) falls into the "you must be kidding"
category.

Moreover, while we've done much better in some WGs and at some
meetings than others, we still haven't got good and predictable
queue management for questions and comments by individual remote
participants.  Meetecho has decent (and improving) facilities
for that, but we have a long way to go to sort out the human
factors of balancing multiple in-room queues, remote interactive
queues, jabber input, the effects of various kinds of delays
between a comment and a question about it, and so on in a way
that is fair to everyone.  

If we have to combine the present situation and its challenges
with in-Hub-room queues, we have, AFAICT, two options ( think
the Meetecho team has reached much the same conclusion).  We can
put everyone in front of their own laptops, which forces the use
of headsets and complicates the bandwidth and other facility
issues (and makes some of your Section 4.6.3 inapplicable), or
we can set up in-room queues and a local queue manager or
moderator (perhaps the coordinator, perhaps not, but, if there
are parallel WGs being covered by the remote hub, we need at
least one each).   The latter raises more questions: how does a
WG Chair prioritize the third person in line in Hub#1 versus the
second person in line in Hub #2, versus in-room participants and
standalone remote participants?  Is the in-room queue manager
accountable to the WG Chair(s) or responsible ADs and how?   

If there is disruption in the remote hub, even someone becoming
aggressive in the microphone line or trying to control it, is a
remote hub coordinator or other leader authorized to control
that (or harassment, which the draft mentions) in the name of
the IETF?    Are their representatives of the ombudsteam present
and, if not, how is RFC 7776 interpreted and by whom?  What is
the accountability model there?  Are remote hub coordinators and
any necessary additional moderators covered by the same
insurance that, I believe, extends to WG Chairs even if the IESG
has no role in appointing them?

Is it reasonable and appropriate to put all of those decisions
under the control of whomever is participating in the remote
hob, or a sponsoring company, as your draft seems to suggest?
Does that provide adequate context and protection of the IETF
consensus process?

If a remote hub is open only to employee of the hosting
organization, do we continue to pretend that everyone
participating at the hub is participating as an individual?

And so on...

While I agree with John Leslie that the document is probably
overspecified in at least some places, none of the issues and
questions above are really addressed and there are probably many
more omissions.  Some imply a requirement for significant
training of WG Chairs and RPH coordinators (and perhaps
procedures (above and beyond "you don't get to do that again")
for how non-conforming behavior should be handled; others
involve at least a review and probably changes in important IETF
procedures.    While I believe we can sort them out, I note,
first, that we still don't have the much more simple case of
individual remote participants working smoothly and that remote
participation hubs raise a collection of new issues, and that
bandwidth spent on these kinds of issues (at least for the IETF
participant majority who don't have too much time on their
hands) intrudes on getting technical work done and/or on other
procedural (especially remote participation) refinements.

Is the community really ready to review (and possibly reopen or
amend) RFCs 2026, 2418, 7282, 7776, and perhaps other documents
to identify situations in which people meeting as a group
without the usual accountability structures are in place could
turn into issues?

If for no reason than to reduce the risk of disrupting work to
improve existing forms of remote participation, I suggest it is
in the community's best interests to adopt something of a "one
step at a time" attitude and put this aside 

Again, I'm strongly committed to remote participation.
Personally, I seem to be participating remotely more often than
I attend f2f meetings these days, which definitely motivates me.
But Remote Participation Hubs that are driven more by enthusiasm
than by careful understanding of issues and community consensus
about how to handle them just do not feel like a useful way
forward at this particular time.

 best,
    john

---

From: Nalini J Elkins <[email-masked]>
Date: Wed, 21 Jun 2017 16:47:19 +0000 (UTC)

John,

Thanks for your comments.  Let me just say that we need to carefully consider and think out remote participation as a community.   Surprisingly enough, I actually agree with many of your points.   I did this draft because this is a conversation that we need to have.
Today, I believe that we are ready for "Remote Viewing Hubs" (which is a draft that I will try to get posted by next week!)
IMO, ignoring the issues that come with "real" participation, many of whom you point out, we will do so at our peril.   We need to be thinking 3- 4 years out.  And, planning for unforeseen disasters.  Have we so quickly forgotten the "travel ban" debacle?   Having said that, I do not object at all to putting this work aside and concentrating on Remote Viewing Hubs.  
But, on the back burner should not mean forgotten.
Is it so out of the question that in 2020, some region (say, India) may have 300 people who wish to participate in IETF WGs but cannot all do so in person.   Why would we not have remote participation hubs in Bangalore, Kolkota, Mumbai?    We need to think and plan for that.
Nalini

Nalini,

And so on...

best,
    john