Subject: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08

From: Pete Resnick <[email-masked]>
Date: Fri, 4 Aug 2017 17:36:15 -0500

Greetings,

This message begins a 3-week Working Group Last Call on version -08 of:

https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

The chairs feel we've gotten all of the known open issues addressed:

https://github.com/elear/mtgvenue/issues

The only "issue" we've left open is really a placeholder for a review 
we're soliciting from the secretariat.

If you haven't read the document in a while, please do so and send your 
comments. At this stage, problems with the document are more important 
to hear than, "Looks good to me". However, do look through the closed 
issues to see an issue you're bringing up has already been addressed by 
the WG:

https://github.com/elear/mtgvenue/issues?q=is%3Aissue+is%3Aclosed

Barring new issues (or ones that cannot be quickly addressed), the 
chairs plan to submit the document to the IESG after August 25. Please 
try to do your reviewing sooner rather than later.

Thanks,

Pete & Charles

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Aug 2017 08:48:18 +1200

Unfortunately it seems to me that although text changes were made in
response to issue #20, many of the instances of 'IAOC' that should have
been changed to 'IASA' at the same time were not actually changed.
For example the Introduction starts thus:

   The IAOC has responsibility for arranging IETF plenary meeting venue
   selection and operation.  The purpose of this document is to guide
   the IAOC in their selection of regions, cities, and facilities, and
   hotels.  The IAOC applies this guidance at different points in the
   process in an attempt to faithfully meet the requirements of the IETF
   community.  We specify a set of general criteria for venue selection
   and several requirements for transparency and community consultation.

and in the spirit of issue #20 that should be

   The IASA has responsibility for arranging IETF plenary meeting venue
   selection and operation.  The purpose of this document is to guide
   the IASA in its selection of regions, cities, and facilities, and
   hotels.  The IASA applies this guidance at different points in the
   process in an attempt to faithfully meet the requirements of the IETF
   community.  We specify a set of general criteria for venue selection
   and several requirements for transparency and community consultation.

(The whole point of this change was to make the document as robust as
possible, whatever changes the IASA 2.0 process leads to.)

If the WG agrees with this, I'll gladly mark up the whole document
accordingly, or even edit the XML.

Regards
   Brian

On 05/08/2017 10:36, Pete Resnick wrote:
> _______________________________________________
> Mtgvenue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mtgvenue
>

---

From: Pete Resnick <[email-masked]>
Date: Mon, 21 Aug 2017 17:39:04 -0500

[Sent from wrong address; apologies if you receive a duplicate]

Seeing no response to this, my inclination is to have you send the 
markup and Eliot can yelp if something looks amiss.

Looking forward to more comments this week folks.

pr

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Aug 2017 11:46:00 +1200

If Eliot can authorise me (becarpenter) in github I can send a pull request
with my proposed edits to the XML. Otherwise we can do it the old-fashioned
way...

Also, I noticed some more nits:

1) The draft uses three different terms: Meetings Committee,
Meeting Subcommittee, Meeting Committee. I think we should pick one.

2) The RFC Editor will be picky about several abbreviations
being used before defined (including IASA and IAOC).

Regards
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Aug 2017 07:27:32 +0200

Hi Brian,

First, thanks for your detailed read.  Let me address both of your

> possible, whatever changes the IASA 2.0 process leads to.)

I agree, and it was an oversight in the previous version.  I've
corrected for -09, not having heard any objection.

> Meeting Subcommittee, Meeting Committee. I think we should pick one.

Corrected in -09.

> being used before defined (including IASA and IAOC).

I've done a scrub for this for -09.

Thanks again,

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Aug 2017 08:40:39 +1200

On 22/08/2017 17:30, Eliot Lear wrote:
> Brian,
> 
> Please see attached for comparison.  Please if you could post any
> additional changes you would like to the WG in the next day or so.
> 
> Eliot

Eliot,

OK, since you asked. Once again: the point here is not to change reality,
but to make the document as far as possible robust against changes to
the current structure of IASA. When I orginally said that IMHO most
instances of "IAOC" should be replaced by "IASA" I meant it. The sections
concerned as I would like to see them are below. The intention is that
the IAOC is mentioned only where oversight and approval is directly
involved. Everything else is IASA as a whole, which of course includes
the IAOC.

If you send me the latest xml or post it in github, I will volunteer to
make the updates.

Regards
    Brian

3.1.  Mandatory Criteria

   If criteria in this subsection cannot be met, a particular location
   is unacceptable for selection, and the IASA MUST NOT enter into a
   contract.  Should the IASA learn that a location no longer can meet a
   mandatory requirement after having entered into a contract, it will
   inform the community and address the matter on a case by case basis.

