Re: IETF Endowment update

"Scott O. Bradner" <sob@sobco.com> Fri, 15 July 2016 21:59 UTC

Return-Path: <sob@sobco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F371012D890 for <ietf@ietfa.amsl.com>; Fri, 15 Jul 2016 14:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level:
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 I98k-L52KHh5 for <ietf@ietfa.amsl.com>; Fri, 15 Jul 2016 14:59:08 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD5D12D844 for <ietf@ietf.org>; Fri, 15 Jul 2016 14:59:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 63E72260AC9C; Fri, 15 Jul 2016 17:59:07 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3ctSfOarGZx; Fri, 15 Jul 2016 17:59:05 -0400 (EDT)
Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id EAA8A260AC8D; Fri, 15 Jul 2016 17:59:04 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: IETF Endowment update
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <70EA6724-904D-422C-A468-371549762EDA@shockey.us>
Date: Fri, 15 Jul 2016 17:53:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <78544314-01D5-4E56-824B-D7736C45CA07@sobco.com>
References: <20160715000647.41148.qmail@ary.lan> <44BE89E0-70F5-4CEC-B660-FEF90365AC4A@gmail.com> <0b11500e-9c21-c583-79f6-4cd33b0b9067@cisco.com> <5789429A.3070503@alvestrand.no> <CAMm+Lwj=gA+ZPOgBR=-T1M8+L9MPZta-w6cevFR-Lk2re+cfzw@mail.gmail.com> <70EA6724-904D-422C-A468-371549762EDA@shockey.us>
To: Richard Shockey <richard@shockey.us>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pI80bpo5Qe-o1kUU6l0CSeFU6kA>
Cc: Harald Tveit Alvestrand <harald@alvestrand.no>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2016 21:59:10 -0000

> On Jul 15, 2016, at 4:57 PM, Richard Shockey <richard@shockey.us> wrote:
> 
>  
> Nahh… sell naming rights to protocols and WG’s.   You can’t form a new WG until you can sell off the naming rights… there is a start. 

see REC 5241
>  
> Rename TCP/IP to the “Alphabet” protocol.  Lets see 20M over 15 years.
>  
> SIP to the ATT/SIP protocol ..  
>  
> — 
> Richard Shockey
> Shockey Consulting LLC
> Chairman of the Board SIP Forum
> www.shockey.us
> www.sipforum.org
> richard<at>shockey.us
> Skype-Linkedin-Facebook rshockey101
> PSTN +1 703-593-2683
>  
>  
> From: ietf <ietf-bounces@ietf.org> on behalf of Phillip Hallam-Baker <phill@hallambaker.com>
> Date: Friday, July 15, 2016 at 10:36 PM
> To: Harald Alvestrand <harald@alvestrand.no>
> Cc: IETF Discussion Mailing List <ietf@ietf.org>
> Subject: Re: IETF Endowment update
>  
> +1 to Harald's point.
>  
> I have been worrying that the conference fee model is a trap for quite a while. It is very similar to the 'innovators dilemma' problem.
>  
>  
> There is one other way round that could work and that is to adopt the Linux foundation model of giving paid courses to non experts. Which would in effect mean using the IETF brand to go into the training business.
>  
> But that isn't an entirely risk free proposition. The course material would have to be designed not to compete with other courses that companies participating in IETF provide, so no product training. And the other problem is that the reason training has insane margins is that it hits a wall and goes to $0 when a recession hits.
>  
>  
> What is clear is that the current approach isn't sustainable. We are making many modes of working obsolete including the way the IETF does business. 
>  
> Ooops.
>  
>  
> On Fri, Jul 15, 2016 at 4:07 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>> One of the things I've learned in dealing with budgets is that the size
>> of your reserves significantly influences the size of the risk you can
>> take - with any steering group with financial responsibility, they will
>> not take risks where the potential downside is larger than the reserves
>> of the organization.
>> 
>> This means that an organziation without reserves is, by necessity, a
>> timid organization.
>> Some of that can be mitigated by depending on other organizations'
>> reserves (like IETF depends on ISOC), but it's not necessarily a good
>> thing for either organizations to be in such a relationshiop.
>> 
>> The IETF needs to be the very opposite of timid going forward.
>> Reserves will help that.
>> 
>> I see the IETF Endowment as a means of making sure the IETF has the
>> reserves to take the risks it needs to take without asking our leaders
>> to abandon financial responsibility.
>> 
>> I'm proud to have my name on the list of sponsors.
>> 
>> Harald
>> 
>> 
>