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

Hi John,

I agree with you that there is a relationship between the two documents, although it’s not clear that it’s a normative one. I’ve pulled draft-ietf-mtgvenue-iaoc-venue-selection-process from this week’s IESG telechat to provide time to process draft-ietf-mtgvenue-meeting-policy and make some of the other changes to venue-selection-process that have surfaced in the recent threads.

Best,
Alissa

> On Feb 5, 2018, at 4:46 PM, John C Klensin <john-ietf@jck.com> 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.
> 
> (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.
> 
> 
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue