Subject: [Mtgvenue] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

From: Dan Romascanu <[email-masked]>
Date: Wed, 24 Jan 2018 09:46:39 -0800

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/ - 'where the IETF guest room
allocations are negotiated' - do we mean to say 'where IETF guest room rates
are applied'? - '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.

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

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

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.

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

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.

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

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

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

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'

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

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

Nits/editorial comments:

1. In Section 1, expand SSID

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

---

From: Pete Resnick <[email-masked]>
Date: Mon, 29 Jan 2018 12:12:22 -0600

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:

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

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?

> We did not ask the IETF Hotel either to be connected to the IETF 

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.

> origin, or gender identity./national origin, citizenship, or gender 

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

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

> I am not sure what 'burden' means. I suggest drop 'burden' and just 

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

> with the mentioning of accessibility in the first paragraph of the 

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

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

>    community informed in this regard, and MAY do so without updating

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

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.

> in section 5.1: 'The IASA selects regions, cities and dates for 

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.

> (avoiding conflicts with other SDOs calendars, avoiding major 

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

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

> 1. In Section 1, expand SSID

Sure, pending your above comment on section 1.

> s/The meetings budget is managed by the IAD/The IAD manages the 

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

---

From: Dan Romascanu <[email-masked]>
Date: Mon, 29 Jan 2018 20:26:32 +0200

Hi Pete,

Thanks for your answers and for addressing my concerns.

Here are a few answers to your returned questions:

On Mon, Jan 29, 2018 at 8:12 PM, Pete Resnick <[email-masked]>
wrote:

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

what about 'where a substantial number of rooms are allocated for the IETF
meeting participants at negotiated rates'?

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

I am still unsure about the vagueness of 'burden'. Based on your
explanation, it may be appropriate to change: s/cost, time and burden/cost,
time and formalities/?

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

let us just say  "economic, health, and safety risks"  than.

Regards,

Dan

---

From: Eliot Lear <[email-masked]>
Date: Mon, 29 Jan 2018 23:07:03 +0100

Hi Pete and thanks Dan for the review.  Please see below.

On 29.01.18 19:12, Pete Resnick wrote:
> That seems like a perfectly reasonable change. Unless I hear
> objections from others, let's do it.
>

How about "where IETF guest room block allocations are negotiated and
contracted"?

> 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"?

> 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.
> 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.
> "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
> that the burden is reasonable. Unless I hear others, I suggest we
> leave this one alone.
>
> 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.

> comment in AD Evaluation, I'm inclined to hear from Alissa.

Waiting on that as well.

> thereby dropping the "IETF". It probably wouldn't hurt to put "IETF"
> in front of all of them.

Fixed.
> problem. Perhaps change "approves" to "gives final approval of"? But
> I'm not sure that's necessary.

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

> and safety risks" mentioned in 3.2.1. Do you think we should change
> the text?

Added text based on Dan's next message.
> 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.
>> other BCPs are indicated by both BCP and RFC numbers, this should be

The references require a cleanup in the back of the XML.  This will
happen between me and the publication process.

>> to the general Internet and their corporate networks.

Corrected.

>> Informational References)

Added.
>> double-dashes before and after -- or at an acceptable --

ok.
>> s/The meetings budget is managed by the IAD/The IAD manages the meetings

ok.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 30 Jan 2018 10:54:24 -0500

> On Jan 29, 2018, at 1:12 PM, Pete Resnick <[email-masked]> wrote:
> 
> 
>> 8. Section 4:
>> 
>> 'It is anticipated that
> 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.

Perhaps the concern could be addressed by saying “without first updating this memo”? The point I raised is that this document shouldn’t gate the ability for the roles to change, but certainly if they do change the document should be updated (or obsoleted by a new document) to match the reality.

Thanks,
Alissa

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 30 Jan 2018 18:02:44 +0200

On Tue, Jan 30, 2018 at 5:54 PM, Alissa Cooper <[email-masked]> wrote:

> Perhaps the concern could be addressed by saying “without first updating
> this memo”? The point I raised is that this document shouldn’t gate the
> ability for the roles to change, but certainly if they do change the
> document should be updated (or obsoleted by a new document) to match the
> reality.
>
> Thanks,
> Alissa

That would be fine with me.

Regards,

Dan

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Jan 2018 18:32:49 +0100

Ok.  I'll push an update based on these changes in the next few days,
barring additional comments.

On 30.01.18 17:02, Dan Romascanu wrote:
>
>
>
> On Tue, Jan 30, 2018 at 5:54 PM, Alissa Cooper <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > On Jan 29, 2018, at 1:12 PM, Pete Resnick
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >
>     >> 8. Section 4:
>     >>
>     >> 'It is anticipated that
>     ambivalent about the change. Since this text was put in to address
>     a comment in AD Evaluation, I'm inclined to hear from Alissa.
>
>     Perhaps the concern could be addressed by saying “without first
>     updating this memo”? The point I raised is that this document
>     shouldn’t gate the ability for the roles to change, but certainly
>     if they do change the document should be updated (or obsoleted by
>     a new document) to match the reality.
>
>     Thanks,
>     Alissa
>
>
>