Last Call Review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11
review-ietf-mtgvenue-iaoc-venue-selection-process-11-genart-lc-romascanu-2018-01-24-00

Request Review of draft-ietf-mtgvenue-iaoc-venue-selection-process
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-01-31
Requested 2018-01-17
Authors Eliot Lear
Draft last updated 2018-01-24
Completed reviews Rtgdir Telechat review of -12 by Stewart Bryant (diff)
Genart Last Call review of -11 by Dan Romascanu (diff)
Secdir Last Call review of -11 by Dacheng Zhang (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-mtgvenue-iaoc-venue-selection-process-11-genart-lc-romascanu-2018-01-24
Reviewed rev. 11 (document currently at 16)
Review result Ready with Issues
Review completed: 2018-01-24

Review
review-ietf-mtgvenue-iaoc-venue-selection-process-11-genart-lc-romascanu-2018-01-24

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mtgvenue-iaoc-venue-selection-process-11
Reviewer: Dan Romascanu
Review Date: 2018-01-24
IETF LC End Date: 2018-01-31
IESG Telechat date: 2018-02-08

Summary:

This is an important document for the IETF process, resulting from many discussions in the IETF and the different associated groups and committees. The memo is well written and reflects these discussions. The comments from the Gen-ART perspective represent a review for clarity and consistency, and not a personal input on the content of the document.   

Major issues:

Minor issues:

1. in Section 1: 

'   IETF Hotels:
      One or more hotels, in close proximity to the Facility, where the
      IETF guest room allocations are negotiated and IETF SSIDs are in
      use.'

a few comments here: 
- taking into account the previous definition of Facility, it looks better s/in close proximity/within or in close proximity/
- 'where the IETF guest room allocations are negotiated' - do we mean to say 'where IETF guest room rates are applied'? 
- 'and IETF SSIDs are in use' : do we really need to include this in the definition of the IETF Hotels and if yes, this is the way to say it? SSID is somehow technology specific, and imposes a restriction on the hotel network (network name) that is not really critical. What is critical is for the participants to have the Internet Access mandatory requirements met in their hotel room, and even this needs not be part of the definition. 

2. Also in Section 1: 

'Of particular note is that overflow hotels usually are
      not connected to the IETF network '

We did not ask the IETF Hotel either to be connected to the IETF network - see also the above

3. Section 2: 

      2.  Avoid meeting in countries with laws that effectively exclude
          people on the basis of race, religion, gender, sexual
          orientation, national origin, or gender identity.

The term 'national origin' has different connotations in different cultures and law systems. Some make a clear distinction between nationality and citizenship. I believe that the intention is to be inclusive, so I suggest: s/national origin, or gender identity./national origin, citizenship, or gender identity./

4. Section 3.1 - the last bullet says nothing about remote access - is this intentional? It should say something also about global reachability from outside for remote participants.

5. Section 3.2.1: 

'Travel to the Venue is acceptable based on cost, time, and burden for participants traveling from multiple regions.'

I am not sure what 'burden' means. I suggest drop 'burden' and just leave 'cost and time'.

6. Section 3.2.2 - the last bullet (about accessibility) seems to be redundant with the mentioning of accessibility in the first paragraph of the same section.  

7. Section 3.2.3 - the second bullet seems to be redundant with the last bullet in section 3.1 (Mandatory Criteria). In any case, this 'need' seems to be mandatory, not only 'important'. 

8. Section 4: 

'It is anticipated that
   those roles will evolve.  The IASA is responsible for keeping the
   community informed in this regard, and MAY do so without updating
   this memo.'

I would be a little concerned if some of the key roles would change without this document being updated. I understand the need to be flexible, but we need to put some limits. Maybe at least emphasize the need to inform the community by a MUST. For example: 

'It is anticipated that
   those roles will evolve.  The IASA MUST keep the
   community informed in this regard, and MAY do so without updating
   this memo.'

9. Section 4.3 - be clear that by 'Secretariat' what is meant is 'IETF Secretariat'. 

10. Two statements about the responsibility on setting the meetings dates seem to be contradictory or at least confusing: 

in section 4.4: 'It (DR - the IAOC) approves the IETF meetings calendar.'
in section 5.1: 'The IASA selects regions, cities and dates for meetings' 

Is really the IASA responsible with setting or proposing dates? I thought that the calendar is set years in advance taking into account different criteria (avoiding conflicts with other SDOs calendars, avoiding major holidays, etc.)

11. I am not sure that it is clear what is meant by 'travel risks' in 5.2 and 5.4. In any case, wherever we are talking about sharing with the community information about 'travel risks' we need also to mention if there are any exceptions from the Important Criteria detailed in Section 3.2


Nits/editorial comments: 

1. In Section 1, expand SSID

2. In Section 2: 

'We meet to pursue the IETF’s mission [RFC3935]' - RFC 3935 is also BCP 95, the other BCPs are indicated by both BCP and RFC numbers, this should be the same

3. also in Section 2: s/Meeting attendees need unfiltered access to the general Internet and our corporate networks./Meeting attendees need unfiltered access to the general Internet and their corporate networks.

4. also in Section 2: "Bar BOF" can be referred by RFC 6771 (also include in Informational References)

5. section 3.2.3 - unless there is a special reason I suggest to delete the double-dashes before and after -- or at an acceptable --

6. Section 4.6: 

s/The meetings budget is managed by the IAD/The IAD manages the meetings budget./