[Mtgvenue] Terminology issue in mtgvenue

"Pete Resnick" <resnick@episteme.net> Fri, 19 October 2018 21:38 UTC

Return-Path: <resnick@episteme.net>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C24B3130DF4; Fri, 19 Oct 2018 14:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xddZxqHUi2Ek; Fri, 19 Oct 2018 14:38:24 -0700 (PDT)
Received: from episteme.net (episteme.net []) by ietfa.amsl.com (Postfix) with ESMTP id E2C69130DEB; Fri, 19 Oct 2018 14:38:23 -0700 (PDT)
Received: from localhost (localhost []) by episteme.net (Postfix) with ESMTP id 8582B6B29A42; Fri, 19 Oct 2018 16:38:23 -0500 (CDT)
Received: from episteme.net ([]) by localhost (episteme.net []) (amavisd-new, port 10024) with ESMTP id YYts5aX4p-8P; Fri, 19 Oct 2018 16:38:21 -0500 (CDT)
Received: from [] (episteme.net []) by episteme.net (Postfix) with ESMTPSA id 8D5856B29A37; Fri, 19 Oct 2018 16:38:21 -0500 (CDT)
From: "Pete Resnick" <resnick@episteme.net>
To: iasa20@ietf.org
Cc: mtgvenue@ietf.org
Date: Fri, 19 Oct 2018 16:38:19 -0500
X-Mailer: MailMate (1.12r5523)
Message-ID: <8F025819-6D43-4D09-858E-0866532FEBDC@episteme.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/R_FuuPJiULW4GpVFdJtuieaSBhM>
Subject: [Mtgvenue] 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: Fri, 19 Oct 2018 21:38:26 -0000

IASA 2.0 folks:

With my mtgvenue chair hat on: An issue has come up over in mtgvenue 
that I think really needs to be resolved by iasa20, and in particular 
not by the mtgvenue folks alone.

The Venue Selection document, 
refers to "IASA" throughout. When written, the document presumed that we 
were working under IASA 1.0, and had references to RFC 4071. When our 
documents got to AUTH48, we realized that it was going to come out right 
on the heels of the IASA 2.0 docs and that it would be silly to publish 
only to have to turn around and fix things. The initial suggestion in 
mtgvenue was to pretty much do a global replace of "IASA" with "IETF 
LLC" (with some other editorial changes). The document editor's version 
with those edits is here: 
<https://www.rfc-editor.org/authors/rfc8491-auth48diff.html>. However, a 
few folks (and in particular, folks who are active in iasa20) noted that 
in fact "IASA" was correct, because under IASA 2.0, the LLC is under 
IASA, and that using "LLC" might be incorrect in some instances. 
Conversely, some folks thought that "LLC" was a clearer reference. As 
that discussion has evolved, your faithful mtgvenue chair is no longer 
sure that we've gotten this exactly right. On top of that, Alissa has 
indicated that it's probably better to have iasa20 figure out what 
terminology is appropriate to refer to the assorted entities, for the 
sake of all documents, not just mtgvenue's.

So, I would ask that the iasa20 WG review the above two documents and 
let us know whether we've got it right or wrong, and generally let us 
know which terminology should be used in which circumstances. I'm sure 
mtgvenue folks will pipe up with their concerns, but guidance should 
really be coming from a discussion in iasa20.

BTW: Don't worry about the fact that the document is in AUTH48 or 
whether it will need a new Last Call or whatever. Let's get the document 
correct first, and then we'll figure out what process knobs, lights, and 
buttons need to be operated.


Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best