...

3.2.  Important Criteria

   The criteria in this subsection are not mandatory, but are still
   highly significant.  It may be necessary to trade one or more of
   these criteria off against others.  A Venue that meets more of these
   criteria is on the whole more preferable than another that meets less
   of these criteria.  Requirements classed as Important can also be
   balanced across Venue selections for multiple meetings.  When a
   particular requirement in this section cannot be met, the IASA MUST
   notify the community at the time the venue is booked.  Furthermore,
   the IASA is requested to assist those who, as a result, may be
   inconvenienced in some way.

...

   Participants have a responsibility to express their views about
   venues early and often, by responding to surveys or other
   solicitations from the IAD or IASA, and by initiating fresh input as
   the Participant becomes aware of changes in venues that have been
   reviewed.  This permits those responsible for venue selection to be
   made aware of concerns relating to particular locations well in
   advance of having entered into contract discussions.

...

4.3.  The Internet Society

   With respect to IETF meetings, the Internet Society (ISOC):

   o  Executes all Venue contracts on behalf of the IETF at the request
      of the IASA

...

4.4.  IETF Administrative Oversight Committee

   The IETF Administrative Oversight Committee (IAOC) has the
   responsibility to oversee the selection of IETF meeting venues.

...

4.6.  IETF Administrative Director

   The IETF Administrative Director (IAD) coordinates and supports the
   activities of the IETF Secretariat, the IASA Meetings Committee and
   the IASA to ensure the timely execution of the meeting process.  This
   includes participating in the IASA Meetings Committee and ensuring
   its efforts are documented, leading Venue contract negotiation, and
   coordinating contract execution with ISOC.  The meetings budget is
   managed by the IAD.

4.7.  IASA Meetings Committee

...

5.  Venue Selection Steps

   The following sequence is used by the IASA to select venues.  Unless
   otherwise stated below, the IASA may evolve these steps over time
   without updating this document.

5.1.  Identification

   Four years out, a process identifies cities that might be candidates
   for meetings.  For example:

   a.  The IASA selects regions, cities, and dates for meetings.

...

5.2.  Consultation

   The IASA MUST consult the community about potential new venues prior
   to them being booked.  The timing and means by which it does so may
   vary over time, but MUST include references to any notable travel
   risks.  The consultation may overlap with the previous step
   (identification).

   For example:

   a.  The IASA asks the community whether there are any barriers to
       holding a successful meeting in any of the target cities in the
       set.

   b.  Community responses are reviewed and concerns investigated by the
       Meetings Committee.  The results together with recommendations
       for whether each city should be considered as potential meeting
       location is provided to the IASA.

   c.  The IASA identifies which cities are to be considered as a
       potential meeting location.

   d.  On a public web page, the IASA lists all candidate cities, when
       community input was solicited, and if a city is to be considered
       as a potential meeting location.

...

5.5.  Late Changes

   If at any time after a contract is signed the IASA learns
   circumstances have changed such that it is not certain that Important
   or Mandatory criteria can be met by a Venue, the IASA MUST reconsider
   the selection.  A description of how reconsideration currently takes
   place is found in Appendix B.  The IASA will gauge the cost of making
   a change against the ability of the IETF to conclude a successful
   meeting, and make a final determination based on their best judgment.
   When there is enough time to do so, the IASA is expected to consult
   the community about changes.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Aug 2017 23:03:54 +0200

Hi Brian,

Thanks.  I've taken  all of your changes but one class: I don't think it
would be accurate to call the meetings committee the "IASA meetings
committee".  As documented, it is appointed by the IAOC, and not by "The
IASA".  Otherwise we would have to go through this same substitution and
a consolidation with "IAD".  As there is no normative requirement on the
meetings committee leaving this text shouldn't really make a difference
even after IASA 2.0.  Furthermore, the intent is not to codify the
IAOC's subcommittee structure, but simply to mention it informatively. 
I can make that clearer if you like.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Aug 2017 10:15:39 +1200

> I can make that clearer if you like.

Thanks Eliot, I can certainly live with that. I think that with these
changes the document will be robust enough to last for a long time.

Regards
    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Aug 2017 17:54:13 -0400

Hi,

Though just under the wire, I have read -08.  I think it is in pretty
good shape.  I still have some comments, but I think they're mostly
easy to deal with and this document could probably go to IETF LC
without addressing any of them.  Thanks to everyone who has worked to
get the document this far along.

Below are my comments.

