[Mtgvenue] can we make an RFC for the venue selection process?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 02 May 2017 17:37 UTC

Return-Path: <prvs=1295ecb3a4=jordi.palet@consulintel.es>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6734124D6C for <mtgvenue@ietfa.amsl.com>; Tue, 2 May 2017 10:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Umct4pYKLU8y for <mtgvenue@ietfa.amsl.com>; Tue, 2 May 2017 10:37:08 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5132D127871 for <mtgvenue@ietf.org>; Tue, 2 May 2017 10:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1493746428; x=1494351228; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=N5QV3Kjk3zhunLrQV4FWKWi+3xqdS8OeRpjS13+sLbc=; b=Hi3NMdqVJbR7w a422vwao7O2cB1ZkmCIH03p3ud9IXNF+YZ9IMvWWgbdKnU7PISrk/Q+ByBLXie/B O4Dcli14OqByV+FzSUcwqZDrmHaTR2vpTQHHlEcxk9x4zpcb0d/NHhNzjC6CTPg6 sCPuSxZn4RW0V2EtmoOD+SAHnBQUPs=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=CVt2CANse7sqEhKbIJqxmt0g7qjHMzYayCENMNxusnURoHNbEzl6m+dtXT1l MERRnYTXtR623BwurcSUmpK1FdF4+VunB4hL1nt179QnvNrNFBRlwkGQ6 M9RExslB6l0dh9TjR3Q0/t2/BSYTMjhaibtnmQU5mDngDK6HvDnU8I=;
X-MDAV-Processed: mail.consulintel.es, Tue, 02 May 2017 19:33:48 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 02 May 2017 19:33:48 +0200
Received: from [10.10.9.148] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005419737.msg for <mtgvenue@ietf.org>; Tue, 02 May 2017 19:33:47 +0200
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170502:md50005419737::XEKEXQkDhDW50r6w:00000nvn
X-Return-Path: prvs=1295ecb3a4=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: mtgvenue@ietf.org
User-Agent: Microsoft-MacOutlook/f.21.0.170409
Date: Tue, 02 May 2017 19:33:43 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: mtgvenue@ietf.org
Message-ID: <52FC6A53-E129-4FC0-8D62-62BAD74252AC@consulintel.es>
Thread-Topic: can we make an RFC for the venue selection process?
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/4chUv6kLTfNMbrAEDWJNlIw9CqY>
Subject: [Mtgvenue] can we make an RFC for the venue selection process?
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2017 17:37:11 -0000

Hi all,

During all last week, I’ve participated in a very interesting experience that I believe is important to share with this WG.

I was assisting the AMS/NOC team in the survey of 8 different venues (plus a few overflow hotels) in a couple of cities.

Before that, I’d already a lot of ideas of what are our needs, and in fact, I worked in draft-palet-ietf-meeting-venue-selection-criteria-04, and of course, I’m following this list and the meetings.

However, actually participating in the process I feel that we are getting wrong draft-ietf-mtgvenue-iaoc-venue-selection-process-06.

I wish that all the contributors in this effort actually have the opportunity to participate in this activity (on-site venue survey) before actually contributing to the document in a way that it works. Believe me, it will be useless if we approve a document that is not based in REAL EXPERIENCE. Moreover, I did the exercise of trying to “pass” venues where we had successful meetings, and only a couple of them, in the last years, actually worked.

Again, I’m not talking about “theoretical”, but what I’ve seen in the IETF meeting, as I started participating in London 2001 and since then I’ve been in all them, not missing any, so I’ve been able to see in my own skin what it worked and what not …

We are a technical standards organization, and RFCs are very good for defining protocols, algorithms and so, that can be turned in to actual code. However, it is very clear now for me that we can’t use an RFC to enforce a venue coalification. This will bring us to the situation that only 4-5, maybe 6 venues in the world, work for us.

Is that what we are looking for?

We may need a “special” document, not what we understand as an RFC, and different requirements language to make it work.

