IETF Logo Mail Archive

Re: [Mtgvenue] [Iasa20] Terminology issue in mtgvenue

Eliot Lear <lear@cisco.com> Tue, 06 November 2018 14:58 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 BDAA1130E51; Tue, 6 Nov 2018 06:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 9MZ4iIiZs_Vr; Tue, 6 Nov 2018 06:58:50 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C6C130DFE; Tue, 6 Nov 2018 06:58:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2462; q=dns/txt; s=iport; t=1541516329; x=1542725929; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=fcMnquEN9j4wNtitwTqR1wBXtY0S7Gu5rO3ohK5MPwk=; b=ednQ4XsnQ6qOIDfZ+3eLl3Tx3BF0SWyBCMGDq4SAsEx8gxbyACf3l+yp woPDNRMXFijIFp9D/uweDrr97fbZAbflF02qy84dZcuGk1Oe7hVEUBfLb JOPTyW2d2x9ecEKTV6tUDkbAKKx9dzOgxh3lO9Esw89xutY1iNivLoA4H o=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAAAeq+Fb/xjFo0hkGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBgzghEoQdiHeNRpcwgXoIBYRsAoN6NQwNAQMBAQIBAQJtKIU7AQUjVhALGCoCAlcGAQwIAQGDHQGCAagGgS6KIw+CbYkiggCBESeCPS6IAoJXAo9tj0oJhBqBcIsCBhiJUocSl0uBRQMzgVUzGggbFYMokGUzA44jAQE
X-IronPort-AV: E=Sophos;i="5.54,472,1534809600"; d="asc'?scan'208";a="95842633"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 14:58:43 +0000
Received: from [10.75.233.55] (hkidc-vpn-client-233-55.cisco.com [10.75.233.55]) by bgl-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wA6Ewf13026144; Tue, 6 Nov 2018 14:58:42 GMT
To: "Livingood, Jason" <Jason_Livingood@comcast.com>, Alissa Cooper <alissa@cooperw.in>
Cc: "mtgvenue@ietf.org" <mtgvenue@ietf.org>, "iasa20@ietf.org" <iasa20@ietf.org>, Pete Resnick <resnick@episteme.net>
References: <57CCDBD1-B66A-4C96-A51A-E15F1EF7EC60@cable.comcast.com>
From: Eliot Lear <lear@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ==
Message-ID: <598d913a-fc28-28d5-a86d-d5930251c2a0@cisco.com>
Date: Tue, 06 Nov 2018 21:58:40 +0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <57CCDBD1-B66A-4C96-A51A-E15F1EF7EC60@cable.comcast.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="fkxRTy7uAjJt4DP4X2NX8t9KqxRsb6b4j"
X-Outbound-SMTP-Client: 10.75.233.55, hkidc-vpn-client-233-55.cisco.com
X-Outbound-Node: bgl-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/ClXqsYfaT4TdBNwbk0eAByBoTpk>
Subject: Re: [Mtgvenue] [Iasa20] Terminology issue in mtgvenue
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 14:58:52 -0000

Hi Jason,


On 05.11.18 23:01, Livingood, Jason wrote:
> As a side note, one thing the diff does is drops the reference to RFC 4071's general appeals process. The diff proposes dropping that and the associated normative reference to RFC 4071. This might be one thing worth doing in the draft because there does not seem like there's much need to specifically call out the appeals process per se, and that appeals process is specified in IASA-related or other IETF process-related documents.

I've asked the RFC Editor to move the mtgvenue document back to
MISSREF.  Whether we reference it or not in the end will depend on
whether there is any sort of appeals process in the iasa-struct doc.  So
long as that document doesn't stall, we're not in a hurry.

Eliot

v2.23.0 | Report a Bug | By Email