[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11
From:       Eliot Lear <lear () cisco ! com>
Date:       2018-01-29 22:07:03
Message-ID: 8316bd79-56b8-a3e5-a481-b977f97351cd () cisco ! com
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


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



["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]