Meeting Venue (MTGVENUE) Working Group meeting
IETF 98 - Chicago
0900 - 1130 Wednesday, March 29, 2017. Room: Zurich B
Chairs: Charles Eckel eckelcu@cisco.com, Pete Resnick presnick@qti.qualcomm.com
Notes thanks to Barry Leiba barryleiba@computer.org, combined with comments captured during meeting via issue list in github, https://github.com/elear/mtgvenue/issues

Start at 9:05

Introductory remarks from chairs
Meeting Venue Selection Process draft
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

Issue #1: What is "mandatory"? (Pete)

• Are there things that are "drop-dead show-stopper criteria"?
• Are there things where there's a line not to cross, but there is otherwise discretion?
• And then there are things that are fully discretionary.
• Fred: Yes, but what is the purpose and intended use of the document?
• Fred originally intended it to be something to use four years ahead, before the IAOC is deciding.
• Who will actually be making use of this doc?
• Chair considers the distinction not clear in the charter.
• Fred: Can't figure out what's mandatory until you know that.
• Ted: If the filter is the way we want it, it can be put anywhere in the process.
• Discussion of contract vs planning vs early considerations.
• What about things that change late in the process?
• Need to be explicit in the document about where in the process the application of some things might change.
• Tobias: Number of mandatory elements should be kept to an absolute minimum.
• More value in guidance than in making things mandatory.

Next steps: Editor will provide some introductory paragraphs to clarify how the criteria (mandatory or otherwise) apply at different times, and indicate that this document will provide community guidance for the IAOC. Might also add notes to each criteria about how they will be applied.

Issue #2: (Need a decision tree, Was: Too many categories)

• Eliot thinks he can handle this easily, and proposes rough outline text
• Nervousness about "writing code" rather than specifying requirements
• But we want to be clear about filtering and how the filters are used

Next steps: Post to list for guidance to whether to leave organization as is or organize with most important first, etc.

Issue #3: Too much mandatory

• By default, things should not be mandatory, and only mandatory with a really strong case
• If too much stuff is mandatory, we won't have a place for a meeting at all -- already hard
• Revisit the mandatories, with an eye toward reducing
• Alternative (Tobias): change all to "important", and then revisit
• Concern (Ted): that will set the WG process back considerably
• First have to be crystal clear about what "mandatory" means
• Proposed: A mandatory requirement is one such that if, at whatever point in the process we are, that requirement isn't met, we stop considering the venue at that point.
• Brian adds: "if, in the judgment of the IAOC".
• Pete would like to defer that until Eliot's recategorization process has been done
• How does mandatory change after the contract is signed?
• Proposal to include text that says the IAOC uses discretion, and may consult the community.
• Proposal: Things we can't put solid constraints on (such as safety) can't be "mandatory".

Next steps: Start by defining clearly what "Mandatory" means. Revisit list of mandatories, categorizing as important by default, and argue individually for any that are to be mandatory. Constrain mandatory requirements as much as possible. Eliot to make initial recategorization.

Issue #4: Process innovation

• No way to run consensus calls on venue selection.
• Need to make a different version of determining "acceptable" other than consensus.
• Proposal: remove text reading "IETF Consensus, with respect to this meeting Venue selection process" (etc)

Next steps: Consensus in room to remove text.

Issue #5: Clarity on definitions re: hotel rooms

• Hotel rooms might or might not be part of the facility? Don't understand.
• Eliot and Andrew will work offline to clarify the definitions.

Next Steps: Eliot to work with Andrew offline on definitions and bring proposal back to the list

---

Switch to Suresh: meeting-policy document
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-meeting-policy/
Overview of changes since last version
Overview of open issues

Issue #1: Why do we meet in new places? Is one reason to attract new participants?

• decision: no

Next steps: Remove text

Issue #2: How do we define regions?

• Really looking at travel difficulty/cost
• Therefore, be deliberately vague or say explicitly that it's a proxy for transportation issues

Next steps: Ted and Bob will work with Suresh on proposed text

Issue #3: How do we define success criteria for exploratory meetings?

• Alissa: We don't define success criteria for meetings. Why do we need to define it for this?
• Bob: We do this so seldom; let's not spend a lot of time on this
• Klensin: If we have success criteria, they need to be stated by the proponents, and the discussion will wind up wasting a lot of time

Next steps: Remove text

---

Back to Eliot

Issue #6: Terminology is hard to follow

• Andrew and Eliot will work this out; Andrew will make an initial proposal

Next steps: Eliot and Andrew to work offline on evaluation of definitions and return to list with proposal

Issue #7: Clarity of responsibility

• Eliot will propose some text for the Introduction section to specify that the IAOC has the responsibility, and they are the ones who are appealed.

Next steps: Add this as introduction in section 1, taking Brian's proposal into account as well. Pete will try to find Brian's suggested text in the archive and get back to Eliot.

Issue #8: What if target list of cities are not known? (Sec 5.1)

• Eliot understands the issue and will propose a fix.

Next steps: Eliot to clarify, adding step to identify cities

Issue #9: Concurrent objection?

• Eliot will propose an editorial change.

Next steps: Indicate that community responses (step b) can come in continuously

Issue #10: What happens if there is a change of policies in the interim?

• Issue already covered in earlier discussion.

Next steps: Invoked if mandatory criterion is violated after contract has been signed

Issue #11: Text seems strange (Sec 2.2)

• "Maximal attendance" item needs editorial work.
• Key point is that we meet to get our work done, which might include welcoming new people, but that just making a big meeting is the non-objective.

Next step: Eliot to reword to less offensive and inclusive.

Issue #12: Sponsor required as mandatory?

• Will fall out of revisiting the mandatory items.
• Might actually split the issue; how hosts/sponsors are solicited might change
• Might remove the text altogether
• Proposal: remove this text
• Andrew notes that funding/cash-positive points might need further clarification

Next steps: Proposal to remove. Eliot to verify on list. Funding/sponsorship issue may need to be added as a separate issue. Discuss this on list.

Issue #13: Handling repeats

Next steps: Clarify "Venue" vs "Facility"

Issue #14: Odd that accessibility requirements differ

• Wheelchair (mandatory) vs disabilities (important)
• Wheelchair access is specific and easy to assess
• Other accessibility issues are complicated, harder to assess, and less available
• Therefore the concrete and accessible one is mandatory
• Will fall out of revisiting mandatory, and the two might be combined
• Result: Leave the current requirements as they are

Next steps: Discussion was inconclusive. Leave text as is and lieu of a concrete proposal for how to change.

Issue: #15 Distinction between these two requirements?

• Difference is Facility vs IETF Hotels
• Eliot will discuss with NOC folks

Next steps: Eliot to check if network specifications draft covers and reference it.

End at 11:30