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

Pete Resnick <presnick@qti.qualcomm.com> Tue, 06 February 2018 02:30 UTC

Return-Path: <presnick@qti.qualcomm.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 6D9D9124239; Mon, 5 Feb 2018 18:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 vBsOLOz797U5; Mon, 5 Feb 2018 18:30:30 -0800 (PST)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBA3120725; Mon, 5 Feb 2018 18:30:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1517884230; x=1549420230; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=oTu/kG3OlbYZ4PQgYKcT6R6biyWbq7asUAHDHKCZqoo=; b=KS2yeKz41cIfFEraNSuT81IK0ZWJn0fYBh5dbCQ/R4jCurMpI1HhK8do diQgIm4dqoDSCqhzeaT4rIEMmVcNh8tL8MIfCfx9nxdhP/opdbpf+GT5T +CflSiGRJLtec2cJ+6bsIQQlrdh2w3ct5U1uxBiMeBmuf6z7k6itmxfrq c=;
X-IronPort-AV: E=Sophos;i="5.46,467,1511856000"; d="scan'208,217";a="123545087"
Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by sabertooth01.qualcomm.com with ESMTP; 05 Feb 2018 18:30:29 -0800
X-IronPort-AV: E=McAfee;i="5900,7806,8796"; a="87881734"
X-MGA-submission: MDEpbOMQGu/84EUsheIg0tlNd7L8TSCyy0HTwoZNyzsquGcwyETqHdA5qpUJmUIN4S1Jf7Zv8PBJ7AHhPo+yPvrG+TuTL7rL1Prv4e+cTuigoVobNfDSkLyF+jswh29IU2Z7xxIgt9xrvDgmckYd0481
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/AES256-SHA; 05 Feb 2018 18:30:27 -0800
Received: from [10.110.56.34] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 5 Feb 2018 18:30:18 -0800
From: Pete Resnick <presnick@qti.qualcomm.com>
To: John C Klensin <john-ietf@jck.com>
CC: mtgvenue@ietf.org, rtg-dir@ietf.org, ietf@ietf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process.all@ietf.org
Date: Mon, 05 Feb 2018 18:28:13 -0800
X-Mailer: MailMate (1.10r5443)
Message-ID: <8E176F12-4B25-47F2-A532-2E27B8F82C58@qti.qualcomm.com>
In-Reply-To: <D123E3DB3501C61987793A7E@PSB>
References: <151782868264.5731.15496399706573021777@ietfa.amsl.com> <15F0E669-0195-4315-AAA5-AED71CD6C5B3@qti.qualcomm.com> <ce5c3e3b-fb8a-0a29-3569-ab61f5de7da0@gmail.com> <D123E3DB3501C61987793A7E@PSB>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_2906D9BE-9CA0-4CE7-9441-6A60807F0666_="
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/r-KKpyz3CNtH8m886ObLoFtAcP0>
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: Tue, 06 Feb 2018 02:30:33 -0000

[I may be slow following up to this, as I have a day-job presentation 
tomorrow for which I have to prepare, so fear not if you don't hear from 
me before Wednesday.]

WG Chair, and particularly document shepherd for -selection-process, hat 
firmly on head:

On 5 Feb 2018, at 15:46, John C Klensin wrote:

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

I was following the previous thread, though speaking for myself, I would 
have found it easier if you would have created a new thread instead of 
finding this now in the middle of two different threads on two different 
topics. Not the end of the world by any means. Anyway, on the issues:

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

This document specifies a general policy (or perhaps "principles") for 
venue selection, particularly regarding location, in section 2.1:

       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.

and in section 3.2.1:

     o  Travel to the Venue is acceptable based on cost, time, and 
burden
        for participants traveling from multiple regions.  It is
        anticipated that the burden borne will be generally shared over
        the course of multiple years.

There are a few other location policies/principles in the document, but 
those are the big two.

As far as I can tell, -meeting-policy is simply specifying a more 
limiting instantiation of the above principles: Given the current active 
participants, the 1-1-1* policy is consistent with the policies above. 
In the future, we could change -meeting-policy (e.g., because of a 
change in demographics) and still be consistent with this document, so I 
don't see how it makes sense to have a normative dependence on 
-meeting-policy in this document. The documents don't contradict each 
other, and both are to be executed by IASA.

>   FWIW, I
> question whether the material cited as "{MeetingNet]" is really
> informative rather than a normative part of the "Internet
> Access" Core Value.

As above, [MeetingNet] could change independently of this document, so 
long as the documents do not contradict.

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

Since the remote participants issue is a new (and controversial) one 
during Last Call, I'll leave it, and commentary on this, to the 
sponsoring AD. (You're welcome, Alissa. ;-) )

> (3) The criterion of proximity to a significant number of actual
> participants appears to have been dropped completely and without
> comment.

No, I think you missed it in section 2.1 ("active participants" and 
"regions in which IETF participants are based"). It has not at all been 
dropped, though maybe worded in a way that you don't think captures what 
you want, in which case suggested text would be appreciated.

> Perhaps the vaguely-worded "familiar with both the
> locale and the IETF" statement in Section 3.3 is intended to be
> a substitute

No, that is about asking the secretariat to get advice from people 
familiar with the locale, not about location criteria.

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

This comment seems out of scope for the discussion of this document.

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

Since IMO you got a few of your premises wrong, obviously I don't think 
your conclusion follows. While it might be useful to do the reviews 
together to ensure that there is in fact no dependency between the two 
documents, I believe the WG has not created such a normative dependency, 
and therefore this is not required. The WG has passed both documents to 
our AD at this point, so if you see such a dependency in the current 
documents, that would be a fine Last Call comment on this one in any 
case. In any case, I'll leave it to the responsible AD to make the call 
on how the IESG wishes to evaluate them.

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

I don't consider the issue "procedural". If you find a dependency, we 
want to know that.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478