Subject: Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12

From: Stewart Bryant <[email-masked]>
Date: Mon, 05 Feb 2018 03:04:42 -0800

Reviewer: Stewart Bryant
Review result: Has Issues

I  have been asked to review this draft on behalf of the Routing Directorate.

Please see below.

- Stewart Bryant ([email-masked])

Summary:

Th is an important and difficult to write document on an important topic.

It has a few issues that ought be be considered before proceeding with
publication.

Major Issues:

   o  The Facility and IETF Hotels MUST provide wheelchair access to
      accommodate the number of people who are anticipated to require
      it.

and

   o  The Facility is accessible or reasonable accommodations can be
      made to allow access by people with disabilities.

SB> I am not an expert but I think more than just simple wheelchair
SB> access is required, also you need a set of suitable facilities in the
meeting SB> facility and in at least one hotel and its environs. SB> SB> I
assume that there is some code of practice that can and should SB> be
referenced here.

====

 A description of how reconsideration currently takes
   place is found in <https://iaoc.ietf.org/meetings-
   committee/documents/IETF-VenueSelectionID-
   ContingencyPlanningFlowChart-2016.pdf>.

SB> Maybe it is my finger trouble, but I could not access this
rather unfriendly multi-line URL. I get a 404 error, and when I
edit the URL to remove the %20s that show up in my browser
I get "authentication required".

Minor Issues:

Where we meet?
      We meet in different locations globally, in order to spread the
      difficulty and cost of travel among active participants, balancing
      travel time and expense across the regions in which IETF
      participants are based.

SB> Given the support and encouragement of remote participants, there ought to
be a note about sharing unreasonable time zone difference pain across the
spectrum of remote participants.

====

8.  Privacy Considerations

   This note reveals no personally identifying information apart from
   its authorship.

SB> This is true, but does spawn the question of whether privacy should
be a meeting location selection criteria?

Editorials/Nits:

In the abstract the terms IASA and IAOC should be spelled out. This is part of
a wider problem of the various I* abbreviations that are scattered through the
text not being particularly user friendly. It would be helpful to the reader to
provide a small glossary early in the text.

 ====

 o  It MUST be possible to provision Internet Access to the Facility
      and IETF Hotels that allows local attendees to utilize the
SB> When I first read this I though you meant local as in those
SB> who live in the country, but I think you mean those at the facility.
SB> Clarification may be useful.

