Minutes for MTGVENUE at IETF-96
minutes-96-mtgvenue-1

MTGVENUE session

Will talk about venue selection process document and policy document.
Other documents: venue decisions and participant metrics.

---------------------
Highlights and to-dos:

Problem of moving meetings will be addressed in the
  documents
Ask the mailing list about the disposition of Andrew and
  Alissa's draft
Metrics document: double-check with working group on punting
  on this one until we've made more progress on the other
  deliverables, remind them that just because it wouldn't be
  worked on here doesn't mean it wouldn't be worked on at all

---------------------

Selection process document (Fred Baker)
- discussed at IETF 95 and on the mailing list
- text incorporated, still a few more comments to add
- would like to close the draft out
- authors would like decisions document to be folded into this one; wg will
discuss - other issues?

Melinda: should the problem of moving meetings be discussed in the doc?
Jonne: issue is that if we have to pull out for health or safety reasons, what
criteria apply Ray: for BA, we considered whether it might have to be moved,
and looked at a number of places and established a backup location.  But
there's a pivot point, beyond which you can't do that, a number of days beyond
which you can't move it.  Would have to cancel or have a virtual meeting
instead.  We're looking at backup locations for other meetings as well. Jonne:
yes, but the question is whether this issue should be addressed in this
document.  Should there be a process and policies written down for it? Ray: it
would be good to cover when the decision points are made Yoav: Do we really
have a plan for actually having a virtual meeting?  Can't do it without a plan.
Jari: We do have a process for re-evaluating if we need to. Fred: We'd need to
prototype a virtual meeting.  Have a large-scale interim meeting to try it.
Alissa: A couple of items on the list have no resolution yet.  Should we
discuss those now?  What is the point of this draft?:  People complain about
issues such as "one roof"... but having a BCP that sets out policy can be a way
of resolving complaints.  Consensus on this draft could be very different from
the ongoing complaint cycle.  We need opinions that are not just from those who
complain. Klensin: We did more a meeting, though not at the last minute: AP ->
Vancouver.  But not only does that community need to have plans for moving as a
contingency, but a document like this needs to discuss the conditions and/or
mechanisms for making the determination that is necessary. Ray: We've not moved
a meeting after we had a contract.  We moved Atlanta from 2010 to 2012 to make
room for the Beijing meeting, but that was allowed by the contract. Crocker:
During normal planning there have been changes made with respect to venues, and
the staff know how to do that.  But really interesting, difficult, and worth
exploring: sudden, last-minute change (disaster, etc).  The sense I get of
having a virtual meeting is that we're not there yet.  We need to plan for
emergency procedures... but they also don't work if they never get used.  Worth
thinking about putting a substantial effort into planning and testing for such
contingency. Tobias: [agrees]  What's valuable for us is to understand the time
points the community needs.  What time points are good for you?  60 days?  Or
what? Nalini: We should have a backup plan. Mary Barnes: On the accessibility
point: ADA covers invisible disabilities as well as visible ones.  For example,
food with respect to dietary restrictions.  Has that factor been considered?
Fred: Not the same standard worldwide.  What we can say is that we would
*prefer* a venue that meets US standards.

Policy document (Suresh)
- 1-1-1-* policy hasn't really been well defined; this draft does that, and
aims to set out the goals for it. - - Distribute travel pain - - Distribute
time zone pain for remote participants - - Attract new participants? -
summarizes draft Open issues: 1. Should attracting new participants be a stated
goal? 2. Do we need more precise definitions of geo regions? 3. Do we need to
specify a mechanism to initiate the wildcard * proposals? 4. Should the
reevaluation be periodic or need-based? Jari: Some differences between how
we've been doing this and the draft.  On the *, who proposes that?  Also, the
draft generalizes the concept of the *. Fred: On question 1: this perennially
comes up.  My question: does going to a new place actually result in people
from that area staying in the IETF?  Does it actually attract new participants?
 I think it did not do so when we went to Adelaide.  Open question to Ray about
