IETF Logo Mail Archive

Re: [Iasa20] IASA 2.0 minutes

"Eggert, Lars" <lars@netapp.com> Mon, 24 April 2017 07:07 UTC

Return-Path: <lars@netapp.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6823F128CB9 for <iasa20@ietfa.amsl.com>; Mon, 24 Apr 2017 00:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com
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 CmEdLmrYgFg3 for <iasa20@ietfa.amsl.com>; Mon, 24 Apr 2017 00:07:36 -0700 (PDT)
Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384D7128C83 for <iasa20@ietf.org>; Mon, 24 Apr 2017 00:07:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.37,243,1488873600"; d="asc'?scan'208";a="197790674"
Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx141-out.netapp.com with ESMTP; 23 Apr 2017 23:53:33 -0700
Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 00:06:07 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 24 Apr 2017 00:06:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LiVnPhns12xKwB8W8BNxBxePB+Dtzl8ArwHGVvbzWBI=; b=WO6XykbhdWLjIB0Vx63OgqDIbEj13KSDCqV0jMf0YZZuKxsU85av5fGcCPRVks0vrdHs6sj35a39h8H5uW0QDwyFuOMqJcUhTp6WtjW1GjgpizP/OjTvn/AeIjTjG20lnpRhbU8871AupDJPGiWa+AWYNwMhu6t0SmNZbazryFE=
Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Mon, 24 Apr 2017 07:06:15 +0000
Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1047.019; Mon, 24 Apr 2017 07:06:15 +0000
From: "Eggert, Lars" <lars@netapp.com>
To: Alissa Cooper <alissa@cooperw.in>
CC: Glenn Deen <rgd.ietf@gmail.com>, "Livingood, Jason" <Jason_Livingood@comcast.com>, Jari Arkko <jari.arkko@piuha.net>, "iasa20@ietf.org" <iasa20@ietf.org>
Thread-Topic: [Iasa20] IASA 2.0 minutes
Thread-Index: AQHSqWWgHUgd0Msj5UqQwO+xqkA+E6GzuncAgABpKACAAA95gIAbxG+AgABu64CAAUHngIACOZmAgABdxQA=
Date: Mon, 24 Apr 2017 07:06:15 +0000
Message-ID: <2B2097E4-F309-4A62-990C-67225354C259@netapp.com>
References: <CABkgnnW2CYoLcfpTwgqKYo0WKfJAjK1gTmNuaamSp=mibtSDUg@mail.gmail.com> <9AE1C2CB-F2D1-4796-8D10-C625D16D41DC@cooperw.in> <d6ecdbc2-bcbb-f4e8-d914-e57ad094714f@gmail.com> <A15970F6-4D71-4C98-A057-393D5CD510EA@cable.comcast.com> <aca56723-49cf-206f-ae57-13c35498a974@gmail.com> <68A7AFC8-A2BE-4906-9767-4ED2B4BA2268@piuha.net> <592432f8-68a9-8069-1c90-fe7dd70d97fc@gmail.com> <B1609C31-505A-4149-9757-E1226CFD195E@gmail.com> <F8062A8E-4366-411E-B8EE-4304EADFFCC1@cooperw.in>
In-Reply-To: <F8062A8E-4366-411E-B8EE-4304EADFFCC1@cooperw.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3273)
authentication-results: cooperw.in; dkim=none (message not signed) header.d=none;cooperw.in; dmarc=none action=none header.from=netapp.com;
x-originating-ip: [217.70.211.15]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 7:Yi28RkDuanDJ/iXqsizTp6EbPUnSk6UzFTSRa7ykPQwd6EhEF8s8E0kuShMmUGdbdM1RgHok6eRFBWNZXb37/suA5i07O1uxG04WQnpHMG0DBIU6TexSxmufRM2d+KBwn5f/3tGrFxu9Cv7/E90cPiv0R/803gYYbY98+k4ejemUbSvs3nqHM1dAymXzcyy356OH4T9ycvt+RLf/8oUEtFKe/GpPDCKdTzIqvogeQfWuc88cf+3usXL6jyeodf7mtdRPAkDdfmSQK91tG084p6d8B2c9/bEGeM+on4eQYkzvV02rjynIJgib1HvFKAShGGaoEubfSqkqoBBviUjQiQ==
x-ms-office365-filtering-correlation-id: 9af65392-23c8-40f0-5b0f-08d48ae065fb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1764;
x-microsoft-antispam-prvs: <BLUPR06MB17643D3A41740BA15610809BA71F0@BLUPR06MB1764.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764;
x-forefront-prvs: 0287BBA78D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39450400003)(39840400002)(39410400002)(39400400002)(377424004)(24454002)(50226002)(8676002)(6246003)(7736002)(305945005)(6506006)(77096006)(2900100001)(8936002)(229853002)(6486002)(2906002)(110136004)(36756003)(81166006)(83716003)(2950100002)(3280700002)(6916009)(82746002)(6436002)(189998001)(3660700001)(5660300001)(86362001)(6512007)(76176999)(4001150100001)(50986999)(53936002)(99936001)(99286003)(54906002)(53546009)(25786009)(122556002)(33656002)(57306001)(93886004)(39060400002)(4326008)(66066001)(102836003)(3846002)(6116002)(38730400002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_B231B358-E6B9-4E8F-ACF2-D36A419FBA22"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 07:06:15.2359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764
X-OriginatorOrg: netapp.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/qgOOTLY5UaTJL75l1EJpd386qAs>
Subject: Re: [Iasa20] IASA 2.0 minutes
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 07:07:37 -0000

On 2017-4-24, at 3:30, Alissa Cooper <alissa@cooperw.in> wrote:
> So perhaps what we want to strive for here is flexibility: the ability for some sponsors to support specific meeting-related items, and others to provide more generalized support for IETF administration. I don’t see compelling reasons why we shouldn’t be able to support both options at once.

Flexibility is good.

But general-purpose support is more useful than support that can only be spent on certain things. I think we want to give sponsors choices as to what things are *branded* as having received their support, without being restricted by actually spending the money received from a sponsor on exactly only those things.

Again using SIGCOMM as an example, *all* sponsor dollars end up in a general budget. A sponsor can request that, say, the Tuesday lunch is *branded* as having received their support, but the conference retains flexibility in where those funds are actually spent (well, in reality, since it's all going into one pool, we don't track).

In-kind support (which SIGCOMM doesn't have, other than universities providing free rooms, etc.) of course can't be thrown into the support pool, but I think we have few enough of these sponsors and they are unique enough that special-casing them is not an issue.

Lars

v2.23.0 | Report a Bug | By Email