====

   o  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 in the combination of spaces
      offered by the facilities, hotels and bars/restaurants in the
      surrounding area, within walking distance (5-10').

SB> I imagine you mean 5-10 minutes not 5-10 feet.

====

   o  Overflow Hotels can be placed under contract, within convenient
      travel time of the Facility and at a variety of guest room rates.
SB> s/of/to and from/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 5 Feb 2018 11:37:27 +0000

Hi Stewart,

I will let Pete or Charles address other comments.  As to these:

> I get "authentication required".

I confirm that this is a problem, and I have contacted the IAOC and AMSL
to see what can be done about it.

> provide a small glossary early in the text.

I would prefer that we not create a glossary.  I will leave to the RFC
Editor to help me on style with expansions, if that's okay.
> SB> Clarification may be useful.

I think this becomes clear in the following sentence.
> SB> I imagine you mean 5-10 minutes not 5-10 feet.

I've expanded this out in my working copy.

>       travel time of the Facility and at a variety of guest room rates.

Ok.

These changes are in my working copy.  Whether there will be a new
version prior to proceeding to the RFC Editor is not my call but the
AD's.  In any case, I will see that they are addressed.

Eliot

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 5 Feb 2018 12:02:36 +0000

> I think this becomes clear in the following sentence.

I still think there is scope of ambiguity. What about "physical attendees"?

Stewart

---

From: Eliot Lear <[email-masked]>
Date: Mon, 5 Feb 2018 12:08:44 +0000

> I still think there is scope of ambiguity. What about "physical

"those attending in person:"?

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 5 Feb 2018 12:26:19 +0000

> "those attending in person:"?

Perfect.

  - Stewart

---

From: Pete Resnick <[email-masked]>
Date: Mon, 5 Feb 2018 09:40:58 -0600

Hi Stewart,

Thanks for the review. Just on the things that Eliot hasn't already 
covered

> assume that there is some code of practice that can and should SB> be

There was considerable discussion on this issue; perhaps I should have 
included this specifically in the shepherd report. Here's what I last 
posted to a question about this:

-
The way I have thought about the distinction is that things in 3.1 are 
things for which IASA (or the secretariat for most practical purposes) 
would have to come to the community and get consensus to do something 
different before they contract. Things in 3.2 they can use their 
expertise and best judgement and make the contract, but even so they 
must notify the community that they are doing so.

So in the case of accessibility, the inability to have wheelchair access 
at the Facility or Hotels is a showstopper; there is no reasonable 
accommodation that can be made for wheelchair users that involves not 
being able to access a location with their wheelchair. If IASA thinks 
that such a facility is still acceptable, they have to make their case 
to the IETF community first and get consensus. For other disabilities, 
IASA is supposed to use their expertise (or that of others they enlist) 
to make sure that the facility is accessible or that reasonable 
accommodations can be made, and might judge that, while a particular 
normal accommodation for a particular disability is not available, a 
facility is nonetheless acceptable. They still must notify the community 
in this case, and bad things might happen if the community finds that 
they have made a poor judgement, but they are not expected clear a given 
lack of accommodation with the community every time.

-

So with regard to referencing a "code of practice", the assumption in 
this document is that, beyond wheelchair access, it is the IASA's 
responsibility to choose the correct set of accessibility requirements, 
which could of course change over time, and inform the community if 
there is a departure from their expectations.

> spectrum of remote participants.

I don't believe we currently do take that into account in location 
selection (perhaps others can chime in), so this would be a new 
requirement. We could bring this back to the WG to try and get consensus 
around it, but that doesn't excite me. :-) I'll leave it to my fearless 
AD to advise.

> be a meeting location selection criteria?

"I refer my Right Honourable Friend to the answer I gave some moments 
ago." ;-) This sounds like a can of worms. I'll again wait for AD 
direction.

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 5 Feb 2018 16:43:40 +0000

On 05/02/2018 15:40, Pete Resnick wrote:
> So in the case of accessibility, the inability to have wheelchair 
> access at the Facility or Hotels is a showstopper; there is no 
> reasonable accommodation that can be made for wheelchair users that 
> involves not being able to access a location with their wheelchair. If 
> IASA thinks that such a facility is still acceptable, they have to 
> make their case to the IETF community first and get consensus. For 
> other disabilities, IASA is supposed to use their expertise (or that 
> of others they enlist) to make sure that the facility is accessible or 
> that reasonable accommodations can be made, and might judge that, 
> while a particular normal accommodation for a particular disability is 
> not available, a facility is nonetheless acceptable. They still must 
> notify the community in this case, and bad things might happen if the 
> community finds that they have made a poor judgement, but they are not 
> expected clear a given lack of accommodation with the community every 
> time.

Actually it is more than the facility itself, it is the venue and 
transport to the venue, and there are a range of disabilities beyond 
mobility that we need to take into account.

If you want a high-level requirement it is presumably something like 
"that there is no reasonable impediment to a participant with mobility 
or sensory disability travelling to and from the venue, obtaining 
suitable accommodation at the venue, or being able to fully participate 
in all aspects of the meeting"

> responsibility to choose the correct set of accessibility 
> requirements, which could of course change over time, and inform the 
> community if there is a departure from their expectations.
>
>> Where we meet?
> requirement. We could bring this back to the WG to try and get 
> consensus around it, but that doesn't excite me. :-) I'll leave it to 
> my fearless AD to advise.

I suppose location is a proxy for this, but if we are trying to be 
inclusive we ought to be inclusive to both groups of participant.

> ago." ;-) This sounds like a can of worms. I'll again wait for AD 

Hm, I doubt that I will ever advice the Queen :)

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Feb 2018 08:06:18 +1300

> On 5 Feb 2018, at 5:04, Stewart Bryant wrote:
...>> Where we meet?
> around it, but that doesn't excite me. :-) I'll leave it to my fearless 

Having participated in the IETF while living in UTC+1, UTC, UTC-6
and UTC+12 at various times, all with or with daylight savings, I feel almost
uniquely qualified to comment on this.

Firstly, add jet lag for the in-person participants to the mix. Then
try to work out the optimisation function across all participants,
to simultaneously minimise jet lag effects and unsocial hours.

I think it's impossible. At the very least, it's a rat hole. So I
highly recommend leaving this issue aside.

    Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 5 Feb 2018 20:38:58 +0000

> highly recommend leaving this issue aside.

+1

Plus, we're pretty much left with the empty set when it comes to locations that match our already long list of requirements. So adding more requirements is largely a no-op.

