Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11
Eliot Lear <lear@cisco.com> Mon, 29 January 2018 22:07 UTC
Return-Path: <lear@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BA612D7E7; Mon, 29 Jan 2018 14:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KDHL-W084jIQ; Mon, 29 Jan 2018 14:07:10 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8621200C5; Mon, 29 Jan 2018 14:07:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13345; q=dns/txt; s=iport; t=1517263629; x=1518473229; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=37tF9zf6yIkn7N/3R4qqYRWbc+Dx2hSPF/aPi35/Kbw=; b=alS4rY+31q5SSirtcklyzKFLrKHP+sOBhpRsDkg7Vp4ZmP+gojvwoCpk +38S1GbiCIVaMuTjcP5i0E1buUhERUulaWXAZOW23wDXPY5if3zOW9Gy2 lrEOcffZlHSmJrllM78InphS53Bfl/vjQFT8/SWt4vuon+CzttYsQE+Hm 4=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COAABtmm9a/xbLJq1TCRkBAQEBAQEBAQEBAQEHAQEBAQGEKHWECIokdI95l0QVggIHAyOFGAKDDRgBAQEBAQEBAQJrKIUjAQEBAwEjUgQQCQIOBgQVFQICVwYBDAgBARABihgIEIgEnXGCJ4plAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhFSFVCmDBYMvAoEsGwNHH4JYgmUFiwCBb4VOh1aKAYRhgjKBBYEhjC6CG4Yhg3Emh1aNYooAgTwfOYFQMxoIGxU9giuCVBwZgW5AjQOCSwEBAQ
X-IronPort-AV: E=Sophos; i="5.46,432,1511827200"; d="asc'?scan'208"; a="1733359"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2018 22:07:04 +0000
Received: from [10.61.98.118] (dhcp-10-61-98-118.cisco.com [10.61.98.118]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0TM74PD024827; Mon, 29 Jan 2018 22:07:04 GMT
To: Pete Resnick <presnick@qti.qualcomm.com>, Dan Romascanu <dromasca@gmail.com>
Cc: gen-art@ietf.org, mtgvenue@ietf.org, ietf@ietf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process.all@ietf.org
References: <151681599994.22697.16969006332176223005@ietfa.amsl.com> <EA611862-03E6-4E6E-8221-20EC57E47D98@qti.qualcomm.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <8316bd79-56b8-a3e5-a481-b977f97351cd@cisco.com>
Date: Mon, 29 Jan 2018 23:07:03 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <EA611862-03E6-4E6E-8221-20EC57E47D98@qti.qualcomm.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="H8udKJE4qarg6fvSO8PAW5jQHbtgLrobU"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/450m160DWfMTzvJt-hkypI4vdyk>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 22:07:13 -0000
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
- [Gen-art] Genart last call review of draft-ietf-m… Dan Romascanu
- Re: [Gen-art] Genart last call review of draft-ie… Pete Resnick
- Re: [Gen-art] Genart last call review of draft-ie… Dan Romascanu
- Re: [Gen-art] Genart last call review of draft-ie… Eliot Lear
- Re: [Gen-art] Genart last call review of draft-ie… Alissa Cooper
- Re: [Gen-art] Genart last call review of draft-ie… Dan Romascanu
- Re: [Gen-art] Genart last call review of draft-ie… Eliot Lear
- Re: [Gen-art] Genart last call review of draft-ie… Eliot Lear
- Re: [Gen-art] Genart last call review of draft-ie… Eliot Lear