Re: [HT-rt] HR-RT Review of draft-ietf-mtgvenue-iaoc-venue-selection-process

Beatrice Martini <mail@beatricemartini.it> Sun, 22 April 2018 16:36 UTC

Return-Path: <mail@beatricemartini.it>
X-Original-To: hr-rt@ietfa.amsl.com
Delivered-To: hr-rt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890EE126D45 for <hr-rt@ietfa.amsl.com>; Sun, 22 Apr 2018 09:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.185
X-Spam-Level:
X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_GREY=0.424] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=beatricemartini-it.20150623.gappssmtp.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 2NADcOC65_ra for <hr-rt@ietfa.amsl.com>; Sun, 22 Apr 2018 09:36:37 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 D2E94126C0F for <hr-rt@irtf.org>; Sun, 22 Apr 2018 09:36:36 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id d11-v6so7877698iof.11 for <hr-rt@irtf.org>; Sun, 22 Apr 2018 09:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beatricemartini-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M2vOuVYbF7xSb19GVTZk9WBZOFWTIJV/I+wN5I8zLa8=; b=TIR410pdcOXtjpsi13ErXwID/R8SI31fL8NqKNrMEJHfBIWUpRHxePGc018ifNhoXp zNg8Vc6SYRpumpvru7sXDXdU5SEU+pi75oDWpiveW6QfJZA4f7Jo/YFZ6crX3bQznBh9 oUiTystcAMlq2897W5zXWBEoknQZM7ANjSSjc9eKW5eW9EpCYUQrIbL3GjjuZFEaNPE9 cBqKDHb6W8g/AiJFonxm1oE3z/eH3E9bPblEf4hTeOyCigam44v2zIelbUCiISMcOOxp NBd7lw8BBtp7lJXzRNlSYasbRkt3LWs0yQlzf3wrgjCis4JPQa5A9uAERdijcb9Mi/eh 4YAQ==
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=M2vOuVYbF7xSb19GVTZk9WBZOFWTIJV/I+wN5I8zLa8=; b=aJNXXWLgIBiwaKnGpAdWv6hGOYeOEBA+3gjPTHaoq/zDJOy56ji7oRGmkRsyLyP/PZ GauMaYY3dYdnPu5ojkVT/cqSqDIXvDwgu8+ughDCWiXqyIh5pj/ycjV7BOXyP1H+8Lpc cADjT4XAbmG8CIeGOhkrGKolvZ2VWrzWgdSfakkJ/pwxkdmWaMqkvUDnhu4V6J0PJDLf 5q62FtrSN/pETwYbmabQD3O0Ru9keEVF8IzRmXKjK2AXfg0cVwxdwXxYIhPrRo5EuX0g Uv7YRHpg1YY1hppO+VqzV3pB/Qo2ndkBdHn3TpvSsWjfBwcFyQFZv7+xX/ru4Sj+8BQn WrIQ==
X-Gm-Message-State: ALQs6tCWsAY09js8SWKdMJdKnWnsBAOfhZtu11C7LNGtnERhFNsMtYXH Npcw6MpOQjxVbdMMBsjCEqZWtnY2wFdPqqvTSMqVGQ==
X-Google-Smtp-Source: AIpwx4+YuK3PrtU9L5ZMg/QtMasYwSxWee0jiOzFL8JkQSQ2vrLAN9pSrOeJJNpCfNhtjVLZ02xvMNodLgnzo/7hARQ=
X-Received: by 2002:a6b:591:: with SMTP id 139-v6mr3234426iof.282.1524414995828; Sun, 22 Apr 2018 09:36:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:840e:0:0:0:0:0 with HTTP; Sun, 22 Apr 2018 09:36:35 -0700 (PDT)
In-Reply-To: <22946590-de79-a2ab-9cf8-be9bcec50b73@cisco.com>
References: <d0739bb2-626e-8aa3-f22f-d51b07dfdacf@digitaldissidents.org> <21952.1524157167@obiwan.sandelman.ca> <7B17FF2E-4393-4644-998B-16462F71A00F@qti.qualcomm.com> <22946590-de79-a2ab-9cf8-be9bcec50b73@cisco.com>
From: Beatrice Martini <mail@beatricemartini.it>
Date: Sun, 22 Apr 2018 18:36:35 +0200
Message-ID: <CA+0Hr7vFLcp+sWVz8CiCwY32VMrun0dbsfAz5JMOjvaNqjG5jg@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Niels ten Oever <lists@digitaldissidents.org>, hr-rt@irtf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary="000000000000512f46056a728631"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hr-rt/zo7zp3QDmwlGewikB7syhWwkMLs>
Subject: Re: [HT-rt] HR-RT Review of draft-ietf-mtgvenue-iaoc-venue-selection-process
X-BeenThere: hr-rt@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Human Rights Protocol Considerations Review Team <hr-rt.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hr-rt/>
List-Post: <mailto:hr-rt@irtf.org>
List-Help: <mailto:hr-rt-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Apr 2018 16:36:40 -0000