Lars

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Feb 2018 16:46:23 -0500

Because this thread seems to be where the action is, a brief
summary of comments on another thread [1] that seems to bear on
this Last Call and review and that seems to me to be
complementary to some of the "location" comments on this thread.

(1) Policy and process issues both covered in this document with
sections 2 and at least part of 3 stating/ explaining policies
and 4 and 5 being about process.  That would be ok except
insofar as draft-ietf-mtgvenue-meeting-policy is supposed to
cover the policy issues but is, in practice, a specification and
explanation of what it calls 1-1-1*.   If
draft-ietf-mtgvenue-iaoc-venue-selection-process is intended to
operate within the constraints imposed by
draft-ietf-mtgvenue-meeting-policy, that is a normative
dependency, not something that can be ignored as irrelevant to
the process outlined in this document.  Conversely, if it can be
ignored in the process of considering and evaluating venues,
then draft-ietf-mtgvenue-meeting-policy is either irrelevant
(and should be discarded) or is an orthogonal explanatory
document that should be Informational, not a BCP.  FWIW, I
question whether the material cited as "{MeetingNet]" is really
informative rather than a normative part of the "Internet
Access" Core Value.

(2) I note that, independent of how it comes out, the recent
discussion of interaction between remote participants and
meeting locations is ultimately a discussion about large-area
geographical policies that are not covered by 1-1-1*.  If the
topic is properly discussed in the context of the current
document, the boundary between it and
draft-ietf-mtgvenue-meeting-policy is even less clear than
discussed above.

(3) The criterion of proximity to a significant number of actual
participants appears to have been dropped completely and without
comment.  Perhaps the vaguely-worded "familiar with both the
locale and the IETF" statement in Section 3.3 is intended to be
a substitute, but it is not clear to me what it means or, more
specifically, how "familiar" is to be gauged.  I would have
happy leaving that to the IAOC if they were open and transparent
about what they have done in each case, who is making key
decisions or being relied on for advice, etc.  But that level of
transparency has basically existed; probably if it was more
common, we really wouldn't need a document like this one.

(4) My main conclusion from the above is that the IESG final
review and voting on this document should be postponed and the
evaluation period left open until
draft-ietf-mtgvenue-meeting-policy is ready for evaluation so
that they can be evaluated together and the community identify
any policy or procedural topics that slip through the cracks
between the two and the community believes are worth mentioning,
even as "non-objectives" or relatively unimportant criteria.   I
hope the WG will recommend that to the IESG and/or that the IESG
will make that decision on its own rather than forcing us to
descend into a procedural discussion of whether separating
evaluation of the two is appropriate.

best,
   john

[1] See the thread with Subject "Re: Bangkok and IETF (was: Last
Call draft-ietf-mtgvenue-iaoc-venue-selection-process-11)".   I
am assuming that I do not need to repeat the arguments made on
that thread in detail here.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Feb 2018 00:09:27 +0000

On 05/02/18 20:38, Eggert, Lars wrote:
> adding more requirements is largely a no-op.

If it's a NOOP, I want a pony that delivers beer to
my seat in boring sessions:-)

S

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 5 Feb 2018 20:50:05 -0500

Hi Stewart,

> On Feb 5, 2018, at 6:04 AM, Stewart Bryant <[email-masked]> wrote:
> 

Any actionable criterion that I can conceive of to address this would likely render our already tiny set of acceptable locations to roughly zero. If you have a proposal that would do otherwise, feel free to suggest it.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 5 Feb 2018 20:54:38 -0500

> On Feb 5, 2018, at 2:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Fully agree.
Alissa

---

From: Pete Resnick <[email-masked]>
Date: Mon, 5 Feb 2018 18:28:13 -0800

[I may be slow following up to this, as I have a day-job presentation 
tomorrow for which I have to prepare, so fear not if you don't hear from 
me before Wednesday.]

WG Chair, and particularly document shepherd for -selection-process, hat 
firmly on head:

> complementary to some of the "location" comments on this thread.

I was following the previous thread, though speaking for myself, I would 
have found it easier if you would have created a new thread instead of 
finding this now in the middle of two different threads on two different 
topics. Not the end of the world by any means. Anyway, on the issues:

> document that should be Informational, not a BCP.

This document specifies a general policy (or perhaps "principles") for 
venue selection, particularly regarding location, in section 2.1:

       We meet in different locations globally, in order to spread the
       difficulty and cost of travel among active participants, 
