Subject: [Mtgvenue] issue #3: Too many mandatory

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Apr 2017 15:40:48 +0200

As mentioned by the chair, I am downgrading requirements based on
working group discussion, mostly from Mandatory to Important.  As a
reminder, the words are intended to be used consistent with their plain
meaning.  That is- just because something is now Important specifically
does not mean that it is UNimportant. 

From Mandatory to Important:

  * Travel to venue is acceptable based on cost...
  * The venue is assessed as favorable for obtaining...
  * Travel barriers and visa requirements...
  * Economic, safety, health...
  * Facility support technology and services...
  * Facility directly provides or permits...
  * The IETF Hotel(s) directly provide, or else permit...
  * The guest rooms at the IETF Hotel(s) are sufficient...
  * The Venue environs, which includes both onsite, as...
  * A range of attendee's health-related and religion...
  * Overflow Hotels can be placed under contract...
  * The Venue environs include budget hotels within...
  * There are sufficient places (e.g., a mix of hallways, bars, meeting
    rooms, and restaurants) for people to hold ad hoc conversations and
    group discussions.
    (This last one is split out from a Mandatory)

Several requirements are removed based on the discussion.  They include
the following:

  * Available travel issue assessments -- such as...
    This requirement is to be moved into Section 5.
  * The economics of the Venue allow the meeting to be...

This leaves but three mandatory requirements as follows:

  * Consultation with the IETF Community has not produced concerns
    sufficient to disqualify the Venue.
    This requirement should probably turn into normative text in Section 5.
  * The Facility is assessed to be able to provide sufficient space in
    an appropriate layout to accommodate the expected number of people
    to attend that meeting. (reworded to be clear as to what is mandatory)
  * The Facility permits easy wheelchair access.
    Based on discussion in the room.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 02:17:42 +1200

On 06/04/2017 01:40, Eliot Lear wrote:
> working group discussion, mostly from Mandatory to Important. 

>   * The Venue environs include budget hotels within...

Individually, it seems fine to make these "Important", but
somehow it seems mandatory that there are *in total* enough
hotel rooms close enough to the Facility.

    Brian

---

From: Lou Berger <[email-masked]>
Date: Wed, 5 Apr 2017 11:56:07 -0400

Eliot/All,

On 4/5/2017 9:40 AM, Eliot Lear wrote:
> The economics of the Venue allow the meeting to be...
Is this going to be moved to a "desired" category? If so, the next
comment doesn't apply.

If not, was the agreement in the room really that it is okay for the
IAOC to select a location that is known well in advance to result in a
net loss?

Lou

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Apr 2017 18:02:01 +0200

This one gets removed based on comments in the room.

---

From: Lou Berger <[email-masked]>
Date: Wed, 5 Apr 2017 12:44:13 -0400

Eliot,

I don't mind being in the minority / the rough, but I think it
reasonable for us to follow rfc2418 in this discussion. 

Lou

On 4/5/2017 12:02 PM, Eliot Lear wrote:
> _______________________________________________
> Mtgvenue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mtgvenue

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 10:42:02 -0700

> does not mean that it is UNimportant.

While it's understandable to wish for a shorter list, the realities of 
what this community keeps insisting on is what produced the current set.

For each item that folk propose to drop, we should carefully discuss the 
history that produced it and the likely community reaction if the 
requirement is not met, going forward.

>  From Mandatory to Important:

So this means that any of these items can be traded-off against some 
other item.  That means that for each one, it can be acceptable not to 
satisfy the 'requirement'.

Note that there is always the ability to seek exceptions to any 
requirement.  What dropping this item does is to move it from being an 
exception requiring community review to something the IAOC can decide 
without community review.

Consider...

>   * Travel to venue is acceptable based on cost...

So, it's tolerable to have the travel costs, time and/or effort be 
prohibitively high and/or difficult?

>   * The venue is assessed as favorable for obtaining...

The challenge in downgrading this has already been noted.

>   * Travel barriers and visa requirements...

So, it's tolerable to have travel barriers and visa requirements be 
UNacceptable?

>   * Economic, safety, health...

So, going to dangerous, horribly expensive environments, rife with 
outbreaks of pandemics is tolerable?

>   * Facility support technology and services...

How, exactly, are we doing to have a successful meeting if this is not a 
mandatory requirement?

>   * Facility directly provides or permits...

Same question.

>   * The IETF Hotel(s) directly provide, or else permit...

Same question.

>   * The guest rooms at the IETF Hotel(s) are sufficient...

Same question.

>   * The Venue environs, which includes both onsite, as...

Sam question.

>   * A range of attendee's health-related and religion...

So we are back to deciding that it's acceptable to have folk with 
special dietary requirements have to bring a week's worth of food with 
them to the meeting (or to have to travel long distances from the venue, 
in order to eat)?

>   * Overflow Hotels can be placed under contract...

It will be tolerable to have no overflow hotels under contract or to 
have them be a long way away from the meeting venue?

>   * The Venue environs include budget hotels within...

The goal of inclusivity will not be significantly damaged if there are 
not budget hotels or they are distant from the venue (meaning long and 
maybe expensive transit both ways)?

>     (This last one is split out from a Mandatory)

Given how often and vigorously complains when this is not satisfied, 
what will make it tolerable, going forward?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Apr 2017 19:51:08 +0200

Dave,

I think this goes to the heart of what "mandatory" means.  Editorially,
the sense I got of the room (or at least the implication) that matches
the directive to downgrade was that "mandatory" means "it's impossible
to have a successful; meeting unless the criteria is met."  Thus the
agreement on the need to argue the reverse of what you listed: what is
the justification for this requirement being mandatory?

Eliot

On 4/5/17 7:42 PM, Dave Crocker wrote:
>> reminder, the words are intended to be used consistent with their
>> plain meaning.  That is- just because something is now Important
>> specifically does not mean that it is UNimportant.
>
> For each item that folk propose to drop, we should carefully discuss
> the history that produced it and the likely community reaction if the
> How, exactly, are we doing to have a successful meeting if this is not
> a mandatory requirement?
>
>
> them to the meeting (or to have to travel long distances from the
> venue, in order to eat)?
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Apr 2017 20:18:18 +0100

Dave, Eliot,

Seems to me like you're using different semantics for the same
label.

A: Eliot: ""mandatory" means "it's impossible to have a successful;
meeting unless the criterion is met."

B: Dave: "What dropping this item does is to move it from being an
exception requiring community review to something the IAOC can decide
without community review. " which I think is equivalent to saying
that "mandatory" means "MUST unless community informed and ok with
not meeting the criterion."

I question the utility of (A). (B) might be good actually but
in that case a better label could be defined as meaning that.

Cheers,
S.

PS: Apologies if this was discussed on the list before or in the
meeting in Chicago.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 12:28:16 -0700

> not meeting the criterion."

Here's what Important authorizes:

       It can be traded against other Important items

My text that you quote derives from this authorizing statement.  The 
IAOC is authorized to do tradeoffs, which means it is authorized to 
choose not to satisfy one or another of these requirements.  Hence the 
very specific questions I've annotated, for each of the items proposed 
for a change in status.