I note that the definitions define IETF Hotels, and that the
definition includes using the IETF SSIDs.  But later, in the
description of the value of Internet Access, there's a mention of
"overflow hotels", which of course don't meet the definition of IETF
Hotels, and Overflow Hotels are listed in the Hotel needs.  Perhaps
this definition helps:

    Overflow Hotels:
        One or more hotels, usually in close proximity to the Facility,
        where the IETF has negotiated a group rate for the purposes of
        the meeting.  Of particular note is that overflow hotels usually
        are not connected to the IETF network and do not use IETF SSIDs.

Also in the Internet Access section, there is this bit:

    We seek to avoid such locales without reducing
      the pool of cities to an unacceptable level by stating a number of
      criteria below, one mandatory and others important, to allow for
      the case where local laws may require filtering in some
      circumstances.

It's not clear to me how that claim forms part of a core value, so
perhaps it ought to be removed.

I continue to be a little nervous about some mandatory criteria.  To
begin with, there's this:

   o  The Facility MUST be assessed to be able to provide sufficient
      space in an appropriate layout to accommodate the expected number
      of people to attend that meeting.

In my reading, this says not that the Facility has to have enough
rooms in an appropriate layout, but that it has to be "assessed" that
way.  I fear the passive construction tends to encourage motivated
assessments.  I don't get what is wrong with "The Facility MUST
provide suffucuent space in an appropriate layout to accommodate the
expected number of people to attend, and the expected simultaneous
sessions at, that meeting."  I don't feel super strongly about this
one, however, and I could live with the existing language.

   o  The venue MUST provide unfiltered access to the Internet, to the
      extent permitted by governing laws and regulations.

In my reading, this says that we have to have unfiltered access except
when we can't.  That's not a mandatory requirement at all, and if
that's what we mean then it ought to be moved to Important.  If it
changes that way, I'd suggest this wording instead:

    o The Venue provides unfiltered or minimally filtered access to
    the Internet in the interests of local government policy and to
    the extent permitted by governing laws and regulations.  Any
    degree of mandatory filtering is to be considered problematic.

But I think anyway that isn't the community expectation.  I think the
expectation is that, if the jurisdiction requires large-scale
filtering or other modification of the allowable connections, then it
is not a permissible Venue.  I am aware that this stronger version of
the requirement might mean that places where we claim to have had
successful meetings could not be considered again.  I suggest that
either means that the criterion as written is not really Mandatory, or
else that we have defined "successful meeting" more selectively than
perhaps we ought to have done.

In section 3.2, the IAOC (or I guess the IASA, following Brian) "is
requested to assist those who, as a result, may be inconvenienced in
some way."  But the first criterion is acceptable time and money for
travel.  I worry that the "requested to assist" language could create
an expectation that the IASA is going to rebate people for travel
expenditure or something.  Perhaps instead it could say, "In some
cases, it may be appropriate for IASA to attempt to mitigate
individial inconvenience caused by IASA's selection."  This gives the
freedom to mitigate without some expectation.

I'm a little surprised, in 3.2.3, to find both support technologies
and services, and the IETF Network, to be Important rather than
Mandatory.  I'm trying to imagine a trade-off where we say, "Yep, we
just can't get network|enough projectors|microphones," and yet we
would be willing to sign an agreement with that venue.  It seems like
a disqualifier.  I am aware of the irony that I should be the one
suggesting something ought to be Mandatory, but maybe these two were
downgraded too quickly.  The hotel and guestroom network is pretty
clearly Important, at least historically, though I will note that the
NOC seems to have to make heroic efforts every time the guest room
network is bad.

In section 5.1, I find this sentence to be surprising:

   for meetings.

Surely what we mean is that some person or group of people identifies
the cities, probably by running through some process.  Normally I
would probably find this sort of locution merely ugly, but I think
that part of what got this WG going was some dissatisfaction in the
community about who did what and why, so I'd prefer not to make this
the responsibility of some process.  I don't feel super strongly about
this item, and can live with the existing language, but it'd be nice
to fix it.

5.4 a says "Only options that meet all Mandatory labeled criteria
might be recommended."  Maybe this could be clearer as "The Meetings
Committee MUST NOT recommend an option unless it meets all Mandatory
criteria"?

NITS:

Section 3.2: "than another that meets less…" s/less/fewer.

There are a few places where the document uses "Venue environs".  I
think this is confusing: if Toronto were the Venue, then Hamilton
would meet the term "Venue environs" even though it's about an hour
away.  This is probably either Facility environs or just Venue.  I
suspect the former is what's meant.