balancing
       travel time and expense across the regions in which IETF
       participants are based.

and in section 3.2.1:

     o  Travel to the Venue is acceptable based on cost, time, and 
burden
        for participants traveling from multiple regions.  It is
        anticipated that the burden borne will be generally shared over
        the course of multiple years.

There are a few other location policies/principles in the document, but 
those are the big two.

As far as I can tell, -meeting-policy is simply specifying a more 
limiting instantiation of the above principles: Given the current active 
participants, the 1-1-1* policy is consistent with the policies above. 
In the future, we could change -meeting-policy (e.g., because of a 
change in demographics) and still be consistent with this document, so I 
don't see how it makes sense to have a normative dependence on 
-meeting-policy in this document. The documents don't contradict each 
other, and both are to be executed by IASA.

>   FWIW, I

As above, [MeetingNet] could change independently of this document, so 
long as the documents do not contradict.

> draft-ietf-mtgvenue-meeting-policy is even less clear than

Since the remote participants issue is a new (and controversial) one 
during Last Call, I'll leave it, and commentary on this, to the 
sponsoring AD. (You're welcome, Alissa. ;-) )

> comment.

No, I think you missed it in section 2.1 ("active participants" and 
"regions in which IETF participants are based"). It has not at all been 
dropped, though maybe worded in a way that you don't think captures what 
you want, in which case suggested text would be appreciated.

> Perhaps the vaguely-worded "familiar with both the
> a substitute

No, that is about asking the secretariat to get advice from people 
familiar with the locale, not about location criteria.

> I would have

This comment seems out of scope for the discussion of this document.

> even as "non-objectives" or relatively unimportant criteria.

Since IMO you got a few of your premises wrong, obviously I don't think 
your conclusion follows. While it might be useful to do the reviews 
together to ensure that there is in fact no dependency between the two 
documents, I believe the WG has not created such a normative dependency, 
and therefore this is not required. The WG has passed both documents to 
our AD at this point, so if you see such a dependency in the current 
documents, that would be a fine Last Call comment on this one in any 
case. In any case, I'll leave it to the responsible AD to make the call 
on how the IESG wishes to evaluate them.

> I

I don't consider the issue "procedural". If you find a dependency, we 
want to know that.

pr

---

From: Pete Resnick <[email-masked]>
Date: Mon, 5 Feb 2018 19:28:50 -0800

On 5 Feb 2018, at 8:43, Stewart Bryant wrote:

> suitable accommodation at the venue, or being able to fully 
> participate in all aspects of the meeting"

That a pretty substantial change to a piece of text that took a great 
deal of back and forth on which to come to rough consensus. Perhaps 
Eliot could suggest some text to satisfy your concern that the 
requirement is for more than just the facility, without having to 
re-hash the whole issue.

> inclusive we ought to be inclusive to both groups of participant.

See comments from Brian, Lars, and Alissa.

> Hm, I doubt that I will ever advice the Queen :)

Well certainly you ought to. ;-)

pr

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 6 Feb 2018 09:36:15 +0000

On 06/02/2018 03:28, Pete Resnick wrote:
>> "that there is no reasonable impediment to a participant with 
>> mobility or sensory disability travelling to and from the venue, 
>> obtaining suitable accommodation at the venue, or being able to fully 

Well we could be silent on the whole matter, but that would surely be 
contra to the basic ethos of the IETF and modern culture.

All I have proposed is that we consider the three core aspects of 
participation (travel, accommodation and participation in discussion), 
and consider enabling those with disabilities  more generally rather 
than focusing on wheelchair access issues.

However I am not an expert in this space. Perhaps this is something that 
we need to take professional advice on.

- Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Feb 2018 09:36:11 -0000

Hi all,

> Any actionable criterion that I can conceive of to address this would likely
render
> our already tiny set of acceptable locations to roughly zero. If you have a
proposal
> that would do otherwise, feel free to suggest it.

In the spirit of Privacy Considerations for protocol specs we should not
necessarily be looking to resolve all privacy concerns, but we should be looking
to expose them so that participants can be aware of the risks and can mitigate
them or choose to not participate.

I would certainly agree that we are unlikely to find a nation stat that
perfectly respects personal and online privacy, but that need not be the
objective. Nor need it be a requirement that the IAOC report on the privacy of a
venue when announcing it. On the other  hand, I bet we would all agree that a
venue that assigned a government official to accompany us at all times listening
to our conversations and noting our sleeping habits would rule itself out. So
there are lines :-)