As for seeking exceptions, I merely noted a reality that has been used 
more than once:  When there is a desire to hold a meeting that does not 
conform to the considerable list of community expectations -- demands, 
actually -- the community has been asked to provide comment and the IAOC 
has decided whether to make an exception.

The problem with taking 'mandatory' to be a requirement for mathematical 
perfection that does not permit exception is that, unfortunately, humans 
can sometimes tolerate exceptions where mathematical formula don't.

d/

---

From: Pete Resnick <[email-masked]>
Date: Wed, 5 Apr 2017 14:31:14 -0500

> reasonable for us to follow rfc2418 in this discussion.

I would take Eliot's sentence to mean, "Based on what was said in the 
f2f room in Chicago, this is to be removed. Speak up if you disagree." 
In particular, I would not interpret it to mean, "This is absolutely the 
consensus of the WG, therefore it will be removed and we are done with 
this topic." So I think we are following regular 2418 order here.

Still looking in the Meetecho recording for the section that speaks to 
your substantive point. (Gee, transcription service would be nice.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Apr 2017 20:40:45 +0100

> can sometimes tolerate exceptions where mathematical formula don't.

Nah, the difference between A and B is neither a mathematical
nicety nor a subtle human frailty - they're just different concepts
that ought be labelled differently. I reckon that A is not very
useful here but that B could well be quite a useful distinction
for this document. I'd encourage the editor to ponder whether
re-casting the requirements in terms of (some label for) B might
make the whole thing more clear. (And even maybe avoid a future
kerfuffle or two:-)

Cheers,
S.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Apr 2017 13:12:14 -0700

> not meeting the criterion."
I question the utility of (A).

I think "mandatory" could be useful, were it actually used the way Eliot
describes it.  The community could decide, for example, that we cannot have
a successful meeting where access to the Internet is not available (e.g.
parts of Cameroon at the moment and 55 other places during the course of
last yea
<https://www.internetsociety.org/sites/default/files/Rights%20Con%202017%20Press%20Release%20March28.pdf>r).
We can define that pretty crisply( e.g. "At least N of the K root servers")
for the purposes of the requirement.

And the marching orders for mandatory can be crisp too:  if this isn't met,
move or cancel the meeting.  If a natural disaster has eliminated the local
air transit hub(s):  move or cancel the meeting.  If an armed conflict has
erupted:  move or cancel the meeting.

It may seem silly to state those and put in the marching orders, but I
think it actually helps distinguish between those and the category below
which I interpret as "confirm exception is okay".  So if the local currency
skyrockets and the costs go up 40% over night (hello, CHF), we might have
marching orders to confirm the exception to our usual cost basis with the
community.

I personally hope that the categories end up somewhere along the lines:

Mandatory:  If not met, don't schedule the meeting here and move or cancel
the meeting if the requirement ceases to be met.

Exception-required:  Confirm that these are met during scheduling or get
community confirmation of the exception.

Important:  Things we care about but which can be traded off if the balance
of requirements is met without confirmation by the full community.

Desired:  Things we like, but which can be dropped without having an impact
on the meeting's effectiveness.

No hats,

Ted

(B) might be good actually but

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Apr 2017 16:18:13 -0400

Dear colleagues,

> on the meeting's effectiveness.

I quite like this set of requirements.  I do think there is utility in
maintaining a category of Mandatory that means exactly what the drafts
have said: if it can't be satisfied, then no meeting there.

In addition, I agree strongly with Ted's suggestion about crisp
"marching orders" for Madatory.  I think of the canonical case for
Mandatory is "enough meeting rooms".  If there aren't enough, we're
not going to have the meeting there, period.

This is why I don't like things like "Mandatory" for stuff like
"travel costs are acceptable".  I don't know how to operationalize
"acceptable" such that it is meaningful.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 13:24:46 -0700

On 4/5/2017 1:12 PM, Ted Hardie wrote:
> move or cancel the meeting.

BTW, folk seem to have mostly missed that the title of the draft refers 
to 'selection', which is a particular step in the overall process. And 
the wg charter concerns "specification of the venue selection process."

All sorts of things happen after a venue is 'selected'.  These things 
are quite distinct form 'selection'.

Contracting is one of those steps.  Another is monitoring and 
re-evaluating if conditions change.  Those are, of course, essential.

They are also outside the formal scope of this effort, though everyone 
seems to prefer to conflate them, which is having the predictable effect 
of making discussion and wording considerably more complicated.

d/

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Apr 2017 13:50:12 -0700

Howdy,

On Wed, Apr 5, 2017 at 1:24 PM, Dave Crocker <[email-masked]> wrote:

> BTW, folk seem to have mostly missed that the title of the draft refers to
> 'selection', which is a particular step in the overall process. And the wg
> charter concerns "specification of the venue selection process."
>
>
In each of the categories I put forwarding, I used "scheduling", but I am
fine with replacing it with "selecting".  I've put language for that below,
shifting all of the things post-"selecting" into new sentences.  If those
sentences/instructions don't go in this draft, that's fine by me, provided
they are clear in the directions somewhere.

> the meeting if the requirement ceases to be met.
Mandatory:  Do not select this site for a meeting.  Move or cancel the
meeting if the requirement ceases to be met.

> community confirmation of the exception.
Exception-required: Confirm that these are met while considering a site for
selection or get community confirmation of the exception.  If they cease to
be met and will not be met at the time scheduled for the meeting, confirm
the exception with the community.

> of requirements is met without confirmation by the full community.
Important:  Things we care about when selecting site but which can be
traded off if the balance of requirements is met without confirmation by
the full community.  If these cease to be met after selection, these is no
need for community confirmation unless the balance of requirements is no
longer met.

> on the meeting's effectiveness.

Desired:  Things we like in sites, but which do not have an impact on a
meetings effectiveness and thus can be considered in site selection without
being true requirements.

> All sorts of things happen after a venue is 'selected'.  These things are
> quite distinct form 'selection'.
>
The draft as currently constructed covers those as venue selection steps,
at least as I read Section 5.  If each of those steps needs a new document,
we may be here a while.

Ted

> seems to prefer to conflate them, which is having the predictable effect of
> making discussion and wording considerably more complicated.
>
>
> d/
>
> --
> Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Apr 2017 22:51:09 +0200

Dave's right, and this is where Alissa chimed in during the meeting.  As
a first priority she would like us to focus on before the contract is
signed.

On 4/5/17 10:24 PM, Dave Crocker wrote:
> BTW, folk seem to have mostly missed that the title of the draft
> refers to 'selection', which is a particular step in the overall
> process. And the wg charter concerns "specification of the venue
> selection process."
>
> seems to prefer to conflate them, which is having the predictable
> effect of making discussion and wording considerably more complicated.
>
> d/
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 14:02:50 -0700

> Exception-required: Confirm that these are met while considering a site 
> for selection or get community confirmation of the exception.  If they 
> cease to be met and will not be met at the time scheduled for the 
> meeting, confirm the exception with the community.
> 
> the full community.  If these cease to be met after selection, these is 
> no need for community confirmation unless the balance of requirements is 
> no longer met.
> 
> meetings effectiveness and thus can be considered in site selection 
> without being true requirements.
> 
>     All sorts of things happen after a venue is 'selected'.  These
>     things are quite distinct form 'selection'.
> 
> The draft as currently constructed covers those as venue selection 
> steps, at least as I read Section 5.  If each of those steps needs a new 
> document, we may be here a while.

"move or cancel" is language that only has meaning /after/ selection. 
It is therefore formally out of scope.

And while I'm at it...

The effort to move to a yet-more complicated ranking system -- adding 
Exception into the mix -- is mostly continuing to ignore the human 
factors points I keep raising:  Both in creating such a ranking list and 
in applying them, free-form human performance mostly sucks.

On the creation side, people are inconsistent in their assessment, from 
one hour to the next, never mind one day to the next.  On the 
application side -- absent quite a lot of on-going training and quite a 
lot of diligent application -- people are quite horrible at 
decision-making that properly juggles such a range of nuanced requirements.

So as folk comfortably move towards these changes, please do explain how 
they will be used in practice and what the basis is for believing that 
it will be practical for the Meetings Committee and for the staff.

d/

---

From: Warren Kumari <[email-masked]>
Date: Wed, 5 Apr 2017 17:18:15 -0400

> have said: if it can't be satisfied, then no meeting there.

... and this concern me. We select people to serve (presumably)
because we think that they have a brain, and are not intentionally out
to make the meetings fail.

I think that us creating strong rules like: "If X, then no meeting can
be held here" without letting those same people apply some judgement
and / or an exception process.

For example, I could easily see us writing:
Mandatory: Location must be at least 50KM away from a war zone, or a
border between 2 countries who are at war with each other.

This sounds like grand mandatory requirement; I know that I find it
distracting to have my presentation interrupted by an RPG passing
through the window, it distracts participants and makes hums difficult
to hear.

This would have ruled out Seoul - the DMZ is ~35km away, and, although
there is an armistice, (I believe) that N and S Korea are still
technically at war.
Dunno about you, but I liked Seoul, and felt safe...

> not going to have the meeting there, period.

This also sounds like a fine mandatory rule...

However, at a recent meeting (I *think* it was in Berlin, but cannot
swear to that) there were not enough "meeting rooms", and one of the
larger rooms was split into two smaller spaces with air walls.
Worked just fine. If we write Mandatory rules (with no exception
processing) we'll have to be very very precise as to what exactly we
mean - luckily we have many armchair lawyers we can rope in...
Personally I think it is preferable to explain what we really really
want (call it mandatory if we like), what we really want (important),
and what we'd like to have (desirable), and assume that the folk
running the process are a: mostly sane and b: not out to make us sad.

> "acceptable" such that it is meaningful.

... and the fact that we have meeting selection *people* (and not
mindless machines) is why I don't like mandatory to be such an
absolute -- I think that we should always allow an out / exception
handling for corner cases...
So, I think that Mandatory should really mean "Do X, unless there is a
really good reason not to" -- this seems to be very very similar to
"Exception-required", and so these should just a a single level.

I also think that it is impolite to assume that we need to document
things like: "Thou shalt not meet in a location if there is not enough
space". If we really think that the folk selecting meeting venues
cannot figure that out, then we have bigger issues, and no amount of
documentation will solve it...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Apr 2017 14:26:55 -0700

On Wed, Apr 5, 2017 at 2:02 PM, Dave Crocker <[email-masked]> wrote:

> "move or cancel" is language that only has meaning /after/ selection. It
> is therefore formally out of scope.
>
>
You should give Eliot a PR removing section 5.4 and 5.5,then; I don't
agree, but that would make this concrete.  As I said, I don't care whether
these are in this document or not, only that they are clear.

> Exception into the mix -- is mostly continuing to ignore the human factors
> points I keep raising:  Both in creating such a ranking list and in
> applying them, free-form human performance mostly sucks.
>
>
I think our disagreement is that I don't see these as a ranking system.
They indicate which branch of actions to follow.  For that, you want to
have as many indicators as branches you intend to support.  I think there
are four branches and that it is unhelpful to have indicators that might
match one or more of the underlying branches.

> one hour to the next, never mind one day to the next.  On the application
> side -- absent quite a lot of on-going training and quite a lot of diligent
> application -- people are quite horrible at decision-making that properly
> juggles such a range of nuanced requirements.
>
> they will be used in practice and what the basis is for believing that it
> will be practical for the Meetings Committee and for the staff.
>
>
If you have a requirement written to allow the branching, this works
better.  This sort of writing:

The Facility directly provides, or permits and
facilitates, the delivery of a high performance,
robust, unfiltered and unmodified IETF Network.

Is a lot harder to test than the "network has reachability to X of Y sites
and a throughput capacity of at least N mbps per attendee to the nearest
IXP."   I can see why you don't want to name X, Y, and N in an archival
document, but making them pointers to references maintained in a more
living document isn't beyond our capabilities.

Ted

---

From: Pete Resnick <[email-masked]>
Date: Wed, 5 Apr 2017 16:36:25 -0500

On 5 Apr 2017, at 16:27, Lou Berger wrote:

> Pete,
>
>     Thanks for the response.
>
>
> On 4/5/2017 3:31 PM, Pete Resnick wrote:
> Well I wanted to get more info and to understand before rehashing what
> was discussed.  As this wasn't minuted (but I didn't listen to the
> recording) I thought asking before disagreeing made sense.  Depending 
> on
> the rationale/conclusion I may even agree.

Yeah, I do wish this point was captured in the minutes. I have to admit: 
I *think* I know what the rationale was, but I don't want to say until I 
review the Meetecho because I had a discussion outside of the session 
about this topic where I expressed my own opinion, and I'm not 
completely sure that I haven't mashed the two in my head. Bad form for 
the chair to let their own opinion get in like that. :-)