I think this sentence needs to be fixed (I think the i.e. has somehow
broken the syntax):

   It is desirable to enter into a multi-event contract with the
   Facility and IETF Hotels to optimize meeting and attendee benefits,
   i.e., reduce administrative costs and reduce direct attendee costs,
   will be considered a positive factor.

maybe

   It is desirable to enter into a multi-event contract with the
   Facility and IETF Hotels in case such a contract will either reduce
   administrative costs, reduce direct attendee costs, or both.

> https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Aug 2017 15:30:57 +0200

Hi Andrew,

Thanks for your comments.  Please see below:

>         are not connected to the IETF network and do not use IETF SSIDs.

So added.
> perhaps it ought to be removed.

I think we have been back and forth on this, and I need to hear from
others.  Perhaps we need to reword this along the lines of, “because we
like to test out our own systems, and because we need to securely stay
in contact with customers, partners, and companies, we seek unfettered
access to the Internet.  The more a Venue uses filtering,  the less
attractive it will be to the IETF."

???

> one, however, and I could live with the existing language.

Ok.

> perhaps we ought to have done.

I am neutral on this, but do need to hear from others in order to
recommend how to best proceed.

> freedom to mitigate without some expectation.

How about this:

Furthermore, it may be appropriate for the IASA to assist those who, as
a result, have been inconvenienced in some way.

> NOC seems to have to make heroic efforts every time the guest room

I would have no problem adding this as a mandatory as long as it is
clear enough as to what it is, but others should be agreed on this point.

> this item, and can live with the existing language, but it'd be nice

What would you like in its place?  If the issue is the word "process",
we can point to the Meetings Committee or IAD or IASA, but that strikes
me as equally vague.

> Committee MUST NOT recommend an option unless it meets all Mandatory
I'm okay with that except hat I'd rather not use the normative language
in order to be more specific about the Meetings Committee versus the
IASA (so I use "will not").

> Section 3.2: "than another that meets less…" s/less/fewer.

Fixed.

> suspect the former is what's meant.
Facility environs.
>    administrative costs, reduce direct attendee costs, or both.
Ok!  Will take.

Thanks again,

Eliot

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Aug 2017 16:00:07 +0200

Regarding the filtering text … and also other mandatory requirements.

As I already mention some time ago, if we have a venue that may qualify, but we get too strict with what is mandatory, then we may be missing a lot of venues that have worked already for us in previous occasions and others that may work.

The on-site survey team has the right expertise to assess that and then inform the meetings committee, which in turn will provide his view to the IAOC.

So, in my opinion, the ideal will be to have somehow a text that instead of mandatory means that in case of discrepancies with our “meetings spirit” or “limit situations”, the IAOC will consult the community.

In section 5.1, instead of process, maybe “on-site survey team”? This is a very well stablished process which proven to be efficient. You may want to read the intro (and may be also section 12 & 13) in my document https://datatracker.ietf.org/doc/draft-palet-ietf-meeting-network-requirements

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Eliot Lear <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 28 de agosto de 2017, 15:31
Para: Andrew Sullivan <[email-masked]>, <[email-masked]>
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08

    Hi Andrew,

    
    So added.

    ???

    Ok.

    
    
    How about this:

    

    
    
    Fixed.
    
    Facility environs.
    Ok!  Will take.
    
    Thanks again,
    
    Eliot

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 11:42:11 -0400

> attractive it will be to the IETF."

That'd be fine with me.

> >       extent permitted by governing laws and regulations.

[…]

> recommend how to best proceed.

I don't have a real strong feeling about how it is changed, but I
really don't think we can have a Mandatory criterion of the sort that
is currently there, just because it isn't actually Mandatory at all. 

> a result, have been inconvenienced in some way.

WFM.

> we can point to the Meetings Committee or IAD or IASA, but that strikes

I don't think it's equally vague: someone is making a decision, and we
just have to say who it is.  That's actually what I'm mostly worried
about: saying "a process" decides this suggests that it rolls on
regardless of what the humans want.  That seems to be exactly the
feeling that caused the controversy that got this WG formed :)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 11:58:12 -0400

Hi Jordi,

> As I already mention some time ago, if we have a venue that may qualify, but we get too strict with what is mandatory, then we may be missing a lot of venues that have worked already for us in prev…

In my reading, "Mandatory" just means that, if the criterion isn't
met, then the site does not work, period.  For sites that "have
worked" but that don't meet the Mandatory criteria in the document
(whatever that comes out to be), there are only three possibilities:

    1.  The Venue didn't actually work in fact.  That is, people put
    up with the failure, but the meeting was in some way harmed by
    that missed criterion such that it was not in fact successful.

    2.  The criterion isn't actually Mandatory at all.

    3.  The Venue has changed such that the Mandatory criterion is not
    met.

