Re: [Mtgvenue] Alvaro Retana's No Objection on draft-ietf-mtgvenue-iaoc-venue-selection-process-15: (with COMMENT)

Mary Barnes <mary.ietf.barnes@gmail.com> Thu, 07 June 2018 15:58 UTC

Return-Path: <mary.ietf.barnes@gmail.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 A24E4130F56; Thu, 7 Jun 2018 08:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 iBOLV8AGNrGR; Thu, 7 Jun 2018 08:58:18 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 80C0D130F1C; Thu, 7 Jun 2018 08:58:17 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id d24-v6so15478711lfa.8; Thu, 07 Jun 2018 08:58:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y9YZ2uAjlz8d/0/IUUq5a6fWbGztpzZ2kC6byuhQ4yw=; b=G5qaNDsSKB4DdBcffPVh1Sns2UVGnLfm2GskjQXVXgHxBGOOcSnZw1U48EaZ+I7sak ZAJyxtV660vYo9TKKHHf8yTG3lsCz0+77+NtR7/GqXek7mcQII6wBMmqk5meDkYhiwya zR6ZBnlqy/xrKB9KZ1aKuCaVeT6rrJygbzikmRFOINcKX2bgr4yNJfKCP0cxGgpftJiK Ltm5j/USJFSCq08KAat0ZDkl6jDrNdrvtCEC+YdkqxKE30NFBAuCqHOtFDfiGIyfG+Wh JQunXBCZO5Rb2jv7dpF7hv6QbQSlHO5NnJrJc3LwTaQg45ZI/EDC0V6LNX9M2Z6EVx71 +bLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y9YZ2uAjlz8d/0/IUUq5a6fWbGztpzZ2kC6byuhQ4yw=; b=tCU6DtkZT7IwArcgDAqpF1KDu9wqURfFMWKfSC5rNkEkkODaf/Irau33gIWe/SMpXP 6Hnzt7rfiGUiMmFR43UXXAAXZ6otdnuN1axoy83SzBJ3z2rum1O9tTWXyj21ckHAgsYC 4s4oeJcybZ8IasXWq/mDMVfeUq7Qg5PpW5lRm5J/nXgT8pV67hakbolsgEwUavCL21g4 HpxoPHdSne5a/QYMyfnKDskO40i8lhNcom7BwCOCcEcHlPlgla+BXpWJb0kaUXM2kenK BOruHssO2qd4KpTjYazhie4KS7owka/D+9qDMSRUCpRCVYyEfYDw03XB3FK0sBut8Ygv Q53Q==
X-Gm-Message-State: APt69E0yfkA0876G3FJFduTsv4mQ4rEtHRK4VtXp7o9KD3VOtRL+fzXL q4nASBY1ozv2aqaHoXZIx46DHHDylgmbZF8QCHQ=
X-Google-Smtp-Source: ADUXVKIuK6Km3VEy6bR13s7LM3tYp9AAaD3Iht321oJXQNYORYyPtRJ1/2oqQr40Xd1Qi0efHeK7xQbgge5ruzHPDbU=
X-Received: by 2002:a19:e9d3:: with SMTP id j80-v6mr1743180lfk.129.1528387095762; Thu, 07 Jun 2018 08:58:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:5804:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 08:58:14 -0700 (PDT)
In-Reply-To: <6D1FE14F-6BEE-46A9-A511-77B3E63DD49D@qti.qualcomm.com>
References: <152830294286.6280.13192764028667391463.idtracker@ietfa.amsl.com> <6D1FE14F-6BEE-46A9-A511-77B3E63DD49D@qti.qualcomm.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thu, 7 Jun 2018 10:58:14 -0500
Message-ID: <CAHBDyN4UkgqJY-Dm=0035AxVrXSpY-4hPhK1SV0HEPb7gYmpXw@mail.gmail.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, mtgvenue <mtgvenue@ietf.org>, draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org, The IESG <iesg@ietf.org>, mtgvenue-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ec1c63056e0f595a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/5VBMtFK62BdkKTwJLyEiats6HZE>
Subject: Re: [Mtgvenue] Alvaro Retana's No Objection on draft-ietf-mtgvenue-iaoc-venue-selection-process-15: (with COMMENT)
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 15:58:23 -0000

One point below [MB].

Mary.

On Wed, Jun 6, 2018 at 5:27 PM, Pete Resnick <presnick@qti.qualcomm.com>
wrote:

> Hi Alvaro,
>
> On 6 Jun 2018, at 11:35, Alvaro Retana wrote:
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> (1) The term "participant" is used in several places, sometimes with
> different
> modifiers; for example: active, IETF and regular. Some of the phrases seem
> to
> want to differentiate between them, but that distinction is not clear (for
> example): "in order to spread the difficulty and cost of travel among
> active
> participants, balancing travel time and expense across the regions in which
> IETF participants are based." What is the difference between active and
> IETF
> participants?
>
> Note that "attendee" is also used, in my interpretation, to also mean
> "participant". Is that the intent, or is there a difference?
>
> Clarifying and being consistent would help. I don't think that a
> terminology
> section is needed -- I just want to probe whether the terms were
> differentiated
> on purpose, and, if so, to understand what that differentiation may be.
>
> We'll give these a scrub to make sure they're consistent. My take is:
>
>    -
>
>    "IETF participants" is simply "participants" and, the "IETF" bit
>    should simply be removed.
>    -
>
>    The "where we meet" section mentions "active" participants because we
>    want meetings near people who are currently contributing participants.
>    -
>
>    The "least astonishment" section mentions "regular" participants
>    because we want people who regularly follow or contribute to work to be
>    able to easily discover information.
>    -
>
>    "Attendees" are people who actually show up at a meeting.
>    "Participants" are people who participate in the IETF (whether in person or
>    electronically) who might want to show up at a meeting.
>
> (2) From §2.2 (Venue Selection Non-Objectives)
>
> Maximal attendance:
> While the IETF strives to be as inclusive as possible both online
> and in person, maximal meeting attendance in and of itself is not
> a goal. It would defeat a key goal of meeting if active
> contributors with differing points of view did not have the
> opportunity to resolve their disagreements, no matter how full the
> rooms.
>
> Should maximal attendance by "active contributors" be listed as an
> objective?
> Measuring what that means will not be easy...but that seems to be
> corollary:
> the text above sounds like it says "it doesn't matter how many people show
> up,
> as long as active contributors are there".
>
> I believe that's captured in the "where we meet" section in 2.1.
>
> BTW, following up on my first point, what's the relationship between
> "contributor" and "participant"? Is there a difference between an "active
> contributor" and an "active participant"?
>
> As I indicated above, I think "active contributor" == "active participant".
>
> (3) §3.2 (Important Criteria) says that "when a particular requirement in
> this
> section cannot be met...it may be appropriate for the IASA to assist those
> who,
> as a result, have been inconvenienced in some way."
>
> What does the IASA providing assistance mean? Looking at the criteria,
> would
> (for example) a high cost be considered an inconvenience? Knowing that the
> intent is to spread the burden "over the course of multiple years", who
> determines that inconvenience? How could the IASA assist? Maybe there's
> some
> other purpose for that sentence for which I'm missing context.
>
> For cost, the assistance could come in the form of identifying lower cost
> hotels. For visa issues, the assistance could be in the form of contacting
> local folks to attempt to expedite approval. IASA is expected to weigh the
> inconveniences and take them into account.
>
> (4) §3.2.5 (Food and Beverage)
>
> It is said that an army travels on its stomach. So too does the
> IETF. The following criteria relate to food and beverage.
>
> Personal opinion: unfortunate quote and comparison.
>
> Taken under advisement. Certainly it was intended tongue-in-cheek.
>
> (Interesting read: https://quoteinvestigator.com/2017/10/15/army/ )
>
> ...
> o A range of attendee's health-related and religion-related dietary
> requirements can be satisfied with robust and flexible onsite
> service or through access to an adequate grocery.
>
> o The Facility environs include grocery shopping that will
> accommodate a wide range of dietary requirements, within a
> reasonable walking distance, or conveniently accessible by a short
> taxi, bus, or subway ride, from the Facility and IETF Hotels.
>
> These last two bullets sound almost the same: the difference seems to be in
> calling for "robust and flexible onsite service" in the first one. Maybe
> they
> can be merged.
>
> Reasonable point. We'll see if we can combine.
>
[MB] Please don't.   I don't think we want to belabor the food issue yet
again.   The first bullet gives those that select venues an "out" in terms
of expecting the venue to accommodate the dietary requirements.  Ideally,
the venue should be able to support the requirements.  If not, then we hope
that those that select the venue at least heed the requirements in the
second bullet.   Personally, I have an issue with that "out" and the
general fact that we actually don't consider having food to eat essential
for some attendees when selecting a venue. We have a mandatory requirement
for physical disabilities but none for invisible disabilities (e.g., celiac
disease which is covered by the American Disabilities Act and is considered
equally as impacting on daily life activities as being in wheelchair).
I've have written a whole document describing how we can ensure a venue can
support the requirements.  But, I've pretty much given up the battle.
[/MB]

> (5) I think that the reference to rfc3935 should be a Normative reference
> given
> that it defines why we meet (§2.1).
>
> I don't think someone needs to read the mission statement to understand
> the process described here, nor do I think if there is an update to 3935 it
> is likely to affect this document.
>
> (6) Is the intent for this document and draft-ietf-mtgvenue-meeting-policy
> to
> be part of the same BCP? I would think so, but I didn't see that mentioned
> an
> the writeups.
>
> Good point. That makes sense. I'll review existing BCPs to see if it fits
> in any of them, or just the two belong in one together.
>
> Thanks,
>
> pr
>
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>
>