>> this topic."
> Fair enough.  Given the brevity of the response -- This is basically 
> how
> I read it.
>
>>  So I think we are following regular 2418 order here.
>
> Great.  My hope  is to see (quoting here)
>
>    Decisions reached during a face-to-face meeting about
>    topics or issues which have not been discussed on the mailing list,
>    or are significantly different from previously arrived mailing list
>    consensus MUST be reviewed on the mailing list.

You bet. The chairs are absolutely committed to that principle.

> Specifically, I think it's reasonable to explain on the list  the
> rational for basically saying the it's okay to plan for a meeting that
> will operate at a loss discussed.

Yep. Unless Charles or Eliot (or for that matter, anyone else on the 
list who can do so) gets to it first, I'll post a summary of that part 
of the discussion once I get unburied from day-job things.

pr

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Apr 2017 14:37:01 -0700

On Wed, Apr 5, 2017 at 2:18 PM, Warren Kumari <[email-masked]> wrote:

> On Wed, Apr 5, 2017 at 4:18 PM, Andrew Sullivan

> "Exception-required", and so these should just a a single level.
So, reading this, I assumed you simply saw 3 branches to this rather than
4.  That is, you saw that there *might* be an exception to even rules like
"Must not select a venue with no network" and that the people involved
should be able to put it to the community when they thought there was such

> documentation will solve it...
This seems to read as "Anything in the mandatory branch would be so obvious
that it would be rude to mention it".   I disagree with this.  We have
enough people from enough different places that what some of us consider
"it would be rude to mention it" turn out to be "eh, we could trade it off"
to others.  Unless we actually write it down, we'll continue to have the
assumptions about what belongs in which category as a source of late
surprise and contention.

No hats,

Ted

