IETF Logo Mail Archive

[Mtgvenue] document status, the role of the iaoc, and enforceability

Eliot Lear <lear@cisco.com> Fri, 06 January 2017 16:40 UTC

Return-Path: <lear@cisco.com>
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 B3182129B54 for <mtgvenue@ietfa.amsl.com>; Fri, 6 Jan 2017 08:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.622
X-Spam-Level:
X-Spam-Status: No, score=-17.622 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, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, 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 yD7ol2XWKFCs for <mtgvenue@ietfa.amsl.com>; Fri, 6 Jan 2017 08:40:08 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE69129B53 for <mtgvenue@ietf.org>; Fri, 6 Jan 2017 08:40:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1483720808; x=1484930408; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=tj1GIfmMchEKQB3iop3V630T6TzZdLfW32TSviNyueA=; b=gO5G6/57vWNQ49soGeyvloj9/TdrLUL4c4e1RaVARpBgwGlLneE4/LCj bOtnXtCxvTEekx/uTvAnl3VVkFav/mKrVzYl3TSAFP4t75YTZX77qo8BC VRwUuQJt9bKJRTXsos6hM2ehKyqLdLyffbAa8+2VIGplcVqO1o3syflq1 Y=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D9AAAOx29Y/xbLJq1eGQEBAQEBAQEBAQEBBwEBAQEBgzkBAQEBAY9hcqZVggmGIgKCFBQBAgEBAQEBAQFjKIRpBiNmTQICVwcMCAEBEIhcsD+CJYoYAQEBBwIXD4hHCIolgj8fBZsVg2aBfotjgV+IR4Y1klEfODVaEgcUFYZaPYkbAQEB
X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="asc'?scan'208";a="691118690"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2017 16:40:04 +0000
Received: from [10.61.247.161] ([10.61.247.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v06Ge358026145; Fri, 6 Jan 2017 16:40:03 GMT
To: dcrocker@bbiw.net, mtgvenue@ietf.org
References: <148302624729.30218.3797301462532090032.idtracker@ietfa.amsl.com> <e2da432a-1ed8-fd51-be59-70213cd932f6@dcrocker.net>
From: Eliot Lear <lear@cisco.com>
Message-ID: <be74a492-a414-1947-91cc-f8eafabd57f8@cisco.com>
Date: Fri, 06 Jan 2017 17:40:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <e2da432a-1ed8-fd51-be59-70213cd932f6@dcrocker.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="WO0vhKiM3D5tIgKnR9SPfJjCgxVujS60W"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/ZdeYcXv3adpQEuPYXfAvDabki24>
Subject: [Mtgvenue] document status, the role of the iaoc, and enforceability
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2017 16:40:10 -0000

Hi,

IETF leadership tends to use BCPs as a means of enforcement.  That can't
be the case with this document.  It simply is impracticable to rework
contracts based on some sort of appeal, for instance.  At best,
therefore, this is the IETF community's advice to the IAOC about how it
would like venues selected.  At the end of the day, if members of the
community are unhappy with the IAOC's venue selections, the appropriate
recourse is the NOMCOM and not some sort of appeal.  I would like this
further clarified in the document.

Eliot

v2.23.0 | Report a Bug | By Email