Re: [RTG-DIR] [Mtgvenue] Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12

John C Klensin <john-ietf@jck.com> Mon, 05 February 2018 21:46 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5F312DA08; Mon, 5 Feb 2018 13:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLi4ft9hbWXC; Mon, 5 Feb 2018 13:46:29 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8841F12D969; Mon, 5 Feb 2018 13:46:29 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1eioaq-0005vW-6E; Mon, 05 Feb 2018 16:46:28 -0500
Date: Mon, 05 Feb 2018 16:46:23 -0500
From: John C Klensin <john-ietf@jck.com>
To: mtgvenue@ietf.org
cc: rtg-dir@ietf.org, ietf@ietf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process.all@ietf.org
Message-ID: <D123E3DB3501C61987793A7E@PSB>
In-Reply-To: <ce5c3e3b-fb8a-0a29-3569-ab61f5de7da0@gmail.com>
References: <151782868264.5731.15496399706573021777@ietfa.amsl.com> <15F0E669-0195-4315-AAA5-AED71CD6C5B3@qti.qualcomm.com> <ce5c3e3b-fb8a-0a29-3569-ab61f5de7da0@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/jEG-5gpWCUc8ym2ow5WHhjDHs-8>
Subject: Re: [RTG-DIR] [Mtgvenue] Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2018 21:46:32 -0000

Because this thread seems to be where the action is, a brief
summary of comments on another thread [1] that seems to bear on
this Last Call and review and that seems to me to be
complementary to some of the "location" comments on this thread.

(1) Policy and process issues both covered in this document with
sections 2 and at least part of 3 stating/ explaining policies
and 4 and 5 being about process.  That would be ok except
insofar as draft-ietf-mtgvenue-meeting-policy is supposed to
cover the policy issues but is, in practice, a specification and
explanation of what it calls 1-1-1*.   If
draft-ietf-mtgvenue-iaoc-venue-selection-process is intended to
operate within the constraints imposed by
draft-ietf-mtgvenue-meeting-policy, that is a normative
dependency, not something that can be ignored as irrelevant to
the process outlined in this document.  Conversely, if it can be
ignored in the process of considering and evaluating venues,
then draft-ietf-mtgvenue-meeting-policy is either irrelevant
(and should be discarded) or is an orthogonal explanatory
document that should be Informational, not a BCP.  FWIW, I
question whether the material cited as "{MeetingNet]" is really
informative rather than a normative part of the "Internet
Access" Core Value.

(2) I note that, independent of how it comes out, the recent
discussion of interaction between remote participants and
meeting locations is ultimately a discussion about large-area
geographical policies that are not covered by 1-1-1*.  If the
topic is properly discussed in the context of the current
document, the boundary between it and
draft-ietf-mtgvenue-meeting-policy is even less clear than
discussed above.

(3) The criterion of proximity to a significant number of actual
participants appears to have been dropped completely and without
comment.  Perhaps the vaguely-worded "familiar with both the
locale and the IETF" statement in Section 3.3 is intended to be
a substitute, but it is not clear to me what it means or, more
specifically, how "familiar" is to be gauged.  I would have
happy leaving that to the IAOC if they were open and transparent
about what they have done in each case, who is making key
decisions or being relied on for advice, etc.  But that level of
transparency has basically existed; probably if it was more
common, we really wouldn't need a document like this one.

(4) My main conclusion from the above is that the IESG final
review and voting on this document should be postponed and the
evaluation period left open until
draft-ietf-mtgvenue-meeting-policy is ready for evaluation so
that they can be evaluated together and the community identify
any policy or procedural topics that slip through the cracks
between the two and the community believes are worth mentioning,
even as "non-objectives" or relatively unimportant criteria.   I
hope the WG will recommend that to the IESG and/or that the IESG
will make that decision on its own rather than forcing us to
descend into a procedural discussion of whether separating
evaluation of the two is appropriate.

best,
   john

[1] See the thread with Subject "Re: Bangkok and IETF (was: Last
Call draft-ietf-mtgvenue-iaoc-venue-selection-process-11)".   I
am assuming that I do not need to repeat the arguments made on
that thread in detail here.