Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

[Pete Resnick <[e-mail]>]

Dan,

Thanks so much for the thorough review. I'll try to get each of these 
into the issues list. Comments inline:

On 24 Jan 2018, at 11:46, Dan Romascanu wrote:

> Reviewer: Dan Romascanu
> Review result: Ready with Issues
>
> 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/

That seems like a perfectly reasonable change. Unless I hear objections 
from others, let's do it.

> - 'where the IETF guest room
> allocations are negotiated' - do we mean to say 'where IETF guest room 
> rates
> are applied'?

It's not just the rates, but also the number of rooms reserved. This 
seems just editorial to me, though probably worth addressing. I'm glad 
to have you or Eliot suggest text to clarify.

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

Interesting. I suppose "SSID" could turn out to be anachronistic. I 
don't think there would be any objection to generalizing the text. 
Eliot, will you take a stab at this?

> 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

I understand your point: We do not necessarily have "connecting to the 
IETF network" as a requirement for the IETF Hotel; rather, they must 
meet the Internet Access criteria. I think this one should be addressed 
to be consistent with the resolution of the previous issue.

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

I think that's a reasonable change; I believe it matches the intent of 
the WG.

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

Good catch. The bullet was written from the point of view of the local 
attendees, but I think it's reasonable to make note of remote attendees 
in this context. (It does say, "not limited to", but it makes sense to 
make this one explicit.)

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

"Cost" is often thought of as monetary cost. "Burden" is saying that if 
the travel requires that you row your own canoe 100km over to the 
island, or if getting a visa requires that you submit yourself at the 
embassy for exploratory surgery, that should probably disqualify a 
venue. ;-) Either way, it is left to the judgment of IASA to make sure 
that the burden is reasonable. Unless I hear others, I suggest we leave 
this one alone.

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

Conformance with local accessibility laws and regulations may not be 
identical with actual accessibility. This simply says that IASA should 
take that into account.

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

I tend to agree, particularly if 3.1 is rewritten as you suggest. Unless 
someone sees a subtlety both of us are missing, that can probably be 
deleted.

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

I don't think the MUST significantly changes the meaning, so I'm 
ambivalent about the change. Since this text was put in to address a 
comment in AD Evaluation, I'm inclined to hear from Alissa.

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

Yes, I believe the first occurrence of "Secretariat" moved in an edit, 
thereby dropping the "IETF". It probably wouldn't hurt to put "IETF" in 
front of all of them.

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

4.4 is the approval. 5.1 is the selection. I don't think that's a 
problem. Perhaps change "approves" to "gives final approval of"? But I'm 
not sure that's necessary.

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

Ah, so you're saying that the dates are first researched by the 
Secretariat. Is that true? If so, it could be clarified.

> 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

I always read "travel risks" as identical with the "economic, health, 
and safety risks" mentioned in 3.2.1. Do you think we should change the 
text?

> Nits/editorial comments:
>
> 1. In Section 1, expand SSID

Sure, pending your above comment on section 1.

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

No objection to any of those.

Thanks again Dan. Excellent review.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]