Hi Eliot,

Thank you for your feedback.

I will copy a few relevant excerpts from your message and follow up
accordingly.

>  How about the following:
>
>  <t>The cost of guest rooms, meeting space, meeting food and
>  beverage
>  is affordable, within the norms of business travel, and
>  there are at least some inexpensive and safe
>  alternative accommodations within easy reach to the Facility.

I very much appreciate the note on alternative accommodations.

About the smoke-free meeting spaces:
> I cannot remember a time when there was smoking at
> an IETF meeting, except perhaps in a bar.

When talking with Niels about the importance of accessibility to all event
spaces, it was mentioned that some IETF sessions are sometimes organized in
bar spaces. This is the detail that prompted us to suggest a specific note
about smoke-free spaces.

The policy about smoke-free spaces is something that usually depends on the
local legislation.

For example: I live in Berlin, where most bars can allow smoking in the
evening. It is not uncommon to attend a tech meetup hosted in a bar, and
find out that smoke is allowed in the space, because of how the bar is
managed. I have seen many people who were planning to join an event go back
home disheartened because of this issue.

So we thought it was worth specifying that the IETF organizers should make
sure that all sessions are scheduled in spaces where no smoke is allowed,
e.g. should double check with the venue management what are their own
policies in this regard and if they can meet the IEFT requirements.

> It is desirable that preferably the Facility, or failing that the IETF
> Hotel(s), offer childcare services.

Having organized international events in a few different countries, I can
say that it is very rare to find hotels and event spaces that provide
childcare services by default.

What is common is for the organizers of an event to contact the venue
and/or hotel and ask if they already have a list of trusted contacts to
hire licensed professionals able to provide the service on request. The
number of kids expected to attend would determine the suitable number of
carers needed. The carer(s) would come to the venue and set it up with toys
and/or any other specific supply needed to entertain the kids.

If the event space/hotel does not already have reference contacts for this
type of service, further information can usually be found through other
local service providers.

>>>> We invite to consider the addition of one item to Section 3.3 Other
>>>> Considerations.
>>>>
>>>> Section 3.2.2 Basic Venue Criteria says:
>>>> "The Facility is accessible or reasonable accommodations can be made to
>>>> allow access by people with disabilities."
>>>>
>>>> This is great!
>>>> At the same time, sometimes one person's required accommodation might
>>>> create a barrier for someone else. For example, the same session could
>>>> be attended by one participant with a guide dog, and another
>>>> participant
>>>> with a severe allergy to dogs.
>>>>
>>>> It would be ideal if the document could mention a consideration on this
>>>> type of conflicting requirements that might occur. For example, it
>>>> could
>>>> say that, in the full respect of everyone's needs, the organizing team
>>>> will aim to find the most suitable solution on a case by case basis.
>>>>
>>>> This statement should also include information about who / what team
>>>> can
>>>> be contacted to ask for information in case of need.
>>
>> I think adding a short informational note to that bullet in 3.2.2
>> makes sense. I'll again leave it to Eliot to see if he can come up
>> with something.

> <editor>

> I am not clear on whether this text should go into this draft or into
> the IASA's documentation.  The question I have is  this: is this a venue
> selection criterion?  If so, and if IASA is reasonably aware of the
> conflict, then I think it goes in this document.

It is not a criterion. It is a consideration that specify how the event
organizers would manage conflicts that could possibly emerge from the
following item of "Section 3.2.2 Basic Venue Criteria": "The Facility is
accessible or reasonable accommodations can be made to allow access by
people with disabilities."

> I would suggest an
>  example would help us understand that.

You mean like the example mentioned in our message? That one is a real life
example, just happened at a work meeting I was running last week :)

> If not, then I think what is
> being asked for is a directive to IASA in this document to provide
> attendees information about the above.

As said, it is not a criterion. But it is an important information for:

* The team who selects the venue, to be aware of how the accessibility
criteria can sometime unfold, and prepare to address potential issues that
might arise;
* Participants, so that they know what to expect from the event
space/organization.

So, if not in this document's "Section 3.3 Other Considerations", a note on
this type of conflict and how it will be addressed could be included in:

* The documentation related to the event management on site;
* Information provided to participants to inform them about venue
accessibility.

Thank you!

Best,
Beatrice

On 20 April 2018 at 18:44, Eliot Lear <lear@cisco.com> wrote:

