ietf
[Top] [All Lists]

Re: A couple of meta points -- IETF 100, Singapore, onwards

2016-05-23 16:13:42
Thank you Leslie. I agree with the strategy of pursuing two lines of 
discussion, one about IETF 100 and one about the principles used to guide 
meeting selection. I think it is clear just from the recent thread that the 
principles discussion will take some time, in particular because the principles 
are inter-related in different ways. I don’t think it makes sense to rush that 
discussion to resolution for the expediency of making a decision about IETF 
100. In my personal view I’d like to see some version of the inclusivity 
principle that currently exists in Fred’s draft adopted as a rule for the road 
going forward, and feel some shame that this was not done long ago (same goes 
for the accessibility principle) but I’ll take that opinion over to mtgvenue.

Now, about IETF 100.

After the plenary at IETF 95, the IAOC said that it was "gathering information 
about the situation — including the full cost of canceling existing contracts, 
so that the IETF community can have a fuller picture from which to provide 
guidance for our next steps.” But I don’t feel that our picture is much fuller 
than the picture we had during IETF 95. Thus far the community hasn’t heard 
anything to characterize the costs of moving IETF 100, nor the opportunities 
the IAOC investigated for covering those costs, nor the possibilities for other 
meeting options, nor the criteria that the IAOC used to evaluate those other 
options given the unique circumstances of potentially needing to relocate a 
meeting on short order (e.g., “relaxing" the 1:1:1* guideline for 2017, dealing 
with higher hotel room costs, moving to different dates, etc.).  We have heard 
some non-IAOC folks make claims about some of those things, but we haven’t 
received any specific insight from the IAOC a!
 bout those things that could form the basis from which the community can 
“provide guidance” on the IAOC’s next steps. This is information the IAOC is 
exclusively positioned to provide (unlike country-specific information from 
travel.state.gov).

I realize that there are some details directly implicated by contract 
negotiations that the IAOC may consider unwise to share on a public mailing 
list. But it would seem that there is a good amount of detail about each of the 
items above that can be shared with the community if the point is to get 
well-informed feedback.

I raise this in particular because Cisco happens to be the host for IETF 100. 
In chatting with folks around the company, it didn't seem to me that anyone had 
been contacted by the IAOC about the possibility of helping to offset costs 
associated with relocating the meeting, prior to you sending your mail last 
week. This causes me to wonder about exactly what the IAOC considered under the 
banner of "costs and possibilities of moving the meeting to a different 
location" in coming to its current decision.

I think it’s obvious that some folks have a clear-cut opinion about whether 
Singapore is or is not a suitable venue for IETF 100 even in the absence of 
this information. I would put myself in that camp — having thought about this a 
lot recently and considered my own participation and the potential impact on 
other participants, I can’t support the decision to have the meeting there. But 
I would still like to understand the implications if that decision is made, and 
for others this may well be key information they need to ground their input to 
the IAOC.

Thanks,
Alissa

On May 23, 2016, at 8:14 AM, Leslie Daigle 
<ldaigle(_at_)thinkingcat(_dot_)com> wrote:


(Not speaking for the IAOC, which does owe Ted a response, but offering some 
of my own perspective of the meta issues in this discussion).

Again, I see 2 burning issues here:

1/ what do we want to consider appropriate meeting sites going forward, and

2/ what to do with IETF 100/Singapore

We’re separating these two because the second has to get decided pretty much 
instantly, and in separating them we have to say that the outcome on “2/“ has 
to be a one-off, and might not be suitable under updated policies after we 
settle out “1/“.

Spelling it out a little bit:

What the IAOC does is make site selections based on (our understanding of) 
the community’s requirements.  To date, our understanding has been that we 
should find sites that allow the greatest proportion of our participants to 
attend the meeting and get the work done.   We expect that people make their 
own choices about attending or not attending a meeting, and recognize that is 
gated on personal choices and beliefs.

If the IETF community wants to shift the focus of requirements and make 
requirements include other things — such as suitability for family 
attendance,  selecting for absence of laws or other policies that make the 
experience more difficult or uncomfortable for some part of our community — 
that’s fine as long as its a consensus position.  And, the IAOC needs to have 
the resultant requirements spelled out[1].   I argue that discussion should 
take place on the aforementioned mtgvenue(_at_)ietf(_dot_)org mailing list, 
where the meeting venue selection requirements document is being discussed.

I don’t believe we can have that discussion quickly, with the attention to 
detail that it needs in order to ensure an outcome that fits everyone 
(especially including those who have been more comfortable suffering in 
silence than putting their challenges out for discussion).

And, we need to make a decision about IETF 100 quickly.

So, to be clear, whatever we decided to do with Singapore for IETF 100 will 
NOT be a statement about whether we ever meet in Singapore again, or never 
meet in Singapore again (depending on which way the decision goes).

Leslie.


[1] Not all requirements are necessarily feasibly implemented, and/or there 
are cost implications, but we can all have that discussion as part of the 
mtgvenue dialog.


-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises LLC
ldaigle(_at_)thinkingcat(_dot_)com
-------------------------------------------------------------------