Subject: [Mtgvenue] Last Call: <draft-ietf-mtgvenue-iaoc-venue-selection-process-13.txt> (IETF Plenary Meeting Venue Selection Process) to Best Current Practice

From: The IESG <[email-masked]>
Date: Thu, 05 Apr 2018 13:12:08 -0700

The IESG has received a request from the Meeting Venue WG (mtgvenue) to
consider the following document: - 'IETF Plenary Meeting Venue Selection
Process'
  <draft-ietf-mtgvenue-iaoc-venue-selection-process-13.txt> as Best Current
  Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-04-19. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   The IASA has responsibility for arranging IETF plenary meeting Venue
   selection and operation.  This memo specifies IETF community
   requirements for meeting venues, including hotels and meeting room
   space.  It directs the IASA to make available additional process
   documents around that describe the current meeting selection process.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Apr 2018 13:29:24 -0400

Thanks for putting this document together.  I have one overall comment and a couple of nits.

I think that an overall goal is missing.  We try to share the load among IETF participants.  That is the reason we rotate between North America, Europe, and Asia-Pacific.  Without this goal, the IETF might select the one perfect location and hold every meeting there.

The document uses "Venue" and "venue" in many, many places.  I cannot figure out what the presence or absence of the capital letter is trying to convey.

Section 4 says:

   The IETF Community works best when it is best informed.

It might be better to say:

   The IETF Community works best when it is well informed.

In Section 1, please update the last paragraph to reference RFC 8174 in addition to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
   all capitals, as shown here.

Russ

> On Apr 5, 2018, at 4:12 PM, The IESG <[email-masked]> wrote:
> 
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Apr 2018 14:23:11 -0500

Russ,

Thanks for the review. On your overall comment:

On 17 Apr 2018, at 12:29, Russ Housley wrote:

> I think that an overall goal is missing.  We try to share the load 
> among IETF participants.  That is the reason we rotate between North 
> America, Europe, and Asia-Pacific.  Without this goal, the IETF might 
> select the one perfect location and hold every meeting there.

Do you not think that the paragraph in 2.1 addresses this?

       We meet in different locations globally, in order to spread the
       difficulty and cost of travel among active participants, 
balancing
       travel time and expense across the regions in which IETF
       participants are based.

Or did you mean that you wanted it stated up front more clearly?

For the editorial bits, I will leave Eliot to address those.

pr

> The document uses "Venue" and "venue" in many, many places.  I cannot 
> figure out what the presence or absence of the capital letter is 
> trying to convey.
>
>
> Section 4 says:
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Apr 2018 16:48:10 -0400

Pete:
>   difficulty and cost of travel among active participants, balancing
This comes from the core values section, which has not RC 2119 language.  I see nothing about it in the other parts of the document that have RFC2119 language.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2018 23:15:14 +0200

Hi Russ,

On 17.04.18 22:48, Russ Housley wrote:
> This comes from the core values section, which has not RC 2119
> language.  I see nothing about it in the other parts of the document
> that have RFC2119 language.

Isn't that what draft-ietf-mtgvenue-meeting-policy-04.txt is for?
>
> Russ 
>
>
>
> _______________________________________________
> Mtgvenue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mtgvenue

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Apr 2018 18:12:53 -0400

> Isn't that what draft-ietf-mtgvenue-meeting-policy-04.txt is for?

A reference in this document would be very helpful to the reader.  My preference would be a MUST statement that includes the reference.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Apr 2018 08:37:36 +0200

Hi Russ,

Assuming nobody has an objection, I've updated my local editor's copy to
include a normative reference (I don't think it matters which it is in
this case, but at least the RFC Editor will group the two docs).

Regarding the editorials, my proposal is to downcase not only Venue, but
the h's in hotels and the F in facility, as the capitalization does not
in fact distinguish anything normatively.

If that is acceptable, to everyone, I can publish an update with the
changes on Monday.

Eliot

On 18.04.18 00:12, Russ Housley wrote:
> A reference in this document would be very helpful to the reader.  My
> preference would be a MUST statement that includes the reference.
>
> Russ
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 19 Apr 2018 15:16:00 -0500

> this case, but at least the RFC Editor will group the two docs).

That makes sense to me.

> in fact distinguish anything normatively.

Actually, I found the capitalization helpful, because it was a nice hint 
to me that they were terms defined in section 1.

> If that is acceptable, to everyone, I can publish an update with the

Since the document is in "Waiting for AD Go-Ahead", please wait for 
Alissa's go-ahead to post a new version.

pr

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Apr 2018 07:10:57 +0200

>> this case, but at least the RFC Editor will group the two docs).

Oops!  Except that if the IESG really has serious concerns about the the
other document (and it seems that at least one member does), I'd just
assume leave the reference informational.

Eliot