Hi Pete and thanks Dan for the review. Please see below. On 29.01.18 19:12, Pete Resnick wrote: > 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. How about "where IETF guest room block allocations are negotiated and contracted"? > >> - '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? The point is that the IETF establishes its own network services at these hotels. How about- where "network services managed by the IASA (e.g., the "IETF" SSID) are available"? > >> 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. Right. I can invert 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./ > > 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.) The line in question is as follows: This includes, but is not limited to, native and unmodified IPv4 and IPv6 connectivity, global reachability, and no additional limitation that would materially impact their Internet use. How about: This includes, but is not limited to, native and unmodified IPv4 and IPv6 connectivity, global reachability, and no additional limitation that would materially impact their Internet use. > > >> 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. > So noted. >> 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. Waiting on that as well. > >> 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. Fixed. > >> 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. Also noted. > >> 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. Just for information: this change was explicitly made because the IASA is an umbrella function under which other functions are likely to shift – be that the Secretariat or other. > >> 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? Added text based on Dan's next message. > >> Nits/editorial comments: >> >> 1. In Section 1, expand SSID > > Sure, pending your above comment on section 1. Editorially I don't think this needs expansion. The test for that is this: if we were to list the expansion of that alone, nobody outside of someone who attends IEEE 802 would know what it means. But everyone knows what a SSID is. > >> 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 The references require a cleanup in the back of the XML. This will happen between me and the publication process. >> >> 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. Corrected. >> >> 4. also in Section 2: "Bar BOF" can be referred by RFC 6771 (also >> include in >> Informational References) Added. >> >> 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 -- ok. >> >> 6. Section 4.6: >> >> s/The meetings budget is managed by the IAD/The IAD manages the meetings >> budget./ ok. > > No objection to any of those. > > Thanks again Dan. Excellent review. > > pr
Attachment:
signature.asc
Description: OpenPGP digital signature