But what this section should say is something like...

==
Physical and remote participants at IETF meetings should be aware that privacy
norms vary considerably from country to country. Participants with a concern for
their personal or work-related privacy are advised to familiarise themselves
with the privacy risks associated with a venue before attending. Concerns may
include privacy of Internet communications, record of having travelled, and
freedom of association. Some people may have particular concern for the privacy
of information stored on electronic devices when they cross specific national
borders. 

Participants are responsible for taking their own measures in mitigation.

In general, the meeting selection process will not take privacy concerns into
consideration and will not seek to report on them to the community for any
chosen venue. However, it is expected that the selection process will exclude
venues where privacy of attendees is known to be particularly at risk. Such
exclusions might include (although not be limited to) venues where attendees
cannot use VPNs or other security mechanisms to access their home networks and
the Internet in general.
==

...I'm not wedded to that - I only had 4 hours sleep  :-)

Adrian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 6 Feb 2018 09:40:55 +0000

> ...I'm not wedded to that - I only had 4 hours sleep  :-)

That looks like good text.

- Stewart

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Feb 2018 10:01:24 +0000

Hi,

> requirement is for more than just the facility, without having to

Unfortunately I do not.  I think the intent here is cover the bear
minimum requirements we need, and otherwise continue  to trust in the
IASA that they really are going to take good care of our participants. 
In short, my suggestion is to run with the current text, and if we have
a problem later, make a chcange

Eliot

---

From: Matthew Ford <[email-masked]>
Date: Tue, 6 Feb 2018 10:04:50 +0000

> On 6 Feb 2018, at 10:01, Eliot Lear <[email-masked]> wrote:
> 
> cover the bear
> minimum

More reasons to meet in Canada...

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Feb 2018 10:17:25 +0000

Hi Adrian,

<editor hat on; you can relate ;-)>

> ...I'm not wedded to that - I only had 4 hours sleep  :-)

I think you would agree that that text is a bit verbose, and some of
this is well covered in the networking requirements above.  On the other
hand, that text hasn't really changed since Fred created a placeholder
(good that he did), and it seems like we can and should at least provide
some guidance to the IASA (that is to say, your humble editor is
embarrassed that he didn't propose the below earlier).  I also think we
have to be careful how much responsibility to place on the IASA in this
regard.  Here then is my suggestion:

<--snip-->

Privacy Considerations
----------------------------
Different places have different constraints on individual privacy.  The
requirements in this memo are intended to provide for some limited
protections that attendees can apply.  As meetings are announced, IASA
SHALL provide the IETF with any limitations to privacy they have become
aware of in their investigations.  For example, participants would be
informed of any regulatory authentication or logging requirements.

<--snip-->

This provides some transparency without demanding more than a small
increment of work from the IASA (we don't want this to become a huge
legal exercise and expense).

<Editor hat off; now head exposed>

I do want to reinforce something that Alissa pointed out: it is
extremely easy for this organization to require itself out of all
venues.  We need to be very careful of that.

Thanks to you and Stewart, and Jordi earlier, for hammering on this point.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 6 Feb 2018 21:28:27 -0500

Hi John,

I agree with you that there is a relationship between the two documents, although it’s not clear that it’s a normative one. I’ve pulled draft-ietf-mtgvenue-iaoc-venue-selection-process from this week’s IESG telechat to provide time to process draft-ietf-mtgvenue-meeting-policy and make some of the other changes to venue-selection-process that have surfaced in the recent threads.

Best,
Alissa

> On Feb 5, 2018, at 4:46 PM, John C Klensin <[email-masked]> wrote:
> 
> _______________________________________________
> Mtgvenue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mtgvenue

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Feb 2018 09:52:38 -0500

--On Tuesday, February 6, 2018 21:28 -0500 Alissa Cooper
<[email-masked]> wrote:

> Hi John,
> 
> I agree with you that there is a relationship between the two
> documents, although it's not clear that it's a normative
> one. I've pulled
> draft-ietf-mtgvenue-iaoc-venue-selection-process from this
> week's IESG telechat to provide time to process
> draft-ietf-mtgvenue-meeting-policy and make some of the other
> changes to venue-selection-process that have surfaced in the
> recent threads.

Alissa,

Thanks.  After reading Pete's note and those of others, I'm not
completely sure about the normative relationship either.  My
major concern is the one you've dealt with -- the opportunity to
see these documents as part of the same context and comment on
any potential gaps or conflicts.

  best, 
    john