Subject: Re: [Mtgvenue] I-D Action: draft-baker-mtgvenue-iaoc-venue-selection-process-02.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 25 May 2016 22:41:47 +0000

Passing along, with permission, a private discussion I have had with George Michelson.

> On May 24, 2016, at 11:01 PM, George Michaelson <[email-masked]> wrote:
> 
> I have a serious problem with the IAOC making that a MUST. Its a
> strong preference, but we need to be prepared to dig a hole sometimes.
> If we lost a good venue because technically we have to self-fund from
> capital, thats bad.
> 
> maybe its 'subject to review' in future: needs explicit approval in
> some mechanism.
> 
> -G
> 
> On Wed, May 25, 2016 at 3:26 PM, Fred Baker (fred) <[email-masked]> wrote:
>> I questioned that too. Ray tells me we have never run at a net loss, at least since leaving CNRI.
>> 
>>> On May 24, 2016, at 9:31 PM, George Michaelson <[email-masked]> wrote:
>>> 
>>> The economics of the venue allow the meeting to be net cash
>>>     positive [Mandatory].
>>> 
>>> Really? the IETF won't go to a venue if there is a forseeable loss?
>>> 
>>> How do you grow things, if you don't invest?
>>> 
>>> -G
>>> 
>>> On Wed, May 25, 2016 at 12:10 PM,  <[email-masked]> wrote:
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> 
>>>> 
>>>>       Title           : IAOC Plenary Meeting Venue Selection Process
>>>>       Author          : Fred Baker
>>>>       Filename        : draft-baker-mtgvenue-iaoc-venue-selection-process-02.txt
>>>>       Pages           : 15
>>>>       Date            : 2016-05-24
>>>> 
>>>> Abstract:
>>>>  This documents the IAOC's IETF Meeting Venue Selection Process from
>>>>  the perspective of its goals and thought processes.  It points to
>>>>  additional process documents on the IAOC Web Site that go into
>>>>  further detail and are subject to change with experience.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-baker-mtgvenue-iaoc-venue-selection-process/
>>>> 
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-baker-mtgvenue-iaoc-venue-selection-process-02
>>>> 
>>>> 
>>>> Please note that it may take a couple of minutes from the time of submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>> 
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 May 2016 16:09:04 -0700

>> > maybe its 'subject to review' in future: needs explicit approval in

Interesting.

I think I understand a model that views this issue as involving an 
'investment'.  And I think it can be a legitimate view, in special 
circumstances.

But I doubt it's legitimate for the IETF, absent an extremely careful 
and clear and compelling business case.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: George Michaelson <[email-masked]>
Date: Thu, 26 May 2016 09:48:22 +1000

First of all, simply saying "must not make a loss" doesn't actually
stop it making a loss. contingencies happen. sponsors pull out, or go
broke, or commit fraud. fire. &c. even after insurance, IETF can wind
up out of pocket.

Secondly, whilst i understand some (not all, and undoubtedly coloured
by my sources) background to the long held fear of being bankrupt, It
is entirely normal for not-for-profit entities to carry costs forward
between events, between years.

So I'm looking at a MUST normative rule which is being placed along
side a range of financial and non-financial criteria, all of which
impute consequence in costs, some to the IETF as an entity and some to
us, attendees as individuals.

I can't see why this alone, is in the realms of a MUST, when in
practice, its entirely possible that (a) it won't be met and (b) we
might have a high preference venue, which on all other grounds is
compelling, but because we cannot AT THIS STAGE confirm its positive
for cash, we have to decline.

I think "extremely careful and clear and compelling business case"
covers it: The MUST quality should be constrained by language which
says "unless we really really really want to"

-G

On Thu, May 26, 2016 at 9:09 AM, Dave Crocker <[email-masked]> wrote:
> But I doubt it's legitimate for the IETF, absent an extremely careful and
> clear and compelling business case.
>
> d/
>
> --
>
>   Dave Crocker

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 26 May 2016 00:06:03 +0000

