[Mtgvenue] Alvaro Retana's No Objection on draft-ietf-mtgvenue-meeting-policy-06: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 06 June 2018 16:44 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: mtgvenue@ietf.org
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF1130F79; Wed, 6 Jun 2018 09:44:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-mtgvenue-meeting-policy@ietf.org, Charles Eckel <eckelcu@cisco.com>, mtgvenue-chairs@ietf.org, mtgvenue@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152830349321.6354.15716971538916281021.idtracker@ietfa.amsl.com>
Date: Wed, 06 Jun 2018 09:44:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/Y2CnTAFdaSPc2AllD3P_ogEybJ0>
Subject: [Mtgvenue] Alvaro Retana's No Objection on draft-ietf-mtgvenue-meeting-policy-06: (with COMMENT)
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.26
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2018 16:45:11 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-mtgvenue-meeting-policy-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Documenting this policy is important and useful.  Making the policy clear for
future implementers is even more so.

(1) §2 (The 1-1-1-* meeting policy) talks about "exploratory meeting
proposals", but the process to be followed is not clear.  Looking at the
proposed text to Martin's comment [1]:

   The timing and frequency of future exploratory meetings will be based on
   IETF consensus as determined by the IETF chair. Once a meeting proposal is
   initiated, the IESG will make a decision in consultation with the Internet
   Administrative Support Activity (IASA) to ensure that the proposal can be
   realistically implemented.

It is not clear to me what should happen if I, for example, would like the IETF
to consider an exploratory meeting somewhere.  The text talks about both IETF
consensus and the IESG making a decision -- it seems to me that the IESG role
"to ensure that the proposal can be realistically implemented" may be a nice
first step before asking the community for feedback -- but I can see how the
process could also be the other way around: if there is no consensus then don't
even think about implementation.  Please clarify.

To all this, should I make my proposal for an exploratory meeting to the IESG,
the IETF Chair, the IASA, the community (which list?)...?

(2) §4 (Re-evaluation and changes to this policy) says that "this policy needs
to be periodically evaluated and revised to ensure that the stated goals
continue to be met".  Which stated goals?

The only goal (or objective/intent/criteria) explicitly mentioned as one is in
this text from §1: "The IETF currently strives to have a 1-1-1-* meeting policy
[IETFMEET] where the goal is to distribute the meetings equally between North
America, Europe, and Asia.  These are the locations most of the IETF
participants have come from in the recent past."

The text above is not clear because it says that the "goal is to distribute the
meetings equally between North America, Europe, and Asia"...but [interpreting a
little] I think the real intent might have been "to distribute the meetings
equally between...the locations most of the IETF participants have come from". 
Is that the intent?  If not, then re-evaluating with the objective to maintain
the meetings in North America, Europe and Asia makes no sense.  To be clear, if
that distribution is the result of the periodic evaluation, then nothing should
change -- I'm not raising a point about the regions mentioned, but about the
clarity of what the goal is.

(2a) Note also that the text in §4 goes on to say that "the criteria that are
to be met need to be agreed upon by the community prior to initiating a
revision of this document".  I think that there are two (independent) things
that can be revised: the policy (should it be 1-1-1 or 3-2-1 or ??), and the
criteria used to determine the distribution.  Based on the aspirational nature
of the document, the policy should be able to be changed following the general
guidelines ("distribute the meetings equally between...the locations most of
the IETF participants have come from") without changing the criteria (which is
what would most likely lead to an update of the document).

Having statements about updating policy and criteria/document in the same
paragraph, I think, confuses the evaluation needs going forward.  Separating
and clarifying them should help.

(3) §3 (Implementation of the policy)

   As mentioned in [I-D.ietf-mtgvenue-iaoc-venue-selection-process], the
   IASA will also be responsible

   o  to assist the community in the development of detailed meeting
   criteria that are feasible and implementable, and

I couldn't find a place where I-D.ietf-mtgvenue-iaoc-venue-selection-process
mentions that.

(4) I think the I-D.ietf-mtgvenue-iaoc-venue-selection-process reference should
be Normative.

(5) Is the intent for this document and
I-D.ietf-mtgvenue-iaoc-venue-selection-process to be part of the same BCP?  I
would think so, but I didn't see that mentioned an the writeups.

[1] https://mailarchive.ietf.org/arch/msg/mtgvenue/t1TbS4qgrz7UF9dF6VGe2M-kAEw