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. - +1 (858)651-4478
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
