[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