the BA meeting -- how many from South America are here in Berlin?  Let's not
automatically assume that this works.  As to question 2, more specific
definition could work against us.  Is Malta OK as Europe?  Turkey?  Morocco? 
Maybe close enough, maybe not. Crocker: On text "without extensively impacting
the regular meetings", well, as an * meeting replaces a regular meeting, it's
certainly an impact.  Would be surprised if we were to add a fourth meeting to
be an *. Suresh: Could do a virtual meeting between two regular meetings.
Crocker: For writing general policy, that's too particular.  [new topic]  Also,
language I like: We usually talk about "sharing the pain", but that's not
concrete enough, and I like your separation of travel and time zone.  We should
add some language to go further on that.  As we look at * situations and see
ones that violate those goals, we might think harder.  On the questions, #1
reduces to whether we should choose venues reactively or proactively.  History
has generally been reactive.  China was reaction to an emerging trend.  BA is
the only one that seems proactive.  We need to consider also the damage, as
well as the hoped-for benefit -- such as reduced participation.  We need to be
careful in thinking about this.  It's an appealing idea, but that doesn't mean
it's right. Nalini: Collecting metrics for this very reason.  The question has
a lot of nuance. Ray: In Yokohama > 500 from Asia.  In other geos, < 250. 
Other examples.  Where we go has an impact on participation from the region. 
In BA, 600 people registered as remote participants, including hundreds from
India.  Here in Berlin, we have 200 remote registrants, including many from
Latin America that we didn't have before. Alissa: Question 1, the draft that
Andrew and I wrote gives an emphatic "no".  Looking at the goals of the work
we're doing, the work is much more important than the geographic locations.  We
should think about ways to help people all over the world contribute, but that
doesn't necessary drive this policy.  For Q2, locations have different aspects,
including visas and such. Suresh: Region definition should not include that,
but decisions will. Alissa: If we're just talking distance, arbitrary region
boundaries don't make sense.  For example, is Hawaii a reasonable compromise
for distance?  What about how easy it is to enter? Crocker: Ray's comments
about local people... of course we get more local people, but we have to think
about actual contributor.  Locals may bring revenue, but we need to actually
get work done. Klensin: [very similar comment] Fred: One doesn't show up at
first IETF meeting and produce documents.  There's a process over time.  How
many people who were new in BA are here this time?  That's kind of the first
step. Jari: Q2, I think we don't need a precise definition.  Following up with
Alissa, yes, distances and visas are different tradeoffs.  This is a
multidimensional problem, and we're trying to establish high-level principles
here.  We need to know how much participation from a region we need before
considering it. Pete Resnick: On "process to become participant", we'd have to
measure.  But we can start measuring the inverse: see when new people started
in relation to past meetings, and see if there's a correlation.  Really comes
down to people on mailing lists, and what caused them to do that. Article 19:
Favouring the existing cohort.  Need different perspectives that are reflective
of the global Internet community. Christian: Agree with Pete on more complex
measuring, but I don't agree with his conclusion.  Not because of the meeting
itself, but the process *before* the meeting, encouraging people over time,
remote hubs, etc. Harald: BCP can say we need to measure, but actual measuring
needs more flexibility. Jonne: Should we have more policy guidance about things
such as the Singapore issue?  People should think about that. Fred: It would be
not helpful to try to have a list of such things, because it is by definition
incomplete.  We always have many tradeoffs and there's no perfect answer. 
Andrew/Alissa's document is trying to guide those tradeoffs, and that's useful.
Melinda: What could be included in the documents that might have helped with
the Singapore situation, and to help avoid these situations and deal with them
when they happen. Fred: There are open conflicts: some people would like us to
have a meeting in Africa, but most African countries have similar or worse
(much worse) LGBT issues than Singapore.  What's helpful is to have guidance in
how to structure and investigate. Jonne: We could have a very long checklist
and no possible venues.  But this is a more complex issue than just geo
consideration. Jari: Need to have geo policy.  Need to have venue selection
criteria -- Fred's doc, but need policy also.  Need Andrew/Alissa document. 
And we need venue selection process.  How these document needs are split is up
to the WG. Alissa: One of the concerns with respect to our draft is that it'd
be a shame if the community is happy but the IAOC has no better guidance for
the controversial issues.  But defining bright lines that will help... is very
controversial.  So can we write something down that really helps but doesn't
inflame everyone and can get consensus.  If we don't do something that helps
the IAOC, we will not have been successful.  I'd like to see us have a few
locations we rotate among. Tobias: Practically, it'd be easy to have only a few
locations, but that discriminates financially against those not in/near those
locations.  And also visa issues.  We need to make the effort to allow everyone
to come to meetings. Leslie: Strongly agree with Alissa's comments about
guidance for the IAOC.  IAOC never *intends* to surprise the community.  This
can't be a one-shot deal or it's not implementable.  Things will always come
up, and we need part of the process that can get more dynamic input from the
community. Nalini: Need to figure out why mistakes are made.  Lack of
transparency was probably one problem.  Think about why did the Singapore chaos
happen?  Maybe we're engineering focused and dis-count socio-political things? 
Maybe not a bad idea to pick just a few places, and maybe you can subsidize
people who don't live there and have a hard time. Ray: I'd like to get to the
point where we have a few places.  EU: Berlin, Paris, someplace else.  Repeat. 
NA: Vancouver, SF, someplace east.  AP, not enough experience.  Yokohama maybe.
 Seoul could be the second.  Need more experience.  Would save a lot of time,
