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
--On Thursday, June 15, 2017 14:50 +0000
nalini(_dot_)elkins(_at_)insidethestack(_dot_)com wrote:
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.
...
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