---

From: Lou Berger <[email-masked]>
Date: Wed, 5 Apr 2017 17:42:36 -0400

Thanks Pete.  This sounds perfect.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 5 Apr 2017 17:27:06 -0400

Pete,

    Thanks for the response.

Well I wanted to get more info and to understand before rehashing what
was discussed.  As this wasn't minuted (but I didn't listen to the
recording) I thought asking before disagreeing made sense.  Depending on
the rationale/conclusion I may even agree.

> consensus of the WG, therefore it will be removed and we are done with 

Fair enough.  Given the brevity of the response -- This is basically how
I read it.

Lou

---

From: Pete Resnick <[email-masked]>
Date: Wed, 5 Apr 2017 17:02:50 -0500

> It is therefore formally out of scope.

Whoa there! Dave, it is not your call that this (or anything) is 
formally out of scope.

As I said at the f2f meeting, the charter is not crystal clear on this 
point:

> The MTGVENUE working group is the forum where the IETF community can
> discuss and agree on what should go into the policies, the selection
> process, and the detailed criteria going forward. All criteria and all
> other aspects of the process are open for discussion.

As Alissa said at the meeting, the charter is flexible enough to allow 
the WG to write a document that can be applied only at the beginning of 
the process, or might be applied at multiple points. She also suggested 
that we start with the initial (pre-contract) criteria first to make 
sure we reach consensus on that, and then take on other stuff if desired 
afterwards, and I believe that is good advice. In any event, nobody has 
declared issues of "move or cancel" out of scope. Please refrain from 
making such calls in the future.

pr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 15:25:05 -0700

> Whoa there! Dave, it is not your call that this (or anything) is 

That's a style of objection that we do frequently in the IETF and misses 
the distinction between authority and ability.  Any of us can raise the 
question.  I'm raising it.

>> other aspects of the process are open for discussion.

Again, all of the language is about the selection process.  It says 
nothing about contracting or canceling or any other part of the venue 
process as being within scope.

> the process, or might be applied at multiple points. 

Where is this sort of flexibility justified in the charter?

d/

ps. Again, the ultimate issue is that going beyond the specifics of 
/selection/ conflates things in a way that is already adding significant 
complexity to the discussion.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Apr 2017 18:43:55 -0400

Hi,

See also Ted's response to this, with which I agree, but I want to
make another point.

> and / or an exception process.

[…]

> handling for corner cases...

This stance quite plainly empties the word "mandatory" of its meaning.
If you wish to remove the "mandatory" items and call them "Really
Sooper Genius Important" or something (to indicate that they're More
Important than the Important ones), I'm ok with that.  But they're not
_mandatory_.  "Mandatory", both in the plain English meaning of the
word and as it is defined in the document now, means that if the
condition is not met then the target thing cannot be reached.  It is
mandatory to have reached 16 years of age in Ontario in order to apply
for a G-class license.  That doesn't mean that the day before your
16th birthday you get to write the test.  You need to be 16.  Period,
end of story, no exceptions, do not pass go, do not collect $200.

