From nobody Fri Aug 4 09:20:00 2017
Return-Path:
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 CAC82132402 for ; Fri, 4 Aug 2017 09:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 1aRrKCNGxPCv for ; Fri, 4 Aug 2017 09:19:57 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AD71323FB for ; Fri, 4 Aug 2017 09:19:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5338; q=dns/txt; s=iport; t=1501863596; x=1503073196; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WHosZ893aIYhyVuMtWKZzvkDL5mLj9xw/sRHrbqyJ9o=; b=aUdcncJk/Uo7mRTTY+/cAjyNXBClMZpgRhqjaVNZukdbMLQniSmsWo6g 4Bdp/kzDa4RftHeXcCnh9SCuhdPrqUuI4Io9jVq7jJjzrjMBeHIMa5Hvg N6PKObWkul4VfJNTLX0n1IkldIuu0n2QMixK7rWRixOI4UtplnXImMSie c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AQBTnoRZ/5xdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy0tZG0nB44IkAeBbpYVghIhC4RMTwIahDE/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQIDAQEWCxE3AxcGAQgRAwECAwIfBwIEJQsUAQgKBAESii8QrnuCJos/AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBIIELgh2BMVGCNIEmgnyEc4MTMIIxBaAFApQtgg+FWIp?= =?us-ascii?q?ilgEBHziBCncVSRIBhTmBTnaIYIEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.41,321,1498521600"; d="scan'208";a="466700482"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 16:19:45 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v74GJjbo026766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 16:19:45 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 11:19:45 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 4 Aug 2017 11:19:44 -0500
From: "Charles Eckel (eckelcu)"
To: "jordi.palet@consulintel.es" , "mtgvenue@ietf.org"
Thread-Topic: [Mtgvenue] charter and possible path forward for draft-palet-ietf-meeting-network-requirements-01
Thread-Index: AQHTDT17woFH3wktUUuelUi2+sIVRQ==
Date: Fri, 4 Aug 2017 16:19:44 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: text/plain; charset="utf-8"
Content-ID: <04AC43C96B68A2408BDC17130E13898B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At:
Subject: Re: [Mtgvenue] charter and possible path forward for draft-palet-ietf-meeting-network-requirements-01
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 04 Aug 2017 16:19:59 -0000
SGkgSm9yZGksDQoNCkkgdGhpbmsgaXQgaXMgbW9yZSBhIHF1ZXN0aW9uIG9mIHNob3VsZCB0aGFu
IGNhbiB3ZSBhZGQgYSBtaWxlc3RvbmUgZm9yIHRoaXMgZHJhZnQgYW5kIHdvcmsgb24gaXQgd2l0
aGluIHRoZSB3b3JraW5nIGdyb3VwLiBUaGVyZSB3ZXJlIG1hbnkgcGVvcGxlIHdobyBhZ3JlZWQg
dGhhdCBkb2N1bWVudGluZyB0aGUgbmV0d29yayByZXF1aXJlbWVudHMgaXMgaW1wb3J0YW50IGFu
ZCBhIHNtYWxsZXIgbnVtYmVyIHRoYXQgaW5kaWNhdGVkIGEgd2lsbGluZ25lc3MgdG8gaGVscCB3
b3JrIHdpdGggeW91IG9uIHRoaXMgZHJhZnQgdG8gbWFrZSBzdXJlIGl0IGNhcHR1cmVzIHRob3Nl
IHJlcXVpcmVtZW50cy4gSG93ZXZlciwgdGhlcmUgd2FzIG5vdCBjb25zZW5zdXMgdGhhdCBhZG9w
dGluZyB0aGlzIGFzIGEgbXRndmVudWUgd29ya2luZyBncm91cCBkb2N1bWVudCBhbmQgcHJvZ3Jl
c3NpbmcgaXQgYXMgYW4gUkZDIHdhcyB0aGUgYXBwcm9wcmlhdGUgcGF0aCBmb3J3YXJkLg0KDQpU
aGUgcmVjb21tZW5kYXRpb24gZnJvbSB0aGUgY2hhaXJzIGlzIHRoYXQgdGhvc2UgaW50ZXJlc3Rl
ZCB0byB3b3JrIHdpdGggSm9yZGkgb24gdGhpcyBkcmFmdCBjb250YWN0IGhpbSBkaXJlY3RseS4g
WW91IGNhbiBkZWNpZGUgYW1vbmcgeW91cnNlbHZlcyB0aGUgZm9ybWF0IHRoZSBkb2N1bWVudCBz
aG91bGQgdGFrZSB0byBiZXN0IG1lZXQgdGhlIGludGVuZGVkIHB1cnBvc2Ugb2YgY2FwdHVyaW5n
IHRoZSBuZXR3b3JrIHJlcXVpcmVtZW50cyBpbiBhIHdheSB0aGF0IGlzIGhlbHBmdWwgZm9yIHNp
dGUgc2VsZWN0aW9uIGFuZCBtZWV0aW5nIHByZXBhcmF0aW9uLg0KDQpDaGVlcnMsDQpDaGFybGVz
DQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNdGd2ZW51ZSA8bXRndmVu
dWUtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxq
b3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NClJlcGx5LVRvOiAiam9yZGkucGFsZXRAY29uc3Vs
aW50ZWwuZXMiIDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NCkRhdGU6IEZyaWRheSwgSnVs
eSAyMSwgMjAxNyBhdCAyOjA0IEFNDQpUbzogIm10Z3ZlbnVlQGlldGYub3JnIiA8bXRndmVudWVA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBbTXRndmVudWVdIGNoYXJ0ZXIgYW5kIHBvc3NpYmxlIHBhdGgg
Zm9yd2FyZCBmb3IgZHJhZnQtcGFsZXQtaWV0Zi1tZWV0aW5nLW5ldHdvcmstcmVxdWlyZW1lbnRz
LTAxDQoNCiAgICBIaSBhbGwsDQogICAgDQogICAgSeKAmXZlIGJlZW4gdGhpbmtpbmcgb24gdGhl
IHF1ZXN0aW9uIHJhaXNlZCBkdXJpbmcgdGhlIG1lZXRpbmcgcmVnYXJkaW5nIHRoZSBjaGFydGVy
Lg0KICAgIA0KICAgIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBkaWZmZXJlbnQgd29yZGluZyBz
dWNoIGFzIOKAnHZlbnVlIHNlbGVjdGlvbiBwcm9jZXNzIGFuZCBjcml0ZXJpYeKAnSwgdXNlZCBh
Y3Jvc3MgdGhlIGNoYXJ0ZXIgKGJlY2F1c2UgdGhlIHRlY2huaWNhbCBkZXRhaWxzIGFyZSBhIGtl
eSBwYXJ0IG9mIHRoZSBzZWxlY3Rpb24gY3JpdGVyaWEgYW5kIG9uLXNpdGUtc3VydmV5KSBtZWFu
cyB0aGF0IHRoZSBjb3JyZWN0IHBsYWNlIGZvciB0aGlzIGRvY3VtZW50IGlzIHRoaXMgV0cuIEZ1
cnRoZXJtb3JlLCBpcyBxdWl0ZSBjb21tb24gdG8gYWRkIG1pbGVzdG9uZXMgdG8gYSBydW5uaW5n
IFdHLg0KICAgIA0KICAgIE5vdywgb25lIG9mIHRoZSBwcml2YXRlIGNvbW1lbnRzIEkgZ290LCBm
cm9tIHNldmVyYWwgZm9sa3MsIGlzIHRoYXQgdGhpcyBXRyBkb27igJl0IGhhdmUgdGhlIHJpZ2h0
IOKAnHBhcnRpY2lwYW50c+KAnSB0byBldmFsdWF0ZSB0aGlzIGRvY3VtZW50LiBIb3dldmVyIHRo
aXMgaXMgYWxzbyBjb21tb24gaW4gbWFueSBXRy4gU29tZXRpbWVzIHRoZXJlIGFyZSBkaWZmZXJl
bnQgc2V0cy9sZXZlbHMgb2Ygc2tpbGxzIGluIG1hbnkgV0dzIGFuZCBJIHRoaW5rIHdlIGFyZSBz
bWFydCBlbm91Z2ggdG8gYXZvaWQgYmxvY2tpbmcgYSBkb2N1bWVudCBpZiB3ZSBkb27igJl0IGhh
dmUgdGhlIHJpZ2h0IGV4cGVydGlzZSB0byBldmFsdWF0ZSBpdCwgYXMgd2UgYXJlIGNvbmZpZGVu
dCB0aGF0IG90aGVyIGZvbGtzIHdpbGwgZG8gaXQgY29ycmVjdGx5Lg0KICAgIA0KICAgIENsZWFy
bHkgdGhlIG1vc3QgaW1wb3J0YW50IHBlb3BsZSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGlzIGRvY3Vt
ZW50IGRpc2N1c3Npb24gaXMgdGhlIHBhcnRpY2lwYW50cyBpbiB0aGUgTk9DIChpbiBmYWN0LCBO
T0MgcGFydGljaXBhbnRzIHdlcmUgZGlyZWN0bHkgY29udHJpYnV0aW5nIHRvIHRoZSB2ZXJzaW9u
IDAwIG9mIHRoaXMgZG9jdW1lbnQgaW4gMjAwNS82KSwgYW5kIHBlb3BsZSB0aGF0IHBhcnRpY2lw
YXRlIGluIG9uLXNpdGUtc3VydmV5cyBmb3IgZmFjaWxpdGllcywgd2hpY2ggSeKAmW0gc3VyZSBo
YXZlIG5vdCB0cm91YmxlIGlmIG5lZWRlZCwgdG8gcGFydGljaXBhdGUgaW4gYSBzcGVjaWZpYyBt
YWlsaW5nIGxpc3QgZm9yIHRoaXMgd29yayBhbmQgdGhlbiByZXBvcnQgc29tZWhvdywgb3VyIOKA
nGNvbnNlbnN1c+KAnSB0byB0aGUgY29tcGxldGUgV0cgZm9yIGEgbGFzdCBjYWxsLg0KICAgIA0K
ICAgIElzIHRoYXQgYSBwb3NzaWJsZSBwYXRoIGZvcndhcmQ/DQogICAgDQogICAgT3Igd2Ugc2hv
dWxkIGhhdmUgYSBkaWZmZXJlbnQgdmVudWUgZm9yIGl0PyBXaGljaCBvbmU/DQogICAgDQogICAg
UGxlYXNlLCBub3RlIHRoYXQgSeKAmW0gbm90IGluIGZhdm9yIG9mIG9uZSBvciB0aGUgb3RoZXIg
d2F5LCBJIGp1c3Qgd2FudCB0byBhdm9pZCBoYXZpbmcgdGhpcyBkb2N1bWVudCB3aXRob3V0IGFu
eSB1bWJyZWxsYSwgYXMgdGhpcyBpcyBiYXNpY2FsbHkgdGhlIHJlYXNvbiBpdCBkaWVkIGluIDIw
MDUvNiAodG9nZXRoZXIgd2l0aCBkcmFmdC1wYWxldC1pZXRmLW1lZXRpbmctdmVudWUtc2VsZWN0
aW9uLWNyaXRlcmlhLTA0KS4gSSBndWVzcyB3ZSBjb3VsZCBoYXZlIHByb2JhYmx5IHNhdmVkIGEg
bG90IG9mIGN5Y2xlcyBhbmQgdHJvdWJsZXMgdG8gZXZlcnlvbmUgaWYgdGhvc2UgZG9jdW1lbnRz
IHdlcmUgbW92ZWQgZm9yd2FyZCBpbiAyMDA2LCBzbyBsZXTigJlzIGF2b2lkIHJlcGVhdGluZyBt
aXN0YWtlcy4NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIEpvcmRpDQogICAgIA0KICAgIA0KICAg
IA0KICAgIA0KICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioNCiAgICBJUHY0IGlzIG92ZXINCiAgICBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVy
bmV0ID8NCiAgICBodHRwOi8vd3d3LmNvbnN1bGludGVsLmVzDQogICAgVGhlIElQdjYgQ29tcGFu
eQ0KICAgIA0KICAgIFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9u
IHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9u
IGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVk
IGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRo
YXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNv
bnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMg
cHJvaGliaXRlZC4NCiAgICANCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIE10Z3ZlbnVlIG1haWxpbmcgbGlzdA0KICAg
IE10Z3ZlbnVlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tdGd2ZW51ZQ0KICAgIA0KDQo=
From nobody Fri Aug 4 15:36:02 2017
Return-Path:
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 EB7AF1204DA for ; Fri, 4 Aug 2017 15:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.595
X-Spam-Level:
X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 XwpYP1JlFddX for ; Fri, 4 Aug 2017 15:35:58 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC0E12714F for ; Fri, 4 Aug 2017 15:35:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1501886158; x=1533422158; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bL2WZKc+rbkGQB7Gihzl9SPe5Zn7X/aQD/0tb+F5ps0=; b=IRnv/vZcEBqGR6QhjgVr/Tok8y9u3V7DNCQYv6CyPb3lehwADcRbbS5p aFhbYyimBYmTK9qi477B1Wh0qfdgigCw4530claP92hwu7TubXRQHcDCL eb5zWHrXwNYxP1+J1Ro/MSCfwBPbVTyOee/EosmVlnjZQ1hknjJQCif6A Y=;
X-IronPort-AV: E=Sophos;i="5.41,322,1498546800"; d="scan'208";a="113090196"
Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by sabertooth02.qualcomm.com with ESMTP; 04 Aug 2017 15:35:56 -0700
X-IronPort-AV: E=McAfee;i="5900,7806,8612"; a="1418177779"
X-MGA-submission: =?us-ascii?q?MDF+VHNPLhPsm9Gqn/xBgzDp4YhPEwO0jBa/cK?= =?us-ascii?q?yJeeSy7d327h3X5etwXvEFu4g05M/7wBI5bBVSQx3oTNBP5Z60Yj4nks?= =?us-ascii?q?LFwS4VHgDqxK9INw2UHWtSpmyA3HjANSOaDWwyt5uisF0JBcysFvmkSC?= =?us-ascii?q?Gw?=
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Aug 2017 15:35:55 -0700
Received: from [10.64.111.189] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 4 Aug 2017 15:35:55 -0700
From: Pete Resnick
To: Eliot Lear
CC:
Date: Tue, 25 Jul 2017 14:10:26 -0500
Message-ID: <5E2426BE-030F-4692-815A-1812B7DFAF79@qti.qualcomm.com>
In-Reply-To: <397fd756-2338-3025-3079-8e8e73a28d91@cisco.com>
References: <150090650629.31933.5312976047803730805@ietfa.amsl.com> <397fd756-2338-3025-3079-8e8e73a28d91@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At:
Subject: Re: [Mtgvenue] I-D Action: draft-ietf-mtgvenue-iaoc-venue-selection-process-08.txt
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 04 Aug 2017 22:36:01 -0000
On 24 Jul 2017, at 9:35, Eliot Lear wrote:
> In addition, the chairs have directed that a contributors section be
> created, and authors moved to that section. Dave Crocker has
> requested that he not be listed in that section, but in
> Acknowledgments instead.
Just by way of explanation on this bit:
As you may know, the "Author's Address" section of document is defined
in RFC 7322 to be used for 3 (non-separable) purposes: (1) To list the
authors and/or editors of the document; (2) To indicate the names that
will appear on the first page of the document; and (3) To indicate who
must consent to publication in the RFC Editor AUTH48 stage. The chairs
were most concerned about (3), because we would really prefer to have
the assigned WG document editor be the only one on the hook for AUTH48.
However, for this document (2) was also a problem: If there are more
than five listed authors, the IESG has to sign off on allowing it, and
they have been reluctant to do so. The chairs spoke to all of the listed
authors, and they were willing to appear in the Contributors section,
which 7322 created for this purpose.
The above state of affairs is problematic on several levels. Most
importantly, it would be nice if at least those listed for citation in
the RFC Editor and Datatracker indexes, those who appear on the front
page, and those who are contacted for AUTH48 were 3 independent items.
Completely by coincidence, due to another document in similar
circumstances, the IESG has recently begun discussing this matter. I
chatted with a few ADs last week in Prague, and I'm hoping that they
come up with a reasonable resolution before we actually go for
publication and make this whole thing moot.
pr
--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478
From nobody Fri Aug 4 15:36:23 2017
Return-Path:
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 66701129562 for ; Fri, 4 Aug 2017 15:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 qeAyqGDlbhdr for ; Fri, 4 Aug 2017 15:36:19 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA500126E3A for ; Fri, 4 Aug 2017 15:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1501886177; x=1533422177; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=oooV9aCk20dl1Hixn/HwJ+SbkVlYHoh5IvrJM2eGi0Q=; b=qwGpSj6c6acm1RD/7h1KJur83yabGpWdJ+ZZNPPyo6Cu0YV+Km5JxBFM zwWn9YOD5hvFZygVFA8yHrrxhQPC3TCT2q5uFHAS2T5Vr/+beH/S3+6oH t6uz5AZrYX/pI84EHo+36z+0NBmu4JI3ocyhN5l1Xt1BsaUqMYjHsIBfl 0=;
X-IronPort-AV: E=Sophos;i="5.41,322,1498546800"; d="scan'208";a="112081065"
Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([10.53.140.108]) by sabertooth01.qualcomm.com with ESMTP; 04 Aug 2017 15:36:16 -0700
X-IronPort-AV: E=McAfee;i="5900,7806,8612"; a="1469082884"
X-MGA-submission: =?us-ascii?q?MDH6oJPxVaNWvEEwnvPuqsVvZ5CHDPDLqC5raq?= =?us-ascii?q?jzyq7rJ0lWWjdml6Eq/RHY5f3HHR/WYc/hFPYMDGD+caJIymg9Wl6Tlp?= =?us-ascii?q?a1WLYWsJ+8Leb/CWJbzyV4ZCZHsCtG2mApV2p5gTOOehEtR3VjkL8ROn?= =?us-ascii?q?KS?=
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Aug 2017 15:36:16 -0700
Received: from [10.64.111.189] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 4 Aug 2017 15:36:15 -0700
From: Pete Resnick
To: mtgvenue
Date: Fri, 4 Aug 2017 17:36:15 -0500
Message-ID: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At:
Subject: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 04 Aug 2017 22:36:21 -0000
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=3Dis%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 nobody Fri Aug 11 12:17:41 2017
Return-Path:
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 5A7E91243F6 for ; Fri, 11 Aug 2017 12:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 e0av4iaSFV6v for ; Fri, 11 Aug 2017 12:17:38 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1F5127601 for ; Fri, 11 Aug 2017 12:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=326; q=dns/txt; s=iport; t=1502479057; x=1503688657; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=4QfAxMg1DGhqR2TrRPw5fASjrlWfRNJAflnk4D89klY=; b=GYSVxvTX5U06z9ZOjgKkLakkJ1bvIurrgFSgLDGTJzcbMUVGTAFKoT/g geiAC/rPMCPrHhqIR290cvkWxwsin1zUR/hNf/hwNTxo4P24vQYIN6dlA QBhdBmlRcMywcnhXN8XurH+ZJIz5LRfG3RHJGMqi6QMwU7KTviJembAvs s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQC4AY5Z/4MNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1pkgRuOCpAMmAWCEiyFN4RcPxgBAgEBAQEBAQFrHQuFQhFXASICJgIEMBU?= =?us-ascii?q?SBIpCEKt0giaLYQEBAQEBAQEDAQEBAQEBAQEBARkFgQuCHYICg1qLAjCCMQWgJ?= =?us-ascii?q?gKHUYxngXcBF4VdimiWEgEfOIEKdxVJEgGHB4oWgQ8BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,359,1498521600"; d="scan'208";a="279755305"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2017 19:17:37 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7BJHa5C025497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 11 Aug 2017 19:17:37 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 11 Aug 2017 14:17:36 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 11 Aug 2017 14:17:36 -0500
From: "Charles Eckel (eckelcu)"
To: "mtgvenue@ietf.org"
Thread-Topic: meeting minutes from IETF 99
Thread-Index: AQHTEtZ9QxlPhkaCAkqkEFEfmn8QFw==
Date: Fri, 11 Aug 2017 19:17:36 +0000
Message-ID: <657DA950-C541-44DB-AD11-F33E44D293E4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8EADE95A45650C44973138484C84B143@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At:
Subject: [Mtgvenue] meeting minutes from IETF 99
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 11 Aug 2017 19:17:39 -0000
SGkgRm9sa3MsDQoNCldlIGhhdmUgdXBsb2FkZWQgdGhlIG1pbnV0ZXMgdG8gdGhlIG1lZXRpbmcg
bWF0ZXJpYWxzIHBhZ2UuIA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk5
L21hdGVyaWFscy9taW51dGVzLTk5LW10Z3ZlbnVlDQoNClBsZWFzZSBoYXZlIGEgbG9vayBhbmQg
cG9zdCBhbnkgY29ycmVjdGlvbnMgdG8gdGhlIGxpc3QuDQoNClRoYW5rcywNCkNoYXJsZXMgYW5k
IFBldGUNCg0K
From nobody Fri Aug 11 13:23:07 2017
Return-Path:
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 EE1ED120713 for ; Fri, 11 Aug 2017 13:23:05 -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 V9xaqT_rBjMS for ; Fri, 11 Aug 2017 13:23:03 -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 D28FF1243F3 for ; Fri, 11 Aug 2017 13:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502482981; x=1503087781; 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=+vxUqO61thLBp9AdzxpFQbcV+dYHrAyUnAYp76wd9OI=; b=R2VD9PaorSxI6 dQCMi0iL/+o6DA4wyzCKEdcZsMIekaDE8ONa/mJG8Z5htxYtU0J/o/qWZ7wGwexJ lY8mYsuz47LVdkvF6oXHoyYO6dGG/0pWVBHb2rCs50TdlBWLAQ+z7o9YLLH+oeEh gZe25+y83HGUU5i57Zl/1sg2AH5R14=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dTWGZpCEmNYRF7bq+AN/MPdMmJOeEE+Xh/Q6SU3ZB6ahZOfbs0B6OaU5VYdz Z6gHSlJKuLaaTkb4A9H0SdEAttzHLYAS/j9D/ghf9ipkrprXWqUD7E7ah 3iukujxTkjzzpLSjZ30Y1pcYbSWv/rC5eHJLYVz1phpiHRddEoCwXk=;
X-MDAV-Processed: mail.consulintel.es, Fri, 11 Aug 2017 22:23:01 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 11 Aug 2017 22:23:00 +0200
Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005502786.msg for ; Fri, 11 Aug 2017 22:22:58 +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:170811:md50005502786::v4VUVVinFLqyPZtP:00000DNr
X-Return-Path: prvs=1396ac8e03=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: mtgvenue@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.1.170721
Date: Fri, 11 Aug 2017 22:22:54 +0200
From: JORDI PALET MARTINEZ
To:
Message-ID: <30F9ACFE-79DD-48A5-BC6C-5CD9685EC1EF@consulintel.es>
Thread-Topic: [Mtgvenue] meeting minutes from IETF 99
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At:
Subject: Re: [Mtgvenue] meeting minutes from IETF 99
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 11 Aug 2017 20:23:06 -0000
Hinden, not Hindon, I guess
Jordi, not Jordy ;-) (last line)
I said something different than =E2=80=9CBelieves close to guideline that e=
xist.=E2=80=9D. I said that I believe the guidelines were based (which seem=
s evident because even copy&paste wording) on my -00 version on this.
I think Jim and I clarified the contrary that what minutes reflect. Base re=
quirements are stable, don=E2=80=99t expect to change. What may change is t=
echnical specific details such as for example, types of wiring, how it is s=
etup, etc., and there are different was to achieve what we need in differen=
t facilities, but that=E2=80=99s the reason they aren=E2=80=99t explicitly =
mention in the document they may be fixed in each contract once the venue i=
s surveyed in case anything needs to be changed/improved. An RFP may cite t=
his document as a base line and used in the on-site survey to confirm.
Rgeards,
Jordi
=20
-----Mensaje original-----
De: Mtgvenue en nombre de "Charles Eckel (eckel=
cu)"
Responder a:
Fecha: viernes, 11 de agosto de 2017, 21:17
Para: "mtgvenue@ietf.org"
Asunto: [Mtgvenue] meeting minutes from IETF 99
Hi Folks,
=20
We have uploaded the minutes to the meeting materials page.=20
https://datatracker.ietf.org/meeting/99/materials/minutes-99-mtgvenue
=20
Please have a look and post any corrections to the list.
=20
Thanks,
Charles and Pete
=20
_______________________________________________
Mtgvenue mailing list
Mtgvenue@ietf.org
https://www.ietf.org/mailman/listinfo/mtgvenue
=20
**********************************************
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 con=
fidential. 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 dis=
closure, copying, distribution or use of the contents of this information, =
including attached files, is prohibited.
From nobody Fri Aug 11 15:22:26 2017
Return-Path:
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 934AB132646 for ; Fri, 11 Aug 2017 15:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 qob2q4TCKVZd for ; Fri, 11 Aug 2017 15:22:21 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C24B13228D for ; Fri, 11 Aug 2017 15:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3966; q=dns/txt; s=iport; t=1502490141; x=1503699741; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=26Lr/0KdKHsmnpp6kgUlDWQMZSsyR3KcB4AtxNG/6cE=; b=ZO1xO4T+rGiF0/doRYEUfd3OhH9faWiiGgogCO+iySq9Eb9xUiOKdnG/ Mbr/KLRpvTlIvCgwuHJonDAotCTe6qwXQaZfCjZnfVgPEvaTSnqOhO9BS XWemt/J9t6VB+rqJf+I6tk1FgoBNbg8S8lCUs01CJzQuhkf5GMFSTFGa5 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQD6LY5Z/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgqQDYFMIpYXghIhC4RMTwIahFw/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwEBFgsROhcEAgEIEQMBAgMCJgICAiULFAEICAIEARKKLxCrXoImi?= =?us-ascii?q?2IBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuCHYExUYI0gSYLgnGEc4MTMIIxBaA?= =?us-ascii?q?mAodRjGeCD4VdimiWEgEfOIEKdxVJEgGFBByBZ3aIMYEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.41,359,1498521600"; d="scan'208";a="279480422"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2017 22:22:02 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7BMM2OB028585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Aug 2017 22:22:02 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 11 Aug 2017 17:22:01 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 11 Aug 2017 17:22:01 -0500
From: "Charles Eckel (eckelcu)"
To: "jordi.palet@consulintel.es" , "mtgvenue@ietf.org"
Thread-Topic: [Mtgvenue] meeting minutes from IETF 99
Thread-Index: AQHTEt+m8tFlMr5l1UmhfsjzdK8Z56J/mUSA
Date: Fri, 11 Aug 2017 22:22:01 +0000
Message-ID: <6BA4BFBE-4705-4D4E-B2E0-A940AB5B5110@cisco.com>
References: <30F9ACFE-79DD-48A5-BC6C-5CD9685EC1EF@consulintel.es>
In-Reply-To: <30F9ACFE-79DD-48A5-BC6C-5CD9685EC1EF@consulintel.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: text/plain; charset="utf-8"
Content-ID:
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At:
Subject: Re: [Mtgvenue] meeting minutes from IETF 99
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 11 Aug 2017 22:22:23 -0000
VGhhbmtzIEpvcmRpLiBJIHVwZGF0ZWQgdGhlIG1pbnV0ZXMgYWNjb3JkaW5nbHkuDQoNCkNoZWVy
cywNCkNoYXJsZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE10Z3ZlbnVl
IDxtdGd2ZW51ZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSk9SREkgUEFMRVQgTUFS
VElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KUmVwbHktVG86ICJqb3JkaS5wYWxl
dEBjb25zdWxpbnRlbC5lcyIgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KRGF0ZTogRnJp
ZGF5LCBBdWd1c3QgMTEsIDIwMTcgYXQgMToyMiBQTQ0KVG86ICJtdGd2ZW51ZUBpZXRmLm9yZyIg
PG10Z3ZlbnVlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNdGd2ZW51ZV0gbWVldGluZyBtaW51
dGVzIGZyb20gSUVURiA5OQ0KDQogICAgSGluZGVuLCBub3QgSGluZG9uLCBJIGd1ZXNzDQogICAg
DQogICAgSm9yZGksIG5vdCBKb3JkeSA7LSkgKGxhc3QgbGluZSkNCiAgICANCiAgICBJIHNhaWQg
c29tZXRoaW5nIGRpZmZlcmVudCB0aGFuIOKAnEJlbGlldmVzIGNsb3NlIHRvIGd1aWRlbGluZSB0
aGF0IGV4aXN0LuKAnS4gSSBzYWlkIHRoYXQgSSBiZWxpZXZlIHRoZSBndWlkZWxpbmVzIHdlcmUg
YmFzZWQgKHdoaWNoIHNlZW1zIGV2aWRlbnQgYmVjYXVzZSBldmVuIGNvcHkmcGFzdGUgd29yZGlu
Zykgb24gbXkgLTAwIHZlcnNpb24gb24gdGhpcy4NCiAgICANCiAgICBJIHRoaW5rIEppbSBhbmQg
SSBjbGFyaWZpZWQgdGhlIGNvbnRyYXJ5IHRoYXQgd2hhdCBtaW51dGVzIHJlZmxlY3QuIEJhc2Ug
cmVxdWlyZW1lbnRzIGFyZSBzdGFibGUsIGRvbuKAmXQgZXhwZWN0IHRvIGNoYW5nZS4gV2hhdCBt
YXkgY2hhbmdlIGlzIHRlY2huaWNhbCBzcGVjaWZpYyBkZXRhaWxzIHN1Y2ggYXMgZm9yIGV4YW1w
bGUsIHR5cGVzIG9mIHdpcmluZywgaG93IGl0IGlzIHNldHVwLCBldGMuLCBhbmQgdGhlcmUgYXJl
IGRpZmZlcmVudCB3YXMgdG8gYWNoaWV2ZSB3aGF0IHdlIG5lZWQgaW4gZGlmZmVyZW50IGZhY2ls
aXRpZXMsIGJ1dCB0aGF04oCZcyB0aGUgcmVhc29uIHRoZXkgYXJlbuKAmXQgZXhwbGljaXRseSBt
ZW50aW9uIGluIHRoZSBkb2N1bWVudCB0aGV5IG1heSBiZSBmaXhlZCBpbiBlYWNoIGNvbnRyYWN0
IG9uY2UgdGhlIHZlbnVlIGlzIHN1cnZleWVkIGluIGNhc2UgYW55dGhpbmcgbmVlZHMgdG8gYmUg
Y2hhbmdlZC9pbXByb3ZlZC4gQW4gUkZQIG1heSBjaXRlIHRoaXMgZG9jdW1lbnQgYXMgYSBiYXNl
IGxpbmUgYW5kIHVzZWQgaW4gdGhlIG9uLXNpdGUgc3VydmV5IHRvIGNvbmZpcm0uDQogICAgDQog
ICAgUmdlYXJkcywNCiAgICBKb3JkaQ0KICAgICANCiAgICANCiAgICAtLS0tLU1lbnNhamUgb3Jp
Z2luYWwtLS0tLQ0KICAgIERlOiBNdGd2ZW51ZSA8bXRndmVudWUtYm91bmNlc0BpZXRmLm9yZz4g
ZW4gbm9tYnJlIGRlICJDaGFybGVzIEVja2VsIChlY2tlbGN1KSIgPGVja2VsY3VAY2lzY28uY29t
Pg0KICAgIFJlc3BvbmRlciBhOiA8ZWNrZWxjdUBjaXNjby5jb20+DQogICAgRmVjaGE6IHZpZXJu
ZXMsIDExIGRlIGFnb3N0byBkZSAyMDE3LCAyMToxNw0KICAgIFBhcmE6ICJtdGd2ZW51ZUBpZXRm
Lm9yZyIgPG10Z3ZlbnVlQGlldGYub3JnPg0KICAgIEFzdW50bzogW010Z3ZlbnVlXSBtZWV0aW5n
IG1pbnV0ZXMgZnJvbSBJRVRGIDk5DQogICAgDQogICAgICAgIEhpIEZvbGtzLA0KICAgICAgICAN
CiAgICAgICAgV2UgaGF2ZSB1cGxvYWRlZCB0aGUgbWludXRlcyB0byB0aGUgbWVldGluZyBtYXRl
cmlhbHMgcGFnZS4gDQogICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu
Zy85OS9tYXRlcmlhbHMvbWludXRlcy05OS1tdGd2ZW51ZQ0KICAgICAgICANCiAgICAgICAgUGxl
YXNlIGhhdmUgYSBsb29rIGFuZCBwb3N0IGFueSBjb3JyZWN0aW9ucyB0byB0aGUgbGlzdC4NCiAg
ICAgICAgDQogICAgICAgIFRoYW5rcywNCiAgICAgICAgQ2hhcmxlcyBhbmQgUGV0ZQ0KICAgICAg
ICANCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCiAgICAgICAgTXRndmVudWUgbWFpbGluZyBsaXN0DQogICAgICAgIE10Z3ZlbnVlQGlldGYu
b3JnDQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXRndmVu
dWUNCiAgICAgICAgDQogICAgDQogICAgDQogICAgDQogICAgKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KICAgIElQdjQgaXMgb3Zlcg0KICAgIEFyZSB5b3Ug
cmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KICAgIGh0dHA6Ly93d3cuY29uc3VsaW50ZWwu
ZXMNCiAgICBUaGUgSVB2NiBDb21wYW55DQogICAgDQogICAgVGhpcyBlbGVjdHJvbmljIG1lc3Nh
Z2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlk
ZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2Yg
dGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp
YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVk
aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KICAgIA0KICAgIA0KICAgIA0KICAg
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgTXRn
dmVudWUgbWFpbGluZyBsaXN0DQogICAgTXRndmVudWVAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL210Z3ZlbnVlDQogICAgDQoNCg==
From nobody Sun Aug 13 13:48:28 2017
Return-Path:
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 392561329C2 for ; Sun, 13 Aug 2017 13:48:26 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UXGAhnUzfIVB for ; Sun, 13 Aug 2017 13:48:24 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D25F132A05 for ; Sun, 13 Aug 2017 13:48:24 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id l64so34182904pge.5 for ; Sun, 13 Aug 2017 13:48:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=K3/JDtMKtq/YuFVf4W+XndBqvnwl4lI3/TiJiNhLOwg=; b=nHOagLNaCZA6VzER33PkimSV4QHJ0CNevHUS7W9Qi5gMaTzzk17rEVnIZZgUKOZJ87 sTPUMXb97D6TTRHJXSAqSV+ttPvf0OE6lwezHEsLqsllWY7beB+vJHT/95JLrbz5T2ak 35WggngWGIiw0n8etdt69ybgdQCjVQMASgwxICve65NXwiTPP4dt7uuQkeZzgL0neiL0 hvJALpBzutUq/NImHgS50wscjchCX72kcongHvvIZ/6KXigGANgLhFAaOGcNeEoEPDub bEsJ20Iup5HZHy3AriYQgWTWkzjIOohVqM0ctVdhOSjXfZ5+0dCgqjj0yRnSuJZjvTKi x1pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=K3/JDtMKtq/YuFVf4W+XndBqvnwl4lI3/TiJiNhLOwg=; b=PXK0NxrGjW4AVvQ8TJjP1fH0gxT2uq19TAWyZHlsH7+V2kvSZQGhDyLZxVo4THuEcY SEBDEv98nBVICX8lMz6ivGhMXnuW0CgfS9etlkjCqa/sXQ+72Oshff+grM7Y+dDZ2vpm jmEpbzvcSUtyItALQDfxN6tk3gwBiQMBpjPvI+iW+USPnhNSu47NjfJc7APSWsyxuzTk 1+e8NLQCa1qbrJVYwSc9LcjIbZji0YwOGLm9li4eRWKlst3orL7HdNGj3ry2c5dljI5Y bktRN1uYjJTTJyj5wTj9B1VunEVdRsrPhGggg+dwDZnhxLdXBszWpKrB1ChfbmMbekel 8Icg==
X-Gm-Message-State: AHYfb5g6NguX4ckn/gJKMPCQmbyHkTwaGPFZt2wRhs1V9klO/PE6KpkB vIJlfVIbpTKaGeRv
X-Received: by 10.84.129.6 with SMTP id 6mr25896947plb.289.1502657303377; Sun, 13 Aug 2017 13:48:23 -0700 (PDT)
Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i133sm11488964pgc.0.2017.08.13.13.48.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 13:48:22 -0700 (PDT)
To: mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
From: Brian E Carpenter
Organization: University of Auckland
Message-ID: <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com>
Date: Mon, 14 Aug 2017 08:48:18 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 13 Aug 2017 20:48:26 -0000
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:
> 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
>
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>
From nobody Mon Aug 21 15:39:12 2017
Return-Path:
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 64F6E132AC6 for ; Mon, 21 Aug 2017 15:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 sp5rD8CJfiBZ for ; Mon, 21 Aug 2017 15:39:07 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D287712008A for ; Mon, 21 Aug 2017 15:39:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1503355147; x=1534891147; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ppfmcsN/o4AoK6HwyNr1oahJmcXBYSyg0BuyMYNUQCY=; b=Tm52qj636O6Mnh61P3dC/V1aB5JHF/jMS1j8zMBbTM+QRtqW1Ha6baju f6/fEZi+K+s6BGsg/SNwnWVMTffgAqBtKWlZRQM2BJNiUoavPpTvNY7fo MUEkYpmDTbDrMqwJdH6BOA1/ZN7lUFqPzsmvN7ujOBhy3APH3vqgTjVNa c=;
X-IronPort-AV: E=Sophos;i="5.41,410,1498546800"; d="scan'208";a="114058533"
Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([10.53.140.108]) by sabertooth02.qualcomm.com with ESMTP; 21 Aug 2017 15:39:06 -0700
X-IronPort-AV: E=McAfee;i="5900,7806,8630"; a="1477715945"
X-MGA-submission: =?us-ascii?q?MDGuYSZCsxRQhMmRRrNMMlKt2yn8Ke8MpeTfLx?= =?us-ascii?q?N44YcGEhyN+iazxV0T9qLSVST3/me6BbKG037VNEeAFclxaJi69IkaOw?= =?us-ascii?q?qQft8TD5oinOk32iXHa2gT1FiJNLBK5QEKhKrIwu3mtpCEvdClkmfUl/?= =?us-ascii?q?XH?=
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Aug 2017 15:39:06 -0700
Received: from [10.110.56.223] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Aug 2017 15:39:06 -0700
From: Pete Resnick
To: Brian E Carpenter
CC:
Date: Mon, 21 Aug 2017 17:39:04 -0500
Message-ID: <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com>
In-Reply-To: <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com>
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 21 Aug 2017 22:39:10 -0000
[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
On 13 Aug 2017, at 15:48, Brian E Carpenter wrote:
> 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:
>> 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-select=
ion-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=3Dis%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
>>
>> _______________________________________________
>> Mtgvenue mailing list
>> Mtgvenue@ietf.org
>> https://www.ietf.org/mailman/listinfo/mtgvenue
>>
-- =
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478
From nobody Mon Aug 21 16:46:08 2017
Return-Path:
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 C24CF1321A6 for ; Mon, 21 Aug 2017 16:46:07 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 H0PnnO63S-qa for ; Mon, 21 Aug 2017 16:46:05 -0700 (PDT)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E66313218F for ; Mon, 21 Aug 2017 16:46:05 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id m133so25985990pga.5 for ; Mon, 21 Aug 2017 16:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ykqhkWiytpcrtyPJZOIPLZ0PLM4EfZ03dfjAMEedFXg=; b=r/bi+WjUvCBSPgMM0PXAjNIcFsQVqm7j9ogXxDHWqjtaLooU2FGTJkC3EzmjizSibG geho6Oxmjf8LDuzka6yJwndMSxhWXiH+kj1rbNm/hqwkEzg9SHyMwDHoXGUMv1ZqtZ+5 InFZMU/TJz8k3lzGkuqjnFBattEArDd1npRKUgLEv8n8PyQ23P9CLU6dgXgGgx8lW1EA e1WRfEScVYTOw1xqa3cvwgy2YpmjSDUCYbgPL7NL0pyIhmnjPHaPmJeKIzDpnHojM0Ys 9jT998BROLNvP0u4KzBsEhfyLY9kRZE/BqVpdvDH+NMqBbSXPK8cAivQ2Q5jDeI/Dd34 0ZzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ykqhkWiytpcrtyPJZOIPLZ0PLM4EfZ03dfjAMEedFXg=; b=kMXAkqTS/J3CY/iana2nzmwGcPtR72Dp6Men+IWSKPn5dzAiNly7ZK8S6Q1rQgqH9G NOyriX4cuwvbZ1cxXV/qH+DuPIuwyJR6p9RZf+Mz5lIe+z7hbAYyyd+RUm9HXuYl7SAf cYkogo+g61STGGsaKUc79hfSzEgmyOafFpbepbmHsCmDmn2rzqyfgUytnCgBk4qkuSxJ WDBtnqw+EDqGAX8CWiG59WuJb4qJxELPzY+ZWVDnt4bUbCXsJ4TlHSBh+sXsXHiQPahx 6xfdreBtXKaxmo8K6PiM1Z0wbyag2hLb8iXgC5H8LshB2VPTrln426lWOJ+2X5BxEqhh KoPA==
X-Gm-Message-State: AHYfb5iX4TRz9zhUjeErAmGRbJJVVjTq9jeSn4BGx9dro59TQAEyGDjZ AVNxy8OaGGaB4VzJ
X-Received: by 10.84.176.195 with SMTP id v61mr20624190plb.271.1503359164453; Mon, 21 Aug 2017 16:46:04 -0700 (PDT)
Received: from [130.216.38.3] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.3]) by smtp.gmail.com with ESMTPSA id n66sm26545107pfk.38.2017.08.21.16.46.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Aug 2017 16:46:03 -0700 (PDT)
To: Pete Resnick
Cc: mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com> <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com>
From: Brian E Carpenter
Organization: University of Auckland
Message-ID:
Date: Tue, 22 Aug 2017 11:46:00 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 21 Aug 2017 23:46:08 -0000
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
On 22/08/2017 10:39, Pete Resnick wrote:
> [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
>
> On 13 Aug 2017, at 15:48, Brian E Carpenter wrote:
>
>> 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:
>>> 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
>>>
>>> _______________________________________________
>>> Mtgvenue mailing list
>>> Mtgvenue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mtgvenue
>>>
>
>
From nobody Mon Aug 21 22:27:39 2017
Return-Path:
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 503F813236E for ; Mon, 21 Aug 2017 22:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 OgDQ6U-R50wM for ; Mon, 21 Aug 2017 22:27:36 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EF71321A2 for ; Mon, 21 Aug 2017 22:27:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5485; q=dns/txt; s=iport; t=1503379656; x=1504589256; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=xsq75w5NwZHqfBFgc1u5fsLO95kI/tzA9rSjaMwofPw=; b=QnFyuC6iliP0OAdA9PMkRoYtPHjWOEiofzDSgNgRBM3bB/85tPwvdikT 01++9PgC2/8IekaH6PDpD1qQSXSs8FKLSF/GiBpup5ByuZlyJ6Dw3sXlC +ePS+4/7y9GJhZ6vNtfEHqemNQmhv2t/UMwN/B4YQNmiBERq6825yszd+ A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQDrv5tZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+Ra5ERkGWHSweFQAKEUhUBAgEBAQEBAQFrKIUZAQQBI1YFCws?= =?us-ascii?q?EPgICVwYBDAgBARCKFQisZ4ImJ4s8AQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+DK?= =?us-ascii?q?oUxK4J8iAaCYQWgUoQzgiGNb4IQiTojhnKWJzUigQoyIQgcFYYVgVA+ilwBAQE?=
X-IronPort-AV: E=Sophos;i="5.41,410,1498521600"; d="asc'?scan'208,217";a="654106048"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2017 05:27:31 +0000
Received: from [10.61.168.70] ([10.61.168.70]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7M5RVe0018577; Tue, 22 Aug 2017 05:27:31 GMT
To: Brian E Carpenter , Pete Resnick
Cc: mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com> <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com>
From: Eliot Lear
Message-ID: <73f90a88-cecb-b63c-6dc5-99d0f1ab9420@cisco.com>
Date: Tue, 22 Aug 2017 07:27:32 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3lkf23irrA0F3oShLMLmln3ci19aSpjK9"
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 22 Aug 2017 05:27:38 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3lkf23irrA0F3oShLMLmln3ci19aSpjK9
Content-Type: multipart/mixed; boundary="w7MuxVt4pdroNHVpDc3lOnC3RR17efRbs";
protected-headers="v1"
From: Eliot Lear
To: Brian E Carpenter ,
Pete Resnick
Cc: mtgvenue@ietf.org
Message-ID: <73f90a88-cecb-b63c-6dc5-99d0f1ab9420@cisco.com>
Subject: Re: [Mtgvenue] Working Group Last Call on
draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
<7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com>
<5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com>
In-Reply-To:
--w7MuxVt4pdroNHVpDc3lOnC3RR17efRbs
Content-Type: multipart/alternative;
boundary="------------19E7526D84317252BC5D9A28"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------19E7526D84317252BC5D9A28
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Brian,
First, thanks for your detailed read.=C2=A0 Let me address both of your
messages in one:
> 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 IET=
F
> community. We specify a set of general criteria for venue selection=
> and several requirements for transparency and community consultation=
=2E
>
> (The whole point of this change was to make the document as robust as
> possible, whatever changes the IASA 2.0 process leads to.)
I agree, and it was an oversight in the previous version.=C2=A0 I've
corrected for -09, not having heard any objection.
> 1) The draft uses three different terms: Meetings Committee,
> Meeting Subcommittee, Meeting Committee. I think we should pick one.
Corrected in -09.
>
> 2) The RFC Editor will be picky about several abbreviations
> being used before defined (including IASA and IAOC).
I've done a scrub for this for -09.
Thanks again,
Eliot
--------------19E7526D84317252BC5D9A28
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Brian,
First, thanks for your detailed read.=C2=A0 Let me address both of=
your messages in one:
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.)
I agree, and it was an oversight in the previous version.=C2=A0 I'=
ve
corrected for -09, not having heard any objection.
1) The draft uses three different terms: Meetings =
Committee,
Meeting Subcommittee, Meeting Committee. I think we should pick one.
Corrected in -09.
2) The RFC Editor will be picky about several abbreviations
being used before defined (including IASA and IAOC).
I've done a scrub for this for -09.
Thanks again,
Eliot
--------------19E7526D84317252BC5D9A28--
--w7MuxVt4pdroNHVpDc3lOnC3RR17efRbs--
--3lkf23irrA0F3oShLMLmln3ci19aSpjK9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJZm8DEAAoJEIe2a0bZ0nozg7QH/iN4jZDUFk3wWXSyOZ/GKnde
n1bBsjbPZ/ZxljUpZYBJRgfvWiz5IVH5WUPYX99XzT85rM4jAa0kOJ0o3J+ibOlv
bxud2dNAyLM+UoLsuOJBayzhdm+qhaDZ4eOM+Z1jdxKsNCmENcMALNTEDdKP34I0
v3p0QmW5xCp3cuEazo17MInyuk69Ziqfd/QN6ODg+qlhD1I9PWpBabzNI0rZisc5
CIyJ2k+3NV1/g7hZOYsmKOksNxcml9XqQGK53bAjN1wgHaQGv1oE4HjhF+AWCMrr
StPIJACTp6TtrAaxBwaMPVXlvdIvM//Ixv0rFgkCupRR4g0k+PVzs1tkb+juxmo=
=Hxvj
-----END PGP SIGNATURE-----
--3lkf23irrA0F3oShLMLmln3ci19aSpjK9--
From nobody Tue Aug 22 13:40:45 2017
Return-Path:
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 CC5EC132A43 for ; Tue, 22 Aug 2017 13:40:43 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CwXJfrQCcsC1 for ; Tue, 22 Aug 2017 13:40:41 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398BE132A42 for ; Tue, 22 Aug 2017 13:40:41 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id m133so37146824pga.5 for ; Tue, 22 Aug 2017 13:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cHwukRytKPFLmd3W8jTafrT7FxISLkmTngb8yWpHj2Y=; b=P5YmXRgmOnrQ63c+FlcMnI+2UcGiG+9WvGbShBi4EUL6gVnwxGCHkAzARMN4xgrKjF N1PNwc2GEIXFXry04fVP0mY5+cx9G+7q2lWwID5qxoXp/1Sb8kB7dQLA7d7MUfBXgA+U ySiRG4dXR2kvcgyjj5T/znREMlHE51eRmNWCHaxMvU6tj+9YgB3zKy3BG6aKd7e/xAp+ jDPr7jBu35zEauiOWK0wUHITBfIyUpyDHMJxzUBJZ+Evr8NOSPxqpaHrSe9Wv180030T mfzBbnEJOIHeL2WdnWy08cJqkr8MivW60GuMfI27uZZhQ9M4cP+Ciq7Oyun/T4/7s1HN 30gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cHwukRytKPFLmd3W8jTafrT7FxISLkmTngb8yWpHj2Y=; b=j8AOWnMxXawQrctwVSP/tqXp6oViM7HSwKOkbs+s8zX/+WIUIwh7vOjcP/Ki+zmbMe iK41Slin0f1achdBGAHUHqvyGp2Bu9XOgW4LS2l9x2X942cJF3OkR0zhQRQauCZYpjuJ muF6qW2Ha4/ATjtN/nD+7FMA/a9Ah85fTwR3lvkZkB4A9Du6Jv/2hA1fnUIzQoU/b8if xyIXPCzZbkcoojWuu3u3hBDNqlJiZaH4KbGxpsux3JjAkrvcay9R2dVpvXbCk6G0e+7x 1f0vTu6txe/zwiZNszZJywFtyp1OHRMFXqUszjoGGOD7I51FuDpQBQ6tDqTV5SeiJcR0 55iQ==
X-Gm-Message-State: AHYfb5gT7k5CCa7lCdFOHxMasYaPKWnXySfopAQTmnRFAlxh707iJSUq 24FwqTSkC4sHgxAy
X-Received: by 10.84.217.208 with SMTP id d16mr449915plj.208.1503434440304; Tue, 22 Aug 2017 13:40:40 -0700 (PDT)
Received: from ?IPv6:2406:e001:5420:1:28cc:dc4c:9703:6781? ([2406:e001:5420:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q76sm33611050pfi.76.2017.08.22.13.40.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 13:40:39 -0700 (PDT)
To: Eliot Lear , mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com> <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com> <19b0c88d-e21d-9e10-cf8e-8d803fc3dcdf@cisco.com>
From: Brian E Carpenter
Organization: University of Auckland
Message-ID: <2c9a46e3-e4ce-f5ec-9cc6-9a0b5d7cfd52@gmail.com>
Date: Wed, 23 Aug 2017 08:40:39 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19b0c88d-e21d-9e10-cf8e-8d803fc3dcdf@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 22 Aug 2017 20:40:44 -0000
On 22/08/2017 17:30, Eliot Lear wrote:
> Brian,
>=20
> Please see attached for comparison.=C2=A0 Please if you could post any
> additional changes you would like to the WG in the next day or so.
>=20
> 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.
=2E..
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.
=2E..
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.
=2E..
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
=2E..
4.4. IETF Administrative Oversight Committee
The IETF Administrative Oversight Committee (IAOC) has the
responsibility to oversee the selection of IETF meeting venues.
=2E..
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
=2E..
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.
=2E..
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.
=2E..
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.
=20
From nobody Tue Aug 22 14:04:01 2017
Return-Path:
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 4C3DF132A5E for ; Tue, 22 Aug 2017 14:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 od7npLrIBrh5 for ; Tue, 22 Aug 2017 14:03:58 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD7A132A5F for ; Tue, 22 Aug 2017 14:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8335; q=dns/txt; s=iport; t=1503435837; x=1504645437; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=gUgIvcAOszXW3Tl4IMKddjw317EZduhjBTG/90vKlNA=; b=YonDxTMjUasDnhMfCBE1u7yyRCxVuVDZKTlABcf7DlK8PwXXnXB8HHZH 13lH7H57a97DxnF+BhMvJnFqU7dKyf1o3Yj+aySCyzQmTfCuSagrIS2Im yzs+DRbVv/RB8TvJIwa2yyk5m4mfW8/wBYH9nTmGYC0hsvxNQux8+qyVL g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQBom5xZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBlFuRFXeXOgeFQAKEdBQBAgEBAQEBAQFrKIUZAQUjQiQLGCoCAlc?= =?us-ascii?q?GAQwIAQEQih2tUIImi2MBAQEBAQEEAQEBAQEBARIPgyqFMSuCSDSIBoJhAQSKF?= =?us-ascii?q?JZBhDOCIYIRi16CEIVig1iHFpYpNiGBCjIhCBwVhWAcGYFQPos3AQEB?=
X-IronPort-AV: E=Sophos;i="5.41,413,1498521600"; d="asc'?scan'208";a="656965206"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2017 21:03:51 +0000
Received: from [10.61.78.225] (ams3-vpn-dhcp3809.cisco.com [10.61.78.225]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7ML3psX018210; Tue, 22 Aug 2017 21:03:51 GMT
To: Brian E Carpenter , mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com> <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com> <19b0c88d-e21d-9e10-cf8e-8d803fc3dcdf@cisco.com> <2c9a46e3-e4ce-f5ec-9cc6-9a0b5d7cfd52@gmail.com>
From: Eliot Lear
Message-ID:
Date: Tue, 22 Aug 2017 23:03:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <2c9a46e3-e4ce-f5ec-9cc6-9a0b5d7cfd52@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ssvbCQwcw2DdmqwuV6uWmigjnQVmafFHT"
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 22 Aug 2017 21:04:00 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ssvbCQwcw2DdmqwuV6uWmigjnQVmafFHT
Content-Type: multipart/mixed; boundary="IWsB48D0R9k5XGhJ5J5U7q6JxwhDUe40x";
protected-headers="v1"
From: Eliot Lear
To: Brian E Carpenter , mtgvenue@ietf.org
Message-ID:
Subject: Re: [Mtgvenue] Working Group Last Call on
draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
<7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com>
<5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com>
<19b0c88d-e21d-9e10-cf8e-8d803fc3dcdf@cisco.com>
<2c9a46e3-e4ce-f5ec-9cc6-9a0b5d7cfd52@gmail.com>
In-Reply-To: <2c9a46e3-e4ce-f5ec-9cc6-9a0b5d7cfd52@gmail.com>
--IWsB48D0R9k5XGhJ5J5U7q6JxwhDUe40x
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Hi Brian,
Thanks.=C2=A0 I've taken=C2=A0 all of your changes but one class: I don't=
think it
would be accurate to call the meetings committee the "IASA meetings
committee".=C2=A0 As documented, it is appointed by the IAOC, and not by =
"The
IASA".=C2=A0 Otherwise we would have to go through this same substitution=
and
a consolidation with "IAD".=C2=A0 As there is no normative requirement on=
the
meetings committee leaving this text shouldn't really make a difference
even after IASA 2.0.=C2=A0 Furthermore, the intent is not to codify the
IAOC's subcommittee structure, but simply to mention it informatively.=C2=
=A0
I can make that clearer if you like.
Eliot
On 8/22/17 10:40 PM, Brian E Carpenter wrote:
> On 22/08/2017 17:30, Eliot Lear wrote:
>> Brian,
>>
>> Please see attached for comparison.=C2=A0 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 realit=
y,
> 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 sectio=
ns
> 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 les=
s
> 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. Thi=
s
> 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 th=
e
> 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 Importan=
t
> or Mandatory criteria can be met by a Venue, the IASA MUST reconside=
r
> the selection. A description of how reconsideration currently takes=
> place is found in Appendix B. The IASA will gauge the cost of makin=
g
> a change against the ability of the IETF to conclude a successful
> meeting, and make a final determination based on their best judgment=
=2E
> When there is enough time to do so, the IASA is expected to consult
> the community about changes.
> =20
>
>
>
--IWsB48D0R9k5XGhJ5J5U7q6JxwhDUe40x--
--ssvbCQwcw2DdmqwuV6uWmigjnQVmafFHT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJZnJw7AAoJEIe2a0bZ0nozM6wH/A+tJkAF8LC67L2fYq60zLwN
d1QlRL3wxEsweUl9nLDo+eWEbBcLat9KQB5VgWAGug7PWrq/oll+YZh1idxWxA8C
P3Ag7/GMy/ubMGB+xNTnjC7TExEFPdvBnRhtLxPa+d+oih9QGu1loCUVs2ZFgYql
bKEhObbvpLZB9KCICRLhlE3IcRSLrV4ULRlnZL/xdXlT81Hk8J6rVGECtxa/F7MB
K+BjSs0jMB4qJG6DMr3u36lRIEwmvTXn9U2m1ZXWZzbZsdDrIC0xbgeiZs1Zk610
UY9LaXkbVn9ukzjO7qGdJ2Zi+wQFBkbRJdEs26BONl2u9pNojMNwpMf4x3F17k4=
=YuVb
-----END PGP SIGNATURE-----
--ssvbCQwcw2DdmqwuV6uWmigjnQVmafFHT--
From nobody Tue Aug 22 15:15:45 2017
Return-Path:
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 AB7CB132A97 for ; Tue, 22 Aug 2017 15:15:43 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 uUUN_0m3Hb68 for ; Tue, 22 Aug 2017 15:15:41 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F22132A94 for ; Tue, 22 Aug 2017 15:15:41 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id y129so159635pgy.4 for ; Tue, 22 Aug 2017 15:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=o3HuhZeu8FDT/3hJGQ0A/b4cClfpzHcyDbvBSmOe0Ro=; b=Pnhdbqe44oz+xwyFoS5jcdGg6zWCFgPlBv/qrmeuUQiWcUKmc7+dwFuZC/ZAiMU3dT 6hqXCGY6Bbtd38ZmIrTytqiHKY2LS+eocCD/Fv0lpENXxKOgIlNtkCZ73G6kDjlr6Hcq x0teRd6ZoSV9uXruNCl4CNuTDm2zGSsgvlOy7gQ7QTnMnneW60+UFyn7iPlxbkfxxxry quyo7k/MNHRp9V9u2HUNyUDVucT1BfiAqENolSuHhb7QQPX0BEzunY8OGzPZhc+hz48z ErO08/Nv+h9dQVlHEDxfK6BQ20n9nGTSw6NrULbiCJ6dJU3QCVDqRRoFHN9fjr2z/o1l zHTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=o3HuhZeu8FDT/3hJGQ0A/b4cClfpzHcyDbvBSmOe0Ro=; b=Ic5UyNoMauMrKjFBospBAelBAoYHQpF2yXuvAp0TR851qdfPK0810m59GacLlXbQPq 2HuRIP9CjIPc1fjeCZZATZQ8vY8ay5ti05wx+VRbSsfx0Zd6eZQQope+0uUQnCB/RLpJ GNpuFtcRyVJZ34cbmDwHmXVPZiPk0mQG79bGrpzdCj10a0L/UMcq2weDEi1M5ElFe9uY pIDcjCjPfflcbD1wfX5MYtTS9UoZiIRVCIC4lnTXVX8xB/A+PpcN2JOkjOZjv7lXGmAx YMhA1uRFRpod9GtZYG7n5ilwVbDqNXNhBKSWJHUhFD7L42Dom0EGzuitI2Jzot35qDe0 RbBQ==
X-Gm-Message-State: AHYfb5ikgdp2tEY+EWoy7dRDBG8rLMJtI/EXf/fdRkblWC5cuhieP6xE Rn14T27GKz68nKT4
X-Received: by 10.99.98.3 with SMTP id w3mr643923pgb.350.1503440140593; Tue, 22 Aug 2017 15:15:40 -0700 (PDT)
Received: from ?IPv6:2406:e001:5420:1:28cc:dc4c:9703:6781? ([2406:e001:5420:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g87sm42155pfe.51.2017.08.22.15.15.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 15:15:39 -0700 (PDT)
To: Eliot Lear , mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <7c0df522-9c6e-f399-0930-b8cf210642a8@gmail.com> <5DD86764-54BF-4B8A-A51B-AD5CF6AE3489@qti.qualcomm.com> <19b0c88d-e21d-9e10-cf8e-8d803fc3dcdf@cisco.com> <2c9a46e3-e4ce-f5ec-9cc6-9a0b5d7cfd52@gmail.com>
From: Brian E Carpenter
Organization: University of Auckland
Message-ID: <2ad00a10-a33b-6fa6-54d9-03eb9a566a75@gmail.com>
Date: Wed, 23 Aug 2017 10:15:39 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 22 Aug 2017 22:15:44 -0000
On 23/08/2017 09:03, Eliot Lear wrote:
> Hi Brian,
>=20
> Thanks.=C2=A0 I've taken=C2=A0 all of your changes but one class: I don=
't think it
> would be accurate to call the meetings committee the "IASA meetings
> committee".=C2=A0 As documented, it is appointed by the IAOC, and not b=
y "The
> IASA".=C2=A0 Otherwise we would have to go through this same substituti=
on and
> a consolidation with "IAD".=C2=A0 As there is no normative requirement =
on the
> meetings committee leaving this text shouldn't really make a difference=
> even after IASA 2.0.=C2=A0 Furthermore, the intent is not to codify the=
> IAOC's subcommittee structure, but simply to mention it informatively.=C2=
=A0
> 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
>=20
> Eliot
>=20
>=20
> On 8/22/17 10:40 PM, Brian E Carpenter wrote:
>> On 22/08/2017 17:30, Eliot Lear wrote:
>>> Brian,
>>>
>>> Please see attached for comparison.=C2=A0 Please if you could post an=
y
>>> 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 reali=
ty,
>> 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 secti=
ons
>> 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 t=
o
>> 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=
=2E
>>
>> ...
>>
>> 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 thes=
e
>> criteria is on the whole more preferable than another that meets le=
ss
>> 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 a=
s
>> 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 reques=
t
>> 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. Th=
is
>> 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. Unles=
s
>> 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 candidate=
s
>> 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 prio=
r
>> 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 t=
he
>> 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 considere=
d
>> 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 Importa=
nt
>> or Mandatory criteria can be met by a Venue, the IASA MUST reconsid=
er
>> the selection. A description of how reconsideration currently take=
s
>> place is found in Appendix B. The IASA will gauge the cost of maki=
ng
>> a change against the ability of the IETF to conclude a successful
>> meeting, and make a final determination based on their best judgmen=
t.
>> When there is enough time to do so, the IASA is expected to consult=
>> the community about changes.
>> =20
>>
>>
>>
>=20
>=20
From nobody Thu Aug 24 14:54:58 2017
Return-Path:
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 DBA7613235C for ; Thu, 24 Aug 2017 14:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=j7KgIPBJ; dkim=pass (1024-bit key) header.d=yitter.info header.b=QERcLJT5
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 tBQsya467SaW for ; Thu, 24 Aug 2017 14:54:47 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C219126BFD for ; Thu, 24 Aug 2017 14:54:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 92E83C09A0 for ; Thu, 24 Aug 2017 21:54:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503611656; bh=+1N/c1t8zJHx9dW+/gCHVtprwzYXkz5yDZhCIPcu6wM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=j7KgIPBJBKM2JoKRwYzfZ5GY4Av/gpESEGw6JTy7iTcx3xk5Q7tsGrgFbnkvxlon2 5i1HVe/8DSlq5C0pkcgC9WKPMO1mFJK5y1cO+0Kokb9/ao78etNBAu755YWuHemgH9 H6dtdjO3tzxsnH/wJv+lGxiauQ2lyvcn2S7v5ouU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEYBZ2_g-Q7V for ; Thu, 24 Aug 2017 21:54:14 +0000 (UTC)
Date: Thu, 24 Aug 2017 17:54:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503611654; bh=+1N/c1t8zJHx9dW+/gCHVtprwzYXkz5yDZhCIPcu6wM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QERcLJT5civMuy0RiDPZAX5WSe+lMEcv9/LvZ6wjcpKsiXF2eqYcfRW7KWPEKe7pM /gbm/79WQWsUZJLZJN+cvldwzYKGC2WqH5sagxybmkcyUpr6RMoKBwGf+gkZF0JtXT fB3HmEKvAigLiLXTUuV4DaoamyE5vthADs+rbfXE=
From: Andrew Sullivan
To: mtgvenue@ietf.org
Message-ID: <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 24 Aug 2017 21:54:57 -0000
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:
Four years out, a process identifies cities that might be candidates
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.
On Fri, Aug 04, 2017 at 05:36:15PM -0500, Pete Resnick wrote:
> 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/
>
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
From nobody Mon Aug 28 06:31:05 2017
Return-Path:
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 36BDA132223 for ; Mon, 28 Aug 2017 06:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 GanFgkHX5qrb for ; Mon, 28 Aug 2017 06:31:02 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9258B124B18 for ; Mon, 28 Aug 2017 06:31:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9936; q=dns/txt; s=iport; t=1503927061; x=1505136661; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=XpaaY0t7RZGUWTBKEUn4V55t1p6B1LOSakbSUq+1Q78=; b=Yvt8RoE0N8krtN7oUdjKB3PmB+/OYPp3tlxThflJzydd5jDYSJMSlkb2 QNFKLmPhge5YjgIYRVCtJnc6p0HUZRWD00tGMZa+6F2GyhImJMcwiUzBX JaskS0uh1p80MEoFRKxr9yGAbM671ciEeqvpO4QL30ZQWM+A/X52sMWOZ 4=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQA9GqRZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBlFuQcyJ3lT2CBAeFQAKEPRQBAgEBAQEBAQFrKIUYAQEBAQIBI04?= =?us-ascii?q?YCw4KKgICVwYBDAgBARCKFQiwWYIni14BAQEBAQUBAQEBAQETD4MqhTMrC4I9N?= =?us-ascii?q?YRdgyuCYQEEigaOJIg6hDSCIYRXiRqCEoVmg1kkhnOWPTYhgQ0yIQgcFYVhHBm?= =?us-ascii?q?BTQM+ix4BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,441,1498521600"; d="asc'?scan'208";a="657078963"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 13:30:57 +0000
Received: from [10.61.221.60] ([10.61.221.60]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7SDUuTr020756; Mon, 28 Aug 2017 13:30:56 GMT
To: Andrew Sullivan , mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
From: Eliot Lear
Message-ID:
Date: Mon, 28 Aug 2017 15:30:57 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B3Crqh7cmoIQjfNNhvEXmawjWcF153NdE"
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 13:31:04 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--B3Crqh7cmoIQjfNNhvEXmawjWcF153NdE
Content-Type: multipart/mixed; boundary="nasoa6lf7P0XpU6Aca3OOaBtFiEENCrfU";
protected-headers="v1"
From: Eliot Lear
To: Andrew Sullivan , mtgvenue@ietf.org
Message-ID:
Subject: Re: [Mtgvenue] Working Group Last Call on
draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
<20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
In-Reply-To: <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
--nasoa6lf7P0XpU6Aca3OOaBtFiEENCrfU
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Hi Andrew,
Thanks for your comments.=C2=A0 Please see below:
On 8/24/17 11:54 PM, Andrew Sullivan wrote:
> 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 usuall=
y
> are not connected to the IETF network and do not use IETF SSIDs=
=2E
So added.
>
> 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 o=
f
> 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 think we have been back and forth on this, and I need to hear from
others.=C2=A0 Perhaps we need to reword this along the lines of, =E2=80=9C=
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.=C2=A0 The more a Venue uses filtering,=C2=A0 the =
less
attractive it will be to the IETF."
???
>
> 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.
Ok.
>
> 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.
I am neutral on this, but do need to hear from others in order to
recommend how to best proceed.
>
> 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.
How about this:
Furthermore, it may be appropriate for the IASA to assist those who, as
a result, have been inconvenienced in some way.
>
> 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.
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.=
>
> In section 5.1, I find this sentence to be surprising:
>
> Four years out, a process identifies cities that might be candidates=
> 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.
What would you like in its place?=C2=A0 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.
>
> 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"?
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").
>
> NITS:
>
> Section 3.2: "than another that meets less=E2=80=A6" s/less/fewer.
Fixed.
>
> 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.
Facility environs.
> 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.
>
Ok!=C2=A0 Will take.
Thanks again,
Eliot
--nasoa6lf7P0XpU6Aca3OOaBtFiEENCrfU--
--B3Crqh7cmoIQjfNNhvEXmawjWcF153NdE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJZpBsRAAoJEIe2a0bZ0noziNwIANDGSvSOuGTW2hT20vp2lM47
y8ZqEvUeRXT2CBx6Zx6TB420WJxJZuzBTChHZHIYbO4BdKpb2wYW3ue3Okk0O8T6
pIQ+ZJQyZ1u1E4pLyDvcAVmbTvwSS7Bdr6T4AWCzvxGcQgbvpDS0NAPIllg0kxlm
diDFB6s5FbNEXDMlQu9ibECf5K3kCbIOFuSjjlrIJ8lMDo+1FyYZGX+u/Z5H6gWb
dita4gUiIU11m1jpceXLM/f2DHb9lbCN+iHCZ1LmpGl3vt+xvH2gLlwdvxdfoS92
7X8le6hI7sGO+Go0FMZl1+ciIIgAHo5xk+Fw9/rY+IyXegoQKxShDrPHo/DTt5s=
=Dbgq
-----END PGP SIGNATURE-----
--B3Crqh7cmoIQjfNNhvEXmawjWcF153NdE--
From nobody Mon Aug 28 07:00:20 2017
Return-Path:
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 B54EA132C39 for ; Mon, 28 Aug 2017 07:00:18 -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 QEUfZ7g_9mDY for ; Mon, 28 Aug 2017 07:00:15 -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 68DFE1243F6 for ; Mon, 28 Aug 2017 07:00:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1503928813; x=1504533613; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=qzYI8OsYx32+tLxSjTFl7gkWk yC4DhoAViJwsFRsqKo=; b=W2uUpzphYtgBN27j8BNTTXxyum/gLuZENFTOsmZst f76pxSDyDdsl7Rky9YPQmA+4dyIkUfbTnHxnwOkcZrIFqqqdvVh7PTHLyNQRd/oJ BuKXlJKYgbaMLvyeLdM4QXfpIZNZvsyI0AlpU2Iw+iA2tEnJfowNj88r+RwtrtX9 5U=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=C2DD58375W0cU80pncE665DsIIc/pcm5Xh3L6SWQQZ9b7ZQmdVRlvMC0ySSA cC3pJGqAuOzCUWzPmdRtRPW5/OXOkgggSxd7CJ0Z1EJE+UCRKydiCNGEh nBHV2wyC7u0K7Rp2JTMp57d3Colq6rNrXenV+7KM1EY9PodrCPQPjU=;
X-MDAV-Processed: mail.consulintel.es, Mon, 28 Aug 2017 16:00:13 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 28 Aug 2017 16:00:12 +0200
Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005529884.msg for ; Mon, 28 Aug 2017 16:00:11 +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:170828:md50005529884::FpZHQJQRmOJKKFbR:00004HDr
X-Return-Path: prvs=141354c2ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: mtgvenue@ietf.org
User-Agent: Microsoft-MacOutlook/f.25.0.170815
Date: Mon, 28 Aug 2017 16:00:07 +0200
From: JORDI PALET MARTINEZ
To:
Message-ID:
Thread-Topic: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 14:00:19 -0000
Regarding the filtering text =E2=80=A6 and also other mandatory requirement=
s.
As I already mention some time ago, if we have a venue that may qualify, bu=
t 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 th=
at may work.
The on-site survey team has the right expertise to assess that and then inf=
orm 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 =E2=80=9Cmeetings s=
pirit=E2=80=9D or =E2=80=9Climit situations=E2=80=9D, the IAOC will consult=
the community.
In section 5.1, instead of process, maybe =E2=80=9Con-site survey team=E2=
=80=9D? 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 do=
cument https://datatracker.ietf.org/doc/draft-palet-ietf-meeting-network-re=
quirements
Regards,
Jordi
=20
-----Mensaje original-----
De: Mtgvenue en nombre de Eliot Lear
Responder a:
Fecha: lunes, 28 de agosto de 2017, 15:31
Para: Andrew Sullivan ,
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-=
venue-selection-process-08
Hi Andrew,
=20
Thanks for your comments. Please see below:
=20
=20
On 8/24/17 11:54 PM, Andrew Sullivan wrote:
> 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 Facilit=
y,
> where the IETF has negotiated a group rate for the purposes o=
f
> the meeting. Of particular note is that overflow hotels usua=
lly
> are not connected to the IETF network and do not use IETF SSI=
Ds.
=20
So added.
>
> 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 fo=
r
> 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.
=20
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, =E2=80=9Cbe=
cause 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."
=20
???
=20
>
> 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 numb=
er
> 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.
=20
Ok.
=20
>
> o The venue MUST provide unfiltered access to the Internet, to th=
e
> extent permitted by governing laws and regulations.
>
> In my reading, this says that we have to have unfiltered access excep=
t
> 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, o=
r
> else that we have defined "successful meeting" more selectively than
> perhaps we ought to have done.
=20
I am neutral on this, but do need to hear from others in order to
recommend how to best proceed.
=20
>
> 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.
=20
How about this:
=20
Furthermore, it may be appropriate for the IASA to assist those who, as
a result, have been inconvenienced in some way.
=20
=20
>
> 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.
=20
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 poin=
t.
=20
>
> In section 5.1, I find this sentence to be surprising:
>
> Four years out, a process identifies cities that might be candidat=
es
> 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 abou=
t
> this item, and can live with the existing language, but it'd be nice
> to fix it.
=20
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.
=20
=20
>
> 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"?
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").
=20
>
> NITS:
>
> Section 3.2: "than another that meets less=E2=80=A6" s/less/fewer.
=20
Fixed.
=20
>
> 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.
Facility environs.
> 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 reduc=
e
> administrative costs, reduce direct attendee costs, or both.
>
Ok! Will take.
=20
Thanks again,
=20
Eliot
=20
_______________________________________________
Mtgvenue mailing list
Mtgvenue@ietf.org
https://www.ietf.org/mailman/listinfo/mtgvenue
=20
**********************************************
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 con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.
From nobody Mon Aug 28 08:42:10 2017
Return-Path:
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 DFBBB132C53 for ; Mon, 28 Aug 2017 08:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=MEbrO/fv; dkim=pass (1024-bit key) header.d=yitter.info header.b=fGst5S28
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 JZxXfgYC4Zns for ; Mon, 28 Aug 2017 08:42:07 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B805132C48 for ; Mon, 28 Aug 2017 08:42:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8B400BB807 for ; Mon, 28 Aug 2017 15:42:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503934926; bh=LZnoJwxO0D/j2dDs/XVsGn+0U6GFkdJmFqWCMTPzAnU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=MEbrO/fvCsiNSqKMpkS2IPY1FfjHNP4UwxXWFkNUB82cM0Np4a1tLdAKXAb9Y8Iy/ iYAVmYY9TZFI3AnBB80XIGhLYXkh6F2GhO55dKpMcu8Jz9gVD71afL0xyJItU9AGgb qBnjCDnN3HUa904tcGLJQ/gJ9NndTdSwVP46a+q0=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu5twfNPr_9a for ; Mon, 28 Aug 2017 15:42:05 +0000 (UTC)
Date: Mon, 28 Aug 2017 11:42:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503934925; bh=LZnoJwxO0D/j2dDs/XVsGn+0U6GFkdJmFqWCMTPzAnU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fGst5S28oWu6NoRhSQ9TfAa/Ex10LLk5d48iHdJG3MCmQ4mkEUESpSiJITg00oRXo uJA2fq+4WQ/NGWOzroHpjqXqD+BKpjFlyJ0ZMB5bdab/Onqw6B8rcX6WMVW9hksR4w X1bpvzNj94+o0NsXHQmAjcfa4zvF6MkXgOcIArUk=
From: Andrew Sullivan
To: mtgvenue@ietf.org
Message-ID: <20170828154211.cdo6sy4rc443eine@mx4.yitter.info>
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 15:42:09 -0000
On Mon, Aug 28, 2017 at 03:30:57PM +0200, Eliot Lear wrote:
> 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."
>
> ???
That'd be fine with me.
> > o The venue MUST provide unfiltered access to the Internet, to the
> > extent permitted by governing laws and regulations.
[…]
> I am neutral on this, but do need to hear from others in order to
> 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.
> How about this:
>
> Furthermore, it may be appropriate for the IASA to assist those who, as
> a result, have been inconvenienced in some way.
WFM.
> 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.
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
ajs@anvilwalrusden.com
From nobody Mon Aug 28 08:58:42 2017
Return-Path:
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 34C761321B6 for ; Mon, 28 Aug 2017 08:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=I+D6v6Sg; dkim=pass (1024-bit key) header.d=yitter.info header.b=Nz0XDZfy
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 Tqmu8IKotKJJ for ; Mon, 28 Aug 2017 08:58:38 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719A3132027 for ; Mon, 28 Aug 2017 08:58:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id BE155BB807 for ; Mon, 28 Aug 2017 15:58:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503935887; bh=GOJxMirybC//Eu+MNjLArsa3z5V1P+8geq7qSao1zTA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=I+D6v6Sg8q+T/NXgegAHNRWZdT3sKSlqQzv00L7GOI7GvuB927axiuuunIOi7AY/N s34GRu4lyQytiLXFgIMkuIyG/DbtzHomF/0pAml1CRsI5OunSqdXMVTIP2SLzJoQuF YXRs5h5aSiNbhJWvSIlXaPbU2ZvlWZDTH7J8nY3k=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUB9mDGKfoJP for ; Mon, 28 Aug 2017 15:58:06 +0000 (UTC)
Date: Mon, 28 Aug 2017 11:58:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503935885; bh=GOJxMirybC//Eu+MNjLArsa3z5V1P+8geq7qSao1zTA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Nz0XDZfy2y9IlAHQkwn3UuPjXyAdSeQue4uZ4yTcXgy4WuRAA9jPz/siMFpF6k9o8 egS3Pnfi6A1IBQoVN0IjrrS1YOds3W5Nb7R9ffYDMyoG31N1heUkt6Jo9KdmJWpMSu Ea1R1YWTBRL3+jAxJZJ3BQi0llGcBWF21rZWEnEA=
From: Andrew Sullivan
To: mtgvenue@ietf.org
Message-ID: <20170828155812.j5oq5ufc466rwq2f@mx4.yitter.info>
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 15:58:40 -0000
Hi Jordi,
On Mon, Aug 28, 2017 at 04:00:07PM +0200, JORDI PALET MARTINEZ wrote:
> 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.
>
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
ajs@anvilwalrusden.com
From nobody Mon Aug 28 09:23:41 2017
Return-Path:
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 4D19A13292C for ; Mon, 28 Aug 2017 09:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 jeBwmH6v3frU for ; Mon, 28 Aug 2017 09:23:37 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B81B1321B8 for ; Mon, 28 Aug 2017 09:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8070; q=dns/txt; s=iport; t=1503937417; x=1505147017; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=PFaNvD1KhZe4xHZfCWRFuPXatuuMmhbvF+180x+XYeg=; b=nHJ+NC+UxJWC5MUZX/WghnW9/Ouv+Q8vUl+0OEJFxpn0JyjzPdSIyv6X kaHHkIszAcIVd2VKaEjlOLm3ROgHYibV3tqSekwQsgSLihuf2XXvFB6Up 2ZDgP6PHSy94sdMOYnvIyzRmSTfxtau1cXnzGMPXMiWzy6UTbqioU/J9e g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AQA/QqRZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBlFuQdCKQaIdQB4VAAoRBFAECAQEBAQEBAWsohRgBAQEBAgEjThg?= =?us-ascii?q?LDgoqAgJXBgEMCAEBiiUIsRaCJyeLPAEBAQEBAQEDAQEBAQEBAQEBEA+DKoUzK?= =?us-ascii?q?wuCcogIgmEBBKBkhDSCIYRXiRqCEoVmg1mHF5Y9NiFBTDIhCBwVhhaBUD6LHgE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.41,442,1498521600"; d="asc'?scan'208,217";a="657081598"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 16:23:32 +0000
Received: from [10.61.221.60] ([10.61.221.60]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7SGNWnD023171; Mon, 28 Aug 2017 16:23:32 GMT
To: Andrew Sullivan , mtgvenue@ietf.org, Ted Hardie
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info> <20170828154211.cdo6sy4rc443eine@mx4.yitter.info>
From: Eliot Lear
Message-ID: <0a7f8e6c-8585-85af-ee79-821f128d6377@cisco.com>
Date: Mon, 28 Aug 2017 18:23:33 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170828154211.cdo6sy4rc443eine@mx4.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PkP9Nis6bPxLjKVnXwVcWW6GtTeNTXpfr"
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 16:23:39 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PkP9Nis6bPxLjKVnXwVcWW6GtTeNTXpfr
Content-Type: multipart/mixed; boundary="2HPBpOPc1Ws86FObHNKVc6JKi9pjd85H5";
protected-headers="v1"
From: Eliot Lear
To: Andrew Sullivan , mtgvenue@ietf.org,
Ted Hardie
Message-ID: <0a7f8e6c-8585-85af-ee79-821f128d6377@cisco.com>
Subject: Re: [Mtgvenue] Working Group Last Call on
draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
<20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
<20170828154211.cdo6sy4rc443eine@mx4.yitter.info>
In-Reply-To: <20170828154211.cdo6sy4rc443eine@mx4.yitter.info>
--2HPBpOPc1Ws86FObHNKVc6JKi9pjd85H5
Content-Type: multipart/alternative;
boundary="------------6E2055983AEC917DCF6E7699"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------6E2055983AEC917DCF6E7699
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,
On 8/28/17 5:42 PM, Andrew Sullivan wrote:
> On Mon, Aug 28, 2017 at 03:30:57PM +0200, Eliot Lear wrote:
>> others.=C2=A0 Perhaps we need to reword this along the lines of, =E2=80=
=9Cbecause 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.=C2=A0 The more a Venue uses filtering,=C2=A0 t=
he less
>> attractive it will be to the IETF."
>>
>> ???
> That'd be fine with me.
Are there any objections to this?
>>> o The venue MUST provide unfiltered access to the Internet, to th=
e
>>> extent permitted by governing laws and regulations.
> [=E2=80=A6]
>
>> I am neutral on this, but do need to hear from others in order to
>> 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.=20
I got that.=C2=A0 Ted, can you comment since I think you came up with the=
language in the draft?=C2=A0 The alternatives are:
* demote the text.
* reword the text.
I think Andrew is properly capturing a concern.=C2=A0 It could be that th=
e
right thing to do here is to get more specific about what sort of
filtering we are willing to put up with.
>> How about this:
>>
>> Furthermore, it may be appropriate for the IASA to assist those who, a=
s
>> a result, have been inconvenienced in some way.
> WFM.
Ok.
>> What would you like in its place?=C2=A0 If the issue is the word "proc=
ess",
>> we can point to the Meetings Committee or IAD or IASA, but that strike=
s
>> me as equally vague.
> 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 :)
I've used "IASA".=C2=A0 If anyone has objections, please speak up.
Eliot
--------------6E2055983AEC917DCF6E7699
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,
On 8/28/17 5:42 PM, Andrew Sullivan
wrote:
On Mon, Aug 28, 2017 at 03:30:57PM +0200, Eliot Lear=
wrote:
others.=C2=A0 Perhaps we need to reword this along=
the lines of, =E2=80=9Cbecause 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.=C2=A0 The more a Venue uses filtering,=C2=A0 the =
less
attractive it will be to the IETF."
???
That'd be fine with me.
Are there any objections to this?
o The venue MUST provide unfiltered access t=
o the Internet, to the
extent permitted by governing laws and regulations.
[=E2=80=A6]
I am neutral on this, but do need to hear from oth=
ers in order to
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.=20
I got that.=C2=A0 Ted, can you comment since I think you came up with=
the
language in the draft?=C2=A0 The alternatives are:
- demote the text.
- reword the text.
I think Andrew is properly capturing a concern.=C2=A0 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.
How about this:
Furthermore, it may be appropriate for the IASA to assist those who, as
a result, have been inconvenienced in some way.
WFM.
Ok.
What would you like in its place?=C2=A0 If the iss=
ue is the word "process",
we can point to the Meetings Committee or IAD or IASA, but that strikes
me as equally vague.
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 :)
I've used "IASA".=C2=A0 If anyone has objections, please speak up.
Eliot
--------------6E2055983AEC917DCF6E7699--
--2HPBpOPc1Ws86FObHNKVc6JKi9pjd85H5--
--PkP9Nis6bPxLjKVnXwVcWW6GtTeNTXpfr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJZpEOFAAoJEIe2a0bZ0noz+7MH/1IeKEQgvDFNVybpRYz8RFzP
A8RBsdNjI9O0BISqjTgZUzlkZbY01Frttsjbgpv8qOor3dQyXZ97VoHq1FO55sH6
xpd4WdGDzZYocYnK8EFpG6/jpab0CHXpLp0Q9EXf1azhSTQfdDO+1IFZPGHvyeQa
a4EaOkbMAiGWhoLzbMEkZORTgwYMZQSsscu0ldd4QvqdJDHCKil/vxxjMSieSrD/
rybetbxtynO+m9EVE7qwdZgxOi4ndml1asRwcIJU63QeERzEQBsLUmh/H/gokDKx
gdKJF/MopAB3Mb8am9jYCRmQ5C7g3CB7fmb2zjXcB6jExVou3CpQHX6B1NeVvoo=
=TTZs
-----END PGP SIGNATURE-----
--PkP9Nis6bPxLjKVnXwVcWW6GtTeNTXpfr--
From nobody Mon Aug 28 09:26:52 2017
Return-Path:
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 BE0721321B8 for ; Mon, 28 Aug 2017 09:26:50 -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 ZM13gSZ6w6Ir for ; Mon, 28 Aug 2017 09:26:48 -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 4BB981321B6 for ; Mon, 28 Aug 2017 09:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1503937606; x=1504542406; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=L16yykk+BFiDowBkT5LBwxzJS reKrWcZz2xoxFzGZ3A=; b=csS55la8hLNZFFA/YuYUu9FgQ1XjEGTw1c2Cv7U1e lca5nzQDemAg+MqnDGzH0BsyJvF6nPXdDuvCtOK1coEbCJKUb05U2AnJLjnEg4k3 8+K+1n6/E+IFqBWZWGdDIkvSv+y2553jmU0bMqvqH0NwP1tTcGWM+z+HmJJrMAzr U4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=jL6/vq64CZbs5HnKIwnk2a625dI3lQdb2VAHXlXaukZvLRNG4fsvvXKtZe4w QOv6rX69uqJJdncj7bokvEAdJ2YBCejNUt1azX/VdVY1GvwwsY+ilXRjy c2aWsX0TN/kDed/4XI2TrxRtCx56rGdGjv9j+18Tgh/GMlUukp8f3Y=;
X-MDAV-Processed: mail.consulintel.es, Mon, 28 Aug 2017 18:26:46 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 28 Aug 2017 18:26:46 +0200
Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005530066.msg for ; Mon, 28 Aug 2017 18:26:45 +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:170828:md50005530066::ssFKZNcKtf4YHJwZ:000016+A
X-Return-Path: prvs=141354c2ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: mtgvenue@ietf.org
User-Agent: Microsoft-MacOutlook/f.25.0.170815
Date: Mon, 28 Aug 2017 18:26:42 +0200
From: JORDI PALET MARTINEZ
To:
Message-ID: <99280BC4-2885-4B22-9E8E-70D8374CCE64@consulintel.es>
Thread-Topic: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info> <20170828155812.j5oq5ufc466rwq2f@mx4.yitter.info>
In-Reply-To: <20170828155812.j5oq5ufc466rwq2f@mx4.yitter.info>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 16:26:51 -0000
I missed an =E2=80=9Cif=E2=80=9D:
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 excl=
uded, even if it worked before. But I can see venues that may fail if we ha=
ve 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=E2=80=99m s=
aying that we should try to avoid any mandatory criterion (your possibility=
2).
Regards,
Jordi
=20
-----Mensaje original-----
De: Mtgvenue en nombre de Andrew Sullivan
Responder a:
Fecha: lunes, 28 de agosto de 2017, 17:58
Para:
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-=
venue-selection-process-08
Hi Jordi,
=20
On Mon, Aug 28, 2017 at 04:00:07PM +0200, JORDI PALET MARTINEZ wrote:
> As I already mention some time ago, if we have a venue that may quali=
fy, 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 oth=
ers that may work.
>=20
=20
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:
=20
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.
=20
2. The criterion isn't actually Mandatory at all.
=20
3. The Venue has changed such that the Mandatory criterion is not
met.
=20
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!)
=20
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.
=20
Best regards,
=20
A
=20
--=20
Andrew Sullivan
ajs@anvilwalrusden.com
=20
_______________________________________________
Mtgvenue mailing list
Mtgvenue@ietf.org
https://www.ietf.org/mailman/listinfo/mtgvenue
=20
**********************************************
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 con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.
From nobody Mon Aug 28 09:29:21 2017
Return-Path:
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 626FD1321B8 for ; Mon, 28 Aug 2017 09:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 W6x5NYyaIk6I for ; Mon, 28 Aug 2017 09:29:18 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D5F1321B6 for ; Mon, 28 Aug 2017 09:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14578; q=dns/txt; s=iport; t=1503937757; x=1505147357; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Fy0QtQHF3H2dbV9Ak1GB5maAIThD/7PebeIBpNjxnl4=; b=LCkzzMM2TjUJHd6TCGEJEUJ0ogVWMhhQ9zrhgImWDADgSwUd2n2HlbMK gTN4pIEtqQQatZ0N02Jd3ZGF4zbxWLswckWNo0t/sbLl5uij/OrrP1pkq 5KjXW7DWN/p2Jwsw6DF11YXkeB370JPEqmjPqcmhXBhfqaS10sL05Ls5N Q=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAACCQ6RZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFY4UdJB0IneVLw6CBAcaDYRKTwKEPRgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEWC0gDAw0LCxgqAgInMAcMBgIBARCKFQgQsQyCJ4tjAQEIAQEBA?= =?us-ascii?q?RUPgyqBMYMHeysLgj01hDkWDoMrgmEFigaWXoQ0giGBAYERgkWJGoIShWaDWSS?= =?us-ascii?q?Gc5Y9HziBDTIhCBwVSYUYHBmBTQM+NogogjcJAQEB?=
X-IronPort-AV: E=Sophos;i="5.41,442,1498521600"; d="asc'?scan'208";a="654238115"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 16:29:12 +0000
Received: from [10.61.221.60] ([10.61.221.60]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7SGTBCB001083; Mon, 28 Aug 2017 16:29:12 GMT
To: jordi.palet@consulintel.es, mtgvenue@ietf.org
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
From: Eliot Lear
Message-ID: <78048bf0-506c-042f-4037-af4e1b4e3217@cisco.com>
Date: Mon, 28 Aug 2017 18:29:13 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IB1IIa8Nmwqg0Wqjfvaopj5jwR9N4imxB"
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 16:29:20 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IB1IIa8Nmwqg0Wqjfvaopj5jwR9N4imxB
Content-Type: multipart/mixed; boundary="EFc1VcQF0iToDmqh6sFjMlBc41B1tb9OO";
protected-headers="v1"
From: Eliot Lear
To: jordi.palet@consulintel.es, mtgvenue@ietf.org
Message-ID: <78048bf0-506c-042f-4037-af4e1b4e3217@cisco.com>
Subject: Re: [Mtgvenue] Working Group Last Call on
draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com>
<20170824215413.t62453rhn7ht64ep@mx4.yitter.info>
In-Reply-To:
--EFc1VcQF0iToDmqh6sFjMlBc41B1tb9OO
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Hi Jordi,
I agree that the team do a pretty good job on this issue without anyone
actually saying anything.=C2=A0 Put another way, it hasn't really been th=
e
painpoint.=C2=A0 In that sense, this might argue to demote the requiremen=
t to
"Important" and continue to trust the judgment of people like Jim.
Eliot
On 8/28/17 4:00 PM, JORDI PALET MARTINEZ wrote:
> Regarding the filtering text =E2=80=A6 and also other mandatory require=
ments.
>
> 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 o=
thers 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 th=
e IAOC.
>
> So, in my opinion, the ideal will be to have somehow a text that instea=
d of mandatory means that in case of discrepancies with our =E2=80=9Cmeet=
ings spirit=E2=80=9D or =E2=80=9Climit situations=E2=80=9D, the IAOC will=
consult the community.
>
> In section 5.1, instead of process, maybe =E2=80=9Con-site survey team=E2=
=80=9D? This is a very well stablished process which proven to be efficie=
nt. You may want to read the intro (and may be also section 12 & 13) in m=
y document https://datatracker.ietf.org/doc/draft-palet-ietf-meeting-netw=
ork-requirements
>
> Regards,
> Jordi
> =20
>
> -----Mensaje original-----
> De: Mtgvenue en nombre de Eliot Lear
> Responder a:
> Fecha: lunes, 28 de agosto de 2017, 15:31
> Para: Andrew Sullivan ,
> Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-i=
aoc-venue-selection-process-08
>
> Hi Andrew,
> =20
> Thanks for your comments. Please see below:
> =20
> =20
> On 8/24/17 11:54 PM, Andrew Sullivan wrote:
> > Hi,
> >
> > Though just under the wire, I have read -08. I think it is in pr=
etty
> > good shape. I still have some comments, but I think they're most=
ly
> > easy to deal with and this document could probably go to IETF LC
> > without addressing any of them. Thanks to everyone who has worke=
d 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 I=
ETF
> > Hotels, and Overflow Hotels are listed in the Hotel needs. Perha=
ps
> > this definition helps:
> >
> > Overflow Hotels:
> > One or more hotels, usually in close proximity to the Fac=
ility,
> > where the IETF has negotiated a group rate for the purpos=
es of
> > the meeting. Of particular note is that overflow hotels =
usually
> > are not connected to the IETF network and do not use IETF=
SSIDs.
> =20
> So added.
> >
> > 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 nu=
mber of
> > criteria below, one mandatory and others important, to allo=
w 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, s=
o
> > perhaps it ought to be removed.
> =20
> I think we have been back and forth on this, and I need to hear fro=
m
> others. Perhaps we need to reword this along the lines of, =E2=80=9C=
because we
> like to test out our own systems, and because we need to securely s=
tay
> in contact with customers, partners, and companies, we seek unfette=
red
> access to the Internet. The more a Venue uses filtering, the less=
> attractive it will be to the IETF."
> =20
> ???
> =20
> >
> > 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 suffici=
ent
> > 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 motivate=
d
> > 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 simultaneou=
s
> > sessions at, that meeting." I don't feel super strongly about th=
is
> > one, however, and I could live with the existing language.
> =20
> Ok.
> =20
> >
> > o The venue MUST provide unfiltered access to the Internet, t=
o the
> > extent permitted by governing laws and regulations.
> >
> > In my reading, this says that we have to have unfiltered access e=
xcept
> > 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 i=
t
> > 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=
=2E
> >
> > 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, the=
n it
> > is not a permissible Venue. I am aware that this stronger versio=
n of
> > the requirement might mean that places where we claim to have had=
> > successful meetings could not be considered again. I suggest tha=
t
> > either means that the criterion as written is not really Mandator=
y, or
> > else that we have defined "successful meeting" more selectively t=
han
> > perhaps we ought to have done.
> =20
> I am neutral on this, but do need to hear from others in order to
> recommend how to best proceed.
> =20
> >
> > 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 cr=
eate
> > 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.
> =20
> How about this:
> =20
> Furthermore, it may be appropriate for the IASA to assist those who=
, as
> a result, have been inconvenienced in some way.
> =20
> =20
> >
> > I'm a little surprised, in 3.2.3, to find both support technologi=
es
> > 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 w=
ere
> > downgraded too quickly. The hotel and guestroom network is prett=
y
> > clearly Important, at least historically, though I will note that=
the
> > NOC seems to have to make heroic efforts every time the guest roo=
m
> > network is bad.
> =20
> 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.
> =20
> >
> > In section 5.1, I find this sentence to be surprising:
> >
> > Four years out, a process identifies cities that might be cand=
idates
> > for meetings.
> >
> > Surely what we mean is that some person or group of people identi=
fies
> > the cities, probably by running through some process. Normally I=
> > would probably find this sort of locution merely ugly, but I thin=
k
> > that part of what got this WG going was some dissatisfaction in t=
he
> > community about who did what and why, so I'd prefer not to make t=
his
> > 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 n=
ice
> > to fix it.
> =20
> What would you like in its place? If the issue is the word "proces=
s",
> we can point to the Meetings Committee or IAD or IASA, but that str=
ikes
> me as equally vague.
> =20
> =20
> >
> > 5.4 a says "Only options that meet all Mandatory labeled criteria=
> > might be recommended." Maybe this could be clearer as "The Meeti=
ngs
> > Committee MUST NOT recommend an option unless it meets all Mandat=
ory
> > criteria"?
> I'm okay with that except hat I'd rather not use the normative lang=
uage
> in order to be more specific about the Meetings Committee versus th=
e
> IASA (so I use "will not").
> =20
> >
> > NITS:
> >
> > Section 3.2: "than another that meets less=E2=80=A6" s/less/fewer=
=2E
> =20
> Fixed.
> =20
> >
> > 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 ho=
ur
> > away. This is probably either Facility environs or just Venue. =
I
> > suspect the former is what's meant.
> Facility environs.
> > I think this sentence needs to be fixed (I think the i.e. has som=
ehow
> > broken the syntax):
> >
> > It is desirable to enter into a multi-event contract with the
> > Facility and IETF Hotels to optimize meeting and attendee bene=
fits,
> > i.e., reduce administrative costs and reduce direct attendee c=
osts,
> > 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 r=
educe
> > administrative costs, reduce direct attendee costs, or both.
> >
> Ok! Will take.
> =20
> Thanks again,
> =20
> Eliot
> =20
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
> =20
>
>
>
> **********************************************
> 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 disc=
losure, 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 recipi=
ent be aware that any disclosure, copying, distribution or use of the con=
tents of this information, even if partially, including attached files, i=
s strictly prohibited, will be considered a criminal offense, so you must=
reply to the original sender to inform about this communication and dele=
te it.
>
>
>
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
--EFc1VcQF0iToDmqh6sFjMlBc41B1tb9OO--
--IB1IIa8Nmwqg0Wqjfvaopj5jwR9N4imxB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJZpETZAAoJEIe2a0bZ0nozJ4oH/Ranv17/HB9XOdNH+iBOiZfO
a9aCMJhrYCrW6OFNsJx3Y5Spu4Zrj9WFaki+XGUfL2pD0SzmG4e60FbPKUHEaglP
4FD107AjDfl/D+yQ9ipJb8OBonR6on8n/M+3xRToBgdShxHm9l3CiYB4vkE4fMNR
npfqKFrKoBfISoUEt39B2K5noO8ButVAbf7YPfOPcgp6ztPdrc4fxQz0Im3cxzdE
YAaffXbw4E3anOmsh7DXDnixJn6w9b/LuIwsxa5bBN/9YM5pqFfhidoHiVE8UWTe
qsc4/BQCA5CYxpYFL77ndOTscUkt2ft8XFoJ6K1zel73XaJAj22KzgHPFzd0BB8=
=/epl
-----END PGP SIGNATURE-----
--IB1IIa8Nmwqg0Wqjfvaopj5jwR9N4imxB--
From nobody Mon Aug 28 10:09:58 2017
Return-Path:
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 1826813234B for ; Mon, 28 Aug 2017 10:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=aV7CkpMa; dkim=pass (1024-bit key) header.d=yitter.info header.b=NWh9BJye
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 w7cIEkRDdQby for ; Mon, 28 Aug 2017 10:09:55 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D43513218E for ; Mon, 28 Aug 2017 10:09:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 094F6BB807 for ; Mon, 28 Aug 2017 17:09:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503940194; bh=4d4GUePvC1DV6Vg00xH5mm2X5a7NCbKdAs3Yak1C8II=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aV7CkpMaKQ1khwkx8gjpITCZ9CaIUnok9IFGq+SvOFDfTEwkyZwFu/XB9sRDJ7OIQ fMF5qVCFrIStHf/XPYDrtNaH88zilrI0rHh7/A9rvmbGtW1qIQddCz11DXYXkJtXjK BskuC6wJ8wzr4rRx7oXeDpwGYUFd7R4YKnyMsnLI=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4atLG_8myCO for ; Mon, 28 Aug 2017 17:09:52 +0000 (UTC)
Date: Mon, 28 Aug 2017 13:09:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503940192; bh=4d4GUePvC1DV6Vg00xH5mm2X5a7NCbKdAs3Yak1C8II=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NWh9BJyeLQ8zSVgtFwd/fKdLVgIn7W8xo6YIYGC7fecxYiSCS5l1vKm6332cvdD6h zKNAPBSkLCPxgKacp6MTUxDWKByosKIGDUTaNGs5S59Fi2+xaK3LCfRPQUBpcZ6gFc i5flnIxGlvosZ8moMIIGPf7T0oCcWvMQY5PSXZMA=
From: Andrew Sullivan
To: mtgvenue@ietf.org
Message-ID: <20170828170950.lyr6u34eqtxexhi3@mx4.yitter.info>
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info> <20170828155812.j5oq5ufc466rwq2f@mx4.yitter.info> <99280BC4-2885-4B22-9E8E-70D8374CCE64@consulintel.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <99280BC4-2885-4B22-9E8E-70D8374CCE64@consulintel.es>
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 17:09:57 -0000
On Mon, Aug 28, 2017 at 06:26:42PM +0200, JORDI PALET MARTINEZ wrote:
> 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).
>
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
ajs@anvilwalrusden.com
From nobody Mon Aug 28 10:42:59 2017
Return-Path:
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 2A022132949 for ; Mon, 28 Aug 2017 10:42:58 -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 TycvV3EWlSrk for ; Mon, 28 Aug 2017 10:42:56 -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 97AEC132946 for ; Mon, 28 Aug 2017 10:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1503942173; x=1504546973; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=b+1iYxAghHeIO1rivD/0vbwiR 19NhksNZRNd0+JZOjE=; b=iHon7pnJT/Vm1Qx1qawYiq5HucwvbOfYNm7UdJ+VU wgJSdSGnvdXgi3xEXKEtVEBITWcLMSNTQOFmhtqZ11zC/9e0nQuFl8aVGZ68nG4H aeHa+NUTAl2SzTGj6oh20C0bSaci0oRZf9eR8hjY/mxkCPFKm9cT4NZWnMRsAaLc cg=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Rnd0Y9kv5QPk9bHI391a1hJN4EP9BT8wDk7QDJAOLf4oaIRkZ8m9GWmma2gy xKRjvBvNBDMkhra2/QoDmqNXUANBmkWs6+TlGd/G3C9jXTaO4I0lhQ7ZC L04Mh70L2eI+0MezkvwWdaA0hHKFjfhsbaggTYKvScgR9j6VfsSMvM=;
X-MDAV-Processed: mail.consulintel.es, Mon, 28 Aug 2017 19:42:53 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 28 Aug 2017 19:42:52 +0200
Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005530172.msg for ; Mon, 28 Aug 2017 19:42:52 +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:170828:md50005530172::WP6dxLhtuws13CnM:00000C1G
X-Return-Path: prvs=141354c2ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: mtgvenue@ietf.org
User-Agent: Microsoft-MacOutlook/f.25.0.170815
Date: Mon, 28 Aug 2017 19:42:50 +0200
From: JORDI PALET MARTINEZ
To:
Message-ID: <676B3981-187B-44B8-99B5-884D475CA25A@consulintel.es>
Thread-Topic: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
References: <86001E72-F6B4-4B75-B5E0-13043BCE56E4@qti.qualcomm.com> <20170824215413.t62453rhn7ht64ep@mx4.yitter.info> <20170828155812.j5oq5ufc466rwq2f@mx4.yitter.info> <99280BC4-2885-4B22-9E8E-70D8374CCE64@consulintel.es> <20170828170950.lyr6u34eqtxexhi3@mx4.yitter.info>
In-Reply-To: <20170828170950.lyr6u34eqtxexhi3@mx4.yitter.info>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At:
Subject: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-venue-selection-process-08
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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Aug 2017 17:42:58 -0000
Yes, for the wheelchair accessibility, not for the meeting rooms, if we put=
that in the extreme case and let me explain that.
Let=E2=80=99s suppose that a couple of the meeting rooms are smaller than w=
hat we actually require, but there are double of them and they are connecte=
d with a built-in audio-video system which allows to execute the meetings w=
ith the same results, just different =E2=80=9Csetup=E2=80=9D. Should that e=
xclude 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
=20
-----Mensaje original-----
De: Mtgvenue en nombre de Andrew Sullivan
Responder a:
Fecha: lunes, 28 de agosto de 2017, 19:10
Para:
Asunto: Re: [Mtgvenue] Working Group Last Call on draft-ietf-mtgvenue-iaoc-=
venue-selection-process-08
On Mon, Aug 28, 2017 at 06:26:42PM +0200, JORDI PALET MARTINEZ wrote:
> Obviously, number 3 in your possibilities, is a case for a venue to b=
e 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 com=
mittee/IAOC can have some degree of judgement, can keep working. So I=E2=80=
=99m saying that we should try to avoid any mandatory criterion (your possi=
bility 2).
>=20
=20
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?
=20
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.
=20
Best regards,
=20
A
=20
--=20
Andrew Sullivan
ajs@anvilwalrusden.com
=20
_______________________________________________
Mtgvenue mailing list
Mtgvenue@ietf.org
https://www.ietf.org/mailman/listinfo/mtgvenue
=20
**********************************************
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 con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.
From nobody Mon Aug 28 10:50:23 2017
Return-Path:
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 31F901321D8 for ; Mon, 28 Aug 2017 10:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=WTsEbVOH; dkim=pass (1024-bit key) header.d=yitter.info header.b=ATxLzKKe
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 p_zJNfGeA3Wt for ; Mon, 28 Aug 2017 10:50:20 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB97413218E for ; Mon, 28 Aug 2017 10:50:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D3994BB807 for