> On May 25, 2016, at 4:48 PM, George Michaelson <[email-masked]> wrote:
> 

Which sounds like "SHOULD"

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 May 2016 17:09:21 -0700

> Which sounds like "SHOULD"

I doubt it.  Any rule is subject to exception.  The fact that something 
is classed as mandatory does not mean that there can't be an exceptions 
process, such as community override.

To answer the range of examples that George just noted, I'll suggest 
that there is a difference between planning for a loss, versus 
encountering an unexpected one.  I take the mandatory as referring to 
the former.  It makes no sense to have a rule that mandates no 
unexpected problems...

d/

-- 

   Dave Crocker

---

From: George Michaelson <[email-masked]>
Date: Thu, 26 May 2016 10:17:01 +1000

I'm happy with that context. If you want to retain a MUST over a
forseeable loss, I won't object.

-G

On Thu, May 26, 2016 at 10:09 AM, Dave Crocker <[email-masked]> wrote:
> I doubt it.  Any rule is subject to exception.  The fact that something is
> classed as mandatory does not mean that there can't be an exceptions
> To answer the range of examples that George just noted, I'll suggest that
> there is a difference between planning for a loss, versus encountering an
> unexpected one.  I take the mandatory as referring to the former.  It makes
> no sense to have a rule that mandates no unexpected problems...
>
>
> d/
>
> --
>
>   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 May 2016 17:18:36 -0700

> forseeable loss, I won't object.

the term 'forseeable loss' sounds nicely clear, concise and useful.

d/

-- 

   Dave Crocker

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 26 May 2016 00:47:13 +0000

> the term 'forseeable loss' sounds nicely clear, concise and useful.

Sounds good to me.

<pedantic>
I could imagine somebody foreseeing a loss but the committee not, and there eventually being a loss. The fact that someone saw it coming says it was foreseeable, even if the person was hearing voices in their head.

There is also the question of who saw it when. Suppose we're proceeding swimmingly up to N months before the event, and then a major funding source collapses (host pulls out or whatever). One could argue that it was "foreseeable" N months before the event. (IIRC, this has happened, and the mitigation N months in advance involved cutting costs).

I'll want to think of a way to word it that will allow for good planning followed by reverses that in turn call for mitigations. Suggested text accepted...
</pedantic>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 May 2016 11:32:44 +1200

Hi,

A few comments; sorry if some of them are old as I have only just joined
this list.

> 1.  Introduction

It would be helpful if the draft mentioned the discussion venue
(presumably https://www.ietf.org/mailman/listinfo/mtgvenue)

> 3.1.  Venue Selection Principles
...
>    Who are we?
>       We are computer scientists, engineers, network operators,
>       academics, and other interested parties sharing the goal of making
>       the Internet work better.  At this time, the vast majority of
>       attendees come from North America, Western and Central Europe, and
>       Eastern Asia.  We also have participants from other regions.

s/attendees/participants/ please. Otherwise it sounds as if the whole
venue selection process is slanted towards people who already travel
to meetings.

> 3.3.5.  Food and Beverage
> 
>    o  The Venue environs, which includes onsite, and the areas within a
>       reasonable walking distance, or conveniently accessible by a short
>       taxi, bus, or subway ride, has convenient and inexpensive choices
>       for meals that can accommodate a wide range of dietary
>       requirements.  [Mandatory]

Anybody remember Munich? I would add a note that suitable opening times and
speed of service are essential.

> 3.4.  Non-criteria

More needed here. For example:

 o While the IETF often organizes a Companion Program for friends or
   family members of attendees, the availability of such a program is
   not a criterion.

 o While attendees often choose to take some vacation time at or near
   the venue city, the availability of tourist attractions is not
   a criterion.

 o While the IETF often organizes a social event one evening, the quality
   of this event is not in itself a criterion.

Regards,
    Brian