If people instead want to have an ordered list of classes in
descending order of importance, I can buy that as long as the first
one isn't "mandatory" and doesn't contain enough room in each
criterion that it all turns into "judgement call".  (e.g. "Must be
considered" is meaningless for a high-importance item.)  We already
_have_ that arrangement, and the continual expressions of discontent
suggest to me that it doesn't work for at least part of the community.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 15:50:36 -0700

> descending order of importance, I can buy that as long as the first

Each time you have put that model forward, I've pointed out the human 
factors challenges of applying it.  The simple summary of those 
challenges is that for any interesting list, almost no human does that 
in almost any situation reliably or accurately.

I do not recall seeing you respond this point of practical concern.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Apr 2017 18:54:27 -0400

> I do not recall seeing you respond this point of practical concern.

I believe, Dave, that we have already agreed that we disagree about
this, so I don't think I will engage with you on the topic either on
or off the list.

Have a nice day,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 16:00:24 -0700

> this, so I don't think I will engage with you on the topic either on

I don't recall agreeing to that.

When one proposes something, there is usually an affirmative obligation 
to justify it.  In this case, the simple form of the challenge is:  How 
will that work, in actual practice?

And yes, I've noticed that you won't engage on this point. Perhaps 
pragmatics don't matter here.

d/

---

From: Pete Resnick <[email-masked]>
Date: Wed, 5 Apr 2017 18:02:25 -0500

On 5 Apr 2017, at 17:25, Dave Crocker wrote:

>>> "move or cancel" is language that only has meaning /after/ 
>>> selection. It is therefore formally out of scope.
>>
> That's a style of objection that we do frequently in the IETF and 
> misses the distinction between authority and ability.

I believe this style of objection, stating the conclusion as fact 
instead of stating it as an opinion, and particularly when it comes to a 
matter of WG process, is chilling to productive discussion and 
disruptive of WG process. As a way to suppress discussion, it is 
incredibly effective. I do think it is used far too often in the IETF. 
I'm requesting that it not be used in this group in the future.

> Any of us can raise the question.  I'm raising it.

I will take your objection as saying, "I believe that the word 
'selection' in the charter means that discussion should be limited to 
things prior to contracting, and that discussion of 'move or cancel' 
should be considered out of scope."

>> As I said at the f2f meeting, the charter is not crystal clear on 
>> this point:
>>

The above text says that the WG is to discuss and agree on what goes 
into three things: policies, selection process, and detailed criteria 
going forward. I read those as three separate items and not solely about 
the selection process.

>> As Alissa said at the meeting, the charter is flexible enough to 
>> allow the WG to write a document that can be applied only at the 
>> beginning of the process, or might be applied at multiple points.
>

I take Alissa to have read the same text that I did. She can further 
clarify if she desires.

> /selection/ conflates things in a way that is already adding 
> significant complexity to the discussion.

I believe the complexity was already in the discussion, but hidden 
behind people having different definitions in their heads of the same 
word. Insofar as we end up identifying items that people believed all 
along were in the "considerations for move or cancel" category, I 
believe that reduces the complexity of the discussion. We may decide to 
remove those items from the final document, or we may decide that for 
all of the criteria, we should give guidance as to how they should be 
applied if something changes after contracting. Either way, clearly 
separating out people's reasons for wanting any particular criteria in 
the document is incredibly helpful to me, as one of the people who has 
to make the call in the end of what the WG intended.

pr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Apr 2017 16:12:22 -0700

> going forward. I read those as three separate items and not solely about 

So, there's no constraint on the first clause or the last one?

Since they aren't constrained to the selection process, what else bounds 
their scope?

The charter has no explicit reference except to meeting venue selection 
process -- and there are quite a few such references to exactly and only 
that, and FWIW as I recall, that was intentional -- so I must be missing 
the text that enables considering a wider range of issues.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Apr 2017 00:39:13 +0100

On 05/04/17 23:43, Andrew Sullivan wrote:
> _mandatory_. 

+1, that class is not useful IMO, getting rid of it will help

On the same point at 05/04/17 23:50, Dave Crocker wrote:
> factors challenges of applying it.

ISTM that the humans composing the total product that is this discussion
are less varied and more predictable than the factors. (Yeah, sorry for
that:-)

Substantively: I don't find Dave's objection to eliminating the
"mandatory" class of requirement even a teeny little bit convincing.
A badly defined re-use of a term not matching its meaning in typical
English usage is just not helping.

S

---

From: Eliot Lear <[email-masked]>
Date: Thu, 6 Apr 2017 06:46:01 +0200

Hi Lou,

> of the discussion once I get unburied from day-job things.

The basis for that discussion was that the financial model of the IETF
is undergoing change, and that meeting revenue is likely not to be as
important as it once was.  The room did not want the old model codified.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 6 Apr 2017 07:04:01 +0200

Hi Stephen,

> +1, that class is not useful IMO, getting rid of it will help

I think we are coming quite close to it, and if that is what the WG
wants, then your editor will happily comply (conversely if the WG wants
to keep all the mandatory criteria as are, the same holds.  This is,
after all, a WG doc). 

Based on the breakdown I mentioned there are only three Mandatory fields
left.  One is that the community must have been consulted, the second is
that there is enough space for the meeting, and the third is wheelchair
accessible (this last as agreed in the room).  The first is something
that could be moved to Section 5.  The last is something that probably
still needs some wordsmithing in order to be actionable by the IAOC. 
That leaves "enough space".  I have attempted to rewrite it so that it
is more clearly actionable.

The issue then is whether "Mandatory" means we have to cancel the
meeting if, for some reason, the number of rooms comes up short.  That
is- we signed the contract, and, well, oops.  We have more WGs that need
to meet, because we didn't know how things would look N years ago.  It
would be simply crazy to do so.  But the IAOC shouldn't PLAN for such a
shortfall.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Apr 2017 01:08:51 +1200

On 06/04/2017 17:04, Eliot Lear wrote:
> accessible (this last as agreed in the room).  

It might have got lost in the noise that I suggested that there is actually
a fourth one: Enough *hotel* rooms in total (regardless of whether they are
in the main hotel, backup hotels, or budget hotels). But it's like enough
meeting rooms - there's nothing we can do if an extra 500 people
register the day before the early bird cutoff. 

    Brian

> The first is something

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 6 Apr 2017 11:29:23 -0400

> On Apr 5, 2017, at 4:51 PM, Eliot Lear <[email-masked]> wrote:
> 

Correct. Out of a desire to see progress towards consensus, my suggestion is for folks to focus on the set of criteria needed to initially select a venue for an upcoming meeting which has no venue contracted already. If the WG can get consensus around those criteria and how to organize them, I think that it will have achieved a meaningful milestone.

At that point, the WG may want to consider how the set of criteria might apply at later stages in the process between the time of initial venue selection and the time of a meeting itself, or it may not want to consider this. That does not need to be decided now, so I think energy would be better channeled towards finding the consensus described above.

My motivation for suggesting this sequencing of the work is that decisions about breaking a contract and moving or canceling a meeting inherently have additional considerations associated with them that initial venue selections do not have — e.g., the specific circumstances leading to consideration of moving or canceling, cancellation costs, costs to our relationships with particular venues or venue chains, etc. So I think it will be easier to settle on criteria for initial venue selection before adding these additional factors into the discussion.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 6 Apr 2017 11:37:06 -0400

Commenting as an individual below ...

> On Apr 5, 2017, at 9:40 AM, Eliot Lear <[email-masked]> wrote:
> 
> As mentioned by the chair, I am downgrading requirements based on working group discussion, mostly from Mandatory to Important.  As a reminder, the words are intended to be used consistent with their plain meaning.  That is- just because something is now Important specifically does not mean that it is UNimportant.  
> The IETF Hotel(s) directly provide, or else permit…
The full text of this one is:

The Facility directly provides, or permits and facilitates, the delivery of a high performance, robust, unfiltered and unmodified IETF Network.

Personally I think this should be a mandatory criterion, i.e. we should not select a venue that cannot provide this. If this needs to reference the meeting network requirements document to provide the objective criteria by which it will be judged, that would be fine, I think. 

Alissa

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Apr 2017 09:19:21 -0700

On Apr 6, 2017, at 8:29 AM, Alissa Cooper <[email-masked]> wrote:
> I think it will be easier to settle on criteria for initial venue selection before adding these additional factors into the discussion.

Which, of course, brings us back to the comment I first made at the mike in Chicago. We need to have an idea of what timeframe this draft targets. Does it target breaking a contract, making a contract, or investigating options with a view to advising the IAOC on a possible contract? I agree, let's not focus on failure, which would result in breaking a contract, especially given that to my knowledge the IETF has never needed to do so. Let's focus on investigation of venues (the context of the first draft I wrote), and perhaps guide the IAOC in the trade-offs relevant to selecting one.

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Apr 2017 13:12:20 -0400

Eliot,

> important as it once was.  The room did not want the old model codified.

There's a bit of distance between saying we're preserving/codifying the
old model and that it's okay to knowingly setup a meeting that is going
to loose money, i.e., which will likely translate to increased meeting
fees. 

The text in question reads:

    The economics of the Venue allow the meeting to be net cash positive.

To make make it clear that it's not saying preserve the current model, how about:

    The economics of the Venue allow the meeting to not result in a net
loss.

Note: I'm not voicing an opinion on the category of importance here,
whichever one persists is fine with me.

Lou

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Apr 2017 13:18:23 -0400

> to loose money, i.e., which will likely translate to increased meeting

Why does that follow?  It could be that a new sponsorship arrangement
supports IETF activities generally, and maybe meetings are a net loss.
I suspect that's how ICANN operates, just for instance (their meeting
budgets are amazing, and it seems unlikely that they get enough
sponsorship to cover them.  And they charge no fees).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Apr 2017 13:40:30 -0400

> sponsorship to cover them.  And they charge no fees).

Then these meetings don't operate at a loss, they are covered by
sponsorships or other donations.   I guess we need to define net loss -
unless you're suggesting that not covering costs in a projected /
budgeted fashion is acceptable?

Lou

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Apr 2017 19:44:21 +0200

Hi Lou,

>     The economics of the Venue allow the meeting to not result in a net

What was said in the meeting, as I recall, was that even planning a loss
at ONE meeting is okay, so long as the IAOC can see their way clear from
a budgetary standpoint.  For instance, Jari was complaining about the
cost of going to Japan.  Maybe what happens (and I don't know if this is
the right thing to do) is that the IAOC decides to subsidize a meeting
with Japan from somewhere else.  Should that not be allowed, and should
the IETF community care?  And if we do, what precisely is it that we
care about?

Regards,

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Apr 2017 14:03:06 -0400

> budgeted fashion is acceptable?

If we have to define net loss in this case, then we start to try to
define the financial model underlying the whole matter and I think we
have a problem.

What about something along the lines of, "The venue appears to be
consistent with the bounds of the budget for the meeting"?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Apr 2017 14:11:53 -0400

Sure.  Close enough.

Lou

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Apr 2017 20:12:28 +0200

> consistent with the bounds of the budget for the meeting"?

I don't see a problem with that sort of text, but let me ask this
question: has there ever been a meeting where that WASN'T true?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 06:21:14 +1200

> question: has there ever been a meeting where that WASN'T true?

And why are we even discussing this? IASA has the responsibility
for managing the budget, including any tradeoffs between various
meetings. That doesn't need micro-managing by RFC text.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Apr 2017 11:26:31 -0700

> On Apr 11, 2017, at 10:44 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Lou,
> 
> 

I think that is stated too tightly.

The IAOC has a budget for IETF operations 365 days a year, which includes the costs of the secretariat, IT expenses, yada yada yada, and OBTW, meetings. Meeting fees pay for part of the costs; we also have ISOC funding, which is primarily derived from organizational member fees and PIR profits (which Steve Crocker will tell you exist for exactly one purpose, which is the funding of the IETF), and we have funding from hosts and sponsors. The point is that the sum of the revenues meets or exceeds the sum of the costs.

So it's not "let's make enough in meeting X to pay for the loss in meeting Y", it's "let's fund the entire budget".

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Apr 2017 14:35:01 -0400

> meetings. That doesn't need micro-managing by RFC text.

For me the driver is for the community to provide some direction on
meeting expenses so that the IAOC doesn't have the freedom to choose
meeting locations that end up resulting with the community paying even
higher bills. I've talked with folks who have said meeting costs are
already driving away (their) participation and don't want to see it get
worse.  Capturing the gist of this is certainly hard. The no-loss on a
meeting was a way of covering this concern to some degree.  Andrew's
language is IMO compromise that at least keeps the topic of expenses as
part of the decision making process.

Lou

---

From: Pete Resnick <[email-masked]>
Date: Tue, 11 Apr 2017 13:39:01 -0500

On 11 Apr 2017, at 13:26, Fred Baker wrote:

> So it's not "let's make enough in meeting X to pay for the loss in 
> meeting Y", it's "let's fund the entire budget".

Between this, Andrew's comment, and Brian's comment, I'm starting to 
hear that "This is not a requirement for meeting selection; it is an 
overall budget requirement". That's starting to sound out of scope for 
the document. Are there objections to removing this item from the 
document entirely?

pr

---

From: Pete Resnick <[email-masked]>
Date: Tue, 11 Apr 2017 13:41:04 -0500

Whoops. Didn't notice Lou's response to Brian before I hit send. Too 
quick on the trigger. Let's wait to see if that part of the thread comes 
to ground before making a call here.

pr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 06:47:09 +1200

On 12/04/2017 06:35, Lou Berger wrote:
> higher bills.

Understood, but since money is fungible, that is an issue of the total
annual budget and how much of it comes from meeting attendance fees.
It's not directly a matter of the costs of an idividual venue. 

> I've talked with folks who have said meeting costs are
> worse.  

Sure, but that is the sum of meeting fee + hotel + airfare + expenses.
Minimising that might also be a goal, but it's a different goal.

> Capturing the gist of this is certainly hard. The no-loss on a

Fair enough, but minimising expense to IASA is different from minimising
expense to each participant.

    Brian

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Tue, 11 Apr 2017 18:55:52 +0000

>part of the decision making process.

I agree with Brian, and I¹m worried that this is getting too deep into
trying to codify in a a few sentences what is a complex issue and
something that the IASA is already tasked with managing.

A no-loss meeting isn¹t the main finance objective, the main finance
objective is having an overall IASA balanced budget without overruns, and
long term management of the meeting costs so as to get the best value for
the IETF and to keep the IETF viable.

However both of those are not something that is a requirement we can code
in a meeting venue selection requirement.

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Apr 2017 16:13:36 -0400

Sounds like it's time for me to drop this one - oh well would have liked
to keep *something* on expense control...

Lou

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Apr 2017 14:51:25 +0200

Editor hat firmly off.

Please see below.

On 4/6/17 5:37 PM, Alissa Cooper wrote:
> The Facility directly provides, or permits and facilitates, the
> delivery of a high performance, robust, unfiltered and unmodified IETF
> Network.
>
> Personally I think this should be a mandatory criterion, i.e. we
> should not select a venue that cannot provide this. If this needs to
> reference the meeting network requirements document to provide the
> objective criteria by which it will be judged, that would be fine, I
> think. 
>

I agree that this one should be Mandatory, and propose to make it so in
the next version of the document.  My logic is as follows:

  * It can generally be determined when a network is filtered, and so
    it's an easy criteria at least to provide an objective answer to.
  * As a matter of course, people working at the IETF have to
    communicate with both their companies and their customers in
    confidence, and they could be anywhere.  In this sense, I don't
    think we can run a successful meeting without such unfettered access.
  * We tend to eat our own dog food, and as such need necessary network
    access to conduct experiments.

It may strike people as odd as to why I wouldn't argue the same for the
other network requirements.  We had a discussion about this in Chicago,
and there was some hope of using a network requirements doc from the NOC
folk.  Unfortunately that doc is not kept up to date.  As such, while I
think we might reasonably all agree that having a functioning network is
quite important, it's actually quite hard to direct the IAOC to provide
such a thing without the requirements reading as trivially true.  If the
requirement isn't observably true or false, we should probably not make
it mandatory.  Moreover, the NOC is really an organ of the IAOC, and
referencing their document in order to have them tell us to direct them
seems just a bit circular.

Eliot

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Apr 2017 17:54:53 +0300

Hi, Eliot.

I don’t think I disagree with the conclusion, but I think some of the logic is flawed.

> On 18 Apr 2017, at 15:51, Eliot Lear <[email-masked]> wrote:
> 
> Editor hat firmly off.
> Please see below.
> 
> I agree that this one should be Mandatory, and propose to make it so in the next version of the document.  My logic is as follows:
> It can generally be determined when a network is filtered, and so it's an easy criteria at least to provide an objective answer to.
We get to determine whether the network is filtered or not two days before the meeting starts. By then participants are in the city, in the air or packing. Measurement cannot affect venue selection. Only promises can.
> As a matter of course, people working at the IETF have to communicate with both their companies and their customers in confidence, and they could be anywhere.  In this sense, I don't think we can run a successful meeting without such unfettered access.
> We tend to eat our own dog food, and as such need necessary network access to conduct experiments.
Both of those points assume we need some kind of Internet access that others people on business travel don’t. European countries (not just the UK) are constantly toying with mandatory filtering to prevent copyright infringement, child pornography and hate speech. See the below links in no particular order. Countries in other parts of the world either filter more or plan to filter more.

Our use of the Internet is no different from that of any conference of doctors or insurance salespeople.

Yoav

http://www.telegraph.co.uk/technology/2017/01/26/porn-blocking-legislation-cement-internet-filtering-uk-law/ <http://www.telegraph.co.uk/technology/2017/01/26/porn-blocking-legislation-cement-internet-filtering-uk-law/>
https://policyreview.info/articles/analysis/internet-filtering-trends-liberal-democracies-french-and-german-regulatory-debates <https://policyreview.info/articles/analysis/internet-filtering-trends-liberal-democracies-french-and-german-regulatory-debates>
https://www.eff.org/deeplinks/2017/03/eu-internet-advocates-launch-campaign-stop-eus-dangerous-copyright-filtering <https://www.eff.org/deeplinks/2017/03/eu-internet-advocates-launch-campaign-stop-eus-dangerous-copyright-filtering>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Apr 2017 17:02:26 +0200

Hi Yoav,

I'm happy that you don't disagree with the conclusion (is that the same
as agreeing?).  Please see below.