In a generic way, the term Mandatory, as described in 1.2 of the actual document, is useless, and will only mean that we need to consult the community 95% of the venues that already worked before for successful meetings.

I think we need a document that can be used by the “on-site venue survey team” as a guidance, not as a document to “match” the venues with. Believe me this will not work and will be a tool for endless debates.

Maybe, if we just relax what Mandatory means, then it may work, but only maybe. For example:

Actual:
Mandatory:
      If this requirement cannot be met, a particular location is
      unacceptable for selection, and no contract is to be entered into.
      Should the IAOC 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.

New:
Mandatory:
      If this requirement cannot be met, a particular location will need
      further examination and a balance among “mandatory” and
      “important” and “desired” will be required towards a final decision.
      by the IAOC. In extreme situations, the IAOC will consult with the 
      community.

Alternatively, instead of an RFC, we may think that this must be a web page with all the information as “recommendations” or “guidelines” for venue requirements.

As I’ve re-read several times the actual document during last week, I also have some other inputs (many of those related to the past week experience), which I’m addressing one by one:

1) Section 2.1 point 2, should include “freedom of expression for the participants”.
2) I think we must not hold meetings in venues that allow people to carry firearms. I know this may be a conflict for many people that believe that self-defense is a right, but I agree that is true in the street, but inside a venue? If a venue is not considered safe so it “encourages people to carry a gun”, then there is no discussion on that, we should not meet in that venue.
3) At 3.2 the reference “There are sufficient places (e.g., a mix of hallways, bars, meeting rooms, and restaurants) …” is for the facility or the venue/city? Actually, I think is not the same and we may need to split that in 3 equivalent requirements, one for the facility, one for the hotel, one for the facility neighborhood. For instance, we may find a conference center with is plenty of much more space that what we need, but the hotel may have no space, or on the other way around. Or the hotel maybe has no restaurants but across the street (2’ walk) you have a shopping center with offers 20 options.
4) “The Facility permits easy wheelchair access”. While I agree this is a kind of “MUST” in our usual terminology, what it means “easy”? Regulations in different countries may provide a different meaning for “easy”, so I think we should delete “easy”, because it turns into something very subjective.
5) In the past, we were talking about 350 guest rooms at a minimum in the “headquarter hotel”. Now we have “The guest rooms at the IETF Hotel(s) are sufficient in number to house 1/3 or more of projected meeting”. I recall we had this discussion because the Intercontinental at Yokohama. I think we need to have a clear vision that if we have 3 or 4 hotels instead of just 1-2 that fulfill let’s say, the coverage needed for 75% of the participants, that should be enough if they are in very close proximity. For example, one hotel next to the other in the same street, or across the street, and walking 5 minutes or so bring you to the meeting facility.
6) Same consideration as in 4 above to remove “easy” at “The IETF Hotel(s) permit easy wheelchair access”.
7) “The IETF Headquarters Hotel has a space for use as a lounge …” This text need to be rewritten, as it is assuming that there is only one “headquarter” hotel. What if we have 4 as main hotels, because among them fulfill our needs?
8) “The Venue environs, which includes both onsite, as well as areas within a reasonable walking distance or conveniently accessible by a short taxi, bus, or subway ride, have convenient and inexpensive choices for meals that can accommodate a wide range of dietary requirements.“. Replace “short taxi, bus, or subway ride” with “short taxi ride, or any other public transport service”, this way opens other choices with are not bus or subway, which are available now in cities or may be available in the future …
9) This may be an English issue “grocery shopping” includes small markets, supermarkets, hypermarkets, local shops, etc., just to be on the safe side.
10) I think it will be VERY important to have a local, which is also involved in the IETF, and knows the venue and the neighborhood of the facilities being evaluated, to help the on-site survey team. This could be added to 5.3 Qualification.
11) Appendix A should not be a MUST, is an overall reference. There are many parameters there that may change depending on the set of: facility + hotels + neighborhood.

Regards,
Jordi
 





**********************************************
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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.