ietf
[Top] [All Lists]

Re: Vacation locations (was: Re: [Recentattendees] Were You Planning a Vacation Around IETF91 Trip?)

2014-08-25 16:47:20

I did try to stay focused on that detail

Yes - understood. Thank you.

I don't either, as long as those don't become part of the
negotiations in ways that can increase costs (financial or
otherwise) to either individuals or the community in other
areas.

Right, and I do not believe they are impacting that in any way.

I am also concerned that the number of collateral
activities we are encouraging may increase the space and other
facilities requirements for IETF meetings, thereby restricting
the range of places we can meet.   That concern may be entirely
unjustified (I don't know enough about either our requirements
or hotel profiles these days) but would find it interesting if
the IAOC added at least a count of the number of auxiliary
meeting rooms (IAB, IESG, IAOC, Nomcom, ISOC, etc.) we need and
perhaps how they are being paid for to its reports.

The kind of touristy requirements that we talked about in this thread are, as 
far as I know, having zero impact. And certainly zero priority at least if you 
ask this IETF chair. 

(But the impact of various IETF groups from design teams to the boards meeting 
during the week is non-zero, and we also have some amount of interops, 
associated groups meeting, bits and bites, and so on. Some of that is 
absolutely necessary, and the rest is IMHO beneficial to the IETF even if in 
theory we could cut some of it. I think it would be a great idea for the IAOC 
to give a summary report of meeting space usage after each meeting. I suspect 
the key issue for us to be able to meet in venus though is the big meeting 
rooms, not the IESG- or interop-type rooms.)

I was looking for a simple clarification
that would put at least those impressions to rest.

Understood. Hope you are getting it here.

I also think it would be useful for the IAOC (or
the meetings committee) to be a little bit more open with the
community about what the "all requirements" are and how they are
generally prioritized.  It would even be helpful for the
community to understand which of those requirements are most
often causing locations to be excluded (or to exclude
themselves) because they cannot be met and, again following Dave
Crocker's lead, which sets of participant preferences and needs
are being optimized.  If nothing else, a little more clarity and
openness about those topics might head off at least a few
discussions like this one.

Good points. Let me talk to the IAOC/meetings committee/Ray. However, please do 
not expect an algorithmic RFC for site selection and prioritisation of all 
criteria. But maybe we can provide more thoughts about where we are and what 
kinds of things we are thinking in picking the meeting locations.

FWIW, from my perspective we usually struggle with pretty basic things, such as 
simultaneous fulfilment of 1-1-1 round-robin, functional site, venue costs 
(IETF and participant), travel-abiity, avoiding any special problems (visas, 
Internet access, etc), and finding a host. Costs have been a big issue in 
IAOC’s mind during 2014. Also, we’ve been very lucky for the generous 
sponsorships that we’ve been getting - thank you! But sponsorship tends to 
happen in the near term while meetings have to be contracted far in advance, 
and a fair part of IETF sponsorship money comes from sources that are 
location-dependent. Which means we are committing before knowing whether we’ll 
get sufficient sponsorship in some cases, and occasionally we have to say no to 
sponsorship proposals because there is no room for them it the calendar. And 
then we have a number of destination-specific problems, even in places with a 
lot of IETF participation.

All of these problems can be solved, and indeed, I think we’ve had fairly good 
success overall with our meetings with one or two exceptions. We also have 
long-term sponsorship/multi-year hosting deals, which reduce the risks 
mentioned above. And we are identifying and re-using places and hotel chains 
that we’ve been happy with before.

Jari

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

<Prev in Thread] Current Thread [Next in Thread>