> Hi Pete, Niels, and Michael,
>
> Please see below:
>
>
> On 19.04.18 23:08, Pete Resnick wrote:
> >> I suggest you reword your suggestion to:
> >>    "We would like to facilitate the onsite or remote participation of
> >>    anyone who wants to be involved.  Widespread participation
> >>    contributes to the diversity of perspectives represented in the
> >> working sessions"
> >>
> >> the problem with the "and" in the sentence is that the sentence can
> >> otherwise be parsed
> >> to say that we only want to facilitate partition from those who
> >> contribute to
> >> increased diversity.
> >
> > I have to agree with Michael's suggestion. In addition to the possible
> > ambiguity, there was pretty explicit consensus in the WG that the
> > objective was to facilitate people who participants that want to
> > participate, and explicitly not to use venue selection for purposes of
> > outreach. Michael's reformulation makes that a bit clearer. Does that
> > satisfy your concern?
>
> Propose to include the second sentence based on Niels' concurrence.
>
> >
> >>> 2)
> >>> We find that the current draft is not totally consistent in regards to
> >>> the affordability of participation.
> >>
> >> This is my intepretation.
> >>
> >>> Initially, it acknowledges that many participants are self-funded, and
> >>> that budget solutions should be available. That's great.
> >>
> >>> From Section 2.  Venue Selection Objectives/ 2.1. Core Values:
> >>> "Economics:
> >>> Meeting attendees participate as individuals. While many are
> >>> underwritten by employers or sponsors, many are self-funded.  In order
> >>> to reduce participation costs and travel effort, we therefore seek
> >>> locations that provide convenient budget alternatives for food and
> >>> lodging, and which minimize travel segments from major airports to the
> >>> Venue.  Within reason, budget should not be a barrier to
> >>> accommodation."
> >>
> >>> But then, in Section 3.2.2, things sounds less affordable.
> >>
> >>> From Section 3.2.2 Basic Venue Criteria:
> >>> "The cost of guest rooms, meeting space, meeting food and beverage is
> >>> affordable, within the norms of business travel."
> >>
> >>> "Business travel" has commonly a higher cost than "self-funded budget
> >>> travel".
> >>
> >> The intention is that the *venue* (primary hotel) should not be so
> >> expensive as to be prohibitively expensive to even those on "business
> >> travel".  There are locations (resorts in really exotic locations) where
> >> the nightly price of room is like $500/night.  The intention is to rule
> >> those out.
> >> As a self-funded individual, I accept that I can't often afford to
> >> stay at
> >> the primary hotel, but I will find something acceptable within a few
> >> blocks.  So that's how section 2 and 3.2.2 are reconciled.
> >
> > Michael's explanation is correct, but I take your point that "guest
> > rooms" in the second bullet of 3.2.2 sounds like the combination of
> > rooms in the IETF Hotels, Overflow Hotels, and other nearby local
> > accommodations. Perhaps we can clarify. Let's see if Eliot has any
> > thoughts.
>
> How about the following:
>
>           <t>The cost of guest rooms, meeting space, meeting food and
> beverage
>             is affordable, within the norms of business travel,    and
>              there are at least some inexpensive and safe
>             alternative  accommodations within easy reach to the Facility.
>
>
> >
> >>> 3)
> >>> We invite to consider the addition of a few items to Section 3.2.2.
> >>> Basic Venue Criteria.
> >>
> >>> 3.1)
> >>> "All Meeting Venues should have at least one gender neutral restroom
> >>> with stalls on each floor."
> >>
> >> I'd like to support adding this as aspirational, but it's gonna be two
> >> hotel renovation cycles before it can be found often enough to be a
> >> reasonable criteria.
> >
> > Given that the 3.1 criteria are those for which IASA MUST NOT enter
> > into a contract if they are missing, I don't see how we can make this
> > mandatory at this point, unless IASA can tell us that a sufficient
> > number of Facilities meet this criterion already. Perhaps something
> > along these lines could be added to 3.2.2, but even there I think we'd
> > want input that there are such Facilities available, lest the criteria
> > simply be ignored.
> >
> >> On the topic of being family friendly,  the major thing we can do to
> >> support families is to outside of the mtgvenue, and is with the nomcom
> >> eligibility criteria.
> >
> > Agreed Michael. :-)
> >
> > On to the rest of your comments, Niels:
> >
> >>> 3.2)
> >>> "The Meeting Venue should have at least one dedicated infant feeding
> >>> room and one family restroom."
> >
> > I presume you mean "Facility" here and not "Meeting Venue", correct?
> > Like the gender neutral restrooms, I think we probably want to hear
> > from IASA that this is going to be satisfiable by a reasonable number
> > of Facilities.
> >
> >>> 3.3)
> >>> "The event should be accessible to non-smokers and those with
> >>> respiratory conditions. Therefore all meeting spaces during daytime and
> >>> nighttime should make it possible to fully participate in the scheduled
> >>> activities without being exposed to second-hand smoke."
> >
> > I have no particular concerns about adding this in section 3.3,
> > barring objections.
>
> </editor hat>
> I would go further.  I cannot remember a time when there was smoking at
> an IETF meeting, except perhaps in a bar.  Therefore, I would claim that
> this is an oversight by the working group and an example of a
> requirement that was well understood by the Secretariat long before
> someone came up with the term "mtgvenue".
>
> Therefore, I would reformulate this as follows:
>
>    "The Facility MUST be prohibit indoor smoking.  IETF Hotels and
> Overflow Hotels MUST offer "No Smoking" rooms
>      attendees.
>
> >
> >>> 3.4)
> >
> > There is no section 3.4 in the document. Did you mean for this to go
> > in 3.3?
> >
> >>> We believe that supporting parents with small children attending events
> >>> is a great step forward towards inclusivity.
> >>>
> >>> We would like the document to address this aspect in regards to venue
> >>> requirements.
> >>>
> >>> In particular, it would be helpful for the document to provide
> >>> information about the following:
> >>>
> >>> * Can participants feel comfortable and welcome to have their kid(s)
> >>> with them at the event? If so, are kids under a certain age not allowed
> >>> to be in session rooms?
> >>>
> >>> * Would the venue provide a childcare space and service, like a
> >>> play/activity room managed by a licensed childcare professional? See
> >>> further information about childcare at events at:
> >>> http://geekfeminism.wikia.com/wiki/Childcare
> >>>
> >>> If the organization determines that children should not be allowed to
> >>> access meetings, and/or no childcare space and service can be provided,
> >>> it would anyway be important for the document to acknowledge that the
> >>> organization is aware of the limitation that this would constitute and
> >>> that this might hinder the participation of some attendees.
> >
> > Whether children can be present in meeting rooms sounds like a policy
> > issue beyond the question of venue selection, so I believe is out of
> > scope for the document.
> >
> > As for whether having childcare services available at the Facility or
> > Hotels should go in 3.3, I have no particular concerns about adding
> > it, again, barring objections.
>
> (still no editor hat)
>
>
> My only question is whether these services are commonly offered.
>
> If so,
>
> <editor>
>
> It is desirable that preferably the Facility, or failing that the IETF
> Hotel(s), offer childcare services.
>
>
>
> >
> >>> 4)
> >>> We invite to consider the addition of one item to Section 3.3 Other
> >>> Considerations.
> >>>
> >>> Section 3.2.2 Basic Venue Criteria says:
> >>> "The Facility is accessible or reasonable accommodations can be made to
> >>> allow access by people with disabilities."
> >>>
> >>> This is great!
> >>> At the same time, sometimes one person's required accommodation might
> >>> create a barrier for someone else. For example, the same session could
> >>> be attended by one participant with a guide dog, and another
> >>> participant
> >>> with a severe allergy to dogs.
> >>>
> >>> It would be ideal if the document could mention a consideration on this
> >>> type of conflicting requirements that might occur. For example, it
> >>> could
> >>> say that, in the full respect of everyone's needs, the organizing team
> >>> will aim to find the most suitable solution on a case by case basis.
> >>>
> >>> This statement should also include information about who / what team
> >>> can
> >>> be contacted to ask for information in case of need.
> >
> > I think adding a short informational note to that bullet in 3.2.2
> > makes sense. I'll again leave it to Eliot to see if he can come up
> > with something.
>
> <editor>
>
> I am not clear on whether this text should go into this draft or into
> the IASA's documentation.  The question I have is  this: is this a venue
> selection criterion?  If so, and if IASA is reasonably aware of the
> conflict, then I think it goes in this document.  I would suggest an
> example would help us understand that.  If not, then I think what is
> being asked for is a directive to IASA in this document to provide
> attendees information about the above.
>
> Is that about right?
>
> Eliot
>
>
>
>
> >
> >>> 5)
> >>> Correct typo in the title: "3.3. Other Consideraitons"
> >>>
> >>> Edit: "3.3. Other Considerations"
> >
> > Of course.
> >
> > Thanks again for the great comments.
> >
> > pr
> >
>
>
>
> _______________________________________________
> HR-rt mailing list
> HR-rt@irtf.org
> https://www.irtf.org/mailman/listinfo/hr-rt
>
>


-- 
Beatrice Martini
Twitter <https://twitter.com/beatricemartini> / Blog
<http://beatricemartini.it/blog/> / Newsletter <http://eepurl.com/bbDuEn>