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

"Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com> Fri, 20 April 2018 22:54 UTC

Return-Path: <Glenn.Deen@nbcuni.com>
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 46269126CD6 for <hr-rt@ietfa.amsl.com>; Fri, 20 Apr 2018 15:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 SZR_2elRGt_N for <hr-rt@ietfa.amsl.com>; Fri, 20 Apr 2018 15:54:02 -0700 (PDT)
Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AC51241F3 for <hr-rt@irtf.org>; Fri, 20 Apr 2018 15:54:02 -0700 (PDT)
Received: from pps.filterd (m0047965.ppops.net [127.0.0.1]) by m0047965.ppops.net-00176a04. (8.16.0.22/8.16.0.22) with SMTP id w3KMrTFG036450 for <hr-rt@irtf.org>; Fri, 20 Apr 2018 18:54:02 -0400
Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0047965.ppops.net-00176a04. with ESMTP id 2hds0j6p5u-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for <hr-rt@irtf.org>; Fri, 20 Apr 2018 18:54:01 -0400
Received: from unknown (HELO potemwp00002.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 20 Apr 2018 15:54:00 -0700
Received: from potemwp00030.mail.tfayd.com (100.124.56.54) by potemwp00009.mail.tfayd.com (100.124.56.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 20 Apr 2018 16:53:59 -0600
Received: from potemwp00029.mail.tfayd.com (100.124.56.53) by potemwp00030.mail.tfayd.com (100.124.56.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 20 Apr 2018 16:53:58 -0600
Received: from potemwp00029.mail.tfayd.com ([100.124.56.53]) by potemwp00029.mail.tfayd.com ([100.124.56.53]) with mapi id 15.01.0669.032; Fri, 20 Apr 2018 16:53:58 -0600
From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
To: Eliot Lear <lear@cisco.com>, Pete Resnick <presnick@qti.qualcomm.com>, Niels ten Oever <lists@digitaldissidents.org>
CC: "hr-rt@irtf.org" <hr-rt@irtf.org>, "draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org" <draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [EXTERNAL] Re: HR-RT Review of draft-ietf-mtgvenue-iaoc-venue-selection-process
Thread-Index: AQHT1//g4eAqZ1xMV06MgAMp86mxTqQI+ceAgAFIjAD///HXgA==
Date: Fri, 20 Apr 2018 22:53:58 +0000
Message-ID: <2F97BE9D-2EC3-499E-BDD4-7B9A05DB77D4@nbcuni.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>
In-Reply-To: <22946590-de79-a2ab-9cf8-be9bcec50b73@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [100.126.25.31]
x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45
Content-Type: multipart/alternative; boundary="_000_2F97BE9D2EC3499EBDD47B9A05DB77D4nbcunicom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-20_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804200228
Archived-At: <https://mailarchive.ietf.org/arch/msg/hr-rt/PozsZJyhsLzEHLhhTxJolai9sD4>
Subject: Re: [HT-rt] [EXTERNAL] Re: 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: Fri, 20 Apr 2018 22:54:07 -0000

My [GD] comments inline...



On 4/20/18, 9:45 AM, "ietf on behalf of Eliot Lear" <ietf-bounces@ietf.org on behalf of lear@cisco.com> wrote:

    >

    >>> 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.



[GD]  This is too vague to properly evaluable against and is why the business-travel norms was used.    There are guidelines for business travel costs that are available that can guide evaluation of the criteria.   However, terms like "inexpensive" , "safe" are very subjective and are not practical to evaluate against when testing the criteria in the document.



It's also hard for IASA to evaluate the safety and cost of accommodations around the venue.  Sources such as hotels.com can be used to obtain a sense of availability of other hotel type accommodations within a distance from the venue - say .5 miles at the time of the evaluation, typically several years before the meeting, these rates are not negotiated or guaranteed to be available during the time of the meeting.  Safety, while quite obviously extremely important, is hard to evaluate for the alternative accommodations without IASA actually visiting them and evaluating them, and conditions may change in the 2-3 years between when the primary venue is vetting and contracted.



Also, what is inexpensive?   The meaning is very variable across regions and travelers.   Remember the goal of the document is to provide the IASA criteria to evaluate venues against. To do that the criteria needs to be as clear as it can be.



The current 3.2.2 text is something that can be evaluated against , the proposed text is not.



Recommend keep the current text.



[/GD]



    >

    >>> 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.



[GD] The document is criteria used by IASA to vet a venue against, not a wish list to communicate to venues.  I do not wish to undermine aspirations, but this document is not the place to capture them.  It's used as an evaluation list IASA vet a venue against to determine if the venue meets the needs of the IETF community to meet at.   Putting it in the document does not serve to communicate the aspirations to the venue as we are not handing the document to the venues being evaluated.



This specific criteria is something that is also not yet very common in venues across the range of places the IETF meets, so we would be having to record nearly all venues as failing this criteria, yet still accepting them as acceptable IETF meeting venues which makes the criteria not very useful in raw terms of our vetting venues since the majority of venue we have and will met at will not pass this test, yet we will be able to hold successful meetings at the venue.   In other words the criteria would need to be ignored in almost every venue we accept.  That leaves it as aspirational only.



I suggest against putting any aspirational criteria in the document.



[/GD]





    >

    >> 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.



[GD].



This is a mix of policy and measurable criteria and hence only part of this should be in the document.



The policy part of it would be for the IESG to declare that IETF meetings are smoke free.  I'm not aware of this ever being explicitly stated, but the entire time since I've attended IETF meetings everyone has treated it as an unwritten policy.   Yet, still it wouldn't hurt for outside of this document that being declared to preemptively deal with the situation if it were to arise.  There may be regional rules that permit smoking in bars and casinos as distinguished from restaurants, we do not seem to have had problems locating venues that have smoking bans in place in restaurants and interior spaces such as corridors.



If there is no issue from the IESG in requiring a Smoke Free meeting venue, then measurable criteria that we could have is perhaps the following text:



    The facility MUST prohibit smoking in meeting rooms, interior common spaces and corridors, indoor lobby bars which are open to common spaces and corridors, and indoor restaurants.  IETF primary and secondary hotels MUST have blocks of rooms designated as "Non Smoking" guest rooms.



[\GD]



    >

    >>> 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.



[GD]

  On whether children are allowed in IETF meeting rooms, that is an IESG policy to set and outside the scope of the document.    If such a policy is set, it will need to take into consideration that events such as newcomers, welcome receptions, and socials do typically have alcohol served and may be subject to country/state regulations and venue policies on children being present.



There is also the consideration that children below a certain age may affect liability insurance.



As well, the Tuesday socials are arranged by the host and it's been at the hosts discretion as to if children are permitted or not, and what are the age restrictions if any.



In any case the policy of children in the IETF meetings proper is outside the scope of venue selection criteria.



  On the issue of child care facilities, the I'm worried about the criteria in the document being clear enough to evaluate against.  I am also concerned that this is beyond the core criteria to have successful meetings that the WG consensus had established for what is included in the document.



  For evaluation, it would be necessary to include things such as what age ranges the criteria needs to be evaluated for: babies;  1-2 year olds; 3-5 yr toddlers; 5-8 elementary age; 8-13; 13-18?    What hotels offer varies widely.   Also would these be during daytime 9-5 hours or the hours of the IETF meeting 8am-9pm?    Do they need to available on weekends as well?   Do meals need to provided?  What about cost? What about children with special needs?



  Also, what about safety ?  Are there requirements for physical safety of the child care facility? What are acceptable check in / check out procedures?  Are there requirements for the child care staff in terms of background checks and training?   Is CPR and first aid training certifications required?  Etc.  These are all very important criteria for parents to know, yet they get very detailed very fast, and I doubt the IASA is prepared to properly evaluate these tests.



What about facility insurance requirements?



I am also concerned about the implications of the IASA indicating that approved child care is available, and then if anything changes or worse if problems happen what responsibility and liability could fall on the IETF.



My overall points are:   1) This is far to vaguely specified to be an evaluation criteria;  2) More specific criteria are beyond the IASA's ability to evaluate; 3) there is potential financial impact and risk to the IETF to approve or indicate that acceptable child care is available.





I recommend against including it.

[/GD]



    >

    >>> 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.





[GD]

I do not think this is venue selection criteria.  It is policy and conflict resolution during the running of the meetings which is outside of selecting a venue.  This document is explicitly about evaluating a venue for suitability,  and not how to perform the in room running of the meeting proper.   Keep in mind this document is used during venue selection to measure if a venue meets the requirements for the IETF community to meet there.   This document is not addressing during meeting practices, policies, or resolution of participant issues.  That’s the role of the IESG which run the meetings.



I recommend not adding it to the document.

[/GD]



-glenn