On 4/18/17 4:54 PM, Yoav Nir wrote:

> We get to determine whether the network is filtered or not two days
> before the meeting starts. By then participants are in the city, in
> the air or packing. Measurement cannot affect venue selection. Only
> promises can.

There is a site visit at some point, and the contract can build on
that.  If the network is filtered to begin with, then at least we know
what we're up against before we sign.

>>   * We tend to eat our own dog food, and as such need necessary
>>     network access to conduct experiments.
>>
> Both of those points assume we need some kind of Internet access that
> others people on business travel don’t. European countries (not just
> the UK) are constantly toying with mandatory filtering to prevent
> copyright infringement, child pornography and hate speech. See the
> below links in no particular order. Countries in other parts of the
> world either filter more or plan to filter more.
I think there are two aspects here:

  * Protection of IETF participants from outside threats.  By requiring
    unfiltered access, we the IETF participants would be taking on some
    risks.  We could conceivably demand transparency instead, but I
    don't think that works for us as a functional requirement.
  * Enforcement of local laws in relation to our use of the network. 
    Here, I wonder if we can word the requirement such that this happens
    in a passive form.

> doctors or insurance salespeople.

Very few doctors and lawyers experiment with Internet technology the way
we do.  Consider this: I remember Paul Traina coding up and deploying
code from the back of the room with some operators.

Eliot

---

From: Jim Martin <[email-masked]>
Date: Tue, 18 Apr 2017 11:33:51 -0500

> There is a site visit at some point, and the contract can build on that.  If the network is filtered to begin with, then at least we know what we're up against before we sign.

	During the site visit, we always ask about (and do some non-exhaustive testing for) filtering, as what is published and what is “real” often differ. Our greatest challenge is that the provider for the venue when we visit is generally different from the providers we’ll be getting the IETF circuits from. Also, venue selection thus far has not required a firm commitment from circuit providers, hence clarity on the providers and their limitations (self imposed or otherwise) come into play well after contracting is complete.

> Protection of IETF participants from outside threats.  By requiring unfiltered access, we the IETF participants would be taking on some risks.  We could conceivably demand transparency instead, but I don't think that works for us as a functional requirement.
	At the current time, this is a non-goal. Our networks are as wide open as we can make them, with the exception of BCP-38 and some limited protections for our management networks.

> Very few doctors and lawyers experiment with Internet technology the way we do.  Consider this: I remember Paul Traina coding up and deploying code from the back of the room with some operators.

	We keep this very much in mind in our design and operations. Our goal is to facilitate not just unencumbered Internet access, but also to allow new work to take place.

	- Jim

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Apr 2017 12:58:14 -0700

On Tue, Apr 18, 2017 at 7:54 AM, Yoav Nir <[email-masked]> wrote:

> others people on business travel don’t.
>

I think this varies a good bit.  Some of our communication back to our
companies is bog standard business traveler stuff; some of our
communications among ourselves or our devices is not.  A network that
allows WebRTC media and data channels to flow without TURN servers is
better for our remote participants, for example, and that may be a
consideration for the typical business traveler.  We also have IETF network
users who are more likely to engage in direct network management (or
management of network devices) than would be common.  A tight firewall will
hinder their ability to do that, and result in them spending time on
fiddling with that rather than contributing.

I agree that  "unfiltered and unmodified" may be difficult to assure when
nation states may change their laws, but I think it is reasonable for us to
require that this be unfiltered and unmodified *by the venue's own
actions*.  The larger question of what to do when meeting in a place all of
whose facilities are required to implement such filtering likely belongs in
a different requirement.

Just my two cents,

Ted

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Apr 2017 13:45:09 -0700

> On Apr 18, 2017, at 12:58 PM, Ted Hardie <[email-masked]> wrote:
> 
> I agree that  "unfiltered and unmodified" may be difficult to assure when nation states may change their laws, but I think it is reasonable for us to require that this be unfiltered and unmodified *by the venue's own actions*.  

Good comment. That said, the one place I can think of where this was a real issue was at IETF 79; the host had to jump through some serious hoops to provide us with unfiltered access. In that case, I think that the host could have very reasonably said that the filtering was being done by a national firewall beyond their control. Would we have found that acceptable?

---

From: Ole Jacobsen <[email-masked]>
Date: Tue, 18 Apr 2017 14:58:02 -0700 (PDT)

On Tue, 18 Apr 2017, Fred Baker wrote:

> > I agree that "unfiltered and unmodified" may be difficult to 
> > assure when nation states may change their laws, but I think it is 
> > reasonable for us to require that this be unfiltered and 
> > unmodified *by the venue's own actions*.
> 
> Good comment. That said, the one place I can think of where this was 
> a real issue was at IETF 79; the host had to jump through some 
> serious hoops to provide us with unfiltered access. In that case, I 
> think that the host could have very reasonably said that the 
> filtering was being done by a national firewall beyond their 
> control. Would we have found that acceptable? 

Yes, because it was made very clear what the actual situation would
be: unfiltered network in the meeting area, filtered in the hotel
rooms. And, at the time, the filtering was limited to some 
high-profile sites like Google, Facebook and YouTube, these days
the problem is active sabotage of VPN circuits. If we propose to
have another meeting in such a venue it would certainly only happen
after extensive community review.

Ole

---

From: Yoav Nir <[email-masked]>
Date: Wed, 19 Apr 2017 01:00:46 +0300

> On 18 Apr 2017, at 23:45, Fred Baker <[email-masked]> wrote:
> 
> 

What’s more, even supposing we get an exemption, it’s fairly reasonable to assume that a government might cancel exemptions on short notice.

We *can* require no filtering by the venue or ISP. So if some country requires ISPs to offer filtering in an opt-out basis, we can opt out.  If at the last moment the government sets up some big firewall, there’s not much we can do anyway.

Yoav

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 18 Apr 2017 22:31:33 +0000

From: Mtgvenue <[email-masked]> on behalf of Jim Martin <[email-masked]>
Date: Tuesday, April 18, 2017 at 9:33 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Alissa Cooper <[email-masked]>, Yoav Nir <[email-masked]>
Subject: Re: [Mtgvenue] Issue #21: unfiltered should be mandatory

[cue] This has been true and important for the IETF hackathons as well. Jim and his team have been very accommodating in this regard.

Cheers,
Chares

---

From: "Tobias Gondrom" <[email-masked]>
Date: Tue, 18 Apr 2017 23:54:43 +0100

<IAOC hat=”off”>

I agree with Ted. 

I see unfiltered Internet as a strong requirement. But I don’t think this should to be mandatory. 

Statements like “unfiltered and unmodified *by the venue's own actions* would be something we could enforce in a contract stage, unless there are state level obligations to the venue that we can not overcome. Also I would note that filtering may happen in very different levels and amounts. 

In light of the discussion we had in Chicago, I would like to remind that we should be very conservative with the use of mandatory for requirements, but rather use “strong/ high priority requirement” or other determinations. 

I would see this as a very strong requirement and for the IAOC to continue to use strong incentives to ascertain that the venue has unfiltered Internet access, but I don’t think that this must be mandatory. IMHO so far the track record of the IAOC for selecting unfiltered locations is reasonably good. So I hope we can continue in that mode and rather strengthen this criteria if at some point the community feels that the criteria is not strong enough enforced by the IAOC in the selection process. 

