Re: [Mtgvenue] Last Call: <draft-ietf-mtgvenue-meeting-policy-04.txt> (High level guidance for the meeting policy of the IETF) to Best Current Practice

[Suresh Krishnan <[e-mail]>]

Hi Andrew,
  Thanks for your comments. Just one point inline.

> On Apr 18, 2018, at 9:34 PM, Andrew Sullivan <[e-mail]> wrote:
> 
> Dear IESG,
> 
> On Thu, Apr 05, 2018 at 01:12:40PM -0700, The IESG wrote:
>> 
>> The IESG has received a request from the Meeting Venue WG (mtgvenue) to
>> consider the following document: - 'High level guidance for the meeting
>> policy of the IETF'
>>  <draft-ietf-mtgvenue-meeting-policy-04.txt> as Best Current Practice
> 
> In a recent discussion, the IAOC came to realise that the documents
> draft-ietf-mtgvenue-iaoc-venue-selection-process and
> draft-ietf-mtgvenue-meeting-policy may be in some tension.  One of
> them requires the IASA to balance meeting venues over time, and the
> other has requirements that a meeting must meet.
> 
> One possible difficulty that arises from the combination is if one
> region turns out to be vastly more expensive than others.  In that
> case, some criteria for each venue may not be met in one region.  The
> result might also be financially ruinous for the IETF in general.
> 
> The current IAOC interprets the drafts such that any of the criteria
> except those in section 3.1 of
> draft-ietf-mtgvenue-iaoc-venue-selection-process may be traded against
> any other, over several years if need be, in order to meet the
> geographic distribution policy described in
> draft-ietf-mtgvenue-meeting-policy.  

Personally, I think the above interpretation is accurate. I did add some text in meeting-policy (below) to try to clarify this but can further refine/augment this text if you think it would be helpful.

"  While the typical cycle in an IETF year may be a
   meeting in North America in March, a meeting in Europe in July, and a
   meeting in Asia on November, the 1-1-1 policy does not mandate such a
   cycle, as long as the distribution to these regions over multiple
   years is roughly equal."

Thanks
Suresh