The most obvious example of (3) would be if, say, the Facility closed
or was modified or torn down.  Reportedly this has happened to the
Facility we used in Stockholm last time, so there aren't the rooms we
need now.  Therefore, even if one thinks we had a successful meeting
there (I do), we can't have one again.  By the same token, the IASA
appears to have decided that San Francisco misses or risks missing a
criterion (probably one of the ones in 3.2.1 of -08) such that it was
better to move the meeting.  (By the way, if anyone involved did in
fact report back, as someone suggested, about the decision making in
that case, I missed it.  There's still time!)

I don't believe that any criterion that is actually Mandatory permits
flexibility in evaluation.  Obviously, it permits error.  (e.g. Maybe
the people making the decision _think_ that we are going to get 800
people, and we get 1800: that'd be disastrous for room sizes and
numbers, but nobody would have failed to apply the criteria.)  I can't
tell, therefore, whether you are arguing that the -08 draft has the
settings wrong and that some things that are Mandatory should not be,
or whether you are arguing that the definition of Mandatory is wrong.
For what it's worth, I don't believe the definition is wrong and I
would probably argue strongly against some attempt to alter the
definition.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Aug 2017 18:23:33 +0200

Hi,

>> attractive it will be to the IETF."

Are there any objections to this?

> is currently there, just because it isn't actually Mandatory at all. 

I got that.  Ted, can you comment since I think you came up with the
language in the draft?  The alternatives are:

  * demote the text.
  * reword the text.

I think Andrew is properly capturing a concern.  It could be that the
right thing to do here is to get more specific about what sort of
filtering we are willing to put up with.

Ok.
> feeling that caused the controversy that got this WG formed :)

I've used "IASA".  If anyone has objections, please speak up.

Eliot

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Aug 2017 18:26:42 +0200

I missed an “if”:

if we have a venue that may qualify, but IF we get too strict with what is mandatory

Obviously, number 3 in your possibilities, is a case for a venue to be excluded, even if it worked before. But I can see venues that may fail if we have mandatory items and if the on-site-survey team and the meeting committee/IAOC can have some degree of judgement, can keep working. So I’m saying that we should try to avoid any mandatory criterion (your possibility 2).

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Andrew Sullivan <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 28 de agosto de 2017, 17:58
Para: <[email-masked]>
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08

    Hi Jordi,

    

    

    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Aug 2017 18:29:13 +0200

Hi Jordi,

I agree that the team do a pretty good job on this issue without anyone
actually saying anything.  Put another way, it hasn't really been the
painpoint.  In that sense, this might argue to demote the requirement to
"Important" and continue to trust the judgment of people like Jim.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 13:09:51 -0400

> Obviously, number 3 in your possibilities, is a case for a venue to be excluded, even if it worked before. But I can see venues that may fail if we have mandatory items and if the on-site-survey te…

Does this mean that you think the Mandatory criteria for enough
meeting rooms of the right size and capacity, and the requirement for
wheelchair accessibility, are both possible to trade off?

To be plain, I think at least the first of these is necessarily
Mandatory (i.e. we literally can't have a meeting if that criterion
isn't met), and I think the second of these ought to be Mandatory
(i.e. we just won't go anywhere if someone requiring a wheelchair
can't get in).  I think these are not cases where compromise is
allowed.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Aug 2017 19:42:50 +0200

Yes, for the wheelchair accessibility, not for the meeting rooms, if we put that in the extreme case and let me explain that.

Let’s suppose that a couple of the meeting rooms are smaller than what we actually require, but there are double of them and they are connected with a built-in audio-video system which allows to execute the meetings with the same results, just different “setup”. Should that exclude a venue?

I think in many cases we may find alternatives that work for us, and if we have them as mandatory, we will exclude them, not giving the chance to the IAOC or even community to think twice.

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Andrew Sullivan <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 28 de agosto de 2017, 19:10
Para: <[email-masked]>
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08

    
    
    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 13:50:16 -0400

> Let’s suppose that a couple of the meeting rooms are smaller than what we actually require, but there are double of them and they are connected with a built-in audio-video system which allows to ex…

That doesn't sound like "not enough meeting rooms".  That sounds like
"unusual layout".  At least to me.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Aug 2017 14:01:29 -0400

Andrew Sullivan <[email-masked]> wrote:
    >> Let’s suppose that a couple of the meeting rooms are smaller
    >> than what
    >> we actually require, but there are double of them and they are
    >> connected with a built-in audio-video system which allows to execute

I haven't seen this work well yet.

    > "unusual layout".  At least to me.

IETF99, Karlin I/II, the one with the pillar in the middle of the room.
Effectively, half the room was invisible to the chairs and vv.

The room was effectively half the size; it was annoying.  Unuseable, no, but
I'd rather have used the room space differently.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 14:03:31 -0400

> I'd rather have used the room space differently.

Sure, but does that move "enough meeting rooms" judgement from
"Mandatory" to "Important"?  Or do you think that disqualifies that
venue?  These are the questions we must answer.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Aug 2017 11:06:01 -0700

> On Aug 28, 2017, at 10:09 AM, Andrew Sullivan <[email-masked]> wrote:
> 

I don't disagree. Where I scratch my head is the actual process of selecting a venue. If everything is locked down - "do this or else" - we may have no viable choices. If we can widen by making one requirement optional, we may add a few, and if we make two requirements optional, we may add more.

What seems to me a lot more sensible would be to ask the survey team to report on the proposed venue - "does it have X, Y, and/or Z?" - and then ask the IAOC to make a judgement call. If the requirement is to position a meeting in some location and it can only be done by waiving this requirement or that, give them the respect of trusting their judgement.

Which makes most of these things "important", not "mandatory". If we simply don't have the facilities, I think their judgement will say "let's not go somewhere that the meeting can't actually occur". As to the rest of it, the reason the community selects them is because we think they have the kind of judgement that can be trusted with that. If that is not true, trying to codify this like writing code is a waste of effort.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Aug 2017 20:06:59 +0200

It was just one example (we can consider it as you said as unusual layout or an individual meeting room size). I think our actual text will not exclude that. What I’m trying to say is that making things mandatory we are closing our opportunities and having extra walls that we can’t cross unless we change the document before taking a decision if it happens, because we not necessarily realize that there are alternative options and somebody (human), could take a different decision that what we have in a document if it already says “must”.

May be one possible way out is to have some text that allows the IAOC, even if consulting the community, to jump over some of the mandatory criteria if the on-site-survey or the meetings committee have identified a venue which will fulfill our needs but a literal interpretation of this document disallows it.

The point is an RFC with “must” may not be the best way to choose venues …

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Andrew Sullivan <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 28 de agosto de 2017, 19:50
Para: <[email-masked]>
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08

    
    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 14:50:21 -0400

> What seems to me a lot more sensible would be to ask the survey team to report on the proposed venue - "does it have X, Y, and/or Z?" - and then ask the IAOC to make a judgement call. If the requir…

This is precisely why I was arguing early for reducing the number of
Mandatory items.  But we're down to three now, with a possible fourth
and a possible reduction of a third.  The current one that nobody
seems to object to is "wheelchair accessible".  The one that Jordi
seems to object to is "enough rooms in appropriate number and size".
The one that I objected to in its phrasing was "unfiltered Internet
except where that's not allowed".  And the one I suggested maybe has
to be Mandatory is "can provide the needed AV and Internet
connectivity support".

It seems obvious to me that we could decide to go somewhere and accept
some sort of Internet filtering (indeed, while there was a lot of
noise when we went to Beijing, people seem to have acceeded to the
UK's IMO odious rules without a lot of comment).  So, to me, this is a
judgement the community has to make about whether it will permit IASA
to make those calls in the future.

It seems obvious to me that we could in fact go somewhere that
wheelchairs can't get to, and equally obvious that it would be wrong
to do so.  Therefore, I think this is a judgement the community
appears to be making about whether it will permit IASA to trade such
accessibility against other factors.  The current document says no.

It also seems obvious to me, however, that if we don't have enough
rooms of the right size, or if we can't get the AV or Internet
connectivity support we need, then either the Facility or the Venue is
disqualified.  It might be a matter of judgement about whether the
Facility is quite right -- e.g. some might feel rooms are slightly too
crowded because there aren't any empty chairs -- but if one can't even
make an argument that there are enough rooms, then we can't have the
meeting there.  Similarly, if we just can't run circuits in (or
they're going to cost 100s of thousands of dollars), then it's not a
possible Facility no matter what.  I am trying to understand what the
judgement call is supposed to be in those cases.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Aug 2017 15:54:08 -0400

Andrew Sullivan <[email-masked]> wrote:
    >> The room was effectively half the size; it was annoying.  Unuseable,
    >> no, but I'd rather have used the room space differently.

    > venue?  These are the questions we must answer.

I would not have counted Karlin I/II as a ~100 person room, but rather
two 50 person rooms.  Would the hotel have other rooms that could accomodate?
Probably.  Would many of the WGs have fit into a 50 person room? Probably.

As arranged was this room accessible?  My opinion is no, btw.
Could it have been?  Probably.

I've often suggested that we put 30% fewer chairs in most rooms, spacing
them out enough so that all chairs can actually be used, and providing 20
stacked overflow chairs for when it's really busy.

None of these comments really matters to this document; it's all
implementation details.  I have no idea how to capture these thoughts.
We have many other such experiential information.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Aug 2017 13:17:58 -0700

This is the substance of my question regarding much of the discussion in this working group. The topic is selecting a venue. There might be value in a document discussing the arrangement of chairs at a venue, and in that context I'd welcome the discussion; this isn't it. I honestly don't think I would ask the IASA/IAOC to make a determination on Prague based on Karlin I/II; I might make a note to the IAD suggesting that this meeting room arrangement has issues and should not be considered a 100 person room. The comment I would make on Prague, and on the Hilton specifically, is that we have had four very successful meetings there.

> On Aug 28, 2017, at 12:54 PM, Michael Richardson <[email-masked]> wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2017 19:38:18 -0400

On Mon, Aug 28, 2017 at 01:17:58PM -0700, Fred Baker wrote:
>  The comment I would make on Prague, and on the Hilton specifically, is that we have had four very successful meetings there.
> 

I think the point I was trying to make is that these corner cases tell
us whether something really is Mandatory.  In the case of Prague, what
I understand is that the hotel as it stands only barely just
accommodates us according to how we run the meetings now.  I think
what that means is that, if we were to change in some important way
how we run meetings (say, we attracted 250 more people and had to run
one more parallel track), there'd be a simple fact about Prague: no
matter how successful previous meetings were there, it would no longer
work as a Facility because it just wouldn't have the space we need.
That's what it means for something to be Mandatory.

I can't tell whether you agree or disagree from what you wrote.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Aug 2017 13:11:08 +1200

> I can't tell whether you agree or disagree from what you wrote.

So, we can't possibly meet in a place that's too small.
We can't possibly meet in a place without wheelchair access
to the meeting rooms.
We can't possibly meet in a place without unfiltered access to the Internet, to the
extent permitted by governing laws and regulations.

An IASA that decides to meet in such a place has failed in its job, and an IAOC
that lets such a choice go through has failed to provide oversight.

I really don't see where the text needs wordsmithing.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Aug 2017 00:13:39 -0400

Andrew Sullivan <[email-masked]> wrote:
    >> The comment I would make on Prague, and on the Hilton specifically, is
    >> that we have had four very successful meetings there.

    > accommodates us according to how we run the meetings now.  I think what
    > that means is that, if we were to change in some important way how we
    > run meetings (say, we attracted 250 more people and had to run one more

I agree with you.
I agree there for that "having enough space" is mandatory.
(But there is a lot of leeway in that decision, and we have to trust the IAOC here)

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Aug 2017 06:56:18 +0200

Brian,

If an SP performs BCP38 filtering on us, does that mean we can't go
there?  What if they block port 25 outbound to manage spam?  What if
they block inbound connections, except when requested not to?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Aug 2017 17:55:54 +1200

> they block inbound connections, except when requested not to?

I don't get your point. I'm supporting the current text, which
requires unfiltered access. (I don't see an issue with BCP38 filtering,
because IETF participants shouldn't be forging source addresses,
but I don't think that's intended to be covered by the text anyway.)

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Aug 2017 10:21:42 +0200

Brian,

I made that reply by trying to test if there is a way that we can
sharpen the text to be more specific, so that we can find agreement
between you and Andrew.  It could be that the text there is the best we
can do.  It may be that I've started with a bad example, but the text in
the draft hasn't really sat well with me either, precisely because there
may be some jurisdictions that go Too Far.  Defining what Too Far is,
however, is difficult.

And so... another approach we could take would be along the lines of...

> "Internet service to the Facility and IETF Hotels MUST NOT require
> exposing of any communications between participants and each other or
> their customers and partners.  The IASA MUST  determine that Internet
> service would be unlikely to interference communications between
> partners and each other or their customers.  To facilitate this
> requirement, the IASA SHOULD consult with participants from time to
> time on this matter."

This gets us away from legalities and back to practicalities.  It might
cause problems with certain countries, and might require additional
arrangements with others.  But I think the community does seek
approaches that lean towards openness, while also allowing for some
inconveniences.  Remember: the bar for MUST is that we could not have a
successful meeting if the requirement isn't met.

Some tests:

  * A number of countries prohibit VoIP.  Are they intended to be
    immediately off the list?  I'm thinking of UAE in particular.
  * At least one country might require additional accommodations.  I'm
    thinking of China, as happened the last time.
  * Some jurisdictions may require record keeping and end user
    identification.  Is that something we can live with?  Our
    requirements don't talk about that, by the way.

And so now looking the lens of a MUST:

  * It's murky at best as to whether we can hold a successful meeting
    without VoIP.  Probably not because of remote participation.  The
    current text doesn't really speak to that, but I imagine that Jim is
    probably looking askance at that requirement.
  * IMHO we CAN hold a successful meeting if we maintain records as to
    who used the network.
  * IMHO we would be at risk at losing a great many participants if they
    could not communicate with partners or each other in a secure way,
    but we CAN hold a successful conference if someone catches metadata
    (not that we'd like it).  We could probably ALSO hold a successful
    meeting TODAY if someone blocked access to well known ToR exit
    nodes, but I don't know if that will always hold true.

Sorry for dragging us through this, but as I wrote above, I think the
text there isn't quite right, and I'm somewhat agreeing with Andrew's
point, and striving to find a way forward.  All of this having been
said, if the text in the draft is the best we can do, then I guess we
keep it.

Eliot

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Aug 2017 09:27:18 +0100

> On 28 Aug 2017, at 18:09, Andrew Sullivan <[email-masked]> wrote:
> 

Agreed.

Would every venue we have already been to pass the Mandatory criteria set down in the draft?  It would be interesting to see some worked examples of how some previously commonly used venues tick (or don’t tick) against all the criteria.

Presumably, the selection process would document and record whether a future venue met each criteria, and that record would be public to IETF participants?

Tim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Aug 2017 10:38:30 +0100

Hiya,

>     thinking of China, as happened the last time.

In that case the IETF did not change the meeting network to match
the usual local situation. (Just pointing that out in case we don't
remember that aspect, but we don't need to rehash details I hope.)

>     nodes, but I don't know if that will always hold true.

I'm not sure I agree entirely with any of those. Purely considering
whether we can have *one* successful meeting with an abnormal (for
us) network is not the right model IMO, as such constraints tend to
accumulate over time, once introduced, as do their downsides and the
associated disincentives to participation.

As to the overall point, I (as always) don't like the MUST category
requirements at all - the key thing is that the IASA/IAOC properly
involve the community in any significant deviations from the nominal
case. But I'm not now arguing to get rid of 3.1. I will however
argue that it is that last aspect (consultation) that needs the MUST.

So, I'd suggest a this change:

In section 3, (intro), add something like this:

   When any significant requirement in this section (or that
   becomes accepted by the community over time) cannot be met
   by a planned venue, the IAOC MUST properly consult with the
   community as to how to handle the situation, and such
   consultation MUST happen at the earliest opportunity.

In section 3.2, remove this:

   When a
   particular requirement in this section cannot be met, the IAOC MUST
   notify the community at the time the venue is booked.

And just in case: If someone wanted to argue (as in the quoted text
above) that the IASA/IAOC only "SHOULD" consult the community about
a possible meeting in a country with significant Internet censorship,
then that'd cause lots of LC fuss I suspect, and for the record, I'd
be strenuously against such a SHOULD statement.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Aug 2017 12:26:45 +0200

Hi Steven,

A caution about this email: it's perfectly possible for this document
NOT to close.  Ever.   For that reason I'm asking that we not relitigate
the mandatory/important argument again, and that we keep the scope of
our discussion to just the Internet filtering requirement.

> remember that aspect, but we don't need to rehash details I hope.)

We had an arrangement with CERNET to allow for this, as I understand
it.  That's the sort of accommodation was thinking of.

> associated disincentives to participation.

The point I was trying to make was that the requirement doesn't quite
match up with either existing practice or what we want, and would not
require the consultation, thus obviating the text in your change.  The
first example was meant to demonstrate this.  Similarly, the existing
text might prohibit certain forms of filtering that we would find
perfectly reasonable.  Why?  We said so in places like BCP 38.

I'm not wedded to the proposal I made.  I can live with the text that is
in the draft, although I have to believe that Meetings folk will go well
beyond it in addressing the community's needs, and maybe that's just
okay.  Alternatives would be fine as well.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Aug 2017 11:30:22 +0100

On 29/08/17 11:26, Eliot Lear wrote:
> the mandatory/important argument again, 

Good job I didn't do that then:-)

> and that we keep the scope of

My suggested change was simply to make it a MUST that the
IASA/IAOC consult the community before weird arrangements
are entered into. I wasn't asking to change the text in 3.1
otherwise, and the change in 3.2 would simply remove some
redundancy if we added the text I suggest to the intro of
section 3.

Cheers,
S.