Just my 2cents. 

Tobias

From: Mtgvenue [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Tuesday, April 18, 2017 8:58 PM
To: Yoav Nir <[email-masked]>
Cc: [email-masked]; Alissa Cooper <[email-masked]>; Eliot Lear <[email-masked]>
Subject: Re: [Mtgvenue] Issue #21: unfiltered should be mandatory (was: Re: issue #3: Too many mandatory)

On Tue, Apr 18, 2017 at 7:54 AM, Yoav Nir <[email-masked] <mailto:[email-masked]> > wrote:

Both of those points assume we need some kind of Internet access that others people on business travel don’t.

I think this varies a good bit.  Some of our communication back to our companies is bog standard business traveler stuff; some of our communications among ourselves or our devices is not.  A network that allows WebRTC media and data channels to flow without TURN servers is better for our remote participants, for example, and that may be a consideration for the typical business traveler.  We also have IETF network users who are more likely to engage in direct network management (or management of network devices) than would be common.  A tight firewall will hinder their ability to do that, and result in them spending time on fiddling with that rather than contributing.

I agree that  "unfiltered and unmodified" may be difficult to assure when nation states may change their laws, but I think it is reasonable for us to require that this be unfiltered and unmodified *by the venue's own actions*.  The larger question of what to do when meeting in a place all of whose facilities are required to implement such filtering likely belongs in a different requirement.

Just my two cents,

Ted

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Apr 2017 08:05:51 +0200

To me, whether the venue is doing the filtering based on government
mandate or whether the government has a Great Firewall matters very
little.  The fundamental point is this: I don't think the IETF could
have a successful meeting if we cannot hold private communications with
our home offices or customers.  Putting this into context in the current
wording, that would mean that the IAOC should seek out venues in places
where this wouldn't be a problem.  If the situation changes after
contracts are signed, then the IAOC would be required to consult the
community, and then they would have to make a decision.

Maybe we can get around this by crafting the requirement to allow
unfettered VPN access both from hotel rooms and the facility, but I
think that comes pretty close to just unfettered access to everything.

But I guess my question to experienced IAOC and meeting folk is this:
just how hard would this have hit us in the past?  Fred and Ole have
already discussed one venue.  Are there others?  Is there a way to
circumscribe the requirement, such as what Ole mentioned with regard to
how it was handled in that particular case?

Eliot

On 4/18/17 9:58 PM, Ted Hardie wrote:
> On Tue, Apr 18, 2017 at 7:54 AM, Yoav Nir <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Both of those points assume we need some kind of Internet access
>     that others people on business travel don’t.
>
>
> consideration for the typical business traveler.  We also have IETF
> network users who are more likely to engage in direct network
> management (or management of network devices) than would be common.  A
> tight firewall will hinder their ability to do that, and result in
> them spending time on fiddling with that rather than contributing.
>
> I agree that  "unfiltered and unmodified" may be difficult to assure
> when nation states may change their laws, but I think it is reasonable
> for us to require that this be unfiltered and unmodified *by the
> venue's own actions*.  The larger question of what to do when meeting
> in a place all of whose facilities are required to implement such
> filtering likely belongs in a different requirement.
>
> Just my two cents,
>
> Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Apr 2017 09:08:07 -0700

Hi Eliot,

On Tue, Apr 18, 2017 at 11:05 PM, Eliot Lear <[email-masked]> wrote:

> little.
I would class both of these as implementations of the government mandate.
There are quite a few venues, though, that impose limitations based on
their own understanding of security, acceptable traffic patterns, or the
like.  One hotel I stayed in recently, for example, blocked a well-known
consumer video service because the traffic competed with its own on-demand
service.  Many, many others don't permit traffic on ports that they don't
recognize.   In those cases the service is not unfiltered or unmodified by
the venue; they are curating it in ways that hinder the IETF doing its
work.  Making avoiding this a mandatory requirement makes sense to me.

The government mandates are harder to manage, especially when some of them
are crafted to be responses to other social ills (bans on child
pornography, nazi symbolism, etc).  I would put these into a separate
category so that they can be considered during site selection without a
blanket ban.  There is an obvious risk to that (once the machinery in
place, it can be turned to many uses), but it seems like one that has to be
managed with other concerns about the host country or territory.

Just my two cents,

Ted

The fundamental point is this: I don't think the IETF could have a
> successful meeting if we cannot hold private communications with our home
> offices or customers.  Putting this into context in the current wording,
> that would mean that the IAOC should seek out venues in places where this
> wouldn't be a problem.  If the situation changes after contracts are
> signed, then the IAOC would be required to consult the community, and then
> they would have to make a decision.
>
> unfettered VPN access both from hotel rooms and the facility, but I think
> that comes pretty close to just unfettered access to everything.
>
> But I guess my question to experienced IAOC and meeting folk is this: just
> how hard would this have hit us in the past?  Fred and Ole have already
> discussed one venue.  Are there others?  Is there a way to circumscribe the
> requirement, such as what Ole mentioned with regard to how it was handled
> in that particular case?
>
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Apr 2017 18:21:36 +0200

Hi Ted,

Let me then try to articulate two concrete criteria:

"MANDATORY: Within the bounds of BCP38, both the Facility and IETF
hotels provide unfiltered access to the maximum extent permitted by law."

And then:

"IMPORTANT: Within the bounds of BCP38, the Facility and IETF Hotels
provide unfiltered access.  (This criterion is present for the cases
where laws may require ISPs to filter certain traffic)."[*]

Is the IAOC comfortable having to do the research on that?  Are others
comfortable with that?  Wordsmithing?  Is this what people want?  Please
comment.

Eliot
[*] The text in ()s is there to explain why there are two.

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 Apr 2017 10:30:09 -0700

It might be worthwhile to try to define "unfiltered". I, personally, have no problem with the hotel or anyone else preventing access to known purveyors of malware, which happens to coincide with porn etc, and might be describable in terms of reputation at common reputation services. Several have stated (and I agree) that VPNs need to be OK, and access to anything that would be business-relevant to an international business traveller. Trying to describe it as "illegal" intersects with the country's laws, which we might or might not approve of. In such cases, the point might be to not position meetings in places where we would be uncomfortable with ambient legal restrictions rather than a comment about the fact of filtering.

BCP 38 is an odd restriction. It is about outbound filtering at an upstream router - it prevents *me* from sending traffic with spoofed addresses. The point here isn't bad behavior on our part, but behavior on the network's part preventing access to content and services that are somewhere else.

> On Apr 19, 2017, at 9:21 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Ted,
>

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 19 Apr 2017 10:42:32 -0700 (PDT)

"...VPNs need to be OK, and access to anything that would be 
business-relevant..."

I agree on the concept, the problem is that this is a dynamic 
environment with lots of variables and "tools" deployed in various 
ways to block, intercept, maximize revenue, etc by various parties. 
Thus, I think this is classic example of where the document needs to 
be less specific and more generic along the lines of "...deemed to be 
sufficiently open and of sufficient capacity for normal IETF business 
activities..."

Ole

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office:  +1 415-550-9433
Cell:    +1 415-370-4628
Docomo:  090 3337-9311
Web: protocoljournal.org
E-mail: [email-masked]