effort, money, etc.

Decisions draft (Andrew and Alissa)
Four questions:
- Is this a useful effort?
- Are there objectives missing?
- Are there objectives here that should not be here?
- Are the objectives in the right order?
Crocker: Ordered list: Network access more important than safety/security. 
Right... problem is that we need more coarse ordering. Andrew: We've *been*
places where I've felt my physical security was in question. Crocker: The text
needs to be more nuanced. Jari: Unclear in the draft: the visa situation.  Some
of these things vary hugely, but they affect ability and willingness to travel
somewhere.  And yes, this is a very useful effort.  Not sure that general
network filtering is in the right order here. Andrew: On document structure,
the beginning is probably not clear enough, but some of it might be better
broken out into separate items.  More explicit distinctions. Alissa: Issues
Jari raised about network access are among the most important ones to get
clarity on.  The IAOC needs more guidance on network filtering and surveillance
to avoid perpetual hand-wringing. Leslie: Listing the objectives this way hides
important nuance.  Ordering objectives, OK.  Non-objectives, not really. 
Remember Vienna... we couldn't really do that now, so "under one roof" might be
a non-objective, but it's not black and white. Andrew: Important point, and
right to the heart of why this is separate.  Other draft is a long list of
things that need to be traded off.  So we're specifying why we're making the
decisions.  The problem with Vienna isn't that it's not one roof, but that it
didn't meet the interaction criteria. Leslie: Maybe an appendix of scenarios
where you step through the logic. Ray: IETF has set calendar through 2022;
contracting through 2019.  Implementation of this takes place in 2020 at
earliest. Andrew: I hope tentative conclusions take the ongoing process into
account, not wait until RFC. Harald: Call this "stuff that needs to be
considered", not "rules". Andrew: From my PoV, the three things we listed as
non-objectives really are things I do not want to be considered.  I think these
pervert our selection. Alissa: [agrees] Crocker: Prioritizing vs core set of
requirements... Drawing a line is difficult, but there are core levels of
safety that are not negotiable.  There's nuance.  There must be some level of
safety, but other can be traded off.  Document has to make that distinction in
order to be useful. Klensin: One of the problems with "not until four or five
years from now" is that it has often seemed to be an excuse for not doing
something the community wants or, more generally, "no change because it is too
far away to consider."  That doesn't make it less real, but we need to be a lot
more careful about it than we have been in the past.  It is also a reason why
it is important that the IAOC be more forthcoming about hotel/venue contracts
and what is being negotiated. Andrew: What do the chairs want us to do with
this document? Melinda: Take it to the mailing list.  What would *you* like?
Andrew: If it's useful, we'll continue working on it.  We're here to be useful.
Fred: It's useful.

Metrics (Nalini)
- Document tries to define "participation" in this context, and...
- ...propose objective and fair metrics
Participation:
- Fundamental participation
- Process participation
- Remote vs physical vs email
Pete Resnick: 1-1-1 says to get the participants to the event, but the
participation is contributing on the mailing lists.  We're carving the turkey
the wrong way here by saying remote/physical/email. Fred: We have physical
attendance figures.  We also look at where I-Ds come from.  We don't collect
such information about mailing list posting. Nalini: Remote participation is
important. Alissa: We don't have to be concerned with previous policy setting. 
We're thinking about this afresh, and it doesn't matter what the earlier
reasoning was.  We don't have to be constrained by past definitions, but just
consider what's best going forward. Crocker: The idea of starting with a clean
slate is intersting, but risky when there's established practice.  If current
practice has merits, ignoring it completely can be destructive.  Look for ways
to improve rather than ways to ignore.  WRT participation: observation vs
contribution.  Participation amounts to just showing up, but what's helpful is
contribution.  The hard part is for us to be clear about what constitutes
contribution that we can have metrics for, vs contribution that we can't
measure.  Could look at names in a "acknowledgments" section.  But ignore
physicality, and only count contribution. Harald: The purpose of the IETF is to
make the Internet work better.  I like the idea of measuring how contributions
do that, but we have to focus on that.  If you measure something, people will
adapt their behaviour to skew your measurements.  You need to consider security
of measuring. Melinda: Who thinks a measurement project would be valuable? 
(hum for, none against)